dri-devel June 2020

dri-devel@lists.freedesktop.org

315 participants
731 discussions

[PATCH] drm/msm/dpu: fix error return code in dpu_encoder_init
by Chen Tao 08 Jun '20

08 Jun '20

Fix to return negative error code -ENOMEM with the use of ERR_PTR from dpu_encoder_init. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Chen Tao <chentao107(a)huawei.com> --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index a1b79ee2bd9d..a2f6b688a976 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -2173,7 +2173,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device *dev, dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL); if (!dpu_enc) - return ERR_PTR(ENOMEM); + return ERR_PTR(-ENOMEM); rc = drm_encoder_init(dev, &dpu_enc->base, &dpu_encoder_funcs, drm_enc_mode, NULL); -- 2.22.0

1 0

Enable fp16 scanout on DCE 8 and DCE 10
by Mario Kleiner 07 Jun '20

07 Jun '20

So i'm sending these on the off-chance that DCE-8/10 do support fp16 scanout without hw bugs. Would be nice to enable this if it is supported, even if the hw can't do HDR. This is also useful for non-HDR to get effectively 11 bpc precision from the fb to the display outputs for more precise color reproduction. thanks, -mario

1 2

[PATCH v3 00/13] PCI: brcmstb: enable PCIe for STB chips
by Jim Quinlan 05 Jun '20

05 Jun '20

v3: Commit "device core: Introduce multiple dma pfn offsets" Commit "arm: dma-mapping: Invoke dma offset func if needed" -- The above two commits have been squashed. More importantly, the code has been modified so that the functionality for multiple pfn offsets subsumes the use of dev->dma_pfn_offset. In fact, dma_pfn_offset is removed and supplanted by dma_pfn_offset_map, which is a pointer to an array. The more common case of a uniform offset is now handled as a map with a single entry, while cases requiring multiple pfn offsets use a map with multiple entries. Code paths that used to do this: dev->dma_pfn_offset = mydrivers_pfn_offset; have been changed to do this: attach_uniform_dma_pfn_offset(dev, pfn_offset); Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips" -- Add if/then clause for required props: resets, reset-names (RobH) -- Change compatible list from const to enum (RobH) -- Change list of u32-tuples to u64 (RobH) Commit "of: Include a dev param in of_dma_get_range()" -- modify of/unittests.c to add NULL param in of_dma_get_range() call. Commit "device core: Add ability to handle multiple dma offsets" -- align comment in device.h (AndyS). -- s/cpu_beg/cpu_start/ and s/dma_beg/dma_start/ in struct dma_pfn_offset_region (AndyS). v2: Commit: "device core: Add ability to handle multiple dma offsets" o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph) o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph) o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP o dev->dma_pfn_map => dev->dma_pfn_offset_map o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph) o In device.h: s/const void */const struct dma_pfn_offset_region */ o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph) o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now dev->dma_pfn_offset_map is copied as well. o Merged two of the DMA commits into one (Christoph). Commit "arm: dma-mapping: Invoke dma offset func if needed": o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET Other commits' changes: o Removed need for carrying of_id var in priv (Nicolas) o Commit message rewordings (Bjorn) o Commit log messages filled to 75 chars (Bjorn) o devm_reset_control_get_shared()) => devm_reset_control_get_optional_shared (Philipp) o Add call to reset_control_assert() in PCIe remove routines (Philipp) v1: This patchset expands the usefulness of the Broadcom Settop Box PCIe controller by building upon the PCIe driver used currently by the Raspbery Pi. Other forms of this patchset were submitted by me years ago and not accepted; the major sticking point was the code required for the DMA remapping needed for the PCIe driver to work [1]. There have been many changes to the DMA and OF subsystems since that time, making a cleaner and less intrusive patchset possible. This patchset implements a generalization of "dev->dma_pfn_offset", except that instead of a single scalar offset it provides for multiple offsets via a function which depends upon the "dma-ranges" property of the PCIe host controller. This is required for proper functionality of the BrcmSTB PCIe controller and possibly some other devices. [1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-… Jim Quinlan (13): PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB ata: ahci_brcm: Fix use of BCM7216 reset controller dt-bindings: PCI: Add bindings for more Brcmstb chips PCI: brcmstb: Add bcm7278 reigister info PCI: brcmstb: Add suspend and resume pm_ops PCI: brcmstb: Add bcm7278 PERST support PCI: brcmstb: Add control of rescal reset of: Include a dev param in of_dma_get_range() device core: Introduce multiple dma pfn offsets PCI: brcmstb: Set internal memory viewport sizes PCI: brcmstb: Accommodate MSI for older chips PCI: brcmstb: Set bus max burst size by chip type PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list .../bindings/pci/brcm,stb-pcie.yaml | 58 ++- arch/arm/include/asm/dma-mapping.h | 9 +- arch/arm/mach-keystone/keystone.c | 9 +- arch/sh/drivers/pci/pcie-sh7786.c | 3 +- arch/sh/kernel/dma-coherent.c | 17 +- arch/x86/pci/sta2x11-fixup.c | 7 +- drivers/acpi/arm64/iort.c | 5 +- drivers/ata/ahci_brcm.c | 14 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 7 +- drivers/iommu/io-pgtable-arm.c | 2 +- .../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +- .../platform/sunxi/sun6i-csi/sun6i_csi.c | 5 +- drivers/of/address.c | 97 ++++- drivers/of/device.c | 10 +- drivers/of/of_private.h | 8 +- drivers/of/unittest.c | 2 +- drivers/pci/controller/Kconfig | 3 +- drivers/pci/controller/pcie-brcmstb.c | 408 +++++++++++++++--- drivers/remoteproc/remoteproc_core.c | 2 +- .../staging/media/sunxi/cedrus/cedrus_hw.c | 7 +- drivers/usb/core/message.c | 4 +- drivers/usb/core/usb.c | 2 +- include/linux/device.h | 4 +- include/linux/dma-direct.h | 16 +- include/linux/dma-mapping.h | 45 ++ kernel/dma/coherent.c | 11 +- 26 files changed, 631 insertions(+), 129 deletions(-) -- 2.17.1

