On Mon, Aug 1, 2022 at 5:54 AM Adam Ford <aford173@xxxxxxxxx> wrote: > > On Mon, Aug 1, 2022 at 1:20 AM Marco Felsch <m.felsch@xxxxxxxxxxxxxx> 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
