Hi Adam,

On 22-08-04, Adam Ford wrote:

On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch [off-list ref] wrote:

quoted

Hi Dave,

On 22-08-04, Dave Stevenson wrote:

quoted

Hi Marco

On Thu, 4 Aug 2022 at 10:38, Marco Felsch [off-list ref] wrote:

quoted

Hi Dave, Adam,

On 22-08-03, Dave Stevenson wrote:

quoted

Hi Adam

On Wed, 3 Aug 2022 at 12:03, Adam Ford [off-list ref] wrote:

...

quoted

quoted

quoted

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 :)

quoted

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.

quoted

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.

quoted

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

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

  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.

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

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.

quoted

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 :-)

^^

quoted

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

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

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

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

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

Okay, thanks for checking.

Regards,
  Marco

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

quoted

quoted

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

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

adam

quoted

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

Regards,
  Marco

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