imx8mm lcdif->dsi->adv7535 no video, no errors

imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

Hey all,

I am trying to test Jagan's patch series [1] to add support for the
samsung dsim bridge which is used on the imx8mm to output DSI video.
The DSIM gets the video from the mxsfb, and in my case, the DSI is
sent to the adv7535 for connecting to HDMI.

I have been able to get the device tree setup and I don't get any
errors.  The Linux system appears to think the video is connected as
determined by modetest:

trying to open device 'mxsfb-drm'...done
Encoders:
id crtc type possible crtcs possible clones
34 33 none 0x00000001 0x00000001

Connectors:
id encoder status name size (mm) modes encoders
35 34 connected HDMI-A-1        620x340 29 34
  modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
  #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
flags: nhsync, nvsync; type: driver
  #1 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
flags: phsync, pvsync; type: driver
  #2 1920x1080 59.94 1920 2008 2052 2200 1080 1084 1089 1125 148352
flags: phsync, pvsync; type: driver
  #3 1920x1080 50.00 1920 2448 2492 2640 1080 1084 1089 1125 148500
flags: phsync, pvsync; type: driver
  #4 1680x1050 59.88 1680 1728 1760 1840 1050 1053 1059 1080 119000
flags: phsync, nvsync; type: driver
  #5 1280x1024 75.02 1280 1296 1440 1688 1024 1025 1028 1066 135000
flags: phsync, pvsync; type: driver
  #6 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000
flags: phsync, pvsync; type: driver
  #7 1440x900 59.90 1440 1488 1520 1600 900 903 909 926 88750 flags:
phsync, nvsync; type: driver
  #8 1280x960 60.00 1280 1376 1488 1800 960 961 964 1000 108000 flags:
phsync, pvsync; type: driver
  #9 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags:
phsync, pvsync; type: driver
  #10 1280x720 59.94 1280 1390 1430 1650 720 725 730 750 74176 flags:
phsync, pvsync; type: driver
  #11 1280x720 50.00 1280 1720 1760 1980 720 725 730 750 74250 flags:
phsync, pvsync; type: driver
  #12 1024x768 75.03 1024 1040 1136 1312 768 769 772 800 78750 flags:
phsync, pvsync; type: driver
  #13 1024x768 70.07 1024 1048 1184 1328 768 771 777 806 75000 flags:
nhsync, nvsync; type: driver
  #14 1024x768 60.00 1024 1048 1184 1344 768 771 777 806 65000 flags:
nhsync, nvsync; type: driver
  #15 832x624 74.55 832 864 928 1152 624 625 628 667 57284 flags:
nhsync, nvsync; type: driver
  #16 800x600 75.00 800 816 896 1056 600 601 604 625 49500 flags:
phsync, pvsync; type: driver
  #17 800x600 72.19 800 856 976 1040 600 637 643 666 50000 flags:
phsync, pvsync; type: driver
  #18 800x600 60.32 800 840 968 1056 600 601 605 628 40000 flags:
phsync, pvsync; type: driver
  #19 800x600 56.25 800 824 896 1024 600 601 603 625 36000 flags:
phsync, pvsync; type: driver
  #20 720x576 50.00 720 732 796 864 576 581 586 625 27000 flags:
nhsync, nvsync; type: driver
  #21 720x480 60.00 720 736 798 858 480 489 495 525 27027 flags:
nhsync, nvsync; type: driver
  #22 720x480 59.94 720 736 798 858 480 489 495 525 27000 flags:
nhsync, nvsync; type: driver
  #23 640x480 75.00 640 656 720 840 480 481 484 500 31500 flags:
nhsync, nvsync; type: driver
  #24 640x480 72.81 640 664 704 832 480 489 492 520 31500 flags:
nhsync, nvsync; type: driver
  #25 640x480 66.67 640 704 768 864 480 483 486 525 30240 flags:
nhsync, nvsync; type: driver
  #26 640x480 60.00 640 656 752 800 480 490 492 525 25200 flags:
nhsync, nvsync; type: driver
  #27 640x480 59.94 640 656 752 800 480 490 492 525 25175 flags:
nhsync, nvsync; type: driver
  #28 720x400 70.08 720 738 846 900 400 412 414 449 28320 flags:
nhsync, pvsync; type: driver
  props:
1 EDID:
flags: immutable blob
blobs:

value:
00ffffffffffff0005e37928b1000000
2b190103803e22782a08a5a2574fa228
0f5054bfef00d1c0b300950081808140
81c0010101014dd000a0f0703e803020
35006d552100001aa36600a0f0701f80
302035006d552100001a000000fc0055
3238373947360a2020202020000000fd
0017501e8c3c000a2020202020200114
020333f14c9004031f1301125d5e5f60
6123090707830100006d030c00100039
7820006001020367d85dc401788003e3
0f000c011d007251d01e206e2855006d
552100001e8c0ad08a20e02d10103e96
006d55210000184d6c80a070703e8030
203a006d552100001aa36600a0f0701f
80302035006d552100001a00000000ea
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
5 link-status:
flags: enum
enums: Good=0 Bad=1
value: 0
6 non-desktop:
flags: immutable range
values: 0 1
value: 0
4 TILE:
flags: immutable blob
blobs:

value:

CRTCs:
id fb pos size
33 37 (0,0) (1920x1080)
  #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
flags: nhsync, nvsync; type: driver
  props:
24 VRR_ENABLED:
flags: range
values: 0 1
value: 0

Planes:
id crtc fb CRTC x,y x,y gamma size possible crtcs
31 33 37 0,0 0,0 0        0x00000001
  formats: RG16 XR24
  props:
8 type:

flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 1
30 IN_FORMATS:
flags: immutable blob
blobs:

value:
01000000000000000200000018000000
01000000200000005247313658523234
03000000000000000000000000000000
0000000000000000
in_formats blob decoded:
RG16:  LINEAR
XR24:  LINEAR

Frame buffers:
id size pitch

Unfortunately, there is no video in my monitor, and my monitor states
there is no signal.

If I use NXP's downstream kernel, this same hardware configuration
works fine and I can see the video.

I have checked the clk_summary, and the working and non-working
conditions both have clock rates that are the same for DSI, LCDIF and
related items.  The power domains connected to the lcdif and the dsi
show they are active.

Since I go no errors, and  Linux looks like it's happy, I was hoping
someone from who better understands the interconnections between all
these bridge layers might be able to offer a suggestion of something
to investigate and/or try.

The kernel repo I am using is from Jagan located here:

[1] - https://github.com/openedev/kernel

I am not convinced it's a device tree issue since I get no errors when
the drivers enumerate, but I can provide my device tree updates if
that helps.

adam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Adam,

On 22-07-30, Adam Ford wrote:
> Hey all,
> 
> I am trying to test Jagan's patch series [1] to add support for the
> samsung dsim bridge which is used on the imx8mm to output DSI video.
> The DSIM gets the video from the mxsfb, and in my case, the DSI is
> sent to the adv7535 for connecting to HDMI.

So you're using the NXP recommended evalboard setup :)

> I have been able to get the device tree setup and I don't get any
> errors.  The Linux system appears to think the video is connected as
> determined by modetest:

...

> Unfortunately, there is no video in my monitor, and my monitor states
> there is no signal.

This is pretty much known, at least on our side. We also have a few more
patches on top of the series [1] for fixing the horizontal porches.  Our
current status is that we can get only one mode out of the ADV7535 which
is 1080P. Our assumption is that the ADV7535 needs some attentions
(fixes) but we can't verify that since the documentation is under NDA.

> If I use NXP's downstream kernel, this same hardware configuration
> works fine and I can see the video.

This is because of the NXP downstream kernel porch 'calculation' and
workarounds. The values they are using for calculation don't take any
mode values into account and instead they are using a table. We don't
know where those values come from.

> I have checked the clk_summary, and the working and non-working
> conditions both have clock rates that are the same for DSI, LCDIF and
> related items.  The power domains connected to the lcdif and the dsi
> show they are active.
> 
> Since I go no errors, and  Linux looks like it's happy, I was hoping
> someone from who better understands the interconnections between all
> these bridge layers might be able to offer a suggestion of something
> to investigate and/or try.
> 
> The kernel repo I am using is from Jagan located here:
> 
> [1] - https://github.com/openedev/kernel
> 
> I am not convinced it's a device tree issue since I get no errors when
> the drivers enumerate, but I can provide my device tree updates if
> that helps.

Please see above. Our debugging showed that there is a strange behaviour
of the ADV7535 but we don't have any documentation.

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Mon, Aug 1, 2022 at 1:20 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> Hi Adam,
>
> On 22-07-30, Adam Ford wrote:
> > Hey all,
> >
> > I am trying to test Jagan's patch series [1] to add support for the
> > samsung dsim bridge which is used on the imx8mm to output DSI video.
> > The DSIM gets the video from the mxsfb, and in my case, the DSI is
> > sent to the adv7535 for connecting to HDMI.
>
> So you're using the NXP recommended evalboard setup :)

Yes and no.  Our design also adds audio to theADV7535 in addition to
the video signal.
For the 8M Plus design, we're looking to see if there are any 4K
DSI->HDMI bridge chips available.

>
> > I have been able to get the device tree setup and I don't get any
> > errors.  The Linux system appears to think the video is connected as
> > determined by modetest:
>
> ...
>
> > Unfortunately, there is no video in my monitor, and my monitor states
> > there is no signal.
>
> This is pretty much known, at least on our side. We also have a few more
> patches on top of the series [1] for fixing the horizontal porches.  Our
> current status is that we can get only one mode out of the ADV7535 which
> is 1080P. Our assumption is that the ADV7535 needs some attentions
> (fixes) but we can't verify that since the documentation is under NDA.

I am glad I am not alone.   Thanks for the tip.  That gives me
something to investigate.
>
> > If I use NXP's downstream kernel, this same hardware configuration
> > works fine and I can see the video.
>
> This is because of the NXP downstream kernel porch 'calculation' and
> workarounds. The values they are using for calculation don't take any
> mode values into account and instead they are using a table. We don't
> know where those values come from.

I would think the VESA group would have something like these published.
>
> > I have checked the clk_summary, and the working and non-working
> > conditions both have clock rates that are the same for DSI, LCDIF and
> > related items.  The power domains connected to the lcdif and the dsi
> > show they are active.
> >
> > Since I go no errors, and  Linux looks like it's happy, I was hoping
> > someone from who better understands the interconnections between all
> > these bridge layers might be able to offer a suggestion of something
> > to investigate and/or try.
> >
> > The kernel repo I am using is from Jagan located here:
> >
> > [1] - https://github.com/openedev/kernel
> >
> > I am not convinced it's a device tree issue since I get no errors when
> > the drivers enumerate, but I can provide my device tree updates if
> > that helps.
>
> Please see above. Our debugging showed that there is a strange behaviour
> of the ADV7535 but we don't have any documentation.
Thanks for the comments.

I'll look to see what I have for documentation.  I know my company
signed a bunch of NDA stuff and we have an HDMI license.  I'll go
through NXP's patches to their kernel and compare with whatever
documentation I can find to see if I can make any improvements.

adam
>
> Regards,
>   Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Mon, Aug 1, 2022 at 5:54 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Mon, Aug 1, 2022 at 1:20 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > Hi Adam,
> >
> > On 22-07-30, Adam Ford wrote:
> > > Hey all,
> > >
> > > I am trying to test Jagan's patch series [1] to add support for the
> > > samsung dsim bridge which is used on the imx8mm to output DSI video.
> > > The DSIM gets the video from the mxsfb, and in my case, the DSI is
> > > sent to the adv7535 for connecting to HDMI.
> >
> > So you're using the NXP recommended evalboard setup :)
>
> Yes and no.  Our design also adds audio to theADV7535 in addition to
> the video signal.
> For the 8M Plus design, we're looking to see if there are any 4K
> DSI->HDMI bridge chips available.
>
> >
> > > I have been able to get the device tree setup and I don't get any
> > > errors.  The Linux system appears to think the video is connected as
> > > determined by modetest:
> >
> > ...
> >
> > > Unfortunately, there is no video in my monitor, and my monitor states
> > > there is no signal.
> >
> > This is pretty much known, at least on our side. We also have a few more
> > patches on top of the series [1] for fixing the horizontal porches.  Our
> > current status is that we can get only one mode out of the ADV7535 which
> > is 1080P. Our assumption is that the ADV7535 needs some attentions
> > (fixes) but we can't verify that since the documentation is under NDA.
>
> I am glad I am not alone.   Thanks for the tip.  That gives me
> something to investigate.
> >
> > > If I use NXP's downstream kernel, this same hardware configuration
> > > works fine and I can see the video.
> >
> > This is because of the NXP downstream kernel porch 'calculation' and
> > workarounds. The values they are using for calculation don't take any
> > mode values into account and instead they are using a table. We don't
> > know where those values come from.
>
> I would think the VESA group would have something like these published.
> >
> > > I have checked the clk_summary, and the working and non-working
> > > conditions both have clock rates that are the same for DSI, LCDIF and
> > > related items.  The power domains connected to the lcdif and the dsi
> > > show they are active.
> > >
> > > Since I go no errors, and  Linux looks like it's happy, I was hoping
> > > someone from who better understands the interconnections between all
> > > these bridge layers might be able to offer a suggestion of something
> > > to investigate and/or try.
> > >
> > > The kernel repo I am using is from Jagan located here:
> > >
> > > [1] - https://github.com/openedev/kernel
> > >
> > > I am not convinced it's a device tree issue since I get no errors when
> > > the drivers enumerate, but I can provide my device tree updates if
> > > that helps.
> >
> > Please see above. Our debugging showed that there is a strange behaviour
> > of the ADV7535 but we don't have any documentation.
> Thanks for the comments.
>
> I'll look to see what I have for documentation.  I know my company
> signed a bunch of NDA stuff and we have an HDMI license.  I'll go
> through NXP's patches to their kernel and compare with whatever
> documentation I can find to see if I can make any improvements.

I checked our datasheet vault and I found no programming guide for the
ADV7535.  :-(
I've put in a request to see if we can get one.

I found one for the adv7511 on Analog Device's web site:
https://www.analog.com/media/en/technical-documentation/user-guides/ADV7511_Programming_Guide.pdf

They have a table of values for the different resolutions.  I am
guessing they might be the same or similar for 7535.
I'm going to look into NXP's alterations to this driver when I have more time.

adam
>
> adam
> >
> > Regards,
> >   Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Fabio Estevam]

Hi Adam,

On Sat, Jul 30, 2022 at 12:16 PM Adam Ford <aford173@gmail.com> wrote:
>
> Hey all,
>
> I am trying to test Jagan's patch series [1] to add support for the
> samsung dsim bridge which is used on the imx8mm to output DSI video.
> The DSIM gets the video from the mxsfb, and in my case, the DSI is
> sent to the adv7535 for connecting to HDMI.

I had to add some extra patches on top of Jagan's imx8mm-dsi-v3 to get
HDMI output functional on a imx8mm-evk via ADV7535:

https://github.com/fabioestevam/kernel/commits/imx8mm-dsi-v3

Does it work on your board?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Mon, Aug 1, 2022 at 2:33 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Adam,
>
> On Sat, Jul 30, 2022 at 12:16 PM Adam Ford <aford173@gmail.com> wrote:
> >
> > Hey all,
> >
> > I am trying to test Jagan's patch series [1] to add support for the
> > samsung dsim bridge which is used on the imx8mm to output DSI video.
> > The DSIM gets the video from the mxsfb, and in my case, the DSI is
> > sent to the adv7535 for connecting to HDMI.
>
> I had to add some extra patches on top of Jagan's imx8mm-dsi-v3 to get
> HDMI output functional on a imx8mm-evk via ADV7535:
>
> https://github.com/fabioestevam/kernel/commits/imx8mm-dsi-v3
>
> Does it work on your board?

I'll give them a try tonight.  I managed to get a hold of an adv7535
user manual, and there are some items that it appears NXP did in their
downstream kernel that never got pushed upstream. Based on my review
of some of the changes, some of the NXP changes seem reasonable to me.
If/when I can get it working, I'll try to report back some of my
findings and push driver changes to the adv7535 as I find them.

adam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Fabio, Adam,

+Cc Marek, Robert, Laurentiu

On 22-08-01, Fabio Estevam wrote:
> Hi Adam,
> 
> On Sat, Jul 30, 2022 at 12:16 PM Adam Ford <aford173@gmail.com> wrote:
> >
> > Hey all,
> >
> > I am trying to test Jagan's patch series [1] to add support for the
> > samsung dsim bridge which is used on the imx8mm to output DSI video.
> > The DSIM gets the video from the mxsfb, and in my case, the DSI is
> > sent to the adv7535 for connecting to HDMI.
> 
> I had to add some extra patches on top of Jagan's imx8mm-dsi-v3 to get
> HDMI output functional on a imx8mm-evk via ADV7535:
> 
> https://github.com/fabioestevam/kernel/commits/imx8mm-dsi-v3

You have a few interesting patches from Marek and Robert I didn't
noticed yet :)

Question is, does your setup work for all modes after applying your
patches and without using the NXP-downstream porches settings? We also
have a few patches in our queue for the porch calculation which we wanna
send as soon as possible as we verified our assumptions.

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Mon, Aug 1, 2022 at 3:07 PM Adam Ford <aford173@gmail.com> wrote:
>
> On Mon, Aug 1, 2022 at 2:33 PM Fabio Estevam <festevam@gmail.com> wrote:
> >
> > Hi Adam,
> >
> > On Sat, Jul 30, 2022 at 12:16 PM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > Hey all,
> > >
> > > I am trying to test Jagan's patch series [1] to add support for the
> > > samsung dsim bridge which is used on the imx8mm to output DSI video.
> > > The DSIM gets the video from the mxsfb, and in my case, the DSI is
> > > sent to the adv7535 for connecting to HDMI.
> >
> > I had to add some extra patches on top of Jagan's imx8mm-dsi-v3 to get
> > HDMI output functional on a imx8mm-evk via ADV7535:
> >
> > https://github.com/fabioestevam/kernel/commits/imx8mm-dsi-v3
> >
> > Does it work on your board?

Fabio,

I tried your branch, but I still get no video on the output of HDMI.
I do get a response to the modetest.  I won't post the whole thing
here, but here is a snippet

CRTCs:
id fb pos size
33 37 (0,0) (1920x1080)
  #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
flags: nhsync, nvsync; type: driver
  props:
24 VRR_ENABLED:
flags: range
values: 0 1
value: 0

Planes:
id crtc fb CRTC x,y x,y gamma size possible crtcs
31 33 37 0,0 0,0 0        0x00000001
  formats: RG16 XR24
  props:
8 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 1
30 IN_FORMATS:
flags: immutable blob
blobs:

value:
01000000000000000200000018000000
01000000200000005247313658523234
03000000000000000000000000000000
0000000000000000
in_formats blob decoded:
RG16:  LINEAR
XR24:  LINEAR

Frame buffers:
id size pitch

When I compare this with NXP's downstream kernel that works with this
monitor, I get some different info:

CRTCs:
id fb pos size
33 41 (0,0) (1920x1080)
  #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
flags: nhsync, nvsync; type: driver
  props:
24 VRR_ENABLED:
flags: range
values: 0 1
value: 0

Planes:
id crtc fb CRTC x,y x,y gamma size possible crtcs
31 33 41 0,0 0,0 0        0x00000001
  formats: XR24 AR24 RG16 XB24 AB24 RX24 RA24 AR15 XR15 AB15 XB15 BG16
  props:
8 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 1
32 zpos:
flags: immutable range
values: 0 0
value: 0

Frame buffers:
id size pitch

Notably, the  formats for the downstream list significantly more
formats.  I don't know how that translates to working video, but it
was something to note.

>
> I'll give them a try tonight.  I managed to get a hold of an adv7535
> user manual, and there are some items that it appears NXP did in their
> downstream kernel that never got pushed upstream. Based on my review
> of some of the changes, some of the NXP changes seem reasonable to me.
> If/when I can get it working, I'll try to report back some of my
> findings and push driver changes to the adv7535 as I find them.
>
> adam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Fabio Estevam]

Hi Marco,

On Mon, Aug 1, 2022 at 7:55 PM Marco Felsch <m.felsch@pengutronix.de> wrote:

> Question is, does your setup work for all modes after applying your
> patches and without using the NXP-downstream porches settings? We also

Without Frieder's patch:
"drm/exynos: Fix horizontal timing settings in MHPORCH/MSYNC
registers", I get no HDMI output.

Regards,

Fabio Estevam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Mon, Aug 1, 2022 at 6:12 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Marco,
>
> On Mon, Aug 1, 2022 at 7:55 PM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> > Question is, does your setup work for all modes after applying your
> > patches and without using the NXP-downstream porches settings? We also
>
> Without Frieder's patch:
> "drm/exynos: Fix horizontal timing settings in MHPORCH/MSYNC
> registers", I get no HDMI output.
>

I managed to get my HDMI output working. I had the lanes set to 2
instead of 4.  Once I switched to 4-lanes, the monitor came up in
1080p.  I haven't yet been able to get other modes to work.

adam
> Regards,
>
> Fabio Estevam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Fabio Estevam]

On Mon, Aug 1, 2022 at 10:39 PM Adam Ford <aford173@gmail.com> wrote:

> I managed to get my HDMI output working. I had the lanes set to 2
> instead of 4.  Once I switched to 4-lanes, the monitor came up in
> 1080p.  I haven't yet been able to get other modes to work.

Ok, good. On another thread, you mentioned that you were also trying
to get LVDS to work via SN65DSI83.

Does LVDS work for you on this branch?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> On Mon, Aug 1, 2022 at 10:39 PM Adam Ford <aford173@gmail.com> wrote:
>
> > I managed to get my HDMI output working. I had the lanes set to 2
> > instead of 4.  Once I switched to 4-lanes, the monitor came up in
> > 1080p.  I haven't yet been able to get other modes to work.
>
> Ok, good. On another thread, you mentioned that you were also trying
> to get LVDS to work via SN65DSI83.
>
> Does LVDS work for you on this branch?

I haven't tried with Marek's latest suggestion.  In the other thread
he mentioned a burst mode and setting the DSI speeds to higher
frequencies, but the patch he had didn't look like it would apply
cleanly, so I will need to dig into that a bit further.  Since my
company doesn't really ship the LVDS displays with the kits, the HDMI
is the default video, so I've been focusing on it.

To answer Marco's question, I was able to revert "MLK-21958-13:
drm/bridge: adv7511: Limit supported clocks" and still get a display
at 1080p, but all the other resolutions I tried appear to come up
blank.  I didn't try every one.  With that revert, more options come
available, but 1440x900 and 800x600 were options I tried
unsuccessfullyl.

adam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Adam, Fabio,

On 22-08-01, Adam Ford wrote:
> On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam <festevam@gmail.com> wrote:
> >
> > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford <aford173@gmail.com> wrote:
> >
> > > I managed to get my HDMI output working. I had the lanes set to 2
> > > instead of 4.  Once I switched to 4-lanes, the monitor came up in
> > > 1080p.  I haven't yet been able to get other modes to work.
> >
> > Ok, good. On another thread, you mentioned that you were also trying
> > to get LVDS to work via SN65DSI83.
> >
> > Does LVDS work for you on this branch?
> 
> I haven't tried with Marek's latest suggestion.  In the other thread
> he mentioned a burst mode and setting the DSI speeds to higher
> frequencies, but the patch he had didn't look like it would apply
> cleanly, so I will need to dig into that a bit further. 

Can you provide me a link to this thread?

> Since my company doesn't really ship the LVDS displays with the kits,
> the HDMI is the default video, so I've been focusing on it.
> 
> To answer Marco's question, I was able to revert "MLK-21958-13:
> drm/bridge: adv7511: Limit supported clocks" and still get a display
> at 1080p, but all the other resolutions I tried appear to come up
> blank. 

Cool so now you have the same state as we are.

I think that the most important one is the blanking calc. Can you try to
revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check
if you can get a output still? Also something to try would be to disable
the internal timing generator by specifying
'adi,disable-timing-generator'. Also if you have an oscilloscope for
such frequencies you can check the hdmi clk-lane. I noticed that this is
sometimes wrong.

Regards,
  Marco

> I didn't try every one.  With that revert, more options come
> available, but 1440x900 and 800x600 were options I tried
> unsuccessfullyl.

> 
> adam
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> Hi Adam, Fabio,
>
> On 22-08-01, Adam Ford wrote:
> > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam <festevam@gmail.com> wrote:
> > >
> > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > > I managed to get my HDMI output working. I had the lanes set to 2
> > > > instead of 4.  Once I switched to 4-lanes, the monitor came up in
> > > > 1080p.  I haven't yet been able to get other modes to work.
> > >
> > > Ok, good. On another thread, you mentioned that you were also trying
> > > to get LVDS to work via SN65DSI83.
> > >
> > > Does LVDS work for you on this branch?
> >
> > I haven't tried with Marek's latest suggestion.  In the other thread
> > he mentioned a burst mode and setting the DSI speeds to higher
> > frequencies, but the patch he had didn't look like it would apply
> > cleanly, so I will need to dig into that a bit further.
>
> Can you provide me a link to this thread?

Sure,

https://www.spinics.net/lists/dri-devel/msg358301.html

>
> > Since my company doesn't really ship the LVDS displays with the kits,
> > the HDMI is the default video, so I've been focusing on it.
> >
> > To answer Marco's question, I was able to revert "MLK-21958-13:
> > drm/bridge: adv7511: Limit supported clocks" and still get a display
> > at 1080p, but all the other resolutions I tried appear to come up
> > blank.
>
> Cool so now you have the same state as we are.

I have a couple patches applied to mine which mimic some of the stuff
that NXP did.  Since I have access to a programmer manual, i was able
to confirm some of the 7535 specific stuff and the low-refresh rate
changes in their kernel appear appropriate and I also created a second
table of default settings for the 7535 and if the type is set
properly, i'll use the newer table instead of the older one. If anyone
wants any of these patches, I can certainly share them, but I am not
certain they make any difference.

There are a few other items in the programmer manual that I want to
attempt to implement once I have a chance to further review the
document.

>
> I think that the most important one is the blanking calc. Can you try to
> revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check
> if you can get a output still? Also something to try would be to disable
> the internal timing generator by specifying
> 'adi,disable-timing-generator'. Also if you have an oscilloscope for
> such frequencies you can check the hdmi clk-lane. I noticed that this is
> sometimes wrong.

I am doing this from my home office as a side project, so I don't have
a scope, but I can try to revert the other patch and try to disable
the internal timing generator when I get home tonight.  I'll report my
findings.