4 13

[drm-intel:drm-intel-next-queued 1/7] drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:933:21: error: unused function 'unmask_page'
by kernel test robot 05 Jun '20

05 Jun '20

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 84d24cb5247a356a4310a25761f8aa56b8814538 commit: 9e0f9464e2ab36b864359a59b0e9058fdef0ce47 [1/7] drm/i915/gem: Async GPU relocations only config: x86_64-randconfig-a011-20200605 (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 6dd738e2f0609f7d3313b574a1d471263d2d3ba1) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu git checkout 9e0f9464e2ab36b864359a59b0e9058fdef0ce47 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> All errors (new ones prefixed by >>, old ones prefixed by <<): >> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:933:21: error: unused function 'unmask_page' [-Werror,-Wunused-function] static inline void *unmask_page(unsigned long p) ^ >> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:938:28: error: unused function 'unmask_flags' [-Werror,-Wunused-function] static inline unsigned int unmask_flags(unsigned long p) ^ >> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:945:33: error: unused function 'cache_to_ggtt' [-Werror,-Wunused-function] static inline struct i915_ggtt *cache_to_ggtt(struct reloc_cache *cache) ^ 3 errors generated. vim +/unmask_page +933 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 5032d871f7d300 drivers/gpu/drm/i915/i915_gem_execbuffer.c Rafael Barbalho 2013-08-21 932 d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 @933 static inline void *unmask_page(unsigned long p) d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 934 { d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 935 return (void *)(uintptr_t)(p & PAGE_MASK); d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 936 } d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 937 d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 @938 static inline unsigned int unmask_flags(unsigned long p) d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 939 { d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 940 return p & ~PAGE_MASK; d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 941 } d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 942 d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 943 #define KMAP 0x4 /* after CLFLUSH_FLAGS */ d50415cc6c8395 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2016-08-18 944 650bc63568e421 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2017-06-15 @945 static inline struct i915_ggtt *cache_to_ggtt(struct reloc_cache *cache) 650bc63568e421 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2017-06-15 946 { 650bc63568e421 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2017-06-15 947 struct drm_i915_private *i915 = 650bc63568e421 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2017-06-15 948 container_of(cache, struct i915_execbuffer, reloc_cache)->i915; 650bc63568e421 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2017-06-15 949 return &i915->ggtt; 650bc63568e421 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2017-06-15 950 } 650bc63568e421 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2017-06-15 951 :::::: The code at line 933 was first introduced by commit :::::: d50415cc6c8395602052b39a1a39290fba3d313e drm/i915: Refactor execbuffer relocation writing :::::: TO: Chris Wilson <chris(a)chris-wilson.co.uk> :::::: CC: Chris Wilson <chris(a)chris-wilson.co.uk> --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

