dri-devel June 2022

dri-devel@lists.freedesktop.org

332 participants
697 discussions

[PATCH v5 0/9] Add new formats support to vkms
by Igor Torrente 13 Jun '22

13 Jun '22

Summary ======= This series of patches refactor some vkms components in order to introduce new formats to the planes and writeback connector. Now in the blend function, the plane's pixels are converted to ARGB16161616 and then blended together. The CRC is calculated based on the ARGB1616161616 buffer. And if required, this buffer is copied/converted to the writeback buffer format. And to handle the pixel conversion, new functions were added to convert from a specific format to ARGB16161616 (the reciprocal is also true). Tests ===== This patch series was tested using the following igt tests: -t ".*kms_plane.*" -t ".*kms_writeback.*" -t ".*kms_cursor_crc*" -t ".*kms_flip.*" New tests passing ------------------- - pipe-A-cursor-size-change - pipe-A-cursor-alpha-transparent Performance ----------- It's running slightly faster than the current implementation. Results running the IGT[1] test `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times: | Frametime | |:--------------------------------------------:| | Implementation | Current | This commit | |:---------------:|:---------:|:--------------:| | frametime range | 9~22 ms | 10~22 ms | | Average | 11.4 ms | 12.32 ms | Memory consumption ================== It consumes less memory than the current implementation in the common case (more detail in the commit message). | Memory consumption (output dimensions) | |:--------------------------------------:| | Current | This patch | |:------------------:|:-----------------:| | Width * Heigth | 2 * Width | [1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4 XRGB to ARGB behavior ===================== During the development, I decided to always fill the alpha channel of the output pixel whenever the conversion from a format without an alpha channel to ARGB16161616 is necessary. Therefore, I ignore the value received from the XRGB and overwrite the value with 0xFFFF. Primary plane and CRTC size =========================== This patch series reworks the blend function to accept a primary plane with a different size and position from CRTC. Because now we need to fill the background, we had a loss in performance with this change --- Igor Torrente (9): drm: vkms: Alloc the compose frame using vzalloc drm: vkms: Replace hardcoded value of `vkms_composer.map` to DRM_FORMAT_MAX_PLANES drm: vkms: Rename `vkms_composer` to `vkms_frame_info` drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation drm: vkms: Add fb information to `vkms_writeback_job` drm: vkms: Refactor the plane composer to accept new formats drm: vkms: Supports to the case where primary plane doesn't match the CRTC drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats drm: vkms: Add support to the RGB565 format Documentation/gpu/vkms.rst | 13 +- drivers/gpu/drm/drm_atomic_helper.c | 39 ++++ drivers/gpu/drm/vkms/Makefile | 1 + drivers/gpu/drm/vkms/vkms_composer.c | 325 ++++++++++++-------------- drivers/gpu/drm/vkms/vkms_crtc.c | 4 + drivers/gpu/drm/vkms/vkms_drv.h | 41 +++- drivers/gpu/drm/vkms/vkms_formats.c | 298 +++++++++++++++++++++++ drivers/gpu/drm/vkms/vkms_formats.h | 12 + drivers/gpu/drm/vkms/vkms_plane.c | 50 ++-- drivers/gpu/drm/vkms/vkms_writeback.c | 35 ++- include/drm/drm_atomic_helper.h | 3 + 11 files changed, 596 insertions(+), 225 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h -- 2.30.2

5 43

[PATCH] drm/msm: Deprecate MSM_BO_UNCACHED harder
by Rob Clark 13 Jun '22

13 Jun '22

From: Rob Clark <robdclark(a)chromium.org> Handle the demotion to MSM_BO_WC at the userspace ABI level, and fix the remaining internal MSM_BO_UNCACHED user. Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/msm/msm_drv.c | 13 +++++++++++++ drivers/gpu/drm/msm/msm_gem.c | 7 +++---- drivers/gpu/drm/msm/msm_gpu.c | 2 +- 3 files changed, 17 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index 57a66093e671..acc940d32ab4 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -633,12 +633,25 @@ static int msm_ioctl_gem_new(struct drm_device *dev, void *data, struct drm_file *file) { struct drm_msm_gem_new *args = data; + uint32_t flags = args->flags; if (args->flags & ~MSM_BO_FLAGS) { DRM_ERROR("invalid flags: %08x\n", args->flags); return -EINVAL; } + /* + * Uncached CPU mappings are deprecated, as of: + * + * 9ef364432db4 ("drm/msm: deprecate MSM_BO_UNCACHED (map as writecombine instead)") + * + * So promote them to WC. + */ + if (flags & MSM_BO_UNCACHED) { + flags &= ~MSM_BO_CACHED; + flags |= MSM_BO_WC; + } + return msm_gem_new_handle(dev, file, args->size, args->flags, &args->handle, NULL); } diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 9a73e48a3049..35845e273d81 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -129,7 +129,7 @@ static struct page **get_pages(struct drm_gem_object *obj) /* For non-cached buffers, ensure the new pages are clean * because display controller, GPU, etc. are not coherent: */ - if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) + if (msm_obj->flags & MSM_BO_WC) sync_for_device(msm_obj); update_inactive(msm_obj); @@ -160,7 +160,7 @@ static void put_pages(struct drm_gem_object *obj) * pages are clean because display controller, * GPU, etc. are not coherent: */ - if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) + if (msm_obj->flags & MSM_BO_WC) sync_for_cpu(msm_obj); sg_free_table(msm_obj->sgt); @@ -213,7 +213,7 @@ void msm_gem_put_pages(struct drm_gem_object *obj) static pgprot_t msm_gem_pgprot(struct msm_gem_object *msm_obj, pgprot_t prot) { - if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) + if (msm_obj->flags & MSM_BO_WC) return pgprot_writecombine(prot); return prot; } @@ -1122,7 +1122,6 @@ static int msm_gem_new_impl(struct drm_device *dev, struct msm_gem_object *msm_obj; switch (flags & MSM_BO_CACHE_MASK) { - case MSM_BO_UNCACHED: case MSM_BO_CACHED: case MSM_BO_WC: break; diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index f99292eaf529..e59a757578df 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -952,7 +952,7 @@ int msm_gpu_init(struct drm_device *drm, struct platform_device *pdev, memptrs = msm_gem_kernel_new(drm, sizeof(struct msm_rbmemptrs) * nr_rings, - check_apriv(gpu, MSM_BO_UNCACHED), gpu->aspace, &gpu->memptrs_bo, + check_apriv(gpu, MSM_BO_WC), gpu->aspace, &gpu->memptrs_bo, &memptrs_iova); if (IS_ERR(memptrs)) { -- 2.36.1

1 0

[PATCH] iosys-map: Add word-sized reads
by Lucas De Marchi 13 Jun '22

13 Jun '22

Instead of always falling back to memcpy_fromio() for any size, prefer using read{b,w,l}(). When reading struct members it's common to read individual integer variables individually. Going through memcpy_fromio() for each of them poses a high penalty. Employ a similar trick as __seqprop() by using _Generic() to generate only the specific call based on a type-compatible variable. For a pariticular i915 workload producing GPU context switches, __get_engine_usage_record() is particularly hot since the engine usage is read from device local memory with dgfx, possibly multiple times since it's racy. Test execution time for this test shows a ~12.5% improvement with DG2: Before: nrepeats = 1000; min = 7.63243e+06; max = 1.01817e+07; median = 9.52548e+06; var = 526149; After: nrepeats = 1000; min = 7.03402e+06; max = 8.8832e+06; median = 8.33955e+06; var = 333113; Other things attempted that didn't prove very useful: 1) Change the _Generic() on x86 to just dereference the memory address 2) Change __get_engine_usage_record() to do just 1 read per loop, comparing with the previous value read 3) Change __get_engine_usage_record() to access the fields directly as it was before the conversion to iosys-map (3) did gave a small improvement (~3%), but doesn't seem to scale well to other similar cases in the driver. Additional test by Chris Wilson using gem_create from igt with some changes to track object creation time. This happens to accidentaly stress this code path: Pre iosys_map conversion of engine busyness: lmem0: Creating 262144 4KiB objects took 59274.2ms Unpatched: lmem0: Creating 262144 4KiB objects took 108830.2ms With readl (this patch): lmem0: Creating 262144 4KiB objects took 61348.6ms s/readl/READ_ONCE/ lmem0: Creating 262144 4KiB objects took 61333.2ms So we do take a little bit more time than before the conversion, but that is due to other factors: bringing the READ_ONCE back would be as good as just doing this conversion. Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- If this is acceptable we should probably add the write counterpart, too. Sending here only the read for now since this fixes the issue we are seeing and to gather feedback. include/linux/iosys-map.h | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h index e69a002d5aa4..4ae3e459419e 100644 --- a/include/linux/iosys-map.h +++ b/include/linux/iosys-map.h @@ -333,6 +333,20 @@ static inline void iosys_map_memset(struct iosys_map *dst, size_t offset, memset(dst->vaddr + offset, value, len); } +#ifdef CONFIG_64BIT +#define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) \ + u64: val_ = readq(vaddr_iomem_), +#else +#define __iosys_map_u64_case(val_, vaddr_iomem_) +#endif + +#define __iosys_map_rd_io(val__, vaddr_iomem__, type__) _Generic(val__, \ + u8: val__ = readb(vaddr_iomem__), \ + u16: val__ = readw(vaddr_iomem__), \ + u32: val__ = readl(vaddr_iomem__), \ + __iosys_map_rd_io_u64_case(val__, vaddr_iomem__) \ + default: memcpy_fromio(&(val__), vaddr_iomem__, sizeof(val__))) + /** * iosys_map_rd - Read a C-type value from the iosys_map * @@ -346,10 +360,14 @@ static inline void iosys_map_memset(struct iosys_map *dst, size_t offset, * Returns: * The value read from the mapping. */ -#define iosys_map_rd(map__, offset__, type__) ({ \ - type__ val; \ - iosys_map_memcpy_from(&val, map__, offset__, sizeof(val)); \ - val; \ +#define iosys_map_rd(map__, offset__, type__) ({ \ + type__ val; \ + if ((map__)->is_iomem) { \ + __iosys_map_rd_io(val, (map__)->vaddr_iomem + offset__, type__);\ + } else { \ + memcpy(&val, (map__)->vaddr + offset__, sizeof(val)); \ + } \ + val; \ }) /** -- 2.36.1

4 6

[PATCH] drm/msm/adreno: Defer enabling runpm until hw_init()
by Rob Clark 13 Jun '22

13 Jun '22

From: Rob Clark <robdclark(a)chromium.org> To avoid preventing the display from coming up before the rootfs is mounted, without resorting to packing fw in the initrd, the GPU has this limbo state where the device is probed, but we aren't ready to start sending commands to it. This is particularly problematic for a6xx, since the GMU (which requires fw to be loaded) is the one that is controlling the power/clk/icc votes. So defer enabling runpm until we are ready to call gpu->hw_init(), as that is a point where we know we have all the needed fw and are ready to start sending commands to the coproc's. Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++++++ drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 - 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c index 8706bcdd1472..7cef8ae73c71 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_device.c +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c @@ -415,6 +415,12 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev) if (ret) return NULL; + /* + * Now that we have firmware loaded, and are ready to begin + * booting the gpu, go ahead and enable runpm: + */ + pm_runtime_enable(&pdev->dev); + /* Make sure pm runtime is active and reset any previous errors */ pm_runtime_set_active(&pdev->dev); diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c index 4e665c806a14..e1aef4875e2f 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c @@ -1042,7 +1042,6 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev, pm_runtime_set_autosuspend_delay(dev, adreno_gpu->info->inactive_period); pm_runtime_use_autosuspend(dev); - pm_runtime_enable(dev); return msm_gpu_init(drm, pdev, &adreno_gpu->base, &funcs->base, gpu_name, &adreno_gpu_config); -- 2.36.1

1 0

Re: [PATCH v6 3/6] drm: Add driver for Solomon SSD130x OLED displays
by Dominik Kierner 13 Jun '22

13 Jun '22

Hello Javier, On 5/25/2022 21:46, Javier Martinez Canillas wrote: > > Now that Your driver is quite a bit maturer than mine, I will happily > > provide You with the source of my draft, so that any useful bits can > > be incorporated in Your driver. > > I know that links are a bit frowned upon, but I'd rather avoid > > cluttering the thread with my draft code, which is unfinished and > > incompatible with the code in this thread. > > > > https://github.com/dh-electronics/panel-solomon-ssd130x-draft > > https://github.com/dh-electronics/panel-solomon-ssd130x-draft/tree/drm-ssd1… > > > > Thanks, I looked at the code briefly and think that there are things there that we > could use. I.e the 3-wire SPI support that's in panel-solomon-ssd130x-spi-3wire.c. When writing my driver code, I wasn't even considering using regmaps, like You did in Your I2C-Code. If that's applicable for 3-wire-SPI, it would likely be the better, more generic option. Your SPI-code reuses these parts to some extent. For that case, ssd130x_spi_regmap_config.reg_bits would need be changed to 1, as the "register address" has a length of 1 bit and we are sending 9 bits over the line and not 16. Since we still have 2 bytes of host memory, it should still be compatible with the 4-wire write, right? Or would 3-wire SPI require a second regmap? > > Splitting in VCC/VBAT and VDD and enforcing their presence is of > > course compatibility breaking. > > > > https://github.com/dh-electronics/panel-solomon-ssd130x-draft/blob/drm > > -ssd130x/drivers/gpu/drm/panel/panel-solomon-ssd130x.h#L85 > > https://github.com/dh-electronics/panel-solomon-ssd130x-draft/blob/drm > > -ssd130x/drivers/gpu/drm/panel/panel-solomon-ssd130x.c#L80 > > > > It is a break in the DT binding indeed but on the other hand it seems that the > regulator story is lacking in the current solomon,ssd1307fb.yaml anyways. > > That is, the binding schema only mentions a "vbat-supply" but the DRM driver is not > looking for that but instead for "vcc-supply" (I think that was changed due some > feedback I got on some revisions, but didn't update the DT binding). The fbdev > drivers/video/fbdev/ssd1307fb.c driver does lookup "vbat-supply" but all the DTS and > DTS overlays I find don't set one. > > Also the "vbat-supply" is not a required property in the current binding. One thing to > notice is that regulator_get() and regulator_get_optional() semantics are confusing > (at least for me). Since doesn't mean whether the regulator must be present or not > but rather if a dummy regulator must be provided if a supply is not found. I always understood regulator_get_optional() as a way of not having to rely on a dummy, when a regulator is not present, but please correct me, if I am wrong on this. The dummies would only be necessary for the mandatory supplies VCC and VDD. You mean this part of the documentation of regulator_get_optional(), correct?: > * This is intended for use by consumers for devices which can have > * some supplies unconnected in normal use, such as some MMC devices. > * It can allow the regulator core to provide stub supplies for other > * supplies requested using normal regulator_get() calls without > * disrupting the operation of drivers that can handle absent > * supplies. > In other words, I don't think that any of these supplies should be made required in > the DT binding but just leave the current "vbat-supply" and add properties for "vcc- > supply" and explain the relationship between these and just make the logic in the > driver to override struct ssd130x_deviceinfo .need_chargepump if are present. My idea was to require these supplies, so that the binding correctly reflects the manuals. Driving supply VCC and logic supply VDD, are present throughout the SSD130x family. Only the VBAT supply is an optional SSD1306 specific and would therefore use an optional regulator. The only other device specific supply is the SSD1305's VDDIO supply, which is mandatory and seems to be commonly connected to VDD, so including that is likely unnecessary. I Just wanted to mention it for completeness. If the device isn't controllable by Linux, a dummy would be connected instead, just like the dummy regulator documentation states: > * This is useful for systems with mixed controllable and > * non-controllable regulators, as well as for allowing testing on > * systems with no controllable regulators. Which would be the case, with the SSD130x controllers. Sometimes they are connected to external, non-controllable regulators. I figured that the kernel developers might be more open to a compatibility breaking change, under the circumstance, that this is more or less a new driver for DRM, that it provides atomic charge pump configuration for the SSD1306 and that some (embedded) user space software might need to be rewritten to accommodate for the transition from fbdev to DRM anyway. But I might be wrong on this. > > # Static or Dynamic Configuration for SPI-Modes 3-Wire and 4-Wire > > > > For the SPI-protocol drivers I see two possible approaches: > > * Dynamic configuration by determining the presence/absence of the > > D/C-GPIO and assigning the functions accordingly. > > This way a single driver file for both SPI modes could be sufficient. > > * Static configuration by using the device-tree names > > (ssd130x-spi-3wire/-4wire) to differentiate between the SPI protocol > > drivers. > > This would obviously necessitate two drivers files. > > > > Which one do you think would be the best approach for this? > > > > I think that prefer the first approach. As mentioned the staging driver has a > "buswidth" property but as you said we could just use the "dc-gpios" presence as > indication on whether is a 4-wire or 3-wire SPI mode. You are correct, I do prefer the first approach. It would cut the additional file and code required for the second approach and eliminate an additional device tree name, that would have been necessary otherwise. > > What is Your opinion on using drm_panel for Your driver? > > > > I can't remember exactly why I decided to stop using drm_panel, but I think that > was because struct drm_panel doesn't have a DRM device and so couldn't use any of > the helper functions that needed one? I likely hit the same roadblock. I would say, this approach should be revisited, when appropriate helpers for this approach exist, as it would further clean up and generify the ssd130x device configuration. -- Best regards Dominik Kierner Research & Development DH electronics

3 3

[PATCH] Revert "fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled"
by Javier Martinez Canillas 13 Jun '22

13 Jun '22

This reverts commit fa0e256450f27a7d85f65c63f05e6897954a1d53. The kernel test robot reported that attempting to build the vesafb driver fails on some architectures, because these don't define a `struct screen_info`. This leads to linking errors, for example on parisc with allyesconfig: hppa-linux-ld: drivers/video/fbdev/vesafb.o: in function `vesafb_probe': >> (.text+0x738): undefined reference to `screen_info' >> hppa-linux-ld: (.text+0x73c): undefined reference to `screen_info' hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init': >> (.init.text+0x28): undefined reference to `screen_info' >> hppa-linux-ld: (.init.text+0x30): undefined reference to `screen_info' hppa-linux-ld: (.init.text+0x78): undefined reference to `screen_info' The goal of commit fa0e256450f2 ("fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled") was to have more build coverage for the driver but it wrongly assumed that all architectures would define a screen_info. Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> --- drivers/video/fbdev/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index bd849013f16f..f2a6b81e45c4 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -616,7 +616,7 @@ config FB_UVESA config FB_VESA bool "VESA VGA graphics support" - depends on (FB = y) && (X86 || COMPILE_TEST) + depends on (FB = y) && X86 select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 2.36.1

2 2

[PATCH v2 0/3] KUnit tests for drm_format_helper
by José Expósito 13 Jun '22

13 Jun '22

Hello everyone, Here is the v2 of the series, including the documentation, previously sent as a standalone patch [1], and changes suggested during review. Thanks a lot, José Expósito RFC -> v1: https://lore.kernel.org/dri-devel/20220530102017.471865-1-jose.exposito89@g… - Add .kunitconfig (Maxime Ripard) - Fix memory leak (Daniel Latypov) - Make config option generic (Javier Martinez Canillas): DRM_FORMAR_HELPER_TEST -> DRM_KUNIT_TEST - Remove DISABLE_STRUCTLEAK_PLUGIN (Daniel Latypov) v1 -> v2: https://lore.kernel.org/dri-devel/20220606095516.938934-1-jose.exposito89@g… Thomas Zimmermann: - Add DRM_RECT_INIT() macro - Move tests to drivers/gpu/drm/kunit - Improve test documentation [1] https://lore.kernel.org/dri-devel/20220606180940.43371-1-jose.exposito89@gm… José Expósito (3): drm/rect: Add DRM_RECT_INIT() macro drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332() drm/doc: Add KUnit documentation Documentation/gpu/drm-internals.rst | 32 ++++ drivers/gpu/drm/Kconfig | 16 ++ drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/kunit/.kunitconfig | 3 + drivers/gpu/drm/kunit/Makefile | 3 + .../gpu/drm/kunit/drm_format_helper_test.c | 169 ++++++++++++++++++ include/drm/drm_rect.h | 12 ++ 7 files changed, 236 insertions(+) create mode 100644 drivers/gpu/drm/kunit/.kunitconfig create mode 100644 drivers/gpu/drm/kunit/Makefile create mode 100644 drivers/gpu/drm/kunit/drm_format_helper_test.c -- 2.25.1

2 5

[PATCH v6 0/6] Raspberry PI 4 V3D enablement
by Peter Robinson 13 Jun '22

13 Jun '22

This is a follow up from my v4 patchset. The power management pieces have been split out to a separate independent set of patches by Stefan [1]. This version 5 of the DRM patches are independent and given the V3D driver has been upstream for some time the two patches to enable it in defconfigs can be taken at anytime independent of the enablement for the Raspberry Pi 4. I've tested this using mesa 22.0.x and Wayland/Gnome on Fedora 36, it's more or less stable with basic testing. Changes since v5: - Update the DT compatible to match the others that were updated - Adjust the Kconfig help text - Add review tags Changes since v4: - Fixes for device tree and bindings - Split out the power management changes into an independent set - Rebase to 5.18 - Individual changes in patches [1] https://www.spinics.net/lists/arm-kernel/msg980342.html Nicolas Saenz Julienne (1): arm64: config: Enable DRM_V3D Peter Robinson (5): dt-bindings: gpu: v3d: Add BCM2711's compatible drm/v3d: Get rid of pm code drm/v3d: Add support for bcm2711 ARM: dts: bcm2711: Enable V3D ARM: configs: Enable DRM_V3D .../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 + arch/arm/boot/dts/bcm2711-rpi.dtsi | 4 ++++ arch/arm/boot/dts/bcm2711.dtsi | 11 +++++++++++ arch/arm/configs/bcm2835_defconfig | 1 + arch/arm/configs/multi_v7_defconfig | 1 + arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/v3d/Kconfig | 5 +++-- drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +----------------- drivers/gpu/drm/v3d/v3d_drv.c | 12 +----------- drivers/gpu/drm/v3d/v3d_gem.c | 12 +----------- 10 files changed, 25 insertions(+), 41 deletions(-) -- 2.36.1

5 20

[PATCH] ASoC: hdmi-codec: Update to modern DAI terminology
by Mark Brown 13 Jun '22

13 Jun '22

As part of retiring the old defines used to specify DAI formats update the hdmi_codec driver to use the modern names, including the variables in the struct hdmi_codec_daifmt exported to the DRM drivers. In updating this I did note that the only use of this information in DRM drivers is to reject clock provider settings, thinking about what this hardware is doing I rather suspect that there might not be any hardware out there which needs the configuration so it may be worth considering just having hdmi-codec support only clock consumer. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- drivers/gpu/drm/bridge/sii902x.c | 5 +++-- .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 8 ++++---- drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++--- drivers/gpu/drm/sti/sti_hdmi.c | 8 ++++---- include/sound/hdmi-codec.h | 4 ++-- sound/soc/codecs/hdmi-codec.c | 18 +++++++++--------- 7 files changed, 26 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c index 65549fbfdc87..be9736f67542 100644 --- a/drivers/gpu/drm/bridge/sii902x.c +++ b/drivers/gpu/drm/bridge/sii902x.c @@ -549,8 +549,9 @@ static int sii902x_audio_hw_params(struct device *dev, void *data, unsigned long mclk_rate; int i, ret; - if (daifmt->bit_clk_master || daifmt->frame_clk_master) { - dev_dbg(dev, "%s: I2S master mode not supported\n", __func__); + if (daifmt->bit_clk_provider || daifmt->frame_clk_provider) { + dev_dbg(dev, "%s: I2S clock provider mode not supported\n", + __func__); return -EINVAL; } diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index f50b47ac11a8..a2f0860b20bb 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c @@ -45,7 +45,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data, u8 inputclkfs = 0; /* it cares I2S only */ - if (fmt->bit_clk_master | fmt->frame_clk_master) { + if (fmt->bit_clk_provider | fmt->frame_clk_provider) { dev_err(dev, "unsupported clock settings\n"); return -EINVAL; } diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 7655142a4651..10b0036f8a2e 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -1594,12 +1594,12 @@ static int hdmi_audio_hw_params(struct device *dev, void *data, struct hdmi_context *hdata = dev_get_drvdata(dev); if (daifmt->fmt != HDMI_I2S || daifmt->bit_clk_inv || - daifmt->frame_clk_inv || daifmt->bit_clk_master || - daifmt->frame_clk_master) { + daifmt->frame_clk_inv || daifmt->bit_clk_provider || + daifmt->frame_clk_provider) { dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__, daifmt->bit_clk_inv, daifmt->frame_clk_inv, - daifmt->bit_clk_master, - daifmt->frame_clk_master); + daifmt->bit_clk_provider, + daifmt->frame_clk_provider); return -EINVAL; } diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index b7ec6c374fbd..c4fadaecbb2d 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -1095,11 +1095,11 @@ static int tda998x_audio_hw_params(struct device *dev, void *data, if (!spdif && (daifmt->bit_clk_inv || daifmt->frame_clk_inv || - daifmt->bit_clk_master || daifmt->frame_clk_master)) { + daifmt->bit_clk_provider || daifmt->frame_clk_provider)) { dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__, daifmt->bit_clk_inv, daifmt->frame_clk_inv, - daifmt->bit_clk_master, - daifmt->frame_clk_master); + daifmt->bit_clk_provider, + daifmt->frame_clk_provider); return -EINVAL; } diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index b3fbee7eac11..622d0dfe7bb9 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -1175,12 +1175,12 @@ static int hdmi_audio_hw_params(struct device *dev, DRM_DEBUG_DRIVER("\n"); if ((daifmt->fmt != HDMI_I2S) || daifmt->bit_clk_inv || - daifmt->frame_clk_inv || daifmt->bit_clk_master || - daifmt->frame_clk_master) { + daifmt->frame_clk_inv || daifmt->bit_clk_providre || + daifmt->frame_clk_provider) { dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__, daifmt->bit_clk_inv, daifmt->frame_clk_inv, - daifmt->bit_clk_master, - daifmt->frame_clk_master); + daifmt->bit_clk_provider, + daifmt->frame_clk_provider); return -EINVAL; } diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h index 4fc733c8c570..48ad33aba393 100644 --- a/include/sound/hdmi-codec.h +++ b/include/sound/hdmi-codec.h @@ -32,8 +32,8 @@ struct hdmi_codec_daifmt { } fmt; unsigned int bit_clk_inv:1; unsigned int frame_clk_inv:1; - unsigned int bit_clk_master:1; - unsigned int frame_clk_master:1; + unsigned int bit_clk_provider:1; + unsigned int frame_clk_provider:1; /* bit_fmt could be standard PCM format or * IEC958 encoded format. ALSA IEC958 plugin will pass * IEC958_SUBFRAME format to the underneath driver. diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c index b773466619b2..7d1e351f863a 100644 --- a/sound/soc/codecs/hdmi-codec.c +++ b/sound/soc/codecs/hdmi-codec.c @@ -606,18 +606,18 @@ static int hdmi_codec_i2s_set_fmt(struct snd_soc_dai *dai, /* Reset daifmt */ memset(cf, 0, sizeof(*cf)); - switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { - case SND_SOC_DAIFMT_CBM_CFM: - cf->bit_clk_master = 1; - cf->frame_clk_master = 1; + switch (fmt & SND_SOC_DAIFMT_CLOCK_PROVIDER_MASK) { + case SND_SOC_DAIFMT_CBP_CFP: + cf->bit_clk_provider = 1; + cf->frame_clk_provider = 1; break; - case SND_SOC_DAIFMT_CBS_CFM: - cf->frame_clk_master = 1; + case SND_SOC_DAIFMT_CBC_CFP: + cf->frame_clk_provider = 1; break; - case SND_SOC_DAIFMT_CBM_CFS: - cf->bit_clk_master = 1; + case SND_SOC_DAIFMT_CBP_CFC: + cf->bit_clk_provider = 1; break; - case SND_SOC_DAIFMT_CBS_CFS: + case SND_SOC_DAIFMT_CBC_CFC: break; default: return -EINVAL; -- 2.30.2

1 1

[PATCH] drm/msm: Fix convert to drm_of_get_data_lanes_count
by Marek Vasut 13 Jun '22

13 Jun '22

Add missing header file into dsi_host.c and encode data-lanes string directly into the warning message in the driver to avoid build issues detected by lkp. Fixes: 185443efa26a ("drm/msm: Convert to drm_of_get_data_lanes_count") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Abhinav Kumar <quic_abhinavk(a)quicinc.com> Cc: Andrzej Hajda <andrzej.hajda(a)intel.com> Cc: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Maxime Ripard <maxime(a)cerno.tech> Cc: Rob Clark <robdclark(a)gmail.com> Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Sean Paul <sean(a)poorly.run> To: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/msm/dp/dp_parser.c | 4 ++-- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c index 346556c5706d7..57ae14a0e1814 100644 --- a/drivers/gpu/drm/msm/dp/dp_parser.c +++ b/drivers/gpu/drm/msm/dp/dp_parser.c @@ -106,8 +106,8 @@ static int dp_parser_misc(struct dp_parser *parser) len = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES); if (len < 0) { - DRM_WARN("Invalid property %s, default max DP lanes = %d\n", - data_lane_property, DP_MAX_NUM_DP_LANES); + DRM_WARN("Invalid property \"data-lanes\", default max DP lanes = %d\n", + DP_MAX_NUM_DP_LANES); len = DP_MAX_NUM_DP_LANES; } diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index db5871b9c5d88..7e21916d1511a 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -21,6 +21,8 @@ #include <video/mipi_display.h> +#include <drm/drm_of.h> + #include "dsi.h" #include "dsi.xml.h" #include "sfpb.xml.h" -- 2.35.1

3 2

← Newer
1
...
38
39
40
41
42
43
44
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2022