>
> Regards,
>   Marco
>
> > I didn't try every one.  With that revert, more options come
> > available, but 1440x900 and 800x600 were options I tried
> > unsuccessfullyl.
>
> >
> > adam
> >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Tue, Aug 2, 2022 at 7:13 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > Hi Adam, Fabio,
> >
> > On 22-08-01, Adam Ford wrote:
> > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam <festevam@gmail.com> wrote:
> > > >
> > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > > I managed to get my HDMI output working. I had the lanes set to 2
> > > > > instead of 4.  Once I switched to 4-lanes, the monitor came up in
> > > > > 1080p.  I haven't yet been able to get other modes to work.
> > > >
> > > > Ok, good. On another thread, you mentioned that you were also trying
> > > > to get LVDS to work via SN65DSI83.
> > > >
> > > > Does LVDS work for you on this branch?
> > >
> > > I haven't tried with Marek's latest suggestion.  In the other thread
> > > he mentioned a burst mode and setting the DSI speeds to higher
> > > frequencies, but the patch he had didn't look like it would apply
> > > cleanly, so I will need to dig into that a bit further.
> >
> > Can you provide me a link to this thread?
>
> Sure,
>
> https://www.spinics.net/lists/dri-devel/msg358301.html
>
> >
> > > Since my company doesn't really ship the LVDS displays with the kits,
> > > the HDMI is the default video, so I've been focusing on it.
> > >
> > > To answer Marco's question, I was able to revert "MLK-21958-13:
> > > drm/bridge: adv7511: Limit supported clocks" and still get a display
> > > at 1080p, but all the other resolutions I tried appear to come up
> > > blank.
> >
> > Cool so now you have the same state as we are.
>
> I have a couple patches applied to mine which mimic some of the stuff
> that NXP did.  Since I have access to a programmer manual, i was able
> to confirm some of the 7535 specific stuff and the low-refresh rate
> changes in their kernel appear appropriate and I also created a second
> table of default settings for the 7535 and if the type is set
> properly, i'll use the newer table instead of the older one. If anyone
> wants any of these patches, I can certainly share them, but I am not
> certain they make any difference.
>
> There are a few other items in the programmer manual that I want to
> attempt to implement once I have a chance to further review the
> document.
>
> >
> > I think that the most important one is the blanking calc. Can you try to
> > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check
> > if you can get a output still? Also something to try would be to disable
> > the internal timing generator by specifying
> > 'adi,disable-timing-generator'. Also if you have an oscilloscope for

I did some reading about the internal timing generator.  It appears
that it's required when video formats use fractional bytes, and it's
preconfigured to run at 720p by default, but registers 28h through 37h
configure it for other video modes.

Are you thinking the imx8mm DSI generator would do it better?

> > such frequencies you can check the hdmi clk-lane. I noticed that this is
> > sometimes wrong.
>
> I am doing this from my home office as a side project, so I don't have
> a scope, but I can try to revert the other patch and try to disable
> the internal timing generator when I get home tonight.  I'll report my
> findings.
>
> >
> > Regards,
> >   Marco
> >
> > > I didn't try every one.  With that revert, more options come
> > > available, but 1440x900 and 800x600 were options I tried
> > > unsuccessfullyl.
> >
> > >
> > > adam
> > >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Tue, Aug 2, 2022 at 8:51 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Aug 2, 2022 at 7:13 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> > >
> > > Hi Adam, Fabio,
> > >
> > > On 22-08-01, Adam Ford wrote:
> > > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam <festevam@gmail.com> wrote:
> > > > >
> > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > > I managed to get my HDMI output working. I had the lanes set to 2
> > > > > > instead of 4.  Once I switched to 4-lanes, the monitor came up in
> > > > > > 1080p.  I haven't yet been able to get other modes to work.
> > > > >
> > > > > Ok, good. On another thread, you mentioned that you were also trying
> > > > > to get LVDS to work via SN65DSI83.
> > > > >
> > > > > Does LVDS work for you on this branch?
> > > >
> > > > I haven't tried with Marek's latest suggestion.  In the other thread
> > > > he mentioned a burst mode and setting the DSI speeds to higher
> > > > frequencies, but the patch he had didn't look like it would apply
> > > > cleanly, so I will need to dig into that a bit further.
> > >
> > > Can you provide me a link to this thread?
> >
> > Sure,
> >
> > https://www.spinics.net/lists/dri-devel/msg358301.html
> >
> > >
> > > > Since my company doesn't really ship the LVDS displays with the kits,
> > > > the HDMI is the default video, so I've been focusing on it.
> > > >
> > > > To answer Marco's question, I was able to revert "MLK-21958-13:
> > > > drm/bridge: adv7511: Limit supported clocks" and still get a display
> > > > at 1080p, but all the other resolutions I tried appear to come up
> > > > blank.
> > >
> > > Cool so now you have the same state as we are.
> >
> > I have a couple patches applied to mine which mimic some of the stuff
> > that NXP did.  Since I have access to a programmer manual, i was able
> > to confirm some of the 7535 specific stuff and the low-refresh rate
> > changes in their kernel appear appropriate and I also created a second
> > table of default settings for the 7535 and if the type is set
> > properly, i'll use the newer table instead of the older one. If anyone
> > wants any of these patches, I can certainly share them, but I am not
> > certain they make any difference.
> >
> > There are a few other items in the programmer manual that I want to
> > attempt to implement once I have a chance to further review the
> > document.
> >
> > >
> > > I think that the most important one is the blanking calc. Can you try to
> > > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check
> > > if you can get a output still? Also something to try would be to disable
> > > the internal timing generator by specifying
> > > 'adi,disable-timing-generator'. Also if you have an oscilloscope for
>
> I did some reading about the internal timing generator.  It appears
> that it's required when video formats use fractional bytes, and it's
> preconfigured to run at 720p by default, but registers 28h through 37h
> configure it for other video modes.
I think there may still be some issues with the DSIM since some of the
clock frequencies are set in the device tree.

From what I can tell, the pixel rate is calculated based on the
burst-clock-frequency and that generates a byte clock.  For 891000000,
the byte clock is 111375000.

Modetest timings for 1080p show:

index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
  #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
flags: nhsync, nvsync; type: driver


When looking at modetest, there is a clock for 1080p which appears to be 148500.
111375000/148500 = 750.

The rest of the entries in my table do not divide evenly.  I don;t
know if that explains the lack of display, but it's something to note.
It seems to me that instead of fixing the
samsung,burst-clock-frequency to 891000000, we should make the desired
PLL related to the desired pixel clock so it divides evenly.

Looking at NXP's kernel, I also noticed that their esc_prescaler is
based on the byte clock divided by 20MHz.  With some small code
changes to get the PLL based on the desired pixel clock instead of
hard-coded,  I was able to set

samsung,burst-clock-frequency = <1500000000>;
samsung,esc-clock-frequency = <20000000>;

With these settings and the above mentioned code changes, 1080p still
appears, however when attempting other modes, the display still fails
to load.  I also noticed that the phy ref clock is set to 27MHz
instead of NXP's 12MHz.  I attempted to play with that setting, but I
couldn't get 1080p to work again, so I backed it out.

Maybe I am headed in the wrong direction, but I'm going to examine the
P/M/S calculation of the timing on NXP's kernel to see how the DSIM in
this code compares.

If someone who understands the interactions between these different
components has suggestions, I'm willing to run some experiments.

adam



>
> Are you thinking the imx8mm DSI generator would do it better?
>
> > > such frequencies you can check the hdmi clk-lane. I noticed that this is
> > > sometimes wrong.
> >
> > I am doing this from my home office as a side project, so I don't have
> > a scope, but I can try to revert the other patch and try to disable
> > the internal timing generator when I get home tonight.  I'll report my
> > findings.
> >
> > >
> > > Regards,
> > >   Marco
> > >
> > > > I didn't try every one.  With that revert, more options come
> > > > available, but 1440x900 and 800x600 were options I tried
> > > > unsuccessfullyl.
> > >
> > > >
> > > > adam
> > > >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Adam,

sorry for the delay.

On 22-08-02, Adam Ford wrote:

...

> > > I think that the most important one is the blanking calc. Can you try to
> > > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check
> > > if you can get a output still? Also something to try would be to disable
> > > the internal timing generator by specifying
> > > 'adi,disable-timing-generator'. Also if you have an oscilloscope for
> 
> I did some reading about the internal timing generator.  It appears
> that it's required when video formats use fractional bytes, and it's
> preconfigured to run at 720p by default, but registers 28h through 37h
> configure it for other video modes.

I thought this timing generator can detect the sync timing
automatically. Also I saw some mail discussions where this timing
generator can trigger missbehaviours. Since we send the sync packages
from the dsi-host to the ADV, I think it should be possible for the ADV
to reconstruct the sync signals without the need of the internal timing
generator.

> Are you thinking the imx8mm DSI generator would do it better?

You mean the porches we are sending?

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

On 22-08-02, Adam Ford wrote:

...

> > I did some reading about the internal timing generator.  It appears
> > that it's required when video formats use fractional bytes, and it's
> > preconfigured to run at 720p by default, but registers 28h through 37h
> > configure it for other video modes.
>
> I think there may still be some issues with the DSIM since some of the
> clock frequencies are set in the device tree.
> 
> From what I can tell, the pixel rate is calculated based on the

By pixel rate you mean the HDMI pixel rate from the ADV? If so then yes.
The ADV has an divider which is already configured by the driver but
meaningless since the driver is lacking of setting the "manual-divider"
bit within the same register.

> burst-clock-frequency and that generates a byte clock.  For 891000000,
> the byte clock is 111375000.

The burst-clock-frequency is the hs-clk and DDR. So the MIPI-DSI clock
is burst-clock-frequency/2 which is in your case: 891000000/2 =
445500000. This clock is than divided by 3 within the ADV and you get
your 148500000 pixel clock. This divide by 3 is detected automatically
by the ADV due to the missing bit (see above).

> Modetest timings for 1080p show:
> 
> index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
>   #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
> flags: nhsync, nvsync; type: driver
> 
> 
> When looking at modetest, there is a clock for 1080p which appears to be 148500.
> 111375000/148500 = 750.

Please see above.

> The rest of the entries in my table do not divide evenly.  I don;t
> know if that explains the lack of display, but it's something to note.
> It seems to me that instead of fixing the
> samsung,burst-clock-frequency to 891000000, we should make the desired
> PLL related to the desired pixel clock so it divides evenly.

Please see above.

> Looking at NXP's kernel, I also noticed that their esc_prescaler is
> based on the byte clock divided by 20MHz.  With some small code
> changes to get the PLL based on the desired pixel clock instead of
> hard-coded,  I was able to set
> 
> samsung,burst-clock-frequency = <1500000000>;

This is not correct since the burst-clock-freq. specifies the hs-clock
for the data lanes (see above).

> samsung,esc-clock-frequency = <20000000>;

This is correct, we also use a esc-clock of 20MHz.

> With these settings and the above mentioned code changes, 1080p still
> appears, however when attempting other modes, the display still fails
> to load.  I also noticed that the phy ref clock is set to 27MHz
> instead of NXP's 12MHz. 

That's interesting, I didn't noticed that NXP uses 12 MHz as refclock
but I don't think that this is the problem. Since we have other
converter chips using the bridge driver and they work fine. I still
think that the main problem is within the ADV driver.

> I attempted to play with that setting, but I couldn't get 1080p to
> work again, so I backed it out.
> 
> Maybe I am headed in the wrong direction, but I'm going to examine the
> P/M/S calculation of the timing on NXP's kernel to see how the DSIM in
> this code compares.

I think the pms values are fine.

> If someone who understands the interactions between these different
> components has suggestions, I'm willing to run some experiments.

Did managed to get access to the ADV7535 programming guide? This is the
black box here. Let me check if I can provide you a link with our repo
so you can test our current DSIM state if you want.

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> On 22-08-02, Adam Ford wrote:
>
> ...
>
> > > I did some reading about the internal timing generator.  It appears
> > > that it's required when video formats use fractional bytes, and it's
> > > preconfigured to run at 720p by default, but registers 28h through 37h
> > > configure it for other video modes.
> >
> > I think there may still be some issues with the DSIM since some of the
> > clock frequencies are set in the device tree.
> >
> > From what I can tell, the pixel rate is calculated based on the
>
> By pixel rate you mean the HDMI pixel rate from the ADV? If so then yes.
> The ADV has an divider which is already configured by the driver but
> meaningless since the driver is lacking of setting the "manual-divider"
> bit within the same register.

I was thinking about the pixel clock from the DSI to the ADV.  I did
see the manual-divider bit was missing.  I tried enabling that bit,
but it didn't appear to make much difference.
>
> > burst-clock-frequency and that generates a byte clock.  For 891000000,
> > the byte clock is 111375000.
>
> The burst-clock-frequency is the hs-clk and DDR. So the MIPI-DSI clock
> is burst-clock-frequency/2 which is in your case: 891000000/2 =
> 445500000. This clock is than divided by 3 within the ADV and you get
> your 148500000 pixel clock. This divide by 3 is detected automatically
> by the ADV due to the missing bit (see above).
>
> > Modetest timings for 1080p show:
> >
> > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
> >   #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
> > flags: nhsync, nvsync; type: driver
> >
> >
> > When looking at modetest, there is a clock for 1080p which appears to be 148500.
> > 111375000/148500 = 750.
>
> Please see above.
>
> > The rest of the entries in my table do not divide evenly.  I don;t
> > know if that explains the lack of display, but it's something to note.
> > It seems to me that instead of fixing the
> > samsung,burst-clock-frequency to 891000000, we should make the desired
> > PLL related to the desired pixel clock so it divides evenly.
>
> Please see above.
>
> > Looking at NXP's kernel, I also noticed that their esc_prescaler is
> > based on the byte clock divided by 20MHz.  With some small code
> > changes to get the PLL based on the desired pixel clock instead of
> > hard-coded,  I was able to set
> >
> > samsung,burst-clock-frequency = <1500000000>;
>
> This is not correct since the burst-clock-freq. specifies the hs-clock
> for the data lanes (see above).

But I don't think the clock should be fixed. I think it should vary as
the resolution changes.  From what I can tell, NXP's DSI code doesn't
hard code this value, but it does appear to cap it at 1.5G.  I did
soom looking into the NXP frequency calculation and it is capable of
adjusting resolutions to some extent and from what I can see the
891MHz clock is only set when 1080p.  At 720p, thier kernel shows the
output frequency at  445.5 MHz.  The way the DSIM is currently
configured, it's fixed at 891MHz, so I don't expect the output feeding
the adv7535 to be correct for the different resolutions.


>
> > samsung,esc-clock-frequency = <20000000>;
>
> This is correct, we also use a esc-clock of 20MHz.
>
> > With these settings and the above mentioned code changes, 1080p still
> > appears, however when attempting other modes, the display still fails
> > to load.  I also noticed that the phy ref clock is set to 27MHz
> > instead of NXP's 12MHz.
>
> That's interesting, I didn't noticed that NXP uses 12 MHz as refclock
> but I don't think that this is the problem. Since we have other
> converter chips using the bridge driver and they work fine. I still
> think that the main problem is within the ADV driver.

Do the other converter chips work fine at different resolutions?

>
> > I attempted to play with that setting, but I couldn't get 1080p to
> > work again, so I backed it out.
> >
> > Maybe I am headed in the wrong direction, but I'm going to examine the
> > P/M/S calculation of the timing on NXP's kernel to see how the DSIM in
> > this code compares.
>
> I think the pms values are fine.

I compared the P/M/S values between this driver and NXP's and they
calculate different values of PMS when running at 1080P.
NXP @ 1080p:
fout = 891000, fin = 12000, m = 297, p = 2, s = 1, best_delta = 0

This kernel @ 1080p:

PLL freq 891000000, (p 3, m 99, s 0)

at 720P, the NXP Kernel
fout = 445500, fin = 12000, m = 297, p = 2, s = 2, best_delta = 0
(working)

at 720P, this kernel:
PLL freq 891000000, (p 3, m 99, s 0)
hs_clk = 891000000, byte_clk = 111375000, esc_clk = 18562500
(not working)


>
> > If someone who understands the interactions between these different
> > components has suggestions, I'm willing to run some experiments.
>
> Did managed to get access to the ADV7535 programming guide? This is the
> black box here. Let me check if I can provide you a link with our repo
> so you can test our current DSIM state if you want.

I do have access to the programming guide, but it's under NDA, but
I'll try to answer questions if I can.

adam
>
> Regards,
>   Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Dave Stevenson]

Hi Adam

On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:
>
> On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > On 22-08-02, Adam Ford wrote:
> >
> > ...
> >
> > > > I did some reading about the internal timing generator.  It appears
> > > > that it's required when video formats use fractional bytes, and it's
> > > > preconfigured to run at 720p by default, but registers 28h through 37h
> > > > configure it for other video modes.
> > >
> > > I think there may still be some issues with the DSIM since some of the
> > > clock frequencies are set in the device tree.
> > >
> > > From what I can tell, the pixel rate is calculated based on the
> >
> > By pixel rate you mean the HDMI pixel rate from the ADV? If so then yes.
> > The ADV has an divider which is already configured by the driver but
> > meaningless since the driver is lacking of setting the "manual-divider"
> > bit within the same register.
>
> I was thinking about the pixel clock from the DSI to the ADV.  I did
> see the manual-divider bit was missing.  I tried enabling that bit,
> but it didn't appear to make much difference.
> >
> > > burst-clock-frequency and that generates a byte clock.  For 891000000,
> > > the byte clock is 111375000.
> >
> > The burst-clock-frequency is the hs-clk and DDR. So the MIPI-DSI clock
> > is burst-clock-frequency/2 which is in your case: 891000000/2 =
> > 445500000. This clock is than divided by 3 within the ADV and you get
> > your 148500000 pixel clock. This divide by 3 is detected automatically
> > by the ADV due to the missing bit (see above).
> >
> > > Modetest timings for 1080p show:
> > >
> > > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
> > >   #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
> > > flags: nhsync, nvsync; type: driver
> > >
> > >
> > > When looking at modetest, there is a clock for 1080p which appears to be 148500.
> > > 111375000/148500 = 750.
> >
> > Please see above.
> >
> > > The rest of the entries in my table do not divide evenly.  I don;t
> > > know if that explains the lack of display, but it's something to note.
> > > It seems to me that instead of fixing the
> > > samsung,burst-clock-frequency to 891000000, we should make the desired
> > > PLL related to the desired pixel clock so it divides evenly.
> >
> > Please see above.
> >
> > > Looking at NXP's kernel, I also noticed that their esc_prescaler is
> > > based on the byte clock divided by 20MHz.  With some small code
> > > changes to get the PLL based on the desired pixel clock instead of
> > > hard-coded,  I was able to set
> > >
> > > samsung,burst-clock-frequency = <1500000000>;
> >
> > This is not correct since the burst-clock-freq. specifies the hs-clock
> > for the data lanes (see above).
>
> But I don't think the clock should be fixed. I think it should vary as
> the resolution changes.  From what I can tell, NXP's DSI code doesn't
> hard code this value, but it does appear to cap it at 1.5G.  I did
> soom looking into the NXP frequency calculation and it is capable of
> adjusting resolutions to some extent and from what I can see the
> 891MHz clock is only set when 1080p.  At 720p, thier kernel shows the
> output frequency at  445.5 MHz.  The way the DSIM is currently
> configured, it's fixed at 891MHz, so I don't expect the output feeding
> the adv7535 to be correct for the different resolutions.
>
>
> >
> > > samsung,esc-clock-frequency = <20000000>;
> >
> > This is correct, we also use a esc-clock of 20MHz.
> >
> > > With these settings and the above mentioned code changes, 1080p still
> > > appears, however when attempting other modes, the display still fails
> > > to load.  I also noticed that the phy ref clock is set to 27MHz
> > > instead of NXP's 12MHz.
> >
> > That's interesting, I didn't noticed that NXP uses 12 MHz as refclock
> > but I don't think that this is the problem. Since we have other
> > converter chips using the bridge driver and they work fine. I still
> > think that the main problem is within the ADV driver.
>
> Do the other converter chips work fine at different resolutions?
>
> >
> > > I attempted to play with that setting, but I couldn't get 1080p to
> > > work again, so I backed it out.
> > >
> > > Maybe I am headed in the wrong direction, but I'm going to examine the
> > > P/M/S calculation of the timing on NXP's kernel to see how the DSIM in
> > > this code compares.
> >
> > I think the pms values are fine.
>
> I compared the P/M/S values between this driver and NXP's and they
> calculate different values of PMS when running at 1080P.
> NXP @ 1080p:
> fout = 891000, fin = 12000, m = 297, p = 2, s = 1, best_delta = 0
>
> This kernel @ 1080p:
>
> PLL freq 891000000, (p 3, m 99, s 0)
>
> at 720P, the NXP Kernel
> fout = 445500, fin = 12000, m = 297, p = 2, s = 2, best_delta = 0
> (working)
>
> at 720P, this kernel:
> PLL freq 891000000, (p 3, m 99, s 0)
> hs_clk = 891000000, byte_clk = 111375000, esc_clk = 18562500
> (not working)
>
>
> >
> > > If someone who understands the interactions between these different
> > > components has suggestions, I'm willing to run some experiments.
> >
> > Did managed to get access to the ADV7535 programming guide? This is the
> > black box here. Let me check if I can provide you a link with our repo
> > so you can test our current DSIM state if you want.
>
> I do have access to the programming guide, but it's under NDA, but
> I'll try to answer questions if I can.

Not meaning to butt in, but I have datasheets for ADV7533 and 7535
from previously looking at these chips.
Mine fairly plainly states:
"The DSI receiver input supports DSI video mode operation only, and
specifically, only supports nonburst mode with sync pulses".
Non-burst mode meaning that the DSI pixel rate MUST be the same as the
HDMI pixel rate.
Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
even more explicit about the requirement of DSI timing matching

The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
be correct for 720p operation.

If you do program the manual DSI divider register to allow a DSI pixel
rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
the ADV753x having at least a half-line FIFO between DSI rx and HDMI
tx to compensate for the differing data rates. I see no reference to
such, and I'd be surprised if it was more than a half dozen pixels to
compensate for the jitter in the cases where the internal timing
generator is mandatory due to fractional bytes.

  Dave

> adam
> >
> > Regards,
> >   Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Wed, Aug 3, 2022 at 7:17 AM Dave Stevenson
<dave.stevenson@raspberrypi.com> wrote:
>
> Hi Adam
>
> On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:
> >
> > On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> > >
> > > On 22-08-02, Adam Ford wrote:
> > >
> > > ...
> > >
> > > > > I did some reading about the internal timing generator.  It appears
> > > > > that it's required when video formats use fractional bytes, and it's
> > > > > preconfigured to run at 720p by default, but registers 28h through 37h
> > > > > configure it for other video modes.
> > > >
> > > > I think there may still be some issues with the DSIM since some of the
> > > > clock frequencies are set in the device tree.
> > > >
> > > > From what I can tell, the pixel rate is calculated based on the
> > >
> > > By pixel rate you mean the HDMI pixel rate from the ADV? If so then yes.
> > > The ADV has an divider which is already configured by the driver but
> > > meaningless since the driver is lacking of setting the "manual-divider"
> > > bit within the same register.
> >
> > I was thinking about the pixel clock from the DSI to the ADV.  I did
> > see the manual-divider bit was missing.  I tried enabling that bit,
> > but it didn't appear to make much difference.
> > >
> > > > burst-clock-frequency and that generates a byte clock.  For 891000000,
> > > > the byte clock is 111375000.
> > >
> > > The burst-clock-frequency is the hs-clk and DDR. So the MIPI-DSI clock
> > > is burst-clock-frequency/2 which is in your case: 891000000/2 =
> > > 445500000. This clock is than divided by 3 within the ADV and you get
> > > your 148500000 pixel clock. This divide by 3 is detected automatically
> > > by the ADV due to the missing bit (see above).
> > >
> > > > Modetest timings for 1080p show:
> > > >
> > > > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
> > > >   #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
> > > > flags: nhsync, nvsync; type: driver
> > > >
> > > >
> > > > When looking at modetest, there is a clock for 1080p which appears to be 148500.
> > > > 111375000/148500 = 750.
> > >
> > > Please see above.
> > >
> > > > The rest of the entries in my table do not divide evenly.  I don;t
> > > > know if that explains the lack of display, but it's something to note.
> > > > It seems to me that instead of fixing the
> > > > samsung,burst-clock-frequency to 891000000, we should make the desired
> > > > PLL related to the desired pixel clock so it divides evenly.
> > >
> > > Please see above.
> > >
> > > > Looking at NXP's kernel, I also noticed that their esc_prescaler is
> > > > based on the byte clock divided by 20MHz.  With some small code
> > > > changes to get the PLL based on the desired pixel clock instead of
> > > > hard-coded,  I was able to set
> > > >
> > > > samsung,burst-clock-frequency = <1500000000>;
> > >
> > > This is not correct since the burst-clock-freq. specifies the hs-clock
> > > for the data lanes (see above).
> >
> > But I don't think the clock should be fixed. I think it should vary as
> > the resolution changes.  From what I can tell, NXP's DSI code doesn't
> > hard code this value, but it does appear to cap it at 1.5G.  I did
> > soom looking into the NXP frequency calculation and it is capable of
> > adjusting resolutions to some extent and from what I can see the
> > 891MHz clock is only set when 1080p.  At 720p, thier kernel shows the
> > output frequency at  445.5 MHz.  The way the DSIM is currently
> > configured, it's fixed at 891MHz, so I don't expect the output feeding
> > the adv7535 to be correct for the different resolutions.
> >
> >
> > >
> > > > samsung,esc-clock-frequency = <20000000>;
> > >
> > > This is correct, we also use a esc-clock of 20MHz.
> > >
> > > > With these settings and the above mentioned code changes, 1080p still
> > > > appears, however when attempting other modes, the display still fails
> > > > to load.  I also noticed that the phy ref clock is set to 27MHz
> > > > instead of NXP's 12MHz.
> > >
> > > That's interesting, I didn't noticed that NXP uses 12 MHz as refclock
> > > but I don't think that this is the problem. Since we have other
> > > converter chips using the bridge driver and they work fine. I still
> > > think that the main problem is within the ADV driver.
> >
> > Do the other converter chips work fine at different resolutions?
> >
> > >
> > > > I attempted to play with that setting, but I couldn't get 1080p to
> > > > work again, so I backed it out.
> > > >
> > > > Maybe I am headed in the wrong direction, but I'm going to examine the
> > > > P/M/S calculation of the timing on NXP's kernel to see how the DSIM in
> > > > this code compares.
> > >
> > > I think the pms values are fine.
> >
> > I compared the P/M/S values between this driver and NXP's and they
> > calculate different values of PMS when running at 1080P.
> > NXP @ 1080p:
> > fout = 891000, fin = 12000, m = 297, p = 2, s = 1, best_delta = 0
> >
> > This kernel @ 1080p:
> >
> > PLL freq 891000000, (p 3, m 99, s 0)
> >
> > at 720P, the NXP Kernel
> > fout = 445500, fin = 12000, m = 297, p = 2, s = 2, best_delta = 0
> > (working)
> >
> > at 720P, this kernel:
> > PLL freq 891000000, (p 3, m 99, s 0)
> > hs_clk = 891000000, byte_clk = 111375000, esc_clk = 18562500
> > (not working)
> >
> >
> > >
> > > > If someone who understands the interactions between these different
> > > > components has suggestions, I'm willing to run some experiments.
> > >
> > > Did managed to get access to the ADV7535 programming guide? This is the
> > > black box here. Let me check if I can provide you a link with our repo
> > > so you can test our current DSIM state if you want.
> >
> > I do have access to the programming guide, but it's under NDA, but
> > I'll try to answer questions if I can.
>
> Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> from previously looking at these chips.

Thanks for the feedback.

> Mine fairly plainly states:
> "The DSI receiver input supports DSI video mode operation only, and
> specifically, only supports nonburst mode with sync pulses".
> Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> HDMI pixel rate.

Mine also states the DSI source needs to provide correct video timing
with start and stop sync packets.

If I remember correctly, it seemed like Marek V wanted the hard coded
samsung,burst-clock-frequency to go away so the clock frequency could
be set dynamically.  I have attempted to do some of this work based on
what I am seeing in the NXP kernel, and I get get my monitor to sync
at some resolutions, but the screen is usually all green or all blue,
so it's not really a success.  The clock part appears to be good
enough to make the monitor see some sort of signal, so I am going to
investigate the calculation of the rest of the video timings to see if
I can fix the color issue.

> Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> even more explicit about the requirement of DSI timing matching
>
> The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> be correct for 720p operation.
>
> If you do program the manual DSI divider register to allow a DSI pixel
> rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> tx to compensate for the differing data rates. I see no reference to
> such, and I'd be surprised if it was more than a half dozen pixels to
> compensate for the jitter in the cases where the internal timing
> generator is mandatory due to fractional bytes.

