Message ID | 20210923070701.145377-1-narmstrong@baylibre.com (mailing list archive) |
---|---|
Headers | show |
Series | drm/omap: Add virtual-planes support | expand |
Hi, On 23/09/2021 09:06, Neil Armstrong wrote: > This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. > > This patch series adds virtual-plane support to omapdrm driver to allow the use > of display wider than 2048 pixels. > > In order to do so we introduce the concept of hw_overlay which can then be > dynamically allocated to a plane. When the requested output width exceed what > be supported by one overlay a second is then allocated if possible to handle > display wider then 2048. > > This series replaces an earlier series which was DT based and using statically > allocated resources. > > This implementation is inspired from the work done in msm/disp/mdp5 > driver. Gentle ping, who is supposed reviewing those patches ? Thanks, Neil > > Changes since v4 at [1]: > - rebased on v5.15-rc2 > - adapted to drm_atomic_get_new/old_plane_state() > - tested on Beagle-x15 > - checked for non-regression on Beagle-x15 > - removed unused "state" variable in omap_global_state > > [1] https://lore.kernel.org/all/20181012201703.29065-1-bparrot@ti.com/ > > Benoit Parrot (8): > drm/omap: Add ability to check if requested plane modes can be > supported > drm/omap: Add ovl checking funcs to dispc_ops > drm/omap: introduce omap_hw_overlay > drm/omap: omap_plane: subclass drm_plane_state > drm/omap: Add global state as a private atomic object > drm/omap: dynamically assign hw overlays to planes > drm/omap: add plane_atomic_print_state support > drm/omap: Add a 'right overlay' to plane state > > drivers/gpu/drm/omapdrm/Makefile | 1 + > drivers/gpu/drm/omapdrm/dss/dispc.c | 31 +- > drivers/gpu/drm/omapdrm/dss/dss.h | 5 + > drivers/gpu/drm/omapdrm/omap_drv.c | 189 ++++++++++++- > drivers/gpu/drm/omapdrm/omap_drv.h | 28 ++ > drivers/gpu/drm/omapdrm/omap_fb.c | 33 ++- > drivers/gpu/drm/omapdrm/omap_fb.h | 4 +- > drivers/gpu/drm/omapdrm/omap_overlay.c | 254 +++++++++++++++++ > drivers/gpu/drm/omapdrm/omap_overlay.h | 41 +++ > drivers/gpu/drm/omapdrm/omap_plane.c | 375 +++++++++++++++++++++---- > drivers/gpu/drm/omapdrm/omap_plane.h | 1 + > 11 files changed, 903 insertions(+), 59 deletions(-) > create mode 100644 drivers/gpu/drm/omapdrm/omap_overlay.c > create mode 100644 drivers/gpu/drm/omapdrm/omap_overlay.h >
Hi Neil, On 06/10/2021 11:17, Neil Armstrong wrote: > Hi, > > On 23/09/2021 09:06, Neil Armstrong wrote: >> This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. >> >> This patch series adds virtual-plane support to omapdrm driver to allow the use >> of display wider than 2048 pixels. >> >> In order to do so we introduce the concept of hw_overlay which can then be >> dynamically allocated to a plane. When the requested output width exceed what >> be supported by one overlay a second is then allocated if possible to handle >> display wider then 2048. >> >> This series replaces an earlier series which was DT based and using statically >> allocated resources. >> >> This implementation is inspired from the work done in msm/disp/mdp5 >> driver. > > Gentle ping, who is supposed reviewing those patches ? I think that would be me. I'll try to find time in the nearby future to do the review. Tomi
On 23/09/2021 10:06, Neil Armstrong wrote: > This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. > > This patch series adds virtual-plane support to omapdrm driver to allow the use > of display wider than 2048 pixels. > > In order to do so we introduce the concept of hw_overlay which can then be > dynamically allocated to a plane. When the requested output width exceed what > be supported by one overlay a second is then allocated if possible to handle > display wider then 2048. > > This series replaces an earlier series which was DT based and using statically > allocated resources. > > This implementation is inspired from the work done in msm/disp/mdp5 > driver. > > Changes since v4 at [1]: > - rebased on v5.15-rc2 What is this based on? Doesn't apply to v5.15-rc2, and "error: sha1 information is lacking or useless". Tomi
On 12/10/2021 09:15, Tomi Valkeinen wrote: > On 23/09/2021 10:06, Neil Armstrong wrote: >> This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. >> >> This patch series adds virtual-plane support to omapdrm driver to allow the use >> of display wider than 2048 pixels. >> >> In order to do so we introduce the concept of hw_overlay which can then be >> dynamically allocated to a plane. When the requested output width exceed what >> be supported by one overlay a second is then allocated if possible to handle >> display wider then 2048. >> >> This series replaces an earlier series which was DT based and using statically >> allocated resources. >> >> This implementation is inspired from the work done in msm/disp/mdp5 >> driver. >> >> Changes since v4 at [1]: >> - rebased on v5.15-rc2 > > What is this based on? Doesn't apply to v5.15-rc2, and "error: sha1 information is lacking or useless". Indeed the sha1 info is useless, it's based on v5.15-rc2 on top of "HACK: drm/omap: increase DSS5 max tv pclk to 192MHz" in order to validate on 2k monitors. My bad, I thought it would apply based on this patch, I'll rebase on v5.15-rc2 for v6. Thanks for the review, Neil > > Tomi
On 12/10/2021 11:30, Neil Armstrong wrote: > On 12/10/2021 09:15, Tomi Valkeinen wrote: >> On 23/09/2021 10:06, Neil Armstrong wrote: >>> This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. >>> >>> This patch series adds virtual-plane support to omapdrm driver to allow the use >>> of display wider than 2048 pixels. >>> >>> In order to do so we introduce the concept of hw_overlay which can then be >>> dynamically allocated to a plane. When the requested output width exceed what >>> be supported by one overlay a second is then allocated if possible to handle >>> display wider then 2048. >>> >>> This series replaces an earlier series which was DT based and using statically >>> allocated resources. >>> >>> This implementation is inspired from the work done in msm/disp/mdp5 >>> driver. >>> >>> Changes since v4 at [1]: >>> - rebased on v5.15-rc2 >> >> What is this based on? Doesn't apply to v5.15-rc2, and "error: sha1 information is lacking or useless". > > Indeed the sha1 info is useless, it's based on v5.15-rc2 on top of "HACK: drm/omap: increase DSS5 max tv pclk to 192MHz" > in order to validate on 2k monitors. I'm personally fine with removing the HACK from that, and applying it too. I used the patch for a long time without any issues. However, I never found anyone to confirm that 192MHz is fine (or that it's not fine). Too old HW for finding HW engineers to look at it =). Tomi
Hi, On 12/10/2021 12:36, Tomi Valkeinen wrote: > On 12/10/2021 11:30, Neil Armstrong wrote: >> On 12/10/2021 09:15, Tomi Valkeinen wrote: >>> On 23/09/2021 10:06, Neil Armstrong wrote: >>>> This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. >>>> >>>> This patch series adds virtual-plane support to omapdrm driver to allow the use >>>> of display wider than 2048 pixels. >>>> >>>> In order to do so we introduce the concept of hw_overlay which can then be >>>> dynamically allocated to a plane. When the requested output width exceed what >>>> be supported by one overlay a second is then allocated if possible to handle >>>> display wider then 2048. >>>> >>>> This series replaces an earlier series which was DT based and using statically >>>> allocated resources. >>>> >>>> This implementation is inspired from the work done in msm/disp/mdp5 >>>> driver. >>>> >>>> Changes since v4 at [1]: >>>> - rebased on v5.15-rc2 >>> >>> What is this based on? Doesn't apply to v5.15-rc2, and "error: sha1 information is lacking or useless". >> >> Indeed the sha1 info is useless, it's based on v5.15-rc2 on top of "HACK: drm/omap: increase DSS5 max tv pclk to 192MHz" >> in order to validate on 2k monitors. > > I'm personally fine with removing the HACK from that, and applying it too. I used the patch for a long time without any issues. However, I never found anyone to confirm that 192MHz is fine (or that it's not fine). Too old HW for finding HW engineers to look at it =). Indeed it seems to be applied the TI trees for a long time now, will post it. Thanks, Neil > > Tomi