[1/6] drm: bridge: samsung-dsim: Support multi-lane calculations

  If there is more than one lane, the HFP, HBP, and HSA is calculated in
bytes/pixel, then they are divided amongst the different lanes with some
additional overhead. This is necessary to achieve higher resolutions while
keeping the pixel clocks lower as the number of lanes increase.

Signed-off-by: Adam Ford <aford173@gmail.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 40 +++++++++++++++++++++++----
 1 file changed, 34 insertions(+), 6 deletions(-)
  

On 4/15/23 12:40, Adam Ford wrote:
> If there is more than one lane, the HFP, HBP, and HSA is calculated in
> bytes/pixel, then they are divided amongst the different lanes with some
> additional overhead. This is necessary to achieve higher resolutions while
> keeping the pixel clocks lower as the number of lanes increase.
> 
> Signed-off-by: Adam Ford <aford173@gmail.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 40 +++++++++++++++++++++++----
>   1 file changed, 34 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index e0a402a85787..1ccbad4ea577 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -215,6 +215,7 @@
>   #define DSI_RX_FIFO_SIZE		256
>   #define DSI_XFER_TIMEOUT_MS		100
>   #define DSI_RX_FIFO_EMPTY		0x30800002
> +#define DSI_HSYNC_PKT_OVERHEAD	6
>   
>   #define OLD_SCLK_MIPI_CLK_NAME		"pll_clk"
>   
> @@ -879,13 +880,40 @@ static void samsung_dsim_set_display_mode(struct samsung_dsim *dsi)
>   			| DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
>   		samsung_dsim_write(dsi, DSIM_MVPORCH_REG, reg);
>   
> -		reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> -			| DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> -		samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> +		/*
> +		 * If there is more than one lane, the HFP, HBP, and HSA
> +		 * is calculated in bytes/pixel, then they are divided
> +		 * amongst the different lanes with some additional
> +		 * overhead correction
> +		 */

Did you find any confirmation of this in the MX8M* datasheet or at least 
by measuring the DSI data lanes with a scope ?

It would be real cool if this could be confirmed somehow, and we could 
rule out that this tweaking of HSA/HSE/... stuff isn't related to either 
LP-HS transition timing calculation this driver is missing, OR, 
incorrect flags in various bridge/panel drivers like commit:

ca161b259cc84 ("drm/bridge: ti-sn65dsi83: Do not generate HFP/HBP/HSA 
and EOT packet")
  

Hi Adam,

Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> If there is more than one lane, the HFP, HBP, and HSA is calculated in
> bytes/pixel, then they are divided amongst the different lanes with some
> additional overhead. This is necessary to achieve higher resolutions while
> keeping the pixel clocks lower as the number of lanes increase.
> 

In the testing I did to come up with my patch "drm: bridge: samsung-
dsim: fix blanking packet size calculation" the number of lanes didn't
make any difference. My testing might be flawed, as I could only
measure the blanking after translation from MIPI DSI to DPI, so I'm
interested to know what others did here. How did you validate the
blanking with your patch? Would you have a chance to test my patch and
see if it works or breaks in your setup?

Regards,
Lucas

> Signed-off-by: Adam Ford <aford173@gmail.com>
> ---
>  drivers/gpu/drm/bridge/samsung-dsim.c | 40 +++++++++++++++++++++++----
>  1 file changed, 34 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index e0a402a85787..1ccbad4ea577 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -215,6 +215,7 @@
>  #define DSI_RX_FIFO_SIZE		256
>  #define DSI_XFER_TIMEOUT_MS		100
>  #define DSI_RX_FIFO_EMPTY		0x30800002
> +#define DSI_HSYNC_PKT_OVERHEAD	6
>  
>  #define OLD_SCLK_MIPI_CLK_NAME		"pll_clk"
>  
> @@ -879,13 +880,40 @@ static void samsung_dsim_set_display_mode(struct samsung_dsim *dsi)
>  			| DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
>  		samsung_dsim_write(dsi, DSIM_MVPORCH_REG, reg);
>  
> -		reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> -			| DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> -		samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> +		/*
> +		 * If there is more than one lane, the HFP, HBP, and HSA
> +		 * is calculated in bytes/pixel, then they are divided
> +		 * amongst the different lanes with some additional
> +		 * overhead correction
> +		 */
> +		if (dsi->lanes > 1) {
> +			u32 hfp, hbp, hsa;
> +			int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format) / 8;
> +
> +			hfp = ((m->hsync_start - m->hdisplay) * bpp) / dsi->lanes;
> +			hfp -= (hfp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> +
> +			hbp = ((m->htotal - m->hsync_end) * bpp) / dsi->lanes;
> +			hbp -= (hbp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
>  
> -		reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> -			| DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> -		samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> +			hsa = ((m->hsync_end - m->hsync_start) * bpp) / dsi->lanes;
> +			hsa -= (hsa > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> +
> +			reg = DSIM_MAIN_HFP(hfp) | DSIM_MAIN_HBP(hbp);
> +			samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> +
> +			reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> +				| DSIM_MAIN_HSA(hsa);
> +			samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> +		} else {
> +			reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> +				| DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> +			samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> +
> +			reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> +				| DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> +			samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> +		}
>  	}
>  	reg =  DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
>  		DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol);
  

On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Hi Adam,
>
> Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> > If there is more than one lane, the HFP, HBP, and HSA is calculated in
> > bytes/pixel, then they are divided amongst the different lanes with some
> > additional overhead. This is necessary to achieve higher resolutions while
> > keeping the pixel clocks lower as the number of lanes increase.
> >
>
> In the testing I did to come up with my patch "drm: bridge: samsung-
> dsim: fix blanking packet size calculation" the number of lanes didn't
> make any difference. My testing might be flawed, as I could only
> measure the blanking after translation from MIPI DSI to DPI, so I'm
> interested to know what others did here. How did you validate the
> blanking with your patch? Would you have a chance to test my patch and
> see if it works or breaks in your setup?

Mine was purely by trial and error.  I don't have a scope, nor do I
have a copy of the MIPI DSI spec, so if the image sync'd with my
monitor, I treated it as successful.

I can give yours a try, but it might be a few days since I've only
been working on this stuff a bit in my spare time.

adam

>
> Regards,
> Lucas
>
> > Signed-off-by: Adam Ford <aford173@gmail.com>
> > ---
> >  drivers/gpu/drm/bridge/samsung-dsim.c | 40 +++++++++++++++++++++++----
> >  1 file changed, 34 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index e0a402a85787..1ccbad4ea577 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -215,6 +215,7 @@
> >  #define DSI_RX_FIFO_SIZE             256
> >  #define DSI_XFER_TIMEOUT_MS          100
> >  #define DSI_RX_FIFO_EMPTY            0x30800002
> > +#define DSI_HSYNC_PKT_OVERHEAD       6
> >
> >  #define OLD_SCLK_MIPI_CLK_NAME               "pll_clk"
> >
> > @@ -879,13 +880,40 @@ static void samsung_dsim_set_display_mode(struct samsung_dsim *dsi)
> >                       | DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
> >               samsung_dsim_write(dsi, DSIM_MVPORCH_REG, reg);
> >
> > -             reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> > -                     | DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> > -             samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> > +             /*
> > +              * If there is more than one lane, the HFP, HBP, and HSA
> > +              * is calculated in bytes/pixel, then they are divided
> > +              * amongst the different lanes with some additional
> > +              * overhead correction
> > +              */
> > +             if (dsi->lanes > 1) {
> > +                     u32 hfp, hbp, hsa;
> > +                     int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format) / 8;
> > +
> > +                     hfp = ((m->hsync_start - m->hdisplay) * bpp) / dsi->lanes;
> > +                     hfp -= (hfp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> > +
> > +                     hbp = ((m->htotal - m->hsync_end) * bpp) / dsi->lanes;
> > +                     hbp -= (hbp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> >
> > -             reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> > -                     | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> > -             samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> > +                     hsa = ((m->hsync_end - m->hsync_start) * bpp) / dsi->lanes;
> > +                     hsa -= (hsa > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> > +
> > +                     reg = DSIM_MAIN_HFP(hfp) | DSIM_MAIN_HBP(hbp);
> > +                     samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> > +
> > +                     reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> > +                             | DSIM_MAIN_HSA(hsa);
> > +                     samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> > +             } else {
> > +                     reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> > +                             | DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> > +                     samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> > +
> > +                     reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> > +                             | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> > +                     samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> > +             }
> >       }
> >       reg =  DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
> >               DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol);
>
  

On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >
> > Hi Adam,
> >
> > Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> > > If there is more than one lane, the HFP, HBP, and HSA is calculated in
> > > bytes/pixel, then they are divided amongst the different lanes with some
> > > additional overhead. This is necessary to achieve higher resolutions while
> > > keeping the pixel clocks lower as the number of lanes increase.
> > >
> >
> > In the testing I did to come up with my patch "drm: bridge: samsung-
> > dsim: fix blanking packet size calculation" the number of lanes didn't
> > make any difference. My testing might be flawed, as I could only
> > measure the blanking after translation from MIPI DSI to DPI, so I'm
> > interested to know what others did here. How did you validate the
> > blanking with your patch? Would you have a chance to test my patch and
> > see if it works or breaks in your setup?

Lucas,

I tried your patch instead of mine.  Yours is dependent on the
hs_clock being always set to the burst clock which is configured by
the device tree.  I unrolled a bit of my stuff and replaced it with
yours.  It worked at 1080p, but when I tried a few other resolutions,
they did not work.  I assume it's because the DSI clock is fixed and
not changing based on the pixel clock.  In the version I did, I only
did that math when the lanes were > 1. In your patch, you divide by 8,
and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
that just in case the bpp ever changes from 8.  Overall,  I think our
patches basically do the same thing.

adam

>
> Mine was purely by trial and error.  I don't have a scope, nor do I
> have a copy of the MIPI DSI spec, so if the image sync'd with my
> monitor, I treated it as successful.
>
> I can give yours a try, but it might be a few days since I've only
> been working on this stuff a bit in my spare time.
>
> adam
>
> >
> > Regards,
> > Lucas
> >
> > > Signed-off-by: Adam Ford <aford173@gmail.com>
> > > ---
> > >  drivers/gpu/drm/bridge/samsung-dsim.c | 40 +++++++++++++++++++++++----
> > >  1 file changed, 34 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > index e0a402a85787..1ccbad4ea577 100644
> > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > @@ -215,6 +215,7 @@
> > >  #define DSI_RX_FIFO_SIZE             256
> > >  #define DSI_XFER_TIMEOUT_MS          100
> > >  #define DSI_RX_FIFO_EMPTY            0x30800002
> > > +#define DSI_HSYNC_PKT_OVERHEAD       6
> > >
> > >  #define OLD_SCLK_MIPI_CLK_NAME               "pll_clk"
> > >
> > > @@ -879,13 +880,40 @@ static void samsung_dsim_set_display_mode(struct samsung_dsim *dsi)
> > >                       | DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
> > >               samsung_dsim_write(dsi, DSIM_MVPORCH_REG, reg);
> > >
> > > -             reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> > > -                     | DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> > > -             samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> > > +             /*
> > > +              * If there is more than one lane, the HFP, HBP, and HSA
> > > +              * is calculated in bytes/pixel, then they are divided
> > > +              * amongst the different lanes with some additional
> > > +              * overhead correction
> > > +              */
> > > +             if (dsi->lanes > 1) {
> > > +                     u32 hfp, hbp, hsa;
> > > +                     int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format) / 8;
> > > +
> > > +                     hfp = ((m->hsync_start - m->hdisplay) * bpp) / dsi->lanes;
> > > +                     hfp -= (hfp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> > > +
> > > +                     hbp = ((m->htotal - m->hsync_end) * bpp) / dsi->lanes;
> > > +                     hbp -= (hbp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> > >
> > > -             reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> > > -                     | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> > > -             samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> > > +                     hsa = ((m->hsync_end - m->hsync_start) * bpp) / dsi->lanes;
> > > +                     hsa -= (hsa > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> > > +
> > > +                     reg = DSIM_MAIN_HFP(hfp) | DSIM_MAIN_HBP(hbp);
> > > +                     samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> > > +
> > > +                     reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> > > +                             | DSIM_MAIN_HSA(hsa);
> > > +                     samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> > > +             } else {
> > > +                     reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> > > +                             | DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> > > +                     samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> > > +
> > > +                     reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> > > +                             | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> > > +                     samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> > > +             }
> > >       }
> > >       reg =  DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
> > >               DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol);
> >
  

Hi Adam,

Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
> On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
> > 
> > On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > > 
> > > Hi Adam,
> > > 
> > > Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> > > > If there is more than one lane, the HFP, HBP, and HSA is calculated in
> > > > bytes/pixel, then they are divided amongst the different lanes with some
> > > > additional overhead. This is necessary to achieve higher resolutions while
> > > > keeping the pixel clocks lower as the number of lanes increase.
> > > > 
> > > 
> > > In the testing I did to come up with my patch "drm: bridge: samsung-
> > > dsim: fix blanking packet size calculation" the number of lanes didn't
> > > make any difference. My testing might be flawed, as I could only
> > > measure the blanking after translation from MIPI DSI to DPI, so I'm
> > > interested to know what others did here. How did you validate the
> > > blanking with your patch? Would you have a chance to test my patch and
> > > see if it works or breaks in your setup?
> 
> Lucas,
> 
> I tried your patch instead of mine.  Yours is dependent on the
> hs_clock being always set to the burst clock which is configured by
> the device tree.  I unrolled a bit of my stuff and replaced it with
> yours.  It worked at 1080p, but when I tried a few other resolutions,
> they did not work.  I assume it's because the DSI clock is fixed and
> not changing based on the pixel clock.  In the version I did, I only
> did that math when the lanes were > 1. In your patch, you divide by 8,
> and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
> that just in case the bpp ever changes from 8.  Overall,  I think our
> patches basically do the same thing.

The calculations in your and my patch are quite different. I'm not
taking into account the number of lanes or the MIPI format. I'm basing
the blanking size purely on the ratio between MIPI DSI byte clock and
the DPI interface clock. It's quite counter-intuitive that the host
would scale the blanking to the number of lanes automatically, but
still require the MIPI packet offset removed, but that's what my
measurements showed to produce the correct blanking after translation
to DPI by the TC358767 bridge chip.

If you dynamically scale the HS clock, then you would need to input the
real used HS clock to the calculation in my patch, instead of the fixed
burst mode rate.

Regards,
Lucas
  

On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Hi Adam,
>
> Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
> > On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> > > > > If there is more than one lane, the HFP, HBP, and HSA is calculated in
> > > > > bytes/pixel, then they are divided amongst the different lanes with some
> > > > > additional overhead. This is necessary to achieve higher resolutions while
> > > > > keeping the pixel clocks lower as the number of lanes increase.
> > > > >
> > > >
> > > > In the testing I did to come up with my patch "drm: bridge: samsung-
> > > > dsim: fix blanking packet size calculation" the number of lanes didn't
> > > > make any difference. My testing might be flawed, as I could only
> > > > measure the blanking after translation from MIPI DSI to DPI, so I'm
> > > > interested to know what others did here. How did you validate the
> > > > blanking with your patch? Would you have a chance to test my patch and
> > > > see if it works or breaks in your setup?
> >
> > Lucas,
> >
> > I tried your patch instead of mine.  Yours is dependent on the
> > hs_clock being always set to the burst clock which is configured by
> > the device tree.  I unrolled a bit of my stuff and replaced it with
> > yours.  It worked at 1080p, but when I tried a few other resolutions,
> > they did not work.  I assume it's because the DSI clock is fixed and
> > not changing based on the pixel clock.  In the version I did, I only
> > did that math when the lanes were > 1. In your patch, you divide by 8,
> > and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
> > that just in case the bpp ever changes from 8.  Overall,  I think our
> > patches basically do the same thing.
>
> The calculations in your and my patch are quite different. I'm not
> taking into account the number of lanes or the MIPI format. I'm basing

I was looking more at the division by 8 and the overhead correction of 6.
This number 6 also appears in the NXP downstream kernel [1].  I know
Marek V had some concerns about that.

> the blanking size purely on the ratio between MIPI DSI byte clock and
> the DPI interface clock. It's quite counter-intuitive that the host
> would scale the blanking to the number of lanes automatically, but
> still require the MIPI packet offset removed, but that's what my
> measurements showed to produce the correct blanking after translation
> to DPI by the TC358767 bridge chip.

How many lanes is your DSI interface using?

>
> If you dynamically scale the HS clock, then you would need to input the
> real used HS clock to the calculation in my patch, instead of the fixed
> burst mode rate.

I think what you're saying makes sense.

The code I originally modeled this from was from the NXP downstream
kernel where they define the calculation as being in words [2]. I am
not saying the NXP code is perfect, but the NXP code works.  With this
series, my monitors are able to sync a bunch of different resolutions
from 1080p down to 640x480 and a bunch in between with various refresh
rates too. That was the goal of this series.

Instead of just using your patch as-is, I will adapt yours to use the
scaled clock to see how it behaves and get back to you.  I have
finished reworking the dynamic DPHY settings, and I've fixed up making
the PLL device tree optional. If your patch works, I'll drop my
calculation and just build off what you have to use the scaled HS
clock when I submit the V2 and I'll make sure I CC you.

adam

[1] - https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/sec-dsim.c#L270
[2] - https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/sec-dsim.c#L914

>
> Regards,
> Lucas
  

Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
> On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > 
> > Hi Adam,
> > 
> > Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
> > > On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
> > > > 
> > > > On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > > > > 
> > > > > Hi Adam,
> > > > > 
> > > > > Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> > > > > > If there is more than one lane, the HFP, HBP, and HSA is calculated in
> > > > > > bytes/pixel, then they are divided amongst the different lanes with some
> > > > > > additional overhead. This is necessary to achieve higher resolutions while
> > > > > > keeping the pixel clocks lower as the number of lanes increase.
> > > > > > 
> > > > > 
> > > > > In the testing I did to come up with my patch "drm: bridge: samsung-
> > > > > dsim: fix blanking packet size calculation" the number of lanes didn't
> > > > > make any difference. My testing might be flawed, as I could only
> > > > > measure the blanking after translation from MIPI DSI to DPI, so I'm
> > > > > interested to know what others did here. How did you validate the
> > > > > blanking with your patch? Would you have a chance to test my patch and
> > > > > see if it works or breaks in your setup?
> > > 
> > > Lucas,
> > > 
> > > I tried your patch instead of mine.  Yours is dependent on the
> > > hs_clock being always set to the burst clock which is configured by
> > > the device tree.  I unrolled a bit of my stuff and replaced it with
> > > yours.  It worked at 1080p, but when I tried a few other resolutions,
> > > they did not work.  I assume it's because the DSI clock is fixed and
> > > not changing based on the pixel clock.  In the version I did, I only
> > > did that math when the lanes were > 1. In your patch, you divide by 8,
> > > and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
> > > that just in case the bpp ever changes from 8.  Overall,  I think our
> > > patches basically do the same thing.
> > 
> > The calculations in your and my patch are quite different. I'm not
> > taking into account the number of lanes or the MIPI format. I'm basing
> 
> I was looking more at the division by 8 and the overhead correction of 6.
> This number 6 also appears in the NXP downstream kernel [1].  I know
> Marek V had some concerns about that.
> 
Yea, I don't fully remember the details about the overhead. Need to
page that back in. The division by 8 in my patch is just to get from
the bit to a byte clock, nothing to do with the MIPI format bits per
channel or something like that.

> > the blanking size purely on the ratio between MIPI DSI byte clock and
> > the DPI interface clock. It's quite counter-intuitive that the host
> > would scale the blanking to the number of lanes automatically, but
> > still require the MIPI packet offset removed, but that's what my
> > measurements showed to produce the correct blanking after translation
> > to DPI by the TC358767 bridge chip.
> 
> How many lanes is your DSI interface using?
> 
When I did the measurements to come up with the patch, I varied the
number of lanes between 1 and 4. Different number of lanes didn't make
a difference. In fact trying to compensate for the number of lanes when
calculating the blanking size to program into the controller lead to
wildly wrong blanking on the DPI side of the external bridge.

> > 
> > If you dynamically scale the HS clock, then you would need to input the
> > real used HS clock to the calculation in my patch, instead of the fixed
> > burst mode rate.
> 
> I think what you're saying makes sense.
> 
> The code I originally modeled this from was from the NXP downstream
> kernel where they define the calculation as being in words [2]. I am
> not saying the NXP code is perfect, but the NXP code works.  With this
> series, my monitors are able to sync a bunch of different resolutions
> from 1080p down to 640x480 and a bunch in between with various refresh
> rates too. That was the goal of this series.
> 
> Instead of just using your patch as-is, I will adapt yours to use the
> scaled clock to see how it behaves and get back to you.
> 

Thanks, that would be very much appreciated.

I also don't assert that my calculation is perfect, as I also don't
have any more information and needed to resort to observing the
blanking after translation by the external bridge, so I hope we could
get some better understanding of how things really work by checking
what works for both our systems.

>   I have
> finished reworking the dynamic DPHY settings, and I've fixed up making
> the PLL device tree optional. If your patch works, I'll drop my
> calculation and just build off what you have to use the scaled HS
> clock when I submit the V2 and I'll make sure I CC you.
> 
Thanks, I'm open to re-do my measurements with your new patches.

Regards,
Lucas

> adam
> 
> [1] - https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/sec-dsim.c#L270
> [2] - https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/sec-dsim.c#L914
> 
> > 
> > Regards,
> > Lucas
  

On Thu, Apr 20, 2023 at 8:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
> > On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > >
> > > Hi Adam,
> > >
> > > Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
> > > > On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > > > > >
> > > > > > Hi Adam,
> > > > > >
> > > > > > Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> > > > > > > If there is more than one lane, the HFP, HBP, and HSA is calculated in
> > > > > > > bytes/pixel, then they are divided amongst the different lanes with some
> > > > > > > additional overhead. This is necessary to achieve higher resolutions while
> > > > > > > keeping the pixel clocks lower as the number of lanes increase.
> > > > > > >
> > > > > >
> > > > > > In the testing I did to come up with my patch "drm: bridge: samsung-
> > > > > > dsim: fix blanking packet size calculation" the number of lanes didn't
> > > > > > make any difference. My testing might be flawed, as I could only
> > > > > > measure the blanking after translation from MIPI DSI to DPI, so I'm
> > > > > > interested to know what others did here. How did you validate the
> > > > > > blanking with your patch? Would you have a chance to test my patch and
> > > > > > see if it works or breaks in your setup?
> > > >
> > > > Lucas,
> > > >
> > > > I tried your patch instead of mine.  Yours is dependent on the
> > > > hs_clock being always set to the burst clock which is configured by
> > > > the device tree.  I unrolled a bit of my stuff and replaced it with
> > > > yours.  It worked at 1080p, but when I tried a few other resolutions,
> > > > they did not work.  I assume it's because the DSI clock is fixed and
> > > > not changing based on the pixel clock.  In the version I did, I only
> > > > did that math when the lanes were > 1. In your patch, you divide by 8,
> > > > and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
> > > > that just in case the bpp ever changes from 8.  Overall,  I think our
> > > > patches basically do the same thing.
> > >
> > > The calculations in your and my patch are quite different. I'm not
> > > taking into account the number of lanes or the MIPI format. I'm basing

I was taking the number of lanes into account in order to calculate
the clock rate, since 4-lanes can run slower.

> >
> > I was looking more at the division by 8 and the overhead correction of 6.
> > This number 6 also appears in the NXP downstream kernel [1].  I know
> > Marek V had some concerns about that.
> >
> Yea, I don't fully remember the details about the overhead. Need to
> page that back in. The division by 8 in my patch is just to get from
> the bit to a byte clock, nothing to do with the MIPI format bits per
> channel or something like that.
>
> > > the blanking size purely on the ratio between MIPI DSI byte clock and
> > > the DPI interface clock. It's quite counter-intuitive that the host
> > > would scale the blanking to the number of lanes automatically, but
> > > still require the MIPI packet offset removed, but that's what my
> > > measurements showed to produce the correct blanking after translation
> > > to DPI by the TC358767 bridge chip.
> >
> > How many lanes is your DSI interface using?
> >
> When I did the measurements to come up with the patch, I varied the
> number of lanes between 1 and 4. Different number of lanes didn't make
> a difference. In fact trying to compensate for the number of lanes when
> calculating the blanking size to program into the controller lead to
> wildly wrong blanking on the DPI side of the external bridge.
>
> > >
> > > If you dynamically scale the HS clock, then you would need to input the
> > > real used HS clock to the calculation in my patch, instead of the fixed
> > > burst mode rate.
> >
> > I think what you're saying makes sense.
> >
> > The code I originally modeled this from was from the NXP downstream
> > kernel where they define the calculation as being in words [2]. I am
> > not saying the NXP code is perfect, but the NXP code works.  With this
> > series, my monitors are able to sync a bunch of different resolutions
> > from 1080p down to 640x480 and a bunch in between with various refresh
> > rates too. That was the goal of this series.
> >
> > Instead of just using your patch as-is, I will adapt yours to use the
> > scaled clock to see how it behaves and get back to you.
> >
>
> Thanks, that would be very much appreciated.

Lucas,

I took your patch and added a dsi state variable named "hs_clock"  to
keep track of the output of samsung_dsim_set_pll which should be the
active high-speed clock.

I then replaced one line in your code to reference the hs_clock
instead of the burst clock:

@@ -960,7 +962,7 @@ static void samsung_dsim_set_display_mode(struct
samsung_dsim *dsi)
        u32 reg;

        if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
-               int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
+               int byte_clk_khz = dsi->hs_clock / 1000 / 8;
                int hfp = (m->hsync_start - m->hdisplay) *
byte_clk_khz / m->clock;

With that change, your patch works with the rest of my code, and I
think it's easier to read, and it doesn't involve recalculating the
clock speed each time since it's cached.  If you're OK with that, I'll
incorporate your code into V2 of my series, and I'll apply my changes
as a subsequent patch.  I hope to be able to send out V2 this weekend.

I would be curious to know frm Marek Szyprowski what the impact is on
the Samsung devices, if any.

adam

>
> I also don't assert that my calculation is perfect, as I also don't
> have any more information and needed to resort to observing the
> blanking after translation by the external bridge, so I hope we could
> get some better understanding of how things really work by checking
> what works for both our systems.
>
> >   I have
> > finished reworking the dynamic DPHY settings, and I've fixed up making
> > the PLL device tree optional. If your patch works, I'll drop my
> > calculation and just build off what you have to use the scaled HS
> > clock when I submit the V2 and I'll make sure I CC you.
> >
> Thanks, I'm open to re-do my measurements with your new patches.
>
> Regards,
> Lucas
>
> > adam
> >
> > [1] - https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/sec-dsim.c#L270
> > [2] - https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/sec-dsim.c#L914
> >
> > >
> > > Regards,
> > > Lucas
>
  

Am Donnerstag, dem 20.04.2023 um 16:51 -0500 schrieb Adam Ford:
> On Thu, Apr 20, 2023 at 8:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > 
> > Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
> > > On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > > > 
> > > > Hi Adam,
> > > > 
> > > > Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
> > > > > On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
> > > > > > 
> > > > > > On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > > > > > > 
> > > > > > > Hi Adam,
> > > > > > > 
> > > > > > > Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> > > > > > > > If there is more than one lane, the HFP, HBP, and HSA is calculated in
> > > > > > > > bytes/pixel, then they are divided amongst the different lanes with some
> > > > > > > > additional overhead. This is necessary to achieve higher resolutions while
> > > > > > > > keeping the pixel clocks lower as the number of lanes increase.
> > > > > > > > 
> > > > > > > 
> > > > > > > In the testing I did to come up with my patch "drm: bridge: samsung-
> > > > > > > dsim: fix blanking packet size calculation" the number of lanes didn't
> > > > > > > make any difference. My testing might be flawed, as I could only
> > > > > > > measure the blanking after translation from MIPI DSI to DPI, so I'm
> > > > > > > interested to know what others did here. How did you validate the
> > > > > > > blanking with your patch? Would you have a chance to test my patch and
> > > > > > > see if it works or breaks in your setup?
> > > > > 
> > > > > Lucas,
> > > > > 
> > > > > I tried your patch instead of mine.  Yours is dependent on the
> > > > > hs_clock being always set to the burst clock which is configured by
> > > > > the device tree.  I unrolled a bit of my stuff and replaced it with
> > > > > yours.  It worked at 1080p, but when I tried a few other resolutions,
> > > > > they did not work.  I assume it's because the DSI clock is fixed and
> > > > > not changing based on the pixel clock.  In the version I did, I only
> > > > > did that math when the lanes were > 1. In your patch, you divide by 8,
> > > > > and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
> > > > > that just in case the bpp ever changes from 8.  Overall,  I think our
> > > > > patches basically do the same thing.
> > > > 
> > > > The calculations in your and my patch are quite different. I'm not
> > > > taking into account the number of lanes or the MIPI format. I'm basing
> 
> I was taking the number of lanes into account in order to calculate
> the clock rate, since 4-lanes can run slower.
> 
Ah that makes sense if you aren't running at full clock burst clock
rate.

> > > 
> > > I was looking more at the division by 8 and the overhead correction of 6.
> > > This number 6 also appears in the NXP downstream kernel [1].  I know
> > > Marek V had some concerns about that.
> > > 
> > Yea, I don't fully remember the details about the overhead. Need to
> > page that back in. The division by 8 in my patch is just to get from
> > the bit to a byte clock, nothing to do with the MIPI format bits per
> > channel or something like that.
> > 
> > > > the blanking size purely on the ratio between MIPI DSI byte clock and
> > > > the DPI interface clock. It's quite counter-intuitive that the host
> > > > would scale the blanking to the number of lanes automatically, but
> > > > still require the MIPI packet offset removed, but that's what my
> > > > measurements showed to produce the correct blanking after translation
> > > > to DPI by the TC358767 bridge chip.
> > > 
> > > How many lanes is your DSI interface using?
> > > 
> > When I did the measurements to come up with the patch, I varied the
> > number of lanes between 1 and 4. Different number of lanes didn't make
> > a difference. In fact trying to compensate for the number of lanes when
> > calculating the blanking size to program into the controller lead to
> > wildly wrong blanking on the DPI side of the external bridge.
> > 
> > > > 
> > > > If you dynamically scale the HS clock, then you would need to input the
> > > > real used HS clock to the calculation in my patch, instead of the fixed
> > > > burst mode rate.
> > > 
> > > I think what you're saying makes sense.
> > > 
> > > The code I originally modeled this from was from the NXP downstream
> > > kernel where they define the calculation as being in words [2]. I am
> > > not saying the NXP code is perfect, but the NXP code works.  With this
> > > series, my monitors are able to sync a bunch of different resolutions
> > > from 1080p down to 640x480 and a bunch in between with various refresh
> > > rates too. That was the goal of this series.
> > > 
> > > Instead of just using your patch as-is, I will adapt yours to use the
> > > scaled clock to see how it behaves and get back to you.
> > > 
> > 
> > Thanks, that would be very much appreciated.
> 
> Lucas,
> 
> I took your patch and added a dsi state variable named "hs_clock"  to
> keep track of the output of samsung_dsim_set_pll which should be the
> active high-speed clock.
> 
> I then replaced one line in your code to reference the hs_clock
> instead of the burst clock:
> 
> @@ -960,7 +962,7 @@ static void samsung_dsim_set_display_mode(struct
> samsung_dsim *dsi)
>         u32 reg;
> 
>         if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> -               int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
> +               int byte_clk_khz = dsi->hs_clock / 1000 / 8;
>                 int hfp = (m->hsync_start - m->hdisplay) *
> byte_clk_khz / m->clock;
> 
> With that change, your patch works with the rest of my code, and I
> think it's easier to read, and it doesn't involve recalculating the
> clock speed each time since it's cached.  If you're OK with that, I'll
> incorporate your code into V2 of my series, and I'll apply my changes
> as a subsequent patch.  I hope to be able to send out V2 this weekend.
> 
That's good to hear! Seems we are converging here. Feel free to pick up
the patch, that's also easier for me as I don't have to resend with CC
fixed.

> I would be curious to know frm Marek Szyprowski what the impact is on
> the Samsung devices, if any.
> 
Since I messed up the list CC you also couldn't see his reply to my
patch:

| Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
| 
| Works fine on the Exynos based boards I have in my test farm.

Regards,
Lucas

> adam
> 
> > 
> > I also don't assert that my calculation is perfect, as I also don't
> > have any more information and needed to resort to observing the
> > blanking after translation by the external bridge, so I hope we could
> > get some better understanding of how things really work by checking
> > what works for both our systems.
> > 
> > >   I have
> > > finished reworking the dynamic DPHY settings, and I've fixed up making
> > > the PLL device tree optional. If your patch works, I'll drop my
> > > calculation and just build off what you have to use the scaled HS
> > > clock when I submit the V2 and I'll make sure I CC you.
> > > 
> > Thanks, I'm open to re-do my measurements with your new patches.
> > 
> > Regards,
> > Lucas
> > 
> > > adam
> > > 
> > > [1] - https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/sec-dsim.c#L270
> > > [2] - https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/sec-dsim.c#L914
> > > 
> > > > 
> > > > Regards,
> > > > Lucas
> >
  

On 21.04.2023 10:40, Lucas Stach wrote:
> Am Donnerstag, dem 20.04.2023 um 16:51 -0500 schrieb Adam Ford:
>> On Thu, Apr 20, 2023 at 8:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>>> Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
>>>> On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>>>>> Hi Adam,
>>>>>
>>>>> Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
>>>>>> On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
>>>>>>> On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>>>>>>>> Hi Adam,
>>>>>>>>
>>>>>>>> Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
>>>>>>>>> If there is more than one lane, the HFP, HBP, and HSA is calculated in
>>>>>>>>> bytes/pixel, then they are divided amongst the different lanes with some
>>>>>>>>> additional overhead. This is necessary to achieve higher resolutions while
>>>>>>>>> keeping the pixel clocks lower as the number of lanes increase.
>>>>>>>>>
>>>>>>>> In the testing I did to come up with my patch "drm: bridge: samsung-
>>>>>>>> dsim: fix blanking packet size calculation" the number of lanes didn't
>>>>>>>> make any difference. My testing might be flawed, as I could only
>>>>>>>> measure the blanking after translation from MIPI DSI to DPI, so I'm
>>>>>>>> interested to know what others did here. How did you validate the
>>>>>>>> blanking with your patch? Would you have a chance to test my patch and
>>>>>>>> see if it works or breaks in your setup?
>>>>>> Lucas,
>>>>>>
>>>>>> I tried your patch instead of mine.  Yours is dependent on the
>>>>>> hs_clock being always set to the burst clock which is configured by
>>>>>> the device tree.  I unrolled a bit of my stuff and replaced it with
>>>>>> yours.  It worked at 1080p, but when I tried a few other resolutions,
>>>>>> they did not work.  I assume it's because the DSI clock is fixed and
>>>>>> not changing based on the pixel clock.  In the version I did, I only
>>>>>> did that math when the lanes were > 1. In your patch, you divide by 8,
>>>>>> and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
>>>>>> that just in case the bpp ever changes from 8.  Overall,  I think our
>>>>>> patches basically do the same thing.
>>>>> The calculations in your and my patch are quite different. I'm not
>>>>> taking into account the number of lanes or the MIPI format. I'm basing
>> I was taking the number of lanes into account in order to calculate
>> the clock rate, since 4-lanes can run slower.
>>
> Ah that makes sense if you aren't running at full clock burst clock
> rate.
>
>>>> I was looking more at the division by 8 and the overhead correction of 6.
>>>> This number 6 also appears in the NXP downstream kernel [1].  I know
>>>> Marek V had some concerns about that.
>>>>
>>> Yea, I don't fully remember the details about the overhead. Need to
>>> page that back in. The division by 8 in my patch is just to get from
>>> the bit to a byte clock, nothing to do with the MIPI format bits per
>>> channel or something like that.
>>>
>>>>> the blanking size purely on the ratio between MIPI DSI byte clock and
>>>>> the DPI interface clock. It's quite counter-intuitive that the host
>>>>> would scale the blanking to the number of lanes automatically, but
>>>>> still require the MIPI packet offset removed, but that's what my
>>>>> measurements showed to produce the correct blanking after translation
>>>>> to DPI by the TC358767 bridge chip.
>>>> How many lanes is your DSI interface using?
>>>>
>>> When I did the measurements to come up with the patch, I varied the
>>> number of lanes between 1 and 4. Different number of lanes didn't make
>>> a difference. In fact trying to compensate for the number of lanes when
>>> calculating the blanking size to program into the controller lead to
>>> wildly wrong blanking on the DPI side of the external bridge.
>>>
>>>>> If you dynamically scale the HS clock, then you would need to input the
>>>>> real used HS clock to the calculation in my patch, instead of the fixed
>>>>> burst mode rate.
>>>> I think what you're saying makes sense.
>>>>
>>>> The code I originally modeled this from was from the NXP downstream
>>>> kernel where they define the calculation as being in words [2]. I am
>>>> not saying the NXP code is perfect, but the NXP code works.  With this
>>>> series, my monitors are able to sync a bunch of different resolutions
>>>> from 1080p down to 640x480 and a bunch in between with various refresh
>>>> rates too. That was the goal of this series.
>>>>
>>>> Instead of just using your patch as-is, I will adapt yours to use the
>>>> scaled clock to see how it behaves and get back to you.
>>>>
>>> Thanks, that would be very much appreciated.
>> Lucas,
>>
>> I took your patch and added a dsi state variable named "hs_clock"  to
>> keep track of the output of samsung_dsim_set_pll which should be the
>> active high-speed clock.
>>
>> I then replaced one line in your code to reference the hs_clock
>> instead of the burst clock:
>>
>> @@ -960,7 +962,7 @@ static void samsung_dsim_set_display_mode(struct
>> samsung_dsim *dsi)
>>          u32 reg;
>>
>>          if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
>> -               int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
>> +               int byte_clk_khz = dsi->hs_clock / 1000 / 8;
>>                  int hfp = (m->hsync_start - m->hdisplay) *
>> byte_clk_khz / m->clock;
>>
>> With that change, your patch works with the rest of my code, and I
>> think it's easier to read, and it doesn't involve recalculating the
>> clock speed each time since it's cached.  If you're OK with that, I'll
>> incorporate your code into V2 of my series, and I'll apply my changes
>> as a subsequent patch.  I hope to be able to send out V2 this weekend.
>>
> That's good to hear! Seems we are converging here. Feel free to pick up
> the patch, that's also easier for me as I don't have to resend with CC
> fixed.
>
>> I would be curious to know frm Marek Szyprowski what the impact is on
>> the Samsung devices, if any.
>>
> Since I messed up the list CC you also couldn't see his reply to my
> patch:
>
> | Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> |
> | Works fine on the Exynos based boards I have in my test farm.

I didn't follow this discussion, I'm a bit busy with other stuff. I've 
just tested this series and patch #3 break Exynos based board. If you 
want me to test anything else (might be a work-in-progress code), just 
let me know by the separate mail.

Best regards
  

On Fri, Apr 21, 2023 at 6:28 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 21.04.2023 10:40, Lucas Stach wrote:
> > Am Donnerstag, dem 20.04.2023 um 16:51 -0500 schrieb Adam Ford:
> >> On Thu, Apr 20, 2023 at 8:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >>> Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
> >>>> On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >>>>> Hi Adam,
> >>>>>
> >>>>> Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
> >>>>>> On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
> >>>>>>> On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >>>>>>>> Hi Adam,
> >>>>>>>>
> >>>>>>>> Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> >>>>>>>>> If there is more than one lane, the HFP, HBP, and HSA is calculated in
> >>>>>>>>> bytes/pixel, then they are divided amongst the different lanes with some
> >>>>>>>>> additional overhead. This is necessary to achieve higher resolutions while
> >>>>>>>>> keeping the pixel clocks lower as the number of lanes increase.
> >>>>>>>>>
> >>>>>>>> In the testing I did to come up with my patch "drm: bridge: samsung-
> >>>>>>>> dsim: fix blanking packet size calculation" the number of lanes didn't
> >>>>>>>> make any difference. My testing might be flawed, as I could only
> >>>>>>>> measure the blanking after translation from MIPI DSI to DPI, so I'm
> >>>>>>>> interested to know what others did here. How did you validate the
> >>>>>>>> blanking with your patch? Would you have a chance to test my patch and
> >>>>>>>> see if it works or breaks in your setup?
> >>>>>> Lucas,
> >>>>>>
> >>>>>> I tried your patch instead of mine.  Yours is dependent on the
> >>>>>> hs_clock being always set to the burst clock which is configured by
> >>>>>> the device tree.  I unrolled a bit of my stuff and replaced it with
> >>>>>> yours.  It worked at 1080p, but when I tried a few other resolutions,
> >>>>>> they did not work.  I assume it's because the DSI clock is fixed and
> >>>>>> not changing based on the pixel clock.  In the version I did, I only
> >>>>>> did that math when the lanes were > 1. In your patch, you divide by 8,
> >>>>>> and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
> >>>>>> that just in case the bpp ever changes from 8.  Overall,  I think our
> >>>>>> patches basically do the same thing.
> >>>>> The calculations in your and my patch are quite different. I'm not
> >>>>> taking into account the number of lanes or the MIPI format. I'm basing
> >> I was taking the number of lanes into account in order to calculate
> >> the clock rate, since 4-lanes can run slower.
> >>
> > Ah that makes sense if you aren't running at full clock burst clock
> > rate.
> >
> >>>> I was looking more at the division by 8 and the overhead correction of 6.
> >>>> This number 6 also appears in the NXP downstream kernel [1].  I know
> >>>> Marek V had some concerns about that.
> >>>>
> >>> Yea, I don't fully remember the details about the overhead. Need to
> >>> page that back in. The division by 8 in my patch is just to get from
> >>> the bit to a byte clock, nothing to do with the MIPI format bits per
> >>> channel or something like that.
> >>>
> >>>>> the blanking size purely on the ratio between MIPI DSI byte clock and
> >>>>> the DPI interface clock. It's quite counter-intuitive that the host
> >>>>> would scale the blanking to the number of lanes automatically, but
> >>>>> still require the MIPI packet offset removed, but that's what my
> >>>>> measurements showed to produce the correct blanking after translation
> >>>>> to DPI by the TC358767 bridge chip.
> >>>> How many lanes is your DSI interface using?
> >>>>
> >>> When I did the measurements to come up with the patch, I varied the
> >>> number of lanes between 1 and 4. Different number of lanes didn't make
> >>> a difference. In fact trying to compensate for the number of lanes when
> >>> calculating the blanking size to program into the controller lead to
> >>> wildly wrong blanking on the DPI side of the external bridge.
> >>>
> >>>>> If you dynamically scale the HS clock, then you would need to input the
> >>>>> real used HS clock to the calculation in my patch, instead of the fixed
> >>>>> burst mode rate.
> >>>> I think what you're saying makes sense.
> >>>>
> >>>> The code I originally modeled this from was from the NXP downstream
> >>>> kernel where they define the calculation as being in words [2]. I am
> >>>> not saying the NXP code is perfect, but the NXP code works.  With this
> >>>> series, my monitors are able to sync a bunch of different resolutions
> >>>> from 1080p down to 640x480 and a bunch in between with various refresh
> >>>> rates too. That was the goal of this series.
> >>>>
> >>>> Instead of just using your patch as-is, I will adapt yours to use the
> >>>> scaled clock to see how it behaves and get back to you.
> >>>>
> >>> Thanks, that would be very much appreciated.
> >> Lucas,
> >>
> >> I took your patch and added a dsi state variable named "hs_clock"  to
> >> keep track of the output of samsung_dsim_set_pll which should be the
> >> active high-speed clock.
> >>
> >> I then replaced one line in your code to reference the hs_clock
> >> instead of the burst clock:
> >>
> >> @@ -960,7 +962,7 @@ static void samsung_dsim_set_display_mode(struct
> >> samsung_dsim *dsi)
> >>          u32 reg;
> >>
> >>          if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> >> -               int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
> >> +               int byte_clk_khz = dsi->hs_clock / 1000 / 8;
> >>                  int hfp = (m->hsync_start - m->hdisplay) *
> >> byte_clk_khz / m->clock;
> >>
> >> With that change, your patch works with the rest of my code, and I
> >> think it's easier to read, and it doesn't involve recalculating the
> >> clock speed each time since it's cached.  If you're OK with that, I'll
> >> incorporate your code into V2 of my series, and I'll apply my changes
> >> as a subsequent patch.  I hope to be able to send out V2 this weekend.
> >>
> > That's good to hear! Seems we are converging here. Feel free to pick up
> > the patch, that's also easier for me as I don't have to resend with CC
> > fixed.
> >
> >> I would be curious to know frm Marek Szyprowski what the impact is on
> >> the Samsung devices, if any.
> >>
> > Since I messed up the list CC you also couldn't see his reply to my
> > patch:
> >
> > | Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > |
> > | Works fine on the Exynos based boards I have in my test farm.
>
> I didn't follow this discussion, I'm a bit busy with other stuff. I've
> just tested this series and patch #3 break Exynos based board. If you
> want me to test anything else (might be a work-in-progress code), just
> let me know by the separate mail.

That's ok. I'm going to drop my patch in favor of Lucas' patch, since
you've already tested his, and it looks cleaner than mine.  Thanks for
your willingness to test.  That really helps us move forward without
breaking your stuff.

adam
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>