Re: [PATCH v3 28/43] drm/renesas/rcar-du: Use fbdev-dma
Quoting Thomas Zimmermann (2024-04-19 09:29:21) > Implement fbdev emulation with fbdev-dma. Fbdev-dma now supports > damage handling, which is required by rcar-du. Avoids the overhead of > fbdev-generic's additional shadow buffering. No functional changes. > > Signed-off-by: Thomas Zimmermann > Cc: Laurent Pinchart > Cc: Kieran Bingham As I'm on Cc, I'm fine with this too. Reviewed-by: Kieran Bingham > Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > index dee530e4c8b27..fb719d9aff10d 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > @@ -20,7 +20,7 @@ > > #include > #include > -#include > +#include > #include > #include > #include > @@ -716,7 +716,7 @@ static int rcar_du_probe(struct platform_device *pdev) > > drm_info(>ddev, "Device %s probed\n", dev_name(>dev)); > > - drm_fbdev_generic_setup(>ddev, 32); > + drm_fbdev_dma_setup(>ddev, 32); > > return 0; > > -- > 2.44.0 >
Re: [PATCH 0/2] drm/fourcc.h: Add libcamera to Open Source Waiver
Quoting Jacopo Mondi (2024-03-14 10:12:47) > Hello > > gentle nudge for > > *) libcamera: are we ok being listed here ? I think it's fine ... Acked-by: Kieran Bingham > *) DRM/KMS: is it ok splitting the list of projects in the way I've >done ? > > Thanks >j > > On Wed, Feb 28, 2024 at 11:22:42AM +0100, Jacopo Mondi wrote: > > As suggested by Sima, add libcamera to the list of projects to which the > > Open Source Waiver notice applies. > > > > To maintain the paragraph readable, make a list out of the projects to which > > such notice applies. > > > > Jacopo Mondi (2): > > drm/fourcc.h: List of Open Source Waiver projects > > drm/fourcc.h: Add libcamera to Open Source Waiver > > > > include/uapi/drm/drm_fourcc.h | 12 +--- > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > -- > > 2.43.2 > >
Re: [PATCH] drm/rcar-du: fix comment to rcar_du_group_get()
Quoting Kieran Bingham (2023-09-03 16:23:46)
> Hi Alexandra
>
> Quoting Alexandra Diupina (2023-09-03 14:37:09)
> > rcar_du_group_get() never returns a negative
> > error code (always returns 0), so change
> > the comment about returned value
>
> If so, then perhaps this may as well become a void return and remove the
> return 0.
>
> That could then clean up some redundant error path handling in
> drivers/gpu/drm/renesas/rcar-du/rcar_du_crtc.c too ?
>
> Still, this does correct the documentation to match the implementation
> as it stands so... for that ...
>
> Reviewed-by: Kieran Bingham
Reading Geert's reply here, I'll retract this RB tag, and instead agree
that the emphasis should either be on a full clean up - or that this
does document the intent that if there is an error it will be returned.
--
Kieran
>
> But removing an unused error path seems like a worthy clean up
> opportunity too.
>
> >
> > Fixes: cb2025d2509f ("drm/rcar-du: Introduce CRTCs groups")
>
> Hrm ... well the documented behaviour was the same even before this
> commit in rcar_du_get(), so perhaps it was documenting the intent... But
> it does seem that the return code has been redundant for quite some time
> so perhaps it's just not required.
>
>
> --
> Kieran
>
>
> > Signed-off-by: Alexandra Diupina
> > ---
> > drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> > b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> > index 2ccd2581f544..499d4e56c32d 100644
> > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> > @@ -200,7 +200,7 @@ static void rcar_du_group_setup(struct rcar_du_group
> > *rgrp)
> > *
> > * This function must be called with the DRM mode_config lock held.
> > *
> > - * Return 0 in case of success or a negative error code otherwise.
> > + * Always return 0.
> > */
> > int rcar_du_group_get(struct rcar_du_group *rgrp)
> > {
> > --
> > 2.30.2
> >
Re: [PATCH] drm/rcar-du: fix comment to rcar_du_group_get()
Hi Alexandra
Quoting Alexandra Diupina (2023-09-03 14:37:09)
> rcar_du_group_get() never returns a negative
> error code (always returns 0), so change
> the comment about returned value
If so, then perhaps this may as well become a void return and remove the
return 0.
That could then clean up some redundant error path handling in
drivers/gpu/drm/renesas/rcar-du/rcar_du_crtc.c too ?
Still, this does correct the documentation to match the implementation
as it stands so... for that ...
Reviewed-by: Kieran Bingham
But removing an unused error path seems like a worthy clean up
opportunity too.
>
> Fixes: cb2025d2509f ("drm/rcar-du: Introduce CRTCs groups")
Hrm ... well the documented behaviour was the same even before this
commit in rcar_du_get(), so perhaps it was documenting the intent... But
it does seem that the return code has been redundant for quite some time
so perhaps it's just not required.
--
Kieran
> Signed-off-by: Alexandra Diupina
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> index 2ccd2581f544..499d4e56c32d 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> @@ -200,7 +200,7 @@ static void rcar_du_group_setup(struct rcar_du_group
> *rgrp)
> *
> * This function must be called with the DRM mode_config lock held.
> *
> - * Return 0 in case of success or a negative error code otherwise.
> + * Always return 0.
> */
> int rcar_du_group_get(struct rcar_du_group *rgrp)
> {
> --
> 2.30.2
>
Re: [PATCH] drm: renesas: rcar-du: use proper naming for R-Car
Quoting Wolfram Sang (2023-08-16 11:56:41) > Not RCAR, but R-Car. > Reviewed-by: Kieran Bingham > Signed-off-by: Wolfram Sang > --- > drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h > b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h > index f9893d7d6dfc..e9e59c5e70d5 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h > @@ -16,7 +16,7 @@ struct rcar_du_format_info; > struct rcar_du_group; > > /* > - * The RCAR DU has 8 hardware planes, shared between primary and overlay > planes. > + * The R-Car DU has 8 hardware planes, shared between primary and overlay > planes. > * As using overlay planes requires at least one of the CRTCs being enabled, > no > * more than 7 overlay planes can be available. We thus create 1 primary > plane > * per CRTC and 7 overlay planes, for a total of up to 9 KMS planes. > -- > 2.35.1 >
Re: [PATCH] drm: Explicitly include correct DT includes
Quoting Rob Herring (2023-07-14 18:45:34) > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring > drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 2 +- > drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 2 ++ > drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c | 1 + > drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 1 - > drivers/gpu/drm/renesas/rcar-du/rzg2l_mipi_dsi.c | 1 - For drivers/gpu/drm/renesas/rcar-du/ > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > index 1ffde19cb87f..3904b0cca814 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > @@ -12,7 +12,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c > b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c > index adfb36b0e815..9ff4537c26c8 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c > @@ -20,8 +20,10 @@ > > #include > #include > +#include > #include > #include > +#include > #include > > #include "rcar_du_crtc.h" > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c > b/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c > index 45c05d0ffc70..9cbb5e6e2cba 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c > @@ -22,6 +22,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c > b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c > index e10e4d4b89a2..db2e6f16f954 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c > @@ -12,7 +12,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/renesas/rcar-du/rzg2l_mipi_dsi.c > b/drivers/gpu/drm/renesas/rcar-du/rzg2l_mipi_dsi.c > index aa95b85a2964..8048bdca2d6c 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rzg2l_mipi_dsi.c > +++ b/drivers/gpu/drm/renesas/rcar-du/rzg2l_mipi_dsi.c > @@ -10,7 +10,6 @@ > #include > #include > #include > -#include > #include > #include > #include Reviewed-by: Kieran Bingham
Re: [PATCH] drm: rcar-du: Replace DRM_INFO() with drm_info()
Quoting Laurent Pinchart (2023-05-30 10:26:39)
> drm_info() adds proper context to the kernel log message, as it receives
> the drm_device pointer. It is thus preferred over DRM_INFO(). Replace
> the latter with the former.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> index 91095f9deb8b..fe4d3b3c9b0c 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> @@ -713,7 +713,7 @@ static int rcar_du_probe(struct platform_device *pdev)
> if (ret)
> goto error;
>
> - DRM_INFO("Device %s probed\n", dev_name(>dev));
> + drm_info(>ddev, "Device %s probed\n", dev_name(>dev));
>
> drm_fbdev_generic_setup(>ddev, 32);
>
> --
> Regards,
>
> Laurent Pinchart
>
Re: [PATCH v2] drm: rcar-du: Use dev_err_probe() to record cause of KMS init errors
Quoting Laurent Pinchart (2023-06-04 11:49:58)
> The (large) rcar_du_modeset_init() function can fail for many reasons,
> two of two involving probe deferral. Use dev_err_probe() in those code
> paths to record the cause of the probe deferral, in order to help
> debugging probe issues.
>
> Signed-off-by: Laurent Pinchart
> ---
> Change since v1:
>
> - Fix compilation
Always helps ;-)
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 4
> drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 8 ++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> index 12a8839fe3be..5b752adb1b02 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
> @@ -701,6 +701,10 @@ static int rcar_du_probe(struct platform_device *pdev)
> /* DRM/KMS objects */
> ret = rcar_du_modeset_init(rcdu);
> if (ret < 0) {
> + /*
> +* Don't use dev_err_probe(), as it would overwrite the probe
> +* deferral reason recorded in rcar_du_modeset_init().
> +*/
> if (ret != -EPROBE_DEFER)
> dev_err(>dev,
> "failed to initialize DRM/KMS (%d)\n", ret);
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> index adfb36b0e815..78b665984e35 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> @@ -932,8 +932,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>
> /* Initialize the Color Management Modules. */
> ret = rcar_du_cmm_init(rcdu);
> - if (ret)
> + if (ret) {
> + dev_err_probe(rcdu->dev, ret, "failed to initialize CMM\n");
This could remain a single line return statement with:
return dev_err_probe(rcdu->dev, ret, "failed to initialize
CMM\n");
Or if you're really concerned about 80 chars:
return dev_err_probe(rcdu->dev, ret,
"failed to initialize CMM\n");
which is still one line cheaper than adding braces to the if statement!
Anyway, either way is functional so:
Reviewed-by: Kieran Bingham
> return ret;
> + }
>
> /* Create the CRTCs. */
> for (swindex = 0, hwindex = 0; swindex < rcdu->num_crtcs; ++hwindex) {
> @@ -952,8 +954,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>
> /* Initialize the encoders. */
> ret = rcar_du_encoders_init(rcdu);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_err_probe(rcdu->dev, ret, "failed to initialize
> encoders\n");
(same here of course)
> return ret;
> + }
>
> if (ret == 0) {
> dev_err(rcdu->dev, "error: no encoder could be
> initialized\n");
> --
> Regards,
>
> Laurent Pinchart
>
Re: [PATCH v2] drm: Switch i2c drivers back to use .probe()
Quoting Uwe Kleine-König (2023-05-26 10:07:09)
> After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type"), all drivers being converted to .probe_new() and then
> 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
> back to (the new) .probe() to be able to eventually drop .probe_new() from
> struct i2c_driver.
>
> Signed-off-by: Uwe Kleine-König
> ---
> Hello,
>
> I didn't get feedback for (implicit) v1 that was sent with Message-Id:
> <20230427175954.666464-1-u.kleine-koe...@pengutronix.de>. This is a
> rebase on v6.4-rc1 as the former patch doesn't apply cleanly any more.
>
> I also added more people to Cc, maybe that helps to get feedback.
Having been invovled in b8a1a4cd5a98 ("i2c: Provide a temporary
.probe_new() call-back type") and definitley expected 'temporary' to
mean less than 7 years, I very much approve of this patchset.
Thank you for all your efforts Uwe.
Reviewed-by: Kieran Bingham
> This patch is based on v6.4-rc1, and applies fine on today's next.
> (There are also no new drivers that need adaption in next.)
>
> Thanks for considering,
> Uwe
>
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 +-
> drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
> drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +-
> drivers/gpu/drm/bridge/chrontel-ch7033.c | 2 +-
> drivers/gpu/drm/bridge/cros-ec-anx7688.c | 2 +-
> drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
> drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9211.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
> drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++--
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/sii9234.c | 2 +-
> drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
> drivers/gpu/drm/bridge/tc358767.c| 2 +-
> drivers/gpu/drm/bridge/tc358768.c| 2 +-
> drivers/gpu/drm/bridge/tc358775.c| 2 +-
> drivers/gpu/drm/bridge/ti-dlpc3433.c | 2 +-
> drivers/gpu/drm/bridge/ti-sn65dsi83.c| 2 +-
> drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> drivers/gpu/drm/i2c/tda9950.c| 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
> drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 2 +-
> drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c| 2 +-
> drivers/gpu/drm/solomon/ssd130x-i2c.c| 2 +-
> 32 files changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index ddceafa7b637..2254457ab5d0 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -1393,7 +1393,7 @@ static struct i2c_driver adv7511_driver = {
> .of_match_table = adv7511_of_ids,
> },
> .id_table = adv7511_i2c_ids,
> - .probe_new = adv7511_probe,
> + .probe = adv7511_probe,
> .remove = adv7511_remove,
> };
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 3577c532abb4..72ab2ab77081 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -815,7 +815,7 @@ static struct i2c_driver anx6345_driver = {
>.name = "anx6345",
>.of_match_table = of_match_ptr(anx6345_match_table),
> },
> - .probe_new = anx6345_i2c_probe,
> + .probe = anx6345_i2c_probe,
> .remove = anx6345_i2c_remove,
> .id_table = anx6345_id,
> };
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index a3a38bbe2786..06a3e3243e19
Re: [PATCH v8 1/5] drm: Place Renesas drivers in a separate dir
Quoting Biju Das (2023-04-24 17:10:20) > Create vendor specific renesas directory and move renesas drivers > to that directory. > > Signed-off-by: Biju Das Acked-by: Kieran Bingham
Re: [PATCH 02/11] drm: rcar-du: remove R-Car H3 ES1.* workarounds
Hi Wolfram,
Quoting Wolfram Sang (2023-03-07 16:30:30)
> R-Car H3 ES1.* was only available to an internal development group and
> needed a lot of quirks and workarounds. These become a maintenance
> burden now, so our development group decided to remove upstream support
> and disable booting for this SoC. Public users only have ES2 onwards.
>
> Signed-off-by: Wolfram Sang
Wow, this lets us get rid of workarounds all throughout.
This looks pretty decisive, and complete to me.
Reviewed-by: Kieran Bingham
> ---
> Please apply individually per subsystem. There are no dependencies and the SoC
> doesn't boot anymore since v6.3-rc1.
>
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 37 ++--
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 48 --
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 --
> drivers/gpu/drm/rcar-du/rcar_du_regs.h | 3 +-
> 4 files changed, 4 insertions(+), 86 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 008e172ed43b..84411c452e30 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -223,20 +223,6 @@ static void rcar_du_crtc_set_display_timing(struct
> rcar_du_crtc *rcrtc)
> * DU channels that have a display PLL can't use the internal
> * system clock, and have no internal clock divider.
> */
> -
> - /*
> -* The H3 ES1.x exhibits dot clock duty cycle stability
> issues.
> -* We can work around them by configuring the DPLL to twice
> the
> -* desired frequency, coupled with a /2 post-divider. Restrict
> -* the workaround to H3 ES1.x as ES2.0 and all other SoCs have
> -* no post-divider when a display PLL is present (as shown by
> -* the workaround breaking HDMI output on M3-W during
> testing).
> -*/
> - if (rcdu->info->quirks & RCAR_DU_QUIRK_H3_ES1_PCLK_STABILITY)
> {
> - target *= 2;
> - div = 1;
> - }
> -
> extclk = clk_get_rate(rcrtc->extclock);
> rcar_du_dpll_divider(rcrtc, , extclk, target);
>
> @@ -245,30 +231,13 @@ static void rcar_du_crtc_set_display_timing(struct
> rcar_du_crtc *rcrtc)
>| DPLLCR_N(dpll.n) | DPLLCR_M(dpll.m)
>| DPLLCR_STBY;
>
> - if (rcrtc->index == 1) {
> + if (rcrtc->index == 1)
> dpllcr |= DPLLCR_PLCS1
>| DPLLCR_INCS_DOTCLKIN1;
> - } else {
> - dpllcr |= DPLLCR_PLCS0_PLL
> + else
> + dpllcr |= DPLLCR_PLCS0
>| DPLLCR_INCS_DOTCLKIN0;
>
> - /*
> -* On ES2.x we have a single mux controlled via bit
> 21,
> -* which selects between DCLKIN source (bit 21 = 0)
> and
> -* a PLL source (bit 21 = 1), where the PLL is always
> -* PLL1.
> -*
> -* On ES1.x we have an additional mux, controlled
> -* via bit 20, for choosing between PLL0 (bit 20 = 0)
> -* and PLL1 (bit 20 = 1). We always want to use PLL1,
> -* so on ES1.x, in addition to setting bit 21, we need
> -* to set the bit 20.
> -*/
> -
> - if (rcdu->info->quirks & RCAR_DU_QUIRK_H3_ES1_PLL)
> - dpllcr |= DPLLCR_PLCS0_H3ES1X_PLL1;
> - }
> -
> rcar_du_group_write(rcrtc->group, DPLLCR, dpllcr);
>
> escr = ESCR_DCLKSEL_DCLKIN | div;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index b9a94c5260e9..1ffde19cb87f 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -16,7 +16,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #include
> @@ -387,43 +386,6 @@ static const struct rcar_du_device_info
> rcar_du_r8a7795_info = {
> .dpll_mask = BIT(2) | BIT(1),
> };
>
> -static const struct rcar_du_device_info rcar_du_r8a7795_es1_info = {
> - .gen = 3,
> - .features = RCAR_DU_FEATURE_CRTC_IRQ
> - | RCAR_DU_FEATURE_CRTC_CLOCK
> - | RCAR_DU
Re: [PATCH] drm: rcar-du: Fix a NULL vs IS_ERR() bug
Quoting Dan Carpenter (2023-02-27 10:06:59)
> The drmm_encoder_alloc() function returns error pointers. It never
> returns NULL. Fix the check accordingly.
Yes, indeed. Thanks.
Reviewed-by: Kieran Bingham
>
> Fixes: 7a1adbd23990 ("drm: rcar-du: Use drmm_encoder_alloc() to manage
> encoder")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index b1787be31e92..7ecec7b04a8d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -109,8 +109,8 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> renc = drmm_encoder_alloc(>ddev, struct rcar_du_encoder, base,
> _du_encoder_funcs,
> DRM_MODE_ENCODER_NONE,
> NULL);
> - if (!renc)
> - return -ENOMEM;
> + if (IS_ERR(renc))
> + return PTR_ERR(renc);
>
> renc->output = output;
>
> --
> 2.39.1
>
Re: [PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4
Quoting Tomi Valkeinen (2022-12-19 14:01:38)
> V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
s/Bumb/bump/
Reviewed-by: Kieran Bingham
> rcar_du_r8a779a0_info.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 46c60a2d710d..c7c5217cfc1a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -504,7 +504,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7799x_info = {
> };
>
> static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
> - .gen = 3,
> + .gen = 4,
> .features = RCAR_DU_FEATURE_CRTC_IRQ
> | RCAR_DU_FEATURE_VSP1_SOURCE
> | RCAR_DU_FEATURE_NO_BLENDING,
> --
> 2.34.1
>
Re: [PATCH v5 7/7] drm: rcar-du: dsi: Add r8A779g0 support
Quoting Tomi Valkeinen (2022-12-01 09:56:31)
> Add DSI support for r8a779g0. The main differences to r8a779a0 are in
> the PLL and PHTW setups.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Laurent Pinchart
Now that the differences I saw about the PHTW values are understood, I'm
happy.
I like the MHZ() macro for readability too.
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 497 ++-
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 6 +-
> 2 files changed, 375 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> index a7f2b7f66a17..e10e4d4b89a2 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -28,6 +29,31 @@
> #include "rcar_mipi_dsi.h"
> #include "rcar_mipi_dsi_regs.h"
>
> +#define MHZ(v) ((u32)((v) * 100U))
> +
> +enum rcar_mipi_dsi_hw_model {
> + RCAR_DSI_V3U,
> + RCAR_DSI_V4H,
> +};
> +
> +struct rcar_mipi_dsi_device_info {
> + enum rcar_mipi_dsi_hw_model model;
> +
> + const struct dsi_clk_config *clk_cfg;
> +
> + u8 clockset2_m_offset;
> +
> + u8 n_min;
> + u8 n_max;
> + u8 n_mul;
> + unsigned long fpfd_min;
> + unsigned long fpfd_max;
> + u16 m_min;
> + u16 m_max;
> + unsigned long fout_min;
> + unsigned long fout_max;
> +};
> +
> struct rcar_mipi_dsi {
> struct device *dev;
> const struct rcar_mipi_dsi_device_info *info;
> @@ -50,6 +76,17 @@ struct rcar_mipi_dsi {
> unsigned int lanes;
> };
>
> +struct dsi_setup_info {
> + unsigned long hsfreq;
> + u16 hsfreqrange;
> +
> + unsigned long fout;
> + u16 m;
> + u16 n;
> + u16 vclk_divider;
> + const struct dsi_clk_config *clkset;
> +};
> +
> static inline struct rcar_mipi_dsi *
> bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge)
> {
> @@ -62,65 +99,78 @@ host_to_rcar_mipi_dsi(struct mipi_dsi_host *host)
> return container_of(host, struct rcar_mipi_dsi, host);
> }
>
> -static const u32 phtw[] = {
> - 0x01020114, 0x01600115, /* General testing */
> - 0x01030116, 0x0102011d, /* General testing */
> - 0x011101a4, 0x018601a4, /* 1Gbps testing */
> - 0x014201a0, 0x010001a3, /* 1Gbps testing */
> - 0x0101011f, /* 1Gbps testing */
> -};
> -
> -static const u32 phtw2[] = {
> - 0x010c0130, 0x010c0140, /* General testing */
> - 0x010c0150, 0x010c0180, /* General testing */
> - 0x010c0190,
> - 0x010a0160, 0x010a0170,
> - 0x01800164, 0x01800174, /* 1Gbps testing */
> -};
> -
> static const u32 hsfreqrange_table[][2] = {
> - { 8000U, 0x00 }, { 9000U, 0x10 }, { 1U, 0x20 },
> - { 11000U, 0x30 }, { 12000U, 0x01 }, { 13000U, 0x11 },
> - { 14000U, 0x21 }, { 15000U, 0x31 }, { 16000U, 0x02 },
> - { 17000U, 0x12 }, { 18000U, 0x22 }, { 19000U, 0x32 },
> - { 20500U, 0x03 }, { 22000U, 0x13 }, { 23500U, 0x23 },
> - { 25000U, 0x33 }, { 27500U, 0x04 }, { 3U, 0x14 },
> - { 32500U, 0x25 }, { 35000U, 0x35 }, { 4U, 0x05 },
> - { 45000U, 0x16 }, { 5U, 0x26 }, { 55000U, 0x37 },
> - { 6U, 0x07 }, { 65000U, 0x18 }, { 7U, 0x28 },
> - { 75000U, 0x39 }, { 8U, 0x09 }, { 85000U, 0x19 },
> - { 9U, 0x29 }, { 95000U, 0x3a }, { 10U, 0x0a },
> - { 105000U, 0x1a }, { 11U, 0x2a }, { 115000U, 0x3b },
> - { 12U, 0x0b }, { 125000U, 0x1b }, { 13U, 0x2b },
> - { 135000U, 0x3c }, { 14U, 0x0c }, { 145000U, 0x1c },
> - { 15U, 0x2c }, { 155000U, 0x3d }, { 16U, 0x0d },
> - { 165000U, 0x1d }, { 17U, 0x2e }, { 175000U, 0x3e },
> - { 18U, 0x0e }, { 185000U, 0x1e }, { 19U, 0x2f },
> - { 195000U, 0x3f }, { 20U, 0x0f }, { 205000U, 0x40 },
> - { 21U, 0x41 }, { 215000U, 0x42 }, { 22U, 0x43 },
> - { 225000U, 0x44 }, { 23U, 0x45 }, { 235000U, 0x46 },
> - { 24U, 0x47 }, { 245000U, 0x48 }, { 25U, 0x49 },
> + { MHZ(80), 0x00 }, { MHZ(90), 0x10 }, { MHZ(100), 0x20 },
> + { MHZ(110)
Re: [PATCH v1 7/8] drm: rcar-du: dsi: Add r8A779g0 support
Quoting Tomi Valkeinen (2022-11-17 15:49:36) > On 17/11/2022 17:46, Kieran Bingham wrote: > >> + if (ret) > >> + return ret; > >> + > >> + if (setup_info->hsfreq <= MHZ(1000)) > >> + ret = WRITE_PHTW(0x01020100, 0x01910170, 0x01020171, > >> +0x01110172); > > The <=1Gbps reads: > > > > <=1Gbps > > > > Set PHTW=H’01020100 > > Set PHTW=H’01010172 > > Set PHTW=H’01570170 > > Set PHTW=H’01060171 > > Set PHTW=H’01110172 > > > > Is it clear why theres a difference here? > > What doc is that? Mine (R19UH0172EJ0054 Rev.0.54) says: Hrm ... mine is R19UH0172EJ0051 ... So I guess I'm on an outdated datasheet. Which leaves me pondering if I should just wave my hand over my eyes and add a tag ... (Or see if I can dig up the later datasheet) ;-) -- Kieran > > Set PHTW=H’01020100 > Set PHTW=H’01910170 > Set PHTW=H’01020171 > Set PHTW=H’01110172 > > Tomi >
Re: [PATCH v1 7/8] drm: rcar-du: dsi: Add r8A779g0 support
Quoting Tomi Valkeinen (2022-11-17 12:25:46)
> From: Tomi Valkeinen
>
> Add DSI support for r8a779g0. The main differences to r8a779a0 are in
> the PLL and PHTW setups.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 484 +++
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 6 +-
> 2 files changed, 384 insertions(+), 106 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> index a7f2b7f66a17..723c35726c38 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -28,6 +29,20 @@
> #include "rcar_mipi_dsi.h"
> #include "rcar_mipi_dsi_regs.h"
>
> +#define MHZ(v) ((v) * 100u)
> +
> +enum rcar_mipi_dsi_hw_model {
> + RCAR_DSI_R8A779A0,
> + RCAR_DSI_R8A779G0,
> +};
> +
> +struct rcar_mipi_dsi_device_info {
> + enum rcar_mipi_dsi_hw_model model;
> + const struct dsi_clk_config *clk_cfg;
> + u8 clockset2_m_offset;
> + u8 clockset2_n_offset;
> +};
> +
> struct rcar_mipi_dsi {
> struct device *dev;
> const struct rcar_mipi_dsi_device_info *info;
> @@ -50,6 +65,17 @@ struct rcar_mipi_dsi {
> unsigned int lanes;
> };
>
> +struct dsi_setup_info {
> + unsigned long hsfreq;
> + u16 hsfreqrange;
> +
> + unsigned long fout;
> + u16 m;
> + u16 n;
> + u16 vclk_divider;
> + const struct dsi_clk_config *clkset;
> +};
> +
> static inline struct rcar_mipi_dsi *
> bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge)
> {
> @@ -62,22 +88,6 @@ host_to_rcar_mipi_dsi(struct mipi_dsi_host *host)
> return container_of(host, struct rcar_mipi_dsi, host);
> }
>
> -static const u32 phtw[] = {
> - 0x01020114, 0x01600115, /* General testing */
> - 0x01030116, 0x0102011d, /* General testing */
> - 0x011101a4, 0x018601a4, /* 1Gbps testing */
> - 0x014201a0, 0x010001a3, /* 1Gbps testing */
> - 0x0101011f, /* 1Gbps testing */
> -};
> -
> -static const u32 phtw2[] = {
> - 0x010c0130, 0x010c0140, /* General testing */
> - 0x010c0150, 0x010c0180, /* General testing */
> - 0x010c0190,
> - 0x010a0160, 0x010a0170,
> - 0x01800164, 0x01800174, /* 1Gbps testing */
> -};
> -
> static const u32 hsfreqrange_table[][2] = {
> { 8000U, 0x00 }, { 9000U, 0x10 }, { 1U, 0x20 },
> { 11000U, 0x30 }, { 12000U, 0x01 }, { 13000U, 0x11 },
> @@ -103,24 +113,53 @@ static const u32 hsfreqrange_table[][2] = {
> { /* sentinel */ },
> };
>
> -struct vco_cntrl_value {
> +struct dsi_clk_config {
> u32 min_freq;
> u32 max_freq;
> - u16 value;
> + u8 vco_cntrl;
> + u8 cpbias_cntrl;
> + u8 gmp_cntrl;
> + u8 int_cntrl;
> + u8 prop_cntrl;
> };
>
> -static const struct vco_cntrl_value vco_cntrl_table[] = {
> - { .min_freq = 4000U, .max_freq = 5500U, .value = 0x3f },
> - { .min_freq = 5250U, .max_freq = 8000U, .value = 0x39 },
> - { .min_freq = 8000U, .max_freq = 11000U, .value = 0x2f },
> - { .min_freq = 10500U, .max_freq = 16000U, .value = 0x29 },
> - { .min_freq = 16000U, .max_freq = 22000U, .value = 0x1f },
> - { .min_freq = 21000U, .max_freq = 32000U, .value = 0x19 },
> - { .min_freq = 32000U, .max_freq = 44000U, .value = 0x0f },
> - { .min_freq = 42000U, .max_freq = 66000U, .value = 0x09 },
> - { .min_freq = 63000U, .max_freq = 114900U, .value = 0x03 },
> - { .min_freq = 11U, .max_freq = 115200U, .value = 0x01 },
> - { .min_freq = 115000U, .max_freq = 125000U, .value = 0x01 },
> +static const struct dsi_clk_config dsi_clk_cfg_r8a779a0[] = {
> + { 4000u, 5500u, 0x3f, 0x10, 0x01, 0x00, 0x0b },
> + { 5250u, 8000u, 0x39, 0x10, 0x01, 0x00, 0x0b },
> + { 8000u, 11000u, 0x2f, 0x10, 0x01, 0x00, 0x0b },
> + { 10500u, 16000u, 0x29, 0x10, 0x01, 0x00, 0x0b },
> + { 16000u, 22000u, 0x1f, 0x10, 0x01, 0x00, 0x0b },
> + { 21000u, 32000u, 0x19, 0x10, 0x01, 0x00, 0x0b },
> + { 32000u, 44000u, 0x0f, 0x10, 0x01, 0x00, 0x0b },
> + { 42000u, 66000u, 0x09, 0x10, 0x01, 0x00, 0x0b },
> + { 63000u, 114900u, 0x03, 0x10, 0x01, 0x00, 0x0b },
> + { 11u, 115200u, 0x01, 0x10, 0x01, 0x00, 0x0b },
> + { 115000u, 125000u, 0x01, 0x10, 0x01, 0x00, 0x0c },
Sigh ... is it this one 0x0c value that means we need to keep all these
entries repeated ? :-S
If it weren't for that, it seems we could keep just two sets of
> + u8 cpbias_cntrl;
> + u8 gmp_cntrl;
> +
Re: [PATCH v1 6/8] drm: rcar-du: Add r8a779g0 support
Quoting Tomi Valkeinen (2022-11-17 12:25:45)
> From: Tomi Valkeinen
>
> Add support for DU on r8a779g0, which is identical to DU on r8a779a0.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index d003e8d9e7a2..b1761d4ec4e5 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -524,6 +524,27 @@ static const struct rcar_du_device_info
> rcar_du_r8a779a0_info = {
> .dsi_clk_mask = BIT(1) | BIT(0),
> };
>
> +static const struct rcar_du_device_info rcar_du_r8a779g0_info = {
> + .gen = 3,
Given that this is the V4H ... I wonder if this should be bumped
already. I guess that has knock on effects through the driver though...
Aside from that, Which may need more work to handle correctly:
Reviewed-by: Kieran Bingham
> + .features = RCAR_DU_FEATURE_CRTC_IRQ
> + | RCAR_DU_FEATURE_VSP1_SOURCE
> + | RCAR_DU_FEATURE_NO_BLENDING,
> + .channels_mask = BIT(1) | BIT(0),
> + .routes = {
> + /* R8A779G0 has two MIPI DSI outputs. */
> + [RCAR_DU_OUTPUT_DSI0] = {
> + .possible_crtcs = BIT(0),
> + .port = 0,
> + },
> + [RCAR_DU_OUTPUT_DSI1] = {
> + .possible_crtcs = BIT(1),
> + .port = 1,
> + },
> + },
> + .num_rpf = 5,
> + .dsi_clk_mask = BIT(1) | BIT(0),
> +};
> +
> static const struct of_device_id rcar_du_of_table[] = {
> { .compatible = "renesas,du-r8a7742", .data = _du_r8a7790_info },
> { .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
> @@ -549,6 +570,7 @@ static const struct of_device_id rcar_du_of_table[] = {
> { .compatible = "renesas,du-r8a77990", .data = _du_r8a7799x_info
> },
> { .compatible = "renesas,du-r8a77995", .data = _du_r8a7799x_info
> },
> { .compatible = "renesas,du-r8a779a0", .data = _du_r8a779a0_info
> },
> + { .compatible = "renesas,du-r8a779g0", .data = _du_r8a779g0_info
> },
> { }
> };
>
> --
> 2.34.1
>
Re: [PATCH v1 5/8] arm64: dts: renesas: white-hawk-cpu: Add DP output support
Quoting Tomi Valkeinen (2022-11-17 12:25:44)
> From: Tomi Valkeinen
>
> Add DT nodes needed for the mini DP connector. The DP is driven by
> sn65dsi86, which in turn gets the pixel data from the SoC via DSI.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Kieran Bingham
> ---
> .../dts/renesas/r8a779g0-white-hawk-cpu.dtsi | 94 +++
> 1 file changed, 94 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
> b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
> index c10740aee9f6..8aab859aac7a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
> @@ -97,6 +97,15 @@ memory@6 {
> reg = <0x6 0x 0x1 0x>;
> };
>
> + reg_1p2v: regulator-1p2v {
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-1.2V";
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> reg_1p8v: regulator-1p8v {
> compatible = "regulator-fixed";
> regulator-name = "fixed-1.8V";
> @@ -114,6 +123,24 @@ reg_3p3v: regulator-3p3v {
> regulator-boot-on;
> regulator-always-on;
> };
> +
> + mini-dp-con {
> + compatible = "dp-connector";
> + label = "CN5";
> + type = "mini";
> +
> + port {
> + mini_dp_con_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +
> + sn65dsi86_refclk: clk-x6 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <3840>;
> + };
> };
>
> {
> @@ -134,6 +161,23 @@ phy0: ethernet-phy@0 {
> };
> };
>
> + {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + dsi0_out: endpoint {
> + remote-endpoint = <_in>;
> + data-lanes = <1 2 3 4>;
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> _clk {
> clock-frequency = <1666>;
> };
> @@ -172,6 +216,51 @@ eeprom@50 {
> };
> };
>
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> + clock-frequency = <40>;
> +
> + bridge@2c {
> + compatible = "ti,sn65dsi86";
> + reg = <0x2c>;
> +
> + clocks = <_refclk>;
> + clock-names = "refclk";
> +
> + interrupt-parent = <_ex>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + enable-gpios = < 26 GPIO_ACTIVE_HIGH>;
> +
> + vccio-supply = <_1p8v>;
> + vpll-supply = <_1p8v>;
> + vcca-supply = <_1p2v>;
> + vcc-supply = <_1p2v>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + sn65dsi86_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + sn65dsi86_out: endpoint {
> + remote-endpoint = <_dp_con_in>;
> + };
> + };
> + };
> + };
> +};
> +
> {
> pinctrl-0 = <_pins>;
> pinctrl-1 = <_pins>;
> @@ -221,6 +310,11 @@ i2c0_pins: i2c0 {
> function = "i2c0";
> };
>
> + i2c1_pins: i2c1 {
> + groups = "i2c1";
> + function = "i2c1";
> + };
> +
> keys_pins: keys {
> pins = "GP_5_0", "GP_5_1", "GP_5_2";
> bias-pull-up;
> --
> 2.34.1
>
Re: [PATCH v1 4/8] arm64: dts: renesas: r8a779g0: Add display related data
nt = <_in>;
> + };
> + };
> + };
> + };
> +
> + dsi0: dsi-encoder@fed8 {
> + compatible = "renesas,r8a779g0-dsi-csi2-tx";
> + reg = <0 0xfed8 0 0x1>;
> + power-domains = < R8A779G0_PD_ALWAYS_ON>;
> + clocks = < CPG_MOD 415>,
> +< CPG_CORE R8A779G0_CLK_DSIEXT>,
> +< CPG_CORE R8A779G0_CLK_DSIREF>;
> + clock-names = "fck", "dsi", "pll";
> + resets = < 415>;
blank line here to separate it, and highlight that it's disabled? (Like
is done for DU?
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint =
> <_out_dsi0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + };
> + };
> + };
> +
> + dsi1: dsi-encoder@fed9 {
> + compatible = "renesas,r8a779g0-dsi-csi2-tx";
> + reg = <0 0xfed9 0 0x1>;
> + power-domains = < R8A779G0_PD_ALWAYS_ON>;
> + clocks = < CPG_MOD 416>,
> +< CPG_CORE R8A779G0_CLK_DSIEXT>,
> +< CPG_CORE R8A779G0_CLK_DSIREF>;
> + clock-names = "fck", "dsi", "pll";
> + resets = < 416>;
Same.
With the VSPD register ranges increased accordingly:
Reviewed-by: Kieran Bingham
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi1_in: endpoint {
> + remote-endpoint =
> <_out_dsi1>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + };
> + };
> + };
> +
> };
>
> timer {
> --
> 2.34.1
>
Re: [PATCH v1 3/8] clk: renesas: r8a779g0: Add display related clocks
Quoting Tomi Valkeinen (2022-11-17 12:25:42)
> From: Tomi Valkeinen
>
> Add clocks related to display which are needed to get the DSI output
> working.
>
> Extracted from Renesas BSP tree.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/clk/renesas/r8a779g0-cpg-mssr.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> b/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> index c6337a408e5e..6937f1aee677 100644
> --- a/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> @@ -145,6 +145,8 @@ static const struct cpg_core_clk r8a779g0_core_clks[]
> __initconst = {
> DEF_FIXED("viobusd2", R8A779G0_CLK_VIOBUSD2, CLK_VIO,2, 1),
> DEF_FIXED("vcbus", R8A779G0_CLK_VCBUS, CLK_VC, 1, 1),
> DEF_FIXED("vcbusd2",R8A779G0_CLK_VCBUSD2, CLK_VC, 2, 1),
> + DEF_FIXED("dsiref", R8A779G0_CLK_DSIREF,CLK_PLL5_DIV4, 48,
> 1),
> + DEF_DIV6P1("dsiext",R8A779G0_CLK_DSIEXT,CLK_PLL5_DIV4,
> 0x884),
>
> DEF_GEN4_SDH("sd0h",R8A779G0_CLK_SD0H, CLK_SDSRC,
> 0x870),
> DEF_GEN4_SD("sd0", R8A779G0_CLK_SD0, R8A779G0_CLK_SD0H,
> 0x870),
> @@ -161,6 +163,14 @@ static const struct mssr_mod_clk r8a779g0_mod_clks[]
> __initconst = {
> DEF_MOD("avb0", 211,R8A779G0_CLK_S0D4_HSC),
> DEF_MOD("avb1", 212,R8A779G0_CLK_S0D4_HSC),
> DEF_MOD("avb2", 213,R8A779G0_CLK_S0D4_HSC),
> +
> + DEF_MOD("dis0", 411,R8A779G0_CLK_S0D3),
dsi0?
Oh - how curious - it's listed as dis0 in the datasheet.
Ok - so this is the DU *display* not DSI ;-)
> + DEF_MOD("dsitxlink0", 415,R8A779G0_CLK_DSIREF),
> + DEF_MOD("dsitxlink1", 416,R8A779G0_CLK_DSIREF),
> +
> + DEF_MOD("fcpvd0", 508,R8A779G0_CLK_S0D3),
> + DEF_MOD("fcpvd1", 509,R8A779G0_CLK_S0D3),
> +
checks out. I guess the fcpcs is the CSI related FCP ? Anyway, if it's
not needed it can be ignored for now.
> DEF_MOD("hscif0", 514,R8A779G0_CLK_SASYNCPERD1),
> DEF_MOD("hscif1", 515,R8A779G0_CLK_SASYNCPERD1),
> DEF_MOD("hscif2", 516,R8A779G0_CLK_SASYNCPERD1),
> @@ -193,6 +203,10 @@ static const struct mssr_mod_clk r8a779g0_mod_clks[]
> __initconst = {
> DEF_MOD("tmu3", 716,R8A779G0_CLK_SASYNCPERD2),
> DEF_MOD("tmu4", 717,R8A779G0_CLK_SASYNCPERD2),
> DEF_MOD("tpu0", 718,R8A779G0_CLK_SASYNCPERD4),
> +
> + DEF_MOD("vspd0",830,R8A779G0_CLK_S0D1_VIO),
> + DEF_MOD("vspd1",831,R8A779G0_CLK_S0D1_VIO),
> +
Reviewed-by: Kieran Bingham
> DEF_MOD("wdt1:wdt0",907,R8A779G0_CLK_R),
> DEF_MOD("cmt0", 910,R8A779G0_CLK_R),
> DEF_MOD("cmt1", 911,R8A779G0_CLK_R),
> --
> 2.34.1
>
Re: [PATCH v1 2/8] dt-bindings: display: bridge: renesas, dsi-csi2-tx: Add r8a779g0
Quoting Tomi Valkeinen (2022-11-17 12:25:41) > From: Tomi Valkeinen > > Extend the Renesas DSI display bindings to support the r8a779g0 V4H. > > Signed-off-by: Tomi Valkeinen > --- > .../bindings/display/bridge/renesas,dsi-csi2-tx.yaml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml > b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml > index afeeb967393d..bc3101f77e5a 100644 > --- > a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml > +++ > b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml > @@ -11,13 +11,14 @@ maintainers: > > description: | >This binding describes the MIPI DSI/CSI-2 encoder embedded in the Renesas > - R-Car V3U SoC. The encoder can operate in either DSI or CSI-2 mode, with up > + R-Car V3U/V4H SoC. The encoder can operate in either DSI or CSI-2 mode, > with up That's 81 chars I think ... so perhaps the 'up' should go 'down' a line ... but hey it's one char, I don't care too much, but I can't resist an up/down reference :D Reviewed-by: Kieran Bingham >to four data lanes. > > properties: >compatible: > enum: >- renesas,r8a779a0-dsi-csi2-tx# for V3U > + - renesas,r8a779g0-dsi-csi2-tx# for V4H > >reg: > maxItems: 1 > -- > 2.34.1 >
Re: [PATCH v1 1/8] dt-bindings: display: renesas, du: Provide bindings for r8a779g0
Quoting Tomi Valkeinen (2022-11-17 12:25:40) > From: Tomi Valkeinen > > Extend the Renesas DU display bindings to support the r8a779g0 V4H. > > Signed-off-by: Tomi Valkeinen Matches my expectations, and interpretations of the datasheets. Reviewed-by: Kieran Bingham > --- > Documentation/devicetree/bindings/display/renesas,du.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml > b/Documentation/devicetree/bindings/display/renesas,du.yaml > index b3e588022082..d4830f52c512 100644 > --- a/Documentation/devicetree/bindings/display/renesas,du.yaml > +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml > @@ -40,6 +40,7 @@ properties: >- renesas,du-r8a77990 # for R-Car E3 compatible DU >- renesas,du-r8a77995 # for R-Car D3 compatible DU >- renesas,du-r8a779a0 # for R-Car V3U compatible DU > + - renesas,du-r8a779g0 # for R-Car V4H compatible DU > >reg: > maxItems: 1 > @@ -762,6 +763,7 @@ allOf: >contains: > enum: >- renesas,du-r8a779a0 > + - renesas,du-r8a779g0 > then: >properties: > clocks: > -- > 2.34.1 >
Re: [PATCH 19/26] drm: shmobile: Remove #ifdef guards for PM related functions
Quoting Paul Cercueil (2022-11-07 17:52:49)
> Use the DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() macros to handle
> the .suspend/.resume callbacks.
>
> These macros allow the suspend and resume functions to be automatically
> dropped by the compiler when CONFIG_SUSPEND is disabled, without having
> to use #ifdef guards.
>
> This has the advantage of always compiling these functions in,
> independently of any Kconfig option. Thanks to that, bugs and other
> regressions are subsequently easier to catch.
>
> Signed-off-by: Paul Cercueil
Reviewed-by: Kieran Bingham
> ---
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index 3d511fa38913..337040fa6438 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -143,7 +143,6 @@ static const struct drm_driver shmob_drm_driver = {
> * Power management
> */
>
> -#ifdef CONFIG_PM_SLEEP
> static int shmob_drm_pm_suspend(struct device *dev)
> {
> struct shmob_drm_device *sdev = dev_get_drvdata(dev);
> @@ -165,11 +164,9 @@ static int shmob_drm_pm_resume(struct device *dev)
> drm_kms_helper_poll_enable(sdev->ddev);
> return 0;
> }
> -#endif
>
> -static const struct dev_pm_ops shmob_drm_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(shmob_drm_pm_suspend, shmob_drm_pm_resume)
> -};
> +static DEFINE_SIMPLE_DEV_PM_OPS(shmob_drm_pm_ops,
> + shmob_drm_pm_suspend, shmob_drm_pm_resume);
>
> /*
> -
> * Platform driver
> @@ -292,7 +289,7 @@ static struct platform_driver shmob_drm_platform_driver =
> {
> .remove = shmob_drm_remove,
> .driver = {
> .name = "shmob-drm",
> - .pm = _drm_pm_ops,
> + .pm = pm_sleep_ptr(_drm_pm_ops),
> },
> };
>
> --
> 2.35.1
>
Re: [PATCH 17/26] drm: rcar-du: Remove #ifdef guards for PM related functions
Quoting Paul Cercueil (2022-11-07 17:52:47)
> Use the DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() macros to handle
> the .suspend/.resume callbacks.
>
> These macros allow the suspend and resume functions to be automatically
> dropped by the compiler when CONFIG_SUSPEND is disabled, without having
> to use #ifdef guards.
>
> This has the advantage of always compiling these functions in,
> independently of any Kconfig option. Thanks to that, bugs and other
> regressions are subsequently easier to catch.
>
> Signed-off-by: Paul Cercueil
Seems reasonable to me.
Reviewed-by: Kieran Bingham
> ---
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index a2776f1d6f2c..0a89094461cc 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -599,7 +599,6 @@ static const struct drm_driver rcar_du_driver = {
> * Power management
> */
>
> -#ifdef CONFIG_PM_SLEEP
> static int rcar_du_pm_suspend(struct device *dev)
> {
> struct rcar_du_device *rcdu = dev_get_drvdata(dev);
> @@ -613,11 +612,9 @@ static int rcar_du_pm_resume(struct device *dev)
>
> return drm_mode_config_helper_resume(>ddev);
> }
> -#endif
>
> -static const struct dev_pm_ops rcar_du_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(rcar_du_pm_suspend, rcar_du_pm_resume)
> -};
> +static DEFINE_SIMPLE_DEV_PM_OPS(rcar_du_pm_ops,
> + rcar_du_pm_suspend, rcar_du_pm_resume);
>
> /*
> -
> * Platform driver
> @@ -712,7 +709,7 @@ static struct platform_driver rcar_du_platform_driver = {
> .shutdown = rcar_du_shutdown,
> .driver = {
> .name = "rcar-du",
> - .pm = _du_pm_ops,
> + .pm = pm_sleep_ptr(_du_pm_ops),
> .of_match_table = rcar_du_of_table,
> },
> };
> --
> 2.35.1
>
Re: [PATCH] drm: rcar_du: DRM_RCAR_DU optionally depends on RCAR_MIPI_DSI
Quoting Javier Martinez Canillas (2022-11-03 11:53:14)
> Hello Kieran,
>
> On 11/3/22 11:59, Kieran Bingham wrote:
> > Hi Randy,
> >
> > Quoting Randy Dunlap (2022-11-03 06:06:45)
> >> ping. I have verified (on linux-next-20221103) that this is still needed.
> >> Thanks.
> >>
> >> On 10/18/22 11:18, Randy Dunlap wrote:
> >>> When CONFIG_DRM_RCAR_DU=y and CONFIG_DRM_RCAR_MIPI_DSI=m, calls
> >>> from the builtin driver to the mipi driver fail due to linker
> >>> errors.
> >>> Since the RCAR_MIPI_DSI driver is not always required, fix the
> >>> build error by making DRM_RCAR_DU optionally depend on the
> >>> RCAR_MIPI_DSI Kconfig symbol. This prevents the problematic
> >>> kconfig combination without requiring that RCAR_MIPI_DSI always
> >>> be enabled.
> >>>
> >>> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> >>> `rcar_du_crtc_atomic_enable':
> >>> rcar_du_crtc.c:(.text+0x3a18): undefined reference to
> >>> `rcar_mipi_dsi_pclk_enable'
> >>> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> >>> `rcar_du_crtc_atomic_disable':
> >>> rcar_du_crtc.c:(.text+0x47cc): undefined reference to
> >>> `rcar_mipi_dsi_pclk_disable'
> >>>
> >>> Fixes: 957fe62d7d15 ("drm: rcar-du: Fix DSI enable & disable sequence")
> >>> Signed-off-by: Randy Dunlap
> >>> Cc: Tomi Valkeinen
> >>> Cc: Laurent Pinchart
> >>> Cc: Kieran Bingham
> >>> Cc: LUU HOAI
> >>> Cc: dri-devel@lists.freedesktop.org
> >>> Cc: linux-renesas-...@vger.kernel.org
> >>> Cc: David Airlie
> >>> Cc: Daniel Vetter
> >>> ---
> >>> drivers/gpu/drm/rcar-du/Kconfig |1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff -- a/drivers/gpu/drm/rcar-du/Kconfig
> >>> b/drivers/gpu/drm/rcar-du/Kconfig
> >>> --- a/drivers/gpu/drm/rcar-du/Kconfig
> >>> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> >>> @@ -4,6 +4,7 @@ config DRM_RCAR_DU
> >>> depends on DRM && OF
> >>> depends on ARM || ARM64
> >>> depends on ARCH_RENESAS || COMPILE_TEST
> >>> + depends on DRM_RCAR_MIPI_DSI || DRM_RCAR_MIPI_DSI=n
> >
> > Please forgive my ignorance, but I don't understand how this works.
> > Could you explain what this is doing please?
> >
> > I know you've explained above that it fixes it to optionally depend on
> > DRM_RCAR_MIPI_DSI ... but it's not making sense to me.
> >
> > To me - this is saying we depend on DRM_RCAR_MIPI_DSI being enabled, or
> > not being enabled ... ? Which is like saying if (0 || 1) ?
> >
> > I'm guessing I'm missing something obvious :-S
> >
>
> What this Kconfig expression is saying is that it depends on
> DRM_RCAR_MIPI_DSI=y
> if DRM_RCAR_DU=y and DRM_RCAR_MIPI_DSI=m if DRM_RCAR_DU=m. But that the it can
> also be satisfied if is not set DRM_RCAR_MIPI_DSI.
>
> This is usually used to make sure that you don't end with a configuration
> where
> DRM_RCAR_MIPI_DSI=y and DRM_RCAR_DU=m or DRM_RCAR_MIPI_DSI=m and
> DRM_RCAR_DU=y.
>
> Randy, I think that it's more idiomatic though to it express as following:
>
> depends on DRM_RCAR_MIPI_DSI || !DRM_RCAR_MIPI_DSI
Ok - thanks, so it's the module part that breaks. I never build modules,
always builtin - so it doesn't hit me ;-)
Anyway - it certainly makes sense now I think so either as posted, or
with the idiomatic proposal from Javier:
Reviewed-by: Kieran Bingham
>
> --
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat
>
Re: [PATCH] drm: rcar_du: DRM_RCAR_DU optionally depends on RCAR_MIPI_DSI
Hi Randy,
Quoting Randy Dunlap (2022-11-03 06:06:45)
> ping. I have verified (on linux-next-20221103) that this is still needed.
> Thanks.
>
> On 10/18/22 11:18, Randy Dunlap wrote:
> > When CONFIG_DRM_RCAR_DU=y and CONFIG_DRM_RCAR_MIPI_DSI=m, calls
> > from the builtin driver to the mipi driver fail due to linker
> > errors.
> > Since the RCAR_MIPI_DSI driver is not always required, fix the
> > build error by making DRM_RCAR_DU optionally depend on the
> > RCAR_MIPI_DSI Kconfig symbol. This prevents the problematic
> > kconfig combination without requiring that RCAR_MIPI_DSI always
> > be enabled.
> >
> > aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> > `rcar_du_crtc_atomic_enable':
> > rcar_du_crtc.c:(.text+0x3a18): undefined reference to
> > `rcar_mipi_dsi_pclk_enable'
> > aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> > `rcar_du_crtc_atomic_disable':
> > rcar_du_crtc.c:(.text+0x47cc): undefined reference to
> > `rcar_mipi_dsi_pclk_disable'
> >
> > Fixes: 957fe62d7d15 ("drm: rcar-du: Fix DSI enable & disable sequence")
> > Signed-off-by: Randy Dunlap
> > Cc: Tomi Valkeinen
> > Cc: Laurent Pinchart
> > Cc: Kieran Bingham
> > Cc: LUU HOAI
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-renesas-...@vger.kernel.org
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/rcar-du/Kconfig |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff -- a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -4,6 +4,7 @@ config DRM_RCAR_DU
> > depends on DRM && OF
> > depends on ARM || ARM64
> > depends on ARCH_RENESAS || COMPILE_TEST
> > + depends on DRM_RCAR_MIPI_DSI || DRM_RCAR_MIPI_DSI=n
Please forgive my ignorance, but I don't understand how this works.
Could you explain what this is doing please?
I know you've explained above that it fixes it to optionally depend on
DRM_RCAR_MIPI_DSI ... but it's not making sense to me.
To me - this is saying we depend on DRM_RCAR_MIPI_DSI being enabled, or
not being enabled ... ? Which is like saying if (0 || 1) ?
I'm guessing I'm missing something obvious :-S
--
Kieran
> > select DRM_KMS_HELPER
> > select DRM_GEM_DMA_HELPER
> > select VIDEOMODE_HELPERS
>
> --
> ~Randy
Re: [PATCH v2 4/4] drm: lcdif: Add support for YUV planes
Quoting Laurent Pinchart (2022-09-28 11:05:33)
> Hi Kieran,
>
> On Wed, Sep 28, 2022 at 10:59:36AM +0100, Kieran Bingham wrote:
> > Quoting Laurent Pinchart (2022-09-28 01:58:12)
> > > From: Kieran Bingham
> >
> > It looks like this has progressed a bit since it left my computer ;-)
>
> I wish the same would be universally true for all patches :-)
>
> > > The LCDIF includes a color space converter that supports YUV input. Use
> > > it to support YUV planes, either through the converter if the output
> > > format is RGB, or in conversion bypass mode otherwise.
> > >
> > > Signed-off-by: Kieran Bingham
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > > Changes since v1:
> > >
> > > - Support all YCbCr encodings and quantization ranges
> > > - Drop incorrect comment
> > > ---
> > > drivers/gpu/drm/mxsfb/lcdif_kms.c | 183 +
> > > drivers/gpu/drm/mxsfb/lcdif_regs.h | 5 +-
> > > 2 files changed, 164 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > > b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > > index c3622be0c587..b469a90fd50f 100644
> > > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > > @@ -15,6 +15,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -32,13 +33,77 @@
> > > /*
> > > -
> > > * CRTC
> > > */
> > > +
> > > +/*
> > > + * Despite the reference manual stating the opposite, the D1, D2 and D3
> > > offset
> > > + * values are added to Y, U and V, not subtracted. They must thus be
> > > programmed
> > > + * with negative values.
> > > + */
> > > +static const u32 lcdif_yuv2rgb_coeffs[3][2][6] = {
> >
> > Ick ... I sort of dislike this. It's fine here at the moment, and I like
> > the table ... but here we're definining the size of the table based on
> > external enum values. (Are those ABI stable, perhaps they are already?)
> >
> > If someone were to put
> >
> > enum drm_color_encoding {
> > +DRM_COLOR_LEGACY,
> > DRM_COLOR_YCBCR_BT601,
> > DRM_COLOR_YCBCR_BT709,
> > DRM_COLOR_YCBCR_BT2020,
> > DRM_COLOR_ENCODING_MAX,
> > };
> >
> > enum drm_color_range {
> > DRM_COLOR_YCBCR_LIMITED_RANGE,
> > + DRM_COLOR_YCBCR_MID_RANGE,
> > DRM_COLOR_YCBCR_FULL_RANGE,
> > DRM_COLOR_RANGE_MAX,
> > };
> >
> > Then this table allocation would be wrong.
> >
> > Perhaps swapping for
> >
> > > +static const u32
> > > lcdif_yuv2rgb_coeffs[DRM_COLOR_ENCODING_MAX][DRM_COLOR_RANGE_MAX][6] = {
> >
> > Would be safer ... but longer :-( ?
> >
> > Anyway, I think the rest of it looks fine, and perhaps these enums are
> > in the UAPI which would make them stable anyway:
>
> The enums themselves are not exposed in UAPI headers, but userspace
> depends on the values, which thus have to remain stable.
And I saw you had to redefine them to use them in libcamera. Perhaps
they should be in a UAPI header then...
--
Kieran
>
> > Reviewed-by: Kieran Bingham
> >
> > > + [DRM_COLOR_YCBCR_BT601] = {
> > > + [DRM_COLOR_YCBCR_LIMITED_RANGE] = {
> > > + CSC0_COEF0_A1(0x012a) | CSC0_COEF0_A2(0x),
> > > + CSC0_COEF1_A3(0x01a2) | CSC0_COEF1_B1(0x0123),
> > > + CSC0_COEF2_B2(0x079c) | CSC0_COEF2_B3(0x0730),
> > > + CSC0_COEF3_C1(0x0124) | CSC0_COEF3_C2(0x0204),
> > > + CSC0_COEF4_C3(0x) | CSC0_COEF4_D1(0x01f0),
> > > + CSC0_COEF5_D2(0x0180) | CSC0_COEF5_D3(0x0180),
> > > + },
> > > + [DRM_COLOR_YCBCR_FULL_RANGE] = {
> > > + CSC0_COEF0_A1(0x0100) | CSC0_COEF0_A2(0x),
> > > + CSC0_COEF1_A3(0x0167) | CSC0_COEF1_B1(0x0100),
> > > + CSC0_COEF2_B2(0x07a8) | CSC0_COEF2_B3(0x0749),
> > > + CSC0_COEF3_C1(0x0100) | CSC0_COEF3_C2(0x01c6),
> > > + CSC0_CO
Re: [PATCH v2 4/4] drm: lcdif: Add support for YUV planes
Quoting Laurent Pinchart (2022-09-28 01:58:12)
> From: Kieran Bingham
>
It looks like this has progressed a bit since it left my computer ;-)
> The LCDIF includes a color space converter that supports YUV input. Use
> it to support YUV planes, either through the converter if the output
> format is RGB, or in conversion bypass mode otherwise.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Support all YCbCr encodings and quantization ranges
> - Drop incorrect comment
> ---
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 183 +
> drivers/gpu/drm/mxsfb/lcdif_regs.h | 5 +-
> 2 files changed, 164 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> index c3622be0c587..b469a90fd50f 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -32,13 +33,77 @@
> /*
> -
> * CRTC
> */
> +
> +/*
> + * Despite the reference manual stating the opposite, the D1, D2 and D3
> offset
> + * values are added to Y, U and V, not subtracted. They must thus be
> programmed
> + * with negative values.
> + */
> +static const u32 lcdif_yuv2rgb_coeffs[3][2][6] = {
Ick ... I sort of dislike this. It's fine here at the moment, and I like
the table ... but here we're definining the size of the table based on
external enum values. (Are those ABI stable, perhaps they are already?)
If someone were to put
enum drm_color_encoding {
+DRM_COLOR_LEGACY,
DRM_COLOR_YCBCR_BT601,
DRM_COLOR_YCBCR_BT709,
DRM_COLOR_YCBCR_BT2020,
DRM_COLOR_ENCODING_MAX,
};
enum drm_color_range {
DRM_COLOR_YCBCR_LIMITED_RANGE,
+DRM_COLOR_YCBCR_MID_RANGE,
DRM_COLOR_YCBCR_FULL_RANGE,
DRM_COLOR_RANGE_MAX,
};
Then this table allocation would be wrong.
Perhaps swapping for
> +static const u32
> lcdif_yuv2rgb_coeffs[DRM_COLOR_ENCODING_MAX][DRM_COLOR_RANGE_MAX][6] = {
Would be safer ... but longer :-( ?
Anyway, I think the rest of it looks fine, and perhaps these enums are
in the UAPI which would make them stable anyway:
Reviewed-by: Kieran Bingham
> + [DRM_COLOR_YCBCR_BT601] = {
> + [DRM_COLOR_YCBCR_LIMITED_RANGE] = {
> + CSC0_COEF0_A1(0x012a) | CSC0_COEF0_A2(0x),
> + CSC0_COEF1_A3(0x01a2) | CSC0_COEF1_B1(0x0123),
> + CSC0_COEF2_B2(0x079c) | CSC0_COEF2_B3(0x0730),
> + CSC0_COEF3_C1(0x0124) | CSC0_COEF3_C2(0x0204),
> + CSC0_COEF4_C3(0x) | CSC0_COEF4_D1(0x01f0),
> + CSC0_COEF5_D2(0x0180) | CSC0_COEF5_D3(0x0180),
> + },
> + [DRM_COLOR_YCBCR_FULL_RANGE] = {
> + CSC0_COEF0_A1(0x0100) | CSC0_COEF0_A2(0x),
> + CSC0_COEF1_A3(0x0167) | CSC0_COEF1_B1(0x0100),
> + CSC0_COEF2_B2(0x07a8) | CSC0_COEF2_B3(0x0749),
> + CSC0_COEF3_C1(0x0100) | CSC0_COEF3_C2(0x01c6),
> + CSC0_COEF4_C3(0x) | CSC0_COEF4_D1(0x),
> + CSC0_COEF5_D2(0x0180) | CSC0_COEF5_D3(0x0180),
> + },
> + },
> + [DRM_COLOR_YCBCR_BT709] = {
> + [DRM_COLOR_YCBCR_LIMITED_RANGE] = {
> + CSC0_COEF0_A1(0x012a) | CSC0_COEF0_A2(0x),
> + CSC0_COEF1_A3(0x01d6) | CSC0_COEF1_B1(0x0123),
> + CSC0_COEF2_B2(0x07c9) | CSC0_COEF2_B3(0x0778),
> + CSC0_COEF3_C1(0x0123) | CSC0_COEF3_C2(0x021d),
> + CSC0_COEF4_C3(0x) | CSC0_COEF4_D1(0x01f0),
> + CSC0_COEF5_D2(0x0180) | CSC0_COEF5_D3(0x0180),
> + },
> + [DRM_COLOR_YCBCR_FULL_RANGE] = {
> + CSC0_COEF0_A1(0x0100) | CSC0_COEF0_A2(0x),
> + CSC0_COEF1_A3(0x0193) | CSC0_COEF1_B1(0x0100),
> + CSC0_COEF2_B2(0x07d0) | CSC0_COEF2_B3(0x0788),
> + CSC0_COEF3_C1(0x0100) | CSC0_COEF3_C2(0x01db),
> + CSC0_COEF4_C3(0x) | CSC0_COEF4_D1(0x),
> + CSC0_COEF5_D2(0x0180) | CSC0_COEF5_D3(0x0180),
> + },
> + },
> + [DRM_COLOR_YCBCR_BT2020] = {
> + [DRM_COLOR_YCBCR_LIMITED_RANGE] = {
> + CSC0_COEF0_A1(0x012a) | CSC0_COEF0_A2(0x),
> +
Re: [PATCH v2 3/4] drm: lcdif: Switch to limited range for RGB to YUV conversion
Quoting Laurent Pinchart (2022-09-28 01:58:11)
> Up to and including v1.3, HDMI supported limited quantization range only
> for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this
> features isn't supported in the dw-hdmi driver that is used in
> conjunction with the LCDIF in the i.MX8MP. The HDMI YCbCr output is thus
> always advertised in the AVI infoframe as limited range.
>
> The LCDIF driver, on the other hand, configures the CSC to produce full
> range YCbCr. This mismatch results in loss of details and incorrect
> colours. Fix it by switching to limited range YCbCr.
>
> The coefficients are copied from drivers/media/platforms/nxp/imx-pxp.c
> for coherency, as the hardware is most likely identical.
Perhaps we need one or two of these somewhere:
https://colorconfidence.com/products/calibrite-colorchecker-display
Or does anyone have one that could test this patch?
Anyway:
Reviewed-by: Kieran Bingham
> Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Use coefficients from imx-pxp.c
> ---
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> index 1f22ea5896d5..c3622be0c587 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -53,16 +53,16 @@ static void lcdif_set_formats(struct lcdif_drm_private
> *lcdif,
> writel(DISP_PARA_LINE_PATTERN_UYVY_H,
>lcdif->base + LCDC_V8_DISP_PARA);
>
> - /* CSC: BT.601 Full Range RGB to YCbCr coefficients. */
> - writel(CSC0_COEF0_A2(0x096) | CSC0_COEF0_A1(0x04c),
> + /* CSC: BT.601 Limited Range RGB to YCbCr coefficients. */
> + writel(CSC0_COEF0_A2(0x081) | CSC0_COEF0_A1(0x041),
>lcdif->base + LCDC_V8_CSC0_COEF0);
> - writel(CSC0_COEF1_B1(0x7d5) | CSC0_COEF1_A3(0x01d),
> + writel(CSC0_COEF1_B1(0x7db) | CSC0_COEF1_A3(0x019),
>lcdif->base + LCDC_V8_CSC0_COEF1);
> - writel(CSC0_COEF2_B3(0x080) | CSC0_COEF2_B2(0x7ac),
> + writel(CSC0_COEF2_B3(0x070) | CSC0_COEF2_B2(0x7b6),
>lcdif->base + LCDC_V8_CSC0_COEF2);
> - writel(CSC0_COEF3_C2(0x795) | CSC0_COEF3_C1(0x080),
> + writel(CSC0_COEF3_C2(0x7a2) | CSC0_COEF3_C1(0x070),
>lcdif->base + LCDC_V8_CSC0_COEF3);
> - writel(CSC0_COEF4_D1(0x000) | CSC0_COEF4_C3(0x7ec),
> + writel(CSC0_COEF4_D1(0x010) | CSC0_COEF4_C3(0x7ee),
>lcdif->base + LCDC_V8_CSC0_COEF4);
> writel(CSC0_COEF5_D3(0x080) | CSC0_COEF5_D2(0x080),
>lcdif->base + LCDC_V8_CSC0_COEF5);
> --
> Regards,
>
> Laurent Pinchart
>
Re: [PATCH v2 2/4] drm: lcdif: Don't use BIT() for multi-bit register fields
Quoting Laurent Pinchart (2022-09-28 01:58:10) > The BIT() macro is meant to represent a single bit. Don't use it for > values of register fields that span multiple bits. > > Signed-off-by: Laurent Pinchart > --- > Changes since v1: > > - Use hex for field values > --- > drivers/gpu/drm/mxsfb/lcdif_regs.h | 28 ++-- > 1 file changed, 14 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/mxsfb/lcdif_regs.h > b/drivers/gpu/drm/mxsfb/lcdif_regs.h > index 013f2cace2a0..0d5d9bedd94a 100644 > --- a/drivers/gpu/drm/mxsfb/lcdif_regs.h > +++ b/drivers/gpu/drm/mxsfb/lcdif_regs.h > @@ -138,9 +138,9 @@ > > #define DISP_PARA_DISP_ON BIT(31) > #define DISP_PARA_SWAP_EN BIT(30) > -#define DISP_PARA_LINE_PATTERN_UYVY_H (GENMASK(29, 28) | BIT(26)) I mean, I like BIT (and sometimes GENMASK) but ... What was going on there! Defintely better this way. Reviewed-by: Kieran Bingham > -#define DISP_PARA_LINE_PATTERN_RGB565 GENMASK(28, 26) > -#define DISP_PARA_LINE_PATTERN_RGB888 0 > +#define DISP_PARA_LINE_PATTERN_UYVY_H (0xd << 26) > +#define DISP_PARA_LINE_PATTERN_RGB565 (0x7 << 26) > +#define DISP_PARA_LINE_PATTERN_RGB888 (0x0 << 26) > #define DISP_PARA_LINE_PATTERN_MASKGENMASK(29, 26) > #define DISP_PARA_DISP_MODE_MASK GENMASK(25, 24) > #define DISP_PARA_BGND_R_MASK GENMASK(23, 16) > @@ -202,18 +202,18 @@ > > #define CTRLDESCL0_5_ENBIT(31) > #define CTRLDESCL0_5_SHADOW_LOAD_ENBIT(30) > -#define CTRLDESCL0_5_BPP_16_RGB565 BIT(26) > -#define CTRLDESCL0_5_BPP_16_ARGB1555 (BIT(26) | BIT(24)) > -#define CTRLDESCL0_5_BPP_16_ARGB (BIT(26) | BIT(25)) > -#define CTRLDESCL0_5_BPP_YCbCr422 (BIT(26) | BIT(25) | BIT(24)) > -#define CTRLDESCL0_5_BPP_24_RGB888 BIT(27) > -#define CTRLDESCL0_5_BPP_32_ARGB (BIT(27) | BIT(24)) > -#define CTRLDESCL0_5_BPP_32_ABGR (BIT(27) | BIT(25)) > +#define CTRLDESCL0_5_BPP_16_RGB565 (0x4 << 24) > +#define CTRLDESCL0_5_BPP_16_ARGB1555 (0x5 << 24) > +#define CTRLDESCL0_5_BPP_16_ARGB (0x6 << 24) > +#define CTRLDESCL0_5_BPP_YCbCr422 (0x7 << 24) > +#define CTRLDESCL0_5_BPP_24_RGB888 (0x8 << 24) > +#define CTRLDESCL0_5_BPP_32_ARGB (0x9 << 24) > +#define CTRLDESCL0_5_BPP_32_ABGR (0xa << 24) > #define CTRLDESCL0_5_BPP_MASK GENMASK(27, 24) > -#define CTRLDESCL0_5_YUV_FORMAT_Y2VY1U 0 > -#define CTRLDESCL0_5_YUV_FORMAT_Y2UY1V BIT(14) > -#define CTRLDESCL0_5_YUV_FORMAT_VY2UY1 BIT(15) > -#define CTRLDESCL0_5_YUV_FORMAT_UY2VY1 (BIT(15) | BIT(14)) > +#define CTRLDESCL0_5_YUV_FORMAT_Y2VY1U (0x0 << 14) > +#define CTRLDESCL0_5_YUV_FORMAT_Y2UY1V (0x1 << 14) > +#define CTRLDESCL0_5_YUV_FORMAT_VY2UY1 (0x2 << 14) > +#define CTRLDESCL0_5_YUV_FORMAT_UY2VY1 (0x3 << 14) > #define CTRLDESCL0_5_YUV_FORMAT_MASK GENMASK(15, 14) > > #define CSC0_CTRL_CSC_MODE_RGB2YCbCr GENMASK(2, 1) > -- > Regards, > > Laurent Pinchart >
Re: [PATCH v2 1/4] drm: lcdif: Fix indentation in lcdif_regs.h
Quoting Laurent Pinchart (2022-09-28 01:58:09) > A couple of the register macro values are incorrectly indented. Fix > them. > Argh, there was already a v2 posted. Sometimes (more often than I like) I really hate email... Reviewed-by: Kieran Bingham > Signed-off-by: Laurent Pinchart > Reviewed-by: Marek Vasut > --- > drivers/gpu/drm/mxsfb/lcdif_regs.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mxsfb/lcdif_regs.h > b/drivers/gpu/drm/mxsfb/lcdif_regs.h > index 8e8bef175bf2..013f2cace2a0 100644 > --- a/drivers/gpu/drm/mxsfb/lcdif_regs.h > +++ b/drivers/gpu/drm/mxsfb/lcdif_regs.h > @@ -130,7 +130,7 @@ > #define CTRL_FETCH_START_OPTION_BPVBIT(9) > #define CTRL_FETCH_START_OPTION_RESV GENMASK(9, 8) > #define CTRL_FETCH_START_OPTION_MASK GENMASK(9, 8) > -#define CTRL_NEG BIT(4) > +#define CTRL_NEG BIT(4) > #define CTRL_INV_PXCK BIT(3) > #define CTRL_INV_DEBIT(2) > #define CTRL_INV_VSBIT(1) > @@ -186,7 +186,7 @@ > #define INT_ENABLE_D1_PLANE_PANIC_EN BIT(0) > > #define CTRLDESCL0_1_HEIGHT(n) (((n) & 0x) << 16) > -#define CTRLDESCL0_1_HEIGHT_MASK GENMASK(31, 16) > +#define CTRLDESCL0_1_HEIGHT_MASK GENMASK(31, 16) > #define CTRLDESCL0_1_WIDTH(n) ((n) & 0x) > #define CTRLDESCL0_1_WIDTH_MASKGENMASK(15, 0) > > -- > Regards, > > Laurent Pinchart >
Re: [PATCH 1/4] drm: lcdif: Fix indentation in lcdif_regs.h
Quoting Laurent Pinchart (2022-09-28 00:38:18) > A couple of the register macro values are incorrectly indented. Fix > them. > Reviewed-by: Kieran Bingham > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/mxsfb/lcdif_regs.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mxsfb/lcdif_regs.h > b/drivers/gpu/drm/mxsfb/lcdif_regs.h > index 8e8bef175bf2..013f2cace2a0 100644 > --- a/drivers/gpu/drm/mxsfb/lcdif_regs.h > +++ b/drivers/gpu/drm/mxsfb/lcdif_regs.h > @@ -130,7 +130,7 @@ > #define CTRL_FETCH_START_OPTION_BPVBIT(9) > #define CTRL_FETCH_START_OPTION_RESV GENMASK(9, 8) > #define CTRL_FETCH_START_OPTION_MASK GENMASK(9, 8) > -#define CTRL_NEG BIT(4) > +#define CTRL_NEG BIT(4) > #define CTRL_INV_PXCK BIT(3) > #define CTRL_INV_DEBIT(2) > #define CTRL_INV_VSBIT(1) > @@ -186,7 +186,7 @@ > #define INT_ENABLE_D1_PLANE_PANIC_EN BIT(0) > > #define CTRLDESCL0_1_HEIGHT(n) (((n) & 0x) << 16) > -#define CTRLDESCL0_1_HEIGHT_MASK GENMASK(31, 16) > +#define CTRLDESCL0_1_HEIGHT_MASK GENMASK(31, 16) > #define CTRLDESCL0_1_WIDTH(n) ((n) & 0x) > #define CTRLDESCL0_1_WIDTH_MASKGENMASK(15, 0) > > -- > Regards, > > Laurent Pinchart >
Re: [PATCH] drm: rcar-du: Drop leftovers variables from Makefile
Quoting Laurent Pinchart (2022-08-27 01:42:20)
> Commit 841281fe52a7 ("drm: rcar-du: Drop LVDS device tree backward
> compatibility") has removed device tree overlay sources used for
> backward compatibility with old bindings, but forgot to remove related
> variables from the Makefile. Fix it.
>
> Fixes: 841281fe52a7 ("drm: rcar-du: Drop LVDS device tree backward
> compatibility")
> Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/Makefile | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile
> index e7275b5e7ec8..6f132325c8b7 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -14,10 +14,3 @@ obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
> obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o
> -
> -# 'remote-endpoint' is fixed up at run-time
> -DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint
> -DTC_FLAGS_rcar_du_of_lvds_r8a7791 += -Wno-graph_endpoint
> -DTC_FLAGS_rcar_du_of_lvds_r8a7793 += -Wno-graph_endpoint
> -DTC_FLAGS_rcar_du_of_lvds_r8a7795 += -Wno-graph_endpoint
> -DTC_FLAGS_rcar_du_of_lvds_r8a7796 += -Wno-graph_endpoint
>
> base-commit: 2c2d7a67defa198a8b8148dbaddc9e5554efebc8
> --
> Regards,
>
> Laurent Pinchart
>
Re: connecting a sn65dsi86 to displayport connector
Quoting Rasmus Villemoes (2022-07-07 10:46:24) > On 05/07/2022 17.10, Kieran Bingham wrote: > > Hi Rasmus, > > > > Quoting Rasmus Villemoes (2022-07-05 10:08:37) > >> Hi > >> > >> I have an imx8mp board with a sn65dsi86 and a (full-size) DisplayPort > >> connector, which I'm trying to get up and running. > >> > [...] > >> Any hints would be highly appreciated. > > > > If it helps, this is an area I've been working to support one of our > > boards. I have a branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git > > kbingham/drm-misc/next/sn65dsi86/hpd > > > > But it's still a work in progress, and now needs rebasing to account for > > Sam's latest updates. > > > > I intend to resume this in a few weeks, but hopefully that branch may > > have some helpful pointers to get things progressing for you too. > > Hi Kieran > > Thanks for the pointer, I'll take a look. But just to be clear: Is the > board you're referring to above the same as the one where the DT changes > went in with commit 5a6bca1ff7 ? Or does that Falcon board work with the > current state of mainline, and the patches in the above branch are to > support some other board/use case? Yes, the board I have is the Falcon V3U, as referred to in 5a6bca1ff7. -- Kieran > > Thanks, > Rasmus
Re: connecting a sn65dsi86 to displayport connector
Hi Rasmus,
Quoting Rasmus Villemoes (2022-07-05 10:08:37)
> Hi
>
> I have an imx8mp board with a sn65dsi86 and a (full-size) DisplayPort
> connector, which I'm trying to get up and running.
>
> The display connector registers itself as a bridge; I do get
> successfully to the end of display_connector_probe(). But
> ti_sn_bridge_probe() only looks for a panel (passing NULL for the
> drm_bridge** argument), so always fails with -EPROBE_DEFER.
>
> This text
>
> At the moment, this binding only handles the eDP case. It is
> possible it will be extended in the future to handle the DP case.
> For DP, presumably a connector would be listed under the DP AUX
> bus instead of a panel.
>
> in dp-aux-bus.yaml suggests that what I'm trying to do is simply not
> supported yet. But then I stumbled on commit 5a6bca1ff7a5 (arm64: dts:
> renesas: falcon-cpu: Add DSI display output), which seems to do exactly
> what I'm trying to, except with a mini dp connector. So I must be
> missing something; maybe ti_sn_bridge_probe() failing is not actually a
> problem and I could be looking at the wrong place.
>
> Snippets from my .dts; the dp connector is currently placed at top
> level, i.e. not within an aux-bus node below the sn65dsi86:
>
> display_port0: connector {
> compatible = "dp-connector";
> label = "DP0";
> type = "full-size";
> dp-pwr-supply = <_DP_PWR>;
>
> port {
> dp_connector_in: endpoint {
> remote-endpoint = <_out>;
> };
> };
> };
>
> {
> ...
> eDP: bridge@2c {
> compatible = "ti,sn65dsi86";
> reg = <0x2c>;
> pinctrl-names = "default";
> pinctrl-0 = <_eDP>;
>
> interrupts-extended = < 14 IRQ_TYPE_LEVEL_HIGH>;
> enable-gpios = < 9 GPIO_ACTIVE_HIGH>;
>
> vpll-supply = <_1V8>;
> vccio-supply = <_1V8>;
> vcca-supply = <_1V2>;
> vcc-supply = <_1V2>;
>
> clocks = <_38_4MHz>;
> clock-names = "refclk";
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> sn65dsi86_in_a: endpoint {
> remote-endpoint = <_dsi_out>;
> };
> };
>
> port@1 {
> reg = <1>;
> sn65dsi86_out: endpoint {
> remote-endpoint = <_connector_in>;
> data-lanes = <3 2 1 0>;
> };
> };
> };
> };
> };
>
> When I manually set the enable-gpio high in U-Boot, I can talk to the
> device and e.g. read out the 8 device_id bytes which match what I expect.
>
> Any hints would be highly appreciated.
If it helps, this is an area I've been working to support one of our
boards. I have a branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git
kbingham/drm-misc/next/sn65dsi86/hpd
But it's still a work in progress, and now needs rebasing to account for
Sam's latest updates.
I intend to resume this in a few weeks, but hopefully that branch may
have some helpful pointers to get things progressing for you too.
--
Kieran
>
> Thanks,
> Rasmus
Re: [PATCH v2 0/1] bridge/ti-sn65dsi86.c: convert to atomic operations
(Dropping CC/lists) Quoting Sam Ravnborg (2022-07-03 21:27:23) > This patch is what is left on a previous attempt to make the > ti-sn65dsi86 support DRM_BRIDGE_ATTACH_NO_CONNECTOR. > > I ran into several challenges on the way: > - I never found a way to retreive bpc when the driver > do not create the connector - and the driver needs it. > There may be ways to change how bpc is used but as I have no access > to HW it is not easy to change much. > - My understanding of the driver is limited so I dropped trying to > do the proper implmentation of format negotiation > - I had made a small macro to encapsulate a few of the common functions > in drm_bridge_funcs - but looking at it with fresh eyes told me > this is not a good idea. > > I dropped previous a-b / r-b as the driver has changed a bit since > last submission. > Especially to Kieran - sorry for letting you wait so long for almost nothing. No worries, thanks for digging in. I'll get my branch back up and rebase on top of this and resume from there. I can't remember all the details right now - so it will be interesting to see how to handle the issues you've mentioned above - but I think some of it is what I was trying to work on. (dealing with getting the BPC at least..., so I don't know if I considered the issue you reference about case of the driver not creating a connector). I don't think I'll be able to resume my DRM work for more than a couple of weeks now though so I'm going to be a bit longer. Hopefully your patch here looks like it could be merged independently though. -- Kieran > > Sorry if this is a duplicate - something went wrong when I sent this > mail the first time. > > Sam > > > Sam Ravnborg (1): > drm/bridge: ti-sn65dsi86: Use atomic variants of drm_bridge_funcs > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 23 +++ > 1 file changed, 15 insertions(+), 8 deletions(-) > >
Re: [PATCH v1 0/9] drm/bridge: ps8640 and ti-sn65dsi86 updates
Hi Sam, Quoting Sam Ravnborg (2022-02-06 19:09:11) > > > > The code builds - but needs testing. > > Hrmff, no it does not build. The fixes was by accident not included. > Will wait a bit for feedback before posting a v2. > > Sam Do you have any plan to send a v2 on this series? I have built up a series to extend the ti-sn65dsi86 which is now based on this. (which means I'll have an implied Tested-by: tag for these as well). -- Kieran
Re: [PATCH v2] drm: shmobile: Use backlight helper
Quoting Stephen Kitt (2022-06-16 18:08:21) > This started with work on the removal of backlight_properties' > deprecated fb_blank field, much of which can be taken care of by using > helper functions provided by backlight.h instead of directly accessing > fields in backlight_properties. This patch series doesn't involve > fb_blank, but it still seems useful to use helper functions where > appropriate. > > Instead of retrieving the backlight brightness in struct > backlight_properties manually, and then checking whether the backlight > should be on at all, use backlight_get_brightness() which does all > this and insulates this from future changes. > > Signed-off-by: Stephen Kitt > Cc: Laurent Pinchart > Cc: Kieran Bingham Hi Stephen, This looks reasonable to me too. Reviewed-by: Kieran Bingham > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > --- > Changes since v1: clarified commit message, this doesn't touch fb_blank > --- > drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_backlight.c > b/drivers/gpu/drm/shmobile/shmob_drm_backlight.c > index f6628a5ee95f..794573badfe8 100644 > --- a/drivers/gpu/drm/shmobile/shmob_drm_backlight.c > +++ b/drivers/gpu/drm/shmobile/shmob_drm_backlight.c > @@ -18,11 +18,7 @@ static int shmob_drm_backlight_update(struct > backlight_device *bdev) > struct shmob_drm_connector *scon = bl_get_data(bdev); > struct shmob_drm_device *sdev = scon->connector.dev->dev_private; > const struct shmob_drm_backlight_data *bdata = > >pdata->backlight; > - int brightness = bdev->props.brightness; > - > - if (bdev->props.power != FB_BLANK_UNBLANK || > - bdev->props.state & BL_CORE_SUSPENDED) > - brightness = 0; > + int brightness = backlight_get_brightness(bdev); > > return bdata->set_brightness(brightness); > } > > base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56 > -- > 2.30.2 >
RE: [PATCH v3 3/4] drm: rcar-du: Add num_rpf to struct rcar_du_device_info
Quoting Biju Das (2022-06-07 11:58:08)
> Hi All,
>
> Gentle ping. Are we happy with this patch?
>
The patch itself looks fine to me.
Reviewed-by: Kieran Bingham
> Since RZ/G2L is using separate drm driver,
> I can drop this patch, if needed.
>
But indeed, it's not clear if the requirement is still there if the RZ
doesn't use this code path now. But there could be future generations
with more (or less?) RPFs ... so it's not unreasonable.
I wonder if it's something that would only be worth applying when needed
though, as otherwise we're increasing the binary size for no real gain.
(17 * 4 = only 68 bytes ... but ... I know people try to reduce these
sizes where possible).
--
Kieran
> Please let me know.
>
> Cheers,
> Biju
>
> > Subject: [PATCH v3 3/4] drm: rcar-du: Add num_rpf to struct
> > rcar_du_device_info
> >
> > Number of RPF's VSP is different on R-Car and RZ/G2L R-Car Gen3 -> 5
> > RPFs R-Car Gen2 -> 4 RPFs RZ/G2L -> 2 RPFs
> >
> > Add num_rpf to struct rcar_du_device_info to support later SoC without
> > any code changes.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Laurent Pinchart
> > ---
> > v2->v3:
> > * Added Rb tag from Laurent.
> > * Fixed the comment "max num"->"num"
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 17 +
> > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 ++ drivers/gpu/drm/rcar-
> > du/rcar_du_vsp.c | 6 +-
> > 3 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > index 957ea97541d5..1bc7325aa356 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -55,6 +55,7 @@ static const struct rcar_du_device_info
> > rzg1_du_r8a7743_info = {
> > },
> > },
> > .num_lvds = 1,
> > + .num_rpf = 4,
> > };
> >
> > static const struct rcar_du_device_info rzg1_du_r8a7745_info = { @@ -
> > 77,6 +78,7 @@ static const struct rcar_du_device_info
> > rzg1_du_r8a7745_info = {
> > .port = 1,
> > },
> > },
> > + .num_rpf = 4,
> > };
> >
> > static const struct rcar_du_device_info rzg1_du_r8a77470_info = { @@ -
> > 104,6 +106,7 @@ static const struct rcar_du_device_info
> > rzg1_du_r8a77470_info = {
> > .port = 2,
> > },
> > },
> > + .num_rpf = 4,
> > };
> >
> > static const struct rcar_du_device_info rcar_du_r8a774a1_info = { @@ -
> > 133,6 +136,7 @@ static const struct rcar_du_device_info
> > rcar_du_r8a774a1_info = {
> > },
> > },
> > .num_lvds = 1,
> > + .num_rpf = 5,
> > .dpll_mask = BIT(1),
> > };
> >
> > @@ -163,6 +167,7 @@ static const struct rcar_du_device_info
> > rcar_du_r8a774b1_info = {
> > },
> > },
> > .num_lvds = 1,
> > + .num_rpf = 5,
> > .dpll_mask = BIT(1),
> > };
> >
> > @@ -190,6 +195,7 @@ static const struct rcar_du_device_info
> > rcar_du_r8a774c0_info = {
> > },
> > },
> > .num_lvds = 2,
> > + .num_rpf = 4,
> > .lvds_clk_mask = BIT(1) | BIT(0),
> > };
> >
> > @@ -220,6 +226,7 @@ static const struct rcar_du_device_info
> > rcar_du_r8a774e1_info = {
> > },
> > },
> > .num_lvds = 1,
> > + .num_rpf = 5,
> > .dpll_mask = BIT(1),
> > };
> >
> > @@ -272,6 +279,7 @@ static const struct rcar_du_device_info
> > rcar_du_r8a7790_info = {
> > },
> > },
> > .num_lvds = 2,
> > + .num_rpf = 4,
> > };
> >
> > /* M2-W (r8a7791) and M2-N (r8a7793) are identical */ @@ -297,6 +305,7
> > @@ static const struct rcar_du_device_info rcar_du_r8a7791_info = {
> > },
> > },
> > .num_lvds = 1,
> > + .num_rpf = 4,
> > };
> >
> > static const struct rcar_du_device_info rcar_du_r8a7792_info = { @@ -
> > 317,6 +326,7 @@ static const struct rcar_du_device_info
> > rcar_du_r8a7792_info = {
> > .port = 1,
> > },
> > },
> > + .num_rpf = 4,
> > };
> >
> > static const struct rcar_du_device_info rcar_du_r8a7794_info = { @@ -
> > 340,6 +350,
Re: [PATCH v2] drm: rcar-du: Fix Alpha blending issue on Gen3
Quoting Biju Das (2022-04-26 09:41:57) > From: LUU HOAI > > As per R-Car-Gen3_Common_OPC_Customer_Notifications_V30.1.pdf, > unexpected image output(such as incorrect colors or planes being > invisible) can happen on the below conditions, as PnALPHAR register > is not initialized by reset. > > When alpha blending (PpMRm.PpSPIM=0b101) is performed and: > •two Planes are enabled on any DUn (n=0,1,2,3) > oDSPRn= 0x 0031 or 0x 0013 > •or DU0 and DU1 is used for display at the same time > oDSPR0= 0x 0001 and DSPR1= 0x 0003 > oDSPR0= 0x 0003 and DSPR1= 0x 0001 > •or DU2 and DU3(H3 Only) is used for display at the same time > oDSPR2= 0x 0001 and DSPR3= 0x 0003 > oDSPR2= 0x 0003 and DSPR3= 0x 0001 > > This patch set PnALPHAR register to 0 to avoid this issue. > > Signed-off-by: LUU HOAI > Signed-off-by: Biju Das > --- > v1->v2: > * Updated commit description > * Updated the code comments > --- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c > b/drivers/gpu/drm/rcar-du/rcar_du_plane.c > index f214a8b6cfd3..aa80c44dd8d7 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c > @@ -510,6 +510,18 @@ static void rcar_du_plane_setup_format_gen3(struct > rcar_du_group *rgrp, > > rcar_du_plane_write(rgrp, index, PnDDCR4, > state->format->edf | PnDDCR4_CODE); > + > + /* > +* On Gen3, some DU channels have two planes, each being wired to a > +* separate VSPD instance. The DU can then blend two planes. While > +* this feature isn't used by the driver, issues related to alpha > +* blending (such as incorrect colors or planes being invisible) may > +* still occur if the PnALPHAR register has a stale value. Set the > +* register to 0 to avoid this. > +*/ > + Sounds reasonable. > + /* TODO: Check if alpha-blending should be disabled in PnMR. */ How will this be done? Do you have a specific test in mind to determine if it causes issues? Or does it need validating through the hardware teams? > + rcar_du_plane_write(rgrp, index, PnALPHAR, 0); Reviewed-by: Kieran Bingham > } > > static void rcar_du_plane_setup_format(struct rcar_du_group *rgrp, > -- > 2.25.1 >
Re: [PATCH] drm: rcar-du: Drop file name from comment header blocks
Quoting Laurent Pinchart (2022-04-24 22:45:50) > The comment blocks at the beginning of each file have a one-line > summary description of the file that includes the file name. While the > description is useful, the file name only creates opportunities for > mistakes (as seen in rcar_du_vsp.c) without any added value. Drop it. > > Reported-by: Biju Das > Suggested-by: Geert Uytterhoeven > Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham > --- > drivers/gpu/drm/rcar-du/rcar_cmm.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_cmm.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.h| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.c| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.h| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_group.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.h| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_regs.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_vsp.h| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_writeback.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_lvds.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 2 +- > 24 files changed, 24 insertions(+), 24 deletions(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c > b/drivers/gpu/drm/rcar-du/rcar_cmm.c > index 382d53f8a22e..e2a67dda4658 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_cmm.c > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0+ > /* > - * rcar_cmm.c -- R-Car Display Unit Color Management Module > + * R-Car Display Unit Color Management Module > * > * Copyright (C) 2019 Jacopo Mondi > */ > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.h > b/drivers/gpu/drm/rcar-du/rcar_cmm.h > index b5f7ec6db04a..628072acc98b 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_cmm.h > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0+ */ > /* > - * rcar_cmm.h -- R-Car Display Unit Color Management Module > + * R-Car Display Unit Color Management Module > * > * Copyright (C) 2019 Jacopo Mondi > */ > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > index 23e1aedf8dc0..621bbccb95d4 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0+ > /* > - * rcar_du_crtc.c -- R-Car Display Unit CRTCs > + * R-Car Display Unit CRTCs > * > * Copyright (C) 2013-2015 Renesas Electronics Corporation > * > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h > index 66e8839db708..d0f38a8b3561 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0+ */ > /* > - * rcar_du_crtc.h -- R-Car Display Unit CRTCs > + * R-Car Display Unit CRTCs > * > * Copyright (C) 2013-2015 Renesas Electronics Corporation > * > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > index 1bc7325aa356..70d85610d720 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0+ > /* > - * rcar_du_drv.c -- R-Car Display Unit DRM driver > + * R-Car Display Unit DRM driver > * > * Copyright (C) 2013-2015 Renesas Electronics Corporation > * > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h > b/drivers/gpu/drm/rcar-du/rcar_du_drv.h > index 83530721e373..bfad7775d9a1 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0+ */ > /* > - * rcar_du_drv.h -- R-Car Display Unit DRM driver > + * R-Car Display Unit DRM driver > * > * Copyright (C) 2013-2015 Renesas Electronics Corporation > * > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c > b/drivers/gpu/drm/
Re: [PATCH] drm: bridge: adv7511: Enable DRM_BRIDGE_OP_HPD based on HPD interrupt
Quoting Biju Das (2022-04-19 15:24:53) > Connector detection using poll method won't work in case of bridge > attached to the encoder with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, as > the code defaults to HPD. > > Enable DRM_BRIDGE_OP_HPD based on HPD interrupt availability, so that > it will fall back to polling, if HPD is not available. Reviewed-by: Kieran Bingham > > Signed-off-by: Biju Das > --- > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > index 668dcefbae17..b3f10c54e064 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > @@ -1292,8 +1292,10 @@ static int adv7511_probe(struct i2c_client *i2c, const > struct i2c_device_id *id) > goto err_unregister_cec; > > adv7511->bridge.funcs = _bridge_funcs; > - adv7511->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID > - | DRM_BRIDGE_OP_HPD; > + adv7511->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID; > + if (adv7511->i2c_main->irq) > + adv7511->bridge.ops |= DRM_BRIDGE_OP_HPD; > + > adv7511->bridge.of_node = dev->of_node; > adv7511->bridge.type = DRM_MODE_CONNECTOR_HDMIA; > > -- > 2.25.1 >
[PATCH] drm: rcar-du: Extend CMM HDSE documentation
When the CMM is enabled, the HDSE offset is further adjusted to compensate for consumed pixels. Explain this further, with an extra comment at the point the offset is adjusted. Suggested-by: Laurent Pinchart Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index f361a604337f..23e1aedf8dc0 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -300,6 +300,11 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc) | DSMR_DIPM_DISP | DSMR_CSPM; rcar_du_crtc_write(rcrtc, DSMR, dsmr); + /* +* When the CMM is enabled, an additional offset of 25 pixels must be +* subtracted from the HDS (horizontal display start) and HDE +* (horizontal display end) registers. +*/ hdse_offset = 19; if (rcrtc->group->cmms_mask & BIT(rcrtc->index % 2)) hdse_offset += 25; -- 2.32.0
Re: [PATCH v4 3/3] drm/bridge: ti-sn65dsi86: Support hotplug detection
Quoting Doug Anderson (2022-03-23 21:47:17)
> Hi,
>
> On Thu, Mar 17, 2022 at 6:13 AM Kieran Bingham
> wrote:
> >
> > @@ -1241,9 +1350,32 @@ static int ti_sn_bridge_probe(struct
> > auxiliary_device *adev,
> > pdata->bridge.type = pdata->next_bridge->type ==
> > DRM_MODE_CONNECTOR_DisplayPort
> >? DRM_MODE_CONNECTOR_DisplayPort :
> > DRM_MODE_CONNECTOR_eDP;
> >
> > - if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort)
> > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) {
> > pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
> >
> > + if (!pdata->no_hpd)
> > + pdata->bridge.ops |= DRM_BRIDGE_OP_DETECT;
> > + }
> > +
> > + if (!pdata->no_hpd && pdata->irq > 0) {
> > + ret = devm_request_threaded_irq(pdata->dev, pdata->irq,
> > NULL,
> > + ti_sn65dsi86_irq_handler,
> > + IRQF_ONESHOT,
> > "sn65dsi86-irq",
> > + pdata);
> > + if (ret)
> > + return dev_err_probe(pdata->dev, ret,
> > +"Failed to register DP
> > interrupt\n");
> > +
> > + /* Enable IRQ based HPD */
> > + pdata->bridge.ops |= DRM_BRIDGE_OP_HPD;
> > +
> > + /*
> > +* Keep the IRQ disabled initially. It will only be enabled
> > when
> > +* requested through ti_sn_bridge_hpd_enable().
> > +*/
> > + disable_irq(pdata->irq);
>
> Instead, I think you should use `IRQF_NO_AUTOEN` which makes sure that
> no matter what the state of the hardware is your IRQ won't fire
> "early". ...and, of course, it saves a line of code. ;-)
>
> Other than that this looks nice to me now so feel free to add my
Aha, thanks, - didn't realise I could do that. I'll remove the
disable_irq, and move the coment above devm_request_threaded_irq, it
still makes sense there with the flag.
I believe I've got the format handling solved on the NO_CONNECTOR patch
from Rob/Sam, so I'm just waiting for some spare cycles to get back and
clean up - and repost the whole of this work as a new series,
incorporating Sam, Rob and Laurent's work with this on top.
--
Kieran
> Reviewed-by tag after the above is fixed.
>
> -Doug
[PATCH v4 2/3] drm/bridge: ti-sn65dsi86: Implement bridge connector operations
From: Laurent Pinchart
Implement the bridge connector-related .get_edid() operation, and report
the related bridge capabilities and type.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
Changes since v1:
- The connector .get_modes() operation doesn't rely on EDID anymore,
__ti_sn_bridge_get_edid() and ti_sn_bridge_get_edid() got merged
together
- Fix on top of Sam Ravnborg's DRM_BRIDGE_STATE_OPS
Changes since v2: [Kieran]
- Only support EDID on DRM_MODE_CONNECTOR_DisplayPort modes.
Changes since v3: [Kieran]
- Remove PM calls in ti_sn_bridge_get_edid() and simplify
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index c5f020a2d0d3..910bf3d41d2f 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1134,10 +1134,19 @@ static void ti_sn_bridge_atomic_post_disable(struct
drm_bridge *bridge,
pm_runtime_put_sync(pdata->dev);
}
+static struct edid *ti_sn_bridge_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
+
+ return drm_get_edid(connector, >aux.ddc);
+}
+
static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
.attach = ti_sn_bridge_attach,
.detach = ti_sn_bridge_detach,
.mode_valid = ti_sn_bridge_mode_valid,
+ .get_edid = ti_sn_bridge_get_edid,
.atomic_pre_enable = ti_sn_bridge_atomic_pre_enable,
.atomic_enable = ti_sn_bridge_atomic_enable,
.atomic_disable = ti_sn_bridge_atomic_disable,
@@ -1232,6 +1241,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device
*adev,
pdata->bridge.type = pdata->next_bridge->type ==
DRM_MODE_CONNECTOR_DisplayPort
? DRM_MODE_CONNECTOR_DisplayPort :
DRM_MODE_CONNECTOR_eDP;
+ if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort)
+ pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
+
drm_bridge_add(>bridge);
ret = ti_sn_attach_host(pdata);
--
2.32.0
[PATCH v4 3/3] drm/bridge: ti-sn65dsi86: Support hotplug detection
When the SN65DSI86 is used in DisplayPort mode, its output is likely
routed to a DisplayPort connector, which can benefit from hotplug
detection. Support it in such cases, with both polling mode and IRQ
based detection.
The implementation is limited to the bridge operations, as the connector
operations are legacy and new users should use
DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
Changes since v1:
- Document the no_hpd field
- Rely on the SN_HPD_DISABLE_REG default value in the HPD case
- Add a TODO comment regarding IRQ support
[Kieran]
- Fix spelling s/assrted/asserted/
- Only enable HPD on DisplayPort connector.
- Support IRQ based hotplug detect
Changes since v2: [Kieran]
- Use unsigned int for values read by regmap
- Update HPD support warning message
- Only enable OP_HPD if IRQ support enabled.
- Only register IRQ handler during ti_sn_bridge_probe()
- Store IRQ in the struct ti_sn65dsi86
- Register IRQ only when !no-hpd
- Refactor DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_HPD handling
Since v3:
- Fix commit message
- Remove stray debug print
- initialise val in case of regmap read error in ti_sn_bridge_detect
- Ensure pm-runtime reference held for ti_sn_bridge_detect
- Reset status immediately after reading to reduce risk of lost
interrupts during ti_sn65dsi86_irq_handler()
- Reset only the IRQ bits set during ti_sn65dsi86_irq_handler()
- Enable / disable IRQ during hpd_{enable,disable}
This ensures the handler completes before it is disabled.
- Extra comments to detail the notification process in
ti_sn65dsi86_irq_handler()
- Move SN_IRQ_EN_REG handling to hpd_{enable,disable} calls.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 159 +++---
1 file changed, 146 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 910bf3d41d2f..0cc0409dcdd4 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -69,6 +69,7 @@
#define BPP_18_RGBBIT(0)
#define SN_HPD_DISABLE_REG 0x5C
#define HPD_DISABLE BIT(0)
+#define HPD_DEBOUNCED_STATE BIT(4)
#define SN_GPIO_IO_REG 0x5E
#define SN_GPIO_INPUT_SHIFT 4
#define SN_GPIO_OUTPUT_SHIFT 0
@@ -105,10 +106,24 @@
#define SN_PWM_EN_INV_REG 0xA5
#define SN_PWM_INV_MASK BIT(0)
#define SN_PWM_EN_MASKBIT(1)
+#define SN_IRQ_EN_REG 0xE0
+#define IRQ_ENBIT(0)
+#define SN_IRQ_HPD_REG 0xE6
+#define IRQ_HPD_ENBIT(0)
+#define IRQ_HPD_INSERTION_EN BIT(1)
+#define IRQ_HPD_REMOVAL_ENBIT(2)
+#define IRQ_HPD_REPLUG_EN BIT(3)
+#define IRQ_HPD_PLL_UNLOCK_EN BIT(5)
#define SN_AUX_CMD_STATUS_REG 0xF4
#define AUX_IRQ_STATUS_AUX_RPLY_TOUT BIT(3)
#define AUX_IRQ_STATUS_AUX_SHORT BIT(5)
#define AUX_IRQ_STATUS_NAT_I2C_FAIL BIT(6)
+#define SN_IRQ_HPD_STATUS_REG 0xF5
+#define IRQ_HPD_STATUSBIT(0)
+#define IRQ_HPD_INSERTION_STATUS BIT(1)
+#define IRQ_HPD_REMOVAL_STATUSBIT(2)
+#define IRQ_HPD_REPLUG_STATUS BIT(3)
+#define IRQ_PLL_UNLOCKBIT(5)
#define MIN_DSI_CLK_FREQ_MHZ 40
@@ -167,6 +182,12 @@
* @pwm_enabled: Used to track if the PWM signal is currently enabled.
* @pwm_pin_busy: Track if GPIO4 is currently requested for GPIO or PWM.
* @pwm_refclk_freq: Cache for the reference clock input to the PWM.
+ *
+ * @no_hpd: Disable hot-plug detection as instructed by device tree (used
+ *for instance for eDP panels whose HPD signal won't be
asserted
+ *until the panel is turned on, and is thus not usable for
+ *downstream device detection).
+ * @irq: IRQ number for the device.
*/
struct ti_sn65dsi86 {
struct auxiliary_device bridge_aux;
@@ -201,6 +222,9 @@ struct ti_sn65dsi86 {
atomic_tpwm_pin_busy;
#endif
unsigned intpwm_refclk_freq;
+
+ boolno_hpd;
+ int irq;
};
static const struct regmap_range ti_sn65dsi86_volatile_ranges[] = {
@@ -315,23 +339,25 @@ static void ti_sn65dsi86_enable_comms(struct ti_sn65dsi86
*pdata)
ti_sn_bridge_set_refclk_freq(pdata);
/*
-* HPD on this bridge chip is a bit useless. This is an eDP bridge
-* so the HPD is an internal signal that's only there to signal that
-* the panel is done
[PATCH v4 1/3] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
From: Laurent Pinchart Despite the SN65DSI86 being an eDP bridge, on some systems its output is routed to a DisplayPort connector. Enable DisplayPort mode when the next component in the display pipeline is detected as a DisplayPort connector, and disable eDP features in that case. Signed-off-by: Laurent Pinchart Reworked to set bridge type based on the next bridge/connector. Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart Reviewed-by: Douglas Anderson -- Changes since v1/RFC: - Rebased on top of "drm/bridge: ti-sn65dsi86: switch to devm_drm_of_get_bridge" - eDP/DP mode determined from the next bridge connector type. Changes since v2: - Remove setting of Standard DP Scrambler Seed. (It's read-only). - Prevent setting DP_EDP_CONFIGURATION_SET in ti_sn_bridge_atomic_enable() - Use Doug's suggested text for disabling ASSR on DP mode. Changes since v3: - Remove ASSR_CONTROL definition drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 +++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index c892ecba91c7..c5f020a2d0d3 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -93,6 +93,8 @@ #define SN_DATARATE_CONFIG_REG 0x94 #define DP_DATARATE_MASK GENMASK(7, 5) #define DP_DATARATE(x)((x) << 5) +#define SN_TRAINING_SETTING_REG0x95 +#define SCRAMBLE_DISABLE BIT(4) #define SN_ML_TX_MODE_REG 0x96 #define ML_TX_MAIN_LINK_OFF 0 #define ML_TX_NORMAL_MODE BIT(0) @@ -982,6 +984,17 @@ static int ti_sn_link_training(struct ti_sn65dsi86 *pdata, int dp_rate_idx, goto exit; } + /* +* eDP panels use an Alternate Scrambler Seed compared to displays +* hooked up via a full DisplayPort connector. SN65DSI86 only supports +* the alternate scrambler seed, not the normal one, so the only way we +* can support full DisplayPort displays is by fully turning off the +* scrambler. +*/ + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) + regmap_update_bits(pdata->regmap, SN_TRAINING_SETTING_REG, + SCRAMBLE_DISABLE, SCRAMBLE_DISABLE); + /* * We'll try to link train several times. As part of link training * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If @@ -1046,12 +1059,13 @@ static void ti_sn_bridge_atomic_enable(struct drm_bridge *bridge, /* * The SN65DSI86 only supports ASSR Display Authentication method and -* this method is enabled by default. An eDP panel must support this +* this method is enabled for eDP panels. An eDP panel must support this * authentication method. We need to enable this method in the eDP panel * at DisplayPort address 0x0010A prior to link training. */ - drm_dp_dpcd_writeb(>aux, DP_EDP_CONFIGURATION_SET, - DP_ALTERNATE_SCRAMBLER_RESET_ENABLE); + if (pdata->bridge.type == DRM_MODE_CONNECTOR_eDP) + drm_dp_dpcd_writeb(>aux, DP_EDP_CONFIGURATION_SET, + DP_ALTERNATE_SCRAMBLER_RESET_ENABLE); /* Set the DP output format (18 bpp or 24 bpp) */ val = (ti_sn_bridge_get_bpp(old_bridge_state) == 18) ? BPP_18_RGB : 0; @@ -1215,6 +1229,8 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev, pdata->bridge.funcs = _sn_bridge_funcs; pdata->bridge.of_node = np; + pdata->bridge.type = pdata->next_bridge->type == DRM_MODE_CONNECTOR_DisplayPort + ? DRM_MODE_CONNECTOR_DisplayPort : DRM_MODE_CONNECTOR_eDP; drm_bridge_add(>bridge); -- 2.32.0
[PATCH v4 0/3] drm/bridge: ti-sn65dsi86: Support non-eDP DisplayPort connectors
Implement support for non eDP connectors on the TI-SN65DSI86 bridge, and provide IRQ based hotplug detect to identify when the connector is present. no-hpd is extended to be the default behaviour for non DisplayPort connectors. This series is based upon Sam Ravnborgs and Rob Clarks series [0] to support DRM_BRIDGE_STATE_OPS and NO_CONNECTOR support on the SN65DSI86, however some extra modifications have been made on the top of Sam's series to fix compile breakage and the NO_CONNECTOR support. A full branch with these changes is available at [1] As in v3, I have not taken ownership of the patches at [0], so it would be good to hear if Sam has any plans to revive or push this series. These patches are not expected to be integrated without [0]. [0] https://lore.kernel.org/all/20220206154405.124-1-...@ravnborg.org/ [1] git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git branch: kbingham/drm-misc/next/sn65dsi86/hpd Kieran Bingham (1): drm/bridge: ti-sn65dsi86: Support hotplug detection Laurent Pinchart (2): drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode drm/bridge: ti-sn65dsi86: Implement bridge connector operations drivers/gpu/drm/bridge/ti-sn65dsi86.c | 191 -- 1 file changed, 176 insertions(+), 15 deletions(-) -- 2.32.0
Re: [PATCH v3 2/3] drm/bridge: ti-sn65dsi86: Implement bridge connector operations
Hi Doug,
Quoting Doug Anderson (2022-03-10 23:10:20)
> Hi,
>
> On Thu, Mar 10, 2022 at 7:22 AM Kieran Bingham
> wrote:
> >
> > From: Laurent Pinchart
> >
> > Implement the bridge connector-related .get_edid() operation, and report
> > the related bridge capabilities and type.
> >
> > Signed-off-by: Laurent Pinchart
> > Signed-off-by: Kieran Bingham
> > ---
> > Changes since v1:
> >
> > - The connector .get_modes() operation doesn't rely on EDID anymore,
> > __ti_sn_bridge_get_edid() and ti_sn_bridge_get_edid() got merged
> > together
> > - Fix on top of Sam Ravnborg's DRM_BRIDGE_STATE_OPS
> >
> > Changes since v2: [Kieran]
> > - Only support EDID on DRM_MODE_CONNECTOR_DisplayPort modes.
> >
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index 93b54fcba8ba..d581c820e5d8 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -1135,10 +1135,24 @@ static void ti_sn_bridge_atomic_post_disable(struct
> > drm_bridge *bridge,
> > pm_runtime_put_sync(pdata->dev);
> > }
> >
> > +static struct edid *ti_sn_bridge_get_edid(struct drm_bridge *bridge,
> > + struct drm_connector *connector)
> > +{
> > + struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > + struct edid *edid;
> > +
> > + pm_runtime_get_sync(pdata->dev);
> > + edid = drm_get_edid(connector, >aux.ddc);
> > + pm_runtime_put_autosuspend(pdata->dev);
>
> I'm 99% sure that the pm_runtime calls here are not needed and can be
> removed.. The AUX transfer function handles the pm_runtime_get_sync()
> and it also does the "put" with autosuspend so that the whole EDID can
> be read without constantly powering the bridge up and down again.
Yes, digging through I agree - It does look like this may be the case.
ti_sn_aux_transfer() certainly looks like it handles the pm_runtime_
calls, and drm_get_edid() looks like it goes through there from the core
using the standard i2c interface, with nothing else expected to touch
the hw between.
So that more or less simplifies this function to just
return drm_get_edid(connector, >aux.ddc);
Thanks
--
Kieran
Re: [PATCH v3 3/3] drm/bridge: ti-sn65dsi86: Support hotplug detection
Hi Doug,
Quoting Doug Anderson (2022-03-10 23:10:12)
> Hi,
>
> On Thu, Mar 10, 2022 at 7:22 AM Kieran Bingham
> wrote:
> >
> > @@ -1135,6 +1161,36 @@ static void ti_sn_bridge_atomic_post_disable(struct
> > drm_bridge *bridge,
> > pm_runtime_put_sync(pdata->dev);
> > }
> >
> > +static enum drm_connector_status ti_sn_bridge_detect(struct drm_bridge
> > *bridge)
> > +{
> > + struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > + int val;
> > +
> > + regmap_read(pdata->regmap, SN_HPD_DISABLE_REG, );
>
> Don't you need a pm_runtime_get_sync() before this and a
> put_autosuspend() after? The "detect" will be used in the yes-HPD but
> no-IRQ case, right? In that case there's nobody holding the pm_runtime
> reference.
Hrm ... I'll have to dig on this a bit. The polling is done by the DRM
core, so indeed I suspect it could be done outside of a context that
holds the pm runtime reference.
Equally a get and put on the reference doesn't hurt even if it's already
taken, so perhaps it's best to add it, but I'll try to confirm it's
requirement first.
> Also, a nit that it'd be great if you error checked the regmap_read().
> I know this driver isn't very good about it, but it's probably
> something to get better. i2c transactions can fail. I guess another
> alternative would be to init "val" to 0...
It's a good point indeed. If we can't read the device we should return
disconnected.
>
>
> > + return val & HPD_DEBOUNCED_STATE ? connector_status_connected
> > +: connector_status_disconnected;
> > +}
> > +
> > +static void ti_sn_bridge_hpd_enable(struct drm_bridge *bridge)
> > +{
> > + struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > +
> > + /* The device must remain active for HPD to function */
> > + pm_runtime_get_sync(pdata->dev);
> > + regmap_write(pdata->regmap, SN_IRQ_HPD_REG,
> > +IRQ_HPD_EN | IRQ_HPD_INSERTION_EN |
> > +IRQ_HPD_REMOVAL_EN | IRQ_HPD_REPLUG_EN);
> > +}
> > +
> > +static void ti_sn_bridge_hpd_disable(struct drm_bridge *bridge)
> > +{
> > + struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > +
> > + regmap_write(pdata->regmap, SN_IRQ_HPD_REG, 0);
> > + pm_runtime_put_autosuspend(pdata->dev);
>
> Before doing the pm_runtime_put_autosuspend() it feels like you should
> ensure that the interrupt has finished. Otherwise we could be midway
> through processing an interrupt and the pm_runtime reference could go
> away, right? Maybe we just disable the irq which I think will wait for
> anything outstanding to finish?
Should the IRQ handler also call pm_runtime_get/put then?
> > @@ -1223,6 +1282,34 @@ static int ti_sn_bridge_parse_dsi_host(struct
> > ti_sn65dsi86 *pdata)
> > return 0;
> > }
> >
> > +static irqreturn_t ti_sn65dsi86_irq_handler(int irq, void *arg)
> > +{
> > + struct ti_sn65dsi86 *pdata = arg;
> > + int ret;
> > + unsigned int hpd;
> > +
> > + ret = regmap_read(pdata->regmap, SN_IRQ_HPD_STATUS_REG, );
> > + if (ret || !hpd)
> > + return IRQ_NONE;
> > +
> > + if (hpd & IRQ_HPD_INSERTION_STATUS)
> > + drm_bridge_hpd_notify(>bridge,
> > connector_status_connected);
> > +
> > + if (hpd & IRQ_HPD_REMOVAL_STATUS)
> > + drm_bridge_hpd_notify(>bridge,
> > connector_status_disconnected);
> > +
> > + /* When replugged, ensure we trigger a detect to update the display
> > */
> > + if (hpd & IRQ_HPD_REPLUG_STATUS)
> > + drm_bridge_hpd_notify(>bridge,
> > connector_status_disconnected);
>
> How does the ordering work here if _both_ insertion and removal are
> asserted? Is that somehow not possible? Should this be "else if" type
> statements then, or give a warn if more than one bit is set, or ... ?
As I understand it, that would trigger a REPLUG IRQ. However this is one
part I quite disliked about the drm_bridge_hpd_notify. The values here
are not taken as the hardware state anyway. A call to drm_bridge_hpd_notify
will
trigger a call on the detect function so a further read will occur to
determine the current state using the same function as is used with
polling.
The IRQ handler only cuts out the polling as far as I see.
> > + /* reset the status registers */
> > + regmap_write(pdata->regmap, SN_IRQ_HPD_STATUS_REG,
> > +
Re: [PATCH v3 0/3] drm/bridge: ti-sn65dsi86: Support non-eDP DisplayPort connectors
Hi Doug, Sam, Quoting Doug Anderson (2022-03-10 23:21:38) > Hi, > > On Thu, Mar 10, 2022 at 7:22 AM Kieran Bingham > wrote: > > > > Implement support for non eDP connectors on the TI-SN65DSI86 bridge, and > > provide IRQ based hotplug detect to identify when the connector is > > present. > > > > no-hpd is extended to be the default behaviour for non DisplayPort > > connectors. > > > > This series is based upon Sam Ravnborgs and Rob Clarks series [0] to > > support DRM_BRIDGE_STATE_OPS and NO_CONNECTOR support on the SN65DSI86, > > however some extra modifications have been made on the top of Sam's > > series to fix compile breakage and the NO_CONNECTOR support. > > This confused me a little bit. As far as I know Rob's series is > abandoned and he's not working on it. I assume that Sam will > eventually re-post his series, but it had unsolved problems and the > bpp solution he had totally didn't work because nobody was setting > "output_bus_cfg.format" [1]. Did you solve that? ...or you're just > going to let your patches sit there and hope that Sam will solve the > problem and re-post his series? I applied Sam's series, and fixed it to work for me. It looked like Rob's patch had been rolled into Sam's series, and I didn't take ownership of Sam's series, as I assume he'll continue on it, but I haven't asked or heard either way yet. Sam's series is only from February, so I would not presume to consider that it is abandoned yet. The changes I made have either already been highlighted by the build bots on Sam's series, or I have replied to his series with the fixes I made. > I'll admit I didn't go through your git tree to figure out if you > solved it some way. If you did, I would have assumed you'd have > re-posted his patches in your series w/ the solution... My changes to his series are on my branch as separate squash: commits so they're easy to see or take if Sam wants to collect the fixes, but there's nothing complex there, that isn't easily solved locally. If Sam's series is abandoned, then I guess my 'Implement SN65DSI86 IRQ HPD' patch will now have a 11:1 ratio of patches that I have to take custodianship of vs author myself ;-) (And even most of the work I have done has been squashed into Laurent's patches already) Sam, What is your plan on your series at [1], are you still actively planning to work on it? -- Kieran > [1] > https://lore.kernel.org/r/CAD=FV=WW6HWLOD9AzTpjwva9UHY=ar+labewqjqznz6nbb4...@mail.gmail.com/ > > -Doug
Re: [PATCH v3 3/3] drm/bridge: ti-sn65dsi86: Support hotplug detection
Hi Laurent
Quoting Laurent Pinchart (2022-03-10 16:42:48)
> Hi Kieran,
>
> Thank you for the patch.
>
> On Thu, Mar 10, 2022 at 03:22:27PM +, Kieran Bingham wrote:
> > When the SN65DSI86 is used in DisplayPort mode, its output is likely
> > routed to a DisplayPort connector, which can benefit from hotplug
> > detection. Support it in such cases, with polling mode only for now.
>
> Don't we support IRQ mode too now ?
Ah yes, I missed this for an update.
> > The implementation is limited to the bridge operations, as the connector
> > operations are legacy and new users should use
> > DRM_BRIDGE_ATTACH_NO_CONNECTOR.
> >
> > Signed-off-by: Laurent Pinchart
> > Signed-off-by: Kieran Bingham
> > ---
> > Changes since v1:
> >
> > - Document the no_hpd field
> > - Rely on the SN_HPD_DISABLE_REG default value in the HPD case
> > - Add a TODO comment regarding IRQ support
> > [Kieran]
> > - Fix spelling s/assrted/asserted/
> > - Only enable HPD on DisplayPort connector.
> > - Support IRQ based hotplug detect
> >
> > Changes since v2: [Kieran]
> > - Use unsigned int for values read by regmap
> > - Update HPD support warning message
> > - Only enable OP_HPD if IRQ support enabled.
> > - Only register IRQ handler during ti_sn_bridge_probe()
> > - Store IRQ in the struct ti_sn65dsi86
> > - Register IRQ only when !no-hpd
> > - Refactor DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_HPD handling
> >
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 142 +++---
> > 1 file changed, 129 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index d581c820e5d8..328a48f09f97 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -70,6 +70,7 @@
> > #define BPP_18_RGB BIT(0)
> > #define SN_HPD_DISABLE_REG 0x5C
> > #define HPD_DISABLE BIT(0)
> > +#define HPD_DEBOUNCED_STATE BIT(4)
> > #define SN_GPIO_IO_REG 0x5E
> > #define SN_GPIO_INPUT_SHIFT 4
> > #define SN_GPIO_OUTPUT_SHIFT0
> > @@ -106,10 +107,24 @@
> > #define SN_PWM_EN_INV_REG0xA5
> > #define SN_PWM_INV_MASK BIT(0)
> > #define SN_PWM_EN_MASK BIT(1)
> > +#define SN_IRQ_EN_REG0xE0
> > +#define IRQ_EN BIT(0)
> > +#define SN_IRQ_HPD_REG 0xE6
> > +#define IRQ_HPD_EN BIT(0)
> > +#define IRQ_HPD_INSERTION_ENBIT(1)
> > +#define IRQ_HPD_REMOVAL_EN BIT(2)
> > +#define IRQ_HPD_REPLUG_EN BIT(3)
> > +#define IRQ_HPD_PLL_UNLOCK_EN BIT(5)
> > #define SN_AUX_CMD_STATUS_REG0xF4
> > #define AUX_IRQ_STATUS_AUX_RPLY_TOUTBIT(3)
> > #define AUX_IRQ_STATUS_AUX_SHORTBIT(5)
> > #define AUX_IRQ_STATUS_NAT_I2C_FAIL BIT(6)
> > +#define SN_IRQ_HPD_STATUS_REG0xF5
> > +#define IRQ_HPD_STATUS BIT(0)
> > +#define IRQ_HPD_INSERTION_STATUSBIT(1)
> > +#define IRQ_HPD_REMOVAL_STATUS BIT(2)
> > +#define IRQ_HPD_REPLUG_STATUS BIT(3)
> > +#define IRQ_PLL_UNLOCK BIT(5)
> >
> > #define MIN_DSI_CLK_FREQ_MHZ 40
> >
> > @@ -168,6 +183,12 @@
> > * @pwm_enabled: Used to track if the PWM signal is currently enabled.
> > * @pwm_pin_busy: Track if GPIO4 is currently requested for GPIO or PWM.
> > * @pwm_refclk_freq: Cache for the reference clock input to the PWM.
> > + *
> > + * @no_hpd: Disable hot-plug detection as instructed by device tree
> > (used
> > + *for instance for eDP panels whose HPD signal won't be
> > asserted
> > + *until the panel is turned on, and is thus not usable for
> > + *downstream device detection).
> > + * @irq: IRQ number for the device.
> > */
> > struct ti_sn65dsi86 {
> > struct auxiliary_device bridge_aux;
> > @@ -202,6 +223,9 @@ struct ti_sn65dsi86 {
> > atomic_tpwm_pin_busy;
> > #endif
> >
Re: [PATCH v3 3/3] drm/bridge: ti-sn65dsi86: Support hotplug detection
Quoting Kieran Bingham (2022-03-10 15:22:27)
> When the SN65DSI86 is used in DisplayPort mode, its output is likely
> routed to a DisplayPort connector, which can benefit from hotplug
> detection. Support it in such cases, with polling mode only for now.
>
> The implementation is limited to the bridge operations, as the connector
> operations are legacy and new users should use
> DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Kieran Bingham
> ---
> Changes since v1:
>
> - Document the no_hpd field
> - Rely on the SN_HPD_DISABLE_REG default value in the HPD case
> - Add a TODO comment regarding IRQ support
> [Kieran]
> - Fix spelling s/assrted/asserted/
> - Only enable HPD on DisplayPort connector.
> - Support IRQ based hotplug detect
>
> Changes since v2: [Kieran]
> - Use unsigned int for values read by regmap
> - Update HPD support warning message
> - Only enable OP_HPD if IRQ support enabled.
> - Only register IRQ handler during ti_sn_bridge_probe()
> - Store IRQ in the struct ti_sn65dsi86
> - Register IRQ only when !no-hpd
> - Refactor DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_HPD handling
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 142 +++---
> 1 file changed, 129 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index d581c820e5d8..328a48f09f97 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -70,6 +70,7 @@
> #define BPP_18_RGBBIT(0)
> #define SN_HPD_DISABLE_REG 0x5C
> #define HPD_DISABLE BIT(0)
> +#define HPD_DEBOUNCED_STATE BIT(4)
> #define SN_GPIO_IO_REG 0x5E
> #define SN_GPIO_INPUT_SHIFT 4
> #define SN_GPIO_OUTPUT_SHIFT 0
> @@ -106,10 +107,24 @@
> #define SN_PWM_EN_INV_REG 0xA5
> #define SN_PWM_INV_MASK BIT(0)
> #define SN_PWM_EN_MASKBIT(1)
> +#define SN_IRQ_EN_REG 0xE0
> +#define IRQ_ENBIT(0)
> +#define SN_IRQ_HPD_REG 0xE6
> +#define IRQ_HPD_ENBIT(0)
> +#define IRQ_HPD_INSERTION_EN BIT(1)
> +#define IRQ_HPD_REMOVAL_ENBIT(2)
> +#define IRQ_HPD_REPLUG_EN BIT(3)
> +#define IRQ_HPD_PLL_UNLOCK_EN BIT(5)
> #define SN_AUX_CMD_STATUS_REG 0xF4
> #define AUX_IRQ_STATUS_AUX_RPLY_TOUT BIT(3)
> #define AUX_IRQ_STATUS_AUX_SHORT BIT(5)
> #define AUX_IRQ_STATUS_NAT_I2C_FAIL BIT(6)
> +#define SN_IRQ_HPD_STATUS_REG 0xF5
> +#define IRQ_HPD_STATUSBIT(0)
> +#define IRQ_HPD_INSERTION_STATUS BIT(1)
> +#define IRQ_HPD_REMOVAL_STATUSBIT(2)
> +#define IRQ_HPD_REPLUG_STATUS BIT(3)
> +#define IRQ_PLL_UNLOCKBIT(5)
>
> #define MIN_DSI_CLK_FREQ_MHZ 40
>
> @@ -168,6 +183,12 @@
> * @pwm_enabled: Used to track if the PWM signal is currently enabled.
> * @pwm_pin_busy: Track if GPIO4 is currently requested for GPIO or PWM.
> * @pwm_refclk_freq: Cache for the reference clock input to the PWM.
> + *
> + * @no_hpd: Disable hot-plug detection as instructed by device tree
> (used
> + *for instance for eDP panels whose HPD signal won't be
> asserted
> + *until the panel is turned on, and is thus not usable for
> + *downstream device detection).
> + * @irq: IRQ number for the device.
> */
> struct ti_sn65dsi86 {
> struct auxiliary_device bridge_aux;
> @@ -202,6 +223,9 @@ struct ti_sn65dsi86 {
> atomic_tpwm_pin_busy;
> #endif
> unsigned intpwm_refclk_freq;
> +
> + boolno_hpd;
> + int irq;
> };
>
> static const struct regmap_range ti_sn65dsi86_volatile_ranges[] = {
> @@ -316,23 +340,25 @@ static void ti_sn65dsi86_enable_comms(struct
> ti_sn65dsi86 *pdata)
> ti_sn_bridge_set_refclk_freq(pdata);
>
> /*
> -* HPD on this bridge chip is a bit useless. This is an eDP bridge
> -* so the HPD is an internal signal that's only there to signal that
> -* the panel is done powering up. ...but the bridge chip debounces
> -* this
[PATCH v3 2/3] drm/bridge: ti-sn65dsi86: Implement bridge connector operations
From: Laurent Pinchart
Implement the bridge connector-related .get_edid() operation, and report
the related bridge capabilities and type.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
Changes since v1:
- The connector .get_modes() operation doesn't rely on EDID anymore,
__ti_sn_bridge_get_edid() and ti_sn_bridge_get_edid() got merged
together
- Fix on top of Sam Ravnborg's DRM_BRIDGE_STATE_OPS
Changes since v2: [Kieran]
- Only support EDID on DRM_MODE_CONNECTOR_DisplayPort modes.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 93b54fcba8ba..d581c820e5d8 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1135,10 +1135,24 @@ static void ti_sn_bridge_atomic_post_disable(struct
drm_bridge *bridge,
pm_runtime_put_sync(pdata->dev);
}
+static struct edid *ti_sn_bridge_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
+ struct edid *edid;
+
+ pm_runtime_get_sync(pdata->dev);
+ edid = drm_get_edid(connector, >aux.ddc);
+ pm_runtime_put_autosuspend(pdata->dev);
+
+ return edid;
+}
+
static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
.attach = ti_sn_bridge_attach,
.detach = ti_sn_bridge_detach,
.mode_valid = ti_sn_bridge_mode_valid,
+ .get_edid = ti_sn_bridge_get_edid,
.atomic_pre_enable = ti_sn_bridge_atomic_pre_enable,
.atomic_enable = ti_sn_bridge_atomic_enable,
.atomic_disable = ti_sn_bridge_atomic_disable,
@@ -1233,6 +1247,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device
*adev,
pdata->bridge.type = pdata->next_bridge->type ==
DRM_MODE_CONNECTOR_DisplayPort
? DRM_MODE_CONNECTOR_DisplayPort :
DRM_MODE_CONNECTOR_eDP;
+ if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort)
+ pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
+
drm_bridge_add(>bridge);
ret = ti_sn_attach_host(pdata);
--
2.32.0
[PATCH v3 3/3] drm/bridge: ti-sn65dsi86: Support hotplug detection
When the SN65DSI86 is used in DisplayPort mode, its output is likely
routed to a DisplayPort connector, which can benefit from hotplug
detection. Support it in such cases, with polling mode only for now.
The implementation is limited to the bridge operations, as the connector
operations are legacy and new users should use
DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
Changes since v1:
- Document the no_hpd field
- Rely on the SN_HPD_DISABLE_REG default value in the HPD case
- Add a TODO comment regarding IRQ support
[Kieran]
- Fix spelling s/assrted/asserted/
- Only enable HPD on DisplayPort connector.
- Support IRQ based hotplug detect
Changes since v2: [Kieran]
- Use unsigned int for values read by regmap
- Update HPD support warning message
- Only enable OP_HPD if IRQ support enabled.
- Only register IRQ handler during ti_sn_bridge_probe()
- Store IRQ in the struct ti_sn65dsi86
- Register IRQ only when !no-hpd
- Refactor DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_HPD handling
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 142 +++---
1 file changed, 129 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index d581c820e5d8..328a48f09f97 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -70,6 +70,7 @@
#define BPP_18_RGBBIT(0)
#define SN_HPD_DISABLE_REG 0x5C
#define HPD_DISABLE BIT(0)
+#define HPD_DEBOUNCED_STATE BIT(4)
#define SN_GPIO_IO_REG 0x5E
#define SN_GPIO_INPUT_SHIFT 4
#define SN_GPIO_OUTPUT_SHIFT 0
@@ -106,10 +107,24 @@
#define SN_PWM_EN_INV_REG 0xA5
#define SN_PWM_INV_MASK BIT(0)
#define SN_PWM_EN_MASKBIT(1)
+#define SN_IRQ_EN_REG 0xE0
+#define IRQ_ENBIT(0)
+#define SN_IRQ_HPD_REG 0xE6
+#define IRQ_HPD_ENBIT(0)
+#define IRQ_HPD_INSERTION_EN BIT(1)
+#define IRQ_HPD_REMOVAL_ENBIT(2)
+#define IRQ_HPD_REPLUG_EN BIT(3)
+#define IRQ_HPD_PLL_UNLOCK_EN BIT(5)
#define SN_AUX_CMD_STATUS_REG 0xF4
#define AUX_IRQ_STATUS_AUX_RPLY_TOUT BIT(3)
#define AUX_IRQ_STATUS_AUX_SHORT BIT(5)
#define AUX_IRQ_STATUS_NAT_I2C_FAIL BIT(6)
+#define SN_IRQ_HPD_STATUS_REG 0xF5
+#define IRQ_HPD_STATUSBIT(0)
+#define IRQ_HPD_INSERTION_STATUS BIT(1)
+#define IRQ_HPD_REMOVAL_STATUSBIT(2)
+#define IRQ_HPD_REPLUG_STATUS BIT(3)
+#define IRQ_PLL_UNLOCKBIT(5)
#define MIN_DSI_CLK_FREQ_MHZ 40
@@ -168,6 +183,12 @@
* @pwm_enabled: Used to track if the PWM signal is currently enabled.
* @pwm_pin_busy: Track if GPIO4 is currently requested for GPIO or PWM.
* @pwm_refclk_freq: Cache for the reference clock input to the PWM.
+ *
+ * @no_hpd: Disable hot-plug detection as instructed by device tree (used
+ *for instance for eDP panels whose HPD signal won't be
asserted
+ *until the panel is turned on, and is thus not usable for
+ *downstream device detection).
+ * @irq: IRQ number for the device.
*/
struct ti_sn65dsi86 {
struct auxiliary_device bridge_aux;
@@ -202,6 +223,9 @@ struct ti_sn65dsi86 {
atomic_tpwm_pin_busy;
#endif
unsigned intpwm_refclk_freq;
+
+ boolno_hpd;
+ int irq;
};
static const struct regmap_range ti_sn65dsi86_volatile_ranges[] = {
@@ -316,23 +340,25 @@ static void ti_sn65dsi86_enable_comms(struct ti_sn65dsi86
*pdata)
ti_sn_bridge_set_refclk_freq(pdata);
/*
-* HPD on this bridge chip is a bit useless. This is an eDP bridge
-* so the HPD is an internal signal that's only there to signal that
-* the panel is done powering up. ...but the bridge chip debounces
-* this signal by between 100 ms and 400 ms (depending on process,
-* voltage, and temperate--I measured it at about 200 ms). One
+* As this is an eDP bridge, the output will be connected to a fixed
+* panel in most systems. HPD is in that case only an internal signal
+* to signal that the panel is done powering up. The bridge chip
+* debounces this signal by between 100 ms and 400 ms (depending on
+* process, voltage, and temperate--I measured it at about 200 ms). One
* particular panel asserted HPD 84 ms after it was powered
[PATCH v3 1/3] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
From: Laurent Pinchart Despite the SN65DSI86 being an eDP bridge, on some systems its output is routed to a DisplayPort connector. Enable DisplayPort mode when the next component in the display pipeline is detected as a DisplayPort connector, and disable eDP features in that case. Signed-off-by: Laurent Pinchart Reworked to set bridge type based on the next bridge/connector. Signed-off-by: Kieran Bingham -- Changes since v1/RFC: - Rebased on top of "drm/bridge: ti-sn65dsi86: switch to devm_drm_of_get_bridge" - eDP/DP mode determined from the next bridge connector type. Changes since v2: - Remove setting of Standard DP Scrambler Seed. (It's read-only). - Prevent setting DP_EDP_CONFIGURATION_SET in ti_sn_bridge_atomic_enable() - Use Doug's suggested text for disabling ASSR on DP mode. drivers/gpu/drm/bridge/ti-sn65dsi86.c | 23 --- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index c892ecba91c7..93b54fcba8ba 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -62,6 +62,7 @@ #define SN_LN_ASSIGN_REG 0x59 #define LN_ASSIGN_WIDTH 2 #define SN_ENH_FRAME_REG 0x5A +#define ASSR_CONTROL BIT(0) #define VSTREAM_ENABLEBIT(3) #define LN_POLRS_OFFSET 4 #define LN_POLRS_MASK 0xf0 @@ -93,6 +94,8 @@ #define SN_DATARATE_CONFIG_REG 0x94 #define DP_DATARATE_MASK GENMASK(7, 5) #define DP_DATARATE(x)((x) << 5) +#define SN_TRAINING_SETTING_REG0x95 +#define SCRAMBLE_DISABLE BIT(4) #define SN_ML_TX_MODE_REG 0x96 #define ML_TX_MAIN_LINK_OFF 0 #define ML_TX_NORMAL_MODE BIT(0) @@ -982,6 +985,17 @@ static int ti_sn_link_training(struct ti_sn65dsi86 *pdata, int dp_rate_idx, goto exit; } + /* +* eDP panels use an Alternate Scrambler Seed compared to displays +* hooked up via a full DisplayPort connector. SN65DSI86 only supports +* the alternate scrambler seed, not the normal one, so the only way we +* can support full DisplayPort displays is by fully turning off the +* scrambler. +*/ + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) + regmap_update_bits(pdata->regmap, SN_TRAINING_SETTING_REG, + SCRAMBLE_DISABLE, SCRAMBLE_DISABLE); + /* * We'll try to link train several times. As part of link training * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If @@ -1046,12 +1060,13 @@ static void ti_sn_bridge_atomic_enable(struct drm_bridge *bridge, /* * The SN65DSI86 only supports ASSR Display Authentication method and -* this method is enabled by default. An eDP panel must support this +* this method is enabled for eDP panels. An eDP panel must support this * authentication method. We need to enable this method in the eDP panel * at DisplayPort address 0x0010A prior to link training. */ - drm_dp_dpcd_writeb(>aux, DP_EDP_CONFIGURATION_SET, - DP_ALTERNATE_SCRAMBLER_RESET_ENABLE); + if (pdata->bridge.type == DRM_MODE_CONNECTOR_eDP) + drm_dp_dpcd_writeb(>aux, DP_EDP_CONFIGURATION_SET, + DP_ALTERNATE_SCRAMBLER_RESET_ENABLE); /* Set the DP output format (18 bpp or 24 bpp) */ val = (ti_sn_bridge_get_bpp(old_bridge_state) == 18) ? BPP_18_RGB : 0; @@ -1215,6 +1230,8 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev, pdata->bridge.funcs = _sn_bridge_funcs; pdata->bridge.of_node = np; + pdata->bridge.type = pdata->next_bridge->type == DRM_MODE_CONNECTOR_DisplayPort + ? DRM_MODE_CONNECTOR_DisplayPort : DRM_MODE_CONNECTOR_eDP; drm_bridge_add(>bridge); -- 2.32.0
[PATCH v3 0/3] drm/bridge: ti-sn65dsi86: Support non-eDP DisplayPort connectors
Implement support for non eDP connectors on the TI-SN65DSI86 bridge, and provide IRQ based hotplug detect to identify when the connector is present. no-hpd is extended to be the default behaviour for non DisplayPort connectors. This series is based upon Sam Ravnborgs and Rob Clarks series [0] to support DRM_BRIDGE_STATE_OPS and NO_CONNECTOR support on the SN65DSI86, however some extra modifications have been made on the top of Sam's series to fix compile breakage and the NO_CONNECTOR support. A full branch with these changes is available at [1] [0] https://lore.kernel.org/all/20220206154405.124-1-...@ravnborg.org/ [1] git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git branch: kbingham/drm-misc/next/sn65dsi86/hpd Kieran Bingham (1): drm/bridge: ti-sn65dsi86: Support hotplug detection Laurent Pinchart (2): drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode drm/bridge: ti-sn65dsi86: Implement bridge connector operations drivers/gpu/drm/bridge/ti-sn65dsi86.c | 180 +++--- 1 file changed, 165 insertions(+), 15 deletions(-) -- 2.32.0
Re: [PATCH v2 3/4] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
Quoting Kieran Bingham (2022-03-10 14:04:09) > Quoting Kieran Bingham (2022-03-07 17:59:54) > > From: Laurent Pinchart > > > > Despite the SN65DSI86 being an eDP bridge, on some systems its output is > > routed to a DisplayPort connector. Enable DisplayPort mode when the next > > component in the display pipeline is detected as a DisplayPort > > connector, and disable eDP features in that case. > > > > Signed-off-by: Laurent Pinchart > > Reworked to set bridge type based on the next bridge/connector. > > Signed-off-by: Kieran Bingham > > -- > > Changes since v1/RFC: > > - Rebased on top of "drm/bridge: ti-sn65dsi86: switch to > >devm_drm_of_get_bridge" > > - eDP/DP mode determined from the next bridge connector type. > > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16 +++- > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > index 29f5f7123ed9..461f963faa0b 100644 > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > @@ -60,6 +60,7 @@ > > #define SN_LN_ASSIGN_REG 0x59 > > #define LN_ASSIGN_WIDTH 2 > > #define SN_ENH_FRAME_REG 0x5A > > +#define ASSR_CONTROL BIT(0) > > #define VSTREAM_ENABLEBIT(3) > > #define LN_POLRS_OFFSET 4 > > #define LN_POLRS_MASK 0xf0 > > @@ -91,6 +92,8 @@ > > #define SN_DATARATE_CONFIG_REG 0x94 > > #define DP_DATARATE_MASK GENMASK(7, 5) > > #define DP_DATARATE(x)((x) << 5) > > +#define SN_TRAINING_SETTING_REG0x95 > > +#define SCRAMBLE_DISABLE BIT(4) > > #define SN_ML_TX_MODE_REG 0x96 > > #define ML_TX_MAIN_LINK_OFF 0 > > #define ML_TX_NORMAL_MODE BIT(0) > > @@ -1005,6 +1008,11 @@ static int ti_sn_link_training(struct ti_sn65dsi86 > > *pdata, int dp_rate_idx, > > regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG, > >DP_DATARATE_MASK, DP_DATARATE(dp_rate_idx)); > > > > + /* For DisplayPort, use the standard DP scrambler seed. */ > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > > + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, > > + ASSR_CONTROL, 0); > > + > > /* enable DP PLL */ > > regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1); > > > > @@ -1016,6 +1024,11 @@ static int ti_sn_link_training(struct ti_sn65dsi86 > > *pdata, int dp_rate_idx, > > goto exit; > > } > > > > + /* For DisplayPort, disable scrambling mode. */ > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > > + regmap_update_bits(pdata->regmap, SN_TRAINING_SETTING_REG, > > + SCRAMBLE_DISABLE, SCRAMBLE_DISABLE); > > + > > /* > > * We'll try to link train several times. As part of link training > > * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If > > @@ -1260,7 +1273,8 @@ static int ti_sn_bridge_probe(struct auxiliary_device > > *adev, > > pdata->bridge.funcs = _sn_bridge_funcs; > > pdata->bridge.of_node = np; > > pdata->bridge.ops = DRM_BRIDGE_OP_EDID; > > - pdata->bridge.type = DRM_MODE_CONNECTOR_eDP; > > + pdata->bridge.type = pdata->next_bridge->type == > > DRM_MODE_CONNECTOR_DisplayPort > > + ? DRM_MODE_CONNECTOR_DisplayPort : > > DRM_MODE_CONNECTOR_eDP; > > Anyone know if there's any expectation of other types here? Or is it > just as safe to do: > > pdata->bridge.type = pdata->next_bridge->type; > > To achieve the same effect? Unfortunately, it would create nicer code - but I don't think it's exactly right. It leaves the definition of our bridge type to the connector type of the panel. While the SN65DSI86 can /only/ be either eDP or DisplayPort. So I'll keep this conditional on if the next connector is DRM_MODE_CONNECTOR_DisplayPort. > > -- > Kieran > > > > > > drm_bridge_add(>bridge); > > > > -- > > 2.32.0 > >
Re: [PATCH v2 3/4] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
Quoting Kieran Bingham (2022-03-07 17:59:54) > From: Laurent Pinchart > > Despite the SN65DSI86 being an eDP bridge, on some systems its output is > routed to a DisplayPort connector. Enable DisplayPort mode when the next > component in the display pipeline is detected as a DisplayPort > connector, and disable eDP features in that case. > > Signed-off-by: Laurent Pinchart > Reworked to set bridge type based on the next bridge/connector. > Signed-off-by: Kieran Bingham > -- > Changes since v1/RFC: > - Rebased on top of "drm/bridge: ti-sn65dsi86: switch to >devm_drm_of_get_bridge" > - eDP/DP mode determined from the next bridge connector type. > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index 29f5f7123ed9..461f963faa0b 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -60,6 +60,7 @@ > #define SN_LN_ASSIGN_REG 0x59 > #define LN_ASSIGN_WIDTH 2 > #define SN_ENH_FRAME_REG 0x5A > +#define ASSR_CONTROL BIT(0) > #define VSTREAM_ENABLEBIT(3) > #define LN_POLRS_OFFSET 4 > #define LN_POLRS_MASK 0xf0 > @@ -91,6 +92,8 @@ > #define SN_DATARATE_CONFIG_REG 0x94 > #define DP_DATARATE_MASK GENMASK(7, 5) > #define DP_DATARATE(x)((x) << 5) > +#define SN_TRAINING_SETTING_REG0x95 > +#define SCRAMBLE_DISABLE BIT(4) > #define SN_ML_TX_MODE_REG 0x96 > #define ML_TX_MAIN_LINK_OFF 0 > #define ML_TX_NORMAL_MODE BIT(0) > @@ -1005,6 +1008,11 @@ static int ti_sn_link_training(struct ti_sn65dsi86 > *pdata, int dp_rate_idx, > regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG, >DP_DATARATE_MASK, DP_DATARATE(dp_rate_idx)); > > + /* For DisplayPort, use the standard DP scrambler seed. */ > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, > + ASSR_CONTROL, 0); > + > /* enable DP PLL */ > regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1); > > @@ -1016,6 +1024,11 @@ static int ti_sn_link_training(struct ti_sn65dsi86 > *pdata, int dp_rate_idx, > goto exit; > } > > + /* For DisplayPort, disable scrambling mode. */ > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > + regmap_update_bits(pdata->regmap, SN_TRAINING_SETTING_REG, > + SCRAMBLE_DISABLE, SCRAMBLE_DISABLE); > + > /* > * We'll try to link train several times. As part of link training > * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If > @@ -1260,7 +1273,8 @@ static int ti_sn_bridge_probe(struct auxiliary_device > *adev, > pdata->bridge.funcs = _sn_bridge_funcs; > pdata->bridge.of_node = np; > pdata->bridge.ops = DRM_BRIDGE_OP_EDID; > - pdata->bridge.type = DRM_MODE_CONNECTOR_eDP; > + pdata->bridge.type = pdata->next_bridge->type == > DRM_MODE_CONNECTOR_DisplayPort > + ? DRM_MODE_CONNECTOR_DisplayPort : > DRM_MODE_CONNECTOR_eDP; Anyone know if there's any expectation of other types here? Or is it just as safe to do: pdata->bridge.type = pdata->next_bridge->type; To achieve the same effect? -- Kieran > > drm_bridge_add(>bridge); > > -- > 2.32.0 >
Re: [PATCH v2 1/4] drm/bridge: ti-sn65dsi86: Implement bridge connector operations
Hi Doug,
Quoting Doug Anderson (2022-03-07 19:52:08)
> Hi,
>
> On Mon, Mar 7, 2022 at 10:00 AM Kieran Bingham
> wrote:
> >
> > From: Laurent Pinchart
> >
> > Implement the bridge connector-related .get_edid() operation, and report
> > the related bridge capabilities and type.
> >
> > Signed-off-by: Laurent Pinchart
> > Reviewed-by: Stephen Boyd
> > Reviewed-by: Douglas Anderson
> > Signed-off-by: Kieran Bingham
> > ---
> > Changes since v1:
> >
> > - The connector .get_modes() operation doesn't rely on EDID anymore,
> > __ti_sn_bridge_get_edid() and ti_sn_bridge_get_edid() got merged
> > together
> >
> > Notes from Kieran:
> >
> > RB Tags collected from:
> >
> > https://lore.kernel.org/all/20210322030128.2283-9-laurent.pinchart+rene...@ideasonboard.com/
> >
> > However this was over a year ago, so let me know if other patches now
> > superceed this one or otherwise invalidate this update.
> >
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index c55848588123..ffb6c04f6c46 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -1154,6 +1154,19 @@ static void ti_sn_bridge_post_disable(struct
> > drm_bridge *bridge)
> > pm_runtime_put_sync(pdata->dev);
> > }
> >
> > +static struct edid *ti_sn_bridge_get_edid(struct drm_bridge *bridge,
> > + struct drm_connector *connector)
> > +{
> > + struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > + struct edid *edid;
> > +
> > + pm_runtime_get_sync(pdata->dev);
> > + edid = drm_get_edid(connector, >aux.ddc);
> > + pm_runtime_put_autosuspend(pdata->dev);
> > +
> > + return edid;
> > +}
> > +
> > static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
> > .attach = ti_sn_bridge_attach,
> > .detach = ti_sn_bridge_detach,
> > @@ -1162,6 +1175,7 @@ static const struct drm_bridge_funcs
> > ti_sn_bridge_funcs = {
> > .enable = ti_sn_bridge_enable,
> > .disable = ti_sn_bridge_disable,
> > .post_disable = ti_sn_bridge_post_disable,
> > + .get_edid = ti_sn_bridge_get_edid,
> > };
> >
> > static void ti_sn_bridge_parse_lanes(struct ti_sn65dsi86 *pdata,
> > @@ -1248,6 +1262,8 @@ static int ti_sn_bridge_probe(struct auxiliary_device
> > *adev,
> >
> > pdata->bridge.funcs = _sn_bridge_funcs;
> > pdata->bridge.of_node = np;
> > + pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
> > + pdata->bridge.type = DRM_MODE_CONNECTOR_eDP;
>
> This doesn't look right to me. In the eDP case the EDID reading is
> driven by the panel.
Now that I have the optional connector working based on Sam's series I
think this is the last issue to solve before reposting the DP/HPD
support.
Are you saying that the bridge.ops should only set DRM_BRIDGE_OP_EDID
when pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort?
--
Regards
Kieran
>
> -Doug
Re: [PATCH v2 3/4] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
Quoting Doug Anderson (2022-03-07 23:22:00) > Hi, > > On Mon, Mar 7, 2022 at 10:00 AM Kieran Bingham > wrote: > > > > From: Laurent Pinchart > > > > Despite the SN65DSI86 being an eDP bridge, on some systems its output is > > routed to a DisplayPort connector. Enable DisplayPort mode when the next > > component in the display pipeline is detected as a DisplayPort > > connector, and disable eDP features in that case. > > > > Signed-off-by: Laurent Pinchart > > Reworked to set bridge type based on the next bridge/connector. > > Signed-off-by: Kieran Bingham > > -- > > Changes since v1/RFC: > > - Rebased on top of "drm/bridge: ti-sn65dsi86: switch to > >devm_drm_of_get_bridge" > > - eDP/DP mode determined from the next bridge connector type. > > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16 +++- > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > index 29f5f7123ed9..461f963faa0b 100644 > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > @@ -60,6 +60,7 @@ > > #define SN_LN_ASSIGN_REG 0x59 > > #define LN_ASSIGN_WIDTH 2 > > #define SN_ENH_FRAME_REG 0x5A > > +#define ASSR_CONTROL BIT(0) > > #define VSTREAM_ENABLEBIT(3) > > #define LN_POLRS_OFFSET 4 > > #define LN_POLRS_MASK 0xf0 > > @@ -91,6 +92,8 @@ > > #define SN_DATARATE_CONFIG_REG 0x94 > > #define DP_DATARATE_MASK GENMASK(7, 5) > > #define DP_DATARATE(x)((x) << 5) > > +#define SN_TRAINING_SETTING_REG0x95 > > +#define SCRAMBLE_DISABLE BIT(4) > > #define SN_ML_TX_MODE_REG 0x96 > > #define ML_TX_MAIN_LINK_OFF 0 > > #define ML_TX_NORMAL_MODE BIT(0) > > @@ -1005,6 +1008,11 @@ static int ti_sn_link_training(struct ti_sn65dsi86 > > *pdata, int dp_rate_idx, > > regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG, > >DP_DATARATE_MASK, DP_DATARATE(dp_rate_idx)); > > > > + /* For DisplayPort, use the standard DP scrambler seed. */ > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > > + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, > > + ASSR_CONTROL, 0); > > I thought it was agreed that this hunk wasn't doing anything and > should be removed? I did some research previously [1] and the manual > said that this bit is "read only" unless "TEST2" is pulled high. In > the previous discussion Laurent said that it wasn't. I also pointed > out that this conflicts with the bit of code in ti_sn_bridge_enable() > which tells the sink to enable the alternate scrambler. Sorry - I had misremembered indeed, and looking back I confirmed that this hunk was not required. I had incorrectly remembered that the second part was required (below) and assumed that had meant both were. Of course if we're disabling the scrambling mode, then it likely doesn't matter what the seed is!. Looking at the datasheet though, register 0x5a, clearly says the default is 01 (ASSR) which we're not using. So the datasheet implies we want the DP scrambler seed (if it were enabled?) Reading the 0x5a register here shows we have 0x05. Indeed, re-reading after attempting to write '0' to it still shows 0x05. So it's read-only and not relevant regardless. I've removed this hunk now. > > /* enable DP PLL */ > > regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1); > > > > @@ -1016,6 +1024,11 @@ static int ti_sn_link_training(struct ti_sn65dsi86 > > *pdata, int dp_rate_idx, > > goto exit; > > } > > > > + /* For DisplayPort, disable scrambling mode. */ > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > > + regmap_update_bits(pdata->regmap, SN_TRAINING_SETTING_REG, > > + SCRAMBLE_DISABLE, SCRAMBLE_DISABLE); > > In my previous review I asked for some comments to include the "why" > we disabling scrambling mode for DP. Can you please add that? > > I also presume that for DP it's probably a good idea to avoid the code > in ti_sn_bridge_enable() that tell
Re: [PATCH v1 6/9] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support
Hi Sam,
Quoting Sam Ravnborg (2022-02-06 15:44:02)
> From: Rob Clark
>
> Slightly awkward to fish out the display_info when we aren't creating
> own connector. But I don't see an obvious better way.
>
> v3:
> - Rebased and dropped the ti_sn_bridge_get_bpp() patch
>as this was solved in a different way (Sam)
>
> v2:
> - Remove error return with NO_CONNECTOR flag (Rob)
>
> Signed-off-by: Rob Clark
> Signed-off-by: Sam Ravnborg
> Cc: Rob Clark
> Cc: Douglas Anderson
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index dc6ec40bc1ef..a9041dfd2ae5 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -746,11 +746,6 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> int ret;
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> - }
> -
> pdata->aux.drm_dev = bridge->dev;
> ret = drm_dp_aux_register(>aux);
> if (ret < 0) {
> @@ -758,12 +753,14 @@ static int ti_sn_bridge_attach(struct drm_bridge
> *bridge,
> return ret;
> }
>
> - ret = ti_sn_bridge_connector_init(pdata);
> - if (ret < 0)
> - goto err_conn_init;
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> + ret = ti_sn_bridge_connector_init(pdata);
> + if (ret < 0)
> + goto err_conn_init;
>
> - /* We never want the next bridge to *also* create a connector: */
> - flags |= DRM_BRIDGE_ATTACH_NO_CONNECTOR;
> + /* We never want the next bridge to *also* create a
> connector: */
> + flags |= DRM_BRIDGE_ATTACH_NO_CONNECTOR;
> + }
>
> /* Attach the next bridge */
> ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge,
> @@ -774,7 +771,8 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> return 0;
>
> err_dsi_host:
> - drm_connector_cleanup(>connector);
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
I think this is unreachable / always false due to the
flags |= DRM_BRIDGE_ATTACH_NO_CONNECTOR.
I've solved this locally by doing:
- /* Attach the next bridge */
+ /*
+* Attach the next bridge We never want the next bridge to *also* create
+* a connector:
+*/
ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge,
- >bridge, flags);
+ >bridge,
+ flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret < 0)
goto err_initted_aux;
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
+
pdata->connector = drm_bridge_connector_init(pdata->bridge.dev,
pdata->bridge.encoder);
if (IS_ERR(pdata->connector)) {
ret = PTR_ERR(pdata->connector);
goto err_initted_aux;
}
drm_connector_attach_encoder(pdata->connector, pdata->bridge.encoder);
return 0;
Which also fixes the support for
flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR
--
Regards
Kieran
> + drm_connector_cleanup(>connector);
> err_conn_init:
> drm_dp_aux_unregister(>aux);
> return ret;
> --
> 2.32.0
>
Re: [PATCH v2 4/4] drm/bridge: ti-sn65dsi86: Support hotplug detection
Quoting Doug Anderson (2022-03-07 23:22:17)
> Hi,
>
> On Mon, Mar 7, 2022 at 10:00 AM Kieran Bingham
> wrote:
> >
> > @@ -1264,6 +1321,14 @@ static int ti_sn_bridge_probe(struct
> > auxiliary_device *adev,
> > return PTR_ERR(pdata->next_bridge);
> > }
> >
> > + pdata->no_hpd = of_property_read_bool(np, "no-hpd");
> > + if (pdata->next_bridge->type != DRM_MODE_CONNECTOR_DisplayPort &&
> > + !pdata->no_hpd) {
> > + dev_warn(pdata->dev,
> > +"HPD support requires a DisplayPort connector\n");
>
> Maybe "HPD support only implemented for full DP connectors".
>
> Plausibly someone could come up with a reason to hook HPD up for eDP
> one day, but so far we haven't seen it.
>
Ok, updated.
>
> > @@ -1272,7 +1337,8 @@ static int ti_sn_bridge_probe(struct auxiliary_device
> > *adev,
> >
> > pdata->bridge.funcs = _sn_bridge_funcs;
> > pdata->bridge.of_node = np;
> > - pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
> > + pdata->bridge.ops = (pdata->no_hpd ? 0 : DRM_BRIDGE_OP_DETECT |
> > DRM_BRIDGE_OP_HPD)
> > + | DRM_BRIDGE_OP_EDID;
>
> Seems like "OP_HPD" ought to be dependent on whether the IRQ was
> provided, right? AKA you could have "detect" because HPD is plumbed
> through to the bridge but not "HPD" if the IRQ from the bridge isn't
> hooked up to the main processor...
Yes, I think that's right. If there's no IRQ, then OP_HPD shouldn't be
set, and it will fall back to polling.
I'll fix that up.
> > @@ -1840,6 +1906,34 @@ static int ti_sn65dsi86_parse_regulators(struct
> > ti_sn65dsi86 *pdata)
> >pdata->supplies);
> > }
> >
> > +static irqreturn_t ti_sn65dsi86_irq_handler(int irq, void *arg)
> > +{
> > + struct ti_sn65dsi86 *pdata = arg;
> > + int ret;
> > + int hpd;
>
> `hpd` should be an `unsigned int` to match the prototype of regmap-read.
Agreed, and updated.
> > @@ -1881,6 +1975,16 @@ static int ti_sn65dsi86_probe(struct i2c_client
> > *client,
> > return dev_err_probe(dev, PTR_ERR(pdata->refclk),
> > "failed to get reference clock\n");
> >
> > + if (client->irq > 0) {
> > + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> > + ti_sn65dsi86_irq_handler,
> > + IRQF_ONESHOT,
> > "sn65dsi86-irq",
> > + pdata);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > +"Failed to register DP
> > interrupt\n");
> > + }
>
> Is this the right place to request the IRQ, or should it be in
> ti_sn_bridge_probe(). As soon as you request it the interrupt can go
> off, but you're relying on a bunch of bridge stuff to have been
> initted, right?
Indeed, it will be relying upon the bridge to have been set up.
You're right I believe, ti_sn_bridge_probe() sounds reasonable. And only
after that should we enable the interrupts.
Fixing ... (But getting stuck/blocked by the connector changes, so ..
I'll keep plowing through).
> > @@ -1888,6 +1992,9 @@ static int ti_sn65dsi86_probe(struct i2c_client
> > *client,
> > pm_runtime_set_autosuspend_delay(pdata->dev, 500);
> > pm_runtime_use_autosuspend(pdata->dev);
> >
> > + /* Enable interrupt handling */
> > + regmap_write(pdata->regmap, SN_IRQ_EN_REG, IRQ_EN);
>
> Shouldn't we only enable interrupt handling if client->irq > 0? AKA
> combine this with the "if" statement?
Agreed.
> -Doug
Re: [PATCH v2 2/4] drm/bridge: ti-sn65dsi86: Make connector creation optional
Hi Doug,
Quoting Doug Anderson (2022-03-07 23:21:28)
> Hi,
>
> On Mon, Mar 7, 2022 at 10:00 AM Kieran Bingham
> wrote:
> >
> > From: Laurent Pinchart
> >
> > Now that the driver supports the connector-related bridge operations,
> > make the connector creation optional. This enables usage of the
> > sn65dsi86 with the DRM bridge connector helper.
> >
> > Signed-off-by: Laurent Pinchart
> > Signed-off-by: Kieran Bingham
> >
> > ---
> > Changes since v1:
> > - None
> >
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 17 +++--
> > 1 file changed, 7 insertions(+), 10 deletions(-)
>
> Can you please CC me on this series next time you send it out? I was
> pretty involved in previous reviews here. Luckily I got CCed on one of
> the patches so I knew to look, but since that one is (probably)
> getting dropped it'd be good to make sure I was on the others. It's
> also pretty important to include +Sam Ravnborg since there's a lot of
> overlap with his series [1]:
Absolutely - I was assuming you were the main target for reviews. I'm
sorry - I also assumed get_maintainer.pl had / would add you - and I
didn't check getting the patches out last night.
I'll be sure to manually add you.
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index ffb6c04f6c46..29f5f7123ed9 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -745,11 +745,6 @@ static int (struct drm_bridge *bridge,
> > struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > int ret;
> >
> > - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> > - DRM_ERROR("Fix bridge driver to make connector optional!");
> > - return -EINVAL;
> > - }
>
> That won't work without some other fixes, sorry!
Ok ;-)
To be clear, my goal here has been to get the IRQ HPD working - so
my main focus is there. I guess I now have to handle custodianship of
these dependencies somehow too though.
> The problem is that you'll break ti_sn_bridge_get_bpp(). That
> absolutely relies on having our own connector so you need to fix that
> _before_ making the connector optional.
>
> Rob Clark made an attempt on this [2] but Laurent didn't like the
> solution he came up with. Sam's series that I mentioned [1] also made
> an attempt at this, specifically in patch 5 ("drm/bridge:
> ti-sn65dsi86: Fetch bpc via drm_bridge_state") of his series.
> Unfortunately, it didn't work because the "output_bus_cfg.format"
> wasn't set to anything. Personally I wouldn't mind Rob's solution as a
> stopgap if Laurent removes his NAK. Then we're not stuck while someone
> tries to find time to fix this correctly.
Ok - all of that is going to take some time for me to review and
process.
> One last problem here is that your patch doesn't actually apply to
> drm-misc/drm-misc-next, which is likely where it would land. I believe
> it conflicts with my recent commit e283820cbf80 ("drm/bridge:
> ti-sn65dsi86: Use drm_bridge_connector"). It looks like you based your
> series on mainline, but you should really be targeting drm-misc-next.
Ah sorry - I thought I had merged in drm-misc-next, but it was a week
ago or so so I guess I'm already outdated.
I'll cleanup for a new base now.
> -Doug
>
> [1] https://lore.kernel.org/r/20220206154405.124-1-...@ravnborg.org/
> [2] https://lore.kernel.org/all/20210920225801.227211-4-robdcl...@gmail.com/
[PATCH v2 1/4] drm/bridge: ti-sn65dsi86: Implement bridge connector operations
From: Laurent Pinchart
Implement the bridge connector-related .get_edid() operation, and report
the related bridge capabilities and type.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
Signed-off-by: Kieran Bingham
---
Changes since v1:
- The connector .get_modes() operation doesn't rely on EDID anymore,
__ti_sn_bridge_get_edid() and ti_sn_bridge_get_edid() got merged
together
Notes from Kieran:
RB Tags collected from:
https://lore.kernel.org/all/20210322030128.2283-9-laurent.pinchart+rene...@ideasonboard.com/
However this was over a year ago, so let me know if other patches now
superceed this one or otherwise invalidate this update.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index c55848588123..ffb6c04f6c46 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1154,6 +1154,19 @@ static void ti_sn_bridge_post_disable(struct drm_bridge
*bridge)
pm_runtime_put_sync(pdata->dev);
}
+static struct edid *ti_sn_bridge_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
+ struct edid *edid;
+
+ pm_runtime_get_sync(pdata->dev);
+ edid = drm_get_edid(connector, >aux.ddc);
+ pm_runtime_put_autosuspend(pdata->dev);
+
+ return edid;
+}
+
static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
.attach = ti_sn_bridge_attach,
.detach = ti_sn_bridge_detach,
@@ -1162,6 +1175,7 @@ static const struct drm_bridge_funcs ti_sn_bridge_funcs =
{
.enable = ti_sn_bridge_enable,
.disable = ti_sn_bridge_disable,
.post_disable = ti_sn_bridge_post_disable,
+ .get_edid = ti_sn_bridge_get_edid,
};
static void ti_sn_bridge_parse_lanes(struct ti_sn65dsi86 *pdata,
@@ -1248,6 +1262,8 @@ static int ti_sn_bridge_probe(struct auxiliary_device
*adev,
pdata->bridge.funcs = _sn_bridge_funcs;
pdata->bridge.of_node = np;
+ pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
+ pdata->bridge.type = DRM_MODE_CONNECTOR_eDP;
drm_bridge_add(>bridge);
--
2.32.0
[PATCH v2 4/4] drm/bridge: ti-sn65dsi86: Support hotplug detection
When the SN65DSI86 is used in DisplayPort mode, its output is likely
routed to a DisplayPort connector, which can benefit from hotplug
detection. Support it in such cases, with polling mode only for now.
The implementation is limited to the bridge operations, as the connector
operations are legacy and new users should use
DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
Changes since v1:
- Document the no_hpd field
- Rely on the SN_HPD_DISABLE_REG default value in the HPD case
- Add a TODO comment regarding IRQ support
[Kieran]
- Fix spelling s/assrted/asserted/
- Only enable HPD on DisplayPort connector.
- Support IRQ based hotplug detect
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 133 +++---
1 file changed, 120 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 461f963faa0b..febb4e672ece 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -68,6 +68,7 @@
#define BPP_18_RGBBIT(0)
#define SN_HPD_DISABLE_REG 0x5C
#define HPD_DISABLE BIT(0)
+#define HPD_DEBOUNCED_STATE BIT(4)
#define SN_GPIO_IO_REG 0x5E
#define SN_GPIO_INPUT_SHIFT 4
#define SN_GPIO_OUTPUT_SHIFT 0
@@ -104,10 +105,24 @@
#define SN_PWM_EN_INV_REG 0xA5
#define SN_PWM_INV_MASK BIT(0)
#define SN_PWM_EN_MASKBIT(1)
+#define SN_IRQ_EN_REG 0xE0
+#define IRQ_ENBIT(0)
+#define SN_IRQ_HPD_REG 0xE6
+#define IRQ_HPD_ENBIT(0)
+#define IRQ_HPD_INSERTION_EN BIT(1)
+#define IRQ_HPD_REMOVAL_ENBIT(2)
+#define IRQ_HPD_REPLUG_EN BIT(3)
+#define IRQ_HPD_PLL_UNLOCK_EN BIT(5)
#define SN_AUX_CMD_STATUS_REG 0xF4
#define AUX_IRQ_STATUS_AUX_RPLY_TOUT BIT(3)
#define AUX_IRQ_STATUS_AUX_SHORT BIT(5)
#define AUX_IRQ_STATUS_NAT_I2C_FAIL BIT(6)
+#define SN_IRQ_HPD_STATUS_REG 0xF5
+#define IRQ_HPD_STATUSBIT(0)
+#define IRQ_HPD_INSERTION_STATUS BIT(1)
+#define IRQ_HPD_REMOVAL_STATUSBIT(2)
+#define IRQ_HPD_REPLUG_STATUS BIT(3)
+#define IRQ_PLL_UNLOCKBIT(5)
#define MIN_DSI_CLK_FREQ_MHZ 40
@@ -166,6 +181,11 @@
* @pwm_enabled: Used to track if the PWM signal is currently enabled.
* @pwm_pin_busy: Track if GPIO4 is currently requested for GPIO or PWM.
* @pwm_refclk_freq: Cache for the reference clock input to the PWM.
+ *
+ * @no_hpd: Disable hot-plug detection as instructed by device tree (used
+ *for instance for eDP panels whose HPD signal won't be
asserted
+ *until the panel is turned on, and is thus not usable for
+ *downstream device detection).
*/
struct ti_sn65dsi86 {
struct auxiliary_device bridge_aux;
@@ -200,6 +220,8 @@ struct ti_sn65dsi86 {
atomic_tpwm_pin_busy;
#endif
unsigned intpwm_refclk_freq;
+
+ boolno_hpd;
};
static const struct regmap_range ti_sn65dsi86_volatile_ranges[] = {
@@ -314,23 +336,25 @@ static void ti_sn65dsi86_enable_comms(struct ti_sn65dsi86
*pdata)
ti_sn_bridge_set_refclk_freq(pdata);
/*
-* HPD on this bridge chip is a bit useless. This is an eDP bridge
-* so the HPD is an internal signal that's only there to signal that
-* the panel is done powering up. ...but the bridge chip debounces
-* this signal by between 100 ms and 400 ms (depending on process,
-* voltage, and temperate--I measured it at about 200 ms). One
+* As this is an eDP bridge, the output will be connected to a fixed
+* panel in most systems. HPD is in that case only an internal signal
+* to signal that the panel is done powering up. The bridge chip
+* debounces this signal by between 100 ms and 400 ms (depending on
+* process, voltage, and temperate--I measured it at about 200 ms). One
* particular panel asserted HPD 84 ms after it was powered on meaning
* that we saw HPD 284 ms after power on. ...but the same panel said
* that instead of looking at HPD you could just hardcode a delay of
-* 200 ms. We'll assume that the panel driver will have the hardcoded
-* delay in its prepare and always disable HPD.
+* 200 ms. HPD is thus a bit useless. For this type of use cases, we'll
+* assume that the panel driver will have
[PATCH v2 2/4] drm/bridge: ti-sn65dsi86: Make connector creation optional
From: Laurent Pinchart
Now that the driver supports the connector-related bridge operations,
make the connector creation optional. This enables usage of the
sn65dsi86 with the DRM bridge connector helper.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
Changes since v1:
- None
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index ffb6c04f6c46..29f5f7123ed9 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -745,11 +745,6 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
int ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
-
pdata->aux.drm_dev = bridge->dev;
ret = drm_dp_aux_register(>aux);
if (ret < 0) {
@@ -757,12 +752,14 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
return ret;
}
- ret = ti_sn_bridge_connector_init(pdata);
- if (ret < 0)
- goto err_conn_init;
+ if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+ ret = ti_sn_bridge_connector_init(pdata);
+ if (ret < 0)
+ goto err_conn_init;
- /* We never want the next bridge to *also* create a connector: */
- flags |= DRM_BRIDGE_ATTACH_NO_CONNECTOR;
+ /* We never want the next bridge to *also* create a connector:
*/
+ flags |= DRM_BRIDGE_ATTACH_NO_CONNECTOR;
+ }
/* Attach the next bridge */
ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge,
--
2.32.0
[PATCH v2 3/4] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
From: Laurent Pinchart Despite the SN65DSI86 being an eDP bridge, on some systems its output is routed to a DisplayPort connector. Enable DisplayPort mode when the next component in the display pipeline is detected as a DisplayPort connector, and disable eDP features in that case. Signed-off-by: Laurent Pinchart Reworked to set bridge type based on the next bridge/connector. Signed-off-by: Kieran Bingham -- Changes since v1/RFC: - Rebased on top of "drm/bridge: ti-sn65dsi86: switch to devm_drm_of_get_bridge" - eDP/DP mode determined from the next bridge connector type. drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index 29f5f7123ed9..461f963faa0b 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -60,6 +60,7 @@ #define SN_LN_ASSIGN_REG 0x59 #define LN_ASSIGN_WIDTH 2 #define SN_ENH_FRAME_REG 0x5A +#define ASSR_CONTROL BIT(0) #define VSTREAM_ENABLEBIT(3) #define LN_POLRS_OFFSET 4 #define LN_POLRS_MASK 0xf0 @@ -91,6 +92,8 @@ #define SN_DATARATE_CONFIG_REG 0x94 #define DP_DATARATE_MASK GENMASK(7, 5) #define DP_DATARATE(x)((x) << 5) +#define SN_TRAINING_SETTING_REG0x95 +#define SCRAMBLE_DISABLE BIT(4) #define SN_ML_TX_MODE_REG 0x96 #define ML_TX_MAIN_LINK_OFF 0 #define ML_TX_NORMAL_MODE BIT(0) @@ -1005,6 +1008,11 @@ static int ti_sn_link_training(struct ti_sn65dsi86 *pdata, int dp_rate_idx, regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG, DP_DATARATE_MASK, DP_DATARATE(dp_rate_idx)); + /* For DisplayPort, use the standard DP scrambler seed. */ + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, + ASSR_CONTROL, 0); + /* enable DP PLL */ regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1); @@ -1016,6 +1024,11 @@ static int ti_sn_link_training(struct ti_sn65dsi86 *pdata, int dp_rate_idx, goto exit; } + /* For DisplayPort, disable scrambling mode. */ + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) + regmap_update_bits(pdata->regmap, SN_TRAINING_SETTING_REG, + SCRAMBLE_DISABLE, SCRAMBLE_DISABLE); + /* * We'll try to link train several times. As part of link training * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If @@ -1260,7 +1273,8 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev, pdata->bridge.funcs = _sn_bridge_funcs; pdata->bridge.of_node = np; pdata->bridge.ops = DRM_BRIDGE_OP_EDID; - pdata->bridge.type = DRM_MODE_CONNECTOR_eDP; + pdata->bridge.type = pdata->next_bridge->type == DRM_MODE_CONNECTOR_DisplayPort + ? DRM_MODE_CONNECTOR_DisplayPort : DRM_MODE_CONNECTOR_eDP; drm_bridge_add(>bridge); -- 2.32.0
[PATCH v2 0/4] drm/bridge: ti-sn65dsi86: Support non-eDP DisplayPort connectors
Implement support for non eDP connectors on the TI-SN65DSI86 bridge, and provide IRQ based hotplug detect to identify when the connector is present. no-hpd is extended to be the default behaviour for non DisplayPort connectors. This series is based on top of José Expósito's patch [0] "drm/bridge: ti-sn65dsi86: switch to devm_drm_of_get_bridge" and Nikita Yushchenko's patch [1] "drm/bridge_connector: enable HPD by default if supported". [0] https://lore.kernel.org/all/20220228183955.25508-1-jose.exposit...@gmail.com/ [1] https://lore.kernel.org/all/20211225063151.2110878-1-nikita.yo...@cogentembedded.com/ Kieran Bingham (1): drm/bridge: ti-sn65dsi86: Support hotplug detection Laurent Pinchart (3): drm/bridge: ti-sn65dsi86: Implement bridge connector operations drm/bridge: ti-sn65dsi86: Make connector creation optional drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode drivers/gpu/drm/bridge/ti-sn65dsi86.c | 178 ++ 1 file changed, 156 insertions(+), 22 deletions(-) -- 2.32.0
Re: [RFC PATCH 11/11] drm/bridge: ti-sn65dsi86: Support hotplug detection
Hi Doug,
Quoting Doug Anderson (2022-02-23 18:25:13)
> Hi,
>
> On Wed, Feb 23, 2022 at 9:43 AM Kieran Bingham
> wrote:
> >
> > Hi All,
> >
> > I'm working to respin the remainder of these patches, now that I have
> > IRQ based HPD working on the SN65DSI86, and the (non-eDP) mode is used
> > for Renesas R-Car boards.
> >
> > Quoting Doug Anderson (2021-06-24 00:51:12)
> > > Hi,
> > >
> > > On Wed, Jun 23, 2021 at 4:26 PM Laurent Pinchart
> > > wrote:
> > > >
> > > > > > @@ -1365,7 +1384,8 @@ static int ti_sn_bridge_probe(struct
> > > > > > i2c_client *client,
> > > > > >
> > > > > > pdata->bridge.funcs = _sn_bridge_funcs;
> > > > > > pdata->bridge.of_node = client->dev.of_node;
> > > > > > - pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
> > > > > > + pdata->bridge.ops = (pdata->no_hpd ? 0 :
> > > > > > DRM_BRIDGE_OP_DETECT)
> > > > >
> > > > > Checking for "no_hpd" here is not the right test IIUC. You want to
> > > > > check for eDP vs. DP (AKA whether a panel is downstream of you or a
> > > > > connector). Specifically if downstream of you is a panel then (I
> > > > > believe) HPD won't assert until you turn on the panel and you won't
> > > > > turn on the panel (which happens in pre_enable, right?) until HPD
> > > > > fires, so you've got a chicken-and-egg problem. If downstream of you
> > > > > is a connector, though, then by definition HPD has to just work
> > > > > without pre_enable running so then you're OK.
> > > >
> > > > Agreed. It's even more true now that your rework has landed, as in the
> > > > eDP case EDID is handled by the panel driver. I'll rework this.
> > > >
> > > > Should I also condition setting HPD_DISABLE to the presence of a panel
> > > > then ? I could drop of_property_read_bool() and set
> > > >
> > > > pdata->no_hpd = !!panel;
> > > >
> > > > > I guess then you'd need to figure out what to do if someone wants to
> > > > > use "HPD" on eDP. Do you need to put a polling loop in pre_enable
> > > > > then? Or you could just punt not support this case until someone needs
> > > > > it.
> > > >
> > > > I think I'll stop short of saving the world this time, yes :-) We'll see
> > > > what to do when this case arises.
> > >
> > > How about as a compromise you still call of_property_read_bool() but
> > > add some type of warning in the logs if someone didn't set "no-hpd"
> > > but they have a panel?
> >
> >
> > Would a mix of the two work well?
> >
> > What about:
> >
> > pdata->no_hpd = of_property_read_bool(np, "no-hpd");
> > if (panel && !pdata->no_hpd) {
> > DRM_ERROR("Panels will not function with HPD. Enforcing
> > no-hpd\n");
> > pdata->no_hpd = true;
> > }
> >
> > That leaves it still optional to DP connectors, but enforced on eDP?
>
> Yeah, that's fine with me. Nits would be to use "warn" instead of
> "error" since this isn't fatal and use the non-SHOUTING versions of
> the prints since the SHOUTING versions are deprecated.
Could you clarify this please? The whole driver uses DRM_ERROR style. Is
there a new debug macro somewhere?
>
>
> > > > > > + | DRM_BRIDGE_OP_EDID;
> > > > >
> > > > > IMO somewhere in here if HPD is being used like this you should throw
> > > > > in a call to pm_runtime_get_sync(). I guess in your solution the
> > > > > regulators (for the bridge, not the panel) and enable pin are just
> > > > > left on all the time,
> > > >
> > > > Correct, on my development board the SN65DSI86 is on all the time, I
> > > > can't control that.
> > > >
> > > > > but plausibly someone might want to build a
> > > > > system to use HPD and also have the enable pin and/or regulators
> > > > > controlled by this driver, right?
> > > >
> > > > True. DRM doesn't make this very easy, as, as far as I can tell, there's
> > > > no standard infrastructure for userspace to register an interes
Re: [PATCH] drm/bridge: ti-sn65dsi86: switch to devm_drm_of_get_bridge
Hi José
Quoting Kieran Bingham (2022-03-03 21:59:26)
> Quoting José Expósito (2022-03-03 18:37:20)
> > On Mon, Feb 28, 2022 at 11:24:36PM +0000, Kieran Bingham wrote:
> > > Hi José
> > >
> > > Quoting José Expósito (2022-02-28 18:39:54)
> > > > The function "drm_of_find_panel_or_bridge" has been deprecated in
> > > > favor of "devm_drm_of_get_bridge".
> > > >
> > > > Switch to the new function and reduce boilerplate.
> > > >
> > > > Signed-off-by: José Expósito
> > > > ---
> > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 8 +---
> > > > 1 file changed, 1 insertion(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > index dab8f76618f3..fb8e16ed7e90 100644
> > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > @@ -1232,15 +1232,9 @@ static int ti_sn_bridge_probe(struct
> > > > auxiliary_device *adev,
> > > > {
> > > > struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
> > > > struct device_node *np = pdata->dev->of_node;
> > > > - struct drm_panel *panel;
> > > > int ret;
> > > >
> > > > - ret = drm_of_find_panel_or_bridge(np, 1, 0, , NULL);
> > > > - if (ret)
> > > > - return dev_err_probe(>dev, ret,
> > > > -"could not find any panel node\n");
> > > > -
> > > > - pdata->next_bridge = devm_drm_panel_bridge_add(pdata->dev,
> > > > panel);
> > > > + pdata->next_bridge = devm_drm_of_get_bridge(pdata->dev, np, 1,
> > > > 0);
> > >
> > > Yikes, I was about to rely on this panel variable to determine if the
> > > device is a panel or a display port connector. (Well, I am relying on
> > > it, and patches are hoping to be reposted this week).
> > >
> > > Is there expected to be another way to identify if the next connection
> > > is a panel or a bridge?
> > >
> > > Regards
> >
> > Hi Kieran,
> >
> > I'm getting started in the DRM subsystem. I couldn't tell if there is a
> > good way to access the panel pointer... I didn't manage to find it, but
> > hopefully someone with more experience can point us to a solution.
> >
> > Since you mentioned display port, I'm not sure if in your case checking
> > "pdata->next_bridge->type" could be good enough.
Actually, it is. And I think this is actually cleaner (both here, and in
the series I'm working on).
> > Anyway, if this patch causes you problems, please go ahead and ignore it.
> > I'm sure the series you are working on are more important than removing
> > a deprecated function :)
>
> If it's deprecated, I don't want to block it's removal. Hopefully I can
> resume my work on this tomorrow so I can check to see what I can parse.
> Thanks for the lead on the bridge type, I'm sure I've seen that around
> too so hopefully that's enough. If it is, I'll rebase my work on top of
> your patch and retest.
So - my series is now working with a bit of adaptation to run on top of
your patch, and I think the overall result is better. So:
Reviewed-by: Kieran Bingham
>
> --
> Kieran
>
>
> >
> > Best wishes,
> > Jose
Re: [PATCH] drm/bridge: ti-sn65dsi86: switch to devm_drm_of_get_bridge
Quoting José Expósito (2022-03-03 18:37:20)
> On Mon, Feb 28, 2022 at 11:24:36PM +0000, Kieran Bingham wrote:
> > Hi José
> >
> > Quoting José Expósito (2022-02-28 18:39:54)
> > > The function "drm_of_find_panel_or_bridge" has been deprecated in
> > > favor of "devm_drm_of_get_bridge".
> > >
> > > Switch to the new function and reduce boilerplate.
> > >
> > > Signed-off-by: José Expósito
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 8 +---
> > > 1 file changed, 1 insertion(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > index dab8f76618f3..fb8e16ed7e90 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > @@ -1232,15 +1232,9 @@ static int ti_sn_bridge_probe(struct
> > > auxiliary_device *adev,
> > > {
> > > struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
> > > struct device_node *np = pdata->dev->of_node;
> > > - struct drm_panel *panel;
> > > int ret;
> > >
> > > - ret = drm_of_find_panel_or_bridge(np, 1, 0, , NULL);
> > > - if (ret)
> > > - return dev_err_probe(>dev, ret,
> > > -"could not find any panel node\n");
> > > -
> > > - pdata->next_bridge = devm_drm_panel_bridge_add(pdata->dev, panel);
> > > + pdata->next_bridge = devm_drm_of_get_bridge(pdata->dev, np, 1, 0);
> >
> > Yikes, I was about to rely on this panel variable to determine if the
> > device is a panel or a display port connector. (Well, I am relying on
> > it, and patches are hoping to be reposted this week).
> >
> > Is there expected to be another way to identify if the next connection
> > is a panel or a bridge?
> >
> > Regards
>
> Hi Kieran,
>
> I'm getting started in the DRM subsystem. I couldn't tell if there is a
> good way to access the panel pointer... I didn't manage to find it, but
> hopefully someone with more experience can point us to a solution.
>
> Since you mentioned display port, I'm not sure if in your case checking
> "pdata->next_bridge->type" could be good enough.
>
> Anyway, if this patch causes you problems, please go ahead and ignore it.
> I'm sure the series you are working on are more important than removing
> a deprecated function :)
If it's deprecated, I don't want to block it's removal. Hopefully I can
resume my work on this tomorrow so I can check to see what I can parse.
Thanks for the lead on the bridge type, I'm sure I've seen that around
too so hopefully that's enough. If it is, I'll rebase my work on top of
your patch and retest.
--
Kieran
>
> Best wishes,
> Jose
Re: [PATCH 2/2] drm: rcar-du: Don't restart group when enabling plane on Gen3
Quoting Laurent Pinchart (2022-02-21 17:13:40)
> On Gen3 hardware enabling a VSP plane doesn't change any register that
> requires DRES to take effect. Avoid a group restart in that case.
This also makes it clear that the need_restart is due to the change
occuring in the VSP1 sink, so I think this is cleaner all round.
Reviewed-by: Kieran Bingham
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 ++
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 9 -
> 2 files changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 9b058d6cb032..22aeeb1cc1fb 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -560,6 +560,12 @@ void __rcar_du_plane_setup(struct rcar_du_group *rgrp,
> if (rcdu->vspd1_sink != vspd1_sink) {
> rcdu->vspd1_sink = vspd1_sink;
> rcar_du_set_dpad0_vsp1_routing(rcdu);
> +
> + /*
> +* Changes to the VSP1 sink take effect on DRES and
> thus
> +* need a restart of the group.
> +*/
> + rgrp->need_restart = true;
> }
> }
> }
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index b7fc5b069cbc..32530d698e75 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -84,15 +84,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
>
> __rcar_du_plane_setup(crtc->group, );
>
> - /*
> -* Ensure that the plane source configuration takes effect by
> requesting
> -* a restart of the group. See rcar_du_plane_atomic_update() for a
> more
> -* detailed explanation.
> -*
> -* TODO: Check whether this is still needed on Gen3.
> -*/
> - crtc->group->need_restart = true;
> -
> vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, );
> }
>
> --
> Regards,
>
> Laurent Pinchart
>
Re: [PATCH 1/2] drm: rcar-du: Don't select VSP1 sink on Gen3
Quoting Laurent Pinchart (2022-02-21 17:13:39)
> The VSP1 sink selection through register DEFR8 is only available on Gen2
> hardware. Skip it on Gen3.
aha, interesting, and I see how this leads into the second patch.
Looks fine on it's own too though:
Reviewed-by: Kieran Bingham
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 862197be1e01..9b058d6cb032 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -549,8 +549,10 @@ void __rcar_du_plane_setup(struct rcar_du_group *rgrp,
> rcar_du_plane_setup_format(rgrp, (state->hwindex + 1) % 8,
>state);
>
> - if (rcdu->info->gen < 3)
> - rcar_du_plane_setup_scanout(rgrp, state);
> + if (rcdu->info->gen >= 3)
> + return;
> +
> + rcar_du_plane_setup_scanout(rgrp, state);
>
> if (state->source == RCAR_DU_PLANE_VSPD1) {
> unsigned int vspd1_sink = rgrp->index ? 2 : 0;
> --
> Regards,
>
> Laurent Pinchart
>
Re: [PATCH] drm/bridge: ti-sn65dsi86: switch to devm_drm_of_get_bridge
Hi José
Quoting José Expósito (2022-02-28 18:39:54)
> The function "drm_of_find_panel_or_bridge" has been deprecated in
> favor of "devm_drm_of_get_bridge".
>
> Switch to the new function and reduce boilerplate.
>
> Signed-off-by: José Expósito
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index dab8f76618f3..fb8e16ed7e90 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -1232,15 +1232,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device
> *adev,
> {
> struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
> struct device_node *np = pdata->dev->of_node;
> - struct drm_panel *panel;
> int ret;
>
> - ret = drm_of_find_panel_or_bridge(np, 1, 0, , NULL);
> - if (ret)
> - return dev_err_probe(>dev, ret,
> -"could not find any panel node\n");
> -
> - pdata->next_bridge = devm_drm_panel_bridge_add(pdata->dev, panel);
> + pdata->next_bridge = devm_drm_of_get_bridge(pdata->dev, np, 1, 0);
Yikes, I was about to rely on this panel variable to determine if the
device is a panel or a display port connector. (Well, I am relying on
it, and patches are hoping to be reposted this week).
Is there expected to be another way to identify if the next connection
is a panel or a bridge?
Regards
--
Kieran
> if (IS_ERR(pdata->next_bridge)) {
> DRM_ERROR("failed to create panel bridge\n");
> return PTR_ERR(pdata->next_bridge);
> --
> 2.25.1
>
Re: [RFC PATCH 10/11] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
Hi Doug, Laurent, Quoting Laurent Pinchart (2021-06-23 14:59:00) > Hi Doug, > > On Wed, Mar 24, 2021 at 03:47:07PM -0700, Doug Anderson wrote: > > On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote: > > > > > > Despite the SN65DSI86 being an eDP bridge, on some systems its output is > > > routed to a DisplayPort connector. Enable DisplayPort mode when the next > > > component in the display pipeline is not a panel, and disable eDP > > > features in that case. > > > > > > Signed-off-by: Laurent Pinchart > > > > > > --- > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 32 --- > > > 1 file changed, 24 insertions(+), 8 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > index e2527d597ccb..f792227142a7 100644 > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > @@ -55,6 +55,7 @@ > > > #define SN_LN_ASSIGN_REG 0x59 > > > #define LN_ASSIGN_WIDTH 2 > > > #define SN_ENH_FRAME_REG 0x5A > > > +#define ASSR_CONTROL BIT(0) > > > #define VSTREAM_ENABLEBIT(3) > > > #define LN_POLRS_OFFSET 4 > > > #define LN_POLRS_MASK 0xf0 > > > @@ -86,6 +87,8 @@ > > > #define SN_DATARATE_CONFIG_REG 0x94 > > > #define DP_DATARATE_MASK GENMASK(7, 5) > > > #define DP_DATARATE(x)((x) << 5) > > > +#define SN_TRAINING_SETTING_REG0x95 > > > +#define SCRAMBLE_DISABLE BIT(4) > > > #define SN_ML_TX_MODE_REG 0x96 > > > #define ML_TX_MAIN_LINK_OFF 0 > > > #define ML_TX_NORMAL_MODE BIT(0) > > > @@ -723,6 +726,11 @@ static int ti_sn_link_training(struct ti_sn_bridge > > > *pdata, int dp_rate_idx, > > > regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG, > > >DP_DATARATE_MASK, DP_DATARATE(dp_rate_idx)); > > > > > > + /* For DisplayPort, use the standard DP scrambler seed. */ > > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) > > > + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, > > > + ASSR_CONTROL, 0); > > > > I don't actually know anything about DP scrambler seeds. However: > > > > 1. From reading the docs, this field seems to be documented to be > > "read only" unless: > > > > 1a) The "TEST2" pin is pulled high when you power on the bridge. > > 1b) You set "ASSR_OVERRIDE" (page select to page 7, write to register > > 0x16, page select back to page 0). > > > > I don't know if TEST2 is being pulled high in your hardware, but at > > least I can see that 1b) isn't done. So I'm guessing that this line is > > a no-op? If I had to guess from all the hoops they're making you jump > > through there's some sort of errata around standard scrambling on this > > bridge chip. Are you sure it works OK? > > Good question :-) We managed to get the SN65DSI86 to work with an > external DP monitor yesterday, so it's possible (some modes don't > operate correctly yet, but I assume that to be an issue with the DSI > encoder). > > The TEST2 pin is strapped to ground on the board. > > According to the DisplayPort specification, eDP and DP use different > scrambler seeds to prevent interoperability between an eDP source and a > DP sink. I'll check what happens without this change. Without this change, the display still works... > > > 2. The docs I see claim that this field is 2 bits big. It seems like > > it would be nice to honor. Yeah, it's silly because 0x11 and 0x10 are > > "reserved" so it's really more like a 1-bit field, but still seems > > like it would be better to set both bits, or at least add a comment > > explaining why you're not matching the datasheet. > > Sure. > > > 3. Your patch doesn't seem to touch the bit of code in > > ti_sn_bridge_enable() that says this: > > > > /** > > * The SN65DSI86 only supports ASSR Display Authentication method and > > * this method is enabled by default. An eDP panel must support this > > * authentication method. We need to enable this method in the eDP panel > > * at DisplayPort address 0x0010A prior to link training. > > */ > > drm_dp_dpcd_writeb(>aux, DP_EDP_CONFIGURATION_SET, > >DP_ALTERNATE_SCRAMBLER_RESET_ENABLE); > > > > Won't that be a problem? > > I'll have a look. I'm not sure I yet fully understand the requirements here, but could it be that only supporting ASSR is why the scrambling is disabled below? Commenting out that write does not affect the bring up of my DP monitor. > > > > + > > > /* enable DP PLL */ > > > regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1); > > > > > > @@ -734,6 +742,11 @@ static int ti_sn_link_training(struct
Re: [RFC PATCH 11/11] drm/bridge: ti-sn65dsi86: Support hotplug detection
Hi All,
I'm working to respin the remainder of these patches, now that I have
IRQ based HPD working on the SN65DSI86, and the (non-eDP) mode is used
for Renesas R-Car boards.
Quoting Doug Anderson (2021-06-24 00:51:12)
> Hi,
>
> On Wed, Jun 23, 2021 at 4:26 PM Laurent Pinchart
> wrote:
> >
> > > > @@ -1365,7 +1384,8 @@ static int ti_sn_bridge_probe(struct i2c_client
> > > > *client,
> > > >
> > > > pdata->bridge.funcs = _sn_bridge_funcs;
> > > > pdata->bridge.of_node = client->dev.of_node;
> > > > - pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
> > > > + pdata->bridge.ops = (pdata->no_hpd ? 0 : DRM_BRIDGE_OP_DETECT)
> > >
> > > Checking for "no_hpd" here is not the right test IIUC. You want to
> > > check for eDP vs. DP (AKA whether a panel is downstream of you or a
> > > connector). Specifically if downstream of you is a panel then (I
> > > believe) HPD won't assert until you turn on the panel and you won't
> > > turn on the panel (which happens in pre_enable, right?) until HPD
> > > fires, so you've got a chicken-and-egg problem. If downstream of you
> > > is a connector, though, then by definition HPD has to just work
> > > without pre_enable running so then you're OK.
> >
> > Agreed. It's even more true now that your rework has landed, as in the
> > eDP case EDID is handled by the panel driver. I'll rework this.
> >
> > Should I also condition setting HPD_DISABLE to the presence of a panel
> > then ? I could drop of_property_read_bool() and set
> >
> > pdata->no_hpd = !!panel;
> >
> > > I guess then you'd need to figure out what to do if someone wants to
> > > use "HPD" on eDP. Do you need to put a polling loop in pre_enable
> > > then? Or you could just punt not support this case until someone needs
> > > it.
> >
> > I think I'll stop short of saving the world this time, yes :-) We'll see
> > what to do when this case arises.
>
> How about as a compromise you still call of_property_read_bool() but
> add some type of warning in the logs if someone didn't set "no-hpd"
> but they have a panel?
Would a mix of the two work well?
What about:
pdata->no_hpd = of_property_read_bool(np, "no-hpd");
if (panel && !pdata->no_hpd) {
DRM_ERROR("Panels will not function with HPD. Enforcing
no-hpd\n");
pdata->no_hpd = true;
}
That leaves it still optional to DP connectors, but enforced on eDP?
> > > > + | DRM_BRIDGE_OP_EDID;
> > >
> > > IMO somewhere in here if HPD is being used like this you should throw
> > > in a call to pm_runtime_get_sync(). I guess in your solution the
> > > regulators (for the bridge, not the panel) and enable pin are just
> > > left on all the time,
> >
> > Correct, on my development board the SN65DSI86 is on all the time, I
> > can't control that.
> >
> > > but plausibly someone might want to build a
> > > system to use HPD and also have the enable pin and/or regulators
> > > controlled by this driver, right?
> >
> > True. DRM doesn't make this very easy, as, as far as I can tell, there's
> > no standard infrastructure for userspace to register an interest in HPD
> > that could be notified to bridges. I think it should be fixable, but
> > it's out of scope for this series :-) Should I still add a
> > pm_runtime_get_sync() at probe time, or leave this to be addressed by
> > someone who will need to implement power control ?
>
> IMO if you've detected you're running in DP mode you should add the
> pm_runtime_get_sync() in probe to keep it powered all the time and
> that seems the simplest. Technically I guess that's not really
> required since you're polling and you could power off between polls,
> but then you'd have to re-init a bunch of your state each time you
> polled too. If you ever transitioned to using an IRQ for HPD then
> you'd have to keep it always powered anyway.
Hrm ... that's precisely what I've done. It's not IRQ based HPD...
So would you like to see something like this during
ti_sn_bridge_probe()?
/* The device must remain powered up for HPD to be supported. */
if (!pdata->no_hpd)
pm_runtime_get_sync(pdata->dev);
--
Regards
Kieran
>
> -Doug
Re: [PATCH] drm/bridge_connector: enable HPD by default if supported
Quoting Laurent Pinchart (2022-02-23 16:25:28)
> Hello,
>
> On Wed, Feb 23, 2022 at 04:17:22PM +0000, Kieran Bingham wrote:
> > Quoting Laurent Pinchart (2021-12-29 23:44:29)
> > > On Sat, Dec 25, 2021 at 09:31:51AM +0300, Nikita Yushchenko wrote:
> > > > Hotplug events reported by bridge drivers over drm_bridge_hpd_notify()
> > > > get ignored unless somebody calls drm_bridge_hpd_enable(). When the
> > > > connector for the bridge is bridge_connector, such a call is done from
> > > > drm_bridge_connector_enable_hpd().
> > > >
> > > > However drm_bridge_connector_enable_hpd() is never called on init paths,
> > > > documentation suggests that it is intended for suspend/resume paths.
> > >
> > > H... I'm in two minds about this. The problem description is
> > > correct, but I wonder if HPD should be enabled unconditionally here, or
> > > if this should be left to display drivers to control.
> > > drivers/gpu/drm/imx/dcss/dcss-kms.c enables HPD manually at init time,
> > > other drivers don't.
> > >
> > > It feels like this should be under control of the display controller
> > > driver, but I can't think of a use case for not enabling HPD at init
> > > time. Any second opinion from anyone ?
> >
> > This patch solves an issue I have where I have recently enabled HPD on
> > the SN65DSI86, but without this, I do not get calls to my .hpd_enable or
> > .hpd_disable hooks that I have added to the ti_sn_bridge_funcs.
> >
> > So it needs to be enabled somewhere, and this seems reasonable to me?
> > It's not directly related to the display controller - as it's a factor
> > of the bridge?
> >
> > On Falcon-V3U with HPD additions to SN65DSI86:
> > Tested-by: Kieran Bingham
>
> If you think this is right, then
>
> Reviewed-by: Laurent Pinchart
I do, and at the very least it works for me, and fixes Nikita's issue so
to me that's enough for:
Reviewed-by: Kieran Bingham
> > > > In result, once encoders are switched to bridge_connector,
> > > > bridge-detected HPD stops working.
> > > >
> > > > This patch adds a call to that API on init path.
> > > >
> > > > This fixes HDMI HPD with rcar-du + adv7513 case when adv7513 reports HPD
> > > > events via interrupts.
> > > >
> > > > Fixes: c24110a8fd09 ("drm: rcar-du: Use drm_bridge_connector_init()
> > > > helper")
> > > > Signed-off-by: Nikita Yushchenko
> > > > ---
> > > > drivers/gpu/drm/drm_bridge_connector.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> > > > b/drivers/gpu/drm/drm_bridge_connector.c
> > > > index 791379816837..4f20137ef21d 100644
> > > > --- a/drivers/gpu/drm/drm_bridge_connector.c
> > > > +++ b/drivers/gpu/drm/drm_bridge_connector.c
> > > > @@ -369,8 +369,10 @@ struct drm_connector
> > > > *drm_bridge_connector_init(struct drm_device *drm,
> > > > connector_type, ddc);
> > > > drm_connector_helper_add(connector,
> > > > _bridge_connector_helper_funcs);
> > > >
> > > > - if (bridge_connector->bridge_hpd)
> > > > + if (bridge_connector->bridge_hpd) {
> > > > connector->polled = DRM_CONNECTOR_POLL_HPD;
> > > > + drm_bridge_connector_enable_hpd(connector);
> > > > + }
> > > > else if (bridge_connector->bridge_detect)
> > > > connector->polled = DRM_CONNECTOR_POLL_CONNECT
> > > > | DRM_CONNECTOR_POLL_DISCONNECT;
>
> --
> Regards,
>
> Laurent Pinchart
Re: [PATCH] drm/bridge_connector: enable HPD by default if supported
Hi Laurent, Nikita,
Quoting Laurent Pinchart (2021-12-29 23:44:29)
> Hi Nikita,
>
> Thank you for the patch.
>
> On Sat, Dec 25, 2021 at 09:31:51AM +0300, Nikita Yushchenko wrote:
> > Hotplug events reported by bridge drivers over drm_bridge_hpd_notify()
> > get ignored unless somebody calls drm_bridge_hpd_enable(). When the
> > connector for the bridge is bridge_connector, such a call is done from
> > drm_bridge_connector_enable_hpd().
> >
> > However drm_bridge_connector_enable_hpd() is never called on init paths,
> > documentation suggests that it is intended for suspend/resume paths.
>
> H... I'm in two minds about this. The problem description is
> correct, but I wonder if HPD should be enabled unconditionally here, or
> if this should be left to display drivers to control.
> drivers/gpu/drm/imx/dcss/dcss-kms.c enables HPD manually at init time,
> other drivers don't.
>
> It feels like this should be under control of the display controller
> driver, but I can't think of a use case for not enabling HPD at init
> time. Any second opinion from anyone ?
This patch solves an issue I have where I have recently enabled HPD on
the SN65DSI86, but without this, I do not get calls to my .hpd_enable or
.hpd_disable hooks that I have added to the ti_sn_bridge_funcs.
So it needs to be enabled somewhere, and this seems reasonable to me?
It's not directly related to the display controller - as it's a factor
of the bridge?
On Falcon-V3U with HPD additions to SN65DSI86:
Tested-by: Kieran Bingham
> > In result, once encoders are switched to bridge_connector,
> > bridge-detected HPD stops working.
> >
> > This patch adds a call to that API on init path.
> >
> > This fixes HDMI HPD with rcar-du + adv7513 case when adv7513 reports HPD
> > events via interrupts.
> >
> > Fixes: c24110a8fd09 ("drm: rcar-du: Use drm_bridge_connector_init() helper")
> > Signed-off-by: Nikita Yushchenko
> > ---
> > drivers/gpu/drm/drm_bridge_connector.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> > b/drivers/gpu/drm/drm_bridge_connector.c
> > index 791379816837..4f20137ef21d 100644
> > --- a/drivers/gpu/drm/drm_bridge_connector.c
> > +++ b/drivers/gpu/drm/drm_bridge_connector.c
> > @@ -369,8 +369,10 @@ struct drm_connector *drm_bridge_connector_init(struct
> > drm_device *drm,
> > connector_type, ddc);
> > drm_connector_helper_add(connector,
> > _bridge_connector_helper_funcs);
> >
> > - if (bridge_connector->bridge_hpd)
> > + if (bridge_connector->bridge_hpd) {
> > connector->polled = DRM_CONNECTOR_POLL_HPD;
> > + drm_bridge_connector_enable_hpd(connector);
> > + }
> > else if (bridge_connector->bridge_detect)
> > connector->polled = DRM_CONNECTOR_POLL_CONNECT
> > | DRM_CONNECTOR_POLL_DISCONNECT;
>
> --
> Regards,
>
> Laurent Pinchart
Re: [PATCH] drm: rcar-du: Fix CRTC timings when CMM is used
Quoting Laurent Pinchart (2021-11-29 22:28:13) > When the CMM is enabled, an offset of 25 pixels must be subtracted from > the HDS (horizontal display start) and HDE (horizontal display end) > registers. Fix the timings calculation, and take this into account in > the mode validation. > > This fixes a visible horizontal offset in the image with VGA monitors. > HDMI monitors seem to be generally more tolerant to incorrect timings, > but may be affected too. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 20 > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > index 5672830ca184..ee6ba74627a2 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > @@ -215,6 +215,7 @@ static void rcar_du_crtc_set_display_timing(struct > rcar_du_crtc *rcrtc) > const struct drm_display_mode *mode = > >crtc.state->adjusted_mode; > struct rcar_du_device *rcdu = rcrtc->dev; > unsigned long mode_clock = mode->clock * 1000; > + unsigned int hdse_offset; > u32 dsmr; > u32 escr; > > @@ -298,10 +299,15 @@ static void rcar_du_crtc_set_display_timing(struct > rcar_du_crtc *rcrtc) > | DSMR_DIPM_DISP | DSMR_CSPM; > rcar_du_crtc_write(rcrtc, DSMR, dsmr); > This looks like the kind of place that could do with a comment explaining what is going on. > + hdse_offset = 19; > + if (rcrtc->group->cmms_mask & BIT(rcrtc->index % 2)) > + hdse_offset += 25; > + > /* Display timings */ > - rcar_du_crtc_write(rcrtc, HDSR, mode->htotal - mode->hsync_start - > 19); > + rcar_du_crtc_write(rcrtc, HDSR, mode->htotal - mode->hsync_start - > + hdse_offset); > rcar_du_crtc_write(rcrtc, HDER, mode->htotal - mode->hsync_start + > - mode->hdisplay - 19); > + mode->hdisplay - hdse_offset); > rcar_du_crtc_write(rcrtc, HSWR, mode->hsync_end - > mode->hsync_start - 1); > rcar_du_crtc_write(rcrtc, HCR, mode->htotal - 1); > @@ -836,6 +842,7 @@ rcar_du_crtc_mode_valid(struct drm_crtc *crtc, > struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc); > struct rcar_du_device *rcdu = rcrtc->dev; > bool interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE; > + unsigned int min_sync_porch; > unsigned int vbp; > > if (interlaced && !rcar_du_has(rcdu, RCAR_DU_FEATURE_INTERLACED)) > @@ -843,9 +850,14 @@ rcar_du_crtc_mode_valid(struct drm_crtc *crtc, > > /* > * The hardware requires a minimum combined horizontal sync and back > -* porch of 20 pixels and a minimum vertical back porch of 3 lines. > +* porch of 20 pixels (when CMM isn't used) or 45 pixels (when CMM is > +* used), and a minimum vertical back porch of 3 lines. > */ > - if (mode->htotal - mode->hsync_start < 20) > + min_sync_porch = 20; > + if (rcrtc->group->cmms_mask & BIT(rcrtc->index % 2)) > + min_sync_porch += 25; > + > + if (mode->htotal - mode->hsync_start < min_sync_porch) > return MODE_HBLANK_NARROW; Is the '19' in the hdse offset, this min_sync_port - 1 for position correction? It looks something like that. And the rest seems ok. With or without the additional optional comment suggestion above: Reviewed-by: Kieran Bingham > > vbp = (mode->vtotal - mode->vsync_end) / (interlaced ? 2 : 1); > > base-commit: c18c889bb5e014e144716044991112f16833 > prerequisite-patch-id: dc9121a1b85ea05bf3eae2b0ac2168d47101ee87 > -- > Regards, > > Laurent Pinchart >
Re: [PATCH 16/23] drm/rcar: plane: Remove redundant zpos initialisation
Quoting Maxime Ripard (2022-02-07 16:35:08)
> The rcar-du KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in rcar_du_plane_reset() and rcar_du_vsp_plane_reset().
> However, the helpers have been adjusted to set it properly at reset, so
> this is not needed anymore.
Sounds helpful ;-)
> Cc: linux-renesas-...@vger.kernel.org
> Cc: Kieran Bingham
> Cc: Laurent Pinchart
> Signed-off-by: Maxime Ripard
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 1 -
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 862197be1e01..9dda5e06457d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -696,7 +696,6 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
> state->hwindex = -1;
> state->source = RCAR_DU_PLANE_MEMORY;
> state->colorkey = RCAR_DU_COLORKEY_NONE;
> - state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> }
>
> static int rcar_du_plane_atomic_set_property(struct drm_plane *plane,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index b7fc5b069cbc..719c60034952 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -362,7 +362,6 @@ static void rcar_du_vsp_plane_reset(struct drm_plane
> *plane)
> return;
>
> __drm_atomic_helper_plane_reset(plane, >state);
> - state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> }
>
> static const struct drm_plane_funcs rcar_du_vsp_plane_funcs = {
> --
> 2.34.1
>
Re: [PATCH v2 31/37] drm: rcar-du: Add support for the nomodeset kernel parameter
Hi Javier,
Quoting Javier Martinez Canillas (2021-12-17 00:37:46)
> According to disable Documentation/admin-guide/kernel-parameters.txt, this
> parameter can be used to disable kernel modesetting.
>
> DRM drivers will not perform display-mode changes or accelerated rendering
> and only the system framebuffer will be available if it was set-up.
What is the 'system framebuffer' in this instance? Reading
https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
it sounds like that means anything already set up by the bootloader.
> But only a few DRM drivers currently check for nomodeset, make this driver
> to also support the command line parameter.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 5a8131ef81d5..982e450233ed 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -701,6 +701,9 @@ static struct platform_driver rcar_du_platform_driver = {
>
> static int __init rcar_du_init(void)
> {
> + if (drm_firmware_drivers_only())
> + return -ENODEV;
> +
This will completely disable all control of the display device when
nomodeset is enabled.
Is there any requirement for us to support outputting to the display if
it was previously set up? presumably without setting or changing any
modes, but simply allowing the existing frame to be updated?
I think the implication is that 'firmware drivers' would mean a display
could be updated through some firmware interface, which we won't have
... so it seems reasonable to accept that this whole driver can be
disabled in that instance.
Reading your mail that brought this thread up in my inbox, I think
you've already hit merge on this, so don't worry about adding a tag in
that instance, but I think this is ok.
Reviewed-by: Kieran Bingham
> rcar_du_of_init(rcar_du_of_table);
>
> return platform_driver_register(_du_platform_driver);
> --
> 2.33.1
>
Re: [PATCH] drm: rcar-du: Drop LVDS device tree backward compatibility
Quoting Laurent Pinchart (2022-01-26 20:29:56)
> The rcar-du driver goes to great lengths to preserve device tree
> backward compatibility for the LVDS encoders by patching old device
> trees at runtime.
>
> The last R-Car Gen2 platform was converted to the new bindings commit
> edb0c3affe5214a2 ("ARM: dts: r8a7793: Convert to new LVDS DT bindings"),
> in v4.17, and the last RZ/G1 platform converted in commit
> 6a6a797625b5fe85 ("ARM: dts: r8a7743: Convert to new LVDS DT bindings"),
> in v5.0. Both are older than commit 58256143cff7c2e0 ("clk: renesas:
> Remove R-Car Gen2 legacy DT clock support"), in v5.5, which removes
> support for legacy bindings for clocks. The LBDS compatibility code is
s/LBDS/LVDS/
> thus not needed anymore. Drop it.
Oh, I'm almost sad to see such exotic code go...
But code gone is less code to worry about so:
Reviewed-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/Makefile | 6 -
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 15 +-
> drivers/gpu/drm/rcar-du/rcar_du_of.c | 323 --
> drivers/gpu/drm/rcar-du/rcar_du_of.h | 20 --
> .../drm/rcar-du/rcar_du_of_lvds_r8a7790.dts | 69
> .../drm/rcar-du/rcar_du_of_lvds_r8a7791.dts | 43 ---
> .../drm/rcar-du/rcar_du_of_lvds_r8a7793.dts | 43 ---
> .../drm/rcar-du/rcar_du_of_lvds_r8a7795.dts | 43 ---
> .../drm/rcar-du/rcar_du_of_lvds_r8a7796.dts | 43 ---
> 9 files changed, 1 insertion(+), 604 deletions(-)
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
> delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts
>
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile
> index 286bc81b3e7c..e7275b5e7ec8 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -6,12 +6,6 @@ rcar-du-drm-y := rcar_du_crtc.o \
> rcar_du_kms.o \
> rcar_du_plane.o \
>
> -rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
> - rcar_du_of_lvds_r8a7790.dtb.o \
> - rcar_du_of_lvds_r8a7791.dtb.o \
> - rcar_du_of_lvds_r8a7793.dtb.o \
> - rcar_du_of_lvds_r8a7795.dtb.o \
> - rcar_du_of_lvds_r8a7796.dtb.o
> rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 5a8131ef81d5..71a9df5a4834 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -28,7 +28,6 @@
>
> #include "rcar_du_drv.h"
> #include "rcar_du_kms.h"
> -#include "rcar_du_of.h"
> #include "rcar_du_regs.h"
>
> /*
> -
> @@ -699,19 +698,7 @@ static struct platform_driver rcar_du_platform_driver = {
> },
> };
>
> -static int __init rcar_du_init(void)
> -{
> - rcar_du_of_init(rcar_du_of_table);
> -
> - return platform_driver_register(_du_platform_driver);
> -}
> -module_init(rcar_du_init);
> -
> -static void __exit rcar_du_exit(void)
> -{
> - platform_driver_unregister(_du_platform_driver);
> -}
> -module_exit(rcar_du_exit);
> +module_platform_driver(rcar_du_platform_driver);
>
> MODULE_AUTHOR("Laurent Pinchart ");
> MODULE_DESCRIPTION("Renesas R-Car Display Unit DRM Driver");
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> deleted file mode 100644
> index afef69669bb4..
> --- a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> +++ /dev/null
> @@ -1,323 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * rcar_du_of.c - Legacy DT bindings compatibility
> - *
> - * Copyright (C) 2018 Laurent Pinchart
> - *
> - * Based on work from Jyri Sarha
> - * Copyright (C) 2015 Texas Instruments
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#includ
Re: dw_hdmi is showing wrong colour after commit 7cd70656d1285b79("drm/bridge: display-connector: implement bus fmts callbacks")
Quoting Neil Armstrong (2022-01-17 13:53:47)
> On 17/01/2022 11:58, Kieran Bingham wrote:
> > Hi Neil,
> > This fixes the issue for me here on an H3 Salvator-XS.
> >
> > Could you add...
> >
> > Bisected-by: Kieran Bingham
> > Tested-by: Kieran Bingham
> >
> > alongside Biju's Reported-by: tag when posting as a fix please?
>
>
> Which patch did you test ?
Ah, yes that's not clear is it - sorry! I replied in the wrong place on
the thread when I went back to the mail ... see below...
> >> I'm not happy with this version since it's merely a hack which makes it
> >> work.
> >>
> >> Can you test the following change instead, it's correctly handles your
> >> situation in a generic manner.
> >>
> >> ><=
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> index 54d8fdad395f..9f2e1cac0ae2 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> @@ -2551,8 +2551,9 @@ static u32
> >> *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> >> if (!output_fmts)
> >> return NULL;
> >>
> >> - /* If dw-hdmi is the only bridge, avoid negociating with ourselves
> >> */
> >> - if (list_is_singular(>encoder->bridge_chain)) {
> >> + /* If dw-hdmi is the first or only bridge, avoid negociating with
> >> ourselves */
> >> + if (list_is_singular(>encoder->bridge_chain) ||
> >> + list_is_first(>chain_node,
> >> >encoder->bridge_chain)) {
> >> *num_output_fmts = 1;
> >> output_fmts[0] = MEDIA_BUS_FMT_FIXED;
> >>
> >> @@ -2673,6 +2674,10 @@ static u32
> >> *dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
> >> if (!input_fmts)
> >> return NULL;
> >>
> >> + /* If dw-hdmi is the first bridge fall-back to safe output format
> >> */
> >> + if (list_is_first(>chain_node,
> >> >encoder->bridge_chain))
> >> + output_fmt = MEDIA_BUS_FMT_FIXED;
> >> +
> >> switch (output_fmt) {
> >> /* If MEDIA_BUS_FMT_FIXED is tested, return default bus format */
> >> case MEDIA_BUS_FMT_FIXED:
> >> ><=
Sorry, I replied in the wrong part of the thread.
Here's the direct diff on my local tree:
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 54d8fdad395f..cac9a87949f1 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2551,8 +2551,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
if (!output_fmts)
return NULL;
- /* If dw-hdmi is the only bridge, avoid negociating with ourselves */
- if (list_is_singular(>encoder->bridge_chain)) {
+ /* If dw-hdmi is the first or only bridge, avoid negociating with
ourselves */
+ if (list_is_singular(>encoder->bridge_chain) ||
+ list_is_first(>chain_node, >encoder->bridge_chain))
{
+
*num_output_fmts = 1;
output_fmts[0] = MEDIA_BUS_FMT_FIXED;
@@ -2673,6 +2675,10 @@ static u32
*dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
if (!input_fmts)
return NULL;
+ /* If dw-hdmi is the first bridge fall-back to safe output format */
+ if (list_is_first(>chain_node, >encoder->bridge_chain))
+ output_fmt = MEDIA_BUS_FMT_FIXED;
+
switch (output_fmt) {
/* If MEDIA_BUS_FMT_FIXED is tested, return default bus format */
case MEDIA_BUS_FMT_FIXED:
Which I believe matches the above.
--
Kieran
Re: dw_hdmi is showing wrong colour after commit 7cd70656d1285b79("drm/bridge: display-connector: implement bus fmts callbacks")
dmi-imx 12.hdmi: Detected HDMI TX controller v1.30a with
> >>>>>>>> HDCP (DWC HDMI 3D TX PHY)
> >>>>>>>>
> >>>>>>>> The colors are shown correctly here.
> >>>>>>>>
> >>>>>>>
> >>>>>>> The imx doesn't use DRM_BRIDGE_ATTACH_NO_CONNECTOR so the
> >>>>>>> negotiation fails and use the RGB fallback input & output format.
> >>>>>>>
> >>>>>>> Anyway thanks for testing
> >>>>>>>
> >>>>>>> Neil
> >>>>>
> >>>>> Can you test :
> >>>>>
> >>>>> ==><===========
> >>>>> diff --git a/drivers/gpu/drm/drm_bridge.c
> >>>>> b/drivers/gpu/drm/drm_bridge.c index c96847fc0ebc..7019acd37716
> >>>>> 100644
> >>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>> @@ -955,7 +955,14 @@ drm_atomic_bridge_chain_select_bus_fmts(struct
> >>>>> drm_bridge *bridge,
> >>>>> last_bridge_state =
> >>>>> drm_atomic_get_new_bridge_state(crtc_state-
> >>>>>> state,
> >>>>>
> >>>>> last_bridge);
> >>>>>
> >>>>> - if (last_bridge->funcs->atomic_get_output_bus_fmts) {
> >>>>> + /*
> >>>>> +* Only negociate with real values if both end of the bridge
> >>> chain
> >>>>> +* support negociation callbacks, otherwise you can end in a
> >>>>> situation
> >>>>> +* where the selected output format doesn't match with the
> >>>>> + first
> >>>>> bridge
> >>>>> +* output format.
> >>>>> +*/
> >>>>> + if (bridge->funcs->atomic_get_input_bus_fmts &&
> >>>>> + last_bridge->funcs->atomic_get_output_bus_fmts) {
> >>>>> const struct drm_bridge_funcs *funcs =
> >>>>> last_bridge->funcs;
> >>>>>
> >>>>> /*
> >>>>> @@ -980,7 +987,12 @@ drm_atomic_bridge_chain_select_bus_fmts(struct
> >>>>> drm_bridge *bridge,
> >>>>> if (!out_bus_fmts)
> >>>>> return -ENOMEM;
> >>>>>
> >>>>> - if (conn->display_info.num_bus_formats &&
> >>>>> + /*
> >>>>> +* If first bridge doesn't support negociation, use
> >>>>> MEDIA_BUS_FMT_FIXED
> >>>>> +* as a safe value for the whole bridge chain
> >>>>> +*/
> >>>>> + if (bridge->funcs->atomic_get_input_bus_fmts &&
> >>>>> + conn->display_info.num_bus_formats &&
> >>>>> conn->display_info.bus_formats)
> >>>>> out_bus_fmts[0] = conn-
> >>>>>> display_info.bus_formats[0];
> >>>>> else
> >>>>> ==><===
> >>>>>
> >>>>> This should exclude your situation where the first bridge doesn't
> >>>>> support negociation.
This fixes the issue for me here on an H3 Salvator-XS.
Could you add...
Bisected-by: Kieran Bingham
Tested-by: Kieran Bingham
alongside Biju's Reported-by: tag when posting as a fix please?
> >>>>
> >>>> I have tested this fix with Linux next-20220114. Still I see colour
> >>> issue.
> >>>>
> >>>> It is still negotiating and it is calling get_output_fmt_callbck
> >>>>
> >>>> [3.460155] dw_hdmi_bridge_atomic_get_output_bus_fmts
> >>> MEDIA_BUS_FMT_UYVY8_1X16=0#
> >>>> [3.460180] dw_hdmi_bridge_atomic_get_output_bus_fmts
> >>> MEDIA_BUS_FMT_YUV8_1X24=1#
> >>>> [3.460202] dw_hdmi_bridge_atomic_get_output_bus_fmts
> >>> MEDIA_BUS_FMT_RGB888_1X24=2#
> >>>>
> >>>> And In get_input_fmt callback, I See the outputformat as YUV16 instead
> >>> of RGB24.
> >>>>
> >>>> [3.460319] dw_hdmi_bridge_atomic_get_input_bus_fmts
> >>> MEDIA_BUS_FMT_UYVY8_1X16#
> >>>> [3.473644] hdmi_video_sample
> >>> MEDIA_BUS_FMT_UYVY8_1X16#
> >>>
> >>> OK, looking at rcar-du, the dw-hdmi bridge is directly connected to the
> >>> encoder.
> >>
> >> Yep.
> >>
> >>>
> >>> Let me figure that out, no sure I can find a clean solution except putting
> >>> back RGB24 before YUV.
> >>>
> >>> Anyway please test that:
> >>
> >> It works now after reordering.
> >>
> >> [3.493302] dw_hdmi_bridge_atomic_get_output_bus_fmts
> >> MEDIA_BUS_FMT_RGB888_1X24=0#
> >> [3.493326] dw_hdmi_bridge_atomic_get_output_bus_fmts
> >> MEDIA_BUS_FMT_YUV8_1X24=1#
> >> [3.493348] dw_hdmi_bridge_atomic_get_output_bus_fmts
> >> MEDIA_BUS_FMT_UYVY8_1X16=2#
> >>
> >> [3.493463] dw_hdmi_bridge_atomic_get_input_bus_fmts
> >> MEDIA_BUS_FMT_RGB888_1X24#
> >> [3.506797] hdmi_video_sample MEDIA_BUS_FMT_RGB888_1X24#
> >>
> >> Is it acceptable solution to the users of dw_hdmi driver? May be it is
> >> worth to post a patch.
> >> at least it is fixing the colour issue??
> >
> > Yes, it gets back to default behavior before negociation, nevertheless we
> > need to think
> > how to handle your use-case correctly at some point.
> >
> > I'll post this as a patch ASAP so it gets applied before landing in linus
> > master.
> >
> > Neil
> >
> >>
> >> Regards,
> >> Biju
> >>
> >>>
> [...]
>
> I'm not happy with this version since it's merely a hack which makes it work.
>
> Can you test the following change instead, it's correctly handles your
> situation in a generic manner.
>
> ><=
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 54d8fdad395f..9f2e1cac0ae2 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2551,8 +2551,9 @@ static u32
> *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> if (!output_fmts)
> return NULL;
>
> - /* If dw-hdmi is the only bridge, avoid negociating with ourselves */
> - if (list_is_singular(>encoder->bridge_chain)) {
> + /* If dw-hdmi is the first or only bridge, avoid negociating with
> ourselves */
> + if (list_is_singular(>encoder->bridge_chain) ||
> + list_is_first(>chain_node,
> >encoder->bridge_chain)) {
> *num_output_fmts = 1;
> output_fmts[0] = MEDIA_BUS_FMT_FIXED;
>
> @@ -2673,6 +2674,10 @@ static u32
> *dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
> if (!input_fmts)
> return NULL;
>
> + /* If dw-hdmi is the first bridge fall-back to safe output format */
> + if (list_is_first(>chain_node,
> >encoder->bridge_chain))
> + output_fmt = MEDIA_BUS_FMT_FIXED;
> +
> switch (output_fmt) {
> /* If MEDIA_BUS_FMT_FIXED is tested, return default bus format */
> case MEDIA_BUS_FMT_FIXED:
> ><=
>
> Thanks,
> Neil
>
>
> >>>
> >>> Neil
> >>>
> >>>>
> >>>> Regards,
> >>>> Biju
> >>>>
> >>
> >
>
Re: [PATCH] drm: adv7511: override i2c address of cec before accessing it
Quoting Antonio Borneo (2021-12-20 15:53:12)
> On Mon, 2021-12-20 at 14:54 +0000, Kieran Bingham wrote:
> > Hi Antonio,
> >
> > Quoting Antonio Borneo (2021-12-18 18:28:04)
> > > Commit 680532c50bca ("drm: adv7511: Add support for
> > > i2c_new_secondary_device") allows a device tree node to override
> > > the default addresses of the secondary i2c devices. This is useful
> > > for solving address conflicts on the i2c bus.
> > >
> > > In adv7511_init_cec_regmap() the new i2c address of cec device is
> > > read from device tree and immediately accessed, well before it is
> > > written in the proper register to override the default address.
> > > This can cause an i2c error during probe and a consequent probe
> > > failure.
> >
> > Ouch, it does seem that way. I guess no one has used the CEC for
> > quite
> > some time, as it must have been like this for a while?
>
> Using the default i2c address for cec works without problem; apparently
> everyone is happy with such default. The issue appears only when you
> have to override the default cec address.
> The commit 680532c50bca landed in v4.18.
Ok, phew - so the 'normal' case still worked. That makes sense.
Sorry for getting it wrong, and I hope it didn't take too long to find
and fix. I'm sure we'll see it percolate down the stable trees once
integrated.
--
Kieran
> > > Once the new i2c address is read from the device tree, override
> > > the default address before any attempt to access the cec.
> >
> > Reviewed-by: Kieran Bingham
>
> Thanks!
> Antonio
>
> > > Tested with adv7533 and stm32mp157f.
> > >
> > > Signed-off-by: Antonio Borneo
> > > Fixes: 680532c50bca ("drm: adv7511: Add support for
> > > i2c_new_secondary_device")
> > > ---
> > > To: Andrzej Hajda
> > > To: Neil Armstrong
> > > To: Robert Foss
> > > To: Laurent Pinchart
> > > To: Jonas Karlman
> > > To: Jernej Skrabec
> > > To: David Airlie
> > > To: Daniel Vetter
> > > To: Kieran Bingham
> > > To: dri-devel@lists.freedesktop.org
> > > Cc: linux-ker...@vger.kernel.org
> > > Cc: linux-st...@st-md-mailman.stormreply.com
> > > ---
> > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > index 76555ae64e9c..629e05286fd9 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > @@ -1048,6 +1048,10 @@ static int adv7511_init_cec_regmap(struct
> > > adv7511 *adv)
> > >
> > > ADV7511_CEC_I2C_ADDR_DEFAULT);
> > > if (IS_ERR(adv->i2c_cec))
> > > return PTR_ERR(adv->i2c_cec);
> > > +
> > > + regmap_write(adv->regmap, ADV7511_REG_CEC_I2C_ADDR,
> > > + adv->i2c_cec->addr << 1);
> > > +
> > > i2c_set_clientdata(adv->i2c_cec, adv);
> > >
> > > adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,
> > > @@ -1252,9 +1256,6 @@ static int adv7511_probe(struct i2c_client
> > > *i2c, const struct i2c_device_id *id)
> > > if (ret)
> > > goto err_i2c_unregister_packet;
> > >
> > > - regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
> > > - adv7511->i2c_cec->addr << 1);
> > > -
> > > INIT_WORK(>hpd_work, adv7511_hpd_work);
> > >
> > > if (i2c->irq) {
> > >
> > > base-commit: fc74881c28d314b10efac016ef49df4ff40b8b97
> > > --
> > > 2.34.1
> > >
>
Re: [PATCH] drm: adv7511: override i2c address of cec before accessing it
Hi Antonio,
Quoting Antonio Borneo (2021-12-18 18:28:04)
> Commit 680532c50bca ("drm: adv7511: Add support for
> i2c_new_secondary_device") allows a device tree node to override
> the default addresses of the secondary i2c devices. This is useful
> for solving address conflicts on the i2c bus.
>
> In adv7511_init_cec_regmap() the new i2c address of cec device is
> read from device tree and immediately accessed, well before it is
> written in the proper register to override the default address.
> This can cause an i2c error during probe and a consequent probe
> failure.
Ouch, it does seem that way. I guess no one has used the CEC for quite
some time, as it must have been like this for a while?
> Once the new i2c address is read from the device tree, override
> the default address before any attempt to access the cec.
Reviewed-by: Kieran Bingham
> Tested with adv7533 and stm32mp157f.
>
> Signed-off-by: Antonio Borneo
> Fixes: 680532c50bca ("drm: adv7511: Add support for i2c_new_secondary_device")
> ---
> To: Andrzej Hajda
> To: Neil Armstrong
> To: Robert Foss
> To: Laurent Pinchart
> To: Jonas Karlman
> To: Jernej Skrabec
> To: David Airlie
> To: Daniel Vetter
> To: Kieran Bingham
> To: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 76555ae64e9c..629e05286fd9 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -1048,6 +1048,10 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
> ADV7511_CEC_I2C_ADDR_DEFAULT);
> if (IS_ERR(adv->i2c_cec))
> return PTR_ERR(adv->i2c_cec);
> +
> + regmap_write(adv->regmap, ADV7511_REG_CEC_I2C_ADDR,
> +adv->i2c_cec->addr << 1);
> +
> i2c_set_clientdata(adv->i2c_cec, adv);
>
> adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,
> @@ -1252,9 +1256,6 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id)
> if (ret)
> goto err_i2c_unregister_packet;
>
> - regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
> -adv7511->i2c_cec->addr << 1);
> -
> INIT_WORK(>hpd_work, adv7511_hpd_work);
>
> if (i2c->irq) {
>
> base-commit: fc74881c28d314b10efac016ef49df4ff40b8b97
> --
> 2.34.1
>
Re: [PATCH] drm: rcar-du: Use dev_err_probe() helper
Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> Use the dev_err_probe() helper, instead of open-coding the same
> operation.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 5612a9e7a9056cf7..86eeda769e2ebd10 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -661,9 +661,8 @@ static int rcar_du_probe(struct platform_device *pdev)
> /* DRM/KMS objects */
> ret = rcar_du_modeset_init(rcdu);
> if (ret < 0) {
> - if (ret != -EPROBE_DEFER)
> - dev_err(>dev,
> - "failed to initialize DRM/KMS (%d)\n", ret);
> + dev_err_probe(>dev, ret,
> + "failed to initialize DRM/KMS\n");
I've just learned that dev_err_probe() sets a 'reason' for the deferral.
Seems like a nice feature when exploring devices that are still waiting
to probe. Is the message still appropriate enough in that case?
I think it's probably fine, so
Reviewed-by: Kieran Bingham
> goto error;
> }
>
> --
> 2.25.1
>
Re: [PATCH] drm: rcar-du: dsi: Fix hsfreq range matching
Quoting Laurent Pinchart (2021-12-06 14:06:01)
> When iterating over hsfreqrange_table, rcar_mipi_dsi_parameters_calc()
> may dereference the sentinel table entry. Fix the loop condition to
> break as soon as a suitable entry is found, defined by the lower bound
> of the frequency range stored in the table being equal to or higher than
> the target frequency.
>
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Laurent Pinchart
> ---
> I will squash this with "drm: rcar-du: Add R-Car DSI driver", but I'm
> posting it separately to ease review.
> ---
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> index faf993eae564..891bb956fd61 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> @@ -219,9 +219,8 @@ static void rcar_mipi_dsi_parameters_calc(struct
> rcar_mipi_dsi *dsi,
> /* Find hsfreqrange */
> hsfreq = fout_target * 2;
> for (i = 0; i < ARRAY_SIZE(hsfreqrange_table); i++) {
> - if (hsfreq > hsfreqrange_table[i][0] &&
> - hsfreq <= hsfreqrange_table[i+1][0]) {
> - setup_info->hsfreqrange = hsfreqrange_table[i+1][1];
> + if (hsfreqrange_table[i][0] >= hsfreq) {
It's hard to tell from this patch, or this point alone, but I see that
fout_target is already limited at 125000, so hsfreq can never be
bigger than 25U.
So ... this is fine (as long as the table and validation check are kept
in sync if anyone updates this).
Reviewed-by: Kieran Bingham
Also validated that it still boots/probes and displays pictures with
kmstest and kmstest --flip.
--
Kieran
> + setup_info->hsfreqrange = hsfreqrange_table[i][1];
> break;
> }
> }
>
> base-commit: c18c889bb5e014e144716044991112f16833
> prerequisite-patch-id: dc9121a1b85ea05bf3eae2b0ac2168d47101ee87
> prerequisite-patch-id: 6754b2ec4caec03e235550004003fe63c1cc793b
> prerequisite-patch-id: d69c605df34d40934fa5d4e00f23d5785105099d
> prerequisite-patch-id: 7d9edfb4758cafe8aec92d32709c0ad25a50942c
> prerequisite-patch-id: 86c526fb41f9f9cbe95c50ba8a140e20484f187f
> prerequisite-patch-id: a9649b53b55858f023b8d3d29afb9be7ad39ea3b
> --
> Regards,
>
> Laurent Pinchart
>
Re: [PATCH v3.1 2/2] drm: rcar-du: Add R-Car DSI driver
Quoting Laurent Pinchart (2021-12-01 21:57:29)
> From: LUU HOAI
>
> The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
> SoC. It currently supports DSI mode only.
>
> Signed-off-by: LUU HOAI
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Kieran Bingham
> Tested-by: Kieran Bingham
> Acked-by: Sam Ravnborg
> ---
> Changes since v3:
>
> - Use bridge atomic ops
(Re-Re-Re)Tested-by: Kieran Bingham
We're still probing and displaying fine here.
--
Kieran
>
> Changes since v2:
>
> - Support probing of child DSI devices
> - Use devm_drm_of_get_bridge() helper
>
> Changes since v1:
>
> - Use U suffix for unsigned constants
> - Fix indentation in Makefile
> - Select DRM_MIPI_DSI
> - Report correct fout frequency in debug message
> - Move dsi_setup_info.err to local variable
> ---
> drivers/gpu/drm/rcar-du/Kconfig | 7 +
> drivers/gpu/drm/rcar-du/Makefile | 1 +
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 820 +++
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 172
> 4 files changed, 1000 insertions(+)
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
>
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 3e588ddba245..1675df21d91f 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -45,6 +45,13 @@ config DRM_RCAR_LVDS
> select OF_FLATTREE
> select OF_OVERLAY
>
> +config DRM_RCAR_MIPI_DSI
> + tristate "R-Car DU MIPI DSI Encoder Support"
> + depends on DRM && DRM_BRIDGE && OF
> + select DRM_MIPI_DSI
> + help
> + Enable support for the R-Car Display Unit embedded MIPI DSI
> encoders.
> +
> config DRM_RCAR_VSP
> bool "R-Car DU VSP Compositor Support" if ARM
> default y if ARM64
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile
> index 4d1187ccc3e5..286bc81b3e7c 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_RCAR_CMM)+= rcar_cmm.o
> obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> +obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o
>
> # 'remote-endpoint' is fixed up at run-time
> DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> new file mode 100644
> index ..faf993eae564
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> @@ -0,0 +1,820 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * rcar_mipi_dsi.c -- R-Car MIPI DSI Encoder
> + *
> + * Copyright (C) 2020 Renesas Electronics Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "rcar_mipi_dsi_regs.h"
> +
> +struct rcar_mipi_dsi {
> + struct device *dev;
> + const struct rcar_mipi_dsi_device_info *info;
> + struct reset_control *rstc;
> +
> + struct mipi_dsi_host host;
> + struct drm_bridge bridge;
> + struct drm_bridge *next_bridge;
> + struct drm_connector connector;
> +
> + void __iomem *mmio;
> + struct {
> + struct clk *mod;
> + struct clk *pll;
> + struct clk *dsi;
> + } clocks;
> +
> + enum mipi_dsi_pixel_format format;
> + unsigned int num_data_lanes;
> + unsigned int lanes;
> +};
> +
> +static inline struct rcar_mipi_dsi *
> +bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct rcar_mipi_dsi, bridge);
> +}
> +
> +static inline struct rcar_mipi_dsi *
> +host_to_rcar_mipi_dsi(struct mipi_dsi_host *host)
> +{
> + return container_of(host, struct rcar_mipi_dsi, host);
> +}
> +
> +static const u32 phtw[] = {
> + 0x01020114, 0x01600115, /* General testing */
> + 0x01030116, 0x0102011d, /* General testing */
> + 0x011101a4, 0x018601a4, /* 1Gbps testing */
> + 0x014201a0, 0x010001a3, /* 1Gbps testing */
> + 0x0101011f, /* 1Gbps testing
Re: [PATCH v2 1/2] drm: rcar-du: mipi-dsi: Support bridge probe ordering
Quoting Laurent Pinchart (2021-12-01 04:38:46)
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tue, Nov 30, 2021 at 04:25:12PM +, Kieran Bingham wrote:
> > The bridge probe ordering for DSI devices has been clarified and further
> > documented in
>
> I've read the document and
>
Good, I'm glad you've fully got the
>
> :-)
Sorry, not sure how I missed that, I must have failed to paste in the
link to the DSI probe documentation. But as you've read that, and now
this is squashed, I think this is done anyway.
Thanks for handling the integrations.
--
Kieran
>
> > To support connecting with the SN65DSI86 device after commit c3b75d4734cb
> > ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe"),
> > update to the new probe ordering to remove a perpetual -EPROBE_DEFER
> > loop between the two devices.
> >
> > Signed-off-by: Kieran Bingham
> >
> > ---
> > v2
> > - Remove now unused panel variable from rcar_mipi_dsi_probe()
> >
> > drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 49 +
> > 1 file changed, 26 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > index 50e922328fed..0a9f197ef62c 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > @@ -637,6 +637,8 @@ static int rcar_mipi_dsi_host_attach(struct
> > mipi_dsi_host *host,
> > struct mipi_dsi_device *device)
> > {
> > struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> > + struct drm_panel *panel;
> > + int ret;
> >
> > if (device->lanes > dsi->num_data_lanes)
> > return -EINVAL;
> > @@ -644,12 +646,36 @@ static int rcar_mipi_dsi_host_attach(struct
> > mipi_dsi_host *host,
> > dsi->lanes = device->lanes;
> > dsi->format = device->format;
> >
> > + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> > + >next_bridge);
> > + if (ret) {
> > + dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
>
> dev_err_probe() should only be used in probe(), and this function isn't
> guaranteed to be called at probe time only.
>
> This isn't a big deal as the next patch fixes this, and both will be
> squashed. Furthermore, rcar_mipi_dsi_host_attach() should only be called
> when the DSI device gets registered, which should happen after it
> registers its bridge, so I don't think we can see a probe deferral here.
>
> Other than that the patch looks fine, I'll squash it with the DSI
> driver.
>
> > + return ret;
> > + }
> > +
> > + if (!dsi->next_bridge) {
> > + dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
> > + if (IS_ERR(dsi->next_bridge)) {
> > + dev_err(dsi->dev, "failed to create panel bridge\n");
> > + return PTR_ERR(dsi->next_bridge);
> > + }
> > + }
> > +
> > + /* Initialize the DRM bridge. */
> > + dsi->bridge.funcs = _mipi_dsi_bridge_ops;
> > + dsi->bridge.of_node = dsi->dev->of_node;
> > + drm_bridge_add(>bridge);
> > +
> > return 0;
> > }
> >
> > static int rcar_mipi_dsi_host_detach(struct mipi_dsi_host *host,
> > struct mipi_dsi_device *device)
> > {
> > + struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> > +
> > + drm_bridge_remove(>bridge);
> > +
> > return 0;
> > }
> >
> > @@ -731,7 +757,6 @@ static int rcar_mipi_dsi_get_clocks(struct
> > rcar_mipi_dsi *dsi)
> > static int rcar_mipi_dsi_probe(struct platform_device *pdev)
> > {
> > struct rcar_mipi_dsi *dsi;
> > - struct drm_panel *panel;
> > struct resource *mem;
> > int ret;
> >
> > @@ -764,21 +789,6 @@ static int rcar_mipi_dsi_probe(struct platform_device
> > *pdev)
> > return PTR_ERR(dsi->rstc);
> > }
> >
> > - ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> > - >next_bridge);
> > - if (ret) {
> > - dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
> > -
Re: [PATCH v3 2/2] drm: rcar-du: Add R-Car DSI driver
Quoting Laurent Pinchart (2021-12-01 05:24:06)
> From: LUU HOAI
>
> The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
> SoC. It currently supports DSI mode only.
>
> Signed-off-by: LUU HOAI
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Kieran Bingham
> Tested-by: Kieran Bingham
And as there have been some changes to the probe / bridge handling:
(Re)Tested-by: Kieran Bingham
> Acked-by: Sam Ravnborg
> ---
> Changes since v2:
>
> - Support probing of child DSI devices
> - Use devm_drm_of_get_bridge() helper
>
> Changes since v1:
>
> - Use U suffix for unsigned constants
> - Fix indentation in Makefile
> - Select DRM_MIPI_DSI
> - Report correct fout frequency in debug message
> - Move dsi_setup_info.err to local variable
> ---
> drivers/gpu/drm/rcar-du/Kconfig | 7 +
> drivers/gpu/drm/rcar-du/Makefile | 1 +
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 817 +++
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 172
> 4 files changed, 997 insertions(+)
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
>
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 3e588ddba245..1675df21d91f 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -45,6 +45,13 @@ config DRM_RCAR_LVDS
> select OF_FLATTREE
> select OF_OVERLAY
>
> +config DRM_RCAR_MIPI_DSI
> + tristate "R-Car DU MIPI DSI Encoder Support"
> + depends on DRM && DRM_BRIDGE && OF
> + select DRM_MIPI_DSI
> + help
> + Enable support for the R-Car Display Unit embedded MIPI DSI
> encoders.
> +
> config DRM_RCAR_VSP
> bool "R-Car DU VSP Compositor Support" if ARM
> default y if ARM64
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile
> index 4d1187ccc3e5..286bc81b3e7c 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_RCAR_CMM)+= rcar_cmm.o
> obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> +obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o
>
> # 'remote-endpoint' is fixed up at run-time
> DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> new file mode 100644
> index ..fcaec3308d68
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> @@ -0,0 +1,817 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * rcar_mipi_dsi.c -- R-Car MIPI DSI Encoder
> + *
> + * Copyright (C) 2020 Renesas Electronics Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "rcar_mipi_dsi_regs.h"
> +
> +struct rcar_mipi_dsi {
> + struct device *dev;
> + const struct rcar_mipi_dsi_device_info *info;
> + struct reset_control *rstc;
> +
> + struct mipi_dsi_host host;
> + struct drm_bridge bridge;
> + struct drm_bridge *next_bridge;
> + struct drm_connector connector;
> +
> + void __iomem *mmio;
> + struct {
> + struct clk *mod;
> + struct clk *pll;
> + struct clk *dsi;
> + } clocks;
> +
> + struct drm_display_mode display_mode;
> + enum mipi_dsi_pixel_format format;
> + unsigned int num_data_lanes;
> + unsigned int lanes;
> +};
> +
> +static inline struct rcar_mipi_dsi *
> +bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct rcar_mipi_dsi, bridge);
> +}
> +
> +static inline struct rcar_mipi_dsi *
> +host_to_rcar_mipi_dsi(struct mipi_dsi_host *host)
> +{
> + return container_of(host, struct rcar_mipi_dsi, host);
> +}
> +
> +static const u32 phtw[] = {
> + 0x01020114, 0x01600115, /* General testing */
> + 0x01030116, 0x0102011d, /* General testing */
> + 0x011101a4, 0x018601a4, /* 1Gbps testing */
> + 0x014201a0, 0x010001a3, /* 1Gbps testing */
> + 0x0101011f, /* 1Gbps testing */
> +
Re: [PATCH v2 2/2] drm: rcar-du: mipi-dsi: Use devm_drm_of_get_bridge helper
Hi Laurent,
Quoting Kieran Bingham (2021-11-30 16:25:13)
> Instead of open coding the calls for
> drm_of_find_panel_or_bridge()
> devm_drm_panel_bridge_add()
>
> use the devm_drm_of_get_bridge() helper directly.
>
> Signed-off-by: Kieran Bingham
> ---
> v2:
> - New patch
>
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 19 ---
> 1 file changed, 4 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> index 0a9f197ef62c..1dfe20d3d0f2 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> @@ -637,7 +637,7 @@ static int rcar_mipi_dsi_host_attach(struct mipi_dsi_host
> *host,
> struct mipi_dsi_device *device)
> {
> struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> - struct drm_panel *panel;
> + struct device *dev = dsi->dev;
> int ret;
>
> if (device->lanes > dsi->num_data_lanes)
> @@ -646,20 +646,9 @@ static int rcar_mipi_dsi_host_attach(struct
> mipi_dsi_host *host,
> dsi->lanes = device->lanes;
> dsi->format = device->format;
>
> - ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> - >next_bridge);
> - if (ret) {
> - dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
> - return ret;
> - }
> -
> - if (!dsi->next_bridge) {
> - dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
> - if (IS_ERR(dsi->next_bridge)) {
> - dev_err(dsi->dev, "failed to create panel bridge\n");
> - return PTR_ERR(dsi->next_bridge);
> - }
> - }
> + dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
> + if (IS_ERR(dsi->next_bridge))
> + return PTR_ERR(dsi->next_bridge);
I did make a change here to make this:
dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
if (IS_ERR(dsi->next_bridge)) {
dev_err(dev, "failed to get next bridge\n");
return PTR_ERR(dsi->next_bridge);
}
But it seems I got out of sequence and saved out the wrong patch ;-(
If you think it's better with the error print, please add it while
squashing, or if you really need, I can send an updated patch and
retest.
--
Kieran
>
> /* Initialize the DRM bridge. */
> dsi->bridge.funcs = _mipi_dsi_bridge_ops;
> --
> 2.30.2
>
[PATCH v2 2/2] drm: rcar-du: mipi-dsi: Use devm_drm_of_get_bridge helper
Instead of open coding the calls for
drm_of_find_panel_or_bridge()
devm_drm_panel_bridge_add()
use the devm_drm_of_get_bridge() helper directly.
Signed-off-by: Kieran Bingham
---
v2:
- New patch
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
index 0a9f197ef62c..1dfe20d3d0f2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
@@ -637,7 +637,7 @@ static int rcar_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
- struct drm_panel *panel;
+ struct device *dev = dsi->dev;
int ret;
if (device->lanes > dsi->num_data_lanes)
@@ -646,20 +646,9 @@ static int rcar_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->lanes = device->lanes;
dsi->format = device->format;
- ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
- >next_bridge);
- if (ret) {
- dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
- return ret;
- }
-
- if (!dsi->next_bridge) {
- dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
- if (IS_ERR(dsi->next_bridge)) {
- dev_err(dsi->dev, "failed to create panel bridge\n");
- return PTR_ERR(dsi->next_bridge);
- }
- }
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
+ if (IS_ERR(dsi->next_bridge))
+ return PTR_ERR(dsi->next_bridge);
/* Initialize the DRM bridge. */
dsi->bridge.funcs = _mipi_dsi_bridge_ops;
--
2.30.2
[PATCH v2 1/2] drm: rcar-du: mipi-dsi: Support bridge probe ordering
The bridge probe ordering for DSI devices has been clarified and further
documented in
To support connecting with the SN65DSI86 device after commit c3b75d4734cb
("drm/bridge: sn65dsi86: Register and attach our DSI device at probe"),
update to the new probe ordering to remove a perpetual -EPROBE_DEFER
loop between the two devices.
Signed-off-by: Kieran Bingham
---
v2
- Remove now unused panel variable from rcar_mipi_dsi_probe()
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 49 +
1 file changed, 26 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
index 50e922328fed..0a9f197ef62c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
@@ -637,6 +637,8 @@ static int rcar_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
+ struct drm_panel *panel;
+ int ret;
if (device->lanes > dsi->num_data_lanes)
return -EINVAL;
@@ -644,12 +646,36 @@ static int rcar_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->lanes = device->lanes;
dsi->format = device->format;
+ ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
+ >next_bridge);
+ if (ret) {
+ dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
+ return ret;
+ }
+
+ if (!dsi->next_bridge) {
+ dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
+ if (IS_ERR(dsi->next_bridge)) {
+ dev_err(dsi->dev, "failed to create panel bridge\n");
+ return PTR_ERR(dsi->next_bridge);
+ }
+ }
+
+ /* Initialize the DRM bridge. */
+ dsi->bridge.funcs = _mipi_dsi_bridge_ops;
+ dsi->bridge.of_node = dsi->dev->of_node;
+ drm_bridge_add(>bridge);
+
return 0;
}
static int rcar_mipi_dsi_host_detach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
+ struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
+
+ drm_bridge_remove(>bridge);
+
return 0;
}
@@ -731,7 +757,6 @@ static int rcar_mipi_dsi_get_clocks(struct rcar_mipi_dsi
*dsi)
static int rcar_mipi_dsi_probe(struct platform_device *pdev)
{
struct rcar_mipi_dsi *dsi;
- struct drm_panel *panel;
struct resource *mem;
int ret;
@@ -764,21 +789,6 @@ static int rcar_mipi_dsi_probe(struct platform_device
*pdev)
return PTR_ERR(dsi->rstc);
}
- ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
- >next_bridge);
- if (ret) {
- dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
- return ret;
- }
-
- if (!dsi->next_bridge) {
- dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
- if (IS_ERR(dsi->next_bridge)) {
- dev_err(dsi->dev, "failed to create panel bridge\n");
- return PTR_ERR(dsi->next_bridge);
- }
- }
-
/* Initialize the DSI host. */
dsi->host.dev = dsi->dev;
dsi->host.ops = _mipi_dsi_host_ops;
@@ -786,11 +796,6 @@ static int rcar_mipi_dsi_probe(struct platform_device
*pdev)
if (ret < 0)
return ret;
- /* Initialize the DRM bridge. */
- dsi->bridge.funcs = _mipi_dsi_bridge_ops;
- dsi->bridge.of_node = dsi->dev->of_node;
- drm_bridge_add(>bridge);
-
return 0;
}
@@ -798,8 +803,6 @@ static int rcar_mipi_dsi_remove(struct platform_device
*pdev)
{
struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
- drm_bridge_remove(>bridge);
-
mipi_dsi_host_unregister(>host);
return 0;
--
2.30.2
[PATCH v2 0/2] drm: rcar-du: mipi-dsi: Cleanup and Fixes
Following on from the earlier version of this series, is an updated patch to move the bridge registration from rcar_mipi_dsi_probe() to rcar_mipi_dsi_host_attach() followed by an immediate update to that code to refactor it to use the new devm_drm_of_get_bridge helper. These two patches are kept distinct to support review, and are both expected to be squashed directly into the still-to-be-posted update of the DSI driver by Laurent [0]. [0] https://lore.kernel.org/all/20210623135639.17125-1-laurent.pinchart+rene...@ideasonboard.com/ The previous patches 1/4, 2/4 and 3/4 from the v1 of this series have already been accepted by Laurent and squashed into his tree, so are not reposted. Kieran Bingham (2): drm: rcar-du: mipi-dsi: Support bridge probe ordering drm: rcar-du: mipi-dsi: Use devm_drm_of_get_bridge helper drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 38 ++--- 1 file changed, 15 insertions(+), 23 deletions(-) -- 2.30.2
Re: [PATCH 4/4] drm: rcar-du: mipi-dsi: Support bridge probe ordering
Hi Jagan,
Quoting Jagan Teki (2021-11-30 07:38:57)
> Hi Kieran,
>
> On Fri, Nov 26, 2021 at 3:45 PM Kieran Bingham
> wrote:
> >
> > The bridge probe ordering for DSI devices has been clarified and further
> > documented in
> >
> > To support connecting with the SN65DSI86 device after commit c3b75d4734cb
> > ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe"),
> > update to the new probe ordering to remove a perpetual -EPROBE_DEFER
> > loop between the two devices.
> >
> > Signed-off-by: Kieran Bingham
> > ---
> > drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 48 +
> > 1 file changed, 26 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > index 833f4480bdf3..f783bacee8da 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > @@ -639,6 +639,8 @@ static int rcar_mipi_dsi_host_attach(struct
> > mipi_dsi_host *host,
> > struct mipi_dsi_device *device)
> > {
> > struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> > + struct drm_panel *panel;
> > + int ret;
> >
> > if (device->lanes > dsi->num_data_lanes)
> > return -EINVAL;
> > @@ -646,12 +648,36 @@ static int rcar_mipi_dsi_host_attach(struct
> > mipi_dsi_host *host,
> > dsi->lanes = device->lanes;
> > dsi->format = device->format;
> >
> > + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> > + >next_bridge);
> > + if (ret) {
> > + dev_err_probe(dsi->dev, ret, "could not find next
> > bridge\n");
> > + return ret;
> > + }
> > +
> > + if (!dsi->next_bridge) {
> > + dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev,
> > panel);
> > + if (IS_ERR(dsi->next_bridge)) {
> > + dev_err(dsi->dev, "failed to create panel
> > bridge\n");
> > + return PTR_ERR(dsi->next_bridge);
> > + }
> > + }
>
> Can we use the new function devm_drm_of_get_bridge instead of the entire code?
I've just tried this, and it works, so yes we can.
I'll update the branch and re-send it for Laurent to collect and
apply/squash whichever works best.
Thanks.
Kieran
>
> Jagan.
[PATCH] drm: rcar-du: Add DSI support to rcar_du_output_name
The DSI output names were not added when the DSI pipeline support was
introduced.
Add the correct labels for these outputs, and fix the sort order to
match 'enum rcar_du_output' while we are here.
Fixes: b291fdcf5114 ("drm: rcar-du: Add r8a779a0 device support")
Suggested-by: Biju Das
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 5612a9e7a905..5a8131ef81d5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -544,10 +544,12 @@ const char *rcar_du_output_name(enum rcar_du_output
output)
static const char * const names[] = {
[RCAR_DU_OUTPUT_DPAD0] = "DPAD0",
[RCAR_DU_OUTPUT_DPAD1] = "DPAD1",
- [RCAR_DU_OUTPUT_LVDS0] = "LVDS0",
- [RCAR_DU_OUTPUT_LVDS1] = "LVDS1",
+ [RCAR_DU_OUTPUT_DSI0] = "DSI0",
+ [RCAR_DU_OUTPUT_DSI1] = "DSI1",
[RCAR_DU_OUTPUT_HDMI0] = "HDMI0",
[RCAR_DU_OUTPUT_HDMI1] = "HDMI1",
+ [RCAR_DU_OUTPUT_LVDS0] = "LVDS0",
+ [RCAR_DU_OUTPUT_LVDS1] = "LVDS1",
[RCAR_DU_OUTPUT_TCON] = "TCON",
};
--
2.30.2
RE: [PATCH 4/4] drm: rcar-du: mipi-dsi: Support bridge probe ordering
Quoting Biju Das (2021-11-26 10:51:48)
> Hi Kieran,
>
> Thanks for the patch.
>
> > Subject: [PATCH 4/4] drm: rcar-du: mipi-dsi: Support bridge probe ordering
> >
> > The bridge probe ordering for DSI devices has been clarified and further
> > documented in
> >
> > To support connecting with the SN65DSI86 device after commit c3b75d4734cb
> > ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe"),
> > update to the new probe ordering to remove a perpetual -EPROBE_DEFER loop
> > between the two devices.
> >
> > Signed-off-by: Kieran Bingham
> > ---
> > drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 48 +
> > 1 file changed, 26 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > index 833f4480bdf3..f783bacee8da 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> > @@ -639,6 +639,8 @@ static int rcar_mipi_dsi_host_attach(struct
> > mipi_dsi_host *host,
> > struct mipi_dsi_device *device)
> > {
> > struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> > + struct drm_panel *panel;
> > + int ret;
> >
> > if (device->lanes > dsi->num_data_lanes)
> > return -EINVAL;
> > @@ -646,12 +648,36 @@ static int rcar_mipi_dsi_host_attach(struct
> > mipi_dsi_host *host,
> > dsi->lanes = device->lanes;
> > dsi->format = device->format;
> >
> > + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> > + >next_bridge);
> > + if (ret) {
> > + dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
> > + return ret;
>
> This can merged with previous line. return dev_err_probe(dsi->dev, ret,
> "could not find next bridge\n");
> > + }
> > +
> > + if (!dsi->next_bridge) {
> > + dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
> > + if (IS_ERR(dsi->next_bridge)) {
> > + dev_err(dsi->dev, "failed to create panel bridge\n");
> > + return PTR_ERR(dsi->next_bridge);
>
> Why not return dev_err_probe??
Yes, I think it probably should. This was just a code move, so I didn't
change it.
--
Kieran
>
> Cheers,
> Biju
>
> > + }
> > + }
> > +
> > + /* Initialize the DRM bridge. */
> > + dsi->bridge.funcs = _mipi_dsi_bridge_ops;
> > + dsi->bridge.of_node = dsi->dev->of_node;
> > + drm_bridge_add(>bridge);
> > +
> > return 0;
> > }
> >
> > static int rcar_mipi_dsi_host_detach(struct mipi_dsi_host *host,
> > struct mipi_dsi_device *device)
> > {
> > + struct rcar_mipi_dsi *dsi = host_to_rcar_mipi_dsi(host);
> > +
> > + drm_bridge_remove(>bridge);
> > +
> > return 0;
> > }
> >
> > @@ -766,21 +792,6 @@ static int rcar_mipi_dsi_probe(struct platform_device
> > *pdev)
> > return PTR_ERR(dsi->rstc);
> > }
> >
> > - ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> > - >next_bridge);
> > - if (ret) {
> > - dev_err_probe(dsi->dev, ret, "could not find next bridge\n");
> > - return ret;
> > - }
> > -
> > - if (!dsi->next_bridge) {
> > - dsi->next_bridge = devm_drm_panel_bridge_add(dsi->dev, panel);
> > - if (IS_ERR(dsi->next_bridge)) {
> > - dev_err(dsi->dev, "failed to create panel bridge\n");
> > - return PTR_ERR(dsi->next_bridge);
> > - }
> > - }
> > -
> > /* Initialize the DSI host. */
> > dsi->host.dev = dsi->dev;
> > dsi->host.ops = _mipi_dsi_host_ops; @@ -788,11 +799,6 @@ static
> > int rcar_mipi_dsi_probe(struct platform_device *pdev)
> > if (ret < 0)
> > return ret;
> >
> > - /* Initialize the DRM bridge. */
> > - dsi->bridge.funcs = _mipi_dsi_bridge_ops;
> > - dsi->bridge.of_node = dsi->dev->of_node;
> > - drm_bridge_add(>bridge);
> > -
> > return 0;
> > }
> >
> > @@ -800,8 +806,6 @@ static int rcar_mipi_dsi_remove(struct platform_device
> > *pdev) {
> > struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
> >
> > - drm_bridge_remove(>bridge);
> > -
> > mipi_dsi_host_unregister(>host);
> >
> > return 0;
> > --
> > 2.30.2
>
[PATCH 1/4] drm: rcar-du: Fix Makefile indentation for DSI
From: Kieran Bingham Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile index adc1b49d02cf..286bc81b3e7c 100644 --- a/drivers/gpu/drm/rcar-du/Makefile +++ b/drivers/gpu/drm/rcar-du/Makefile @@ -19,7 +19,7 @@ obj-$(CONFIG_DRM_RCAR_CMM)+= rcar_cmm.o obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o -obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o +obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o # 'remote-endpoint' is fixed up at run-time DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint -- 2.30.2
