This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DS90UB941AS-Q1: Single link mode, but DSI 0 in and FPD 1 out.

Part Number: DS90UB941AS-Q1
Other Parts Discussed in Thread: DS90UH941AS-Q1,

We have an IMX8QM, with it's DSI 0 connected to the DS90UB941 DSI0. 

The 1280x720 display has a DS90UB948, which only has FPD link 0 connected.

BUT, due to pinout differences between vendors, the FPD link 0 of the display is connected to FPD Link 1 of the '941.

The net result is that we want the single DSI 0 input to go to the single FPD Link 1 output.

Link detect on the '941 sees this just fine as FPD Link 1.

We set TX_PORT_SEL (0x1E) to (0x06) for PORT1_I2C_EN and PORT1_SEL. This lets us see the registers in the '948 just fine, and control GPIO for the backlight and such. 

I'm trying to find the correct mode to get DSI 0 video to FPD 1 output. Does single link mode automatically use FPD 1 if that's the only link? I see swap settings for dual link mode and independent 2:2 mode, but no mention of single link mode. I also worry that if by making too many swap and port selections, we have competing settings. For example, the '941 seems to be telling us that only DSI 1 has a valid DSI clock, but our DSI 1 pins aren't connected at all. 

Does single link mode work if only DSI 0 and FPD 1 are connected? If this can be done, what mode and settings are required. The host CPU should just be outputting a single image on the DSI 0 port, which goes into the DSI 0 port o the '941, and output on the FPD 1 port,  to a display with a '948 that sees only a connection on FPD port 0, due to the ports being swapped at the connector.  

  • Hello Lary,

    Single link mode works with DSI0 and FPD1 - in fact there shouldn't be any additional settings required. The DSI port for single link mode is selected with DSI_PORT_SEL = 0 (default) and then the FPD channel is auto detected to port 1 mode. 

    Are you actually having an issue that it is not working? Or are you asking pre-emptively but have not tested the video yet?

    Best Regards,

    Casey 

  • There's been a week or so of this, so it's post-emptive. I'm the H/W guy, and there's a bit of distance to one of the S/W guys on this issue. So pardon me if there is some lag in responses, and as I get up pto speed on their issues. There was video once, but it hasn't been reproduced for some reason. I think some of our attempts to force the link swap might have actually been interfering rather than helping. Today I had him unplug the display, so that we could focus on verifying the DSI status with no possible interaction with the link swap situation. One step at a time. DSI status seems divided up between registers 0x0C, 0x28, 0x5A, 0x5B, and 0x5F, so I'm trying get a full understanding of those those, and the best order to approach them, like just getting a PLL lock first. Your statement about autodetecting the port 1 mode should also help me start them over a bit with fewer register settings. 

    OH, also, and this could be big. I found out today that the boards were built with the DS90UH941 rather than the 'UB version, due to availability. The S/W guy was already setting reg 0xC3 to 0x02 for DHCP disable, and reg 0x12 to 0x40 for RGB pass through. Is there any other setting we need to use the 'UH as a 'UB?

  • Lary,

    Is the device you are using DS90UH941AS-Q1 or DS90UH941-Q1? UH vs. UB will not make any difference here.

    Can you please share your script for configuring/enabling the part? I can help to identify if something done in the config is causing issues with your configuration

    Best Regards,

    Casey 

  • We have the DS90UH941AS-Q1 installed, but that should be the DS90UB941AS-Q1 when we can get it. There's no call for dhcp in the product. I'll get the latest startup script to check. 

  • Here's the current one:

    Note: the '941 has I2C address 0x10. Reg 0x1E enables the secondary address 0x11, and makes the '948 deserializer visible as 0x2C

    su
    dmesg -n1

    echo 470 > /sys/class/gpio/export
    echo out > /sys/class/gpio/gpio470/direction
    echo 1 > /sys/class/gpio/gpio470/value

    # disable dsi
    i2cset -y 4 0x10 0x01 0x08 b

    # PORT1_I2C_EN PORT1_SEL - work with FPD link 1
    i2cset -y 4 0x10 0x1E 0x06 b

    # CRC_CHECKER EN, FILTER_EN, I2C_PASSTHROUGH, PCLK_AUTO
    i2cset -y 4 0x11 0x03 0x9A b

    # disable hdcp
    i2cset -y 4 0x11 0xC3 0x02 b
    # set pass_rgb
    i2cset -y 4 0x11 0x12 0x40 b
    # set DSI_RST_MODE
    i2cset -y 4 0x11 0x5D 0x46 b

    i2cset -y 4 0x2C 0x02 0x80 b
    i2cset -y 4 0x2C 0x01 0x01 b
    i2cset -y 4 0x2C 0x1E 0x93 b
    i2cset -y 4 0x2C 0x20 0xB0 b
    i2cset -y 4 0x2C 0x1F 0x09 b
    i2cset -y 4 0x2C 0x1D 0x19 b

    # dsi cont clock, 4 lanes
    i2cset -y 4 0x11 0x4F 0xAC b

    # enable dsi

    i2cset -y 4 0x10 0x01 0x00 b

    One big oddity, we ONLY have DSI 0 on pins 51-60. The DSI 1 pins 1-8,62-63 are all no-connects, BUT setting reg 0x4F, DSI_PORT_SEL to DSI port 1 is the only way we get non-zero values in 0x5F

  • Slightly newer info. When we do get a non-zero value in 0x5F, then 0x0C is showing 0x03, and 0x5A is showing 0xA8, and 0x5F has different values each time. Could DSI port 1, as a no-connect, just be responding to stray noise?

  • Lary,

    If you are using single link mode with DSI0, then you need to set 0x4F[5] = 0. The swap setting you are using there by setting "1" is for independent 2:2 mode. 

    Best Regards,

    Casey 

  • Quick datasheet question: I have both an older and newer datasheet for the 'UB941AS. In the older version register 0x5A, bit 2 is shown as DSI_PLL_LOCK, but in newer datasheets it's shown as reserved. Can I assume that it'd definitely not a reliable PLL status?

    I'm working on the idea that since the DSI1 input is floating, we could be picking up some noise. REG 0x5A reports DSI_CLK_DET true, NO_DSI_CLK false, but FREQ_STABLE also false. Reg 0x5F reports a different value each time. If this is just noise, we have to focus on whether or not the host CPU is actually generating a DSI clock, which is where I'm leaning a the moment, though I only have a 200MHz scope available at the moment.

  • Hello Lary,

    in newer datasheets it's shown as reserved. Can I assume that it'd definitely not a reliable PLL status?

    Yes this is correct, please go by the revised datasheet on TI.com

    I'm working on the idea that since the DSI1 input is floating, we could be picking up some noise. REG 0x5A reports DSI_CLK_DET true, NO_DSI_CLK false, but FREQ_STABLE also false. Reg 0x5F reports a different value each time. If this is just noise, we have to focus on whether or not the host CPU is actually generating a DSI clock, which is where I'm leaning a the moment, though I only have a 200MHz scope available at the moment.

    Yes this is definitely possible, but I think the main problem why you are not seeing display is because of my previous comment on 0x4F[5] setting in this particular config

    Best Regards,

    Casey 

  • I'm agreeing with that. We're seeing a clock, albeit unstable, only when 0x4F[5] is set to 1 for DSI1. BUT, I think that's just noise on the floating DSI1 clock pins, and that when we set 0x4F[5] to 0 for DSI0, we're getting nothing because there really is nothing coming from, the host interface. I think the unstable clock is a red herring; The S/W guy is a few thousand miles away, but tomorrow I was have a board here that I can connect to the oscilloscope, and I think the correct DSI CLK should be about 184MHz, just in the range of my scope. 

  • Hello Lary,

    Yes what you are saying makes sense but what additional support do you need here?

    Best Regards,

    Casey 

  • Good point. You've answered my two actual support questions. Thanks.