Thanks Dave!

adam

>
>   Dave
>
> > adam
> > >
> > > Regards,
> > >   Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Dave Stevenson]

On Wed, 3 Aug 2022 at 13:31, Adam Ford <aford173@gmail.com> wrote:
>
> On Wed, Aug 3, 2022 at 7:17 AM Dave Stevenson
> <dave.stevenson@raspberrypi.com> wrote:
> >
> > Hi Adam
> >
> > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> > > >
> > > > On 22-08-02, Adam Ford wrote:
> > > >
> > > > ...
> > > >
> > > > > > I did some reading about the internal timing generator.  It appears
> > > > > > that it's required when video formats use fractional bytes, and it's
> > > > > > preconfigured to run at 720p by default, but registers 28h through 37h
> > > > > > configure it for other video modes.
> > > > >
> > > > > I think there may still be some issues with the DSIM since some of the
> > > > > clock frequencies are set in the device tree.
> > > > >
> > > > > From what I can tell, the pixel rate is calculated based on the
> > > >
> > > > By pixel rate you mean the HDMI pixel rate from the ADV? If so then yes.
> > > > The ADV has an divider which is already configured by the driver but
> > > > meaningless since the driver is lacking of setting the "manual-divider"
> > > > bit within the same register.
> > >
> > > I was thinking about the pixel clock from the DSI to the ADV.  I did
> > > see the manual-divider bit was missing.  I tried enabling that bit,
> > > but it didn't appear to make much difference.
> > > >
> > > > > burst-clock-frequency and that generates a byte clock.  For 891000000,
> > > > > the byte clock is 111375000.
> > > >
> > > > The burst-clock-frequency is the hs-clk and DDR. So the MIPI-DSI clock
> > > > is burst-clock-frequency/2 which is in your case: 891000000/2 =
> > > > 445500000. This clock is than divided by 3 within the ADV and you get
> > > > your 148500000 pixel clock. This divide by 3 is detected automatically
> > > > by the ADV due to the missing bit (see above).
> > > >
> > > > > Modetest timings for 1080p show:
> > > > >
> > > > > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
> > > > >   #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500
> > > > > flags: nhsync, nvsync; type: driver
> > > > >
> > > > >
> > > > > When looking at modetest, there is a clock for 1080p which appears to be 148500.
> > > > > 111375000/148500 = 750.
> > > >
> > > > Please see above.
> > > >
> > > > > The rest of the entries in my table do not divide evenly.  I don;t
> > > > > know if that explains the lack of display, but it's something to note.
> > > > > It seems to me that instead of fixing the
> > > > > samsung,burst-clock-frequency to 891000000, we should make the desired
> > > > > PLL related to the desired pixel clock so it divides evenly.
> > > >
> > > > Please see above.
> > > >
> > > > > Looking at NXP's kernel, I also noticed that their esc_prescaler is
> > > > > based on the byte clock divided by 20MHz.  With some small code
> > > > > changes to get the PLL based on the desired pixel clock instead of
> > > > > hard-coded,  I was able to set
> > > > >
> > > > > samsung,burst-clock-frequency = <1500000000>;
> > > >
> > > > This is not correct since the burst-clock-freq. specifies the hs-clock
> > > > for the data lanes (see above).
> > >
> > > But I don't think the clock should be fixed. I think it should vary as
> > > the resolution changes.  From what I can tell, NXP's DSI code doesn't
> > > hard code this value, but it does appear to cap it at 1.5G.  I did
> > > soom looking into the NXP frequency calculation and it is capable of
> > > adjusting resolutions to some extent and from what I can see the
> > > 891MHz clock is only set when 1080p.  At 720p, thier kernel shows the
> > > output frequency at  445.5 MHz.  The way the DSIM is currently
> > > configured, it's fixed at 891MHz, so I don't expect the output feeding
> > > the adv7535 to be correct for the different resolutions.
> > >
> > >
> > > >
> > > > > samsung,esc-clock-frequency = <20000000>;
> > > >
> > > > This is correct, we also use a esc-clock of 20MHz.
> > > >
> > > > > With these settings and the above mentioned code changes, 1080p still
> > > > > appears, however when attempting other modes, the display still fails
> > > > > to load.  I also noticed that the phy ref clock is set to 27MHz
> > > > > instead of NXP's 12MHz.
> > > >
> > > > That's interesting, I didn't noticed that NXP uses 12 MHz as refclock
> > > > but I don't think that this is the problem. Since we have other
> > > > converter chips using the bridge driver and they work fine. I still
> > > > think that the main problem is within the ADV driver.
> > >
> > > Do the other converter chips work fine at different resolutions?
> > >
> > > >
> > > > > I attempted to play with that setting, but I couldn't get 1080p to
> > > > > work again, so I backed it out.
> > > > >
> > > > > Maybe I am headed in the wrong direction, but I'm going to examine the
> > > > > P/M/S calculation of the timing on NXP's kernel to see how the DSIM in
> > > > > this code compares.
> > > >
> > > > I think the pms values are fine.
> > >
> > > I compared the P/M/S values between this driver and NXP's and they
> > > calculate different values of PMS when running at 1080P.
> > > NXP @ 1080p:
> > > fout = 891000, fin = 12000, m = 297, p = 2, s = 1, best_delta = 0
> > >
> > > This kernel @ 1080p:
> > >
> > > PLL freq 891000000, (p 3, m 99, s 0)
> > >
> > > at 720P, the NXP Kernel
> > > fout = 445500, fin = 12000, m = 297, p = 2, s = 2, best_delta = 0
> > > (working)
> > >
> > > at 720P, this kernel:
> > > PLL freq 891000000, (p 3, m 99, s 0)
> > > hs_clk = 891000000, byte_clk = 111375000, esc_clk = 18562500
> > > (not working)
> > >
> > >
> > > >
> > > > > If someone who understands the interactions between these different
> > > > > components has suggestions, I'm willing to run some experiments.
> > > >
> > > > Did managed to get access to the ADV7535 programming guide? This is the
> > > > black box here. Let me check if I can provide you a link with our repo
> > > > so you can test our current DSIM state if you want.
> > >
> > > I do have access to the programming guide, but it's under NDA, but
> > > I'll try to answer questions if I can.
> >
> > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > from previously looking at these chips.
>
> Thanks for the feedback.
>
> > Mine fairly plainly states:
> > "The DSI receiver input supports DSI video mode operation only, and
> > specifically, only supports nonburst mode with sync pulses".
> > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > HDMI pixel rate.
>
> Mine also states the DSI source needs to provide correct video timing
> with start and stop sync packets.
>
> If I remember correctly, it seemed like Marek V wanted the hard coded
> samsung,burst-clock-frequency to go away so the clock frequency could
> be set dynamically.

I've never worked with Exynos or imx8, but my view would be that
samsung,burst-clock-frequency should only be used if
MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for
adv7533/5).
Without that flag the DSI link frequency should be running at the rate
defined by the mode clock, number of lanes, bpp, etc.

From the DSI spec (v 1.1 section 8.11.1):
"Non-Burst Mode with Sync Pulses – enables the peripheral to
accurately reconstruct original video timing, including sync pulse
widths."
"RGB pixel packets are time-compressed, leaving more time during a
scan line for LP mode (saving power) or for multiplexing other
transmissions onto the DSI link."
How can the peripheral reconstruct the video timing off a quirky link frequency?

Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1]
reconfigures the clock setup of the DSI block, then I don't see how
the Exynos driver can follow the DSI spec in that regard.

Hope that helps.

  Dave

[1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L803

> I have attempted to do some of this work based on
> what I am seeing in the NXP kernel, and I get get my monitor to sync
> at some resolutions, but the screen is usually all green or all blue,
> so it's not really a success.  The clock part appears to be good
> enough to make the monitor see some sort of signal, so I am going to
> investigate the calculation of the rest of the video timings to see if
> I can fix the color issue.
>
> > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > even more explicit about the requirement of DSI timing matching
> >
> > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > be correct for 720p operation.
> >
> > If you do program the manual DSI divider register to allow a DSI pixel
> > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > tx to compensate for the differing data rates. I see no reference to
> > such, and I'd be surprised if it was more than a half dozen pixels to
> > compensate for the jitter in the cases where the internal timing
> > generator is mandatory due to fractional bytes.
>
> Thanks Dave!
>
> adam
>
> >
> >   Dave
> >
> > > adam
> > > >
> > > > Regards,
> > > >   Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

On 22-08-03, Adam Ford wrote:
> On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > On 22-08-02, Adam Ford wrote:
> >
> > ...
> >
> > > > I did some reading about the internal timing generator.  It appears
> > > > that it's required when video formats use fractional bytes, and it's
> > > > preconfigured to run at 720p by default, but registers 28h through 37h
> > > > configure it for other video modes.
> > >
> > > I think there may still be some issues with the DSIM since some of the
> > > clock frequencies are set in the device tree.
> > >
> > > From what I can tell, the pixel rate is calculated based on the
> >
> > By pixel rate you mean the HDMI pixel rate from the ADV? If so then yes.
> > The ADV has an divider which is already configured by the driver but
> > meaningless since the driver is lacking of setting the "manual-divider"
> > bit within the same register.
> 
> I was thinking about the pixel clock from the DSI to the ADV.  I did
> see the manual-divider bit was missing.  I tried enabling that bit,
> but it didn't appear to make much difference.

This depends, e.g. I saw that the HDMI pixel clock is correct if I had
set this bit, set the divider manually to 6 and configured the dsi-host
burst clock to 891MHz:
  -> 891MHz / 2 = 445.5 (DSI-Clock) -> 445.5 / 6 = 74.25 (HDMI pixel
  clock for 720P)

Of course this doesn't happen automatically yet :( I also find it a bit
of too reduce the lane line, I had removed this logic too. But as I
said, I got no frames shown on my HDMI monitor.

...

> > > samsung,burst-clock-frequency = <1500000000>;
> >
> > This is not correct since the burst-clock-freq. specifies the hs-clock
> > for the data lanes (see above).
> 
> But I don't think the clock should be fixed. I think it should vary as
> the resolution changes. 

You're right and this is something we have on our TODO list as well. But
this needs a bit more work within the DRM framework. So the client and
the host can negotiate the frequency.

Remember our main problem: with a correct burst-clock-frequency set and
lane number set for 720P, the ADV don't display anything.

> From what I can tell, NXP's DSI code doesn't
> hard code this value, but it does appear to cap it at 1.5G.  I did
> soom looking into the NXP frequency calculation

Can you provide me a link? There are a lot frequencies involved in this
discussion ^^ Just that I look at the same location.

> and it is capable of adjusting resolutions to some extent and from
> what I can see the 891MHz clock is only set when 1080p.  At 720p,
> thier kernel shows the output frequency at  445.5 MHz. 

Yes, we need the dynamic handling but hardcoding it isn't the way we
should go either. We have the dynamic PLL calculation, so we can
configure it to all possible values not just a few VESA standards.

> The way the DSIM is currently configured, it's fixed at 891MHz, so I
> don't expect the output feeding the adv7535 to be correct for the
> different resolutions.

Why not? The ADV can work with that hs-clock and for 720P@60 we need a
bandwidth of roughly (only pixels no package header/footer overhead):

  1280x720x24x60 = 1327104000 Bit/s = 1327.104 MBit/s

With 891MHz and 2 lanes we have

  891MBps * 2 = 1782000000 Bit/s = 1782 MBit/s

So this should be fine. With 445.5 MHz and 2 lanes we have not enough
bandwidth and with 445.5 MHz and 4 lanes we have exactly the same
bandwidth.

Therefore I still think that there is problem within the ADV.

...

> > > With these settings and the above mentioned code changes, 1080p still
> > > appears, however when attempting other modes, the display still fails
> > > to load.  I also noticed that the phy ref clock is set to 27MHz
> > > instead of NXP's 12MHz.
> >
> > That's interesting, I didn't noticed that NXP uses 12 MHz as refclock
> > but I don't think that this is the problem. Since we have other
> > converter chips using the bridge driver and they work fine. I still
> > think that the main problem is within the ADV driver.
> 
> Do the other converter chips work fine at different resolutions?

Yes.

> 
> >
> > > I attempted to play with that setting, but I couldn't get 1080p to
> > > work again, so I backed it out.
> > >
> > > Maybe I am headed in the wrong direction, but I'm going to examine the
> > > P/M/S calculation of the timing on NXP's kernel to see how the DSIM in
> > > this code compares.
> >
> > I think the pms values are fine.
> 
> I compared the P/M/S values between this driver and NXP's and they
> calculate different values of PMS when running at 1080P.

NXP don't calculate anything if I remember correctly, they just provide
PLL values so they reach the frequency. On the other hand with the
patches from Jagan we can configure the PLL to what-ever value :)

> NXP @ 1080p:
> fout = 891000, fin = 12000, m = 297, p = 2, s = 1, best_delta = 0
> 
> This kernel @ 1080p:
> 
> PLL freq 891000000, (p 3, m 99, s 0)

As you said, we use a differnet fin value 27MHz instead of the 12MHz so
those values must be different.

> at 720P, the NXP Kernel
> fout = 445500, fin = 12000, m = 297, p = 2, s = 2, best_delta = 0
> (working)
> 
> at 720P, this kernel:
> PLL freq 891000000, (p 3, m 99, s 0)
> hs_clk = 891000000, byte_clk = 111375000, esc_clk = 18562500
> (not working)

Yes, as I said you need to configure the PLL manually (see above).

> > > If someone who understands the interactions between these different
> > > components has suggestions, I'm willing to run some experiments.
> >
> > Did managed to get access to the ADV7535 programming guide? This is the
> > black box here. Let me check if I can provide you a link with our repo
> > so you can test our current DSIM state if you want.
> 
> I do have access to the programming guide, but it's under NDA, but
> I'll try to answer questions if I can.

Thanks a lot for your work :)

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Dave, Adam,

On 22-08-03, Dave Stevenson wrote:
> Hi Adam
> 
> On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:

...

> > > Did managed to get access to the ADV7535 programming guide? This is the
> > > black box here. Let me check if I can provide you a link with our repo
> > > so you can test our current DSIM state if you want.
> >
> > I do have access to the programming guide, but it's under NDA, but
> > I'll try to answer questions if I can.
> 
> Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> from previously looking at these chips.

Thanks for stepping into :)

> Mine fairly plainly states:
> "The DSI receiver input supports DSI video mode operation only, and
> specifically, only supports nonburst mode with sync pulses".

I've read this also, and we are working in nonburst mode with sync
pulses. I have no access to an MIPI-DSI analyzer therefore I can't
verify it.

> Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> HDMI pixel rate.

On DSI side you don't have a pixel-clock instead there is bit-clock.

> Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> even more explicit about the requirement of DSI timing matching

Is it possible to share the key points of the requirements?

> The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> be correct for 720p operation.

It should be absolute no difference if you work on 891MHz with 2 lanes
or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
GBps.

> If you do program the manual DSI divider register to allow a DSI pixel
> rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on

There is no such DSI pixel rate to be precise, we only have a DSI bit
clock/rate.

> the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> tx to compensate for the differing data rates. I see no reference to
> such, and I'd be surprised if it was more than a half dozen pixels to
> compensate for the jitter in the cases where the internal timing
> generator is mandatory due to fractional bytes.

This is interesting and would proofs our assumption that the device
don't have a FIFO :)

Our assumptions (we don't have the datasheet/programming manual):
  - HDMI part is fetching 3 bytes per HDMI pixclk
  - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
    HDMI are in sync. So from bandwidth pov there are no differences
    between:
      - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
      - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 )
      - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75)

    But the ratio is different and therefore the faster clocking option
    let something 'overflow'.

Anyway, but all this means that Adam should configure the
burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work
either and now we are back on my initial statement -> the driver needs
some attention.

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

On 22-08-03, Adam Ford wrote:
> On Wed, Aug 3, 2022 at 7:17 AM Dave Stevenson

...

> > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > from previously looking at these chips.
> 
> Thanks for the feedback.
> 
> > Mine fairly plainly states:
> > "The DSI receiver input supports DSI video mode operation only, and
> > specifically, only supports nonburst mode with sync pulses".
> > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > HDMI pixel rate.
> 
> Mine also states the DSI source needs to provide correct video timing
> with start and stop sync packets.
> 
> If I remember correctly, it seemed like Marek V wanted the hard coded
> samsung,burst-clock-frequency to go away so the clock frequency could
> be set dynamically.

As previously said, this is something on our TODO list too :) but needs
a bit more infrastructure work.

> I have attempted to do some of this work based on what I am seeing in
> the NXP kernel, and I get get my monitor to sync at some resolutions,
> but the screen is usually all green or all blue, so it's not really a
> success. The clock part appears to be good enough to make the monitor
> see some sort of signal, so I am going to investigate the calculation
> of the rest of the video timings to see if I can fix the color issue.

Please don't pay to much attention to the NXP kernel. No one have a glue
where those porches came from. If I specify the burst-clock-freq. to
445.5 and set the lane number to 4 and hack in the porches values from
NXP, than I get a 720P output too. But this isn't the way to go instead
we should calc the porches settings and the burst-clock-frequency
dynamiclly to provide more than just a few resolutions. But for that we
need a clear understanding of how the ADV is working.

I will prepare a repo to day and will send you a link with the hack
patches in it, so you can test it :)

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

On 22-08-03, Dave Stevenson wrote:
> On Wed, 3 Aug 2022 at 13:31, Adam Ford <aford173@gmail.com> wrote:

...

> > Mine also states the DSI source needs to provide correct video timing
> > with start and stop sync packets.
> >
> > If I remember correctly, it seemed like Marek V wanted the hard coded
> > samsung,burst-clock-frequency to go away so the clock frequency could
> > be set dynamically.
> 
> I've never worked with Exynos or imx8, but my view would be that
> samsung,burst-clock-frequency should only be used if
> MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for
> adv7533/5).

Some notes on that. The samsung,burst-clock-frequency is the
hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to
do with the MIPI_DSI_MODE_VIDEO_BURST.

> Without that flag the DSI link frequency should be running at the rate
> defined by the mode clock, number of lanes, bpp, etc.

IMHO the DSI link have only to guarantee the bandwidth is sufficient for
the mode.

> From the DSI spec (v 1.1 section 8.11.1):
> "Non-Burst Mode with Sync Pulses – enables the peripheral to
> accurately reconstruct original video timing, including sync pulse
> widths."
> "RGB pixel packets are time-compressed, leaving more time during a
> scan line for LP mode (saving power) or for multiplexing other
> transmissions onto the DSI link."
> How can the peripheral reconstruct the video timing off a quirky link frequency?

If the ADV couldn't reconstruct the sync signals, then we should not get
any mode working but we get the 1080P mode working.

> Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1]
> reconfigures the clock setup of the DSI block, then I don't see how
> the Exynos driver can follow the DSI spec in that regard.

Why do you think that the Exynos driver isn't following the spec? We
configure the host into video mode with sync signals which is working
for the 1080P mode.

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Dave Stevenson]

Hi Marco

On Thu, 4 Aug 2022 at 10:38, Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> Hi Dave, Adam,
>
> On 22-08-03, Dave Stevenson wrote:
> > Hi Adam
> >
> > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:
>
> ...
>
> > > > Did managed to get access to the ADV7535 programming guide? This is the
> > > > black box here. Let me check if I can provide you a link with our repo
> > > > so you can test our current DSIM state if you want.
> > >
> > > I do have access to the programming guide, but it's under NDA, but
> > > I'll try to answer questions if I can.
> >
> > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > from previously looking at these chips.
>
> Thanks for stepping into :)
>
> > Mine fairly plainly states:
> > "The DSI receiver input supports DSI video mode operation only, and
> > specifically, only supports nonburst mode with sync pulses".
>
> I've read this also, and we are working in nonburst mode with sync
> pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> verify it.
>
> > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > HDMI pixel rate.
>
> On DSI side you don't have a pixel-clock instead there is bit-clock.

You have an effective pixel clock, with a fixed conversion for the
configuration.

DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s

As noted elsewhere, the DSI is DDR, so the clock lane itself is only
running at 891 / 2 = 445.5MHz.

> > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > even more explicit about the requirement of DSI timing matching
>
> Is it possible to share the key points of the requirements?

"Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
mode requires real time data generation as a pulse packet received
becomes a pulse generated. Therefore this mode requires a continuous
stream of data with correct video timing to avoid any visual
artifacts."

LP mode is supported on data lanes. Clock lane must remain in HS mode.

"... the goal is to accurately convey DPI-type timing over DSI. This
includes matching DPI pixel-transmission rates, and widths of timing
events."

> > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > be correct for 720p operation.
>
> It should be absolute no difference if you work on 891MHz with 2 lanes
> or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> GBps.

Has someone changed the number of lanes in use? I'd missed that if so,
but I'll agree that 891MHz over 2 lanes should work for 720p60.

I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
of the modes that is mandatory to use the timing generator (reg 0x27
bit 7 = 1). On 2 lanes it is not required.
I don't know why it's referencing the 1000/1001 pixel clock rates and
not the base one, as it's only a base clock change with the same
timing (74.176MHz clock instead of 74.25MHz).

> > If you do program the manual DSI divider register to allow a DSI pixel
> > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
>
> There is no such DSI pixel rate to be precise, we only have a DSI bit
> clock/rate.
>
> > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > tx to compensate for the differing data rates. I see no reference to
> > such, and I'd be surprised if it was more than a half dozen pixels to
> > compensate for the jitter in the cases where the internal timing
> > generator is mandatory due to fractional bytes.
>
> This is interesting and would proofs our assumption that the device
> don't have a FIFO :)
>
> Our assumptions (we don't have the datasheet/programming manual):
>   - HDMI part is fetching 3 bytes per HDMI pixclk
>   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
>     HDMI are in sync. So from bandwidth pov there are no differences
>     between:
>       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
>       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 )
>       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75)
>
>     But the ratio is different and therefore the faster clocking option
>     let something 'overflow'.

I'll agree that all looks consistent.

> Anyway, but all this means that Adam should configure the
> burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work
> either and now we are back on my initial statement -> the driver needs
> some attention.

Things always need attention :-)
I suspect that it's the use of the timing generator that is the issue.
The programming guide does recommend using it for all modes, so that
would be a sensible first step.

I will say that we had a number of issues getting this chip to do
anything, and it generally seemed happier on 2 or 3 lanes instead of
4. Suffice to say that we abandoned trying to use it, despite some
assistance from ADI.

  Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Dave Stevenson]

Hi Marco

On Thu, 4 Aug 2022 at 11:28, Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> On 22-08-03, Dave Stevenson wrote:
> > On Wed, 3 Aug 2022 at 13:31, Adam Ford <aford173@gmail.com> wrote:
>
> ...
>
> > > Mine also states the DSI source needs to provide correct video timing
> > > with start and stop sync packets.
> > >
> > > If I remember correctly, it seemed like Marek V wanted the hard coded
> > > samsung,burst-clock-frequency to go away so the clock frequency could
> > > be set dynamically.
> >
> > I've never worked with Exynos or imx8, but my view would be that
> > samsung,burst-clock-frequency should only be used if
> > MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for
> > adv7533/5).
>
> Some notes on that. The samsung,burst-clock-frequency is the
> hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to
> do with the MIPI_DSI_MODE_VIDEO_BURST.
>
> > Without that flag the DSI link frequency should be running at the rate
> > defined by the mode clock, number of lanes, bpp, etc.
>
> IMHO the DSI link have only to guarantee the bandwidth is sufficient for
> the mode.

DSI spec 8.11.3 Non-Burst Mode with Sync Events
"This mode is a simplification of the format described in Section
8.11.2 (Non-Burst Mode with Sync Pulses)
...
Pixels are transmitted at the same rate as they would in a
corresponding parallel display interface such as DPI-2."

If you are running the DSI clock at anything other than that rate,
then AIUI you are in a burst mode (although you may choose not to drop
into LP mode).

(One of my pet peeves that there is no documentation as to exactly
what MIPI_DSI_MODE_VIDEO_BURST is meant to mean. Seeing as in the DSI
spec all modes of 8.11 say that the host can drop to LP during
blanking if time allows, it surely has to be the time compression
element of 8.11.4 Burst Mode).

> > From the DSI spec (v 1.1 section 8.11.1):
> > "Non-Burst Mode with Sync Pulses – enables the peripheral to
> > accurately reconstruct original video timing, including sync pulse
> > widths."
> > "RGB pixel packets are time-compressed, leaving more time during a
> > scan line for LP mode (saving power) or for multiplexing other
> > transmissions onto the DSI link."
> > How can the peripheral reconstruct the video timing off a quirky link frequency?
>
> If the ADV couldn't reconstruct the sync signals, then we should not get
> any mode working but we get the 1080P mode working.
>
> > Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1]
> > reconfigures the clock setup of the DSI block, then I don't see how
> > the Exynos driver can follow the DSI spec in that regard.
>
> Why do you think that the Exynos driver isn't following the spec? We
> configure the host into video mode with sync signals which is working
> for the 1080P mode.

1080p is working with samsung,burst-clock-frequency setting?
As I say, I've not worked with this IP, I'm only looking at it from
the outside having spent far too much time recently on the Pi DSI
interface.
exynos_drm_dsi.c seems to be doing a lot of PLL computation around
burst-clock-frequency, and nothing with the pixel clock rate. Without
knowledge of what that DSIM_BURST_MODE bit in DSIM_CONFIG_REG actually
does in the hardware, I can only make guesses. Perhaps it does ditch
the burst clock and switch the bit clock to be derived from the pixel
clock of the upstream block, but that seems unlikely.

  Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Dave,

On 22-08-04, Dave Stevenson wrote:
> Hi Marco
> 
> On Thu, 4 Aug 2022 at 10:38, Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > Hi Dave, Adam,
> >
> > On 22-08-03, Dave Stevenson wrote:
> > > Hi Adam
> > >
> > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:
> >
> > ...
> >
> > > > > Did managed to get access to the ADV7535 programming guide? This is the
> > > > > black box here. Let me check if I can provide you a link with our repo
> > > > > so you can test our current DSIM state if you want.
> > > >
> > > > I do have access to the programming guide, but it's under NDA, but
> > > > I'll try to answer questions if I can.
> > >
> > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > > from previously looking at these chips.
> >
> > Thanks for stepping into :)
> >
> > > Mine fairly plainly states:
> > > "The DSI receiver input supports DSI video mode operation only, and
> > > specifically, only supports nonburst mode with sync pulses".
> >
> > I've read this also, and we are working in nonburst mode with sync
> > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > verify it.
> >
> > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > > HDMI pixel rate.
> >
> > On DSI side you don't have a pixel-clock instead there is bit-clock.
> 
> You have an effective pixel clock, with a fixed conversion for the
> configuration.
> 
> DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s

Okay, I just checked the bandwidth which must equal.

> As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> running at 891 / 2 = 445.5MHz.
> 
> > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > > even more explicit about the requirement of DSI timing matching
> >
> > Is it possible to share the key points of the requirements?
> 
> "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
> mode requires real time data generation as a pulse packet received
> becomes a pulse generated. Therefore this mode requires a continuous
> stream of data with correct video timing to avoid any visual
> artifacts."
> 
> LP mode is supported on data lanes. Clock lane must remain in HS mode.
> 
> "... the goal is to accurately convey DPI-type timing over DSI. This
> includes matching DPI pixel-transmission rates, and widths of timing
> events."

Thanks for sharing.

> > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > > be correct for 720p operation.
> >
> > It should be absolute no difference if you work on 891MHz with 2 lanes
> > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> > GBps.
> 
> Has someone changed the number of lanes in use? I'd missed that if so,
> but I'll agree that 891MHz over 2 lanes should work for 720p60.

