• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 32 subscribers
  • Views 1718 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DS90UB964-Q1: 953-964 YUV422-8 bit Format?

Ahmed Abdelazim
Prodigy 150 points
Part Number: DS90UB964-Q1
Other Parts Discussed in Thread: DS90UB962-Q1, DS90UB960-Q1

Hello,

Below is a summary of the clarification provided by the FPD-link team for some questions related to 953-964.

@FPD-link team, Please confirm.

Q1: Can 953-964 support YUV422-8 bit? In other words, the input to 953 is YUV422-8 bit, can this be transmitted to the 964? I assume this can be done using "Non-sychronous external clock" mode (Table 7-6) in the 953 datasheet.

A1:The challenge here is that 964 only supports DVP mode. So, "Non-synchronous external clock mode" is not supported between 953/964.

Natively YUV422 8 bit is not supported in DVP mode since the pixel packing structure does not match the CSI-2 standard.

However, there is one alterative. You can technically send YUV422 8-bit data in a custom data structure which uses RAW10 or RAW12 pixel packing, and then on the deserializer side, the SoC would need to know to expect this custom pixel packing structure and extract the data accordingly.

The more straightforward way to do this would be with YUV422 10 bit format since it fits within the RAW10 pixel packing format
Q2: how to use this DVP mode?
A2:  For DVP mode to CSI-2 DES, the data will be either packed in RAW10 format or RAW12 format. The containers for these data formats are listed below:
RAW12 = 2 pixels over 3 bytes

RAW10 = 4 pixels over 5 bytes

Since YUV422 8 bit sends 2 pixels over 4 bytes, it would probably make most sense to send using RAW10 format but pad one extra byte of 0s for every 2 pixels into the transmission stream. That way you would get an even division of pixels into the 5 byte block size of RAW10.
Essentially, the device will recognize this as a line with 2x the horizontal pixels since you are sending 2 pixels per 5 bytes instead of 4 pixels per 5 bytes which means you will need double the effective “RAW10 pixels” to be sent. 
One the DES side, you can also tell the DES to output the data with a custom data type using register 0x70
By default it will be 0x2B which is the CSI-2 code for RAW10, but since this is not going to be actual RAW10 formatted data, you can use a custom code here and then program the receiving SoC to handle the data reception and processing in a custom fashion. Of course this requires special CSI-2 drivers on both SER and DES sides to work. 

Best regards,

Ahmed

  • 0
    TI__Guru** 103215 points

    Hello Ahmed,

    Thank you for posting our discussion on E2E in case others would like to reference the details in the future. Please keep in mind that this is a custom implementation which does require customized CSI-2 drivers on both serializer and deserializer side. This is only applicable since the 964 side part selection is locked and the serializer side needs to take in CSI-2. If the deserializer side part selection was not locked, it would be much more straightforward to use DS90UB960-Q1 or DS90UB962-Q1 when paired with 935 so that CSI-2 could be passed end to end without any such constraints. 

    Best Regards,

    Casey