Re: [PATCH v2 15/91] clk: bcm: rpi: Pass the clocks data to the firmware function
Quoting Maxime Ripard (2020-04-24 08:33:56) > The raspberry_clock_property only takes the clock ID as an argument, but > now that we have a clock data structure it makes more sense to just pass > that structure instead. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-...@vger.kernel.org > Acked-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/91] clk: bcm: rpi: Make sure pllb_arm is removed
Quoting Maxime Ripard (2020-04-24 08:33:50) > The pllb_arm clock was created at probe time, but was never removed if > something went wrong later in probe, or if the driver was ever removed from > the system. > > Now that we are using clk_hw_register, we can just use its managed variant clk_hw_register() > to take care of that for us. > > Cc: Michael Turquette > Cc: linux-...@vger.kernel.org > Acked-by: Nicolas Saenz Julienne > Reviewed-by: Stephen Boyd > Signed-off-by: Maxime Ripard > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/91] clk: bcm: rpi: Remove global pllb_arm clock pointer
Quoting Maxime Ripard (2020-04-24 08:33:49) > The pllb_arm clk_hw pointer in the raspberry_clk structure isn't used > anywhere but in the raspberrypi_register_pllb_arm. > > Let's remove it, this will make our lives easier in future patches. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-...@vger.kernel.org > Acked-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/91] clk: bcm: rpi: Statically init clk_init_data
Quoting Maxime Ripard (2020-04-24 08:33:47) > Instead of declaring the clk_init_data and then calling memset on it, just > initialise properly. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-...@vger.kernel.org > Acked-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: device hot-unplug for userspace
On Tue, 26 May 2020 10:30:20 -0400 Andrey Grodzovsky wrote: > On 5/19/20 6:06 AM, Pekka Paalanen wrote: > > From: Pekka Paalanen > > > > Set up the expectations on how hot-unplugging a DRM device should look like > > to > > userspace. > > > > Written by Daniel Vetter's request and largely based on his comments in IRC > > and > > from > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&data=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783&sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3D&reserved=0 > > . > > > > Signed-off-by: Pekka Paalanen > > Cc: Daniel Vetter > > Cc: Andrey Grodzovsky > > Cc: Dave Airlie > > Cc: Sean Paul > > > > --- > > > > Disclaimer: I am a userspace developer writing for other userspace > > developers. > > I took some liberties in defining what should happen without knowing what is > > actually possible or what existing drivers already implement. > > --- > > Documentation/gpu/drm-uapi.rst | 75 ++ > > 1 file changed, 75 insertions(+) > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > > index 56fec6ed1ad8..80db4abd2cbd 100644 > > --- a/Documentation/gpu/drm-uapi.rst > > +++ b/Documentation/gpu/drm-uapi.rst > > @@ -1,3 +1,5 @@ > > +.. Copyright 2020 DisplayLink (UK) Ltd. > > + > > === > > Userland interfaces > > === > > @@ -162,6 +164,79 @@ other hand, a driver requires shared state between > > clients which is > > visible to user-space and accessible beyond open-file boundaries, they > > cannot support render nodes. > > > > +Device Hot-Unplug > > += > > + > > +.. note:: > > + The following is the plan. Implementation is not there yet > > + (2020 May 13). > > + > > +Graphics devices (display and/or render) may be connected via USB (e.g. > > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end > > +user is able to hot-unplug this kind of devices while they are being > > +used, and expects that the very least the machine does not crash. Any > > +damage from hot-unplugging a DRM device needs to be limited as much as > > +possible and userspace must be given the chance to handle it if it wants > > +to. Ideally, unplugging a DRM device still lets a desktop to continue > > +running, but that is going to need explicit support throughout the whole > > +graphics stack: from kernel and userspace drivers, through display > > +servers, via window system protocols, and in applications and libraries. > > + > > +Other scenarios that should lead to the same are: unrecoverable GPU > > +crash, PCI device disappearing off the bus, or forced unbind of a driver > > +from the physical device. > > + > > +In other words, from userspace perspective everything needs to keep on > > +working more or less, until userspace stops using the disappeared DRM > > +device and closes it completely. Userspace will learn of the device > > +disappearance from the device removed uevent or in some cases specific > > +ioctls returning EIO. > > + > > +This goal raises at least the following requirements for the kernel and > > +drivers: > > + > > +- The kernel must not hang, crash or oops, no matter what userspace was > > + in the middle of doing when the device disappeared. > > + > > +- All GPU jobs that can no longer run must have their fences > > + force-signalled to avoid inflicting hangs to userspace. > > + > > +- KMS connectors must change their status to disconnected. > > + > > +- Legacy modesets and pageflips fake success. > > + > > +- Atomic commits, both real and TEST_ONLY, fake success. > > + > > +- Pending non-blocking KMS operations deliver the DRM events userspace > > + is expecting. > > + > > +- If underlying memory disappears, the mmaps are replaced with harmless > > + zero pages where access does not raise SIGBUS. Reads return zeros, > > + writes are ignored. > > > Regarding this paragraph - what about exiting mappings ? In the first > patchset we would actively invalidate all the existing CPU mappings to > device memory and i think we still should do it otherwise we will see > random crashes in applications as was before. I guess it's because TLBs > and page tables are not updated to reflect the fact the device is gone. Hi, I was talking about existing mappings. What I forgot to specify is how new mmap() calls after the device disappearance should work (the end result should be the same still, not failure). I'll clarify this in the next revision. Thanks, pq > > + > > +- dmabuf which point to memory that has disappeared are rewritten to > > + point to harmless zero pages, similar to mmaps. Imports still succeed > > + both ways: an existing device importing a dmabuf pointing to > > + disappeared memory, and a disappeared device importing any dma
Re: [PATCH v5 5/8] clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate, fix duplicated ltdc clock register to 'clk_core' case ltdc's clock turn off by clk_disable_unused()
Quoting dillon min (2020-05-26 20:30:47) > On Wed, May 27, 2020 at 9:44 AM Stephen Boyd wrote: > > > > Quoting dillon.min...@gmail.com (2020-05-24 20:45:45) > > > From: dillon min > > > > > > > > > Signed-off-by: dillon min > > > > Any Fixes tag? > ok, will add --fixup in git commit next time, this patch fix two bugs, > i should make two commit, each one has a > fixes tag, right? > first point to '517633e clk: stm32f4: Add post divisor for I2S & SAI PLLs' > second point to 'daf2d11 clk: stm32f4: Add lcd-tft clock' Sounds good. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Hi Maxime, On Tue, May 26, 2020 at 6:20 PM Maxime Ripard wrote: > I gave it a try with U-Boot with my latest work and couldn't reproduce it, so > it > seems that I fixed it along the way Is your latest work available in a git branch anywhere that we could test directly? Thanks Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/8] clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate, fix duplicated ltdc clock register to 'clk_core' case ltdc's clock turn off by clk_disable_unused()
Quoting dillon.min...@gmail.com (2020-05-24 20:45:45) > From: dillon min > > ltdc set clock rate crashed >'post_div_data[]''s pll_num is PLL_I2S, PLL_SAI (number is 1,2). but, Please write "post_div_data[]'s" if it is possessive. "But" doesn't start a sentence. This is one sentence, not two. > as pll_num is offset of 'clks[]' input to clk_register_pll_div(), which > is FCLK, CLK_LSI, defined in 'include/dt-bindings/clock/stm32fx-clock.h' > so, this is a null object at the register time. > then, in ltdc's clock is_enabled(), enable(), will call to_clk_gate(). > will return a null object, cause kernel crashed. > need change pll_num to PLL_VCO_I2S, PLL_VCO_SAI for 'post_div_data[]' > > duplicated ltdc clock >'stm32f429_gates[]' has a member 'ltdc' register to 'clk_core', but no > upper driver use it, ltdc driver use the lcd-tft defined in >'stm32f429_aux_clk[]'. after system startup, as stm32f429_gates[]'s ltdc > enable_count is zero, so turn off by clk_disable_unused() I sort of follow this. Is this another patch? Seems like two things are going on here. > > Changes since V3: > 1 drop last wrong changes about 'CLK_IGNORE_UNUSED' patch > 2 fix PLL_SAI mismatch with PLL_VCO_SAI This change log goes under the --- below. > > Signed-off-by: dillon min Any Fixes tag? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/21] drm/malidp: Use GEM CMA object functions
On Fri, May 22, 2020 at 03:52:36PM +0200, Thomas Zimmermann wrote:
> The malidp driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
> these defaults and .dumb_create in struct drm_driver. All remaining
> operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index def8c9ffafcaf..92e0bca6aa2f4 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -563,16 +563,7 @@ static void malidp_debugfs_init(struct drm_minor *minor)
>
> static struct drm_driver malidp_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .dumb_create = malidp_dumb_create,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> + __DRM_GEM_CMA_DRIVER_OPS(malidp_dumb_create),
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = malidp_debugfs_init,
> #endif
> --
> 2.26.2
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/21] drm/komeda: Use GEM CMA object functions
On Fri, May 22, 2020 at 03:52:35PM +0200, Thomas Zimmermann wrote:
> The komeda driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
> these defaults and .dumb_create in struct drm_driver. All remaining
> operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index 6b85d5f4caa85..bdfbcbc416260 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -61,16 +61,7 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void
> *data)
> static struct drm_driver komeda_kms_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .lastclose = drm_fb_helper_lastclose,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .dumb_create= komeda_gem_cma_dumb_create,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> + __DRM_GEM_CMA_DRIVER_OPS(komeda_gem_cma_dumb_create),
> .fops = &komeda_cma_fops,
> .name = "komeda",
> .desc = "Arm Komeda Display Processor driver",
> --
> 2.26.2
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/21] drm/arm: Use GEM CMA object functions
On Fri, May 22, 2020 at 03:52:28PM +0200, Thomas Zimmermann wrote:
> The arm driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Liviu Dudau
Thanks!
Liviu
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 194419f47c5e5..c83b81a3a582a 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -240,17 +240,7 @@ static struct drm_driver hdlcd_driver = {
> .irq_preinstall = hdlcd_irq_preinstall,
> .irq_postinstall = hdlcd_irq_postinstall,
> .irq_uninstall = hdlcd_irq_uninstall,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_print_info = drm_gem_cma_print_info,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .dumb_create = drm_gem_cma_dumb_create,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> + DRM_GEM_CMA_DRIVER_OPS,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = hdlcd_debugfs_init,
> #endif
> --
> 2.26.2
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Convert get_user_pages() --> pin_user_pages()
On 2020-05-26 14:00, Souptick Joarder wrote: This code was using get_user_pages(), in a "Case 2" scenario (DMA/RDMA), using the categorization from [1]. That means that it's time to convert the get_user_pages() + release_pages() calls to pin_user_pages() + unpin_user_pages() calls. There is some helpful background in [2]: basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: Souptick Joarder Cc: John Hubbard Hi, I'm compile tested this, but unable to run-time test, so any testing help is much appriciated. --- drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5d50c9e..e927de2 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -506,7 +506,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm) uint64_t userptr = gtt->userptr + pinned * PAGE_SIZE; struct page **pages = ttm->pages + pinned; - r = get_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0, + r = pin_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0, pages, NULL); if (r < 0) goto release_pages; @@ -535,7 +535,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm) kfree(ttm->sg); release_pages: - release_pages(ttm->pages, pinned); + unpin_user_pages(ttm->pages, pinned); return r; } @@ -562,7 +562,7 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt *ttm) set_page_dirty(page); Maybe we also need a preceding patch, to fix the above? It should be set_page_dirty_lock(), rather than set_page_dirty(), unless I'm overlooking something (which is very possible!). Either way, from a tunnel vision perspective of changing gup to pup, this looks good to me, so Acked-by: John Hubbard thanks, -- John Hubbard NVIDIA mark_page_accessed(page); - put_page(page); + unpin_user_page(page); } sg_free_table(ttm->sg); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/3] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
On Wed, May 13, 2020 at 02:59:02PM -0700, Douglas Anderson wrote: > The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware > HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP > because of excessive debouncing in hardware. Specifically there is no > way to disable the debouncing and for eDP debouncing hurts you because > HPD is just used for knowing when the panel is ready, not for > detecting physical plug events. > > Currently the driver in Linux just assumes that nobody has HPD hooked > up. It relies on folks setting the "no-hpd" property in the panel > node to specify that HPD isn't hooked up and then the panel driver > using this to add some worst case delays when turning on the panel. > > Apparently it's also useful to specify "no-hpd" in the bridge node so > that the bridge driver can make sure it's doing the right thing > without peeking into the panel [1]. This would be used if anyone ever > found it useful to implement support for the HW HPD pin on the bridge. > Let's add this property to the bindings. > > NOTES: > - This is somewhat of a backward-incompatible change. All current > known users of ti-sn65dsi86 didn't have "no-hpd" specified in the > bridge node yet none of them had HPD hooked up. This worked because > the current Linux driver just assumed that HPD was never hooked up. > We could make it less incompatible by saying that for this bridge > it's assumed HPD isn't hooked up _unless_ a property is defined, but > "no-hpd" is much more standard and it's unlikely to matter unless > someone quickly goes and implements HPD in the driver. > - It is sensible to specify "no-hpd" at the bridge chip level and > specify "hpd-gpios" at the panel level. That would mean HPD is > hooked up to some other GPIO in the system, just not the hardware > HPD pin on the bridge chip. I would say 'no-hpd' belongs wherever HPD is broken. So it may still make sense in the panel. (Otherwise, it needs to be removed from panel-common.yaml and some panel bindings, right?) > [1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com > > Signed-off-by: Douglas Anderson > Reviewed-by: Stephen Boyd > Reviewed-by: Linus Walleij > Reviewed-by: Laurent Pinchart > --- In any case, Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/3] dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml
On Wed, 13 May 2020 14:59:01 -0700, Douglas Anderson wrote: > This moves the bindings over, based a lot on toshiba,tc358768.yaml. > Unless there's someone known to be better, I've set the maintainer in > the yaml as the first person to submit bindings. > > Signed-off-by: Douglas Anderson > Reviewed-by: Stephen Boyd > --- > I removed Stephen's review tag on v5 since I squashed in a bunch of > other stuff. > > Changes in v6: None > Changes in v5: > - Squash > https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/ > > Changes in v4: None > Changes in v3: None > Changes in v2: > - specification => specifier. > - power up => power. > - Added back missing suspend-gpios. > - data-lanes and lane-polarities are are the right place now. > - endpoints don't need to be patternProperties. > - Specified more details for data-lanes and lane-polarities. > - Added old example back in, fixing bugs in it. > - Example i2c bus is just called "i2c", not "i2c1" now. > > .../bindings/display/bridge/ti,sn65dsi86.txt | 87 -- > .../bindings/display/bridge/ti,sn65dsi86.yaml | 285 ++ > 2 files changed, 285 insertions(+), 87 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.102
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
libdrm 2.4.102, lots of FreeBSD and modetest stuff.
Boram Park (1):
drm mode : fix memory leak when freeing drmModePropertyPtr
Dave Airlie (1):
Bump version to 2.4.102
Emil Velikov (17):
tests: install drmdevice
modetest: simplify "dump all" logic
modetest: remove cursor/page_flipping_supported stubs
modetest: move basic args check before open()
modetest: set atomic cap, _only_ when needed
modetest: add and use bo_fb_create() helper
modetest: remove drmMode{,Plane}Res
modetest: close the device on exit
modetest: introduce and use get_crtc_by_id() and get_crtc_mask()
modetest: get the crtc_id from the pipe_arg
modetest: unify {,atomic_}set_mode()
modetest: move pipe_resolve_connectors() further up
modetest: push pipe_resolve_connectors() to set_mode
modetest: factor out atomic pageflip test
modetest: don't error out of final AtomicCommit
modetest: reorder atomic path alike the non-atomic
modetest: Add a new "-r" option to set a default mode
Emmanuel Vadot (15):
libdrm: drmNodeIsDRM: Add FreeBSD variant
xf86drm: Remove ifdef for FreeBSD and DRM_MAJOR
libdrm: drmGetMinorType: Add FreeBSD version
libdrm: drmGetDeviceNameFromFd: Add FreeBSD variant
libdrm: drmGetMinorNameForFD: Add FreeBSD variant
libdrm: Default to PCI for FreeBSD
libdrm: drmGetDeviceNameFromFd2: Add FreeBSD variant
libdrm: drmCheckModesettingSupported: Fix for FreeBSD
libdrm: drmCheckModesettingSupported: fix for FreeBSD
libdrm: Add get_sysctl_pci_bus_info for FreeBSD
libdrm: get_pci_path is Linux only so add an ifdef
libdrm: Implement drmParsePciDeviceInfo for FreeBSD
tests/nouveau/threaded: adapt ioctl signature for FreeBSD
libdrm: drmGetMinorNameFromFd: Fix FreeBSD variant
libdrm: drmGetDeviceNameFromFd: Always return /dev/dri/ node for FreeBSD
Eric Engestrom (1):
meson: don't detect on Linux
James Zhu (1):
tests/amdgpu/vcn: add dummy feedback message
Jose Maria Casanova Crespo (1):
meson: require valgrind 3.10.0 to enable it with freedreno
Karol Herbst (2):
nouveau: fix compile error with -DDEBUG on newer gcc
nouveau: sync up with nouveau_abi16.h and nouveau_drm.h
Leo Liu (1):
tests/amdgpu/vcn: add Renoir VCN2.0 decode support
Mikhail Golubev (1):
xf86drm: Check non-absolute path only for virtio based devices
Nicholas Bishop (2):
intel: properly escape sed pattern for tests
libdrm: intel: add DRM_RDWR flag in drm_intel_bo_gem_export_to_prime
Peter Seiderer (1):
tests/amdgpu: needs atomic_ops
Scott Anderson (1):
libdrm: Handle usb_interface devices for usb parsing
git tag: libdrm-2.4.102
https://dri.freedesktop.org/libdrm/libdrm-2.4.102.tar.xz
SHA256: 8bcbf9336c28e393d76c1f16d7e79e394a7fce8a2e929d52d3ad7ad8525ba05b
libdrm-2.4.102.tar.xz
SHA512:
386afd228efd809fe32776a6ff5d9dd95d1409a6a6a89b3806a3b42ed27e84f1e090f3b7834973f834d6b0d1342b7034447fe8690d072f85f03292d7795c3e0c
libdrm-2.4.102.tar.xz
PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.102.tar.xz.sig
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAl7NftoACgkQDHTzWXnE
hr6AJg//fv8RCU+k0biCDmrV3ji6Yb4jpYds48q2qq1sdZsqMSrzctR5lrLqf0Jo
gyqqsIWdHjqRmrhbtkuBLvFigLwlFtDun2jLpcE32aZsb+NCjFUUnnTsWFsl5VDg
cPUZVc7x+vrm+uJqE9EMv3wzbolfhHWGEEpvhUTTdIljPGTTMEznFPWKc05X+QQR
fWczQDQm6vifw4sF5zMrZWp3fOwBM3utDdhVLUsnRlo67YKeGjkm298FMwrxDfp8
+eRnUW8h6W4GuWva0fKSMdwv9SVwhzHQUGX4P5AXu2cyJoMw1VHMPn3iiFIfZJAp
ny8uGxnbBEvACr5hgSCy7DI1BUtBEwwmWuH3nPsNoQxPlhQRY0ZNKlBokps7QdQ+
aadZ5EbZmfWRSqm8OH7HpZa0zUmPaFwzPDX2b/JcFSt405Ka1yQ+6yjSGADaZ/z5
jQZJNbgNDBaWupgat82/YDI3A2d1NdudKTRrronyanenm7EdO10Aul9SMfZCwR56
0yKoTx+w9fZeqOrYyJMJ9q4Q8eZnpuePbY0nKZEKJOvGFE25xn4/XYqSFr5lYsYc
3pbVxZCyH6c+00dDkkziJbszgIq7RXpH7k8gS/v028LJ+VhmSXs9tZU8SQ8cU4he
J5PvR9IbUOjzQzxn0ymwi/468E8zkM/CWSYpsnL0ba/x7y3rBQ8=
=Pull
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #6 from Maurice Gale (mauricega...@gmail.com) --- (In reply to Ilia Mirkin from comment #5) > Does this continue to occur on recent kernels? e.g. 5.6 or 5.7-rc? > > It looks like aux port 9 is stuck somehow, not 100% sure that's something > that'd have been addressed, but DP stuff definitely got improvements. I will install install 5.7 to give that a shot, Thanks! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 Ilia Mirkin (imir...@alum.mit.edu) changed: What|Removed |Added CC||imir...@alum.mit.edu --- Comment #5 from Ilia Mirkin (imir...@alum.mit.edu) --- Does this continue to occur on recent kernels? e.g. 5.6 or 5.7-rc? It looks like aux port 9 is stuck somehow, not 100% sure that's something that'd have been addressed, but DP stuff definitely got improvements. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #4 from Maurice Gale (mauricega...@gmail.com) --- Created attachment 289317 --> https://bugzilla.kernel.org/attachment.cgi?id=289317&action=edit CPU Information -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #3 from Maurice Gale (mauricega...@gmail.com) --- Created attachment 289315 --> https://bugzilla.kernel.org/attachment.cgi?id=289315&action=edit Config File -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #2 from Maurice Gale (mauricega...@gmail.com) --- Created attachment 289313 --> https://bugzilla.kernel.org/attachment.cgi?id=289313&action=edit PCI Information -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #1 from Maurice Gale (mauricega...@gmail.com) --- Created attachment 289311 --> https://bugzilla.kernel.org/attachment.cgi?id=289311&action=edit Log file with drm debugging enabled -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] New: Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 Bug ID: 207901 Summary: Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot Product: Drivers Version: 2.5 Kernel Version: 5.3.0-51 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: mauricega...@gmail.com Regression: No Created attachment 289307 --> https://bugzilla.kernel.org/attachment.cgi?id=289307&action=edit Stack Trace that occurs when issue arises When four displays are connected to a gpu (NVIDIA p2000), 2 of the 4 displays will remain black. The monitors that remain black are the same exact ones on each boot. The connectors for the respective monitors are displayport->miniDisplayport, and displayport->hdmi. This issue was also identified during install time of Ubuntu. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915/mst: filter out the display mode exceed sink's capability
From: Lee Shawn C
So far, max dot clock rate for MST mode rely on physcial
bandwidth limitation. It would caused compatibility issue
if source display resolution exceed MST hub output ability.
For example, source DUT had DP 1.2 output capability.
And MST docking just support HDMI 1.4 spec. When a HDMI 2.0
monitor connected. Source would retrieve EDID from external
and get max resolution 4k@60fps. DP 1.2 can support 4K@60fps
because it did not surpass DP physical bandwidth limitation.
Do modeset to 4k@60fps, source output display data but MST
docking can't output HDMI properly due to this resolution
already over HDMI 1.4 spec.
Refer to commit ("drm/dp_mst: Use full_pbn
instead of available_pbn for bandwidth checks").
Source driver should refer to full_pbn to evaluate sink
output capability. And filter out the resolution surpass
sink output limitation.
v2: Using mgr->base.lock to protect full_pbn.
v3: Add ctx lock.
v4:
* s/intel_dp_mst_mode_clock_exceed_pbn_bandwidth/
intel_dp_mst_mode_clock_exceeds_pbn_bw/
* Use the new drm_connector_helper_funcs.mode_valid_ctx to properly pipe
down the drm_modeset_acquire_ctx that the probe helpers are using, so
we can safely grab &mgr->base.lock without deadlocking
Cc: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Cooper Chiou
Co-developed-by: Lyude Paul
Signed-off-by: Lee Shawn C
Tested-by: Lee Shawn C
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 39 ++---
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d18b406f2a7d2..cf052095ad785 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -610,15 +610,42 @@ static int intel_dp_mst_get_modes(struct drm_connector
*connector)
return intel_dp_mst_get_ddc_modes(connector);
}
+static int
+intel_dp_mst_mode_clock_exceeds_pbn_bw(struct drm_connector *connector,
+ struct drm_modeset_acquire_ctx *ctx,
+ int clock, int bpp)
+{
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_dp *intel_dp = intel_connector->mst_port;
+ struct drm_dp_mst_topology_mgr *mgr = &intel_dp->mst_mgr;
+ struct drm_dp_mst_port *port = (to_intel_connector(connector))->port;
+ int ret = MODE_OK;
+
+ if (!mgr)
+ return ret;
+
+ ret = drm_modeset_lock(&mgr->base.lock, ctx);
+ if (ret == -EDEADLK)
+ return ret;
+
+ if (port->full_pbn &&
+ drm_dp_calc_pbn_mode(clock, bpp, false) > port->full_pbn)
+ ret = MODE_CLOCK_HIGH;
+
+ return ret;
+}
+
static enum drm_mode_status
-intel_dp_mst_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,
+ struct drm_display_mode *mode,
+ struct drm_modeset_acquire_ctx *ctx)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
int max_rate, mode_rate, max_lanes, max_link_clock;
+ int ret;
if (drm_connector_is_unregistered(connector))
return MODE_ERROR;
@@ -632,7 +659,11 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(mode->clock, 18);
- /* TODO - validate mode against available PBN for link */
+ ret = intel_dp_mst_mode_clock_exceeds_pbn_bw(connector, ctx,
+mode->clock, 24);
+ if (ret != MODE_OK)
+ return ret;
+
if (mode->clock < 1)
return MODE_CLOCK_LOW;
@@ -671,7 +702,7 @@ intel_dp_mst_detect(struct drm_connector *connector,
static const struct drm_connector_helper_funcs
intel_dp_mst_connector_helper_funcs = {
.get_modes = intel_dp_mst_get_modes,
- .mode_valid = intel_dp_mst_mode_valid,
+ .mode_valid_ctx = intel_dp_mst_mode_valid_ctx,
.atomic_best_encoder = intel_mst_atomic_best_encoder,
.atomic_check = intel_dp_mst_atomic_check,
.detect_ctx = intel_dp_mst_detect,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/probe_helper, i915: Validate MST modes against PBN limits
Something we've been missing for a while with drivers that support MST is being able to prune modes that can't be set due to bandwidth limitations. So, let's go ahead and add that. This also adds a new hook that was needed, mode_valid_ctx, so that we can grab additional locks as needed when validating modes. Lee Shawn C (1): drm/i915/mst: filter out the display mode exceed sink's capability Lyude Paul (1): drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx drivers/gpu/drm/drm_crtc_helper_internal.h | 6 +- drivers/gpu/drm/drm_probe_helper.c | 65 ++--- drivers/gpu/drm/i915/display/intel_dp_mst.c | 39 +++-- include/drm/drm_modeset_helper_vtables.h| 41 + 4 files changed, 123 insertions(+), 28 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx
This is just an atomic version of mode_valid, which is intended to be
used for situations where a driver might need to check the atomic state
of objects other than the connector itself. One such example is with
MST, where the maximum possible bandwidth on a connector can change
dynamically irregardless of the display configuration.
Signed-off-by: Lyude Paul
Cc: Lee Shawn C
Tested-by: Lee Shawn C
---
drivers/gpu/drm/drm_crtc_helper_internal.h | 6 +-
drivers/gpu/drm/drm_probe_helper.c | 65 ++
include/drm/drm_modeset_helper_vtables.h | 41 ++
3 files changed, 88 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
b/drivers/gpu/drm/drm_crtc_helper_internal.h
index f0a66ef47e5ad..ca767cba6094d 100644
--- a/drivers/gpu/drm/drm_crtc_helper_internal.h
+++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
@@ -73,8 +73,10 @@ enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc
*crtc,
const struct drm_display_mode *mode);
enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
const struct drm_display_mode
*mode);
-enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode);
+enum drm_mode_status
+drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode,
+struct drm_modeset_acquire_ctx *ctx);
struct drm_encoder *
drm_connector_get_single_encoder(struct drm_connector *connector);
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 466dfbba82564..3132784736841 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -86,16 +86,17 @@ drm_mode_validate_flag(const struct drm_display_mode *mode,
return MODE_OK;
}
-static enum drm_mode_status
+static int
drm_mode_validate_pipeline(struct drm_display_mode *mode,
- struct drm_connector *connector)
+ struct drm_connector *connector,
+ struct drm_modeset_acquire_ctx *ctx)
{
struct drm_device *dev = connector->dev;
- enum drm_mode_status ret = MODE_OK;
struct drm_encoder *encoder;
+ int ret = MODE_OK;
/* Step 1: Validate against connector */
- ret = drm_connector_mode_valid(connector, mode);
+ ret = drm_connector_mode_valid(connector, mode, ctx);
if (ret != MODE_OK)
return ret;
@@ -196,16 +197,23 @@ enum drm_mode_status drm_encoder_mode_valid(struct
drm_encoder *encoder,
return encoder_funcs->mode_valid(encoder, mode);
}
-enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+int
+drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode,
+struct drm_modeset_acquire_ctx *ctx)
{
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
- if (!connector_funcs || !connector_funcs->mode_valid)
+ if (!connector_funcs)
return MODE_OK;
- return connector_funcs->mode_valid(connector, mode);
+ if (connector_funcs->mode_valid_ctx)
+ return connector_funcs->mode_valid_ctx(connector, mode, ctx);
+ else if (connector_funcs->mode_valid)
+ return connector_funcs->mode_valid(connector, mode);
+ else
+ return MODE_OK;
}
#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
@@ -375,8 +383,9 @@ EXPORT_SYMBOL(drm_helper_probe_detect);
* (if specified)
*- drm_mode_validate_flag() checks the modes against basic connector
* capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
- *- the optional &drm_connector_helper_funcs.mode_valid helper can perform
- * driver and/or sink specific checks
+ *- the optional &drm_connector_helper_funcs.mode_valid or
+ * &drm_connector_helper_funcs.mode_valid_ctx helpers can perform driver
+ * and/or sink specific checks
*- the optional &drm_crtc_helper_funcs.mode_valid,
* &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid
* helpers can perform driver and/or source specific checks which are also
@@ -507,22 +516,34 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
mode_flags |= DRM_MODE_FLAG_3D_MASK;
list_for_each_entry(mode, &connector->modes, head) {
- if (mode->status == MODE_OK)
- mode->status = drm_mode_validate_driver(dev, mode);
+ if (mode->status != MODE_OK)
+ continue;
+
+ mode->status = drm_mode_valida
[Bug 207899] AMDGPU large block noise in chrome, on streaming video pages. CS:GO freezes.
https://bugzilla.kernel.org/show_bug.cgi?id=207899 --- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) --- Can you try adding amdgpu.ppfeaturemask=0x3fff to the kernel command line in grub? Does that help? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207899] AMDGPU large block noise in chrome, on streaming video pages. CS:GO freezes.
https://bugzilla.kernel.org/show_bug.cgi?id=207899 --- Comment #6 from Blake C Lewis (blake.le...@gmail.com) --- (In reply to Alex Deucher from comment #4) > Created attachment 289301 [details] > possible fix > > Does this patch fix the issue? I haven't compiled a kernel in like 15 years, I compiled in the 1 and 2 series. I will have to figure this out. Blake -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
On Fri, 15 May 2020 13:49:20 +0800, Xin Ji wrote: > anx7625: MIPI to DP transmitter DT schema > > Signed-off-by: Xin Ji > --- > .../bindings/display/bridge/analogix,anx7625.yaml | 95 > ++ > 1 file changed, 95 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207899] AMDGPU large block noise in chrome, on streaming video pages. CS:GO freezes.
https://bugzilla.kernel.org/show_bug.cgi?id=207899 --- Comment #5 from Blake C Lewis (blake.le...@gmail.com) --- Created attachment 289303 --> https://bugzilla.kernel.org/attachment.cgi?id=289303&action=edit screenshot of block of color noise in chrome -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207899] AMDGPU large block noise in chrome, on streaming video pages. CS:GO freezes.
https://bugzilla.kernel.org/show_bug.cgi?id=207899 --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 289301 --> https://bugzilla.kernel.org/attachment.cgi?id=289301&action=edit possible fix Does this patch fix the issue? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207899] AMDGPU large block noise in chrome, on streaming video pages. CS:GO freezes.
https://bugzilla.kernel.org/show_bug.cgi?id=207899 --- Comment #3 from Blake C Lewis (blake.le...@gmail.com) --- Created attachment 289299 --> https://bugzilla.kernel.org/attachment.cgi?id=289299&action=edit journalctl -b _COMM=Xorg >xorg -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207899] AMDGPU large block noise in chrome, on streaming video pages. CS:GO freezes.
https://bugzilla.kernel.org/show_bug.cgi?id=207899 --- Comment #2 from Blake C Lewis (blake.le...@gmail.com) --- Created attachment 289297 --> https://bugzilla.kernel.org/attachment.cgi?id=289297&action=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207899] AMDGPU large block noise in chrome, on streaming video pages. CS:GO freezes.
https://bugzilla.kernel.org/show_bug.cgi?id=207899 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your xorg log (if using X) and your dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/a6xx: set ubwc config for A640 and A650
On Mon, May 25, 2020 at 11:25:13PM -0400, Jonathan Marek wrote:
> This is required for A640 and A650 to be able to share UBWC-compressed
> images with other HW such as display, which expect this configuration.
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 38 ++-
> 1 file changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 6f335ae179c8..aa004a261277 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -289,6 +289,37 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool
> state)
> gpu_write(gpu, REG_A6XX_RBBM_CLOCK_CNTL, state ? 0x8aa8aa02 : 0);
> }
>
> +static void a6xx_set_ubwc_config(struct msm_gpu *gpu)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + u32 lower_bit = 2;
> + u32 amsbc = 0;
> + u32 rgb565_predicator = 0;
> + u32 uavflagprd_inv = 0;
> +
This hardware design has the amazing ability to make me sad every time I see it.
> + /* a618 is using the hw default values */
> + if (adreno_is_a618(adreno_gpu))
> + return;
> +
I've been a recent convert to the cult of and FIELD_PREP()
could help, maybe?
if (adreno_is_a640(adreno_gpu)) {
rb_ncmode = FIELD_PREP(REG_A6XX_RB_NC_MODE_CNTL_AMSBC, 1);
rb_ncmode |= FIELD_PREP(REG_A6XX_RB_NC_MODE_CNTL_HBB, 2);
tpl1_ncmode = FIELD_PREP(REG_A6XX_TPL1_NC_MODE_HBB, 2);
sp_ncmode = FIELD_PREP(REG_A6XX_TPL1_NC_MODE_HBB, 2);
uchemode = FIELD_PREP(REG_A6XX_UCHE_MODE_CNTL_HBB, 2);
} else if adreno_is_a650(adreno_gpu)) {
rb_ncmode = FIELD_PREP(REG_A6XX_RB_NC_MODE_CNTL_AMSBC, 1);
rb_ncmode |= FIELD_PREP(REG_A6XX_RB_NC_MODE_CNTL_HBB, 3);
rb_ncmode |= FIELD_PREP(REG_A6XX_RB_NC_MODE_CNTL_RGB565, 1);
tpl1_ncmode = FIELD_PREP(REG_A6XX_TPL1_NC_MODE_HBB, 3);
sp_ncmode = FIELD_PREP(REG_A6XX_TPL1_NC_MODE_HBB, 3);
sp_ncmode |= FIELD_PREP(REG_A6XX_TPL1_NC_MODE_UAVFLAGPRD_INV, 2);
uchemode = FIELD_PREP(REG_A6XX_UCHE_MODE_CNTL_HBB, 2);
}
I'm not sure if that is any clearer or not. Perhaps this is a problem for the
next person to add a new target. Regardless the code is programming the
hardware correctly so...
Reviewed-by: Jordan Crouse
> + if (adreno_is_a640(adreno_gpu))
> + amsbc = 1;
> +
> + if (adreno_is_a650(adreno_gpu)) {
> + /* TODO: get ddr type from bootloader and use 2 for LPDDR4 */
> + lower_bit = 3;
> + amsbc = 1;
> + rgb565_predicator = 1;
> + uavflagprd_inv = 2;
> + }
> +
> + gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL,
> + rgb565_predicator << 11 | amsbc << 4 | lower_bit << 1);
> + gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, lower_bit << 1);
> + gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL,
> + uavflagprd_inv >> 4 | lower_bit << 1);
> + gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, lower_bit << 21);
> +}
> +
> static int a6xx_cp_init(struct msm_gpu *gpu)
> {
> struct msm_ringbuffer *ring = gpu->rb[0];
> @@ -478,12 +509,7 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
> /* Select CP0 to always count cycles */
> gpu_write(gpu, REG_A6XX_CP_PERFCTR_CP_SEL_0, PERF_CP_ALWAYS_COUNT);
>
> - if (adreno_is_a630(adreno_gpu)) {
> - gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL, 2 << 1);
> - gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, 2 << 1);
> - gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, 2 << 1);
> - gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, 2 << 21);
> - }
> + a6xx_set_ubwc_config(gpu);
>
> /* Enable fault detection */
> gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL,
> --
> 2.26.1
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207899] New: AMDGPU large block noise in chrome, on streaming video pages. CS:GO freezes.
https://bugzilla.kernel.org/show_bug.cgi?id=207899 Bug ID: 207899 Summary: AMDGPU large block noise in chrome, on streaming video pages. CS:GO freezes. Product: Drivers Version: 2.5 Kernel Version: 5.6.6-5.6.14 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: blake.le...@gmail.com Regression: No Kernel 2.6.6 - 5.6.14 AMDGPU video corruption/noise in blocks (Chrome) and freezes (CS:GO) HP Elite Disk 705 G4 Micro AMD Ryzen 5 Pro 2400GE w/ Radeon Vega Graphics How reproducible: Chrome: youtube.com or twitch.tv blocks on the screen get corrupted. CS:GO play for a few minutes In kernel 5.5.17, no corruption, CS:GO works video freeze. Additional info: Fedora 31 and 32 All kernels v5.6 that have been delivered to FC31 and FC32, <=5.6.14 tested The first 3 kernels v5.6 broke graphics in FC31, so I upgraded to FC32 Kernel 5.5.17 works without video corruption in FC31 and FC32 I am willing to run any data collection needed. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm/a6xx: skip HFI set freq if GMU is powered down
On Fri, May 22, 2020 at 06:29:08PM -0400, Jonathan Marek wrote: > Also skip the newly added HFI set freq path if the GMU is powered down, > which was missing because of patches crossing paths. I saw the 5.8 pull later in my inbox so I'm not sure if this made it or not but it qualifies as a -fix if it didn't. Reviewed-by: Jordan Crouse > Signed-off-by: Jonathan Marek > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > index 67c58345b26a..9851367a88cd 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > @@ -110,13 +110,6 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, > int index) > struct msm_gpu *gpu = &adreno_gpu->base; > int ret; > > - /* > - * This can get called from devfreq while the hardware is idle. Don't > - * bring up the power if it isn't already active > - */ > - if (pm_runtime_get_if_in_use(gmu->dev) == 0) > - return; > - > gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0); > > gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING, > @@ -141,7 +134,6 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int > index) >* for now leave it at max so that the performance is nominal. >*/ > icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216)); > - pm_runtime_put(gmu->dev); > } > > void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq) > @@ -159,13 +151,21 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned > long freq) > break; > > gmu->current_perf_index = perf_index; > + gmu->freq = gmu->gpu_freqs[perf_index]; > + > + /* > + * This can get called from devfreq while the hardware is idle. Don't > + * bring up the power if it isn't already active > + */ > + if (pm_runtime_get_if_in_use(gmu->dev) == 0) > + return; > > if (gmu->legacy) > __a6xx_gmu_set_freq(gmu, perf_index); > else > a6xx_hfi_set_freq(gmu, perf_index); > > - gmu->freq = gmu->gpu_freqs[perf_index]; > + pm_runtime_put(gmu->dev); > } > > unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu) > -- > 2.26.1 > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/21] drm: mxsfb: Add i.MX7 support
Hi Laurent, On 2020-03-09 20:51, Laurent Pinchart wrote: > Hello, > > This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF > instance found in the i.MX7 is backward-compatible with the already > supported LCDC v4, but has extended features amongst which the most > notable one is a second plane. > > The first 9 patches (01/21 to 09/21) contain miscellaneous cleanups and > refactoring to prepare for what is to come. Patch 10/21 starts the real > work with removal of the DRM simple display pipeline helper, as it > doesn't support multiple planes. The next patch (11/21) is an additional > cleanup. > > Patches 12/21 to 14/21 fix vblank handling that I found to be broken > when testing on my device. Patch 15/21 then performs an additional small > cleanup, and patch 16/21 starts official support for i.MX7 by mentioning > it in Kconfig. > > Patch 17/21 adds a new device model for the i.MX6SX and i.MX7 eLCDIF. > After three additional cleanups in patches 18/21 to 20/21, patch 21/21 > finally adds support for the second plane. > > The code is based on drm-misc-next and has been tested on an i.MX7D > platform with a DPI panel. Did you plan to update this series? I guess some of the changes I could already merge now. -- Stefan > > Laurent Pinchart (21): > drm: mxsfb: Remove fbdev leftovers > drm: mxsfb: Use drm_panel_bridge > drm: mxsfb: Use BIT() macro to define register bitfields > drm: mxsfb: Remove unused macros from mxsfb_regs.h > drm: mxsfb: Clarify format and bus width configuration > drm: mxsfb: Pass mxsfb_drm_private pointer to mxsfb_reset_block() > drm: mxsfb: Use LCDC_CTRL register name explicitly > drm: mxsfb: Remove register definitions from mxsfb_crtc.c > drm: mxsfb: Remove unneeded includes > drm: mxsfb: Stop using DRM simple display pipeline helper > drm: mxsfb: Rename mxsfb_crtc.c to mxsfb_kms.c > drm: mxsfb: Move vblank event arm to CRTC .atomic_flush() > drm: mxsfb: Don't touch AXI clock in IRQ context > drm: mxsfb: Enable vblank handling > drm: mxsfb: Remove mxsfb_devdata unused fields > drm: mxsfb: Add i.MX7 to the list of supported SoCs in Kconfig > drm: mxsfb: Update internal IP version number for i.MX6SX > drm: mxsfb: Drop non-OF support > drm: mxsfb: Turn mxsfb_set_pixel_fmt() into a void function > drm: mxsfb: Merge mxsfb_set_pixel_fmt() and mxsfb_set_bus_fmt() > drm: mxsfb: Support the alpha plane > > drivers/gpu/drm/mxsfb/Kconfig | 4 +- > drivers/gpu/drm/mxsfb/Makefile | 2 +- > drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 343 - > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 246 - > drivers/gpu/drm/mxsfb/mxsfb_drv.h | 42 ++- > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 565 + > drivers/gpu/drm/mxsfb/mxsfb_out.c | 99 - > drivers/gpu/drm/mxsfb/mxsfb_regs.h | 107 +++--- > 8 files changed, 730 insertions(+), 678 deletions(-) > delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_crtc.c > create mode 100644 drivers/gpu/drm/mxsfb/mxsfb_kms.c > delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_out.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: device hot-unplug for userspace
On 5/19/20 6:06 AM, Pekka Paalanen wrote: From: Pekka Paalanen Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&data=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783&sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3D&reserved=0 . Signed-off-by: Pekka Paalanen Cc: Daniel Vetter Cc: Andrey Grodzovsky Cc: Dave Airlie Cc: Sean Paul --- Disclaimer: I am a userspace developer writing for other userspace developers. I took some liberties in defining what should happen without knowing what is actually possible or what existing drivers already implement. --- Documentation/gpu/drm-uapi.rst | 75 ++ 1 file changed, 75 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 56fec6ed1ad8..80db4abd2cbd 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -1,3 +1,5 @@ +.. Copyright 2020 DisplayLink (UK) Ltd. + === Userland interfaces === @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is visible to user-space and accessible beyond open-file boundaries, they cannot support render nodes. +Device Hot-Unplug += + +.. note:: + The following is the plan. Implementation is not there yet + (2020 May 13). + +Graphics devices (display and/or render) may be connected via USB (e.g. +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end +user is able to hot-unplug this kind of devices while they are being +used, and expects that the very least the machine does not crash. Any +damage from hot-unplugging a DRM device needs to be limited as much as +possible and userspace must be given the chance to handle it if it wants +to. Ideally, unplugging a DRM device still lets a desktop to continue +running, but that is going to need explicit support throughout the whole +graphics stack: from kernel and userspace drivers, through display +servers, via window system protocols, and in applications and libraries. + +Other scenarios that should lead to the same are: unrecoverable GPU +crash, PCI device disappearing off the bus, or forced unbind of a driver +from the physical device. + +In other words, from userspace perspective everything needs to keep on +working more or less, until userspace stops using the disappeared DRM +device and closes it completely. Userspace will learn of the device +disappearance from the device removed uevent or in some cases specific +ioctls returning EIO. + +This goal raises at least the following requirements for the kernel and +drivers: + +- The kernel must not hang, crash or oops, no matter what userspace was + in the middle of doing when the device disappeared. + +- All GPU jobs that can no longer run must have their fences + force-signalled to avoid inflicting hangs to userspace. + +- KMS connectors must change their status to disconnected. + +- Legacy modesets and pageflips fake success. + +- Atomic commits, both real and TEST_ONLY, fake success. + +- Pending non-blocking KMS operations deliver the DRM events userspace + is expecting. + +- If underlying memory disappears, the mmaps are replaced with harmless + zero pages where access does not raise SIGBUS. Reads return zeros, + writes are ignored. Regarding this paragraph - what about exiting mappings ? In the first patchset we would actively invalidate all the existing CPU mappings to device memory and i think we still should do it otherwise we will see random crashes in applications as was before. I guess it's because TLBs and page tables are not updated to reflect the fact the device is gone. Andrey + +- dmabuf which point to memory that has disappeared are rewritten to + point to harmless zero pages, similar to mmaps. Imports still succeed + both ways: an existing device importing a dmabuf pointing to + disappeared memory, and a disappeared device importing any dmabuf. + +- Render ioctls return EIO which is then handled in userspace drivers, + e.g. Mesa, to have the device disappearance handled in the way + specified for each API (OpenGL, GL ES: GL_KHR_robustness; + Vulkan: VK_ERROR_DEVICE_LOST; etc.) + +Raising SIGBUS is not an option, because userspace cannot realistically +handle it. Signal handlers are global, which makes them extremely +difficult to use correctly from libraries like Mesa produces. Signal +handlers are not composable, you can't have different handlers for GPU1 +and GPU2 from different vendors, and a third handler for mmapped regular +files. Threads cause additional pain with signal handling as well. + +Only after userspac
Re: [PATCH 23/27] drm: bridge: dw-hdmi: Attach to next bridge if available
On 2020-05-26 14:50, Neil Armstrong wrote:
> On 26/05/2020 03:15, Laurent Pinchart wrote:
>> On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings
>> require a video output port connected to an HDMI sink (most likely an
>> HDMI connector, in rare cases another bridges converting HDMI to another
>> protocol). For those platforms, retrieve the next bridge and attach it
>> from the dw-hdmi bridge attach handler.
>>
>> Signed-off-by: Laurent Pinchart
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 52 ++-
>> include/drm/bridge/dw_hdmi.h | 2 +
>> 2 files changed, 53 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 6148a022569a..512e67bb1c32 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -143,6 +143,7 @@ struct dw_hdmi_phy_data {
>> struct dw_hdmi {
>> struct drm_connector connector;
>> struct drm_bridge bridge;
>> +struct drm_bridge *next_bridge;
>>
>> unsigned int version;
>>
>> @@ -2797,7 +2798,8 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
>> *bridge,
>> struct dw_hdmi *hdmi = bridge->driver_private;
>>
>> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
>> -return 0;
>> +return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
>> + bridge, flags);
>>
>> return dw_hdmi_connector_create(hdmi);
>> }
>> @@ -3179,6 +3181,50 @@ static void dw_hdmi_init_hw(struct dw_hdmi *hdmi)
>> hdmi->phy.ops->setup_hpd(hdmi, hdmi->phy.data);
>> }
>>
>> +static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
>> +{
>> +struct device_node *endpoint;
>> +struct device_node *remote;
>> +
>> +if (!hdmi->plat_data->output_port)
>> +return 0;
>> +
>> +endpoint = of_graph_get_endpoint_by_regs(hdmi->dev->of_node,
>> + hdmi->plat_data->output_port,
>> + -1);
>> +if (!endpoint) {
>> +/*
>> + * Don't treat this as a fatal error as the Rockchip DW-HDMI
>> + * binding doesn't make the output port mandatory.
>> + */
>> +dev_dbg(hdmi->dev, "Missing endpoint in port@%u\n",
>> +hdmi->plat_data->output_port);
>> +return 0;
After this series only rcar-du set output_port so this block should only
run for rcar-du, for platforms without output_port the if-statement
for !hdmi->plat_data->output_port already return success so you can
probably return fatal error here.
The comment is a little bit misleading because of the if-statement above
or am I missing something?
Regards,
Jonas
>> +}
>> +
>> +remote = of_graph_get_remote_port_parent(endpoint);
>> +of_node_put(endpoint);
>> +if (!remote) {
>> +dev_err(hdmi->dev, "Endpoint in port@%u unconnected\n",
>> +hdmi->plat_data->output_port);
>> +return -ENODEV;
>> +}
>> +
>> +if (!of_device_is_available(remote)) {
>> +dev_err(hdmi->dev, "port@%u remote device is disabled\n",
>> +hdmi->plat_data->output_port);
>> +of_node_put(remote);
>> +return -ENODEV;
>> +}
>> +
>> +hdmi->next_bridge = of_drm_find_bridge(remote);
>> +of_node_put(remote);
>> +if (!hdmi->next_bridge)
>> +return -EPROBE_DEFER;
>
> I'll be safer to print a warn for now until all platforms has been tested.
>
>> +
>> +return 0;
>> +}
>> +
>> static struct dw_hdmi *
>> __dw_hdmi_probe(struct platform_device *pdev,
>> const struct dw_hdmi_plat_data *plat_data)
>> @@ -3216,6 +3262,10 @@ __dw_hdmi_probe(struct platform_device *pdev,
>> mutex_init(&hdmi->cec_notifier_mutex);
>> spin_lock_init(&hdmi->audio_lock);
>>
>> +ret = dw_hdmi_parse_dt(hdmi);
>> +if (ret < 0)
>> +return ERR_PTR(ret);
>> +
>> ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
>> if (ddc_node) {
>> hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>> index ea34ca146b82..8ebeb65d6371 100644
>> --- a/include/drm/bridge/dw_hdmi.h
>> +++ b/include/drm/bridge/dw_hdmi.h
>> @@ -126,6 +126,8 @@ struct dw_hdmi_phy_ops {
>> struct dw_hdmi_plat_data {
>> struct regmap *regm;
>>
>> +unsigned int output_port;
>> +
>> unsigned long input_bus_encoding;
>> bool use_drm_infoframe;
>> bool ycbcr_420_allowed;
>>
>
> I must check on meson, since I'm not sure for now if the connector probes.
>
> Anyway, this looks fine.
>
> Reviewed-by: Neil Armstrong
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/27] drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()
Hi,
On Tue, May 26, 2020 at 04:14:48AM +0300, Laurent Pinchart wrote:
> When validating a mode, bridges may need to do so in the context of a
> display, as specified by drm_display_info. An example is the meson
> dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to
> perform clock calculations.
>
> Bridges that need the display info currently retrieve it from the
> drm_connector created by the bridge. This gets in the way of moving
> connector creation out of bridge drivers. To make this possible, pass
> the drm_display_info to drm_bridge_funcs .mode_valid().
>
> Changes to the bridge drivers have been performed with the following
> coccinelle semantic patch and have been compile-tested.
>
> @ rule1 @
> identifier funcs;
> identifier fn;
> @@
> struct drm_bridge_funcs funcs = {
> ...,
> .mode_valid = fn
> };
>
> @ depends on rule1 @
> identifier rule1.fn;
> identifier bridge;
> identifier mode;
> @@
> enum drm_mode_status fn(
> struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode
> )
> {
> ...
> }
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 1 +
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 1 +
> drivers/gpu/drm/bridge/cdns-dsi.c | 1 +
> drivers/gpu/drm/bridge/chrontel-ch7033.c | 1 +
> drivers/gpu/drm/bridge/nwl-dsi.c | 1 +
> drivers/gpu/drm/bridge/sii9234.c | 1 +
> drivers/gpu/drm/bridge/sil-sii8620.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 1 +
> drivers/gpu/drm/bridge/tc358767.c | 1 +
> drivers/gpu/drm/bridge/tc358768.c | 1 +
> drivers/gpu/drm/bridge/thc63lvd1024.c | 1 +
> drivers/gpu/drm/bridge/ti-tfp410.c | 1 +
> drivers/gpu/drm/drm_atomic_helper.c| 3 ++-
> drivers/gpu/drm/drm_bridge.c | 4 +++-
> drivers/gpu/drm/drm_probe_helper.c | 4 +++-
> drivers/gpu/drm/i2c/tda998x_drv.c | 1 +
> drivers/gpu/drm/omapdrm/dss/dpi.c | 1 +
> drivers/gpu/drm/omapdrm/dss/sdi.c | 1 +
> drivers/gpu/drm/omapdrm/dss/venc.c | 1 +
> include/drm/drm_bridge.h | 3 +++
> 21 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 2bc6e4f85171..371f4a9f866d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -585,6 +585,7 @@ static int anx6345_bridge_attach(struct drm_bridge
> *bridge,
>
> static enum drm_mode_status
> anx6345_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index 0d5a5ad0c9ee..81debd02c169 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -944,6 +944,7 @@ static int anx78xx_bridge_attach(struct drm_bridge
> *bridge,
>
> static enum drm_mode_status
> anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index 69c3892caee5..76373e31df92 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -663,6 +663,7 @@ static int cdns_dsi_bridge_attach(struct drm_bridge
> *bridge,
>
> static enum drm_mode_status
> cdns_dsi_bridge_mode_valid(struct drm_bridge *bridge,
> +const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
> diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> index f8675d82974b..486f405c2e16 100644
> --- a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> +++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> @@ -317,6 +317,7 @@ static void ch7033_bridge_detach(struct drm_bridge
> *bridge)
> }
>
> static enum drm_mode_status ch7033_bridge_mode_valid(struct drm_bridge
> *bridge,
> + const struct drm_display_info *info,
>const struct drm_display_mode *mode)
> {
> if (mode->clock > 165000)
> diff --git a/
Re: [PATCH] drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
Hi Jonas,
On Mon, May 25, 2020 at 11:08:11AM +, Jonas Karlman wrote:
> Hi,
>
> On 2020-05-15 15:37, Brian Starkey wrote:
> > Hi Ben,
> >
> > On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote:
> >> Hi all, any feedback on this patch?
> >> Thanks, Ben
> >> On Wed, Apr 22, 2020 at 12:13:49PM +0100, Ben Davis wrote:
> >>> DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
> >>> block-linear memory layouts. The format is similar to P010 with 4:2:0
> >>> sub-sampling but has no padding between components. Instead, luminance
> >>> and chrominance samples are grouped into 4s so that each group is packed
> >>> into an integer number of bytes:
> >>>
> >>> = UVUV = 4 * 10 bits = 40 bits = 5 bytes
> >>>
> >>> The '15' suffix refers to the optimum effective bits per pixel which is
> >>> achieved when the total number of luminance samples is a multiple of 8.
> >>>
> >>> Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
> >>> component, but only 10 bits are used and 6 are padded. 'Q' is chosen
> >>> as the first letter to denote 3 plane YUV444, (and is the next letter
> >>> along from P which is usually 2 plane).
> >>>
> >>> Signed-off-by: Ben Davis
> >
> > The descriptions match my understanding of the formats and the
> > format_info struct, so feel free to add my r-b:
> >
> > Reviewed-by: Brian Starkey
> >
> > Can anyone else pass comment on the approach and/or naming? I feel
> > like we should have some non-Arm eyes on this before we merge it.
>
> This pixel format seem to match the memory layout used for 10-bit 4:2:0 by the
> Rockchip Video Decoder, for the rkvdec a 4:2:2 format is also needed (maybe
> NV20?).
>
> From what I can tell the rockchip specific pixel format has previously been
> submitted in [1]
> and GStreamer use NV12_10LE40 (fourcc RK20) for this pixel format.
>
> [1] https://patchwork.freedesktop.org/patch/276029/
>
Yeah you're right, this is the same as the Rockchip version. I see
Randy's submission has `block_w = { 4, 2, 0 }`... more on that below.
The comment on block_w says "in pixels" - but what's a pixel in a
subsampled chroma plane? For a 2-plane 4:2:0 format, is one pair of
chroma samples a single pixel, or one pair of chroma samples is two
pixels?
Looks like Randy assumed the former and us the latter.
> >
> > Thanks,
> > -Brian
> >
> >>> ---
> >>> drivers/gpu/drm/drm_fourcc.c | 12
> >>> include/uapi/drm/drm_fourcc.h | 24
> >>> 2 files changed, 36 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >>> index b234bfaeda06..0c0a65481afd 100644
> >>> --- a/drivers/gpu/drm/drm_fourcc.c
> >>> +++ b/drivers/gpu/drm/drm_fourcc.c
> >>> @@ -274,6 +274,18 @@ const struct drm_format_info *__drm_format_info(u32
> >>> format)
> >>> { .format = DRM_FORMAT_YUV420_10BIT,.depth = 0,
> >>> .num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
> >>> .is_yuv = true },
> >>> + { .format = DRM_FORMAT_NV15,.depth = 0,
> >>> + .num_planes = 2, .char_per_block = { 5, 5, 0 },
> >>> + .block_w = { 4, 4, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
> >>> + .vsub = 2, .is_yuv = true },
>
> For a 4:2:0 format I wonder if the char_per_block value is correct for the
> second plane,
> using the following formula to calculate the pitch seem to result in only
> half expected width.
> Maybe .char_per_block { 5, 10, 0 } could be correct?
>
> pitch = (width * char_per_block[1]) / block_w[1] / hsub
>
> for 16x16 this would be
>
> pitch[1] = (16 * 5) / 4 / 2 = 10 bytes
> vs
> pitch[1] = (16 * 10) / 4 / 2 = 20 bytes
>
> height[1] = 16 / 2 = 8
>
I've talked myself round in circles, I don't know what to think any
more.
drm_format_info_min_pitch() does:
pitch[1] = width * char_per_block[1] / (block_w[1] * block_h[1])
so:
pitch[1] = 16 * 5 / (4 * 1) = 20 bytes
which implies that it expects the subsampling to be baked in to the
block size, or that it just doesn't consider subsampling and so is
broken, or that it expects `width` to be pre-divided.
Looking at DRM_FORMAT_NV12, it has cpp = {1, 2, 0}, which means it
considers a single pair of chromas to be a single pixel - which is
in-line with Randy.
So, I think our definition is inconsistent here. We should have
either:
block_w = { 4, 4, 0 }, char_per_block = { 5, 10, 0 }
or:
block_w = { 4, 2, 0 }, char_per_block = { 5, 5, 0 }
Probably leaning more towards the { 4, 2, 0 } option, and with a big
question-mark over whether drm_format_info_min_pitch() is doing the
right thing.
Thanks,
-Brian
>
> Regards,
> Jonas
>
> >>> + { .format = DRM_FORMAT_Q410,.depth = 0,
> >>> + .num_planes = 3, .char_per_block = { 2, 2, 2 },
> >>> + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> >>> + .vsub = 0, .is_yuv = true },
> >>> + { .format = DRM_FORMAT_Q401,
Re: [PATCH 17/21] drm/stm: Use GEM CMA object functions
On 5/22/20 3:52 PM, Thomas Zimmermann wrote:
> The stm driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
> these defaults and .dumb_create in struct drm_driver. All remaining
> operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/stm/drv.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 0f85dd86cafa7..d6238c71fabf6 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -62,16 +62,7 @@ static struct drm_driver drv_driver = {
> .minor = 0,
> .patchlevel = 0,
> .fops = &drv_driver_fops,
> - .dumb_create = stm_gem_cma_dumb_create,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> + __DRM_GEM_CMA_DRIVER_OPS(stm_gem_cma_dumb_create),
> };
>
> static int drv_load(struct drm_device *ddev)
>
Hi Thomas,
Thank you for the patch.
Reviewed-by: Philippe Cornu
Philippe :-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/27] drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()
On Tue, 26 May 2020 04:14:48 +0300
Laurent Pinchart wrote:
> When validating a mode, bridges may need to do so in the context of a
> display, as specified by drm_display_info. An example is the meson
> dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to
> perform clock calculations.
>
> Bridges that need the display info currently retrieve it from the
> drm_connector created by the bridge. This gets in the way of moving
> connector creation out of bridge drivers. To make this possible, pass
> the drm_display_info to drm_bridge_funcs .mode_valid().
>
> Changes to the bridge drivers have been performed with the following
> coccinelle semantic patch and have been compile-tested.
>
> @ rule1 @
> identifier funcs;
> identifier fn;
> @@
> struct drm_bridge_funcs funcs = {
> ...,
> .mode_valid = fn
> };
>
> @ depends on rule1 @
> identifier rule1.fn;
> identifier bridge;
> identifier mode;
> @@
> enum drm_mode_status fn(
> struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode
> )
> {
> ...
> }
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/27] drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()
On 26/05/2020 03:14, Laurent Pinchart wrote:
> When validating a mode, bridges may need to do so in the context of a
> display, as specified by drm_display_info. An example is the meson
> dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to
> perform clock calculations.
>
> Bridges that need the display info currently retrieve it from the
> drm_connector created by the bridge. This gets in the way of moving
> connector creation out of bridge drivers. To make this possible, pass
> the drm_display_info to drm_bridge_funcs .mode_valid().
>
> Changes to the bridge drivers have been performed with the following
> coccinelle semantic patch and have been compile-tested.
>
> @ rule1 @
> identifier funcs;
> identifier fn;
> @@
> struct drm_bridge_funcs funcs = {
> ...,
> .mode_valid = fn
> };
>
> @ depends on rule1 @
> identifier rule1.fn;
> identifier bridge;
> identifier mode;
> @@
> enum drm_mode_status fn(
> struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode
> )
> {
> ...
> }
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 1 +
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 1 +
> drivers/gpu/drm/bridge/cdns-dsi.c | 1 +
> drivers/gpu/drm/bridge/chrontel-ch7033.c | 1 +
> drivers/gpu/drm/bridge/nwl-dsi.c | 1 +
> drivers/gpu/drm/bridge/sii9234.c | 1 +
> drivers/gpu/drm/bridge/sil-sii8620.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 1 +
> drivers/gpu/drm/bridge/tc358767.c | 1 +
> drivers/gpu/drm/bridge/tc358768.c | 1 +
> drivers/gpu/drm/bridge/thc63lvd1024.c | 1 +
> drivers/gpu/drm/bridge/ti-tfp410.c | 1 +
> drivers/gpu/drm/drm_atomic_helper.c| 3 ++-
> drivers/gpu/drm/drm_bridge.c | 4 +++-
> drivers/gpu/drm/drm_probe_helper.c | 4 +++-
> drivers/gpu/drm/i2c/tda998x_drv.c | 1 +
> drivers/gpu/drm/omapdrm/dss/dpi.c | 1 +
> drivers/gpu/drm/omapdrm/dss/sdi.c | 1 +
> drivers/gpu/drm/omapdrm/dss/venc.c | 1 +
> include/drm/drm_bridge.h | 3 +++
> 21 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 2bc6e4f85171..371f4a9f866d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -585,6 +585,7 @@ static int anx6345_bridge_attach(struct drm_bridge
> *bridge,
>
> static enum drm_mode_status
> anx6345_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index 0d5a5ad0c9ee..81debd02c169 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -944,6 +944,7 @@ static int anx78xx_bridge_attach(struct drm_bridge
> *bridge,
>
> static enum drm_mode_status
> anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index 69c3892caee5..76373e31df92 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -663,6 +663,7 @@ static int cdns_dsi_bridge_attach(struct drm_bridge
> *bridge,
>
> static enum drm_mode_status
> cdns_dsi_bridge_mode_valid(struct drm_bridge *bridge,
> +const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
> diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> index f8675d82974b..486f405c2e16 100644
> --- a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> +++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> @@ -317,6 +317,7 @@ static void ch7033_bridge_detach(struct drm_bridge
> *bridge)
> }
>
> static enum drm_mode_status ch7033_bridge_mode_valid(struct drm_bridge
> *bridge,
> + const struct drm_display_info *info,
>const struct drm_display_mode *mode)
> {
> if (mode->clock > 165000)
> diff --git a/drivers/gpu/drm/bridge/nw
Re: [PATCH 23/27] drm: bridge: dw-hdmi: Attach to next bridge if available
On 26/05/2020 03:15, Laurent Pinchart wrote:
> On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings
> require a video output port connected to an HDMI sink (most likely an
> HDMI connector, in rare cases another bridges converting HDMI to another
> protocol). For those platforms, retrieve the next bridge and attach it
> from the dw-hdmi bridge attach handler.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 52 ++-
> include/drm/bridge/dw_hdmi.h | 2 +
> 2 files changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 6148a022569a..512e67bb1c32 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -143,6 +143,7 @@ struct dw_hdmi_phy_data {
> struct dw_hdmi {
> struct drm_connector connector;
> struct drm_bridge bridge;
> + struct drm_bridge *next_bridge;
>
> unsigned int version;
>
> @@ -2797,7 +2798,8 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
> *bridge,
> struct dw_hdmi *hdmi = bridge->driver_private;
>
> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> - return 0;
> + return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
> + bridge, flags);
>
> return dw_hdmi_connector_create(hdmi);
> }
> @@ -3179,6 +3181,50 @@ static void dw_hdmi_init_hw(struct dw_hdmi *hdmi)
> hdmi->phy.ops->setup_hpd(hdmi, hdmi->phy.data);
> }
>
> +static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
> +{
> + struct device_node *endpoint;
> + struct device_node *remote;
> +
> + if (!hdmi->plat_data->output_port)
> + return 0;
> +
> + endpoint = of_graph_get_endpoint_by_regs(hdmi->dev->of_node,
> + hdmi->plat_data->output_port,
> + -1);
> + if (!endpoint) {
> + /*
> + * Don't treat this as a fatal error as the Rockchip DW-HDMI
> + * binding doesn't make the output port mandatory.
> + */
> + dev_dbg(hdmi->dev, "Missing endpoint in port@%u\n",
> + hdmi->plat_data->output_port);
> + return 0;
> + }
> +
> + remote = of_graph_get_remote_port_parent(endpoint);
> + of_node_put(endpoint);
> + if (!remote) {
> + dev_err(hdmi->dev, "Endpoint in port@%u unconnected\n",
> + hdmi->plat_data->output_port);
> + return -ENODEV;
> + }
> +
> + if (!of_device_is_available(remote)) {
> + dev_err(hdmi->dev, "port@%u remote device is disabled\n",
> + hdmi->plat_data->output_port);
> + of_node_put(remote);
> + return -ENODEV;
> + }
> +
> + hdmi->next_bridge = of_drm_find_bridge(remote);
> + of_node_put(remote);
> + if (!hdmi->next_bridge)
> + return -EPROBE_DEFER;
I'll be safer to print a warn for now until all platforms has been tested.
> +
> + return 0;
> +}
> +
> static struct dw_hdmi *
> __dw_hdmi_probe(struct platform_device *pdev,
> const struct dw_hdmi_plat_data *plat_data)
> @@ -3216,6 +3262,10 @@ __dw_hdmi_probe(struct platform_device *pdev,
> mutex_init(&hdmi->cec_notifier_mutex);
> spin_lock_init(&hdmi->audio_lock);
>
> + ret = dw_hdmi_parse_dt(hdmi);
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
> if (ddc_node) {
> hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index ea34ca146b82..8ebeb65d6371 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -126,6 +126,8 @@ struct dw_hdmi_phy_ops {
> struct dw_hdmi_plat_data {
> struct regmap *regm;
>
> + unsigned int output_port;
> +
> unsigned long input_bus_encoding;
> bool use_drm_infoframe;
> bool ycbcr_420_allowed;
>
I must check on meson, since I'm not sure for now if the connector probes.
Anyway, this looks fine.
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 22/27] drm: bridge: dw-hdmi: Make connector creation optional
On 26/05/2020 03:15, Laurent Pinchart wrote:
> Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
> call drm_bridge_hpd_notify() notify to report HPD. This provides the
> necessary API to support disabling connector creation, do so by
> accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in dw_hdmi_bridge_attach().
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 104 +++---
> 1 file changed, 74 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index b69c14b9de62..6148a022569a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2323,15 +2323,8 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi
> *hdmi)
> hdmi->rxsense);
> }
>
> -/*
> -
> - * DRM Connector Operations
> - */
> -
> -static enum drm_connector_status
> -dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
> +static enum drm_connector_status dw_hdmi_detect(struct dw_hdmi *hdmi)
> {
> - struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> - connector);
> enum drm_connector_status result;
>
> mutex_lock(&hdmi->mutex);
> @@ -2354,31 +2347,57 @@ dw_hdmi_connector_detect(struct drm_connector
> *connector, bool force)
> return result;
> }
>
> -static int dw_hdmi_connector_get_modes(struct drm_connector *connector)
> +static struct edid *dw_hdmi_get_edid(struct dw_hdmi *hdmi,
> + struct drm_connector *connector)
> {
> - struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> - connector);
> struct edid *edid;
> - int ret = 0;
>
> if (!hdmi->ddc)
> - return 0;
> + return NULL;
>
> edid = drm_get_edid(connector, hdmi->ddc);
> - if (edid) {
> - dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
> - edid->width_cm, edid->height_cm);
> -
> - hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> - hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> - drm_connector_update_edid_property(connector, edid);
> - cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
> - ret = drm_add_edid_modes(connector, edid);
> - kfree(edid);
> - } else {
> + if (!edid) {
> dev_dbg(hdmi->dev, "failed to get edid\n");
> + return NULL;
> }
>
> + dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
> + edid->width_cm, edid->height_cm);
> +
> + hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> + hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> +
> + return edid;
> +}
> +
> +/*
> -
> + * DRM Connector Operations
> + */
> +
> +static enum drm_connector_status
> +dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
> +{
> + struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> + connector);
> + return dw_hdmi_detect(hdmi);
> +}
> +
> +static int dw_hdmi_connector_get_modes(struct drm_connector *connector)
> +{
> + struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> + connector);
> + struct edid *edid;
> + int ret;
> +
> + edid = dw_hdmi_get_edid(hdmi, connector);
> + if (!edid)
> + return 0;
> +
> + drm_connector_update_edid_property(connector, edid);
> + cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
> + ret = drm_add_edid_modes(connector, edid);
> + kfree(edid);
> +
> return ret;
> }
>
> @@ -2777,10 +2796,8 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
> *bridge,
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> - }
> + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> + return 0;
>
> return dw_hdmi_connector_create(hdmi);
> }
> @@ -2860,6 +2877,21 @@ static void dw_hdmi_bridge_atomic_enable(struct
> drm_bridge *bridge,
> mutex_unlock(&hdmi->mutex);
> }
>
> +static enum drm_connector_status dw_hdmi_bridge_detect(struct drm_bridge
> *bridge)
> +{
> + struct dw_hdmi *hdmi = bridge->driver_private;
> +
> + return dw_hdmi_detect(hdmi);
> +}
> +
> +static struct edid *dw_hdmi_bridge_get_edid(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> +{
> +
Re: [PATCH 14/27] drm: meson: dw-hdmi: Use dw_hdmi context to replace hack
On 26/05/2020 03:14, Laurent Pinchart wrote:
> The meson-dw-hdmi driver needs to access its own context from the
> .mode_valid() operation. It currently gets it from the dev_private field
> of the drm_device retrieved from the connector, which is a hack. Use the
> private data passed to the .mode_valid() operation instead.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 5cc311c1b8e0..34ba94922605 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -634,7 +634,8 @@ dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> struct drm_connector *connector,
> const struct drm_display_mode *mode)
> {
> - struct meson_drm *priv = connector->dev->dev_private;
> + struct meson_dw_hdmi *dw_hdmi = data;
> + struct meson_drm *priv = dw_hdmi->priv;
> bool is_hdmi2_sink = connector->display_info.hdmi.scdc.supported;
> unsigned int phy_freq;
> unsigned int vclk_freq;
> @@ -693,7 +694,7 @@ dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> venc_freq /= 2;
>
> - dev_dbg(connector->dev->dev, "%s: vclk:%d phy=%d venc=%d hdmi=%d\n",
> + dev_dbg(dw_hdmi->dev, "%s: vclk:%d phy=%d venc=%d hdmi=%d\n",
> __func__, phy_freq, vclk_freq, venc_freq, hdmi_freq);
>
> return meson_vclk_vic_supported_freq(priv, phy_freq, vclk_freq);
> @@ -1068,6 +1069,7 @@ static int meson_dw_hdmi_bind(struct device *dev,
> struct device *master,
>
> /* Bridge / Connector */
>
> + dw_plat_data->priv_data = meson_dw_hdmi;
> dw_plat_data->mode_valid = dw_hdmi_mode_valid;
> dw_plat_data->phy_ops = &meson_dw_hdmi_phy_ops;
> dw_plat_data->phy_name = "meson_dw_hdmi_phy";
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/27] drm: bridge: dw-hdmi: Store current connector in struct dw_hdmi
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Store the connector that the bridge is currently wired to in the dw_hdmi
> structure. This is currently identical to the connector field, but will
> differ once the driver supports disabling connector creation.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 35d38b644912..16bffedb4715 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -181,6 +181,7 @@ struct dw_hdmi {
>
> struct mutex mutex; /* for state below and previous_mode */
> enum drm_connector_force force; /* mutex-protected force state */
> + struct drm_connector *curr_conn;/* current connector (only valid when
> !disabled) */
Nit: The comment position is not great, but I don't see other ways except
adding a tab and removing "(only valid when !disabled)"
> bool disabled; /* DRM has disabled our bridge */
> bool bridge_is_on; /* indicates the bridge is on */
> bool rxsense; /* rxsense state */
> @@ -2823,23 +2824,32 @@ static void dw_hdmi_bridge_mode_set(struct drm_bridge
> *bridge,
> mutex_unlock(&hdmi->mutex);
> }
>
> -static void dw_hdmi_bridge_disable(struct drm_bridge *bridge)
> +static void dw_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
> + struct drm_bridge_state *old_state)
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
>
> mutex_lock(&hdmi->mutex);
> hdmi->disabled = true;
> + hdmi->curr_conn = NULL;
> dw_hdmi_update_power(hdmi);
> dw_hdmi_update_phy_mask(hdmi);
> mutex_unlock(&hdmi->mutex);
> }
>
> -static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
> +static void dw_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
> + struct drm_bridge_state *old_state)
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
> + struct drm_atomic_state *state = old_state->base.state;
> + struct drm_connector *connector;
> +
> + connector = drm_atomic_get_new_connector_for_encoder(state,
> + bridge->encoder);
>
> mutex_lock(&hdmi->mutex);
> hdmi->disabled = false;
> + hdmi->curr_conn = connector;
> dw_hdmi_update_power(hdmi);
> dw_hdmi_update_phy_mask(hdmi);
> mutex_unlock(&hdmi->mutex);
> @@ -2854,8 +2864,8 @@ static const struct drm_bridge_funcs
> dw_hdmi_bridge_funcs = {
> .atomic_check = dw_hdmi_bridge_atomic_check,
> .atomic_get_output_bus_fmts = dw_hdmi_bridge_atomic_get_output_bus_fmts,
> .atomic_get_input_bus_fmts = dw_hdmi_bridge_atomic_get_input_bus_fmts,
> - .enable = dw_hdmi_bridge_enable,
> - .disable = dw_hdmi_bridge_disable,
> + .atomic_enable = dw_hdmi_bridge_atomic_enable,
> + .atomic_disable = dw_hdmi_bridge_atomic_disable,
> .mode_set = dw_hdmi_bridge_mode_set,
> .mode_valid = dw_hdmi_bridge_mode_valid,
> };
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/27] drm: bridge: dw-hdmi: Pass drm_connector to internal functions as needed
On 26/05/2020 03:14, Laurent Pinchart wrote:
> To prepare for making connector creation optional in the driver, pass
> the drm_connector explicitly to the internal functions that require it.
> The functions that still access the connector from the dw_hdmi structure
> are dw_hdmi_connector_create() and __dw_hdmi_probe(). The former access
> is expected, as that's where the internal connector is created. The
> latter will be addressed separately.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 31 +--
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 16bffedb4715..b69c14b9de62 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1632,18 +1632,17 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
> }
>
> static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> + const struct drm_connector *connector,
> const struct drm_display_mode *mode)
> {
> struct hdmi_avi_infoframe frame;
> u8 val;
>
> /* Initialise info frame from DRM mode */
> - drm_hdmi_avi_infoframe_from_display_mode(&frame,
> - &hdmi->connector, mode);
> + drm_hdmi_avi_infoframe_from_display_mode(&frame, connector, mode);
>
> if (hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
> - drm_hdmi_avi_infoframe_quant_range(&frame, &hdmi->connector,
> -mode,
> + drm_hdmi_avi_infoframe_quant_range(&frame, connector, mode,
>
> hdmi->hdmi_data.rgb_limited_range ?
>
> HDMI_QUANTIZATION_RANGE_LIMITED :
>
> HDMI_QUANTIZATION_RANGE_FULL);
> @@ -1760,14 +1759,14 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> }
>
> static void hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
> + const struct drm_connector
> *connector,
> const struct drm_display_mode
> *mode)
> {
> struct hdmi_vendor_infoframe frame;
> u8 buffer[10];
> ssize_t err;
>
> - err = drm_hdmi_vendor_infoframe_from_display_mode(&frame,
> - &hdmi->connector,
> + err = drm_hdmi_vendor_infoframe_from_display_mode(&frame, connector,
> mode);
> if (err < 0)
> /*
> @@ -1813,9 +1812,10 @@ static void
> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
> HDMI_FC_DATAUTO0_VSD_MASK);
> }
>
> -static void hdmi_config_drm_infoframe(struct dw_hdmi *hdmi)
> +static void hdmi_config_drm_infoframe(struct dw_hdmi *hdmi,
> + const struct drm_connector *connector)
> {
> - const struct drm_connector_state *conn_state = hdmi->connector.state;
> + const struct drm_connector_state *conn_state = connector->state;
> struct hdmi_drm_infoframe frame;
> u8 buffer[30];
> ssize_t err;
> @@ -2118,9 +2118,9 @@ static void hdmi_disable_overflow_interrupts(struct
> dw_hdmi *hdmi)
> }
>
> static int dw_hdmi_setup(struct dw_hdmi *hdmi,
> + const struct drm_connector *connector,
>const struct drm_display_mode *mode)
> {
> - struct drm_connector *connector = &hdmi->connector;
> int ret;
>
> hdmi_disable_overflow_interrupts(hdmi);
> @@ -2192,9 +2192,9 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi,
> dev_dbg(hdmi->dev, "%s HDMI mode\n", __func__);
>
> /* HDMI Initialization Step F - Configure AVI InfoFrame */
> - hdmi_config_AVI(hdmi, mode);
> - hdmi_config_vendor_specific_infoframe(hdmi, mode);
> - hdmi_config_drm_infoframe(hdmi);
> + hdmi_config_AVI(hdmi, connector, mode);
> + hdmi_config_vendor_specific_infoframe(hdmi, connector, mode);
> + hdmi_config_drm_infoframe(hdmi, connector);
> } else {
> dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
> }
> @@ -2263,7 +2263,12 @@ static void initialize_hdmi_ih_mutes(struct dw_hdmi
> *hdmi)
> static void dw_hdmi_poweron(struct dw_hdmi *hdmi)
> {
> hdmi->bridge_is_on = true;
> - dw_hdmi_setup(hdmi, &hdmi->previous_mode);
> +
> + /*
> + * The curr_conn field is guaranteed to be valid here, as this function
> + * is only be called when !hdmi->disabled.
> + */
> + dw_hdmi_setup(hdmi, hdmi->curr_conn, &hdmi->previous_mode);
> }
>
> static void dw_hdmi_poweroff(struct dw_hdmi *hdmi)
>
Reviewed-by: Neil Arms
Re: Dynamically change enumeration list of DRM enumeration property
On Tue, May 26, 2020 at 9:39 AM Pekka Paalanen wrote: > > On Tue, 26 May 2020 10:01:23 +0530 > Yogish Kulkarni wrote: > > > Hi, > > > > Is it possible to dynamically change enumeration list of DRM enumeration > > property ? Motivation behind this question is to understand whether it is > > possible to create connector enum property (e.g a property which will list > > supported output encodings - like yuv420, yuv422 etc) whose list of > > supported enum values could be changed dynamically e.g. based on which sink > > is connected. > > > > I think there is existing EDID connector property whose value changes based > > on connected sink. EDID is a BLOB property, I am trying to understand if > > this is also possible for ENUM type property. There is > > "drm_property_replace_blob" to replace blob but I wasn't able to find any > > API which could replace list of supported enums. Alternatively, would it be > > good idea to destroy custom enum property created by a driver and create > > new enum property with new list of supported enums e.g when there is a > > HOTPLUG event. > > Hi, > > looking at Weston code, it *might* cope with it. A hotplug event does > cause Weston to re-discover all properties of a connector. This is > specific to connectors only. Currently the kernel doesn't cope with that. Only objects which can be added/removed are connectors, blobs and fbs (iow the refcounted ones). Adding/removing properties isn't supported, nor is adding/removing which properties are attached to which object while that object is life. Also I think the uapi risk for this is way too big, see my other reply for what we've done in the past for stuff like this. -Daniel > The race exists though: userspace might be poking at KMS after you > changed the property in the kernel but before userspace handles the > hotplug event. You'd have to check that does not cause regressions. I > guess for a completely new property, the risk seems low, as userspace > does not know to poke at it (risk of using outdated property or value > IDs causing unexpected atomic commit failure). Also I'm not aware of > any KMS program that would yet attempt blind KMS state save & restore > to sanitize the KMS state after dropping and re-gaining DRM master. > > You'd have to check all other KMS using programs too: every Wayland > compositor, Xorg, DRM Vulkan WSI(?), ... > > > Thanks, > pq > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically change enumeration list of DRM enumeration property
Thanks, Daniel & Pekka. It might be bad idea to destroy and re-create the connector enum property from HOTPLUG handler in DRM. But if this is done through DRM_IOCTL_MODE_GETCONNECTOR, there won't be race, right ? From code walk through it seems that Weston will call this IOCTL for newly connected display found through HOTPLUG event and DRM driver will update the EDID through the call sequence triggered by this IOCTL. On the similar line if existing connector property is destroyed and re-created with new enmu list through this IOCTL call chain, then there won't be race ? Thanks, -Yogish On Tue, May 26, 2020 at 1:09 PM Pekka Paalanen wrote: > On Tue, 26 May 2020 10:01:23 +0530 > Yogish Kulkarni wrote: > > > Hi, > > > > Is it possible to dynamically change enumeration list of DRM enumeration > > property ? Motivation behind this question is to understand whether it is > > possible to create connector enum property (e.g a property which will > list > > supported output encodings - like yuv420, yuv422 etc) whose list of > > supported enum values could be changed dynamically e.g. based on which > sink > > is connected. > > > > I think there is existing EDID connector property whose value changes > based > > on connected sink. EDID is a BLOB property, I am trying to understand if > > this is also possible for ENUM type property. There is > > "drm_property_replace_blob" to replace blob but I wasn't able to find any > > API which could replace list of supported enums. Alternatively, would it > be > > good idea to destroy custom enum property created by a driver and create > > new enum property with new list of supported enums e.g when there is a > > HOTPLUG event. > > Hi, > > looking at Weston code, it *might* cope with it. A hotplug event does > cause Weston to re-discover all properties of a connector. This is > specific to connectors only. > > The race exists though: userspace might be poking at KMS after you > changed the property in the kernel but before userspace handles the > hotplug event. You'd have to check that does not cause regressions. I > guess for a completely new property, the risk seems low, as userspace > does not know to poke at it (risk of using outdated property or value > IDs causing unexpected atomic commit failure). Also I'm not aware of > any KMS program that would yet attempt blind KMS state save & restore > to sanitize the KMS state after dropping and re-gaining DRM master. > > You'd have to check all other KMS using programs too: every Wayland > compositor, Xorg, DRM Vulkan WSI(?), ... > > > Thanks, > pq > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
Hi Ondrej, I see you took over this driver submission from Icenowy. On Wed, May 13, 2020 at 11:24 PM Ondrej Jirman wrote: > From: Icenowy Zheng > > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by > Xingbangda, which is used on PinePhone final assembled phones. > > It is based on Sitronix ST7703 LCD controller. > > Add support for it. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Ondrej Jirman (...) > create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c Nice! > + /* > +* Init sequence was supplied by the panel vendor. > +*/ > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC, > + 0xF1, 0x12, 0x83); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI, > + 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25, > + 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11, > + 0x00, 0x00, 0x37); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, > + 0x25, 0x22, 0x20, 0x03); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF, > + 0x10, 0x10, 0x05, 0x05, 0x03, 0xFF, 0x00, 0x00, > + 0x00, 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR, > + 0x73, 0x73, 0x50, 0x50, 0x00, 0xC0, 0x08, 0x70, > + 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x4E); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0B); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETDISP, 0xF0, 0x12, 0xF0); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETEQ, > + 0x00, 0x00, 0x0B, 0x0B, 0x10, 0x10, 0x00, 0x00, > + 0x00, 0x00, 0xFF, 0x00, 0xC0, 0x10); > + dsi_dcs_write_seq(dsi, 0xC6, 0x01, 0x00, 0xFF, 0xFF, 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER, > + 0x74, 0x00, 0x32, 0x32, 0x77, 0xF1, 0xFF, 0xFF, > + 0xCC, 0xCC, 0x77, 0x77); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x07, 0x07); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x2C, 0x2C); > + dsi_dcs_write_seq(dsi, 0xBF, 0x02, 0x11, 0x00); > + > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1, > + 0x82, 0x10, 0x06, 0x05, 0xA2, 0x0A, 0xA5, 0x12, > + 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38, > + 0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00, > + 0x03, 0x00, 0x00, 0x00, 0x75, 0x75, 0x31, 0x88, > + 0x88, 0x88, 0x88, 0x88, 0x88, 0x13, 0x88, 0x64, > + 0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > + 0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2, > + 0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88, > + 0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13, > + 0x57, 0x13, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > + 0x75, 0x88, 0x23, 0x14, 0x00, 0x00, 0x02, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0A, > + 0xA5, 0x00, 0x00, 0x00, 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, > + 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, 0x35, > + 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, 0x12, > + 0x18, 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, > + 0x35, 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, > + 0x12, 0x18); > + msleep(20); This stuff is really hard or impossible to understand without the datasheet. In my previous review I wrote: It appears that the Himax HX8363 is using the same display controller if you look at the datasheet: http://www.datasheet-pdf.com/PDF/HX8369-A-Datasheet-Himax-729024 There you find an explanation to some of the commands. That means, try to get rid of as much of the magic bytes as you can and use proper #defines. I know it takes some work but the result is so much more useful and readable. Further I wrote: You should definately insert code to read the MTP bytes: 0xDA manufacturer 0xDB driver version 0xDC LCD module/driver And print these, se e.g. my newly added NT35510 driver or the Sony ACX424AKP driver. So please do that. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/
Re: [PATCH v5 00/38] DRM: fix struct sg_table nents vs. orig_nents misuse
On Tue, May 26, 2020 at 9:01 AM Marek Szyprowski wrote: > > Hi > > On 13.05.2020 15:47, Christoph Hellwig wrote: > > I've pushed out a branch with the first three patches here: > > > > git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper > > > > Gitweb: > > > > > > http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-sg_table-helper > > > > and merged it into the dma-mapping for-next tree. Unless someone shouts > > the branch should be considered immutable in 24 hours. > > David & Daniel: could you merge all the DRM related changes on top of > the provided branch? Merging those changes separately would take a lots > of time because of the dependencies on the sgtable helpers and changes > in the DRM core. We generally freeze drm for big rework past -rc6 (small drivers tend to be a bit later). I think simpler if we just land this in the merge window and then smash the drm patches on top for 5.9 merge window. Or all in in the same topic branch, but feels a bit late for that and making sure nothing breaks. -Daniel > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/5] dt-bindings: panel: Add binding for Xingbangda XBD599 panel
On Wed, May 13, 2020 at 11:24 PM Ondrej Jirman wrote: > From: Icenowy Zheng > > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel. It is based on > Sitronix ST7703 LCD controller. > > Add its device tree binding. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Ondrej Jirman Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Don't warn hrtimer_forward_now failure.
On Tue, May 26, 2020 at 6:39 AM Tetsuo Handa
wrote:
>
> On 2020/05/26 13:18, Tetsuo Handa wrote:
> > due to mode->crtc_clock <= 0. Thus, somehow initializing mode->crtc_clock >
> > 0 might be able
> > to solve this problem.
>
> Well, I came to think that vkms_enable_vblank() should return an error to the
> caller
> when drm_calc_timestamping_constants() failed...
If my memory is right we shouldn't even get there. crtc->mode being
all zeros sounds like the simulated output isn't on (no surprise,
syzbot doesn't enable it and fbcon is probably on card0), so something
higher up should reject this. I'll see whether I can figure out what
vkms isn't doing right (or whether there's a higher level bug in
drm_vblank.c code), yesterday my machine died and already evening
anyway.
Thanks for digging into this a bit more meanwhile.
Cheers, Daniel
>
> static int vkms_enable_vblank(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> unsigned int pipe = drm_crtc_index(crtc);
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
>
> drm_calc_timestamping_constants(crtc, &crtc->mode);
>
> hrtimer_init(&out->vblank_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> out->vblank_hrtimer.function = &vkms_vblank_simulate;
> out->period_ns = ktime_set(0, vblank->framedur_ns);
> hrtimer_start(&out->vblank_hrtimer, out->period_ns, HRTIMER_MODE_REL);
>
> return 0;
> }
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/16] drm/i915: Add support for HDCP 1.4 over MST connectors
On 2020-05-20 at 09:11:38 -0400, Sean Paul wrote: > On Mon, May 18, 2020 at 12:41 PM Ramalingam C wrote: > > > > On 2020-05-18 at 10:32:09 -0400, Sean Paul wrote: > > > On Fri, May 15, 2020 at 10:48 AM Ramalingam C > > > wrote: > > > > > > > > On 2020-04-29 at 15:54:46 -0400, Sean Paul wrote: > > > > > From: Sean Paul > > > > > > > > > > Changes in v6: > > > > > -Rebased on -tip > > > > > -Disabled HDCP over MST on GEN12 > > > > > -Addressed Lyude's review comments in the > > > > > QUERY_STREAM_ENCRYPTION_STATUS patch > > > > > > > > Sean, > > > > > > > > What is the test setup you have used? > > > > > > > > > > Hi Ram, > > > Thanks for the feedback. To be completely honest it's really > > > frustrating that I'm just now getting questions and review feedback > > > (which I've been begging for on IRC) on this review that could have > > > been addressed ~5 months ago. It's super disruptive to have to keep > > > switching back to this after a long hiatus and many i915 refactors > > > complicating my rebases. > > Hi Sean, > > > > As a developer I really feel bad for the delay happened in review. > > I couldn't spend required time for understanding MST part hence I > > couldn't review. > > > > Just for this series now I have started preparing myself on these topics, > > hence started reviewing the series. > > > > If you are still interested to work on this, I can commit for regular > > reviews. > > > > Thanks Ram. I'm still incentivized to get this in. Once you have had a > chance to look over the whole series, I'll revise again. Sean I have already gone through the whole series when I commented before. Most of the prepation patches are looking good. I am having questions on MST HDCP enabling sequence and what is the decision on streams to be encrypted on the MST HDCP link (all/selective) etc. Which were posted on https://patchwork.freedesktop.org/patch/363798/?series=70393&rev=6 And also, could you please explain the level of testing this series has gone through? -Ram > > Sean > > > > > Thanks, > > Ram. > > > > > > If no one wants this patchset, that's fine, please just let me know so > > > I don't waste any more time. If Intel is interested, could we please > > > stop the review trickle and lay out exactly what needs to be done to > > > get this landed? > > > > > > Sean > > > > > > > > > > I am afraid our CI dont have the coverage for MST capability yet to > > > > provide > > > > the functional status of the code. > > > > > > > > -Ram. > > > > > > > > > > Sean Paul (16): > > > > > drm/i915: Fix sha_text population code > > > > > drm/i915: Clear the repeater bit on HDCP disable > > > > > drm/i915: WARN if HDCP signalling is enabled upon disable > > > > > drm/i915: Intercept Aksv writes in the aux hooks > > > > > drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP > > > > > signalling > > > > > drm/i915: Factor out hdcp->value assignments > > > > > drm/i915: Protect workers against disappearing connectors > > > > > drm/i915: Don't fully disable HDCP on a port if multiple pipes are > > > > > using it > > > > > drm/i915: Support DP MST in enc_to_dig_port() function > > > > > drm/i915: Use ddi_update_pipe in intel_dp_mst > > > > > drm/i915: Factor out HDCP shim functions from dp for use by dp_mst > > > > > drm/i915: Plumb port through hdcp init > > > > > drm/i915: Add connector to hdcp_shim->check_link() > > > > > drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband > > > > > message > > > > > drm/i915: Print HDCP version info for all connectors > > > > > drm/i915: Add HDCP 1.4 support for MST connectors > > > > > > > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 142 > > > > > drivers/gpu/drm/i915/Makefile | 1 + > > > > > drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- > > > > > drivers/gpu/drm/i915/display/intel_ddi.h | 2 + > > > > > .../drm/i915/display/intel_display_debugfs.c | 21 +- > > > > > .../drm/i915/display/intel_display_types.h| 30 +- > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 654 +-- > > > > > drivers/gpu/drm/i915/display/intel_dp.h | 9 + > > > > > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 743 > > > > > ++ > > > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 + > > > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 217 +++-- > > > > > drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- > > > > > drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +- > > > > > .../drm/selftests/test-drm_dp_mst_helper.c| 17 + > > > > > include/drm/drm_dp_helper.h | 3 + > > > > > include/drm/drm_dp_mst_helper.h | 44 ++ > > > > > include/drm/drm_hdcp.h| 3 + > > > > > 17 files changed, 1235 insertions(+), 726 deletions(-) > > > > > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c > > > > > > > > > > -- > > > > > Sean P
Re: [PATCH v5 6/8] drm/panel: Add ilitek ili9341 panel driver
Den 26.05.2020 11.08, skrev dillon min: > Hi Andy, > > Thanks for input. > > On Tue, May 26, 2020 at 3:46 PM Andy Shevchenko > wrote: >> >> On Mon, May 25, 2020 at 6:46 AM wrote: >>> >>> From: dillon min >>> >>> This driver combine tiny/ili9341.c mipi_dbi_interface driver >>> with mipi_dpi_interface driver, can support ili9341 with serial >>> mode or parallel rgb interface mode by register configuration. >> >> Noralf told once that this driver should be unified with mi0283qt.c. >> >> So, what should we do here? >> >> -- >> With Best Regards, >> Andy Shevchenko > > from sam's suggestion, we can't setup two drivers to support one panel > in the tree. so, i copy the mipi dbi part from tiny/ili9341.c. to this driver > from register settings and dts binding is keep the same to tiny/ili9341.c. > > so, in my opinion if tiny/ili9341.c is unified with mi0283qt.c, this > driver should be > too. > There's a discussion about MIPI DBI panels here: MIPI DSI, DBI, and tinydrm drivers https://lists.freedesktop.org/archives/dri-devel/2020-May/267031.html Noralf. > thanks. > > best regards, > > Dillon, > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 02/17] dma-fence: basic lockdep annotations
Op 12-05-2020 om 10:59 schreef Daniel Vetter:
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lockdep isn't going to complain if the read-side
> isn't nested the same way under all circumstances, so ABBA deadlocks
> are ok. Which they are, since this is an annotation only.
>
> - We're using non-recursive lockdep read lock mode, since in recursive
> read lock mode lockdep does not catch read side hazards. And we
> _very_ much want read side hazards to be caught. For full details of
> this limitation see
>
> commit e91498589746065e3ae95d9a00b068e525eec34f
> Author: Peter Zijlstra
> Date: Wed Aug 23 13:13:11 2017 +0200
>
> locking/lockdep/selftests: Add mixed read-write ABBA tests
>
> - To allow nesting of the read-side explicit annotations we explicitly
> keep track of the nesting. lock_is_held() allows us to do that.
>
> - The wait-side annotation is a write lock, and entirely done within
> dma_fence_wait() for everyone by default.
>
> - To be able to freely annotate helper functions I want to make it ok
> to call dma_fence_begin/end_signalling from soft/hardirq context.
> First attempt was using the hardirq locking context for the write
> side in lockdep, but this forces all normal spinlocks nested within
> dma_fence_begin/end_signalling to be spinlocks. That bollocks.
>
> The approach now is to simple check in_atomic(), and for these cases
> entirely rely on the might_sleep() check in dma_fence_wait(). That
> will catch any wrong nesting against spinlocks from soft/hardirq
> contexts.
>
> The idea here is that every code path that's critical for eventually
> signalling a dma_fence should be annotated with
> dma_fence_begin/end_signalling. The annotation ideally starts right
> after a dma_fence is published (added to a dma_resv, exposed as a
> sync_file fd, attached to a drm_syncobj fd, or anything else that
> makes the dma_fence visible to other kernel threads), up to and
> including the dma_fence_wait(). Examples are irq handlers, the
> scheduler rt threads, the tail of execbuf (after the corresponding
> fences are visible), any workers that end up signalling dma_fences and
> really anything else. Not annotated should be code paths that only
> complete fences opportunistically as the gpu progresses, like e.g.
> shrinker/eviction code.
>
> The main class of deadlocks this is supposed to catch are:
>
> Thread A:
>
> mutex_lock(A);
> mutex_unlock(A);
>
> dma_fence_signal();
>
> Thread B:
>
> mutex_lock(A);
> dma_fence_wait();
> mutex_unlock(A);
>
> Thread B is blocked on A signalling the fence, but A never gets around
> to that because it cannot acquire the lock A.
>
> Note that dma_fence_wait() is allowed to be nested within
> dma_fence_begin/end_signalling sections. To allow this to happen the
> read lock needs to be upgraded to a write lock, which means that any
> other lock is acquired between the dma_fence_begin_signalling() call and
> the call to dma_fence_wait(), and still held, this will result in an
> immediate lockdep complaint. The only other option would be to not
> annotate such calls, defeating the point. Therefore these annotations
> cannot be sprinkled over the code entirely mindless to avoid false
> positives.
>
> v2: handle soft/hardirq ctx better against write side and dont forget
> EXPORT_SYMBOL, drivers can't use this otherwise.
>
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Christian König
> Signed-off-by: Daniel Vetter
> ---
This is something we definitely need, all drivers need to follow the same
rules, in order to put some light in the darkness. :)
Reviewed-by: Maarten Lankhorst
> drivers/dma-buf/dma-fence.c | 53 +
> include/linux/dma-fence.h | 12 +
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 6802125349fb..d5c0fd2efc70 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num)
> }
> EXPORT_SYMBOL(dma_fence_context_alloc);
>
> +#ifdef CONFIG_LOCKDEP
> +struct lockdep_map dma_fence_lockdep_map = {
> + .name = "dma_fence_map"
> +};
> +
> +bool dma_fence_begin_signalling(void)
> +{
> + /* explicitly nesting ... */
> + if (lock_is_held_type(&dma_fence_lockdep_map, 1))
> + return true;
> +
> + /* rely on might_sleep check for soft/hardirq locks */
> + if (in_atomic())
> + return true;
> +
> + /* ... and non-recursive readlock */
> + lock_acquire(&dma_fence_lockdep
Re: [PATCH 19/27] drm: bridge: dw-hdmi: Split connector creation to a separate function
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Isolate all the code related to connector creation to a new
> dw_hdmi_connector_create() function, to prepare for making connector
> creation optional.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 107 +-
> 1 file changed, 62 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index a18794cce0d8..35d38b644912 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2317,6 +2317,10 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi
> *hdmi)
> hdmi->rxsense);
> }
>
> +/*
> -
> + * DRM Connector Operations
> + */
> +
> static enum drm_connector_status
> dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
> {
> @@ -2438,6 +2442,59 @@ static const struct drm_connector_helper_funcs
> dw_hdmi_connector_helper_funcs =
> .atomic_check = dw_hdmi_connector_atomic_check,
> };
>
> +static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
> +{
> + struct drm_connector *connector = &hdmi->connector;
> + struct cec_connector_info conn_info;
> + struct cec_notifier *notifier;
> +
> + if (hdmi->version >= 0x200a)
> + connector->ycbcr_420_allowed =
> + hdmi->plat_data->ycbcr_420_allowed;
> + else
> + connector->ycbcr_420_allowed = false;
> +
> + connector->interlace_allowed = 1;
> + connector->polled = DRM_CONNECTOR_POLL_HPD;
> +
> + drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
> +
> + drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
> + &dw_hdmi_connector_funcs,
> + DRM_MODE_CONNECTOR_HDMIA,
> + hdmi->ddc);
> +
> + /*
> + * drm_connector_attach_max_bpc_property() requires the
> + * connector to have a state.
> + */
> + drm_atomic_helper_connector_reset(connector);
> +
> + drm_connector_attach_max_bpc_property(connector, 8, 16);
> +
> + if (hdmi->version >= 0x200a && hdmi->plat_data->use_drm_infoframe)
> + drm_object_attach_property(&connector->base,
> +
> connector->dev->mode_config.hdr_output_metadata_property, 0);
> +
> + drm_connector_attach_encoder(connector, hdmi->bridge.encoder);
> +
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> +
> + notifier = cec_notifier_conn_register(hdmi->dev, NULL, &conn_info);
> + if (!notifier)
> + return -ENOMEM;
> +
> + mutex_lock(&hdmi->cec_notifier_mutex);
> + hdmi->cec_notifier = notifier;
> + mutex_unlock(&hdmi->cec_notifier_mutex);
> +
> + return 0;
> +}
> +
> +/*
> -
> + * DRM Bridge Operations
> + */
> +
> /*
> * Possible output formats :
> * - MEDIA_BUS_FMT_UYYVYY16_0_5X48,
> @@ -2713,51 +2770,13 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
> *bridge,
>enum drm_bridge_attach_flags flags)
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
> - struct drm_encoder *encoder = bridge->encoder;
> - struct drm_connector *connector = &hdmi->connector;
> - struct cec_connector_info conn_info;
> - struct cec_notifier *notifier;
>
> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> DRM_ERROR("Fix bridge driver to make connector optional!");
> return -EINVAL;
> }
>
> - connector->interlace_allowed = 1;
> - connector->polled = DRM_CONNECTOR_POLL_HPD;
> -
> - drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
> -
> - drm_connector_init_with_ddc(bridge->dev, connector,
> - &dw_hdmi_connector_funcs,
> - DRM_MODE_CONNECTOR_HDMIA,
> - hdmi->ddc);
> -
> - /*
> - * drm_connector_attach_max_bpc_property() requires the
> - * connector to have a state.
> - */
> - drm_atomic_helper_connector_reset(connector);
> -
> - drm_connector_attach_max_bpc_property(connector, 8, 16);
> -
> - if (hdmi->version >= 0x200a && hdmi->plat_data->use_drm_infoframe)
> - drm_object_attach_property(&connector->base,
> -
> connector->dev->mode_config.hdr_output_metadata_property, 0);
> -
> - drm_connector_attach_encoder(connector, encoder);
> -
> - cec_fill_conn_info_from_drm(&conn_info, connector);
> -
> - notifier = cec_notifier_conn_register(hdmi->dev, NULL, &conn_info);
> - if (!notifier)
> - return -ENOMEM;
> -
> - mutex_lock(&hdmi->cec_notifier_mutex);
> - hdmi->cec_notifier = notif
Re: [PATCH 18/27] drm: bridge: dw-hdmi: Pass drm_display_info to dw_hdmi_support_scdc()
On 26/05/2020 03:14, Laurent Pinchart wrote:
> To prepare for making connector creation optional in the driver, pass
> the drm_display_info explicitly to dw_hdmi_support_scdc(). The pointer
> is passed to the callers where required, particularly to the
> dw_hdmi_phy_ops .init() function.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 32 -
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 3 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 +
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 1 +
> include/drm/bridge/dw_hdmi.h| 4 ++-
> 5 files changed, 26 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 5b5f07a23400..a18794cce0d8 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1241,10 +1241,9 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
> unsigned short data,
> EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>
> /* Filter out invalid setups to avoid configuring SCDC and scrambling */
> -static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi)
> +static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi,
> + const struct drm_display_info *display)
> {
> - struct drm_display_info *display = &hdmi->connector.display_info;
> -
> /* Completely disable SCDC support for older controllers */
> if (hdmi->version < 0x200a)
> return false;
> @@ -1282,12 +1281,13 @@ static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi)
> * helper should called right before enabling the TMDS Clock and Data in
> * the PHY configuration callback.
> */
> -void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi)
> +void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi,
> +const struct drm_display_info *display)
> {
> unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mtmdsclock;
>
> /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
> - if (dw_hdmi_support_scdc(hdmi)) {
> + if (dw_hdmi_support_scdc(hdmi, display)) {
> if (mtmdsclock > HDMI14_MAX_TMDSCLK)
> drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
> else
> @@ -1490,7 +1490,8 @@ static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct
> dw_hdmi *hdmi,
> return 0;
> }
>
> -static int hdmi_phy_configure(struct dw_hdmi *hdmi)
> +static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> + const struct drm_display_info *display)
> {
> const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
> @@ -1500,7 +1501,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>
> dw_hdmi_phy_power_off(hdmi);
>
> - dw_hdmi_set_high_tmds_clock_ratio(hdmi);
> + dw_hdmi_set_high_tmds_clock_ratio(hdmi, display);
>
> /* Leave low power consumption mode by asserting SVSRET. */
> if (phy->has_svsret)
> @@ -1531,6 +1532,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
> }
>
> static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void *data,
> + const struct drm_display_info *display,
> const struct drm_display_mode *mode)
> {
> int i, ret;
> @@ -1540,7 +1542,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
> *data,
> dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
> dw_hdmi_phy_sel_interface_control(hdmi, 0);
>
> - ret = hdmi_phy_configure(hdmi);
> + ret = hdmi_phy_configure(hdmi, display);
> if (ret)
> return ret;
> }
> @@ -1846,10 +1848,11 @@ static void hdmi_config_drm_infoframe(struct dw_hdmi
> *hdmi)
> }
>
> static void hdmi_av_composer(struct dw_hdmi *hdmi,
> + const struct drm_display_info *display,
>const struct drm_display_mode *mode)
> {
> u8 inv_val, bytes;
> - struct drm_hdmi_info *hdmi_info = &hdmi->connector.display_info.hdmi;
> + const struct drm_hdmi_info *hdmi_info = &display->hdmi;
> struct hdmi_vmode *vmode = &hdmi->hdmi_data.video_mode;
> int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
> unsigned int vdisplay, hdisplay;
> @@ -1882,7 +1885,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>
> /* Set up HDMI_FC_INVIDCONF */
> inv_val = (hdmi->hdmi_data.hdcp_enable ||
> -(dw_hdmi_support_scdc(hdmi) &&
> +(dw_hdmi_support_scdc(hdmi, display) &&
> (vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
>hdmi_info->scdc.scrambling.low_rates)) ?
> HDMI_FC_INVIDCONF_HDCP_KEEPOUT_ACTIVE :
> @@ -1950,7 +1953,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
> }
>
> /
Re: [PATCH 17/27] drm: bridge: dw-hdmi: Constify mode argument to internal functions
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Several internal functions take a drm_display_mode argument to configure
> the HDMI encoder or the HDMI PHY. They must not modify the mode, make
> the pointer const to enforce that.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 6e6a3d95e68e..5b5f07a23400 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1628,7 +1628,8 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
> HDMI_A_HDCPCFG1_ENCRYPTIONDISABLE_MASK, HDMI_A_HDCPCFG1);
> }
>
> -static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode
> *mode)
> +static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> + const struct drm_display_mode *mode)
> {
> struct hdmi_avi_infoframe frame;
> u8 val;
> @@ -1756,7 +1757,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> struct drm_display_mode *mode)
> }
>
> static void hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode
> *mode)
> {
> struct hdmi_vendor_infoframe frame;
> u8 buffer[10];
> @@ -2112,7 +2113,8 @@ static void hdmi_disable_overflow_interrupts(struct
> dw_hdmi *hdmi)
> HDMI_IH_MUTE_FC_STAT2);
> }
>
> -static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct drm_display_mode *mode)
> +static int dw_hdmi_setup(struct dw_hdmi *hdmi,
> + const struct drm_display_mode *mode)
> {
> int ret;
>
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/27] drm: bridge: dw-hdmi: Pass drm_display_info to .mode_valid()
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Replace the drm_connector pointer passed to the .mode_valid() function
> with a const drm_display_info pointer, as that's all the function should
> need. Use the display info passed to the bridge .mode_valid() operation
> instead of retrieving it from the connector, to prepare for make
> connector creation optional.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 5 ++---
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 4 ++--
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 20 ++--
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 2 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 4 ++--
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +-
> include/drm/bridge/dw_hdmi.h| 4 ++--
> 8 files changed, 21 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index adc5a95a06e9..23650e69604c 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2769,7 +2769,6 @@ dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
> const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
> - struct drm_connector *connector = &hdmi->connector;
> enum drm_mode_status mode_status = MODE_OK;
>
> /* We don't support double-clocked modes */
> @@ -2777,8 +2776,8 @@ dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
> return MODE_BAD;
>
> if (pdata->mode_valid)
> - mode_status = pdata->mode_valid(hdmi, pdata->priv_data,
> - connector, mode);
> + mode_status = pdata->mode_valid(hdmi, pdata->priv_data, info,
> + mode);
>
> return mode_status;
> }
> diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> index 95aed4666c95..2dc93fa6ecb6 100644
> --- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> +++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> @@ -146,7 +146,7 @@ static const struct drm_encoder_helper_funcs
> dw_hdmi_imx_encoder_helper_funcs =
>
> static enum drm_mode_status
> imx6q_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> - struct drm_connector *con,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> if (mode->clock < 13500)
> @@ -160,7 +160,7 @@ imx6q_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
>
> static enum drm_mode_status
> imx6dl_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> -struct drm_connector *con,
> +const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> if (mode->clock < 13500)
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 34ba94922605..71d599970ec7 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -631,12 +631,12 @@ static irqreturn_t dw_hdmi_top_thread_irq(int irq, void
> *dev_id)
>
> static enum drm_mode_status
> dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> -struct drm_connector *connector,
> +const struct drm_display_info *display_info,
> const struct drm_display_mode *mode)
> {
> struct meson_dw_hdmi *dw_hdmi = data;
> struct meson_drm *priv = dw_hdmi->priv;
> - bool is_hdmi2_sink = connector->display_info.hdmi.scdc.supported;
> + bool is_hdmi2_sink = display_info->hdmi.scdc.supported;
> unsigned int phy_freq;
> unsigned int vclk_freq;
> unsigned int venc_freq;
> @@ -647,10 +647,10 @@ dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> DRM_DEBUG_DRIVER("Modeline " DRM_MODE_FMT "\n", DRM_MODE_ARG(mode));
>
> /* If sink does not support 540MHz, reject the non-420 HDMI2 modes */
> - if (connector->display_info.max_tmds_clock &&
> - mode->clock > connector->display_info.max_tmds_clock &&
> - !drm_mode_is_420_only(&connector->display_info, mode) &&
> - !drm_mode_is_420_also(&connector->display_info, mode))
> + if (display_info->max_tmds_clock &&
> + mode->clock > display_info->max_tmds_clock &&
> + !drm_mode_is_420_only(display_info, mode) &&
> + !drm_mode_is_420_also(display_info, mode))
> return MODE_BAD;
>
> /* Check against non-VIC supported modes */
> @@ -667,9 +667,9 @@ dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> vclk_freq = mode->clock;
>
> /* For 420, pixel clock is half unlike venc clock */
> - if (drm_mode_is_420_only(&connector->display_info, mode) ||
> + if (drm_mode_is_420_only(display_in
Re: [PATCH 16/27] drm: bridge: dw-hdmi: Constify mode argument to dw_hdmi_phy_ops .init()
On 26/05/2020 03:14, Laurent Pinchart wrote:
> The PHY .init() must not modify the mode it receives. Make the pointer
> const to enfore that.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 ++--
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 2 +-
> include/drm/bridge/dw_hdmi.h| 2 +-
> 5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 23650e69604c..6e6a3d95e68e 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1531,7 +1531,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
> }
>
> static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void *data,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
> {
> int i, ret;
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 71d599970ec7..757c17fbb29f 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -297,7 +297,7 @@ static inline void dw_hdmi_dwc_write_bits(struct
> meson_dw_hdmi *dw_hdmi,
>
> /* Setup PHY bandwidth modes */
> static void meson_hdmi_phy_setup_mode(struct meson_dw_hdmi *dw_hdmi,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
> {
> struct meson_drm *priv = dw_hdmi->priv;
> unsigned int pixel_clock = mode->clock;
> @@ -427,7 +427,7 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi
> *dw_hdmi,
> }
>
> static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void *data,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
> {
> struct meson_dw_hdmi *dw_hdmi = (struct meson_dw_hdmi *)data;
> struct meson_drm *priv = dw_hdmi->priv;
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index d286751bb333..10e210f6455d 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -312,7 +312,7 @@ static const struct drm_encoder_helper_funcs
> dw_hdmi_rockchip_encoder_helper_fun
> };
>
> static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi *dw_hdmi, void *data,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
> {
> struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> index 43643ad31730..8e078cacf063 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> @@ -341,7 +341,7 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi *hdmi,
> }
>
> static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void *data,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
> {
> struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
> u32 val = 0;
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index fec293b21c2e..f930d218cc6b 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -114,7 +114,7 @@ struct dw_hdmi_phy_config {
>
> struct dw_hdmi_phy_ops {
> int (*init)(struct dw_hdmi *hdmi, void *data,
> - struct drm_display_mode *mode);
> + const struct drm_display_mode *mode);
> void (*disable)(struct dw_hdmi *hdmi, void *data);
> enum drm_connector_status (*read_hpd)(struct dw_hdmi *hdmi, void *data);
> void (*update_hpd)(struct dw_hdmi *hdmi, void *data,
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/27] drm: bridge: dw-hdmi: Pass private data pointer to .configure_phy()
On 26/05/2020 03:14, Laurent Pinchart wrote:
> The .configure_phy() operation takes a dw_hdmi_plat_data pointer as a
> context argument. This differs from .mode_valid() that takes a custom
> private context pointer, causing possible confusion. Make the
> dw_hdmi_plat_data operations more consistent by passing the private
> context pointer to .configure_phy() as well.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c| 3 +--
> include/drm/bridge/dw_hdmi.h | 3 +--
> 3 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 2b3f203cf467..6edb60e6c784 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1514,7 +1514,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>
> /* Write to the PHY as configured by the platform */
> if (pdata->configure_phy)
> - ret = pdata->configure_phy(hdmi, pdata, mpixelclock);
> + ret = pdata->configure_phy(hdmi, pdata->priv_data, mpixelclock);
> else
> ret = phy->configure(hdmi, pdata, mpixelclock);
> if (ret) {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> index 4d837a4d302d..d0dffe55a7cb 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -52,8 +52,7 @@ rcar_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> return MODE_OK;
> }
>
> -static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
> -const struct dw_hdmi_plat_data *pdata,
> +static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi, void *data,
> unsigned long mpixelclock)
> {
> const struct rcar_hdmi_phy_params *params = rcar_hdmi_phy_params;
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index 66a811f75b91..09348c9cbd11 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -151,8 +151,7 @@ struct dw_hdmi_plat_data {
> const struct dw_hdmi_mpll_config *mpll_cfg;
> const struct dw_hdmi_curr_ctrl *cur_ctr;
> const struct dw_hdmi_phy_config *phy_config;
> - int (*configure_phy)(struct dw_hdmi *hdmi,
> - const struct dw_hdmi_plat_data *pdata,
> + int (*configure_phy)(struct dw_hdmi *hdmi, void *data,
>unsigned long mpixelclock);
> };
>
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/27] drm: bridge: dw-hdmi: Remove unused field from dw_hdmi_plat_data
On 26/05/2020 03:14, Laurent Pinchart wrote:
> The input_bus_format field of struct dw_hdmi_plat_data is unused. Remove
> it.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 5 +
> include/drm/bridge/dw_hdmi.h | 1 -
> 2 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 6edb60e6c784..adc5a95a06e9 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2137,10 +2137,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
> drm_display_mode *mode)
> hdmi->hdmi_data.video_mode.mpixelrepetitionoutput = 0;
> hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0;
>
> - if (hdmi->plat_data->input_bus_format)
> - hdmi->hdmi_data.enc_in_bus_format =
> - hdmi->plat_data->input_bus_format;
> - else if (hdmi->hdmi_data.enc_in_bus_format == MEDIA_BUS_FMT_FIXED)
> + if (hdmi->hdmi_data.enc_in_bus_format == MEDIA_BUS_FMT_FIXED)
> hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>
> /* TOFIX: Get input encoding from plat data or fallback to none */
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index 09348c9cbd11..5dfa9d83e2d3 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -125,7 +125,6 @@ struct dw_hdmi_phy_ops {
> struct dw_hdmi_plat_data {
> struct regmap *regm;
>
> - unsigned long input_bus_format;
> unsigned long input_bus_encoding;
> bool use_drm_infoframe;
> bool ycbcr_420_allowed;
>
Obviously, now meta-meson doesn't need it anymore, thanks for fixing this.
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/27] drm: bridge: dw-hdmi: Pass private data pointer to .mode_valid()
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Platform glue drivers for dw_hdmi may need to access device-specific
> data from their .mode_valid() implementation. They currently have no
> clean way to do so, and one driver hacks around it by accessing the
> dev_private data of the drm_device retrieved from the connector.
>
> Add a priv_data void pointer to the dw_hdmi_plat_data structure, and
> pass it to the .mode_valid() function.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 --
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 6 --
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 3 ++-
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 3 ++-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 3 ++-
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 --
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 3 ++-
> include/drm/bridge/dw_hdmi.h| 14 --
> 8 files changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index b535354150db..2b3f203cf467 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2771,6 +2771,7 @@ dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
> const struct drm_display_mode *mode)
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
> + const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
> struct drm_connector *connector = &hdmi->connector;
> enum drm_mode_status mode_status = MODE_OK;
>
> @@ -2778,8 +2779,9 @@ dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> return MODE_BAD;
>
> - if (hdmi->plat_data->mode_valid)
> - mode_status = hdmi->plat_data->mode_valid(connector, mode);
> + if (pdata->mode_valid)
> + mode_status = pdata->mode_valid(hdmi, pdata->priv_data,
> + connector, mode);
>
> return mode_status;
> }
> diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> index ba4ca17fd4d8..95aed4666c95 100644
> --- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> +++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> @@ -145,7 +145,8 @@ static const struct drm_encoder_helper_funcs
> dw_hdmi_imx_encoder_helper_funcs =
> };
>
> static enum drm_mode_status
> -imx6q_hdmi_mode_valid(struct drm_connector *con,
> +imx6q_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> + struct drm_connector *con,
> const struct drm_display_mode *mode)
> {
> if (mode->clock < 13500)
> @@ -158,7 +159,8 @@ imx6q_hdmi_mode_valid(struct drm_connector *con,
> }
>
> static enum drm_mode_status
> -imx6dl_hdmi_mode_valid(struct drm_connector *con,
> +imx6dl_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> +struct drm_connector *con,
> const struct drm_display_mode *mode)
> {
> if (mode->clock < 13500)
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 5be963e9db05..5cc311c1b8e0 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -630,7 +630,8 @@ static irqreturn_t dw_hdmi_top_thread_irq(int irq, void
> *dev_id)
> }
>
> static enum drm_mode_status
> -dw_hdmi_mode_valid(struct drm_connector *connector,
> +dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> +struct drm_connector *connector,
> const struct drm_display_mode *mode)
> {
> struct meson_drm *priv = connector->dev->dev_private;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> index 452461dc96f2..4d837a4d302d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -38,7 +38,8 @@ static const struct rcar_hdmi_phy_params
> rcar_hdmi_phy_params[] = {
> };
>
> static enum drm_mode_status
> -rcar_hdmi_mode_valid(struct drm_connector *connector,
> +rcar_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> + struct drm_connector *connector,
>const struct drm_display_mode *mode)
> {
> /*
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 121aa8a63a76..d08f86783a28 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -220,7 +220,8 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
> *hdmi)
> }
>
> static enum drm_mode_status
> -dw_hdmi_rockchip_mode_valid(struct drm_connector *connector,
> +dw_hdmi_rockchip_mode_valid(struct dw_hdmi *hdmi, void *data,
> + struct drm_connector *connector,
> const struct drm_display_mode *mode)
Re: [PATCH v5 0/8] Enable ili9341 and l3gd20 on stm32f429-disco
On Mon, 25 May 2020 11:45:40 +0800, dillon.min...@gmail.com wrote: > V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX' > for SPI_SIMPLEX_RX mode on stm32 spi controller. > > V5: > 1 instead of add send dummy data out under SIMPLEX_RX mode, >add flags 'SPI_CONTROLLER_MUST_TX' for stm32 spi driver > 2 bypass 'SPI_CONTROLLER_MUST_TX' and 'SPI_CONTROLLER_MUST_RX' under > 'SPI_3WIRE' mode > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/2] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4 commit: 61367d0b8f5edf5146059ba8b79ce4e4485340b2 [2/2] spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't be coexit with 'SPI_3WIRE' mode commit: aee67fe879e5030a2f5e1d9af3cb5b2a1027e78a All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/8] drm/panel: Add ilitek ili9341 panel driver
On Mon, May 25, 2020 at 6:46 AM wrote: > > From: dillon min > > This driver combine tiny/ili9341.c mipi_dbi_interface driver > with mipi_dpi_interface driver, can support ili9341 with serial > mode or parallel rgb interface mode by register configuration. Noralf told once that this driver should be unified with mi0283qt.c. So, what should we do here? -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically change enumeration list of DRM enumeration property
On Tue, 26 May 2020 10:01:23 +0530 Yogish Kulkarni wrote: > Hi, > > Is it possible to dynamically change enumeration list of DRM enumeration > property ? Motivation behind this question is to understand whether it is > possible to create connector enum property (e.g a property which will list > supported output encodings - like yuv420, yuv422 etc) whose list of > supported enum values could be changed dynamically e.g. based on which sink > is connected. > > I think there is existing EDID connector property whose value changes based > on connected sink. EDID is a BLOB property, I am trying to understand if > this is also possible for ENUM type property. There is > "drm_property_replace_blob" to replace blob but I wasn't able to find any > API which could replace list of supported enums. Alternatively, would it be > good idea to destroy custom enum property created by a driver and create > new enum property with new list of supported enums e.g when there is a > HOTPLUG event. Hi, looking at Weston code, it *might* cope with it. A hotplug event does cause Weston to re-discover all properties of a connector. This is specific to connectors only. The race exists though: userspace might be poking at KMS after you changed the property in the kernel but before userspace handles the hotplug event. You'd have to check that does not cause regressions. I guess for a completely new property, the risk seems low, as userspace does not know to poke at it (risk of using outdated property or value IDs causing unexpected atomic commit failure). Also I'm not aware of any KMS program that would yet attempt blind KMS state save & restore to sanitize the KMS state after dropping and re-gaining DRM master. You'd have to check all other KMS using programs too: every Wayland compositor, Xorg, DRM Vulkan WSI(?), ... Thanks, pq pgpj4PR91PW3k.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: Don't warn hrtimer_forward_now failure.
Commit 3a0709928b172a41 ("drm/vkms: Add vblank events simulated by
hrtimers") introduced ret_overrun variable. And that variable was an
unused-but-set-variable until commit 09ef09b4ab95dc40 ("drm/vkms:
WARN when hrtimer_forward_now fails") added WARN_ON(ret_overrun != 1).
Now, syzbot is hitting this WARN_ON() using a simple reproducer that
does open("/dev/dri/card1") followed by ioctl(DRM_IOCTL_WAIT_VBLANK),
and a debug printk() patch says that syzbot is getting
output->vblank_hrtimer.base->get_time()=93531904774 (which is uptime)
output->period_ns=0
ret_overrun=216994
. I can't understand what "verify the hrtimer_forward_now return" in
that commit wants to say. hrtimer_forward_now() must return, and the
return value of hrtimer_forward_now() is not a boolean. Why comparing
with 1 ? Anyway, this failure is not something that worth crashing the
system. Let's remove the ret_overrun variable and WARN_ON() test.
Link:
https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
Signed-off-by: Tetsuo Handa
Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
Fixes: 09ef09b4ab95dc40 ("drm/vkms: WARN when hrtimer_forward_now fails")
---
drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..cc1811ce6092 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -13,12 +13,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
vblank_hrtimer);
struct drm_crtc *crtc = &output->crtc;
struct vkms_crtc_state *state;
- u64 ret_overrun;
bool ret;
- ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
- output->period_ns);
- WARN_ON(ret_overrun != 1);
+ hrtimer_forward_now(&output->vblank_hrtimer, output->period_ns);
spin_lock(&output->lock);
ret = drm_crtc_handle_vblank(crtc);
--
2.18.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/a6xx: set ubwc config for A640 and A650
This is required for A640 and A650 to be able to share UBWC-compressed
images with other HW such as display, which expect this configuration.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 38 ++-
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 6f335ae179c8..aa004a261277 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -289,6 +289,37 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
gpu_write(gpu, REG_A6XX_RBBM_CLOCK_CNTL, state ? 0x8aa8aa02 : 0);
}
+static void a6xx_set_ubwc_config(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ u32 lower_bit = 2;
+ u32 amsbc = 0;
+ u32 rgb565_predicator = 0;
+ u32 uavflagprd_inv = 0;
+
+ /* a618 is using the hw default values */
+ if (adreno_is_a618(adreno_gpu))
+ return;
+
+ if (adreno_is_a640(adreno_gpu))
+ amsbc = 1;
+
+ if (adreno_is_a650(adreno_gpu)) {
+ /* TODO: get ddr type from bootloader and use 2 for LPDDR4 */
+ lower_bit = 3;
+ amsbc = 1;
+ rgb565_predicator = 1;
+ uavflagprd_inv = 2;
+ }
+
+ gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL,
+ rgb565_predicator << 11 | amsbc << 4 | lower_bit << 1);
+ gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, lower_bit << 1);
+ gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL,
+ uavflagprd_inv >> 4 | lower_bit << 1);
+ gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, lower_bit << 21);
+}
+
static int a6xx_cp_init(struct msm_gpu *gpu)
{
struct msm_ringbuffer *ring = gpu->rb[0];
@@ -478,12 +509,7 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
/* Select CP0 to always count cycles */
gpu_write(gpu, REG_A6XX_CP_PERFCTR_CP_SEL_0, PERF_CP_ALWAYS_COUNT);
- if (adreno_is_a630(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL, 2 << 1);
- gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, 2 << 1);
- gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, 2 << 1);
- gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, 2 << 21);
- }
+ a6xx_set_ubwc_config(gpu);
/* Enable fault detection */
gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL,
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] drm/msm/dpu: add SM8150 to hw catalog
This brings up basic video mode functionality for SM8150 DPU. Command mode
and dual mixer/intf configurations are not working, future patches will
address this. Scaler functionality and multiple planes is also untested.
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 147 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
2 files changed, 149 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 1e64fa08c219..f99622870676 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -90,6 +90,23 @@ static const struct dpu_caps sc7180_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
+static const struct dpu_caps sm8150_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0xb,
+ .max_linewidth = 4096,
+ .qseed_type = DPU_SSPP_SCALER_QSEED3,
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2_5,
+ .ubwc_version = DPU_HW_UBWC_VER_30,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 4096,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .max_hdeci_exp = MAX_HORZ_DECIMATION,
+ .max_vdeci_exp = MAX_VERT_DECIMATION,
+};
+
static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -181,6 +198,39 @@ static const struct dpu_ctl_cfg sc7180_ctl[] = {
},
};
+static const struct dpu_ctl_cfg sm8150_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_SPLIT_DISPLAY)
+ },
+ {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x1200, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_SPLIT_DISPLAY)
+ },
+ {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x1400, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG)
+ },
+ {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x1600, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG)
+ },
+ {
+ .name = "ctl_4", .id = CTL_4,
+ .base = 0x1800, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG)
+ },
+ {
+ .name = "ctl_5", .id = CTL_5,
+ .base = 0x1a00, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG)
+ },
+};
+
/*
* SSPP sub blocks config
*/
@@ -335,6 +385,23 @@ static const struct dpu_lm_cfg sc7180_lm[] = {
&sc7180_lm_sblk, PINGPONG_1, LM_0),
};
+/* SM8150 */
+
+static const struct dpu_lm_cfg sm8150_lm[] = {
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_0, LM_1),
+ LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_1, LM_0),
+ LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_2, LM_3),
+ LM_BLK("lm_3", LM_3, 0x47000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_3, LM_2),
+ LM_BLK("lm_4", LM_4, 0x48000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_4, LM_5),
+ LM_BLK("lm_5", LM_5, 0x49000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_5, LM_4),
+};
+
/*
* PINGPONG sub blocks config
*/
@@ -377,6 +444,15 @@ static struct dpu_pingpong_cfg sc7180_pp[] = {
PP_BLK_TE("pingpong_1", PINGPONG_1, 0x70800),
};
+static const struct dpu_pingpong_cfg sm8150_pp[] = {
+ PP_BLK_TE("pingpong_0", PINGPONG_0, 0x7),
+ PP_BLK_TE("pingpong_1", PINGPONG_1, 0x70800),
+ PP_BLK("pingpong_2", PINGPONG_2, 0x71000),
+ PP_BLK("pingpong_3", PINGPONG_3, 0x71800),
+ PP_BLK("pingpong_4", PINGPONG_4, 0x72000),
+ PP_BLK("pingpong_5", PINGPONG_5, 0x72800),
+};
+
/*
* INTF sub blocks config
*/
@@ -402,6 +478,13 @@ static const struct dpu_intf_cfg sc7180_intf[] = {
INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
};
+static const struct dpu_intf_cfg sm8150_intf[] = {
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SC7180_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
+ INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, INTF_SC7180_MASK),
+ INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, INTF_SC7180_MASK),
+};
+
/*
* VBIF sub blocks config
**
[PATCH 2/8] drm/msm/dpu: update UBWC config for sm8150 and sm8250
Update the UBWC registers to the right values for sm8150 and sm8250.
This removes broken dpu_hw_reset_ubwc, which doesn't work because the
"force blk offset to zero to access beginning of register region" hack is
copied from downstream, where mapped region starts 0x1000 below what is
used in the upstream driver.
Also simplifies the overly complicated change that was introduced in
e4f9bbe9f8beab9a1ce4 to work around dpu_hw_reset_ubwc being broken.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 --
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 8 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 16 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 18 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h| 7 --
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 75 ++-
6 files changed, 42 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1b960d9d1b33..3b48257886c6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1090,12 +1090,6 @@ static void _dpu_encoder_virt_enable_helper(struct
drm_encoder *drm_enc)
return;
}
- if (dpu_enc->cur_master->hw_mdptop &&
- dpu_enc->cur_master->hw_mdptop->ops.reset_ubwc)
- dpu_enc->cur_master->hw_mdptop->ops.reset_ubwc(
- dpu_enc->cur_master->hw_mdptop,
- dpu_kms->catalog);
-
_dpu_encoder_update_vsync_source(dpu_enc, &dpu_enc->disp_info);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 09df7d87dd43..f45f031a3a05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -37,7 +37,9 @@
#define DPU_HW_VER_400 DPU_HW_VER(4, 0, 0) /* sdm845 v1.0 */
#define DPU_HW_VER_401 DPU_HW_VER(4, 0, 1) /* sdm845 v2.0 */
#define DPU_HW_VER_410 DPU_HW_VER(4, 1, 0) /* sdm670 v1.0 */
-#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sdm855 v1.0 */
+#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sm8150 v1.0 */
+#define DPU_HW_VER_501 DPU_HW_VER(5, 0, 1) /* sm8150 v2.0 */
+#define DPU_HW_VER_600 DPU_HW_VER(6, 0, 0) /* sm8250 */
#define DPU_HW_VER_620 DPU_HW_VER(6, 2, 0) /* sc7180 v1.0 */
@@ -65,10 +67,9 @@ enum {
DPU_HW_UBWC_VER_10 = 0x100,
DPU_HW_UBWC_VER_20 = 0x200,
DPU_HW_UBWC_VER_30 = 0x300,
+ DPU_HW_UBWC_VER_40 = 0x400,
};
-#define IS_UBWC_20_SUPPORTED(rev) ((rev) >= DPU_HW_UBWC_VER_20)
-
/**
* MDP TOP BLOCK features
* @DPU_MDP_PANIC_PER_PIPE Panic configuration needs to be be done per pipe
@@ -426,7 +427,6 @@ struct dpu_clk_ctrl_reg {
struct dpu_mdp_cfg {
DPU_HW_BLK_INFO;
u32 highest_bank_bit;
- u32 ubwc_static;
u32 ubwc_swizzle;
struct dpu_clk_ctrl_reg clk_ctrls[DPU_CLK_CTRL_MAX];
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 82c5dbfdabc7..c940b69435e1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -303,11 +303,25 @@ static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe
*ctx,
DPU_REG_WRITE(c, SSPP_FETCH_CONFIG,
DPU_FETCH_CONFIG_RESET_VALUE |
ctx->mdp->highest_bank_bit << 18);
- if (IS_UBWC_20_SUPPORTED(ctx->catalog->caps->ubwc_version)) {
+ switch (ctx->catalog->caps->ubwc_version) {
+ case DPU_HW_UBWC_VER_10:
+ /* TODO: UBWC v1 case */
+ break;
+ case DPU_HW_UBWC_VER_20:
fast_clear = fmt->alpha_enable ? BIT(31) : 0;
DPU_REG_WRITE(c, SSPP_UBWC_STATIC_CTRL,
fast_clear | (ctx->mdp->ubwc_swizzle) |
(ctx->mdp->highest_bank_bit << 4));
+ break;
+ case DPU_HW_UBWC_VER_30:
+ DPU_REG_WRITE(c, SSPP_UBWC_STATIC_CTRL,
+ BIT(30) | (ctx->mdp->ubwc_swizzle) |
+ (ctx->mdp->highest_bank_bit << 4));
+ break;
+ case DPU_HW_UBWC_VER_40:
+ DPU_REG_WRITE(c, SSPP_UBWC_STATIC_CTRL,
+ DPU_FORMAT_IS_YUV(fmt) ? 0 : BIT(30));
+ break;
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
index f9af52ae9f3e..01b76766a9a8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
@@ -8,7 +8,6 @@
#include "dpu_kms.h"
#define SSPP_SPARE0x28
-#define
Re: [PATCH] drm/vkms: Don't warn hrtimer_forward_now failure.
On 2020/05/26 2:00, Daniel Vetter wrote: > Forgot to add: I did run this quickly with vkms as secondary output. > Good fireworks show, but there's an entire army of additional splats > after the first one. The WARN_ON you're removing is only the > messenger, the real bug is probably one of the later backtraces. Or at > least points more clearly at the real bug. > -Daniel > >> >> Debug printk() patch shows that hrtimer_forward_now() can return larger than >> 1. >> What is the reason you are expecting hrtimer_forward_now() to always return >> 1 ? >> >>> >>> If the vkms driver is loaded, and there's nothing else going on, then what >>> I expect to happen is that this virtual hw is entirely off. And in that >>> case, the vblank ioctl should be rejected outright. So there's definitely >>> something fishy going on to begin with. >>> >>> If otoh the virtual hw is somehow on (maybe fbcon gets loaded, no idea), >>> then the vblank wait shouldn't just blow up like this. I see. Another debug printk() patch ( https://syzkaller.appspot.com/text?tag=Patch&x=135f254a10 ) found that [ 86.613767][ T7837] [drm:drm_stub_open] [ 86.621592][ T7837] [drm:drm_open] pid = 7837, minor = 1 [ 86.651632][ T7837] [drm:drm_ioctl] pid=7837, dev=0xe201, auth=1, DRM_IOCTL_WAIT_VBLANK [ 86.663391][ T7837] [drm:drm_calc_timestamping_constants] *ERROR* crtc 32: Can't calculate constants, dotclock = 0! [ 86.679151][ T7837] [drm:drm_calc_timestamping_constants] crtc 32: hwmode: htotal 0, vtotal 0, vdisplay 0 [ 86.688865][ T7837] [drm:drm_calc_timestamping_constants] crtc 32: clock 0 kHz framedur 0 linedur 0 [ 86.688899][ T7837] Starting out->vblank_hrtimer : out->period_ns=0 vblank->framedur_ns=0 [ 86.689348][ T7837] [drm:drm_vblank_enable] enabling vblank on crtc 0, ret: 0 [ 86.706883][ T7837] [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=0, diff=0, hw=0 hw_last=0 [ 86.706962][C1] now=86714983667 interval=0 ret_overrun=17693375 hrtimer_start(&out->vblank_hrtimer, 0, HRTIMER_MODE_REL) from vkms_enable_vblank() is causing immediate vkms_vblank_simulate() callback. The reason of vblank->framedur_ns == 0 is that drm_calc_timestamping_constants() fails to calculate framedur_ns (which is 0 by default) due to mode->crtc_clock <= 0. Thus, somehow initializing mode->crtc_clock > 0 might be able to solve this problem. By the way, if you have an environment that can reproduce this problem, you can test with debug printk() patch above applied. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: MIPI DSI, DBI, and tinydrm drivers
Le lun. 25 mai 2020 à 2:46, Noralf Trønnes a
écrit :
Den 24.05.2020 23.33, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 23:24, Noralf Trønnes
a écrit :
Den 24.05.2020 22.42, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 22:14, Noralf Trønnes
a
écrit :
Den 24.05.2020 21.54, skrev Paul Cercueil:
Hi Noralf,
Le dim. 24 mai 2020 à 19:46, Noralf Trønnes
a
écrit :
Den 24.05.2020 18.13, skrev Paul Cercueil:
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.
I did look at this a few months back:
drm/mipi-dbi: Support panel drivers
https://lists.freedesktop.org/archives/dri-devel/2019-August/228966.html
The problem with DBI is that it has reused other busses which
means we
don't have DBI drivers, we have SPI drivers instead
(6800/8080
is not
avail. as busses in Linux yet). DSI and DPI on the other
hand has
dedicated hw controller drivers not shared with other
subsystems.
I don't think that should be much of a problem. You could
have a
DBI/SPI
bridge, that wraps a SPI device into a DBI host, for
instance. The
panel
drivers would just use the DBI API without having to know
what's
done
behind the scene.
This will be a bridge implemented in software, are we allowed
to have
software devices in the Device Tree? I though it was just
allowed to
describe hardware.
It wouldn't appear in devicetree. If the panel is connected over
SPI,
then DBI is just the protocol it uses.
How do you attach a panel to the DBI device if it doesn't appear
in DT?
When probed from a DBI host controller, the panel's devicetree
binding
would look like this:
&dbi_host {
panel {
compatible = "my,dbi-device";
};
};
When probed from SPI it would appear in DT like this:
&spi {
panel@0 {
reg = <0>;
compatible = "my,dbi-device-spi";
};
};
In that case, the driver would create a SPI-DBI bridge, but that is
an
implementation detail that doesn't belong in devicetree.
You said that you want to turn the tinydrm drivers into regular
drm_panel drivers. If this is a drm_panel driver, who calls
drm_of_find_panel_or_bridge() to make use of it? Or is this drm_panel
driver a full blown DRM driver?
What I had in mind was a generic tinydrm driver that fetched the
drm_panel from devicetree. Which is what you were working on, right?
(btw. tinydrm.ko is gone now, all drivers in tiny/ are regular DRM
drivers)
I'm curious, what kind of device is going to use this? It's a bit
strange to spend so many pins on the display interface and choose DBI
instead of DPI.
I'm not sure the number of pins changes that much between the two, does
it? Here I have 16 pins for command/data, one pin for command/data
signal, and the pixel clock.
DBI has advantages over DPI, e.g. you don't need a separate SPI/I2C to
configure the panel, and data is only transferred when a new frame is
available, which means power savings when displaying still images, or a
variable refresh rate when displayin
[PATCH 3/8] drm/msm/dpu: move some sspp caps to dpu_caps
This isn't something that ever changes between planes, so move it to
dpu_caps struct. Making this change will allow more re-use in the
"SSPP sub blocks config" part of the catalog, in particular when adding
support for SM8150 and SM8250 which have different max_linewidth.
This also sets max_hdeci_exp/max_vdeci_exp to 0 for sc7180, as decimation
is not supported on the newest DPU versions. (note that decimation is not
implemented, so this changes nothing)
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 14 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 24 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 6 ++---
3 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index c567917541e8..496407f1cd08 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -68,6 +68,10 @@ static const struct dpu_caps sdm845_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .max_hdeci_exp = MAX_HORZ_DECIMATION,
+ .max_vdeci_exp = MAX_VERT_DECIMATION,
};
static const struct dpu_caps sc7180_dpu_caps = {
@@ -78,6 +82,8 @@ static const struct dpu_caps sc7180_dpu_caps = {
.ubwc_version = DPU_HW_UBWC_VER_20,
.has_dim_layer = true,
.has_idle_pc = true,
+ .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
static const struct dpu_mdp_cfg sdm845_mdp[] = {
@@ -176,16 +182,9 @@ static const struct dpu_ctl_cfg sc7180_ctl[] = {
*/
/* SSPP common configuration */
-static const struct dpu_sspp_blks_common sdm845_sspp_common = {
- .maxlinewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
- .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
- .maxhdeciexp = MAX_HORZ_DECIMATION,
- .maxvdeciexp = MAX_VERT_DECIMATION,
-};
#define _VIG_SBLK(num, sdma_pri, qseed_ver) \
{ \
- .common = &sdm845_sspp_common, \
.maxdwnscale = MAX_DOWNSCALE_RATIO, \
.maxupscale = MAX_UPSCALE_RATIO, \
.smart_dma_priority = sdma_pri, \
@@ -205,7 +204,6 @@ static const struct dpu_sspp_blks_common sdm845_sspp_common
= {
#define _DMA_SBLK(num, sdma_pri) \
{ \
- .common = &sdm845_sspp_common, \
.maxdwnscale = SSPP_UNITY_SCALE, \
.maxupscale = SSPP_UNITY_SCALE, \
.smart_dma_priority = sdma_pri, \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index f45f031a3a05..7a8d1c6658d2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -290,6 +290,10 @@ struct dpu_qos_lut_tbl {
* @has_dim_layer dim layer feature status
* @has_idle_pcindicate if idle power collapse feature is supported
* @has_3d_merge indicate if 3D merge is supported
+ * @max_linewidth max linewidth for sspp
+ * @pixel_ram_size size of latency hiding and de-tiling buffer in bytes
+ * @max_hdeci_exp max horizontal decimation supported (max is 2^value)
+ * @max_vdeci_exp max vertical decimation supported (max is 2^value)
*/
struct dpu_caps {
u32 max_mixer_width;
@@ -301,22 +305,11 @@ struct dpu_caps {
bool has_dim_layer;
bool has_idle_pc;
bool has_3d_merge;
-};
-
-/**
- * struct dpu_sspp_blks_common : SSPP sub-blocks common configuration
- * @maxwidth: max pixelwidth supported by this pipe
- * @pixel_ram_size: size of latency hiding and de-tiling buffer in bytes
- * @maxhdeciexp: max horizontal decimation supported by this pipe
- * (max is 2^value)
- * @maxvdeciexp: max vertical decimation supported by this pipe
- * (max is 2^value)
- */
-struct dpu_sspp_blks_common {
- u32 maxlinewidth;
+ /* SSPP limits */
+ u32 max_linewidth;
u32 pixel_ram_size;
- u32 maxhdeciexp;
- u32 maxvdeciexp;
+ u32 max_hdeci_exp;
+ u32 max_vdeci_exp;
};
/**
@@ -342,7 +335,6 @@ struct dpu_sspp_blks_common {
* @virt_num_formats: Number of supported formats for virtual planes
*/
struct dpu_sspp_sub_blks {
- const struct dpu_sspp_blks_common *common;
u32 creq_vblank;
u32 danger_vblank;
u32 maxdwnscale;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 3b9c33e694bf..33f6c56f01ed 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -153,7 +153,7 @@ static int _dpu_plane_calc_fill_level(struct drm_plane
*plane,
pdpu = to_dpu_plane(plane);
pstate
Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
Hi Michael, On 01. 04. 20 13:30, Michal Simek wrote: > On 01. 04. 20 12:38, Takashi Iwai wrote: >> On Wed, 01 Apr 2020 12:35:16 +0200, >> Michael Ellerman wrote: >>> >>> Michal Simek writes: On 01. 04. 20 4:07, Michael Ellerman wrote: > Michal Simek writes: >> Hi, >> >> recently we wanted to update xilinx intc driver and we found that >> function >> which we wanted to remove is still wired by ancient Xilinx PowerPC >> platforms. Here is the thread about it. >> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/ >> >> I have been talking about it internally and there is no interest in these >> platforms and it is also orphan for quite a long time. None is really >> running/testing these platforms regularly that's why I think it makes >> sense >> to remove them also with drivers which are specific to this platform. >> >> U-Boot support was removed in 2017 without anybody complain about it >> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed >> >> Based on current ppc/next. >> >> If anyone has any objection about it, please let me know. > > Thanks for taking the time to find all this code and remove it. > > I'm not going to take this series for v5.7, it was posted too close to > the merge window, and doing so wouldn't give people much time to object, > especially given people are distracted at the moment. > > I'm happy to take it for v5.8, assuming there's no major objections. Sure. Just to let you know Christophe Leroy included this patch in his series about ppc405 removal. It should be the same. If you don't want to take that alsa patch I can send it separately and this patch can be taken from his series. I don't really mind but please let me know what way you prefer. >>> >>> It's better to keep it all together, so I'm happy take the alsa patch as >>> well, it's already been acked. >> >> Sure, please go ahead. > > > g8. Can you please take this series? I know that there is v5 from Christophe which has this 1/2 as 1/13. But I need this alsa patch too and I would like to close this because it is around for almost 2 months and none raised a concern about removing just these Xilinx platforms. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/msm/dpu: don't use INTF_INPUT_CTRL feature on sdm845
The INTF_INPUT_CTRL feature is not available on sdm845, so don't set it.
This also adds separate feature bits for INTF (based on downstream) instead
of using CTL feature bit for it, and removes the unnecessary NULL check in
the added bind_pingpong_blk function.
Fixes: 73bfb790ac786ca55fa2786a06f59 ("msm:disp:dpu1: setup display datapath
for SC7180 target")
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 20 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 13
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 9 ++---
3 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 496407f1cd08..1e64fa08c219 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -41,6 +41,10 @@
#define PINGPONG_SDM845_SPLIT_MASK \
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
+#define INTF_SDM845_MASK (0)
+
+#define INTF_SC7180_MASK BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE)
+
#define DEFAULT_PIXEL_RAM_SIZE (50 * 1024)
#define DEFAULT_DPU_LINE_WIDTH 2048
#define DEFAULT_DPU_OUTPUT_LINE_WIDTH 2560
@@ -376,26 +380,26 @@ static struct dpu_pingpong_cfg sc7180_pp[] = {
/*
* INTF sub blocks config
*/
-#define INTF_BLK(_name, _id, _base, _type, _ctrl_id) \
+#define INTF_BLK(_name, _id, _base, _type, _ctrl_id, _features) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0x280, \
- .features = BIT(DPU_CTL_ACTIVE_CFG), \
+ .features = _features, \
.type = _type, \
.controller_id = _ctrl_id, \
.prog_fetch_lines_worst_case = 24 \
}
static const struct dpu_intf_cfg sdm845_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0),
- INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1),
- INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SDM845_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SDM845_MASK),
+ INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, INTF_SDM845_MASK),
+ INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, INTF_SDM845_MASK),
};
static const struct dpu_intf_cfg sc7180_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SC7180_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
};
/*
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 7a8d1c6658d2..31ddb2be9c57 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -175,6 +175,19 @@ enum {
DPU_CTL_MAX
};
+/**
+ * INTF sub-blocks
+ * @DPU_INTF_INPUT_CTRL Supports the setting of pp block from which
+ * pixel data arrives to this INTF
+ * @DPU_INTF_TE INTF block has TE configuration support
+ * @DPU_INTF_MAX
+ */
+enum {
+ DPU_INTF_INPUT_CTRL = 0x1,
+ DPU_INTF_TE,
+ DPU_INTF_MAX
+};
+
/**
* VBIF sub-blocks and features
* @DPU_VBIF_QOS_OTLIMVBIF supports OT Limit
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index efe9a5719c6b..64f556d693dd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -225,14 +225,9 @@ static void dpu_hw_intf_bind_pingpong_blk(
bool enable,
const enum dpu_pingpong pp)
{
- struct dpu_hw_blk_reg_map *c;
+ struct dpu_hw_blk_reg_map *c = &intf->hw;
u32 mux_cfg;
- if (!intf)
- return;
-
- c = &intf->hw;
-
mux_cfg = DPU_REG_READ(c, INTF_MUX);
mux_cfg &= ~0xf;
@@ -280,7 +275,7 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
ops->get_status = dpu_hw_intf_get_status;
ops->enable_timing = dpu_hw_intf_enable_timing_engine;
ops->get_line_count = dpu_hw_intf_get_line_count;
- if (cap & BIT(DPU_CTL_ACTIVE_CFG))
+ if (cap & BIT(DPU_INTF_INPUT_CTRL))
ops->bind_pingpong_blk = dpu_hw_intf_bind_pingpong_blk;
}
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: mmotm 2020-05-25-16-56 uploaded (drm/nouveau)
On 5/25/20 9:23 PM, Dave Airlie wrote: > On Tue, 26 May 2020 at 13:50, Randy Dunlap wrote: >> >> On 5/25/20 4:57 PM, Andrew Morton wrote: >>> The mm-of-the-moment snapshot 2020-05-25-16-56 has been uploaded to >>> >>>http://www.ozlabs.org/~akpm/mmotm/ >>> >>> mmotm-readme.txt says >>> >>> README for mm-of-the-moment: >>> >>> http://www.ozlabs.org/~akpm/mmotm/ >>> >>> This is a snapshot of my -mm patch queue. Uploaded at random hopefully >>> more than once a week. >>> >>> You will need quilt to apply these patches to the latest Linus release (5.x >>> or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in >>> http://ozlabs.org/~akpm/mmotm/series >>> >>> The file broken-out.tar.gz contains two datestamp files: .DATE and >>> .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, >>> followed by the base kernel version against which this patch series is to >>> be applied. >>> >> >> on x86_64: >> >> when CONFIG_DRM_NOUVEAU=y and CONFIG_FB=m: >> >> ld: drivers/gpu/drm/nouveau/nouveau_drm.o: in function `nouveau_drm_probe': >> nouveau_drm.c:(.text+0x1d67): undefined reference to >> `remove_conflicting_pci_framebuffers' > > I've pushed the fix for this to drm-next. > > Ben just used the wrong API. That patch is Acked-by: Randy Dunlap # build-tested thanks. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/msm/dpu: add SM8250 to hw catalog
This brings up basic video mode functionality for SM8250 DPU. Command mode
and dual mixer/intf configurations are not working, future patches will
address this. Scaler functionality and multiple planes is also untested.
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 106 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 3 +
2 files changed, 109 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index f99622870676..711ec1e6a543 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -107,6 +107,21 @@ static const struct dpu_caps sm8150_dpu_caps = {
.max_vdeci_exp = MAX_VERT_DECIMATION,
};
+static const struct dpu_caps sm8250_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0xb,
+ .max_linewidth = 4096,
+ .qseed_type = DPU_SSPP_SCALER_QSEED3, /* TODO: qseed3 lite */
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2_5,
+ .ubwc_version = DPU_HW_UBWC_VER_40,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 4096,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -149,6 +164,33 @@ static const struct dpu_mdp_cfg sc7180_mdp[] = {
},
};
+static const struct dpu_mdp_cfg sm8250_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x45C,
+ .features = 0,
+ .highest_bank_bit = 0x3, /* TODO: 2 for LP_DDR4 */
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+ .reg_off = 0x2AC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG1] = {
+ .reg_off = 0x2B4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG2] = {
+ .reg_off = 0x2BC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG3] = {
+ .reg_off = 0x2C4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+ .reg_off = 0x2AC, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
+ .reg_off = 0x2B4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .reg_off = 0x2BC, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .reg_off = 0x2C4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = {
+ .reg_off = 0x2BC, .bit_off = 20},
+ },
+};
+
/*
* CTL sub blocks config
*/
@@ -519,6 +561,14 @@ static const struct dpu_reg_dma_cfg sm8150_regdma = {
.base = 0x0, .version = 0x00010001, .trigger_sel_off = 0x119c
};
+static const struct dpu_reg_dma_cfg sm8250_regdma = {
+ .base = 0x0,
+ .version = 0x00010002,
+ .trigger_sel_off = 0x119c,
+ .xin_id = 7,
+ .clk_ctrl = DPU_CLK_CTRL_REG_DMA,
+};
+
/*
* PERF data config
*/
@@ -656,6 +706,31 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
},
};
+static const struct dpu_perf_cfg sm8250_perf_data = {
+ .max_bw_low = 1370,
+ .max_bw_high = 1660,
+ .min_core_ib = 480,
+ .min_llcc_ib = 0,
+ .min_dram_ib = 80,
+ .danger_lut_tbl = {0xf, 0x, 0x0},
+ .qos_lut_tbl = {
+ {.nentry = ARRAY_SIZE(sc7180_qos_linear),
+ .entries = sc7180_qos_linear
+ },
+ {.nentry = ARRAY_SIZE(sc7180_qos_macrotile),
+ .entries = sc7180_qos_macrotile
+ },
+ {.nentry = ARRAY_SIZE(sc7180_qos_nrt),
+ .entries = sc7180_qos_nrt
+ },
+ /* TODO: macrotile-qseed is different from macrotile */
+ },
+ .cdp_cfg = {
+ {.rd_enable = 1, .wr_enable = 1},
+ {.rd_enable = 1, .wr_enable = 0}
+ },
+};
+
/*
* Hardware catalog init
*/
@@ -747,11 +822,42 @@ static void sm8150_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
};
}
+/*
+ * sm8250_cfg_init(): populate sm8250 dpu sub-blocks reg offsets
+ * and instance counts.
+ */
+static void sm8250_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
+{
+ *dpu_cfg = (struct dpu_mdss_cfg){
+ .caps = &sm8250_dpu_caps,
+ .mdp_count = ARRAY_SIZE(sm8250_mdp),
+ .mdp = sm8250_mdp,
+ .ctl_count = ARRAY_SIZE(sm8150_ctl),
+ .ctl = sm8150_ctl,
+ /* TODO: sspp qs
[PATCH 6/8] drm/msm/dpu: intf timing path for displayport
Calculate the correct timings for displayport, from downstream driver.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 64f556d693dd..6f0f54588124 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -107,11 +107,6 @@ static void dpu_hw_intf_setup_timing_engine(struct
dpu_hw_intf *ctx,
display_v_end = ((vsync_period - p->v_front_porch) * hsync_period) +
p->hsync_skew - 1;
- if (ctx->cap->type == INTF_EDP || ctx->cap->type == INTF_DP) {
- display_v_start += p->hsync_pulse_width + p->h_back_porch;
- display_v_end -= p->h_front_porch;
- }
-
hsync_start_x = p->h_back_porch + p->hsync_pulse_width;
hsync_end_x = hsync_period - p->h_front_porch - 1;
@@ -144,10 +139,25 @@ static void dpu_hw_intf_setup_timing_engine(struct
dpu_hw_intf *ctx,
hsync_ctl = (hsync_period << 16) | p->hsync_pulse_width;
display_hctl = (hsync_end_x << 16) | hsync_start_x;
+ if (ctx->cap->type == INTF_EDP || ctx->cap->type == INTF_DP) {
+ active_h_start = hsync_start_x;
+ active_h_end = active_h_start + p->xres - 1;
+ active_v_start = display_v_start;
+ active_v_end = active_v_start + (p->yres * hsync_period) - 1;
+
+ display_v_start += p->hsync_pulse_width + p->h_back_porch;
+
+ active_hctl = (active_h_end << 16) | active_h_start;
+ display_hctl = active_hctl;
+ }
+
den_polarity = 0;
if (ctx->cap->type == INTF_HDMI) {
hsync_polarity = p->yres >= 720 ? 0 : 1;
vsync_polarity = p->yres >= 720 ? 0 : 1;
+ } else if (ctx->cap->type == INTF_DP) {
+ hsync_polarity = p->hsync_polarity;
+ vsync_polarity = p->vsync_polarity;
} else {
hsync_polarity = 0;
vsync_polarity = 0;
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 09/13] soc: mediatek: cmdq: add write_s value function
On Mon, 2020-05-25 at 10:39 +0200, Matthias Brugger wrote:
>
> On 25/05/2020 04:27, Dennis-YC Hsieh wrote:
> >
> > On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote:
> >>
> >> On 24/05/2020 19:31, Dennis-YC Hsieh wrote:
> >>> Hi Matthias,
> >>>
> >>> Thanks for your comment.
> >>>
> >>> On Sat, 2020-05-16 at 20:20 +0200, Matthias Brugger wrote:
>
> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> > add write_s function in cmdq helper functions which
> > writes a constant value to address with large dma
> > access support.
> >
> > Signed-off-by: Dennis YC Hsieh
> > Reviewed-by: CK Hu
> > ---
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 26 ++
> > include/linux/soc/mediatek/mtk-cmdq.h | 14 ++
> > 2 files changed, 40 insertions(+)
> >
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index 03c129230cd7..a9ebbabb7439 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -269,6 +269,32 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16
> > high_addr_reg_idx,
> > }
> > EXPORT_SYMBOL(cmdq_pkt_write_s);
> >
> > +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> > + u16 addr_low, u32 value, u32 mask)
> > +{
> > + struct cmdq_instruction inst = { {0} };
> > + int err;
> > +
> > + if (mask != U32_MAX) {
> > + inst.op = CMDQ_CODE_MASK;
> > + inst.mask = ~mask;
> > + err = cmdq_pkt_append_command(pkt, inst);
> > + if (err < 0)
> > + return err;
> > +
> > + inst.op = CMDQ_CODE_WRITE_S_MASK;
> > + } else {
> > + inst.op = CMDQ_CODE_WRITE_S;
> > + }
> > +
> > + inst.sop = high_addr_reg_idx;
>
> Writing u16 value in a 5 bit wide variable?
> >>>
> >>> We need only 5 bits in this case. I'll change high_addr_reg_idx
> >>> parameter to u8.
> >>>
> >>
> >> Ok, please make sure to mask the value, so that it's explicit in the code
> >> that
> >> we only use the lowest 5 bits of high_addr_reg_idx.
> >
> > Is it necessary to mask the value?
> > Since sop already defined as "u8 sop:5;", I thought it is explicit that
> > only use 5 bits and compiler should do the rest jobs.
>
> Yes but it makes the code more explicit if we have a
> inst.sop = high_addr_reg_idx & 0x1f;
>
> What do you think?
The value assign to sop will restrict by hardware spec. Clients call
this function will define constant value and use it as parameter. So I
think we don't worry about client call this api with wrong value.
Regards,
Dennis
>
> Regards,
> Matthias
>
> >
> >
> > Regards,
> > Dennis
> >
> >>
> >> Regards,
> >> Matthias
> >>
>
> > + inst.offset = addr_low;
> > + inst.value = value;
> > +
> > + return cmdq_pkt_append_command(pkt, inst);
> > +}
> > +EXPORT_SYMBOL(cmdq_pkt_write_s_value);
> > +
> > int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> > {
> > struct cmdq_instruction inst = { {0} };
> > diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> > b/include/linux/soc/mediatek/mtk-cmdq.h
> > index 01b4184af310..fec292aac83c 100644
> > --- a/include/linux/soc/mediatek/mtk-cmdq.h
> > +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> > @@ -135,6 +135,20 @@ int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16
> > high_addr_reg_idx, u16 addr_low,
> > int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> > u16 addr_low, u16 src_reg_idx, u32 mask);
> >
> > +/**
> > + * cmdq_pkt_write_s_value() - append write_s command with mask to the
> > CMDQ
> > + * packet which write value to a physical
> > address
> > + * @pkt: the CMDQ packet
> > + * @high_addr_reg_idx: internal regisger ID which contains high
> > address of pa
>
> register
> >>>
> >>> will fix
> >>>
> >>>
> >>> Regards,
> >>> Dennis
> >>>
>
> > + * @addr_low: low address of pa
> > + * @value: the specified target value
> > + * @mask: the specified target mask
> > + *
> > + * Return: 0 for success; else the error code is returned
> > + */
> > +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> > + u16 addr_low, u32 value, u32 mask);
> > +
> > /**
> > * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> > * @pkt: the CMDQ packet
> >
> >>>
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/msm/dpu: set missing flush bits for INTF_2 and INTF_3
This fixes flushing of INTF_2 and INTF_3 on SM8150 and SM8250 hardware.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 831e5f7a9b7f..99afdd66 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -245,30 +245,14 @@ static int dpu_hw_ctl_get_bitmask_intf(struct dpu_hw_ctl
*ctx,
static int dpu_hw_ctl_get_bitmask_intf_v1(struct dpu_hw_ctl *ctx,
u32 *flushbits, enum dpu_intf intf)
{
- switch (intf) {
- case INTF_0:
- case INTF_1:
- *flushbits |= BIT(31);
- break;
- default:
- return 0;
- }
+ *flushbits |= BIT(31);
return 0;
}
static int dpu_hw_ctl_active_get_bitmask_intf(struct dpu_hw_ctl *ctx,
u32 *flushbits, enum dpu_intf intf)
{
- switch (intf) {
- case INTF_0:
- *flushbits |= BIT(0);
- break;
- case INTF_1:
- *flushbits |= BIT(1);
- break;
- default:
- return 0;
- }
+ *flushbits |= BIT(intf - INTF_0);
return 0;
}
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] drm/msm/dpu: use right setup_blend_config for sm8150 and sm8250
All DPU versions starting from 4.0 use the sdm845 version, so check for
that instead of checking each version individually. This chooses the right
function for sm8150 and sm8250.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 37becd43bd54..4b8baf71423f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -152,14 +152,13 @@ static void _setup_mixer_ops(const struct dpu_mdss_cfg *m,
unsigned long features)
{
ops->setup_mixer_out = dpu_hw_lm_setup_out;
- if (IS_SDM845_TARGET(m->hwversion) || IS_SDM670_TARGET(m->hwversion)
- || IS_SC7180_TARGET(m->hwversion))
+ if (m->hwversion >= DPU_HW_VER_400)
ops->setup_blend_config = dpu_hw_lm_setup_blend_config_sdm845;
else
ops->setup_blend_config = dpu_hw_lm_setup_blend_config;
ops->setup_alpha_out = dpu_hw_lm_setup_color3;
ops->setup_border_color = dpu_hw_lm_setup_border_color;
-};
+}
static struct dpu_hw_blk_ops dpu_hw_ops;
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Hi, On Mon, May 11, 2020 at 11:12:05AM +0800, Jian-Hong Pan wrote: > Jian-Hong Pan 於 2020年5月8日 週五 下午2:20寫道： > > > > Maxime Ripard 於 2020年5月8日 週五 上午1:22寫道： > > > > > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote: > > > > Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道： > > > > > > > > > > Hi, > > > > > > > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote: > > > > > > Hi Maxime, > > > > > > > > > > > > Thanks for your V2 patch series! I'm testing it. > > > > > > > > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly > > > > > > and built. > > > > > > System can boot into console text mode, but no graphic UI. > > > > > > > > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]: > > > > > > > > > > > > [5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46 > > > > > > [5.587700] debugfs: Directory 'fef00700.hdmi' with parent > > > > > > 'vc4-hdmi' already present! > > > > > > [5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> > > > > > > fef00700.hdmi mapping ok > > > > > > [5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name! > > > > > > [5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops) > > > > > > [5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46 > > > > > > [5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' > > > > > > already present! > > > > > > [5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> > > > > > > fef05700.hdmi mapping ok > > > > > > [5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name! > > > > > > [5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops) > > > > > > [5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops) > > > > > > [5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops) > > > > > > [5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops) > > > > > > [5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops > > > > > > vc4_crtc_ops) > > > > > > [5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops > > > > > > vc4_crtc_ops) > > > > > > [5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops > > > > > > vc4_crtc_ops) > > > > > > [5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops > > > > > > vc4_crtc_ops) > > > > > > [5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops > > > > > > vc4_crtc_ops) > > > > > > [5.589294] checking generic (3e513000 6d8c00) vs hw (0 > > > > > > ) > > > > > > [5.589297] fb0: switching to vc4drmfb from simple > > > > > > [5.589433] Console: switching to colour dummy device 80x25 > > > > > > [5.589481] [drm] Supports vblank timestamp caching Rev 2 > > > > > > (21.10.2013). > > > > > > [5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on > > > > > > minor 0 > > > > > > [5.601079] [ cut here ] > > > > > > [5.601095] WARNING: CPU: 2 PID: 127 at > > > > > > drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 > > > > > > vc5_hdmi_phy_init+0x7ac/0x2078 > > > > > > [5.601097] Modules linked in: > > > > > > [5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted > > > > > > 5.7.0-rc2-00091-ga181df59a930 #7 > > > > > > [5.601105] Hardware name: Raspberry Pi 4 Model B (DT) > > > > > > [5.601112] Workqueue: events deferred_probe_work_func > > > > > > [5.601116] pstate: 2005 (nzCv daif -PAN -UAO) > > > > > > [5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078 > > > > > > [5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > > > > > [5.601124] sp : 80001217b410 > > > > > > [5.601126] x29: 80001217b410 x28: ec6370f0 > > > > > > [5.601129] x27: f650d400 x26: 8a50 > > > > > > [5.601132] x25: 8000113b4ac0 x24: 2060 > > > > > > [5.601135] x23: 0a50 x22: 0300 > > > > > > [5.601137] x21: 08d9ee20 x20: ec535080 > > > > > > [5.601140] x19: 00010989e7c0 x18: > > > > > > [5.601142] x17: 0001 x16: 5207 > > > > > > [5.601145] x15: 4932ad293c92 x14: 0137 > > > > > > [5.601147] x13: 800010015000 x12: 0001 > > > > > > [5.601150] x11: 0001 x10: > > > > > > [5.601152] x9 : x8 : 800010015038 > > > > > > [5.601154] x7 : 0001 x6 : 80001217b368 > > > > > > [5.601157] x5 : x4 : 004c > > > > > > [5.601159] x3 : x2 : 8000113b4ac0 > > > > > > [5.601162] x1 : 8000120c5f44 x0 : dc8984ff > > > > > > [5.601164] Call trace: > > > > > > [5.601169] vc5_hdmi_phy_init+0x7ac/0x2078 > > > > > > [5.601172] vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > > > > > [5.601176] drm_atomic_helper_commit_modeset_enables+0x224/0x248 > > > > > > [5.601179] vc4_atomic_complete_commit+0x400/0x558 > > > > > > [5.601182] v
Re: [PATCH] drm/vkms: Don't warn hrtimer_forward_now failure.
On 2020/05/26 13:18, Tetsuo Handa wrote:
> due to mode->crtc_clock <= 0. Thus, somehow initializing mode->crtc_clock > 0
> might be able
> to solve this problem.
Well, I came to think that vkms_enable_vblank() should return an error to the
caller
when drm_calc_timestamping_constants() failed...
static int vkms_enable_vblank(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
unsigned int pipe = drm_crtc_index(crtc);
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
drm_calc_timestamping_constants(crtc, &crtc->mode);
hrtimer_init(&out->vblank_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
out->vblank_hrtimer.function = &vkms_vblank_simulate;
out->period_ns = ktime_set(0, vblank->framedur_ns);
hrtimer_start(&out->vblank_hrtimer, out->period_ns, HRTIMER_MODE_REL);
return 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:Re: [PATCH] drm: fix setting of plane_mask in pan_display_atomic() function for linux-4.4
-- 发自我的网易邮箱手机智能版 - Original Message - From: "Daniel Vetter" To: chenxb_99...@126.com Cc: "David Airlie" , linux-ker...@vger.kernel.org, dri-devel@lists.freedesktop.org Sent: Mon, 25 May 2020 16:34:28 +0200 Subject: Re: [PATCH] drm: fix setting of plane_mask in pan_display_atomic() function for linux-4.4 >On Sat, May 23, 2020 at 11:49:07AM +0800, chenxb_99...@126.com wrote: > >From: Xuebing Chen > > >>The provides drm_for_each_plane_mask macro and >>plane_mask is defined as bitmask of plane indices, such as >>1< >in pan_display_atomic() function. > > > >Signed-off->>by: Xuebing Chen >What kernel is this patch against? Latest upstream doesn't have any such >code anymore ... I'm assuming that Ville fixed this in one of his patches, >but I can't find the right one just now. >-Danie This bug is still present in the long-supported versions of kernel 4.4.y, including the latest kernel 4.4.224,see https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/?h=v4.4.224 > >--- > > drivers/gpu/drm/drm_fb_helper.c | 2 +- > >1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/drivers/gpu/drm/drm_fb_helper.c > >b/drivers/gpu/drm/drm_fb_helper.c > >index e449f22..6a9f7ee 100644 >> --- a/drivers/gpu/drm/drm_fb_helper.c > >+++ b/drivers/gpu/drm/drm_fb_helper.c >> @@ -1256,7 +1256,7 @@ retry: > >goto fail; >> > > plane = mode_set->crtc->primary; >> - plane_mask |= drm_plane_index(plane); > >+ plane_mask |= 1 << drm_plane_index(plane); >>plane->old_fb = plane->fb; > > } > > >> -- > >2.7.4 > > >> ___ >> dri-devel mailing list > >dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel -- >Daniel Vetter >Software Engineer, Intel Corporation >http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] Initial SM8150 and SM8250 DPU bringup
These patches bring up SM8150 and SM8250 with basic functionality. Tested with displayport output (single mixer, video mode case). I will send patches later to add support for merge3d and dual DSI configurations, and possibly also patches to fix command mode on these SoCs (note it is also currently broken for SC7180). Jonathan Marek (8): drm/msm/dpu: use right setup_blend_config for sm8150 and sm8250 drm/msm/dpu: update UBWC config for sm8150 and sm8250 drm/msm/dpu: move some sspp caps to dpu_caps drm/msm/dpu: don't use INTF_INPUT_CTRL feature on sdm845 drm/msm/dpu: set missing flush bits for INTF_2 and INTF_3 drm/msm/dpu: intf timing path for displayport drm/msm/dpu: add SM8150 to hw catalog drm/msm/dpu: add SM8250 to hw catalog drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 - .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 287 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 48 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 29 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 16 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 18 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h| 7 - drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 75 ++--- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 6 +- 12 files changed, 363 insertions(+), 156 deletions(-) -- 2.26.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Don't warn hrtimer_forward_now failure.
On 2020/05/26 0:21, Daniel Vetter wrote:
> On Mon, May 25, 2020 at 11:38:49PM +0900, Tetsuo Handa wrote:
>> Commit 3a0709928b172a41 ("drm/vkms: Add vblank events simulated by
>> hrtimers") introduced ret_overrun variable. And that variable was an
>> unused-but-set-variable until commit 09ef09b4ab95dc40 ("drm/vkms:
>> WARN when hrtimer_forward_now fails") added WARN_ON(ret_overrun != 1).
>>
>> Now, syzbot is hitting this WARN_ON() using a simple reproducer that
>> does open("/dev/dri/card1") followed by ioctl(DRM_IOCTL_WAIT_VBLANK),
>> and a debug printk() patch says that syzbot is getting
>>
>>output->vblank_hrtimer.base->get_time()=93531904774 (which is uptime)
>>output->period_ns=0
>>ret_overrun=216994
>>
>> . I can't understand what "verify the hrtimer_forward_now return" in
>> that commit wants to say. hrtimer_forward_now() must return, and the
>> return value of hrtimer_forward_now() is not a boolean. Why comparing
>> with 1 ? Anyway, this failure is not something that worth crashing the
>> system. Let's remove the ret_overrun variable and WARN_ON() test.
>
> Uh we're not crashing the system, it's a warning backtrace.
syzbot uses panic_on_warn=1, and this bug is currently the 8th top crasher.
>
> And we've spent a few months hunting the races here, so just removing that
> check isn't really a good idea. The correct thing to do is figure out why
> we're hitting this. It could be that we're having a missing check
> somewhere, or missing initialization, and that's what syzbot is hitting.
> Removing this check here just papers over the bug.
Here is a reproducer which syzbot is using.
--
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
union drm_wait_vblank arg;
int fd = open("/dev/dri/card1", O_RDONLY);
arg.request.type = 0;
arg.request.sequence = 0x;
arg.request.signal = 0x21;
ioctl(fd, DRM_IOCTL_WAIT_VBLANK, &arg);
return 0;
}
--
Debug printk() patch shows that hrtimer_forward_now() can return larger than 1.
What is the reason you are expecting hrtimer_forward_now() to always return 1 ?
>
> If the vkms driver is loaded, and there's nothing else going on, then what
> I expect to happen is that this virtual hw is entirely off. And in that
> case, the vblank ioctl should be rejected outright. So there's definitely
> something fishy going on to begin with.
>
> If otoh the virtual hw is somehow on (maybe fbcon gets loaded, no idea),
> then the vblank wait shouldn't just blow up like this.
> -Daniel
>
>>
>> Link:
>> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
>> Signed-off-by: Tetsuo Handa
>> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
>> Fixes: 09ef09b4ab95dc40 ("drm/vkms: WARN when hrtimer_forward_now fails")
>> ---
>> drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
>> b/drivers/gpu/drm/vkms/vkms_crtc.c
>> index ac85e17428f8..cc1811ce6092 100644
>> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
>> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
>> @@ -13,12 +13,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
>> hrtimer *timer)
>>vblank_hrtimer);
>> struct drm_crtc *crtc = &output->crtc;
>> struct vkms_crtc_state *state;
>> -u64 ret_overrun;
>> bool ret;
>>
>> -ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
>> - output->period_ns);
>> -WARN_ON(ret_overrun != 1);
>> +hrtimer_forward_now(&output->vblank_hrtimer, output->period_ns);
>>
>> spin_lock(&output->lock);
>> ret = drm_crtc_handle_vblank(crtc);
>> --
>> 2.18.2
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: fbtft: fb_st7789v: make HSD20_IPS numeric and not a string
On 21/05/20, Colin King wrote:
> From: Colin Ian King
>
> Currently HSD20_IPS is defined as "true" and will always result in a
> non-zero result even if it is defined as "false" because it is an array
> and that will never be zero. Fix this by defining it as an integer 1
> rather than a literal string.
>
> Addessses-Coverity: ("Array compared against 0")
> Fixes: f03c9b788472 ("staging: fbtft: fb_st7789v: Initialize the Display")
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/fbtft/fb_st7789v.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/fbtft/fb_st7789v.c
> b/drivers/staging/fbtft/fb_st7789v.c
> index ebc17e05ecd0..3a280cc1892c 100644
> --- a/drivers/staging/fbtft/fb_st7789v.c
> +++ b/drivers/staging/fbtft/fb_st7789v.c
> @@ -24,7 +24,7 @@
> "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
> "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"
>
> -#define HSD20_IPS "true"
> +#define HSD20_IPS 1
>
> /**
> * enum st7789v_command - ST7789V display controller commands
Acked-by: Oliver Graute
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/38] DRM: fix struct sg_table nents vs. orig_nents misuse
Hi On 13.05.2020 15:47, Christoph Hellwig wrote: > I've pushed out a branch with the first three patches here: > > git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper > > Gitweb: > > > http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-sg_table-helper > > and merged it into the dma-mapping for-next tree. Unless someone shouts > the branch should be considered immutable in 24 hours. David & Daniel: could you merge all the DRM related changes on top of the provided branch? Merging those changes separately would take a lots of time because of the dependencies on the sgtable helpers and changes in the DRM core. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 09/11] backlight: pwm_bl: Use 64-bit division function
On Tue, 21 Apr 2020, Guru Das Srinagesh wrote: > Since the PWM framework is switching struct pwm_state.period's datatype > to u64, prepare for this transition by using div_u64 to handle a 64-bit > dividend instead of a straight division operation. > > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Cc: Bartlomiej Zolnierkiewicz > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > > Signed-off-by: Guru Das Srinagesh > Reviewed-by: Daniel Thompson Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