1 0

[PATCH v3] drm: document how user-space should use link-status
by Simon Ser 05 Jun '20

05 Jun '20

Describe what a "BAD" link-status means for user-space and how it should handle it. The logic described has been implemented in igt [1]. v2: - Change wording to avoid "enabled" (Daniel) - Add paragraph about multiple connectors sharing the same CRTC (Pekka) - Add paragraph about performing an atomic commit on a connector without updating the link-status property (Daniel) v3: - Fix description of what happens when link-status isn't reset to "GOOD", and when link-status is reset without ALLOW_MODESET (Daniel, Ville) - Changing link-status to "BAD" is a no-op - Clearly state that "BAD" means black screen (Manasi) [1]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/fbe61f529737191d0… Signed-off-by: Simon Ser <contact(a)emersion.fr> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Manasi Navare <manasi.d.navare(a)intel.com> Cc: Ville Syrjala <ville.syrjala(a)linux.intel.com> Cc: Pekka Paalanen <ppaalanen(a)gmail.com> --- I'm not 100% sure the paragraph about not resetting link-status or not using ALLOW_MODESET is accurate. Just like the previous version, this is just an attempt at documenting the current kernel behaviour. drivers/gpu/drm/drm_connector.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index f2b20fd66319..1df036b3353b 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -994,6 +994,26 @@ static const struct drm_prop_enum_list dp_colorspaces[] = { * after modeset, the kernel driver may set this to "BAD" and issue a * hotplug uevent. Drivers should update this value using * drm_connector_set_link_status_property(). + * + * When user-space receives the hotplug uevent and detects a "BAD" + * link-status, the sink doesn't receive pixels anymore (e.g. the screen + * becomes completely black). The list of available modes may have + * changed. User-space is expected to pick a new mode if the current one + * has disappeared and perform a new modeset with link-status set to + * "GOOD" to re-enable the connector. + * + * If multiple connectors share the same CRTC and one of them gets a "BAD" + * link-status, the other are unaffected (ie. the sinks still continue to + * receive pixels). + * + * When user-space performs an atomic commit on a connector with a "BAD" + * link-status without resetting the property to "GOOD", the sink may + * still not receive pixels. When user-space performs an atomic commit + * which resets the link-status property to "GOOD" without the + * ALLOW_MODESET flag set, it might fail because a modeset is required. + * + * User-space can only change link-status to "GOOD", changing it to "BAD" + * is a no-op. * non_desktop: * Indicates the output should be ignored for purposes of displaying a * standard desktop environment or console. This is most likely because -- 2.26.2

3 2

[PATCH 2/2] drm/panel: simple: Add support for KOE TX26D202VM0BWA panel
by Liu Ying 05 Jun '20

05 Jun '20

This patch adds support for Kaohsiung Opto-Electronics Inc. 10.1" TX26D202VM0BWA WUXGA(1920x1200) TFT LCD panel with LVDS interface. The panel has dual LVDS channels. My panel is manufactured by US Micro Products(USMP). There is a tag at the back of the panel, which indicates the panel type is 'TX26D202VM0BWA' and it's made by KOE in Taiwan. The panel spec from USMP can be found at: https://www.usmicroproducts.com/sites/default/files/datasheets/USMP-T101-19… The below panel spec from KOE is basically the same to the one from USMP. However, the panel type 'TX26D202VM0BAA' is a little bit different. It looks that the two types of panel are compatible with each other. http://www.koe.j-display.com/upload/product/TX26D202VM0BAA.pdf Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Signed-off-by: Liu Ying <victor.liu(a)nxp.com> --- drivers/gpu/drm/panel/panel-simple.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index b6ecd15..7c222ec 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -2200,6 +2200,37 @@ static const struct panel_desc koe_tx14d24vm1bpa = { }, }; +static const struct display_timing koe_tx26d202vm0bwa_timing = { + .pixelclock = { 151820000, 156720000, 159780000 }, + .hactive = { 1920, 1920, 1920 }, + .hfront_porch = { 105, 130, 142 }, + .hback_porch = { 45, 70, 82 }, + .hsync_len = { 30, 30, 30 }, + .vactive = { 1200, 1200, 1200}, + .vfront_porch = { 3, 5, 10 }, + .vback_porch = { 2, 5, 10 }, + .vsync_len = { 5, 5, 5 }, +}; + +static const struct panel_desc koe_tx26d202vm0bwa = { + .timings = &koe_tx26d202vm0bwa_timing, + .num_timings = 1, + .bpc = 8, + .size = { + .width = 217, + .height = 136, + }, + .delay = { + .prepare = 1000, + .enable = 1000, + .unprepare = 1000, + .disable = 1000, + }, + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE, + .connector_type = DRM_MODE_CONNECTOR_LVDS, +}; + static const struct display_timing koe_tx31d200vm0baa_timing = { .pixelclock = { 39600000, 43200000, 48000000 }, .hactive = { 1280, 1280, 1280 }, @@ -3832,6 +3863,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "koe,tx14d24vm1bpa", .data = &koe_tx14d24vm1bpa, }, { + .compatible = "koe,tx26d202vm0bwa", + .data = &koe_tx26d202vm0bwa, + }, { .compatible = "koe,tx31d200vm0baa", .data = &koe_tx31d200vm0baa, }, { -- 2.7.4

3 5

[PATCH 0/2] drm/panel: simple: Add a KOE WUXGA 10.1" LVDS panel support
by Liu Ying 05 Jun '20

05 Jun '20

This patch set adds a KOE WUXGA 10.1" LVDS panel support. The panel type is TX26D202VM0BWA. The panel has dual LVDS channels. My panel is manufactured by US Micro Products(USMP). There is a tag at the back of the panel, which indicates the panel type is 'TX26D202VM0BWA' and it's made by KOE in Taiwan. The panel spec from USMP can be found at: https://www.usmicroproducts.com/sites/default/files/datasheets/USMP-T101-19… The below panel spec from KOE is basically the same to the one from USMP. However, the panel type 'TX26D202VM0BAA' is a little bit different. It looks that the two types of panel are compatible with each other. http://www.koe.j-display.com/upload/product/TX26D202VM0BAA.pdf Patch 1/2 adds compatible for the panel in the panel-simple DT binding doc. Patch 2/2 adds the panel support in the DRM panel-simple driver. Liu Ying (2): dt-bindings: panel-simple: Add koe,tx26d202vm0bwa compatible drm/panel: simple: Add support for KOE TX26D202VM0BWA panel .../bindings/display/panel/panel-simple.yaml | 2 ++ drivers/gpu/drm/panel/panel-simple.c | 34 ++++++++++++++++++++++ 2 files changed, 36 insertions(+) -- 2.7.4

2 1

[PATCH] drm/i915: Fix comments mentioning typo in IS_ENABLED()
by Kees Cook 05 Jun '20

05 Jun '20

This has no code changes, but the typo is clearly getting copy/pasted, so better to avoid this now and fix the typo. IS_ENABLED() takes full names, and must have the "CONFIG_" prefix. Reported-by: Joe Perches <joe(a)perches.com> Link: https://lore.kernel.org/lkml/b08611018fdb6d88757c6008a5c02fa0e07b32fb.camel… Signed-off-by: Kees Cook <keescook(a)chromium.org> --- drivers/dma-buf/selftests.h | 2 +- drivers/gpu/drm/i915/selftests/i915_live_selftests.h | 2 +- drivers/gpu/drm/i915/selftests/i915_mock_selftests.h | 2 +- drivers/gpu/drm/i915/selftests/i915_perf_selftests.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/selftests.h b/drivers/dma-buf/selftests.h index 55918ef9adab..bc8cea67bf1e 100644 --- a/drivers/dma-buf/selftests.h +++ b/drivers/dma-buf/selftests.h @@ -5,7 +5,7 @@ * a module parameter. It must be unique and legal for a C identifier. * * The function should be of type int function(void). It may be conditionally - * compiled using #if IS_ENABLED(DRM_I915_SELFTEST). + * compiled using #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST). * * Tests are executed in order by igt/dmabuf_selftest */ diff --git a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h index 5dd5d81646c4..e42ea9c6703b 100644 --- a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h +++ b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h @@ -11,7 +11,7 @@ * a module parameter. It must be unique and legal for a C identifier. * * The function should be of type int function(void). It may be conditionally - * compiled using #if IS_ENABLED(DRM_I915_SELFTEST). + * compiled using #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST). * * Tests are executed in order by igt/drv_selftest */ diff --git a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h index 6a2be7d0dd95..4be044198af9 100644 --- a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h +++ b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h @@ -11,7 +11,7 @@ * a module parameter. It must be unique and legal for a C identifier. * * The function should be of type int function(void). It may be conditionally - * compiled using #if IS_ENABLED(DRM_I915_SELFTEST). + * compiled using #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST). * * Tests are executed in order by igt/drv_selftest */ diff --git a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h index d8da142985eb..c2389f8a257d 100644 --- a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h +++ b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h @@ -11,7 +11,7 @@ * a module parameter. It must be unique and legal for a C identifier. * * The function should be of type int function(void). It may be conditionally - * compiled using #if IS_ENABLED(DRM_I915_SELFTEST). + * compiled using #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST). * * Tests are executed in order by igt/i915_selftest */ -- 2.25.1 -- Kees Cook

2 1

MIPI DSI, DBI, and tinydrm drivers
by Paul Cercueil 05 Jun '20

05 Jun '20

Hi list, I'd like to open a discussion about the current support of MIPI DSI and DBI panels. Both are standards from the MIPI alliance, both are communication protocols between a LCD controller and a LCD panel, they generally both use the same commands (DCS), the main difference is that DSI is serial and DBI is generally parallel. In the kernel right now, DSI is pretty well implemented. All the infrastucture to register a DSI host, DSI device etc. is there. DSI panels are implemented as regular drm_panel instances, and their drivers go through the DSI API to communicate with the panel, which makes them independent of the DSI host driver. DBI, on the other hand, does not have any of this. All (?) DBI panels are implemented as tinydrm drivers, which make them impossible to use with regular DRM drivers. Writing a standard drm_panel driver is impossible, as there is no concept of host and device. All these tinydrm drivers register their own DBI host as they all do DBI over SPI. I think this needs a good cleanup. Given that DSI and DBI are so similar, it would probably make sense to fuse DBI support into the current DSI code, as trying to update DBI would result in a lot of code being duplicated. With the proper host/device registration mechanism from DSI code, it would be possible to turn most of the tinydrm drivers into regular drm_panel drivers. The problem then is that these should still be available as tinydrm drivers. If the DSI/DBI panels can somehow register a .update_fb() callback, it would make it possible to have a panel-agnostic tinydrm driver, which would then probably open a lot of doors, and help a lot to clean the mess. I think I can help with that, I just need some guidance - I am fishing in exotic seas here. Thoughts, comments, are very welcome. Cheers, -Paul

6 20

[PATCH 1/2] drm: cleanup on drm_mode_object_find
by Ramalingam C 05 Jun '20

05 Jun '20

Redundant wrapper for drm_mode_object_find is removed. Signed-off-by: Ramalingam C <ramalingam.c(a)intel.com> --- drivers/gpu/drm/drm_crtc_internal.h | 6 ++--- drivers/gpu/drm/drm_framebuffer.c | 2 +- drivers/gpu/drm/drm_mode_object.c | 38 +++++++++++------------------ drivers/gpu/drm/drm_property.c | 6 ++--- 4 files changed, 21 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_internal.h b/drivers/gpu/drm/drm_crtc_internal.h index da96b2f64d7e..4bfde1367c1a 100644 --- a/drivers/gpu/drm/drm_crtc_internal.h +++ b/drivers/gpu/drm/drm_crtc_internal.h @@ -144,9 +144,9 @@ int drm_mode_object_add(struct drm_device *dev, struct drm_mode_object *obj, uint32_t obj_type); void drm_mode_object_register(struct drm_device *dev, struct drm_mode_object *obj); -struct drm_mode_object *__drm_mode_object_find(struct drm_device *dev, - struct drm_file *file_priv, - uint32_t id, uint32_t type); +struct drm_mode_object *drm_mode_object_find(struct drm_device *dev, + struct drm_file *file_priv, + uint32_t id, uint32_t type); void drm_mode_object_unregister(struct drm_device *dev, struct drm_mode_object *object); int drm_mode_object_get_properties(struct drm_mode_object *obj, bool atomic, diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 0375b3d7f8d0..023cea64e87d 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -888,7 +888,7 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct drm_device *dev, struct drm_mode_object *obj; struct drm_framebuffer *fb = NULL; - obj = __drm_mode_object_find(dev, file_priv, id, DRM_MODE_OBJECT_FB); + obj = drm_mode_object_find(dev, file_priv, id, DRM_MODE_OBJECT_FB); if (obj) fb = obj_to_fb(obj); return fb; diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c index 901b078abf40..6c5e689d8b60 100644 --- a/drivers/gpu/drm/drm_mode_object.c +++ b/drivers/gpu/drm/drm_mode_object.c @@ -133,9 +133,20 @@ bool drm_mode_object_lease_required(uint32_t type) } } -struct drm_mode_object *__drm_mode_object_find(struct drm_device *dev, - struct drm_file *file_priv, - uint32_t id, uint32_t type) +/** + * drm_mode_object_find - look up a drm object with static lifetime + * @dev: drm device + * @file_priv: drm file + * @id: id of the mode object + * @type: type of the mode object + * + * This function is used to look up a modeset object. It will acquire a + * reference for reference counted objects. This reference must be dropped again + * by callind drm_mode_object_put(). + */ +struct drm_mode_object *drm_mode_object_find(struct drm_device *dev, + struct drm_file *file_priv, + uint32_t id, uint32_t type) { struct drm_mode_object *obj = NULL; @@ -158,27 +169,6 @@ struct drm_mode_object *__drm_mode_object_find(struct drm_device *dev, return obj; } - -/** - * drm_mode_object_find - look up a drm object with static lifetime - * @dev: drm device - * @file_priv: drm file - * @id: id of the mode object - * @type: type of the mode object - * - * This function is used to look up a modeset object. It will acquire a - * reference for reference counted objects. This reference must be dropped again - * by callind drm_mode_object_put(). - */ -struct drm_mode_object *drm_mode_object_find(struct drm_device *dev, - struct drm_file *file_priv, - uint32_t id, uint32_t type) -{ - struct drm_mode_object *obj = NULL; - - obj = __drm_mode_object_find(dev, file_priv, id, type); - return obj; -} EXPORT_SYMBOL(drm_mode_object_find); /** diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c index 6ee04803c362..f1e338f909f1 100644 --- a/drivers/gpu/drm/drm_property.c +++ b/drivers/gpu/drm/drm_property.c @@ -656,7 +656,7 @@ struct drm_property_blob *drm_property_lookup_blob(struct drm_device *dev, struct drm_mode_object *obj; struct drm_property_blob *blob = NULL; - obj = __drm_mode_object_find(dev, NULL, id, DRM_MODE_OBJECT_BLOB); + obj = drm_mode_object_find(dev, NULL, id, DRM_MODE_OBJECT_BLOB); if (obj) blob = obj_to_blob(obj); return blob; @@ -919,8 +919,8 @@ bool drm_property_change_valid_get(struct drm_property *property, if (value == 0) return true; - *ref = __drm_mode_object_find(property->dev, NULL, value, - property->values[0]); + *ref = drm_mode_object_find(property->dev, NULL, value, + property->values[0]); return *ref != NULL; } -- 2.20.1

1 1

← Newer
1
...
63
64
65
66
67
68
69
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2020