Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Mon, Aug 8, 2022 at 5:13 AM Adam Ford wrote: > > On Mon, Aug 8, 2022 at 3:54 AM Marco Felsch wrote: > > > > On 22-08-07, Adam Ford wrote: > > > On Fri, Aug 5, 2022 at 4:05 PM Adam Ford wrote: > > > > > > > > On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > > > > > > > > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > > > > > > > > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das > > > > > > 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 > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > > > > > > Hi Marco > > > > > > > > > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > >
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Mon, Aug 8, 2022 at 3:54 AM Marco Felsch wrote: > > On 22-08-07, Adam Ford wrote: > > On Fri, Aug 5, 2022 at 4:05 PM Adam Ford wrote: > > > > > > On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > > > > > > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > > > > > > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das > > > > > 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 > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > > > > > Hi Marco > > > > > > > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > > > > > > > > > > > > > > > > > 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. > > &g
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On 22-08-07, Adam Ford wrote: > On Fri, Aug 5, 2022 at 4:05 PM Adam Ford wrote: > > > > On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > > > > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > > > > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das > > > > 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 > > > > > > wrote: > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > > > > Hi Marco > > > > > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > > > > > > > > > > > > > > > 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. > > > &g
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Fri, Aug 5, 2022 at 4:05 PM Adam Ford wrote: > > On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das > > > 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 > > > > > wrote: > > > > > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > > > wrote: > > > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > > > Hi Marco > > > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > > > 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 > > > > > >
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das 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 > > > > wrote: > > > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > > wrote: > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > > Hi Marco > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > > wrote: > > > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > > 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das 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 > > > wrote: > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > wrote: > > > > > > > > > > Hi Dave, > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > Hi Marco > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > wrote: > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > 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. > > > > &g
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Fri, Aug 5, 2022 at 3:44 AM Biju Das 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 > > wrote: > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > wrote: > > > > > > > > Hi Dave, > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > Hi Marco > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > wrote: > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > Hi Adam > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > 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
RE: imx8mm lcdif->dsi->adv7535 no video, no errors
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 > wrote: > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > wrote: > > > > > > Hi Dave, > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > Hi Marco > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > wrote: > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > Hi Adam > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > 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 a
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson wrote: > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch wrote: > > > > Hi Dave, > > > > On 22-08-04, Dave Stevenson wrote: > > > Hi Marco > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > > > > > Hi Dave, Adam, > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > Hi Adam > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford 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 < 8 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 > > > >
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Thu, 4 Aug 2022 at 13:51, Marco Felsch wrote: > > Hi Dave, > > On 22-08-04, Dave Stevenson wrote: > > Hi Marco > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > > > Hi Dave, Adam, > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > Hi Adam > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford 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 < 8 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
RE: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam, > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors > > On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch > wrote: > > > > Hi Dave, > > > > On 22-08-04, Dave Stevenson wrote: > > > Hi Marco > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > wrote: > > > > > > > > Hi Dave, Adam, > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > Hi Adam > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > 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...@bp.renesas.com/ Cheers, Biju
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam, On 22-08-04, Adam Ford wrote: > On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch wrote: > > > > Hi Dave, > > > > On 22-08-04, Dave Stevenson wrote: > > > Hi Marco > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > > > > > Hi Dave, Adam, > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > Hi Adam > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Dave, On 22-08-04, Dave Stevenson wrote: > Hi Marco > > On Thu, 4 Aug 2022 at 11:28, Marco Felsch wrote: > > > > On 22-08-03, Dave Stevenson wrote: > > > On Wed, 3 Aug 2022 at 13:31, Adam Ford 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 >
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch wrote: > > Hi Dave, > > On 22-08-04, Dave Stevenson wrote: > > Hi Marco > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > > > Hi Dave, Adam, > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > Hi Adam > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Dave, On 22-08-04, Dave Stevenson wrote: > Hi Marco > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > Hi Dave, Adam, > > > > On 22-08-03, Dave Stevenson wrote: > > > Hi Adam > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Marco On Thu, 4 Aug 2022 at 11:28, Marco Felsch wrote: > > On 22-08-03, Dave Stevenson wrote: > > On Wed, 3 Aug 2022 at 13:31, Adam Ford 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Marco On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > Hi Dave, Adam, > > On 22-08-03, Dave Stevenson wrote: > > Hi Adam > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On 22-08-03, Dave Stevenson wrote: > On Wed, 3 Aug 2022 at 13:31, Adam Ford 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Dave, Adam, On 22-08-03, Dave Stevenson wrote: > Hi Adam > > On Wed, 3 Aug 2022 at 12:03, Adam Ford 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On 22-08-03, Adam Ford wrote: > On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch 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 = <15>; > > > > 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 = 178200 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 89100, (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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Wed, 3 Aug 2022 at 13:31, Adam Ford wrote: > > On Wed, Aug 3, 2022 at 7:17 AM Dave Stevenson > wrote: > > > > Hi Adam > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: > > > > > > On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch > > > 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 89100, > > > > > 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: 89100/2 = > > > > 44550. This clock is than divided by 3 within the ADV and you get > > > > your 14850 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 89100, 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 = <15>; > > > > > > > > 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 = <2000>; > > > > > > > > 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Wed, Aug 3, 2022 at 7:17 AM Dave Stevenson wrote: > > Hi Adam > > On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: > > > > On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch 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 89100, > > > > 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: 89100/2 = > > > 44550. This clock is than divided by 3 within the ADV and you get > > > your 14850 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 89100, 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 = <15>; > > > > > > 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 = <2000>; > > > > > > 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 89100,
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: > > On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch 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 89100, > > > 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: 89100/2 = > > 44550. This clock is than divided by 3 within the ADV and you get > > your 14850 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 89100, 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 = <15>; > > > > 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 = <2000>; > > > > 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 89100, (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 89100, (p 3, m 99, s 0) > hs_clk = 89100, byte_clk = 111375000, esc_clk = 18562500 > (not working) > > > > > > >
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch 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 89100, > > 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: 89100/2 = > 44550. This clock is than divided by 3 within the ADV and you get > your 14850 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 89100, 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 = <15>; > > 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 = <2000>; > > 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 89100, (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 89100, (p 3, m 99, s 0) hs_clk = 89100, 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
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 89100, > 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: 89100/2 = 44550. This clock is than divided by 3 within the ADV and you get your 14850 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 89100, 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 = <15>; This is not correct since the burst-clock-freq. specifies the hs-clock for the data lanes (see above). > samsung,esc-clock-frequency = <2000>; 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Tue, Aug 2, 2022 at 8:51 AM Adam Ford wrote: > > On Tue, Aug 2, 2022 at 7:13 AM Adam Ford wrote: > > > > On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote: > > > > > > Hi Adam, Fabio, > > > > > > On 22-08-01, Adam Ford wrote: > > > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > > > > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford 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 89100, 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 89100, 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 = <15>; samsung,esc-clock-frequency = <2000>; 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Tue, Aug 2, 2022 at 7:13 AM Adam Ford wrote: > > On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote: > > > > Hi Adam, Fabio, > > > > On 22-08-01, Adam Ford wrote: > > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford 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 > > >
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote: > > Hi Adam, Fabio, > > On 22-08-01, Adam Ford wrote: > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford 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 > >
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam, Fabio, On 22-08-01, Adam Ford wrote: > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford 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 >
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Mon, Aug 1, 2022 at 10:39 PM Adam Ford 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?
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Mon, Aug 1, 2022 at 6:12 PM Fabio Estevam wrote: > > Hi Marco, > > On Mon, Aug 1, 2022 at 7:55 PM Marco Felsch 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Marco, On Mon, Aug 1, 2022 at 7:55 PM Marco Felsch 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Mon, Aug 1, 2022 at 3:07 PM Adam Ford wrote: > > On Mon, Aug 1, 2022 at 2:33 PM Fabio Estevam wrote: > > > > Hi Adam, > > > > On Sat, Jul 30, 2022 at 12:16 PM 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. > > > > 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 00x0001 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: 010002001800 010020005247313658523234 0300 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 00x0001 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
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 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Mon, Aug 1, 2022 at 2:33 PM Fabio Estevam wrote: > > Hi Adam, > > On Sat, Jul 30, 2022 at 12:16 PM 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. > > 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam, On Sat, Jul 30, 2022 at 12:16 PM 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. 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?
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Mon, Aug 1, 2022 at 5:54 AM Adam Ford wrote: > > On Mon, Aug 1, 2022 at 1:20 AM Marco Felsch 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
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Mon, Aug 1, 2022 at 1:20 AM Marco Felsch 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