The ADV driver is changing it autom. but this logic is somehow odd and
there was already a approach to stop the driver doing this.

To sync up: we have two problems:
  1) The 720P mode with static DSI host configuration isn't working
     without hacks.
  2) The DSI link frequency should changed as soon as required
     automatically. So we can provide all modes.

I would concentrate on problem 1 first before moving on to the 2nd.

> I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
> of the modes that is mandatory to use the timing generator (reg 0x27
> bit 7 = 1). On 2 lanes it is not required.
> I don't know why it's referencing the 1000/1001 pixel clock rates and
> not the base one, as it's only a base clock change with the same
> timing (74.176MHz clock instead of 74.25MHz).

Interesting! I would like to know how the HDMI block gets fetched by the
DSI block and how the timing-generator can influence this in good/bad
way. So that we know what DSI settings (freq, lanes) are sufficient.

> > > If you do program the manual DSI divider register to allow a DSI pixel
> > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> >
> > There is no such DSI pixel rate to be precise, we only have a DSI bit
> > clock/rate.
> >
> > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > > tx to compensate for the differing data rates. I see no reference to
> > > such, and I'd be surprised if it was more than a half dozen pixels to
> > > compensate for the jitter in the cases where the internal timing
> > > generator is mandatory due to fractional bytes.
> >
> > This is interesting and would proofs our assumption that the device
> > don't have a FIFO :)
> >
> > Our assumptions (we don't have the datasheet/programming manual):
> >   - HDMI part is fetching 3 bytes per HDMI pixclk
> >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
> >     HDMI are in sync. So from bandwidth pov there are no differences
> >     between:
> >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 )
> >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75)
> >
> >     But the ratio is different and therefore the faster clocking option
> >     let something 'overflow'.
> 
> I'll agree that all looks consistent.
> 
> > Anyway, but all this means that Adam should configure the
> > burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work
> > either and now we are back on my initial statement -> the driver needs
> > some attention.
> 
> Things always need attention :-)

^^

> I suspect that it's the use of the timing generator that is the issue.
> The programming guide does recommend using it for all modes, so that
> would be a sensible first step.

But I tested it without the timing-generator too. Can you or Adam verify
the timing-generator diable logic?

> I will say that we had a number of issues getting this chip to do
> anything, and it generally seemed happier on 2 or 3 lanes instead of
> 4. Suffice to say that we abandoned trying to use it, despite some
> assistance from ADI.

Even more interessting, what is your alternative to this chip?

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> Hi Dave,
>
> On 22-08-04, Dave Stevenson wrote:
> > Hi Marco
> >
> > On Thu, 4 Aug 2022 at 10:38, Marco Felsch <m.felsch@pengutronix.de> wrote:
> > >
> > > Hi Dave, Adam,
> > >
> > > On 22-08-03, Dave Stevenson wrote:
> > > > Hi Adam
> > > >
> > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:
> > >
> > > ...
> > >
> > > > > > Did managed to get access to the ADV7535 programming guide? This is the
> > > > > > black box here. Let me check if I can provide you a link with our repo
> > > > > > so you can test our current DSIM state if you want.
> > > > >
> > > > > I do have access to the programming guide, but it's under NDA, but
> > > > > I'll try to answer questions if I can.
> > > >
> > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > > > from previously looking at these chips.
> > >
> > > Thanks for stepping into :)
> > >
> > > > Mine fairly plainly states:
> > > > "The DSI receiver input supports DSI video mode operation only, and
> > > > specifically, only supports nonburst mode with sync pulses".
> > >
> > > I've read this also, and we are working in nonburst mode with sync
> > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > verify it.
> > >
> > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > > > HDMI pixel rate.
> > >
> > > On DSI side you don't have a pixel-clock instead there is bit-clock.
> >
> > You have an effective pixel clock, with a fixed conversion for the
> > configuration.
> >
> > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
>
> Okay, I just checked the bandwidth which must equal.
>
> > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > running at 891 / 2 = 445.5MHz.
> >
> > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > > > even more explicit about the requirement of DSI timing matching
> > >
> > > Is it possible to share the key points of the requirements?
> >
> > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
> > mode requires real time data generation as a pulse packet received
> > becomes a pulse generated. Therefore this mode requires a continuous
> > stream of data with correct video timing to avoid any visual
> > artifacts."
> >
> > LP mode is supported on data lanes. Clock lane must remain in HS mode.
> >
> > "... the goal is to accurately convey DPI-type timing over DSI. This
> > includes matching DPI pixel-transmission rates, and widths of timing
> > events."
>
> Thanks for sharing.
>
> > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > > > be correct for 720p operation.
> > >
> > > It should be absolute no difference if you work on 891MHz with 2 lanes
> > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> > > GBps.
> >
> > Has someone changed the number of lanes in use? I'd missed that if so,
> > but I'll agree that 891MHz over 2 lanes should work for 720p60.
>
> The ADV driver is changing it autom. but this logic is somehow odd and
> there was already a approach to stop the driver doing this.
>
> To sync up: we have two problems:
>   1) The 720P mode with static DSI host configuration isn't working
>      without hacks.

can you share your hacks with me about getting 720p to work?  I've
been struggling to get 720 to work.

>   2) The DSI link frequency should changed as soon as required
>      automatically. So we can provide all modes.
>
> I would concentrate on problem 1 first before moving on to the 2nd.

I do have some code that does #2 already.  I can clean it up and share
if you want.  I've been bouncing back and forth between the NXP kernel
and the Jagan/Fabio kernel to compare and with my clock change, it
appears to be generating similar clocks to the NXP, yet it still won't
sync at 720P.

>
> > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
> > of the modes that is mandatory to use the timing generator (reg 0x27
> > bit 7 = 1). On 2 lanes it is not required.
> > I don't know why it's referencing the 1000/1001 pixel clock rates and
> > not the base one, as it's only a base clock change with the same
> > timing (74.176MHz clock instead of 74.25MHz).
>
> Interesting! I would like to know how the HDMI block gets fetched by the
> DSI block and how the timing-generator can influence this in good/bad
> way. So that we know what DSI settings (freq, lanes) are sufficient.
>
> > > > If you do program the manual DSI divider register to allow a DSI pixel
> > > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> > >
> > > There is no such DSI pixel rate to be precise, we only have a DSI bit
> > > clock/rate.
> > >
> > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > > > tx to compensate for the differing data rates. I see no reference to
> > > > such, and I'd be surprised if it was more than a half dozen pixels to
> > > > compensate for the jitter in the cases where the internal timing
> > > > generator is mandatory due to fractional bytes.
> > >
> > > This is interesting and would proofs our assumption that the device
> > > don't have a FIFO :)
> > >
> > > Our assumptions (we don't have the datasheet/programming manual):
> > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
> > >     HDMI are in sync. So from bandwidth pov there are no differences
> > >     between:
> > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 )
> > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75)
> > >
> > >     But the ratio is different and therefore the faster clocking option
> > >     let something 'overflow'.
> >
> > I'll agree that all looks consistent.
> >
> > > Anyway, but all this means that Adam should configure the
> > > burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work
> > > either and now we are back on my initial statement -> the driver needs
> > > some attention.
> >
> > Things always need attention :-)
>
> ^^
>
> > I suspect that it's the use of the timing generator that is the issue.
> > The programming guide does recommend using it for all modes, so that
> > would be a sensible first step.
>
> But I tested it without the timing-generator too. Can you or Adam verify
> the timing-generator diable logic?

The internal timing generator is enabled by setting bit 7 of register 27.

After the timings bits are set, the generator must be reset by
toggling bit 6.  Bits [5:0] must be 001011b

So going between CB and 8B does this task.  From what I can tell, this
code is correct.

The NXP kernel which appears to sync at a few additional resolutions
appears to do this as well.

>
> > I will say that we had a number of issues getting this chip to do
> > anything, and it generally seemed happier on 2 or 3 lanes instead of
> > 4. Suffice to say that we abandoned trying to use it, despite some
> > assistance from ADI.

Ideally, I'd like to experiment with 2-lane as well.  Part of me
wonders if this could be dynamic to help further adjust timings.  When
I try to get clock settings for slower rates, it seems like the clock
generation is off.

adam
>
> Even more interessting, what is your alternative to this chip?
>
> Regards,
>   Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Dave,

On 22-08-04, Dave Stevenson wrote:
> Hi Marco
> 
> On Thu, 4 Aug 2022 at 11:28, Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > On 22-08-03, Dave Stevenson wrote:
> > > On Wed, 3 Aug 2022 at 13:31, Adam Ford <aford173@gmail.com> wrote:
> >
> > ...
> >
> > > > Mine also states the DSI source needs to provide correct video timing
> > > > with start and stop sync packets.
> > > >
> > > > If I remember correctly, it seemed like Marek V wanted the hard coded
> > > > samsung,burst-clock-frequency to go away so the clock frequency could
> > > > be set dynamically.
> > >
> > > I've never worked with Exynos or imx8, but my view would be that
> > > samsung,burst-clock-frequency should only be used if
> > > MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for
> > > adv7533/5).
> >
> > Some notes on that. The samsung,burst-clock-frequency is the
> > hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to
> > do with the MIPI_DSI_MODE_VIDEO_BURST.
> >
> > > Without that flag the DSI link frequency should be running at the rate
> > > defined by the mode clock, number of lanes, bpp, etc.
> >
> > IMHO the DSI link have only to guarantee the bandwidth is sufficient for
> > the mode.
> 
> DSI spec 8.11.3 Non-Burst Mode with Sync Events
> "This mode is a simplification of the format described in Section
> 8.11.2 (Non-Burst Mode with Sync Pulses)
> ...
> Pixels are transmitted at the same rate as they would in a
> corresponding parallel display interface such as DPI-2."
> 
> If you are running the DSI clock at anything other than that rate,
> then AIUI you are in a burst mode (although you may choose not to drop
> into LP mode).

Yes, that makes sense to me. The bandwidth on the DSI side should match
the one required on the other side (HDMI). Apart the fact that the ADV
is working in mode 8.11.2 (Non-Burst Mode with Sync Pulses).

> (One of my pet peeves that there is no documentation as to exactly
> what MIPI_DSI_MODE_VIDEO_BURST is meant to mean. Seeing as in the DSI
> spec all modes of 8.11 say that the host can drop to LP during
> blanking if time allows, it surely has to be the time compression
> element of 8.11.4 Burst Mode).

Hm.. I don't have the DSI spec either but I thought that BURST mode
allows the host to send the data as fast as possible and enter LP
afterwards.

> > > From the DSI spec (v 1.1 section 8.11.1):
> > > "Non-Burst Mode with Sync Pulses – enables the peripheral to
> > > accurately reconstruct original video timing, including sync pulse
> > > widths."
> > > "RGB pixel packets are time-compressed, leaving more time during a
> > > scan line for LP mode (saving power) or for multiplexing other
> > > transmissions onto the DSI link."
> > > How can the peripheral reconstruct the video timing off a quirky link frequency?
> >
> > If the ADV couldn't reconstruct the sync signals, then we should not get
> > any mode working but we get the 1080P mode working.
> >
> > > Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1]
> > > reconfigures the clock setup of the DSI block, then I don't see how
> > > the Exynos driver can follow the DSI spec in that regard.
> >
> > Why do you think that the Exynos driver isn't following the spec? We
> > configure the host into video mode with sync signals which is working
> > for the 1080P mode.
> 
> 1080p is working with samsung,burst-clock-frequency setting?

Yes.

> As I say, I've not worked with this IP, I'm only looking at it from
> the outside having spent far too much time recently on the Pi DSI
> interface.

Good to know :)

> exynos_drm_dsi.c seems to be doing a lot of PLL computation around
> burst-clock-frequency, and nothing with the pixel clock rate.

Yes currently there is just this setting for setting the PLL freq. but
as you said for the "Non-Burst Mode with Sync Pulses" we need to
reconfigure it according the required bandwidth or the dsi-device tells
us about which dsi-link settings should be applied.

> Without knowledge of what that DSIM_BURST_MODE bit in DSIM_CONFIG_REG
> actually does in the hardware, I can only make guesses.

8<----------------------------------------------
   Selects Burst mode in Video mode

   In Non-burst mode, RGB data area is filled with RGB data and Null
   packets, according to input bandwidth of RGB interface.
   
   In Burst mode, RGB data area is filled with RGB data only.

   0 = Non-burst mode
   1 = Burst mode
8<----------------------------------------------

According the current implementation we are in Non-burst mode.

Regards,
  Marco

> Perhaps it does ditch the burst clock and switch the bit clock to be
> derived from the pixel clock of the upstream block, but that seems
> unlikely.
> 
>   Dave
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Adam,

On 22-08-04, Adam Ford wrote:
> On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > Hi Dave,
> >
> > On 22-08-04, Dave Stevenson wrote:
> > > Hi Marco
> > >
> > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch <m.felsch@pengutronix.de> wrote:
> > > >
> > > > Hi Dave, Adam,
> > > >
> > > > On 22-08-03, Dave Stevenson wrote:
> > > > > Hi Adam
> > > > >
> > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > ...
> > > >
> > > > > > > Did managed to get access to the ADV7535 programming guide? This is the
> > > > > > > black box here. Let me check if I can provide you a link with our repo
> > > > > > > so you can test our current DSIM state if you want.
> > > > > >
> > > > > > I do have access to the programming guide, but it's under NDA, but
> > > > > > I'll try to answer questions if I can.
> > > > >
> > > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > > > > from previously looking at these chips.
> > > >
> > > > Thanks for stepping into :)
> > > >
> > > > > Mine fairly plainly states:
> > > > > "The DSI receiver input supports DSI video mode operation only, and
> > > > > specifically, only supports nonburst mode with sync pulses".
> > > >
> > > > I've read this also, and we are working in nonburst mode with sync
> > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > > verify it.
> > > >
> > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > > > > HDMI pixel rate.
> > > >
> > > > On DSI side you don't have a pixel-clock instead there is bit-clock.
> > >
> > > You have an effective pixel clock, with a fixed conversion for the
> > > configuration.
> > >
> > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> >
> > Okay, I just checked the bandwidth which must equal.
> >
> > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > > running at 891 / 2 = 445.5MHz.
> > >
> > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > > > > even more explicit about the requirement of DSI timing matching
> > > >
> > > > Is it possible to share the key points of the requirements?
> > >
> > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
> > > mode requires real time data generation as a pulse packet received
> > > becomes a pulse generated. Therefore this mode requires a continuous
> > > stream of data with correct video timing to avoid any visual
> > > artifacts."
> > >
> > > LP mode is supported on data lanes. Clock lane must remain in HS mode.
> > >
> > > "... the goal is to accurately convey DPI-type timing over DSI. This
> > > includes matching DPI pixel-transmission rates, and widths of timing
> > > events."
> >
> > Thanks for sharing.
> >
> > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > > > > be correct for 720p operation.
> > > >
> > > > It should be absolute no difference if you work on 891MHz with 2 lanes
> > > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> > > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> > > > GBps.
> > >
> > > Has someone changed the number of lanes in use? I'd missed that if so,
> > > but I'll agree that 891MHz over 2 lanes should work for 720p60.
> >
> > The ADV driver is changing it autom. but this logic is somehow odd and
> > there was already a approach to stop the driver doing this.
> >
> > To sync up: we have two problems:
> >   1) The 720P mode with static DSI host configuration isn't working
> >      without hacks.
> 
> can you share your hacks with me about getting 720p to work?  I've
> been struggling to get 720 to work.

Here you go: https://git.pengutronix.de/cgit/mfe/linux

It has just one branch, so very easy. If you use a 8MMini-EVK with the
NXP-Adapter than you only need a proper defconfig.

> >   2) The DSI link frequency should changed as soon as required
> >      automatically. So we can provide all modes.
> >
> > I would concentrate on problem 1 first before moving on to the 2nd.
> 
> I do have some code that does #2 already. 

Unfortunately no, since we want to fix problem 1 first.

> I can clean it up and share if you want.  I've been bouncing back and
> forth between the NXP kernel and the Jagan/Fabio kernel to compare and
> with my clock change, it appears to be generating similar clocks to
> the NXP, yet it still won't sync at 720P.
> 
> >
> > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
> > > of the modes that is mandatory to use the timing generator (reg 0x27
> > > bit 7 = 1). On 2 lanes it is not required.
> > > I don't know why it's referencing the 1000/1001 pixel clock rates and
> > > not the base one, as it's only a base clock change with the same
> > > timing (74.176MHz clock instead of 74.25MHz).
> >
> > Interesting! I would like to know how the HDMI block gets fetched by the
> > DSI block and how the timing-generator can influence this in good/bad
> > way. So that we know what DSI settings (freq, lanes) are sufficient.
> >
> > > > > If you do program the manual DSI divider register to allow a DSI pixel
> > > > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> > > >
> > > > There is no such DSI pixel rate to be precise, we only have a DSI bit
> > > > clock/rate.
> > > >
> > > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > > > > tx to compensate for the differing data rates. I see no reference to
> > > > > such, and I'd be surprised if it was more than a half dozen pixels to
> > > > > compensate for the jitter in the cases where the internal timing
> > > > > generator is mandatory due to fractional bytes.
> > > >
> > > > This is interesting and would proofs our assumption that the device
> > > > don't have a FIFO :)
> > > >
> > > > Our assumptions (we don't have the datasheet/programming manual):
> > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
> > > >     HDMI are in sync. So from bandwidth pov there are no differences
> > > >     between:
> > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 )
> > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75)
> > > >
> > > >     But the ratio is different and therefore the faster clocking option
> > > >     let something 'overflow'.
> > >
> > > I'll agree that all looks consistent.
> > >
> > > > Anyway, but all this means that Adam should configure the
> > > > burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work
> > > > either and now we are back on my initial statement -> the driver needs
> > > > some attention.
> > >
> > > Things always need attention :-)
> >
> > ^^
> >
> > > I suspect that it's the use of the timing generator that is the issue.
> > > The programming guide does recommend using it for all modes, so that
> > > would be a sensible first step.
> >
> > But I tested it without the timing-generator too. Can you or Adam verify
> > the timing-generator diable logic?
> 
> The internal timing generator is enabled by setting bit 7 of register 27.
> 
> After the timings bits are set, the generator must be reset by
> toggling bit 6.  Bits [5:0] must be 001011b
> 
> So going between CB and 8B does this task.  From what I can tell, this
> code is correct.

Okay, thanks for checking.

Regards,
  Marco

> The NXP kernel which appears to sync at a few additional resolutions
> appears to do this as well.
> 
> >
> > > I will say that we had a number of issues getting this chip to do
> > > anything, and it generally seemed happier on 2 or 3 lanes instead of
> > > 4. Suffice to say that we abandoned trying to use it, despite some
> > > assistance from ADI.
> 
> Ideally, I'd like to experiment with 2-lane as well.  Part of me
> wonders if this could be dynamic to help further adjust timings.  When
> I try to get clock settings for slower rates, it seems like the clock
> generation is off.
> 
> adam
> >
> > Even more interessting, what is your alternative to this chip?
> >
> > Regards,
> >   Marco
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: imx8mm lcdif->dsi->adv7535 no video, no errors

[Biju Das]

Hi Adam,

> Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> 
> On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch <m.felsch@pengutronix.de>
> wrote:
> >
> > Hi Dave,
> >
> > On 22-08-04, Dave Stevenson wrote:
> > > Hi Marco
> > >
> > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch <m.felsch@pengutronix.de>
> wrote:
> > > >
> > > > Hi Dave, Adam,
> > > >
> > > > On 22-08-03, Dave Stevenson wrote:
> > > > > Hi Adam
> > > > >
> > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com>
> wrote:
> > > >
> > > > ...
> > > >
> > > > > > > Did managed to get access to the ADV7535 programming guide?
> > > > > > > This is the black box here. Let me check if I can provide
> > > > > > > you a link with our repo so you can test our current DSIM
> state if you want.
> > > > > >
> > > > > > I do have access to the programming guide, but it's under NDA,
> > > > > > but I'll try to answer questions if I can.
> > > > >
> > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > 7535 from previously looking at these chips.
> > > >
> > > > Thanks for stepping into :)
> > > >
> > > > > Mine fairly plainly states:
> > > > > "The DSI receiver input supports DSI video mode operation only,
> > > > > and specifically, only supports nonburst mode with sync pulses".
> > > >
> > > > I've read this also, and we are working in nonburst mode with sync
> > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > > verify it.
> > > >
> > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same
> > > > > as the HDMI pixel rate.
> > > >
> > > > On DSI side you don't have a pixel-clock instead there is bit-
> clock.
> > >
> > > You have an effective pixel clock, with a fixed conversion for the
> > > configuration.
> > >
> > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> >
> > Okay, I just checked the bandwidth which must equal.
> >
> > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > > running at 891 / 2 = 445.5MHz.
> > >
> > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide
> > > > > is even more explicit about the requirement of DSI timing
> > > > > matching
> > > >
> > > > Is it possible to share the key points of the requirements?
> > >
> > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > This mode requires real time data generation as a pulse packet
> > > received becomes a pulse generated. Therefore this mode requires a
> > > continuous stream of data with correct video timing to avoid any
> > > visual artifacts."
> > >
> > > LP mode is supported on data lanes. Clock lane must remain in HS
> mode.
> > >
> > > "... the goal is to accurately convey DPI-type timing over DSI. This
> > > includes matching DPI pixel-transmission rates, and widths of timing
> > > events."
> >
> > Thanks for sharing.
> >
> > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > therefore be correct for 720p operation.
> > > >
> > > > It should be absolute no difference if you work on 891MHz with 2
> > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > you need the minimum required bandwidth which is roughly:
> > > > 1280*720*24*60 = 1.327 GBps.
> > >
> > > Has someone changed the number of lanes in use? I'd missed that if
> > > so, but I'll agree that 891MHz over 2 lanes should work for 720p60.
> >
> > The ADV driver is changing it autom. but this logic is somehow odd and
> > there was already a approach to stop the driver doing this.
> >
> > To sync up: we have two problems:
> >   1) The 720P mode with static DSI host configuration isn't working
> >      without hacks.
> 
> can you share your hacks with me about getting 720p to work?  I've been
> struggling to get 720 to work.

I have problems with 720p working on 3 lanes. Then I switch to 4 lanes [1]
and it starts working on Renesas RZ/G2L SMARC EVK.

[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220309151109.20957-2-biju.das.jz@bp.renesas.com/

Cheers,
Biju

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Dave Stevenson]

On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> Hi Dave,
>
> On 22-08-04, Dave Stevenson wrote:
> > Hi Marco
> >
> > On Thu, 4 Aug 2022 at 10:38, Marco Felsch <m.felsch@pengutronix.de> wrote:
> > >
> > > Hi Dave, Adam,
> > >
> > > On 22-08-03, Dave Stevenson wrote:
> > > > Hi Adam
> > > >
> > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:
> > >
> > > ...
> > >
> > > > > > Did managed to get access to the ADV7535 programming guide? This is the
> > > > > > black box here. Let me check if I can provide you a link with our repo
> > > > > > so you can test our current DSIM state if you want.
> > > > >
> > > > > I do have access to the programming guide, but it's under NDA, but
> > > > > I'll try to answer questions if I can.
> > > >
> > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > > > from previously looking at these chips.
> > >
> > > Thanks for stepping into :)
> > >
> > > > Mine fairly plainly states:
> > > > "The DSI receiver input supports DSI video mode operation only, and
> > > > specifically, only supports nonburst mode with sync pulses".
> > >
> > > I've read this also, and we are working in nonburst mode with sync
> > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > verify it.
> > >
> > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > > > HDMI pixel rate.
> > >
> > > On DSI side you don't have a pixel-clock instead there is bit-clock.
> >
> > You have an effective pixel clock, with a fixed conversion for the
> > configuration.
> >
> > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
>
> Okay, I just checked the bandwidth which must equal.
>
> > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > running at 891 / 2 = 445.5MHz.
> >
> > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > > > even more explicit about the requirement of DSI timing matching
> > >
> > > Is it possible to share the key points of the requirements?
> >
> > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
> > mode requires real time data generation as a pulse packet received
> > becomes a pulse generated. Therefore this mode requires a continuous
> > stream of data with correct video timing to avoid any visual
> > artifacts."
> >
> > LP mode is supported on data lanes. Clock lane must remain in HS mode.
> >
> > "... the goal is to accurately convey DPI-type timing over DSI. This
> > includes matching DPI pixel-transmission rates, and widths of timing
> > events."
>
> Thanks for sharing.
>
> > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > > > be correct for 720p operation.
> > >
> > > It should be absolute no difference if you work on 891MHz with 2 lanes
> > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> > > GBps.
> >
> > Has someone changed the number of lanes in use? I'd missed that if so,
> > but I'll agree that 891MHz over 2 lanes should work for 720p60.
>
> The ADV driver is changing it autom. but this logic is somehow odd and
> there was already a approach to stop the driver doing this.

I'd missed that bit in the driver where it appears to drop to 3 lanes
for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
probably the only way it can be achieved in the current framework.

> To sync up: we have two problems:
>   1) The 720P mode with static DSI host configuration isn't working
>      without hacks.
>   2) The DSI link frequency should changed as soon as required
>      automatically. So we can provide all modes.
>
> I would concentrate on problem 1 first before moving on to the 2nd.

If you change your link frequency, it may be worth trying a lower
resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
lanes is again listed as mandatory for using the timing generator).

> > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
> > of the modes that is mandatory to use the timing generator (reg 0x27
> > bit 7 = 1). On 2 lanes it is not required.
> > I don't know why it's referencing the 1000/1001 pixel clock rates and
> > not the base one, as it's only a base clock change with the same
> > timing (74.176MHz clock instead of 74.25MHz).
>
> Interesting! I would like to know how the HDMI block gets fetched by the
> DSI block and how the timing-generator can influence this in good/bad
> way. So that we know what DSI settings (freq, lanes) are sufficient.
>
> > > > If you do program the manual DSI divider register to allow a DSI pixel
> > > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> > >
> > > There is no such DSI pixel rate to be precise, we only have a DSI bit
> > > clock/rate.
> > >
> > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > > > tx to compensate for the differing data rates. I see no reference to
> > > > such, and I'd be surprised if it was more than a half dozen pixels to
> > > > compensate for the jitter in the cases where the internal timing
> > > > generator is mandatory due to fractional bytes.
> > >
> > > This is interesting and would proofs our assumption that the device
> > > don't have a FIFO :)
> > >
> > > Our assumptions (we don't have the datasheet/programming manual):
> > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
> > >     HDMI are in sync. So from bandwidth pov there are no differences
> > >     between:
> > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 )
> > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75)
> > >
> > >     But the ratio is different and therefore the faster clocking option
> > >     let something 'overflow'.
> >
> > I'll agree that all looks consistent.
> >
> > > Anyway, but all this means that Adam should configure the
> > > burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work
> > > either and now we are back on my initial statement -> the driver needs
> > > some attention.
> >
> > Things always need attention :-)
>
> ^^
>
> > I suspect that it's the use of the timing generator that is the issue.
> > The programming guide does recommend using it for all modes, so that
> > would be a sensible first step.
>
> But I tested it without the timing-generator too. Can you or Adam verify
> the timing-generator diable logic?

Sorry, running without the use of the timing generator is the issue.
It is mandatory in some modes, but supported in all modes. Always
using it should therefore avoid not using it in one of the mandatory
modes (the list looks a little arbitrary).

> > I will say that we had a number of issues getting this chip to do
> > anything, and it generally seemed happier on 2 or 3 lanes instead of
> > 4. Suffice to say that we abandoned trying to use it, despite some
> > assistance from ADI.
>
> Even more interessting, what is your alternative to this chip?

BCM2711 which supported dual HDMI natively.
Our investigation of ADV7535 was when trying to build what became
Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
do have the prototype, the ADV was wired up weirdly with I2C so I
never really got it running with Linux.

  Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
<dave.stevenson@raspberrypi.com> wrote:
>
> On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > Hi Dave,
> >
> > On 22-08-04, Dave Stevenson wrote:
> > > Hi Marco
> > >
> > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch <m.felsch@pengutronix.de> wrote:
> > > >
> > > > Hi Dave, Adam,
> > > >
> > > > On 22-08-03, Dave Stevenson wrote:
> > > > > Hi Adam
> > > > >
> > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > ...
> > > >
> > > > > > > Did managed to get access to the ADV7535 programming guide? This is the
> > > > > > > black box here. Let me check if I can provide you a link with our repo
> > > > > > > so you can test our current DSIM state if you want.
> > > > > >
> > > > > > I do have access to the programming guide, but it's under NDA, but
> > > > > > I'll try to answer questions if I can.
> > > > >
> > > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > > > > from previously looking at these chips.
> > > >
> > > > Thanks for stepping into :)
> > > >
> > > > > Mine fairly plainly states:
> > > > > "The DSI receiver input supports DSI video mode operation only, and
> > > > > specifically, only supports nonburst mode with sync pulses".
> > > >
> > > > I've read this also, and we are working in nonburst mode with sync
> > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > > verify it.
> > > >
> > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > > > > HDMI pixel rate.
> > > >
> > > > On DSI side you don't have a pixel-clock instead there is bit-clock.
> > >
> > > You have an effective pixel clock, with a fixed conversion for the
> > > configuration.
> > >
> > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> >
> > Okay, I just checked the bandwidth which must equal.
> >
> > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > > running at 891 / 2 = 445.5MHz.
> > >
> > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > > > > even more explicit about the requirement of DSI timing matching
> > > >
> > > > Is it possible to share the key points of the requirements?
> > >
> > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
> > > mode requires real time data generation as a pulse packet received
> > > becomes a pulse generated. Therefore this mode requires a continuous
> > > stream of data with correct video timing to avoid any visual
> > > artifacts."
> > >
> > > LP mode is supported on data lanes. Clock lane must remain in HS mode.
> > >
> > > "... the goal is to accurately convey DPI-type timing over DSI. This
> > > includes matching DPI pixel-transmission rates, and widths of timing
> > > events."
> >
> > Thanks for sharing.
> >
> > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > > > > be correct for 720p operation.
> > > >
> > > > It should be absolute no difference if you work on 891MHz with 2 lanes
> > > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> > > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> > > > GBps.
> > >
> > > Has someone changed the number of lanes in use? I'd missed that if so,
> > > but I'll agree that 891MHz over 2 lanes should work for 720p60.
> >
> > The ADV driver is changing it autom. but this logic is somehow odd and
> > there was already a approach to stop the driver doing this.
>
> I'd missed that bit in the driver where it appears to drop to 3 lanes
> for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
> probably the only way it can be achieved in the current framework.
>
> > To sync up: we have two problems:
> >   1) The 720P mode with static DSI host configuration isn't working
> >      without hacks.
> >   2) The DSI link frequency should changed as soon as required
> >      automatically. So we can provide all modes.
> >
> > I would concentrate on problem 1 first before moving on to the 2nd.
>
> If you change your link frequency, it may be worth trying a lower
> resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
> lanes is again listed as mandatory for using the timing generator).
>
> > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
> > > of the modes that is mandatory to use the timing generator (reg 0x27
> > > bit 7 = 1). On 2 lanes it is not required.
> > > I don't know why it's referencing the 1000/1001 pixel clock rates and
> > > not the base one, as it's only a base clock change with the same
> > > timing (74.176MHz clock instead of 74.25MHz).
> >
> > Interesting! I would like to know how the HDMI block gets fetched by the
> > DSI block and how the timing-generator can influence this in good/bad
> > way. So that we know what DSI settings (freq, lanes) are sufficient.
> >
> > > > > If you do program the manual DSI divider register to allow a DSI pixel
> > > > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> > > >
> > > > There is no such DSI pixel rate to be precise, we only have a DSI bit
> > > > clock/rate.
> > > >
> > > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > > > > tx to compensate for the differing data rates. I see no reference to
> > > > > such, and I'd be surprised if it was more than a half dozen pixels to
> > > > > compensate for the jitter in the cases where the internal timing
> > > > > generator is mandatory due to fractional bytes.
> > > >
> > > > This is interesting and would proofs our assumption that the device
> > > > don't have a FIFO :)
> > > >
> > > > Our assumptions (we don't have the datasheet/programming manual):
> > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
> > > >     HDMI are in sync. So from bandwidth pov there are no differences
> > > >     between:
> > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 )
> > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75)
> > > >
> > > >     But the ratio is different and therefore the faster clocking option
> > > >     let something 'overflow'.
> > >
> > > I'll agree that all looks consistent.
> > >
> > > > Anyway, but all this means that Adam should configure the
> > > > burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work
> > > > either and now we are back on my initial statement -> the driver needs
> > > > some attention.
> > >
> > > Things always need attention :-)
> >
> > ^^
> >
> > > I suspect that it's the use of the timing generator that is the issue.
> > > The programming guide does recommend using it for all modes, so that
> > > would be a sensible first step.
> >
> > But I tested it without the timing-generator too. Can you or Adam verify
> > the timing-generator diable logic?
>
> Sorry, running without the use of the timing generator is the issue.
> It is mandatory in some modes, but supported in all modes. Always
> using it should therefore avoid not using it in one of the mandatory
> modes (the list looks a little arbitrary).
>
> > > I will say that we had a number of issues getting this chip to do
> > > anything, and it generally seemed happier on 2 or 3 lanes instead of
> > > 4. Suffice to say that we abandoned trying to use it, despite some
> > > assistance from ADI.
> >
> > Even more interessting, what is your alternative to this chip?
>
> BCM2711 which supported dual HDMI natively.
> Our investigation of ADV7535 was when trying to build what became
> Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
> do have the prototype, the ADV was wired up weirdly with I2C so I
> never really got it running with Linux.

I think I have convinced myself that the DSIM is working good enough
to match that of the NXP.

I've gone through and made a list of the register differences between
a working display using NXP's kernel and
the non-working display.  I've identified a small handful of registers
on both the CEC bank of registers and main set of registers.

I noticed that the working NXP version doesn't rescale the number of
lanes based on the clock rate, and it stays fixed at 4 lanes.

That might actually explain some of the issues I am seeing on their
kernel still not syncing at low resolutions.

I'm going to try to go through the code and identify other differences
and see if I can hack this version of the ADv7535 driver to get it
into a similar working state as the NXP one (not that theirs is the
best).  With a couple of the hacks, I can get my screen to sync, but
it just displays blue, so I think I am making some progress.

I should have a few more hours tomorrow to work on this.  It's a
side-project for me, but I have time over the weekend too.

adam
>
>   Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: imx8mm lcdif->dsi->adv7535 no video, no errors

[Biju Das]

Hi Adam and all,

> Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> 
> On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> <dave.stevenson@raspberrypi.com> wrote:
> >
> > On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de>
> wrote:
> > >
> > > Hi Dave,
> > >
> > > On 22-08-04, Dave Stevenson wrote:
> > > > Hi Marco
> > > >
> > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch
> <m.felsch@pengutronix.de> wrote:
> > > > >
> > > > > Hi Dave, Adam,
> > > > >
> > > > > On 22-08-03, Dave Stevenson wrote:
> > > > > > Hi Adam
> > > > > >
> > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com>
> wrote:
> > > > >
> > > > > ...
> > > > >
> > > > > > > > Did managed to get access to the ADV7535 programming
> > > > > > > > guide? This is the black box here. Let me check if I can
> > > > > > > > provide you a link with our repo so you can test our
> current DSIM state if you want.
> > > > > > >
> > > > > > > I do have access to the programming guide, but it's under
> > > > > > > NDA, but I'll try to answer questions if I can.
> > > > > >
> > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > > 7535 from previously looking at these chips.
> > > > >
> > > > > Thanks for stepping into :)
> > > > >
> > > > > > Mine fairly plainly states:
> > > > > > "The DSI receiver input supports DSI video mode operation
> > > > > > only, and specifically, only supports nonburst mode with sync
> pulses".
> > > > >
> > > > > I've read this also, and we are working in nonburst mode with
> > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore
> > > > > I can't verify it.
> > > > >
> > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the
> > > > > > same as the HDMI pixel rate.
> > > > >
> > > > > On DSI side you don't have a pixel-clock instead there is bit-
> clock.
> > > >
> > > > You have an effective pixel clock, with a fixed conversion for the
> > > > configuration.
> > > >
> > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> > >
> > > Okay, I just checked the bandwidth which must equal.
> > >
> > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is
> > > > only running at 891 / 2 = 445.5MHz.
> > > >
> > > > > > Section 6.1.1 "DSI Input Modes" of
> > > > > > adv7533_hardware_user_s_guide is even more explicit about the
> > > > > > requirement of DSI timing matching
> > > > >
> > > > > Is it possible to share the key points of the requirements?
> > > >
> > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > > This mode requires real time data generation as a pulse packet
> > > > received becomes a pulse generated. Therefore this mode requires a
> > > > continuous stream of data with correct video timing to avoid any
> > > > visual artifacts."
> > > >
> > > > LP mode is supported on data lanes. Clock lane must remain in HS
> mode.
> > > >
> > > > "... the goal is to accurately convey DPI-type timing over DSI.
> > > > This includes matching DPI pixel-transmission rates, and widths of
> > > > timing events."
> > >
> > > Thanks for sharing.
> > >
> > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > > therefore be correct for 720p operation.
> > > > >
> > > > > It should be absolute no difference if you work on 891MHz with 2
> > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > > you need the minimum required bandwidth which is roughly:
> > > > > 1280*720*24*60 = 1.327 GBps.
> > > >
> > > > Has someone changed the number of lanes in use? I'd missed that if
> > > > so, but I'll agree that 891MHz over 2 lanes should work for
> 720p60.
> > >
> > > The ADV driver is changing it autom. but this logic is somehow odd
> > > and there was already a approach to stop the driver doing this.
> >
> > I'd missed that bit in the driver where it appears to drop to 3 lanes
> > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
> > probably the only way it can be achieved in the current framework.
> >
> > > To sync up: we have two problems:
> > >   1) The 720P mode with static DSI host configuration isn't working
> > >      without hacks.
> > >   2) The DSI link frequency should changed as soon as required
> > >      automatically. So we can provide all modes.
> > >
> > > I would concentrate on problem 1 first before moving on to the 2nd.
> >
> > If you change your link frequency, it may be worth trying a lower
> > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
> > lanes is again listed as mandatory for using the timing generator).
> >
> > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as
> > > > one of the modes that is mandatory to use the timing generator
> > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required.
> > > > I don't know why it's referencing the 1000/1001 pixel clock rates
> > > > and not the base one, as it's only a base clock change with the
> > > > same timing (74.176MHz clock instead of 74.25MHz).
> > >
> > > Interesting! I would like to know how the HDMI block gets fetched by
> > > the DSI block and how the timing-generator can influence this in
> > > good/bad way. So that we know what DSI settings (freq, lanes) are
> sufficient.
> > >
> > > > > > If you do program the manual DSI divider register to allow a
> > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz,
> > > > > > you'd be relying on
> > > > >
> > > > > There is no such DSI pixel rate to be precise, we only have a
> > > > > DSI bit clock/rate.
> > > > >
> > > > > > the ADV753x having at least a half-line FIFO between DSI rx
> > > > > > and HDMI tx to compensate for the differing data rates. I see
> > > > > > no reference to such, and I'd be surprised if it was more than
> > > > > > a half dozen pixels to compensate for the jitter in the cases
> > > > > > where the internal timing generator is mandatory due to
> fractional bytes.
> > > > >
> > > > > This is interesting and would proofs our assumption that the
> > > > > device don't have a FIFO :)
> > > > >
> > > > > Our assumptions (we don't have the datasheet/programming
> manual):
> > > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI
> and
> > > > >     HDMI are in sync. So from bandwidth pov there are no
> differences
> > > > >     between:
> > > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock:
> 445.5 )
> > > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > 222.75)
> > > > >
> > > > >     But the ratio is different and therefore the faster clocking
> option
> > > > >     let something 'overflow'.
> > > >
> > > > I'll agree that all looks consistent.
> > > >
> > > > > Anyway, but all this means that Adam should configure the
> > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this
> > > > > doesn't work either and now we are back on my initial statement
> > > > > -> the driver needs some attention.
> > > >
> > > > Things always need attention :-)
> > >
> > > ^^
> > >
> > > > I suspect that it's the use of the timing generator that is the
> issue.
> > > > The programming guide does recommend using it for all modes, so
> > > > that would be a sensible first step.
> > >
> > > But I tested it without the timing-generator too. Can you or Adam
> > > verify the timing-generator diable logic?
> >
> > Sorry, running without the use of the timing generator is the issue.
> > It is mandatory in some modes, but supported in all modes. Always
> > using it should therefore avoid not using it in one of the mandatory
> > modes (the list looks a little arbitrary).
> >
> > > > I will say that we had a number of issues getting this chip to do
> > > > anything, and it generally seemed happier on 2 or 3 lanes instead
> > > > of 4. Suffice to say that we abandoned trying to use it, despite
> > > > some assistance from ADI.
> > >
> > > Even more interessting, what is your alternative to this chip?
> >
> > BCM2711 which supported dual HDMI natively.
> > Our investigation of ADV7535 was when trying to build what became
> > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
> > do have the prototype, the ADV was wired up weirdly with I2C so I
> > never really got it running with Linux.
> 
> I think I have convinced myself that the DSIM is working good enough to
> match that of the NXP.
> 
> I've gone through and made a list of the register differences between a
> working display using NXP's kernel and the non-working display.  I've
> identified a small handful of registers on both the CEC bank of
> registers and main set of registers.
> 
> I noticed that the working NXP version doesn't rescale the number of
> lanes based on the clock rate, and it stays fixed at 4 lanes.

Does it mean theoretically rescale of lanes is not required??
At least 2 platforms can work with fixed 4 lanes@720p.

and looks like few platforms have display stability issue working with 4 lanes@720p, 
so, as a workaround they changed to 3 lanes based on clock rate to make it work.

Can you please confirm, is my understanding correct?

Note:
 On Renesas RZ/G2L platform, 720p with 3 lanes will work, but it needs
 different pll parameters to generate the dot clock to work.
 
Cheers,
Biju

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Fri, Aug 5, 2022 at 3:44 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> Hi Adam and all,
>
> > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> >
> > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> > <dave.stevenson@raspberrypi.com> wrote:
> > >
> > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de>
> > wrote:
> > > >
> > > > Hi Dave,
> > > >
> > > > On 22-08-04, Dave Stevenson wrote:
> > > > > Hi Marco
> > > > >
> > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch
> > <m.felsch@pengutronix.de> wrote:
> > > > > >
> > > > > > Hi Dave, Adam,
> > > > > >
> > > > > > On 22-08-03, Dave Stevenson wrote:
> > > > > > > Hi Adam
> > > > > > >
> > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com>
> > wrote:
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > > > Did managed to get access to the ADV7535 programming
> > > > > > > > > guide? This is the black box here. Let me check if I can
> > > > > > > > > provide you a link with our repo so you can test our
> > current DSIM state if you want.
> > > > > > > >
> > > > > > > > I do have access to the programming guide, but it's under
> > > > > > > > NDA, but I'll try to answer questions if I can.
> > > > > > >
> > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > > > 7535 from previously looking at these chips.
> > > > > >
> > > > > > Thanks for stepping into :)
> > > > > >
> > > > > > > Mine fairly plainly states:
> > > > > > > "The DSI receiver input supports DSI video mode operation
> > > > > > > only, and specifically, only supports nonburst mode with sync
> > pulses".
> > > > > >
> > > > > > I've read this also, and we are working in nonburst mode with
> > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore
> > > > > > I can't verify it.
> > > > > >
> > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the
> > > > > > > same as the HDMI pixel rate.
> > > > > >
> > > > > > On DSI side you don't have a pixel-clock instead there is bit-
> > clock.
> > > > >
> > > > > You have an effective pixel clock, with a fixed conversion for the
> > > > > configuration.
> > > > >
> > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> > > >
> > > > Okay, I just checked the bandwidth which must equal.
> > > >
> > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is
> > > > > only running at 891 / 2 = 445.5MHz.
> > > > >
> > > > > > > Section 6.1.1 "DSI Input Modes" of
> > > > > > > adv7533_hardware_user_s_guide is even more explicit about the
> > > > > > > requirement of DSI timing matching
> > > > > >
> > > > > > Is it possible to share the key points of the requirements?
> > > > >
> > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > > > This mode requires real time data generation as a pulse packet
> > > > > received becomes a pulse generated. Therefore this mode requires a
> > > > > continuous stream of data with correct video timing to avoid any
> > > > > visual artifacts."
> > > > >
> > > > > LP mode is supported on data lanes. Clock lane must remain in HS
> > mode.
> > > > >
> > > > > "... the goal is to accurately convey DPI-type timing over DSI.
> > > > > This includes matching DPI pixel-transmission rates, and widths of
> > > > > timing events."
> > > >
> > > > Thanks for sharing.
> > > >
> > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > > > therefore be correct for 720p operation.
> > > > > >
> > > > > > It should be absolute no difference if you work on 891MHz with 2
> > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > > > you need the minimum required bandwidth which is roughly:
> > > > > > 1280*720*24*60 = 1.327 GBps.
> > > > >
> > > > > Has someone changed the number of lanes in use? I'd missed that if
> > > > > so, but I'll agree that 891MHz over 2 lanes should work for
> > 720p60.
> > > >
> > > > The ADV driver is changing it autom. but this logic is somehow odd
> > > > and there was already a approach to stop the driver doing this.
> > >
> > > I'd missed that bit in the driver where it appears to drop to 3 lanes
> > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
> > > probably the only way it can be achieved in the current framework.
> > >
> > > > To sync up: we have two problems:
> > > >   1) The 720P mode with static DSI host configuration isn't working
> > > >      without hacks.
> > > >   2) The DSI link frequency should changed as soon as required
> > > >      automatically. So we can provide all modes.
> > > >
> > > > I would concentrate on problem 1 first before moving on to the 2nd.
> > >
> > > If you change your link frequency, it may be worth trying a lower
> > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
> > > lanes is again listed as mandatory for using the timing generator).
> > >
> > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as
> > > > > one of the modes that is mandatory to use the timing generator
> > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required.
> > > > > I don't know why it's referencing the 1000/1001 pixel clock rates
> > > > > and not the base one, as it's only a base clock change with the
> > > > > same timing (74.176MHz clock instead of 74.25MHz).
> > > >
> > > > Interesting! I would like to know how the HDMI block gets fetched by
> > > > the DSI block and how the timing-generator can influence this in
> > > > good/bad way. So that we know what DSI settings (freq, lanes) are
> > sufficient.
> > > >
> > > > > > > If you do program the manual DSI divider register to allow a
> > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz,
> > > > > > > you'd be relying on
> > > > > >
> > > > > > There is no such DSI pixel rate to be precise, we only have a
> > > > > > DSI bit clock/rate.
> > > > > >
> > > > > > > the ADV753x having at least a half-line FIFO between DSI rx
> > > > > > > and HDMI tx to compensate for the differing data rates. I see
> > > > > > > no reference to such, and I'd be surprised if it was more than
> > > > > > > a half dozen pixels to compensate for the jitter in the cases
> > > > > > > where the internal timing generator is mandatory due to
> > fractional bytes.
> > > > > >
> > > > > > This is interesting and would proofs our assumption that the
> > > > > > device don't have a FIFO :)
> > > > > >
> > > > > > Our assumptions (we don't have the datasheet/programming
> > manual):
> > > > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI
> > and
> > > > > >     HDMI are in sync. So from bandwidth pov there are no
> > differences
> > > > > >     between:
> > > > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock:
> > 445.5 )
> > > > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > 222.75)
> > > > > >
> > > > > >     But the ratio is different and therefore the faster clocking
> > option
> > > > > >     let something 'overflow'.
> > > > >
> > > > > I'll agree that all looks consistent.
> > > > >
> > > > > > Anyway, but all this means that Adam should configure the
> > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this
> > > > > > doesn't work either and now we are back on my initial statement
> > > > > > -> the driver needs some attention.
> > > > >
> > > > > Things always need attention :-)
> > > >
> > > > ^^
> > > >
> > > > > I suspect that it's the use of the timing generator that is the
> > issue.
> > > > > The programming guide does recommend using it for all modes, so
> > > > > that would be a sensible first step.
> > > >
> > > > But I tested it without the timing-generator too. Can you or Adam
> > > > verify the timing-generator diable logic?
> > >
> > > Sorry, running without the use of the timing generator is the issue.
> > > It is mandatory in some modes, but supported in all modes. Always
> > > using it should therefore avoid not using it in one of the mandatory
> > > modes (the list looks a little arbitrary).
> > >
> > > > > I will say that we had a number of issues getting this chip to do
> > > > > anything, and it generally seemed happier on 2 or 3 lanes instead
> > > > > of 4. Suffice to say that we abandoned trying to use it, despite
> > > > > some assistance from ADI.
> > > >
> > > > Even more interessting, what is your alternative to this chip?
> > >
> > > BCM2711 which supported dual HDMI natively.
> > > Our investigation of ADV7535 was when trying to build what became
> > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
> > > do have the prototype, the ADV was wired up weirdly with I2C so I
> > > never really got it running with Linux.
> >
> > I think I have convinced myself that the DSIM is working good enough to
> > match that of the NXP.
> >
> > I've gone through and made a list of the register differences between a
> > working display using NXP's kernel and the non-working display.  I've
> > identified a small handful of registers on both the CEC bank of
> > registers and main set of registers.
> >
> > I noticed that the working NXP version doesn't rescale the number of
> > lanes based on the clock rate, and it stays fixed at 4 lanes.
>
> Does it mean theoretically rescale of lanes is not required??

On the custom kernel from NXP, I can sync at 720p at 4-lanes.
Unfortunately, I haven't yet been able to replicate all the register
settings between my working version at 720p and my non-working
version, and I still have yet to sync at 720p using the mainline
adv7535 driver.  I am still wrokong on it.

> At least 2 platforms can work with fixed 4 lanes@720p.
>
> and looks like few platforms have display stability issue working with 4 lanes@720p,
> so, as a workaround they changed to 3 lanes based on clock rate to make it work.
>
> Can you please confirm, is my understanding correct?

That is my understanding.

>
> Note:
>  On Renesas RZ/G2L platform, 720p with 3 lanes will work, but it needs
>  different pll parameters to generate the dot clock to work.

The NXP platform I am using also needs to regenerate the clock.  From
what I can tell, it looks like the clock calculation on my board
appears correct for both
>
> Cheers,
> Biju

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Fri, Aug 5, 2022 at 5:55 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Fri, Aug 5, 2022 at 3:44 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> >
> > Hi Adam and all,
> >
> > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> > >
> > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> > > <dave.stevenson@raspberrypi.com> wrote:
> > > >
> > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de>
> > > wrote:
> > > > >
> > > > > Hi Dave,
> > > > >
> > > > > On 22-08-04, Dave Stevenson wrote:
> > > > > > Hi Marco
> > > > > >
> > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch
> > > <m.felsch@pengutronix.de> wrote:
> > > > > > >
> > > > > > > Hi Dave, Adam,
> > > > > > >
> > > > > > > On 22-08-03, Dave Stevenson wrote:
> > > > > > > > Hi Adam
> > > > > > > >
> > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > > > > > Did managed to get access to the ADV7535 programming
> > > > > > > > > > guide? This is the black box here. Let me check if I can
> > > > > > > > > > provide you a link with our repo so you can test our
> > > current DSIM state if you want.
> > > > > > > > >
> > > > > > > > > I do have access to the programming guide, but it's under
> > > > > > > > > NDA, but I'll try to answer questions if I can.
> > > > > > > >
> > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > > > > 7535 from previously looking at these chips.
> > > > > > >
> > > > > > > Thanks for stepping into :)
> > > > > > >
> > > > > > > > Mine fairly plainly states:
> > > > > > > > "The DSI receiver input supports DSI video mode operation
> > > > > > > > only, and specifically, only supports nonburst mode with sync
> > > pulses".
> > > > > > >
> > > > > > > I've read this also, and we are working in nonburst mode with
> > > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore
> > > > > > > I can't verify it.
> > > > > > >
> > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the
> > > > > > > > same as the HDMI pixel rate.
> > > > > > >
> > > > > > > On DSI side you don't have a pixel-clock instead there is bit-
> > > clock.
> > > > > >
> > > > > > You have an effective pixel clock, with a fixed conversion for the
> > > > > > configuration.
> > > > > >
> > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> > > > >
> > > > > Okay, I just checked the bandwidth which must equal.
> > > > >
> > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is
> > > > > > only running at 891 / 2 = 445.5MHz.
> > > > > >
> > > > > > > > Section 6.1.1 "DSI Input Modes" of
> > > > > > > > adv7533_hardware_user_s_guide is even more explicit about the
> > > > > > > > requirement of DSI timing matching
> > > > > > >
> > > > > > > Is it possible to share the key points of the requirements?
> > > > > >
> > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > > > > This mode requires real time data generation as a pulse packet
> > > > > > received becomes a pulse generated. Therefore this mode requires a
> > > > > > continuous stream of data with correct video timing to avoid any
> > > > > > visual artifacts."
> > > > > >
> > > > > > LP mode is supported on data lanes. Clock lane must remain in HS
> > > mode.
> > > > > >
> > > > > > "... the goal is to accurately convey DPI-type timing over DSI.
> > > > > > This includes matching DPI pixel-transmission rates, and widths of
> > > > > > timing events."
> > > > >
> > > > > Thanks for sharing.
> > > > >
> > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > > > > therefore be correct for 720p operation.
> > > > > > >
> > > > > > > It should be absolute no difference if you work on 891MHz with 2
> > > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > > > > you need the minimum required bandwidth which is roughly:
> > > > > > > 1280*720*24*60 = 1.327 GBps.
> > > > > >
> > > > > > Has someone changed the number of lanes in use? I'd missed that if
> > > > > > so, but I'll agree that 891MHz over 2 lanes should work for
> > > 720p60.
> > > > >
> > > > > The ADV driver is changing it autom. but this logic is somehow odd
> > > > > and there was already a approach to stop the driver doing this.
> > > >
> > > > I'd missed that bit in the driver where it appears to drop to 3 lanes
> > > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
> > > > probably the only way it can be achieved in the current framework.
> > > >
> > > > > To sync up: we have two problems:
> > > > >   1) The 720P mode with static DSI host configuration isn't working
> > > > >      without hacks.
> > > > >   2) The DSI link frequency should changed as soon as required
> > > > >      automatically. So we can provide all modes.
> > > > >
> > > > > I would concentrate on problem 1 first before moving on to the 2nd.
> > > >
> > > > If you change your link frequency, it may be worth trying a lower
> > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
> > > > lanes is again listed as mandatory for using the timing generator).

Marco,

Looking through the DSIM driver that NXP uses, it appears that they
have a few special cases where they intentionally manipulate the DSIM
under certain conditions:

/* '1280x720@60Hz' mode with 2 data lanes
* requires special fine tuning for DPHY
* TIMING config according to the tests.
*/

There is also a separate one for the 4-lane mode:

/* workaround for CEA standard mode "1280x720@60" "1920x1080p24"
* display on 4 data lanes with Non-burst with sync
* pulse DSI mode, since use the standard horizontal
* timings cannot display correctly. And this code
* cannot be put into the dsim Bridge's mode_fixup,
* since the DSI device lane number change always
* happens after that.
*/

And lastly, they address issues with 3-lane mode:

/* TODO: DSIM 3 lanes has some display issue, so
* avoid 3 lanes enable, and force data lanes to
* be 2.
*/

Since the ADV is trying to adjust the lanes to 3 when running at 720p,
it could be part of the reason you need to jump to 2-lane mode.

> > > >
> > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as
> > > > > > one of the modes that is mandatory to use the timing generator
> > > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required.
> > > > > > I don't know why it's referencing the 1000/1001 pixel clock rates
> > > > > > and not the base one, as it's only a base clock change with the
> > > > > > same timing (74.176MHz clock instead of 74.25MHz).
> > > > >
> > > > > Interesting! I would like to know how the HDMI block gets fetched by
> > > > > the DSI block and how the timing-generator can influence this in
> > > > > good/bad way. So that we know what DSI settings (freq, lanes) are
> > > sufficient.
> > > > >
> > > > > > > > If you do program the manual DSI divider register to allow a
> > > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz,
> > > > > > > > you'd be relying on
> > > > > > >
> > > > > > > There is no such DSI pixel rate to be precise, we only have a
> > > > > > > DSI bit clock/rate.
> > > > > > >
> > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx
> > > > > > > > and HDMI tx to compensate for the differing data rates. I see
> > > > > > > > no reference to such, and I'd be surprised if it was more than
> > > > > > > > a half dozen pixels to compensate for the jitter in the cases
> > > > > > > > where the internal timing generator is mandatory due to
> > > fractional bytes.
> > > > > > >
> > > > > > > This is interesting and would proofs our assumption that the
> > > > > > > device don't have a FIFO :)
> > > > > > >
> > > > > > > Our assumptions (we don't have the datasheet/programming
> > > manual):
> > > > > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > > > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI
> > > and
> > > > > > >     HDMI are in sync. So from bandwidth pov there are no
> > > differences
> > > > > > >     between:
> > > > > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > > > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock:
> > > 445.5 )
> > > > > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > > 222.75)
> > > > > > >
> > > > > > >     But the ratio is different and therefore the faster clocking
> > > option
> > > > > > >     let something 'overflow'.
> > > > > >
> > > > > > I'll agree that all looks consistent.
> > > > > >
> > > > > > > Anyway, but all this means that Adam should configure the
> > > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this
> > > > > > > doesn't work either and now we are back on my initial statement
> > > > > > > -> the driver needs some attention.
> > > > > >
> > > > > > Things always need attention :-)
> > > > >
> > > > > ^^
> > > > >
> > > > > > I suspect that it's the use of the timing generator that is the
> > > issue.
> > > > > > The programming guide does recommend using it for all modes, so
> > > > > > that would be a sensible first step.
> > > > >
> > > > > But I tested it without the timing-generator too. Can you or Adam
> > > > > verify the timing-generator diable logic?
> > > >
> > > > Sorry, running without the use of the timing generator is the issue.
> > > > It is mandatory in some modes, but supported in all modes. Always
> > > > using it should therefore avoid not using it in one of the mandatory
> > > > modes (the list looks a little arbitrary).
> > > >
> > > > > > I will say that we had a number of issues getting this chip to do
> > > > > > anything, and it generally seemed happier on 2 or 3 lanes instead
> > > > > > of 4. Suffice to say that we abandoned trying to use it, despite
> > > > > > some assistance from ADI.
> > > > >
> > > > > Even more interessting, what is your alternative to this chip?
> > > >
> > > > BCM2711 which supported dual HDMI natively.
> > > > Our investigation of ADV7535 was when trying to build what became
> > > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
> > > > do have the prototype, the ADV was wired up weirdly with I2C so I
> > > > never really got it running with Linux.
> > >
> > > I think I have convinced myself that the DSIM is working good enough to
> > > match that of the NXP.
> > >
> > > I've gone through and made a list of the register differences between a
> > > working display using NXP's kernel and the non-working display.  I've
> > > identified a small handful of registers on both the CEC bank of
> > > registers and main set of registers.
> > >
> > > I noticed that the working NXP version doesn't rescale the number of
> > > lanes based on the clock rate, and it stays fixed at 4 lanes.
> >
> > Does it mean theoretically rescale of lanes is not required??
>
> On the custom kernel from NXP, I can sync at 720p at 4-lanes.
> Unfortunately, I haven't yet been able to replicate all the register
> settings between my working version at 720p and my non-working
> version, and I still have yet to sync at 720p using the mainline
> adv7535 driver.  I am still wrokong on it.
>
> > At least 2 platforms can work with fixed 4 lanes@720p.

Based on what I'm seeing for this NXP platform, it almost seems like
the DSI transmitter should make the determination on whether or not to
scale the number of lanes instead of having the ADV7373 do it.  Since
their custom kernel is able to do 720p in 4-lane mode with this part,
it doesn't seem unreasonable to me.

> >
> > and looks like few platforms have display stability issue working with 4 lanes@720p,
> > so, as a workaround they changed to 3 lanes based on clock rate to make it work.
> >
> > Can you please confirm, is my understanding correct?
>
> That is my understanding.
>
> >
> > Note:
> >  On Renesas RZ/G2L platform, 720p with 3 lanes will work, but it needs
> >  different pll parameters to generate the dot clock to work.
>
> The NXP platform I am using also needs to regenerate the clock.  From
> what I can tell, it looks like the clock calculation on my board
> appears correct for both
> >
> > Cheers,
> > Biju

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Fri, Aug 5, 2022 at 7:56 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Fri, Aug 5, 2022 at 5:55 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Fri, Aug 5, 2022 at 3:44 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > >
> > > Hi Adam and all,
> > >
> > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> > > >
> > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> > > > <dave.stevenson@raspberrypi.com> wrote:
> > > > >
> > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de>
> > > > wrote:
> > > > > >
> > > > > > Hi Dave,
> > > > > >
> > > > > > On 22-08-04, Dave Stevenson wrote:
> > > > > > > Hi Marco
> > > > > > >
> > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch
> > > > <m.felsch@pengutronix.de> wrote:
> > > > > > > >
> > > > > > > > Hi Dave, Adam,
> > > > > > > >
> > > > > > > > On 22-08-03, Dave Stevenson wrote:
> > > > > > > > > Hi Adam
> > > > > > > > >
> > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > ...
> > > > > > > >
> > > > > > > > > > > Did managed to get access to the ADV7535 programming
> > > > > > > > > > > guide? This is the black box here. Let me check if I can
> > > > > > > > > > > provide you a link with our repo so you can test our
> > > > current DSIM state if you want.
> > > > > > > > > >
> > > > > > > > > > I do have access to the programming guide, but it's under
> > > > > > > > > > NDA, but I'll try to answer questions if I can.
> > > > > > > > >
> > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > > > > > 7535 from previously looking at these chips.
> > > > > > > >
> > > > > > > > Thanks for stepping into :)
> > > > > > > >
> > > > > > > > > Mine fairly plainly states:
> > > > > > > > > "The DSI receiver input supports DSI video mode operation
> > > > > > > > > only, and specifically, only supports nonburst mode with sync
> > > > pulses".
> > > > > > > >
> > > > > > > > I've read this also, and we are working in nonburst mode with
> > > > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore
> > > > > > > > I can't verify it.
> > > > > > > >
> > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the
> > > > > > > > > same as the HDMI pixel rate.
> > > > > > > >
> > > > > > > > On DSI side you don't have a pixel-clock instead there is bit-
> > > > clock.
> > > > > > >
> > > > > > > You have an effective pixel clock, with a fixed conversion for the
> > > > > > > configuration.
> > > > > > >
> > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> > > > > >
> > > > > > Okay, I just checked the bandwidth which must equal.
> > > > > >
> > > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is
> > > > > > > only running at 891 / 2 = 445.5MHz.
> > > > > > >
> > > > > > > > > Section 6.1.1 "DSI Input Modes" of
> > > > > > > > > adv7533_hardware_user_s_guide is even more explicit about the
> > > > > > > > > requirement of DSI timing matching
> > > > > > > >
> > > > > > > > Is it possible to share the key points of the requirements?
> > > > > > >
> > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > > > > > This mode requires real time data generation as a pulse packet
> > > > > > > received becomes a pulse generated. Therefore this mode requires a
> > > > > > > continuous stream of data with correct video timing to avoid any
> > > > > > > visual artifacts."
> > > > > > >
> > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS
> > > > mode.
> > > > > > >
> > > > > > > "... the goal is to accurately convey DPI-type timing over DSI.
> > > > > > > This includes matching DPI pixel-transmission rates, and widths of
> > > > > > > timing events."
> > > > > >
> > > > > > Thanks for sharing.
> > > > > >
> > > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > > > > > therefore be correct for 720p operation.
> > > > > > > >
> > > > > > > > It should be absolute no difference if you work on 891MHz with 2
> > > > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > > > > > you need the minimum required bandwidth which is roughly:
> > > > > > > > 1280*720*24*60 = 1.327 GBps.
> > > > > > >
> > > > > > > Has someone changed the number of lanes in use? I'd missed that if
> > > > > > > so, but I'll agree that 891MHz over 2 lanes should work for
> > > > 720p60.
> > > > > >
> > > > > > The ADV driver is changing it autom. but this logic is somehow odd
> > > > > > and there was already a approach to stop the driver doing this.
> > > > >
> > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes
> > > > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
> > > > > probably the only way it can be achieved in the current framework.
> > > > >
> > > > > > To sync up: we have two problems:
> > > > > >   1) The 720P mode with static DSI host configuration isn't working
> > > > > >      without hacks.
> > > > > >   2) The DSI link frequency should changed as soon as required
> > > > > >      automatically. So we can provide all modes.
> > > > > >
> > > > > > I would concentrate on problem 1 first before moving on to the 2nd.
> > > > >
> > > > > If you change your link frequency, it may be worth trying a lower
> > > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
> > > > > lanes is again listed as mandatory for using the timing generator).
>
> Marco,
>
> Looking through the DSIM driver that NXP uses, it appears that they
> have a few special cases where they intentionally manipulate the DSIM
> under certain conditions:
>
> /* '1280x720@60Hz' mode with 2 data lanes
> * requires special fine tuning for DPHY
> * TIMING config according to the tests.
> */
>
> There is also a separate one for the 4-lane mode:
>
> /* workaround for CEA standard mode "1280x720@60" "1920x1080p24"
> * display on 4 data lanes with Non-burst with sync
> * pulse DSI mode, since use the standard horizontal
> * timings cannot display correctly. And this code
> * cannot be put into the dsim Bridge's mode_fixup,
> * since the DSI device lane number change always
> * happens after that.
> */
>
> And lastly, they address issues with 3-lane mode:
>
> /* TODO: DSIM 3 lanes has some display issue, so
> * avoid 3 lanes enable, and force data lanes to
> * be 2.
> */
>
> Since the ADV is trying to adjust the lanes to 3 when running at 720p,
> it could be part of the reason you need to jump to 2-lane mode.
>
> > > > >
> > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as
> > > > > > > one of the modes that is mandatory to use the timing generator
> > > > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required.
> > > > > > > I don't know why it's referencing the 1000/1001 pixel clock rates
> > > > > > > and not the base one, as it's only a base clock change with the
> > > > > > > same timing (74.176MHz clock instead of 74.25MHz).
> > > > > >
> > > > > > Interesting! I would like to know how the HDMI block gets fetched by
> > > > > > the DSI block and how the timing-generator can influence this in
> > > > > > good/bad way. So that we know what DSI settings (freq, lanes) are
> > > > sufficient.
> > > > > >
> > > > > > > > > If you do program the manual DSI divider register to allow a
> > > > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz,
> > > > > > > > > you'd be relying on
> > > > > > > >
> > > > > > > > There is no such DSI pixel rate to be precise, we only have a
> > > > > > > > DSI bit clock/rate.
> > > > > > > >
> > > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx
> > > > > > > > > and HDMI tx to compensate for the differing data rates. I see
> > > > > > > > > no reference to such, and I'd be surprised if it was more than
> > > > > > > > > a half dozen pixels to compensate for the jitter in the cases
> > > > > > > > > where the internal timing generator is mandatory due to
> > > > fractional bytes.
> > > > > > > >
> > > > > > > > This is interesting and would proofs our assumption that the
> > > > > > > > device don't have a FIFO :)
> > > > > > > >
> > > > > > > > Our assumptions (we don't have the datasheet/programming
> > > > manual):
> > > > > > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > > > > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI
> > > > and
> > > > > > > >     HDMI are in sync. So from bandwidth pov there are no
> > > > differences
> > > > > > > >     between:
> > > > > > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > > > > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock:
> > > > 445.5 )
> > > > > > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > > > 222.75)
> > > > > > > >
> > > > > > > >     But the ratio is different and therefore the faster clocking
> > > > option
> > > > > > > >     let something 'overflow'.
> > > > > > >
> > > > > > > I'll agree that all looks consistent.
> > > > > > >
> > > > > > > > Anyway, but all this means that Adam should configure the
> > > > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this
> > > > > > > > doesn't work either and now we are back on my initial statement
> > > > > > > > -> the driver needs some attention.
> > > > > > >
> > > > > > > Things always need attention :-)
> > > > > >
> > > > > > ^^
> > > > > >
> > > > > > > I suspect that it's the use of the timing generator that is the
> > > > issue.
> > > > > > > The programming guide does recommend using it for all modes, so
> > > > > > > that would be a sensible first step.
> > > > > >
> > > > > > But I tested it without the timing-generator too. Can you or Adam
> > > > > > verify the timing-generator diable logic?
> > > > >
> > > > > Sorry, running without the use of the timing generator is the issue.
> > > > > It is mandatory in some modes, but supported in all modes. Always
> > > > > using it should therefore avoid not using it in one of the mandatory
> > > > > modes (the list looks a little arbitrary).

I tested running various modes with the timing generator disable on an
NXP kernel with functional video, and some of the video modes stopped
operating or became blurry.  With the generator on, it appeared to
make the issues go away, so I think it should be left on.

> > > > >
> > > > > > > I will say that we had a number of issues getting this chip to do
> > > > > > > anything, and it generally seemed happier on 2 or 3 lanes instead
> > > > > > > of 4. Suffice to say that we abandoned trying to use it, despite
> > > > > > > some assistance from ADI.
> > > > > >
> > > > > > Even more interessting, what is your alternative to this chip?
> > > > >
> > > > > BCM2711 which supported dual HDMI natively.
> > > > > Our investigation of ADV7535 was when trying to build what became
> > > > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
> > > > > do have the prototype, the ADV was wired up weirdly with I2C so I
> > > > > never really got it running with Linux.
> > > >
> > > > I think I have convinced myself that the DSIM is working good enough to
> > > > match that of the NXP.
> > > >
> > > > I've gone through and made a list of the register differences between a
> > > > working display using NXP's kernel and the non-working display.  I've
> > > > identified a small handful of registers on both the CEC bank of
> > > > registers and main set of registers.
> > > >
> > > > I noticed that the working NXP version doesn't rescale the number of
> > > > lanes based on the clock rate, and it stays fixed at 4 lanes.
> > >
> > > Does it mean theoretically rescale of lanes is not required??
> >
> > On the custom kernel from NXP, I can sync at 720p at 4-lanes.
> > Unfortunately, I haven't yet been able to replicate all the register
> > settings between my working version at 720p and my non-working
> > version, and I still have yet to sync at 720p using the mainline
> > adv7535 driver.  I am still wrokong on it.
> >
> > > At least 2 platforms can work with fixed 4 lanes@720p.
>
> Based on what I'm seeing for this NXP platform, it almost seems like
> the DSI transmitter should make the determination on whether or not to
> scale the number of lanes instead of having the ADV7373 do it.  Since
> their custom kernel is able to do 720p in 4-lane mode with this part,
> it doesn't seem unreasonable to me.

I did a bunch of comparisons between registers for both the ADV7535
and the DSIM, and it appears that the video information is somehow
different between the working NXP kernel and non-working one.

The two main differences are around the values of htotal  hfp.  Both
the DSIM and the ADV7535 are using different values for htotal and the
hfp between the kernels.  I am wondering if there is a bug in the 5.19
driver which is fetching wrong info or somehow the data isn't being
calculated properly because both the DSIM and the ADV timings match
each other, but don't match the working kernel.


720p Working on NXP:

[   24.657957] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 112 ->
hfp_wc = 78
[   24.665284] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
[   24.681496] adv7511_dsi_config_timing_gen: htotal 1652
[   24.691372] adv7511_dsi_config_timing_gen: hfp 112

720p Not working:

[  106.424404] samsung_dsim_set_display_mode: vfp = 5
[  106.429216] samsung_dsim_set_display_mode: bfp = 20
[  106.441777] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 110 ->
hfp_wc = 77
[  106.449221] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
[  106.456314] LCD size = 1280x720
[  106.470115] adv7511_dsi_config_timing_gen: htotal = 1650
[  106.480707] adv7511_dsi_config_timing_gen: hfp = 110

adam
>
> > >
> > > and looks like few platforms have display stability issue working with 4 lanes@720p,
> > > so, as a workaround they changed to 3 lanes based on clock rate to make it work.
> > >
> > > Can you please confirm, is my understanding correct?
> >
> > That is my understanding.
> >
> > >
> > > Note:
> > >  On Renesas RZ/G2L platform, 720p with 3 lanes will work, but it needs
> > >  different pll parameters to generate the dot clock to work.
> >
> > The NXP platform I am using also needs to regenerate the clock.  From
> > what I can tell, it looks like the clock calculation on my board
> > appears correct for both
> > >
> > > Cheers,
> > > Biju

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Fri, Aug 5, 2022 at 4:05 PM Adam Ford <aford173@gmail.com> wrote:
>
> On Fri, Aug 5, 2022 at 7:56 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > >
> > > > Hi Adam and all,
> > > >
> > > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> > > > >
> > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> > > > > <dave.stevenson@raspberrypi.com> wrote:
> > > > > >
> > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de>
> > > > > wrote:
> > > > > > >
> > > > > > > Hi Dave,
> > > > > > >
> > > > > > > On 22-08-04, Dave Stevenson wrote:
> > > > > > > > Hi Marco
> > > > > > > >
> > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch
> > > > > <m.felsch@pengutronix.de> wrote:
> > > > > > > > >
> > > > > > > > > Hi Dave, Adam,
> > > > > > > > >
> > > > > > > > > On 22-08-03, Dave Stevenson wrote:
> > > > > > > > > > Hi Adam
> > > > > > > > > >
> > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > > > > Did managed to get access to the ADV7535 programming
> > > > > > > > > > > > guide? This is the black box here. Let me check if I can
> > > > > > > > > > > > provide you a link with our repo so you can test our
> > > > > current DSIM state if you want.
> > > > > > > > > > >
> > > > > > > > > > > I do have access to the programming guide, but it's under
> > > > > > > > > > > NDA, but I'll try to answer questions if I can.
> > > > > > > > > >
> > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > > > > > > 7535 from previously looking at these chips.
> > > > > > > > >
> > > > > > > > > Thanks for stepping into :)
> > > > > > > > >
> > > > > > > > > > Mine fairly plainly states:
> > > > > > > > > > "The DSI receiver input supports DSI video mode operation
> > > > > > > > > > only, and specifically, only supports nonburst mode with sync
> > > > > pulses".
> > > > > > > > >
> > > > > > > > > I've read this also, and we are working in nonburst mode with
> > > > > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore
> > > > > > > > > I can't verify it.
> > > > > > > > >
> > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the
> > > > > > > > > > same as the HDMI pixel rate.
> > > > > > > > >
> > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit-
> > > > > clock.
> > > > > > > >
> > > > > > > > You have an effective pixel clock, with a fixed conversion for the
> > > > > > > > configuration.
> > > > > > > >
> > > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > > > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> > > > > > >
> > > > > > > Okay, I just checked the bandwidth which must equal.
> > > > > > >
> > > > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is
> > > > > > > > only running at 891 / 2 = 445.5MHz.
> > > > > > > >
> > > > > > > > > > Section 6.1.1 "DSI Input Modes" of
> > > > > > > > > > adv7533_hardware_user_s_guide is even more explicit about the
> > > > > > > > > > requirement of DSI timing matching
> > > > > > > > >
> > > > > > > > > Is it possible to share the key points of the requirements?
> > > > > > > >
> > > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > > > > > > This mode requires real time data generation as a pulse packet
> > > > > > > > received becomes a pulse generated. Therefore this mode requires a
> > > > > > > > continuous stream of data with correct video timing to avoid any
> > > > > > > > visual artifacts."
> > > > > > > >
> > > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS
> > > > > mode.
> > > > > > > >
> > > > > > > > "... the goal is to accurately convey DPI-type timing over DSI.
> > > > > > > > This includes matching DPI pixel-transmission rates, and widths of
> > > > > > > > timing events."
> > > > > > >
> > > > > > > Thanks for sharing.
> > > > > > >
> > > > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > > > > > > therefore be correct for 720p operation.
> > > > > > > > >
> > > > > > > > > It should be absolute no difference if you work on 891MHz with 2
> > > > > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > > > > > > you need the minimum required bandwidth which is roughly:
> > > > > > > > > 1280*720*24*60 = 1.327 GBps.
> > > > > > > >
> > > > > > > > Has someone changed the number of lanes in use? I'd missed that if
> > > > > > > > so, but I'll agree that 891MHz over 2 lanes should work for
> > > > > 720p60.
> > > > > > >
> > > > > > > The ADV driver is changing it autom. but this logic is somehow odd
> > > > > > > and there was already a approach to stop the driver doing this.
> > > > > >
> > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes
> > > > > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
> > > > > > probably the only way it can be achieved in the current framework.
> > > > > >
> > > > > > > To sync up: we have two problems:
> > > > > > >   1) The 720P mode with static DSI host configuration isn't working
> > > > > > >      without hacks.
> > > > > > >   2) The DSI link frequency should changed as soon as required
> > > > > > >      automatically. So we can provide all modes.
> > > > > > >
> > > > > > > I would concentrate on problem 1 first before moving on to the 2nd.
> > > > > >
> > > > > > If you change your link frequency, it may be worth trying a lower
> > > > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
> > > > > > lanes is again listed as mandatory for using the timing generator).
> >
> > Marco,
> >
> > Looking through the DSIM driver that NXP uses, it appears that they
> > have a few special cases where they intentionally manipulate the DSIM
> > under certain conditions:
> >
> > /* '1280x720@60Hz' mode with 2 data lanes
> > * requires special fine tuning for DPHY
> > * TIMING config according to the tests.
> > */
> >
> > There is also a separate one for the 4-lane mode:
> >
> > /* workaround for CEA standard mode "1280x720@60" "1920x1080p24"
> > * display on 4 data lanes with Non-burst with sync
> > * pulse DSI mode, since use the standard horizontal
> > * timings cannot display correctly. And this code
> > * cannot be put into the dsim Bridge's mode_fixup,
> > * since the DSI device lane number change always
> > * happens after that.
> > */
> >
> > And lastly, they address issues with 3-lane mode:
> >
> > /* TODO: DSIM 3 lanes has some display issue, so
> > * avoid 3 lanes enable, and force data lanes to
> > * be 2.
> > */
> >
> > Since the ADV is trying to adjust the lanes to 3 when running at 720p,
> > it could be part of the reason you need to jump to 2-lane mode.
> >
> > > > > >
> > > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as
> > > > > > > > one of the modes that is mandatory to use the timing generator
> > > > > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required.
> > > > > > > > I don't know why it's referencing the 1000/1001 pixel clock rates
> > > > > > > > and not the base one, as it's only a base clock change with the
> > > > > > > > same timing (74.176MHz clock instead of 74.25MHz).
> > > > > > >
> > > > > > > Interesting! I would like to know how the HDMI block gets fetched by
> > > > > > > the DSI block and how the timing-generator can influence this in
> > > > > > > good/bad way. So that we know what DSI settings (freq, lanes) are
> > > > > sufficient.
> > > > > > >
> > > > > > > > > > If you do program the manual DSI divider register to allow a
> > > > > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz,
> > > > > > > > > > you'd be relying on
> > > > > > > > >
> > > > > > > > > There is no such DSI pixel rate to be precise, we only have a
> > > > > > > > > DSI bit clock/rate.
> > > > > > > > >
> > > > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx
> > > > > > > > > > and HDMI tx to compensate for the differing data rates. I see
> > > > > > > > > > no reference to such, and I'd be surprised if it was more than
> > > > > > > > > > a half dozen pixels to compensate for the jitter in the cases
> > > > > > > > > > where the internal timing generator is mandatory due to
> > > > > fractional bytes.
> > > > > > > > >
> > > > > > > > > This is interesting and would proofs our assumption that the
> > > > > > > > > device don't have a FIFO :)
> > > > > > > > >
> > > > > > > > > Our assumptions (we don't have the datasheet/programming
> > > > > manual):
> > > > > > > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > > > > > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI
> > > > > and
> > > > > > > > >     HDMI are in sync. So from bandwidth pov there are no
> > > > > differences
> > > > > > > > >     between:
> > > > > > > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > > > > > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > 445.5 )
> > > > > > > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > > > > 222.75)
> > > > > > > > >
> > > > > > > > >     But the ratio is different and therefore the faster clocking
> > > > > option
> > > > > > > > >     let something 'overflow'.
> > > > > > > >
> > > > > > > > I'll agree that all looks consistent.
> > > > > > > >
> > > > > > > > > Anyway, but all this means that Adam should configure the
> > > > > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this
> > > > > > > > > doesn't work either and now we are back on my initial statement
> > > > > > > > > -> the driver needs some attention.
> > > > > > > >
> > > > > > > > Things always need attention :-)
> > > > > > >
> > > > > > > ^^
> > > > > > >
> > > > > > > > I suspect that it's the use of the timing generator that is the
> > > > > issue.
> > > > > > > > The programming guide does recommend using it for all modes, so
> > > > > > > > that would be a sensible first step.
> > > > > > >
> > > > > > > But I tested it without the timing-generator too. Can you or Adam
> > > > > > > verify the timing-generator diable logic?
> > > > > >
> > > > > > Sorry, running without the use of the timing generator is the issue.
> > > > > > It is mandatory in some modes, but supported in all modes. Always
> > > > > > using it should therefore avoid not using it in one of the mandatory
> > > > > > modes (the list looks a little arbitrary).
>
> I tested running various modes with the timing generator disable on an
> NXP kernel with functional video, and some of the video modes stopped
> operating or became blurry.  With the generator on, it appeared to
> make the issues go away, so I think it should be left on.
>
> > > > > >
> > > > > > > > I will say that we had a number of issues getting this chip to do
> > > > > > > > anything, and it generally seemed happier on 2 or 3 lanes instead
> > > > > > > > of 4. Suffice to say that we abandoned trying to use it, despite
> > > > > > > > some assistance from ADI.
> > > > > > >
> > > > > > > Even more interessting, what is your alternative to this chip?
> > > > > >
> > > > > > BCM2711 which supported dual HDMI natively.
> > > > > > Our investigation of ADV7535 was when trying to build what became
> > > > > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
> > > > > > do have the prototype, the ADV was wired up weirdly with I2C so I
> > > > > > never really got it running with Linux.
> > > > >
> > > > > I think I have convinced myself that the DSIM is working good enough to
> > > > > match that of the NXP.
> > > > >
> > > > > I've gone through and made a list of the register differences between a
> > > > > working display using NXP's kernel and the non-working display.  I've
> > > > > identified a small handful of registers on both the CEC bank of
> > > > > registers and main set of registers.
> > > > >
> > > > > I noticed that the working NXP version doesn't rescale the number of
> > > > > lanes based on the clock rate, and it stays fixed at 4 lanes.
> > > >
> > > > Does it mean theoretically rescale of lanes is not required??
> > >
> > > On the custom kernel from NXP, I can sync at 720p at 4-lanes.
> > > Unfortunately, I haven't yet been able to replicate all the register
> > > settings between my working version at 720p and my non-working
> > > version, and I still have yet to sync at 720p using the mainline
> > > adv7535 driver.  I am still wrokong on it.
> > >
> > > > At least 2 platforms can work with fixed 4 lanes@720p.
> >
> > Based on what I'm seeing for this NXP platform, it almost seems like
> > the DSI transmitter should make the determination on whether or not to
> > scale the number of lanes instead of having the ADV7373 do it.  Since
> > their custom kernel is able to do 720p in 4-lane mode with this part,
> > it doesn't seem unreasonable to me.
>
> I did a bunch of comparisons between registers for both the ADV7535
> and the DSIM, and it appears that the video information is somehow
> different between the working NXP kernel and non-working one.
>
> The two main differences are around the values of htotal  hfp.  Both
> the DSIM and the ADV7535 are using different values for htotal and the
> hfp between the kernels.  I am wondering if there is a bug in the 5.19
> driver which is fetching wrong info or somehow the data isn't being
> calculated properly because both the DSIM and the ADV timings match
> each other, but don't match the working kernel.
>
>
> 720p Working on NXP:
>
> [   24.657957] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 112 ->
> hfp_wc = 78
> [   24.665284] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
> [   24.681496] adv7511_dsi_config_timing_gen: htotal 1652
> [   24.691372] adv7511_dsi_config_timing_gen: hfp 112
>
> 720p Not working:
>
> [  106.424404] samsung_dsim_set_display_mode: vfp = 5
> [  106.429216] samsung_dsim_set_display_mode: bfp = 20
> [  106.441777] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 110 ->
> hfp_wc = 77
> [  106.449221] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
> [  106.456314] LCD size = 1280x720
> [  106.470115] adv7511_dsi_config_timing_gen: htotal = 1650
> [  106.480707] adv7511_dsi_config_timing_gen: hfp = 110
>

After spending more time than I care to admit, I think I have a
working solution to the DSIM + ADV7535, but the vast majority of the
changes I had to do were revolving around samsung_dsim_set_phy_ctrl.
I have an LVDS bridge based on the ti,sn65dsi83.  With some
suggestions from Marek V, I replaced the fixed-clock solution with a
dynamic one based on the attached bridge's requested clocks.

With those changes, I have the following resolutions working on the
ADV7535 (with almost no chages to the ADV code) ane one that's nearly
working:

Working:

1080p@60
1080p@50
720p@50
800x600-75
720x576

Partially Working:
720p@60 (hsync appears off, rounding error?)

This driver appears to be using a fixed frequency and the
corresponding fixed frequency in the DPHY settings. If the clock
changes, the samsung_dsim_set_phy_ctrl needs to adjust accordingly.
NXP lists a 2-lane operation mode for 720 as needing some additional
adjustments because the calculations don't quite line up, but due to
the other changes I made, I didn't investigate 2-lane very much.

In order to switch resolutions, I had to lock the adv7535 in 4-lane
mode with a minor patch to the adv driver, because the DSIM doesn't
appear to operate in 3-lane mode (like the adv7511 wants to do) and
the DSIM seemed to be unhappy about the connections and
disconnections.  I also made some changes to the PMS calibration for
the PLL which allowed me to lower the phy clock a bit.

The rest of the changes I did were attempting to port the dsim dphy
frequency tables from NXP's kernel.  If anyone from NXP or Samsung has
the formula for how to determine some of the values for the DPHY, I'd
like to replace the look-up table [1] with a formula.

Once I have my code changes cleaned up, I'll push them to a github and
share the info.

[1] - https://source.codeaurora.org/external/imx/linux-imx/tree/include/drm/bridge/sec_mipi_dsim.h?h=lf-5.15.y

adam
> adam
> >
> > > >
> > > > and looks like few platforms have display stability issue working with 4 lanes@720p,
> > > > so, as a workaround they changed to 3 lanes based on clock rate to make it work.
> > > >
> > > > Can you please confirm, is my understanding correct?
> > >
> > > That is my understanding.
> > >
> > > >
> > > > Note:
> > > >  On Renesas RZ/G2L platform, 720p with 3 lanes will work, but it needs
> > > >  different pll parameters to generate the dot clock to work.
> > >
> > > The NXP platform I am using also needs to regenerate the clock.  From
> > > what I can tell, it looks like the clock calculation on my board
> > > appears correct for both
> > > >
> > > > Cheers,
> > > > Biju

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

On 22-08-07, Adam Ford wrote:
> On Fri, Aug 5, 2022 at 4:05 PM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Fri, Aug 5, 2022 at 7:56 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > > >
> > > > > Hi Adam and all,
> > > > >
> > > > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> > > > > >
> > > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> > > > > > <dave.stevenson@raspberrypi.com> wrote:
> > > > > > >
> > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Dave,
> > > > > > > >
> > > > > > > > On 22-08-04, Dave Stevenson wrote:
> > > > > > > > > Hi Marco
> > > > > > > > >
> > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch
> > > > > > <m.felsch@pengutronix.de> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Dave, Adam,
> > > > > > > > > >
> > > > > > > > > > On 22-08-03, Dave Stevenson wrote:
> > > > > > > > > > > Hi Adam
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com>
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > > > > > Did managed to get access to the ADV7535 programming
> > > > > > > > > > > > > guide? This is the black box here. Let me check if I can
> > > > > > > > > > > > > provide you a link with our repo so you can test our
> > > > > > current DSIM state if you want.
> > > > > > > > > > > >
> > > > > > > > > > > > I do have access to the programming guide, but it's under
> > > > > > > > > > > > NDA, but I'll try to answer questions if I can.
> > > > > > > > > > >
> > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > > > > > > > 7535 from previously looking at these chips.
> > > > > > > > > >
> > > > > > > > > > Thanks for stepping into :)
> > > > > > > > > >
> > > > > > > > > > > Mine fairly plainly states:
> > > > > > > > > > > "The DSI receiver input supports DSI video mode operation
> > > > > > > > > > > only, and specifically, only supports nonburst mode with sync
> > > > > > pulses".
> > > > > > > > > >
> > > > > > > > > > I've read this also, and we are working in nonburst mode with
> > > > > > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore
> > > > > > > > > > I can't verify it.
> > > > > > > > > >
> > > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the
> > > > > > > > > > > same as the HDMI pixel rate.
> > > > > > > > > >
> > > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit-
> > > > > > clock.
> > > > > > > > >
> > > > > > > > > You have an effective pixel clock, with a fixed conversion for the
> > > > > > > > > configuration.
> > > > > > > > >
> > > > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > > > > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> > > > > > > >
> > > > > > > > Okay, I just checked the bandwidth which must equal.
> > > > > > > >
> > > > > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is
> > > > > > > > > only running at 891 / 2 = 445.5MHz.
> > > > > > > > >
> > > > > > > > > > > Section 6.1.1 "DSI Input Modes" of
> > > > > > > > > > > adv7533_hardware_user_s_guide is even more explicit about the
> > > > > > > > > > > requirement of DSI timing matching
> > > > > > > > > >
> > > > > > > > > > Is it possible to share the key points of the requirements?
> > > > > > > > >
> > > > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > > > > > > > This mode requires real time data generation as a pulse packet
> > > > > > > > > received becomes a pulse generated. Therefore this mode requires a
> > > > > > > > > continuous stream of data with correct video timing to avoid any
> > > > > > > > > visual artifacts."
> > > > > > > > >
> > > > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS
> > > > > > mode.
> > > > > > > > >
> > > > > > > > > "... the goal is to accurately convey DPI-type timing over DSI.
> > > > > > > > > This includes matching DPI pixel-transmission rates, and widths of
> > > > > > > > > timing events."
> > > > > > > >
> > > > > > > > Thanks for sharing.
> > > > > > > >
> > > > > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > > > > > > > therefore be correct for 720p operation.
> > > > > > > > > >
> > > > > > > > > > It should be absolute no difference if you work on 891MHz with 2
> > > > > > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > > > > > > > you need the minimum required bandwidth which is roughly:
> > > > > > > > > > 1280*720*24*60 = 1.327 GBps.
> > > > > > > > >
> > > > > > > > > Has someone changed the number of lanes in use? I'd missed that if
> > > > > > > > > so, but I'll agree that 891MHz over 2 lanes should work for
> > > > > > 720p60.
> > > > > > > >
> > > > > > > > The ADV driver is changing it autom. but this logic is somehow odd
> > > > > > > > and there was already a approach to stop the driver doing this.
> > > > > > >
> > > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes
> > > > > > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
> > > > > > > probably the only way it can be achieved in the current framework.
> > > > > > >
> > > > > > > > To sync up: we have two problems:
> > > > > > > >   1) The 720P mode with static DSI host configuration isn't working
> > > > > > > >      without hacks.
> > > > > > > >   2) The DSI link frequency should changed as soon as required
> > > > > > > >      automatically. So we can provide all modes.
> > > > > > > >
> > > > > > > > I would concentrate on problem 1 first before moving on to the 2nd.
> > > > > > >
> > > > > > > If you change your link frequency, it may be worth trying a lower
> > > > > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
> > > > > > > lanes is again listed as mandatory for using the timing generator).
> > >
> > > Marco,
> > >
> > > Looking through the DSIM driver that NXP uses, it appears that they
> > > have a few special cases where they intentionally manipulate the DSIM
> > > under certain conditions:
> > >
> > > /* '1280x720@60Hz' mode with 2 data lanes
> > > * requires special fine tuning for DPHY
> > > * TIMING config according to the tests.
> > > */
> > >
> > > There is also a separate one for the 4-lane mode:
> > >
> > > /* workaround for CEA standard mode "1280x720@60" "1920x1080p24"
> > > * display on 4 data lanes with Non-burst with sync
> > > * pulse DSI mode, since use the standard horizontal
> > > * timings cannot display correctly. And this code
> > > * cannot be put into the dsim Bridge's mode_fixup,
> > > * since the DSI device lane number change always
> > > * happens after that.
> > > */
> > >
> > > And lastly, they address issues with 3-lane mode:
> > >
> > > /* TODO: DSIM 3 lanes has some display issue, so
> > > * avoid 3 lanes enable, and force data lanes to
> > > * be 2.
> > > */
> > >
> > > Since the ADV is trying to adjust the lanes to 3 when running at 720p,
> > > it could be part of the reason you need to jump to 2-lane mode.
> > >
> > > > > > >
> > > > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as
> > > > > > > > > one of the modes that is mandatory to use the timing generator
> > > > > > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required.
> > > > > > > > > I don't know why it's referencing the 1000/1001 pixel clock rates
> > > > > > > > > and not the base one, as it's only a base clock change with the
> > > > > > > > > same timing (74.176MHz clock instead of 74.25MHz).
> > > > > > > >
> > > > > > > > Interesting! I would like to know how the HDMI block gets fetched by
> > > > > > > > the DSI block and how the timing-generator can influence this in
> > > > > > > > good/bad way. So that we know what DSI settings (freq, lanes) are
> > > > > > sufficient.
> > > > > > > >
> > > > > > > > > > > If you do program the manual DSI divider register to allow a
> > > > > > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz,
> > > > > > > > > > > you'd be relying on
> > > > > > > > > >
> > > > > > > > > > There is no such DSI pixel rate to be precise, we only have a
> > > > > > > > > > DSI bit clock/rate.
> > > > > > > > > >
> > > > > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx
> > > > > > > > > > > and HDMI tx to compensate for the differing data rates. I see
> > > > > > > > > > > no reference to such, and I'd be surprised if it was more than
> > > > > > > > > > > a half dozen pixels to compensate for the jitter in the cases
> > > > > > > > > > > where the internal timing generator is mandatory due to
> > > > > > fractional bytes.
> > > > > > > > > >
> > > > > > > > > > This is interesting and would proofs our assumption that the
> > > > > > > > > > device don't have a FIFO :)
> > > > > > > > > >
> > > > > > > > > > Our assumptions (we don't have the datasheet/programming
> > > > > > manual):
> > > > > > > > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > > > > > > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI
> > > > > > and
> > > > > > > > > >     HDMI are in sync. So from bandwidth pov there are no
> > > > > > differences
> > > > > > > > > >     between:
> > > > > > > > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > > > > > > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > 445.5 )
> > > > > > > > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > > > > > 222.75)
> > > > > > > > > >
> > > > > > > > > >     But the ratio is different and therefore the faster clocking
> > > > > > option
> > > > > > > > > >     let something 'overflow'.
> > > > > > > > >
> > > > > > > > > I'll agree that all looks consistent.
> > > > > > > > >
> > > > > > > > > > Anyway, but all this means that Adam should configure the
> > > > > > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this
> > > > > > > > > > doesn't work either and now we are back on my initial statement
> > > > > > > > > > -> the driver needs some attention.
> > > > > > > > >
> > > > > > > > > Things always need attention :-)
> > > > > > > >
> > > > > > > > ^^
> > > > > > > >
> > > > > > > > > I suspect that it's the use of the timing generator that is the
> > > > > > issue.
> > > > > > > > > The programming guide does recommend using it for all modes, so
> > > > > > > > > that would be a sensible first step.
> > > > > > > >
> > > > > > > > But I tested it without the timing-generator too. Can you or Adam
> > > > > > > > verify the timing-generator diable logic?
> > > > > > >
> > > > > > > Sorry, running without the use of the timing generator is the issue.
> > > > > > > It is mandatory in some modes, but supported in all modes. Always
> > > > > > > using it should therefore avoid not using it in one of the mandatory
> > > > > > > modes (the list looks a little arbitrary).
> >
> > I tested running various modes with the timing generator disable on an
> > NXP kernel with functional video, and some of the video modes stopped
> > operating or became blurry.  With the generator on, it appeared to
> > make the issues go away, so I think it should be left on.
> >
> > > > > > >
> > > > > > > > > I will say that we had a number of issues getting this chip to do
> > > > > > > > > anything, and it generally seemed happier on 2 or 3 lanes instead
> > > > > > > > > of 4. Suffice to say that we abandoned trying to use it, despite
> > > > > > > > > some assistance from ADI.
> > > > > > > >
> > > > > > > > Even more interessting, what is your alternative to this chip?
> > > > > > >
> > > > > > > BCM2711 which supported dual HDMI natively.
> > > > > > > Our investigation of ADV7535 was when trying to build what became
> > > > > > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
> > > > > > > do have the prototype, the ADV was wired up weirdly with I2C so I
> > > > > > > never really got it running with Linux.
> > > > > >
> > > > > > I think I have convinced myself that the DSIM is working good enough to
> > > > > > match that of the NXP.
> > > > > >
> > > > > > I've gone through and made a list of the register differences between a
> > > > > > working display using NXP's kernel and the non-working display.  I've
> > > > > > identified a small handful of registers on both the CEC bank of
> > > > > > registers and main set of registers.
> > > > > >
> > > > > > I noticed that the working NXP version doesn't rescale the number of
> > > > > > lanes based on the clock rate, and it stays fixed at 4 lanes.
> > > > >
> > > > > Does it mean theoretically rescale of lanes is not required??
> > > >
> > > > On the custom kernel from NXP, I can sync at 720p at 4-lanes.
> > > > Unfortunately, I haven't yet been able to replicate all the register
> > > > settings between my working version at 720p and my non-working
> > > > version, and I still have yet to sync at 720p using the mainline
> > > > adv7535 driver.  I am still wrokong on it.
> > > >
> > > > > At least 2 platforms can work with fixed 4 lanes@720p.
> > >
> > > Based on what I'm seeing for this NXP platform, it almost seems like
> > > the DSI transmitter should make the determination on whether or not to
> > > scale the number of lanes instead of having the ADV7373 do it.  Since
> > > their custom kernel is able to do 720p in 4-lane mode with this part,
> > > it doesn't seem unreasonable to me.
> >
> > I did a bunch of comparisons between registers for both the ADV7535
> > and the DSIM, and it appears that the video information is somehow
> > different between the working NXP kernel and non-working one.
> >
> > The two main differences are around the values of htotal  hfp.  Both
> > the DSIM and the ADV7535 are using different values for htotal and the
> > hfp between the kernels.  I am wondering if there is a bug in the 5.19
> > driver which is fetching wrong info or somehow the data isn't being
> > calculated properly because both the DSIM and the ADV timings match
> > each other, but don't match the working kernel.
> >
> >
> > 720p Working on NXP:
> >
> > [   24.657957] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 112 ->
> > hfp_wc = 78
> > [   24.665284] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
> > [   24.681496] adv7511_dsi_config_timing_gen: htotal 1652
> > [   24.691372] adv7511_dsi_config_timing_gen: hfp 112
> >
> > 720p Not working:
> >
> > [  106.424404] samsung_dsim_set_display_mode: vfp = 5
> > [  106.429216] samsung_dsim_set_display_mode: bfp = 20
> > [  106.441777] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 110 ->
> > hfp_wc = 77
> > [  106.449221] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
> > [  106.456314] LCD size = 1280x720
> > [  106.470115] adv7511_dsi_config_timing_gen: htotal = 1650
> > [  106.480707] adv7511_dsi_config_timing_gen: hfp = 110
> >
> 
> After spending more time than I care to admit, I think I have a
> working solution to the DSIM + ADV7535, but the vast majority of the
> changes I had to do were revolving around samsung_dsim_set_phy_ctrl.
> I have an LVDS bridge based on the ti,sn65dsi83.  With some
> suggestions from Marek V, I replaced the fixed-clock solution with a
> dynamic one based on the attached bridge's requested clocks.
> 
> With those changes, I have the following resolutions working on the
> ADV7535 (with almost no chages to the ADV code) ane one that's nearly
> working:
> 
> Working:
> 
> 1080p@60
> 1080p@50
> 720p@50
> 800x600-75
> 720x576
> 
> Partially Working:
> 720p@60 (hsync appears off, rounding error?)
> 
> This driver appears to be using a fixed frequency and the
> corresponding fixed frequency in the DPHY settings. If the clock
> changes, the samsung_dsim_set_phy_ctrl needs to adjust accordingly.
> NXP lists a 2-lane operation mode for 720 as needing some additional
> adjustments because the calculations don't quite line up, but due to
> the other changes I made, I didn't investigate 2-lane very much.
> 
> In order to switch resolutions, I had to lock the adv7535 in 4-lane
> mode with a minor patch to the adv driver, because the DSIM doesn't
> appear to operate in 3-lane mode (like the adv7511 wants to do) and
> the DSIM seemed to be unhappy about the connections and
> disconnections.  I also made some changes to the PMS calibration for
> the PLL which allowed me to lower the phy clock a bit.
> 
> The rest of the changes I did were attempting to port the dsim dphy
> frequency tables from NXP's kernel.  If anyone from NXP or Samsung has
> the formula for how to determine some of the values for the DPHY, I'd
> like to replace the look-up table [1] with a formula.
> 
> Once I have my code changes cleaned up, I'll push them to a github and
> share the info.
> 
> [1] - https://source.codeaurora.org/external/imx/linux-imx/tree/include/drm/bridge/sec_mipi_dsim.h?h=lf-5.15.y

Hi Adam,

thanks for your work and sharing. Did you tested our current solution
since we think that we understood the DSIM porches? As I said in the
very beginning of this discussion, NXP took some porch values we really
don't understand and I don't think they do either. NXP tweaked the
values somehow so the chip is producing at least the most wanted
resolutions.

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Mon, Aug 8, 2022 at 3:54 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> On 22-08-07, Adam Ford wrote:
> > On Fri, Aug 5, 2022 at 4:05 PM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Fri, Aug 5, 2022 at 7:56 AM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > > > >
> > > > > > Hi Adam and all,
> > > > > >
> > > > > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> > > > > > >
> > > > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> > > > > > > <dave.stevenson@raspberrypi.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Dave,
> > > > > > > > >
> > > > > > > > > On 22-08-04, Dave Stevenson wrote:
> > > > > > > > > > Hi Marco
> > > > > > > > > >
> > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch
> > > > > > > <m.felsch@pengutronix.de> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Dave, Adam,
> > > > > > > > > > >
> > > > > > > > > > > On 22-08-03, Dave Stevenson wrote:
> > > > > > > > > > > > Hi Adam
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com>
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > ...
> > > > > > > > > > >
> > > > > > > > > > > > > > Did managed to get access to the ADV7535 programming
> > > > > > > > > > > > > > guide? This is the black box here. Let me check if I can
> > > > > > > > > > > > > > provide you a link with our repo so you can test our
> > > > > > > current DSIM state if you want.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I do have access to the programming guide, but it's under
> > > > > > > > > > > > > NDA, but I'll try to answer questions if I can.
> > > > > > > > > > > >
> > > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > > > > > > > > 7535 from previously looking at these chips.
> > > > > > > > > > >
> > > > > > > > > > > Thanks for stepping into :)
> > > > > > > > > > >
> > > > > > > > > > > > Mine fairly plainly states:
> > > > > > > > > > > > "The DSI receiver input supports DSI video mode operation
> > > > > > > > > > > > only, and specifically, only supports nonburst mode with sync
> > > > > > > pulses".
> > > > > > > > > > >
> > > > > > > > > > > I've read this also, and we are working in nonburst mode with
> > > > > > > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore
> > > > > > > > > > > I can't verify it.
> > > > > > > > > > >
> > > > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the
> > > > > > > > > > > > same as the HDMI pixel rate.
> > > > > > > > > > >
> > > > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit-
> > > > > > > clock.
> > > > > > > > > >
> > > > > > > > > > You have an effective pixel clock, with a fixed conversion for the
> > > > > > > > > > configuration.
> > > > > > > > > >
> > > > > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > > > > > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> > > > > > > > >
> > > > > > > > > Okay, I just checked the bandwidth which must equal.
> > > > > > > > >
> > > > > > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is
> > > > > > > > > > only running at 891 / 2 = 445.5MHz.
> > > > > > > > > >
> > > > > > > > > > > > Section 6.1.1 "DSI Input Modes" of
> > > > > > > > > > > > adv7533_hardware_user_s_guide is even more explicit about the
> > > > > > > > > > > > requirement of DSI timing matching
> > > > > > > > > > >
> > > > > > > > > > > Is it possible to share the key points of the requirements?
> > > > > > > > > >
> > > > > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > > > > > > > > This mode requires real time data generation as a pulse packet
> > > > > > > > > > received becomes a pulse generated. Therefore this mode requires a
> > > > > > > > > > continuous stream of data with correct video timing to avoid any
> > > > > > > > > > visual artifacts."
> > > > > > > > > >
> > > > > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS
> > > > > > > mode.
> > > > > > > > > >
> > > > > > > > > > "... the goal is to accurately convey DPI-type timing over DSI.
> > > > > > > > > > This includes matching DPI pixel-transmission rates, and widths of
> > > > > > > > > > timing events."
> > > > > > > > >
> > > > > > > > > Thanks for sharing.
> > > > > > > > >
> > > > > > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > > > > > > > > therefore be correct for 720p operation.
> > > > > > > > > > >
> > > > > > > > > > > It should be absolute no difference if you work on 891MHz with 2
> > > > > > > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > > > > > > > > you need the minimum required bandwidth which is roughly:
> > > > > > > > > > > 1280*720*24*60 = 1.327 GBps.
> > > > > > > > > >
> > > > > > > > > > Has someone changed the number of lanes in use? I'd missed that if
> > > > > > > > > > so, but I'll agree that 891MHz over 2 lanes should work for
> > > > > > > 720p60.
> > > > > > > > >
> > > > > > > > > The ADV driver is changing it autom. but this logic is somehow odd
> > > > > > > > > and there was already a approach to stop the driver doing this.
> > > > > > > >
> > > > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes
> > > > > > > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
> > > > > > > > probably the only way it can be achieved in the current framework.
> > > > > > > >
> > > > > > > > > To sync up: we have two problems:
> > > > > > > > >   1) The 720P mode with static DSI host configuration isn't working
> > > > > > > > >      without hacks.
> > > > > > > > >   2) The DSI link frequency should changed as soon as required
> > > > > > > > >      automatically. So we can provide all modes.
> > > > > > > > >
> > > > > > > > > I would concentrate on problem 1 first before moving on to the 2nd.
> > > > > > > >
> > > > > > > > If you change your link frequency, it may be worth trying a lower
> > > > > > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
> > > > > > > > lanes is again listed as mandatory for using the timing generator).
> > > >
> > > > Marco,
> > > >
> > > > Looking through the DSIM driver that NXP uses, it appears that they
> > > > have a few special cases where they intentionally manipulate the DSIM
> > > > under certain conditions:
> > > >
> > > > /* '1280x720@60Hz' mode with 2 data lanes
> > > > * requires special fine tuning for DPHY
> > > > * TIMING config according to the tests.
> > > > */
> > > >
> > > > There is also a separate one for the 4-lane mode:
> > > >
> > > > /* workaround for CEA standard mode "1280x720@60" "1920x1080p24"
> > > > * display on 4 data lanes with Non-burst with sync
> > > > * pulse DSI mode, since use the standard horizontal
> > > > * timings cannot display correctly. And this code
> > > > * cannot be put into the dsim Bridge's mode_fixup,
> > > > * since the DSI device lane number change always
> > > > * happens after that.
> > > > */
> > > >
> > > > And lastly, they address issues with 3-lane mode:
> > > >
> > > > /* TODO: DSIM 3 lanes has some display issue, so
> > > > * avoid 3 lanes enable, and force data lanes to
> > > > * be 2.
> > > > */
> > > >
> > > > Since the ADV is trying to adjust the lanes to 3 when running at 720p,
> > > > it could be part of the reason you need to jump to 2-lane mode.
> > > >
> > > > > > > >
> > > > > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as
> > > > > > > > > > one of the modes that is mandatory to use the timing generator
> > > > > > > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required.
> > > > > > > > > > I don't know why it's referencing the 1000/1001 pixel clock rates
> > > > > > > > > > and not the base one, as it's only a base clock change with the
> > > > > > > > > > same timing (74.176MHz clock instead of 74.25MHz).
> > > > > > > > >
> > > > > > > > > Interesting! I would like to know how the HDMI block gets fetched by
> > > > > > > > > the DSI block and how the timing-generator can influence this in
> > > > > > > > > good/bad way. So that we know what DSI settings (freq, lanes) are
> > > > > > > sufficient.
> > > > > > > > >
> > > > > > > > > > > > If you do program the manual DSI divider register to allow a
> > > > > > > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz,
> > > > > > > > > > > > you'd be relying on
> > > > > > > > > > >
> > > > > > > > > > > There is no such DSI pixel rate to be precise, we only have a
> > > > > > > > > > > DSI bit clock/rate.
> > > > > > > > > > >
> > > > > > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx
> > > > > > > > > > > > and HDMI tx to compensate for the differing data rates. I see
> > > > > > > > > > > > no reference to such, and I'd be surprised if it was more than
> > > > > > > > > > > > a half dozen pixels to compensate for the jitter in the cases
> > > > > > > > > > > > where the internal timing generator is mandatory due to
> > > > > > > fractional bytes.
> > > > > > > > > > >
> > > > > > > > > > > This is interesting and would proofs our assumption that the
> > > > > > > > > > > device don't have a FIFO :)
> > > > > > > > > > >
> > > > > > > > > > > Our assumptions (we don't have the datasheet/programming
> > > > > > > manual):
> > > > > > > > > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > > > > > > > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI
> > > > > > > and
> > > > > > > > > > >     HDMI are in sync. So from bandwidth pov there are no
> > > > > > > differences
> > > > > > > > > > >     between:
> > > > > > > > > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > > > > > > > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > > 445.5 )
> > > > > > > > > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > > > > > > 222.75)
> > > > > > > > > > >
> > > > > > > > > > >     But the ratio is different and therefore the faster clocking
> > > > > > > option
> > > > > > > > > > >     let something 'overflow'.
> > > > > > > > > >
> > > > > > > > > > I'll agree that all looks consistent.
> > > > > > > > > >
> > > > > > > > > > > Anyway, but all this means that Adam should configure the
> > > > > > > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this
> > > > > > > > > > > doesn't work either and now we are back on my initial statement
> > > > > > > > > > > -> the driver needs some attention.
> > > > > > > > > >
> > > > > > > > > > Things always need attention :-)
> > > > > > > > >
> > > > > > > > > ^^
> > > > > > > > >
> > > > > > > > > > I suspect that it's the use of the timing generator that is the
> > > > > > > issue.
> > > > > > > > > > The programming guide does recommend using it for all modes, so
> > > > > > > > > > that would be a sensible first step.
> > > > > > > > >
> > > > > > > > > But I tested it without the timing-generator too. Can you or Adam
> > > > > > > > > verify the timing-generator diable logic?
> > > > > > > >
> > > > > > > > Sorry, running without the use of the timing generator is the issue.
> > > > > > > > It is mandatory in some modes, but supported in all modes. Always
> > > > > > > > using it should therefore avoid not using it in one of the mandatory
> > > > > > > > modes (the list looks a little arbitrary).
> > >
> > > I tested running various modes with the timing generator disable on an
> > > NXP kernel with functional video, and some of the video modes stopped
> > > operating or became blurry.  With the generator on, it appeared to
> > > make the issues go away, so I think it should be left on.
> > >
> > > > > > > >
> > > > > > > > > > I will say that we had a number of issues getting this chip to do
> > > > > > > > > > anything, and it generally seemed happier on 2 or 3 lanes instead
> > > > > > > > > > of 4. Suffice to say that we abandoned trying to use it, despite
> > > > > > > > > > some assistance from ADI.
> > > > > > > > >
> > > > > > > > > Even more interessting, what is your alternative to this chip?
> > > > > > > >
> > > > > > > > BCM2711 which supported dual HDMI natively.
> > > > > > > > Our investigation of ADV7535 was when trying to build what became
> > > > > > > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
> > > > > > > > do have the prototype, the ADV was wired up weirdly with I2C so I
> > > > > > > > never really got it running with Linux.
> > > > > > >
> > > > > > > I think I have convinced myself that the DSIM is working good enough to
> > > > > > > match that of the NXP.
> > > > > > >
> > > > > > > I've gone through and made a list of the register differences between a
> > > > > > > working display using NXP's kernel and the non-working display.  I've
> > > > > > > identified a small handful of registers on both the CEC bank of
> > > > > > > registers and main set of registers.
> > > > > > >
> > > > > > > I noticed that the working NXP version doesn't rescale the number of
> > > > > > > lanes based on the clock rate, and it stays fixed at 4 lanes.
> > > > > >
> > > > > > Does it mean theoretically rescale of lanes is not required??
> > > > >
> > > > > On the custom kernel from NXP, I can sync at 720p at 4-lanes.
> > > > > Unfortunately, I haven't yet been able to replicate all the register
> > > > > settings between my working version at 720p and my non-working
> > > > > version, and I still have yet to sync at 720p using the mainline
> > > > > adv7535 driver.  I am still wrokong on it.
> > > > >
> > > > > > At least 2 platforms can work with fixed 4 lanes@720p.
> > > >
> > > > Based on what I'm seeing for this NXP platform, it almost seems like
> > > > the DSI transmitter should make the determination on whether or not to
> > > > scale the number of lanes instead of having the ADV7373 do it.  Since
> > > > their custom kernel is able to do 720p in 4-lane mode with this part,
> > > > it doesn't seem unreasonable to me.
> > >
> > > I did a bunch of comparisons between registers for both the ADV7535
> > > and the DSIM, and it appears that the video information is somehow
> > > different between the working NXP kernel and non-working one.
> > >
> > > The two main differences are around the values of htotal  hfp.  Both
> > > the DSIM and the ADV7535 are using different values for htotal and the
> > > hfp between the kernels.  I am wondering if there is a bug in the 5.19
> > > driver which is fetching wrong info or somehow the data isn't being
> > > calculated properly because both the DSIM and the ADV timings match
> > > each other, but don't match the working kernel.
> > >
> > >
> > > 720p Working on NXP:
> > >
> > > [   24.657957] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 112 ->
> > > hfp_wc = 78
> > > [   24.665284] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
> > > [   24.681496] adv7511_dsi_config_timing_gen: htotal 1652
> > > [   24.691372] adv7511_dsi_config_timing_gen: hfp 112
> > >
> > > 720p Not working:
> > >
> > > [  106.424404] samsung_dsim_set_display_mode: vfp = 5
> > > [  106.429216] samsung_dsim_set_display_mode: bfp = 20
> > > [  106.441777] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 110 ->
> > > hfp_wc = 77
> > > [  106.449221] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
> > > [  106.456314] LCD size = 1280x720
> > > [  106.470115] adv7511_dsi_config_timing_gen: htotal = 1650
> > > [  106.480707] adv7511_dsi_config_timing_gen: hfp = 110
> > >
> >
> > After spending more time than I care to admit, I think I have a
> > working solution to the DSIM + ADV7535, but the vast majority of the
> > changes I had to do were revolving around samsung_dsim_set_phy_ctrl.
> > I have an LVDS bridge based on the ti,sn65dsi83.  With some
> > suggestions from Marek V, I replaced the fixed-clock solution with a
> > dynamic one based on the attached bridge's requested clocks.
> >
> > With those changes, I have the following resolutions working on the
> > ADV7535 (with almost no chages to the ADV code) ane one that's nearly
> > working:
> >
> > Working:
> >
> > 1080p@60
> > 1080p@50
> > 720p@50
> > 800x600-75
> > 720x576
> >
> > Partially Working:
> > 720p@60 (hsync appears off, rounding error?)
> >
> > This driver appears to be using a fixed frequency and the
> > corresponding fixed frequency in the DPHY settings. If the clock
> > changes, the samsung_dsim_set_phy_ctrl needs to adjust accordingly.
> > NXP lists a 2-lane operation mode for 720 as needing some additional
> > adjustments because the calculations don't quite line up, but due to
> > the other changes I made, I didn't investigate 2-lane very much.
> >
> > In order to switch resolutions, I had to lock the adv7535 in 4-lane
> > mode with a minor patch to the adv driver, because the DSIM doesn't
> > appear to operate in 3-lane mode (like the adv7511 wants to do) and
> > the DSIM seemed to be unhappy about the connections and
> > disconnections.  I also made some changes to the PMS calibration for
> > the PLL which allowed me to lower the phy clock a bit.
> >
> > The rest of the changes I did were attempting to port the dsim dphy
> > frequency tables from NXP's kernel.  If anyone from NXP or Samsung has
> > the formula for how to determine some of the values for the DPHY, I'd
> > like to replace the look-up table [1] with a formula.
> >
> > Once I have my code changes cleaned up, I'll push them to a github and
> > share the info.
> >
> > [1] - https://source.codeaurora.org/external/imx/linux-imx/tree/include/drm/bridge/sec_mipi_dsim.h?h=lf-5.15.y
>
> Hi Adam,
>
> thanks for your work and sharing. Did you tested our current solution
> since we think that we understood the DSIM porches? As I said in the
> very beginning of this discussion, NXP took some porch values we really
> don't understand and I don't think they do either. NXP tweaked the
> values somehow so the chip is producing at least the most wanted
> resolutions.

I am using the porch calculator that Jagan's driver used + a bunch of
stuff to address a variety of clock rates and their corresponding DPHY
settings.  I did notice that the porches were different from NXP's,
but for the resolutions I listed, I didn't have to tweak them myself.
I have a tweaking hack for 720x480, but it's purely on the DSIM side,
and I haven't had to hack the ADV driver (other than to keep it from
switching from 4-lanes).    I am not convinced the ADV7535 is a bad
part, but I am convinced there is more to the DSIM than their TRM
documents state.  My changes to the DSIM driver also fixed my LVDS
bridge issue, so I feel like I am headed in the right direction.

I was planning on reviewing your porch calculator and generating some
sort of adjustment, but I'd like to keep it on the DSIM side so as not
to impact or break the ADV7535 for others.

I am guessing that the NXP tweaks were potentially to address areas
where the algorithm where it was compensating for the horizontal
timings where it does some math to recalculate what the timings should
be and there may have been sound rounding errors, but it's just a
guess.

adam

>
> Regards,
>   Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Mon, Aug 8, 2022 at 5:13 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Mon, Aug 8, 2022 at 3:54 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > On 22-08-07, Adam Ford wrote:
> > > On Fri, Aug 5, 2022 at 4:05 PM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > On Fri, Aug 5, 2022 at 7:56 AM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford <aford173@gmail.com> wrote:
> > > > > >
> > > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > > > > >
> > > > > > > Hi Adam and all,
> > > > > > >
> > > > > > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> > > > > > > >
> > > > > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> > > > > > > > <dave.stevenson@raspberrypi.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch <m.felsch@pengutronix.de>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Dave,
> > > > > > > > > >
> > > > > > > > > > On 22-08-04, Dave Stevenson wrote:
> > > > > > > > > > > Hi Marco
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch
> > > > > > > > <m.felsch@pengutronix.de> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Dave, Adam,
> > > > > > > > > > > >
> > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote:
> > > > > > > > > > > > > Hi Adam
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > ...
> > > > > > > > > > > >
> > > > > > > > > > > > > > > Did managed to get access to the ADV7535 programming
> > > > > > > > > > > > > > > guide? This is the black box here. Let me check if I can
> > > > > > > > > > > > > > > provide you a link with our repo so you can test our
> > > > > > > > current DSIM state if you want.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I do have access to the programming guide, but it's under
> > > > > > > > > > > > > > NDA, but I'll try to answer questions if I can.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > > > > > > > > > 7535 from previously looking at these chips.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for stepping into :)
> > > > > > > > > > > >
> > > > > > > > > > > > > Mine fairly plainly states:
> > > > > > > > > > > > > "The DSI receiver input supports DSI video mode operation
> > > > > > > > > > > > > only, and specifically, only supports nonburst mode with sync
> > > > > > > > pulses".
> > > > > > > > > > > >
> > > > > > > > > > > > I've read this also, and we are working in nonburst mode with
> > > > > > > > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore
> > > > > > > > > > > > I can't verify it.
> > > > > > > > > > > >
> > > > > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the
> > > > > > > > > > > > > same as the HDMI pixel rate.
> > > > > > > > > > > >
> > > > > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit-
> > > > > > > > clock.
> > > > > > > > > > >
> > > > > > > > > > > You have an effective pixel clock, with a fixed conversion for the
> > > > > > > > > > > configuration.
> > > > > > > > > > >
> > > > > > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > > > > > > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> > > > > > > > > >
> > > > > > > > > > Okay, I just checked the bandwidth which must equal.
> > > > > > > > > >
> > > > > > > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is
> > > > > > > > > > > only running at 891 / 2 = 445.5MHz.
> > > > > > > > > > >
> > > > > > > > > > > > > Section 6.1.1 "DSI Input Modes" of
> > > > > > > > > > > > > adv7533_hardware_user_s_guide is even more explicit about the
> > > > > > > > > > > > > requirement of DSI timing matching
> > > > > > > > > > > >
> > > > > > > > > > > > Is it possible to share the key points of the requirements?
> > > > > > > > > > >
> > > > > > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > > > > > > > > > This mode requires real time data generation as a pulse packet
> > > > > > > > > > > received becomes a pulse generated. Therefore this mode requires a
> > > > > > > > > > > continuous stream of data with correct video timing to avoid any
> > > > > > > > > > > visual artifacts."
> > > > > > > > > > >
> > > > > > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS
> > > > > > > > mode.
> > > > > > > > > > >
> > > > > > > > > > > "... the goal is to accurately convey DPI-type timing over DSI.
> > > > > > > > > > > This includes matching DPI pixel-transmission rates, and widths of
> > > > > > > > > > > timing events."
> > > > > > > > > >
> > > > > > > > > > Thanks for sharing.
> > > > > > > > > >
> > > > > > > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > > > > > > > > > therefore be correct for 720p operation.
> > > > > > > > > > > >
> > > > > > > > > > > > It should be absolute no difference if you work on 891MHz with 2
> > > > > > > > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > > > > > > > > > you need the minimum required bandwidth which is roughly:
> > > > > > > > > > > > 1280*720*24*60 = 1.327 GBps.
> > > > > > > > > > >
> > > > > > > > > > > Has someone changed the number of lanes in use? I'd missed that if
> > > > > > > > > > > so, but I'll agree that 891MHz over 2 lanes should work for
> > > > > > > > 720p60.
> > > > > > > > > >
> > > > > > > > > > The ADV driver is changing it autom. but this logic is somehow odd
> > > > > > > > > > and there was already a approach to stop the driver doing this.
> > > > > > > > >
> > > > > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes
> > > > > > > > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but
> > > > > > > > > probably the only way it can be achieved in the current framework.
> > > > > > > > >
> > > > > > > > > > To sync up: we have two problems:
> > > > > > > > > >   1) The 720P mode with static DSI host configuration isn't working
> > > > > > > > > >      without hacks.
> > > > > > > > > >   2) The DSI link frequency should changed as soon as required
> > > > > > > > > >      automatically. So we can provide all modes.
> > > > > > > > > >
> > > > > > > > > > I would concentrate on problem 1 first before moving on to the 2nd.
> > > > > > > > >
> > > > > > > > > If you change your link frequency, it may be worth trying a lower
> > > > > > > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
> > > > > > > > > lanes is again listed as mandatory for using the timing generator).
> > > > >
> > > > > Marco,
> > > > >
> > > > > Looking through the DSIM driver that NXP uses, it appears that they
> > > > > have a few special cases where they intentionally manipulate the DSIM
> > > > > under certain conditions:
> > > > >
> > > > > /* '1280x720@60Hz' mode with 2 data lanes
> > > > > * requires special fine tuning for DPHY
> > > > > * TIMING config according to the tests.
> > > > > */
> > > > >
> > > > > There is also a separate one for the 4-lane mode:
> > > > >
> > > > > /* workaround for CEA standard mode "1280x720@60" "1920x1080p24"
> > > > > * display on 4 data lanes with Non-burst with sync
> > > > > * pulse DSI mode, since use the standard horizontal
> > > > > * timings cannot display correctly. And this code
> > > > > * cannot be put into the dsim Bridge's mode_fixup,
> > > > > * since the DSI device lane number change always
> > > > > * happens after that.
> > > > > */
> > > > >
> > > > > And lastly, they address issues with 3-lane mode:
> > > > >
> > > > > /* TODO: DSIM 3 lanes has some display issue, so
> > > > > * avoid 3 lanes enable, and force data lanes to
> > > > > * be 2.
> > > > > */
> > > > >
> > > > > Since the ADV is trying to adjust the lanes to 3 when running at 720p,
> > > > > it could be part of the reason you need to jump to 2-lane mode.
> > > > >
> > > > > > > > >
> > > > > > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as
> > > > > > > > > > > one of the modes that is mandatory to use the timing generator
> > > > > > > > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required.
> > > > > > > > > > > I don't know why it's referencing the 1000/1001 pixel clock rates
> > > > > > > > > > > and not the base one, as it's only a base clock change with the
> > > > > > > > > > > same timing (74.176MHz clock instead of 74.25MHz).
> > > > > > > > > >
> > > > > > > > > > Interesting! I would like to know how the HDMI block gets fetched by
> > > > > > > > > > the DSI block and how the timing-generator can influence this in
> > > > > > > > > > good/bad way. So that we know what DSI settings (freq, lanes) are
> > > > > > > > sufficient.
> > > > > > > > > >
> > > > > > > > > > > > > If you do program the manual DSI divider register to allow a
> > > > > > > > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz,
> > > > > > > > > > > > > you'd be relying on
> > > > > > > > > > > >
> > > > > > > > > > > > There is no such DSI pixel rate to be precise, we only have a
> > > > > > > > > > > > DSI bit clock/rate.
> > > > > > > > > > > >
> > > > > > > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx
> > > > > > > > > > > > > and HDMI tx to compensate for the differing data rates. I see
> > > > > > > > > > > > > no reference to such, and I'd be surprised if it was more than
> > > > > > > > > > > > > a half dozen pixels to compensate for the jitter in the cases
> > > > > > > > > > > > > where the internal timing generator is mandatory due to
> > > > > > > > fractional bytes.
> > > > > > > > > > > >
> > > > > > > > > > > > This is interesting and would proofs our assumption that the
> > > > > > > > > > > > device don't have a FIFO :)
> > > > > > > > > > > >
> > > > > > > > > > > > Our assumptions (we don't have the datasheet/programming
> > > > > > > > manual):
> > > > > > > > > > > >   - HDMI part is fetching 3 bytes per HDMI pixclk
> > > > > > > > > > > >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI
> > > > > > > > and
> > > > > > > > > > > >     HDMI are in sync. So from bandwidth pov there are no
> > > > > > > > differences
> > > > > > > > > > > >     between:
> > > > > > > > > > > >       - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
> > > > > > > > > > > >       - DSI:    891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > > > 445.5 )
> > > > > > > > > > > >       - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock:
> > > > > > > > > > > > 222.75)
> > > > > > > > > > > >
> > > > > > > > > > > >     But the ratio is different and therefore the faster clocking
> > > > > > > > option
> > > > > > > > > > > >     let something 'overflow'.
> > > > > > > > > > >
> > > > > > > > > > > I'll agree that all looks consistent.
> > > > > > > > > > >
> > > > > > > > > > > > Anyway, but all this means that Adam should configure the
> > > > > > > > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this
> > > > > > > > > > > > doesn't work either and now we are back on my initial statement
> > > > > > > > > > > > -> the driver needs some attention.
> > > > > > > > > > >
> > > > > > > > > > > Things always need attention :-)
> > > > > > > > > >
> > > > > > > > > > ^^
> > > > > > > > > >
> > > > > > > > > > > I suspect that it's the use of the timing generator that is the
> > > > > > > > issue.
> > > > > > > > > > > The programming guide does recommend using it for all modes, so
> > > > > > > > > > > that would be a sensible first step.
> > > > > > > > > >
> > > > > > > > > > But I tested it without the timing-generator too. Can you or Adam
> > > > > > > > > > verify the timing-generator diable logic?
> > > > > > > > >
> > > > > > > > > Sorry, running without the use of the timing generator is the issue.
> > > > > > > > > It is mandatory in some modes, but supported in all modes. Always
> > > > > > > > > using it should therefore avoid not using it in one of the mandatory
> > > > > > > > > modes (the list looks a little arbitrary).
> > > >
> > > > I tested running various modes with the timing generator disable on an
> > > > NXP kernel with functional video, and some of the video modes stopped
> > > > operating or became blurry.  With the generator on, it appeared to
> > > > make the issues go away, so I think it should be left on.
> > > >
> > > > > > > > >
> > > > > > > > > > > I will say that we had a number of issues getting this chip to do
> > > > > > > > > > > anything, and it generally seemed happier on 2 or 3 lanes instead
> > > > > > > > > > > of 4. Suffice to say that we abandoned trying to use it, despite
> > > > > > > > > > > some assistance from ADI.
> > > > > > > > > >
> > > > > > > > > > Even more interessting, what is your alternative to this chip?
> > > > > > > > >
> > > > > > > > > BCM2711 which supported dual HDMI natively.
> > > > > > > > > Our investigation of ADV7535 was when trying to build what became
> > > > > > > > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I
> > > > > > > > > do have the prototype, the ADV was wired up weirdly with I2C so I
> > > > > > > > > never really got it running with Linux.
> > > > > > > >
> > > > > > > > I think I have convinced myself that the DSIM is working good enough to
> > > > > > > > match that of the NXP.
> > > > > > > >
> > > > > > > > I've gone through and made a list of the register differences between a
> > > > > > > > working display using NXP's kernel and the non-working display.  I've
> > > > > > > > identified a small handful of registers on both the CEC bank of
> > > > > > > > registers and main set of registers.
> > > > > > > >
> > > > > > > > I noticed that the working NXP version doesn't rescale the number of
> > > > > > > > lanes based on the clock rate, and it stays fixed at 4 lanes.
> > > > > > >
> > > > > > > Does it mean theoretically rescale of lanes is not required??
> > > > > >
> > > > > > On the custom kernel from NXP, I can sync at 720p at 4-lanes.
> > > > > > Unfortunately, I haven't yet been able to replicate all the register
> > > > > > settings between my working version at 720p and my non-working
> > > > > > version, and I still have yet to sync at 720p using the mainline
> > > > > > adv7535 driver.  I am still wrokong on it.
> > > > > >
> > > > > > > At least 2 platforms can work with fixed 4 lanes@720p.
> > > > >
> > > > > Based on what I'm seeing for this NXP platform, it almost seems like
> > > > > the DSI transmitter should make the determination on whether or not to
> > > > > scale the number of lanes instead of having the ADV7373 do it.  Since
> > > > > their custom kernel is able to do 720p in 4-lane mode with this part,
> > > > > it doesn't seem unreasonable to me.
> > > >
> > > > I did a bunch of comparisons between registers for both the ADV7535
> > > > and the DSIM, and it appears that the video information is somehow
> > > > different between the working NXP kernel and non-working one.
> > > >
> > > > The two main differences are around the values of htotal  hfp.  Both
> > > > the DSIM and the ADV7535 are using different values for htotal and the
> > > > hfp between the kernels.  I am wondering if there is a bug in the 5.19
> > > > driver which is fetching wrong info or somehow the data isn't being
> > > > calculated properly because both the DSIM and the ADV timings match
> > > > each other, but don't match the working kernel.
> > > >
> > > >
> > > > 720p Working on NXP:
> > > >
> > > > [   24.657957] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 112 ->
> > > > hfp_wc = 78
> > > > [   24.665284] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
> > > > [   24.681496] adv7511_dsi_config_timing_gen: htotal 1652
> > > > [   24.691372] adv7511_dsi_config_timing_gen: hfp 112
> > > >
> > > > 720p Not working:
> > > >
> > > > [  106.424404] samsung_dsim_set_display_mode: vfp = 5
> > > > [  106.429216] samsung_dsim_set_display_mode: bfp = 20
> > > > [  106.441777] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 110 ->
> > > > hfp_wc = 77
> > > > [  106.449221] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24
> > > > [  106.456314] LCD size = 1280x720
> > > > [  106.470115] adv7511_dsi_config_timing_gen: htotal = 1650
> > > > [  106.480707] adv7511_dsi_config_timing_gen: hfp = 110
> > > >
> > >
> > > After spending more time than I care to admit, I think I have a
> > > working solution to the DSIM + ADV7535, but the vast majority of the
> > > changes I had to do were revolving around samsung_dsim_set_phy_ctrl.
> > > I have an LVDS bridge based on the ti,sn65dsi83.  With some
> > > suggestions from Marek V, I replaced the fixed-clock solution with a
> > > dynamic one based on the attached bridge's requested clocks.
> > >
> > > With those changes, I have the following resolutions working on the
> > > ADV7535 (with almost no chages to the ADV code) ane one that's nearly
> > > working:
> > >
> > > Working:
> > >
> > > 1080p@60
> > > 1080p@50
> > > 720p@50
> > > 800x600-75
> > > 720x576
> > >
> > > Partially Working:
> > > 720p@60 (hsync appears off, rounding error?)
> > >
> > > This driver appears to be using a fixed frequency and the
> > > corresponding fixed frequency in the DPHY settings. If the clock
> > > changes, the samsung_dsim_set_phy_ctrl needs to adjust accordingly.
> > > NXP lists a 2-lane operation mode for 720 as needing some additional
> > > adjustments because the calculations don't quite line up, but due to
> > > the other changes I made, I didn't investigate 2-lane very much.
> > >
> > > In order to switch resolutions, I had to lock the adv7535 in 4-lane
> > > mode with a minor patch to the adv driver, because the DSIM doesn't
> > > appear to operate in 3-lane mode (like the adv7511 wants to do) and
> > > the DSIM seemed to be unhappy about the connections and
> > > disconnections.  I also made some changes to the PMS calibration for
> > > the PLL which allowed me to lower the phy clock a bit.
> > >
> > > The rest of the changes I did were attempting to port the dsim dphy
> > > frequency tables from NXP's kernel.  If anyone from NXP or Samsung has
> > > the formula for how to determine some of the values for the DPHY, I'd
> > > like to replace the look-up table [1] with a formula.
> > >
> > > Once I have my code changes cleaned up, I'll push them to a github and
> > > share the info.
> > >
> > > [1] - https://source.codeaurora.org/external/imx/linux-imx/tree/include/drm/bridge/sec_mipi_dsim.h?h=lf-5.15.y
> >
> > Hi Adam,
> >
> > thanks for your work and sharing. Did you tested our current solution
> > since we think that we understood the DSIM porches? As I said in the
> > very beginning of this discussion, NXP took some porch values we really
> > don't understand and I don't think they do either. NXP tweaked the
> > values somehow so the chip is producing at least the most wanted
> > resolutions.
>
> I am using the porch calculator that Jagan's driver used + a bunch of
> stuff to address a variety of clock rates and their corresponding DPHY
> settings.  I did notice that the porches were different from NXP's,
> but for the resolutions I listed, I didn't have to tweak them myself.
> I have a tweaking hack for 720x480, but it's purely on the DSIM side,
> and I haven't had to hack the ADV driver (other than to keep it from
> switching from 4-lanes).    I am not convinced the ADV7535 is a bad
> part, but I am convinced there is more to the DSIM than their TRM
> documents state.  My changes to the DSIM driver also fixed my LVDS
> bridge issue, so I feel like I am headed in the right direction.
>
> I was planning on reviewing your porch calculator and generating some
> sort of adjustment, but I'd like to keep it on the DSIM side so as not
> to impact or break the ADV7535 for others.
>
> I am guessing that the NXP tweaks were potentially to address areas
> where the algorithm where it was compensating for the horizontal
> timings where it does some math to recalculate what the timings should
> be and there may have been sound rounding errors, but it's just a
> guess.

Jagan / Fabio / Marco et al,

I quasi-cleaned the code up, so it won't cause a bunch of splat.  It
needs more cleanup before I can do more formal patches.  It's not
perfect, but I wanted to share what I have.

My github account is here:
https://github.com/aford173/linux/tree/imx8mm-dsi-v3-7535-enhancements

It's based on Jagan's imx8mm-dsi-v3 with some changes from Fabio.

From there I added the following:

Tweaked the ADV7535 to allow the device tree to keep the lanes fixed
to 4 instead of dynamically changing to 3.
Tweaked the PLL so it's not hard-coded to a device tree speed, but
instead it allows the connected device to specify the clock.
Fixed the PMS calculator a bit to allow for better precision and
lowering of the DSI PHY ref clock.
Updated the imx8mm device tree with a lower PHY clock and removed
changed the clock parent a bit.
Pulled in the NXP lookup table for determining the DPHY timings based
on the requested clock rates.  This way, different resolutions are
available
using 4-lane-only mode.
Since some of the clocks appear to divide by 3, there are some
potential rounding errors which may have to be addressed, so not all
resolutions work
To date, I have tested the following on my monitor:

1920x1080-60
1920x1080-50
1280x720-50
800x600-75
720x576-50

Several resolutions are close, but they don't compleley appear
correctly.  They may require some further adjustments to either the
clocking or addressing the porch calculation and identifying rounding
errors.

adam
>
> adam
>
> >
> > Regards,
> >   Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel