On 03/30/2015 05:00 AM, George Grey wrote:
Hi Thank you - that will be very helpful
But, the import fact is that: Recent days i and our SoC guys are analyzing the HDMI signal issue. We have tested many mode timings on TV monitors and PC monitors and we found very a few mode timings can work, including the 720P. SoC guys said that TV monitors are follow the CEA 681 standard and our SoC can't math this standard and during our SoC design phase HDMI is not taken into account. I'm afraid this signal can't be fixed and our SoC can't support HDMI well.
Can you explain the problem and the limitations of the SoC in technical detail? You say that a few timings do work including 720p. Can you explain the technical reason for this? Is it possible to determine which timing/configurations will work and which will not?
It's not 720p that's working, at least not the CEA compliant 720p. It's a timings setting where the active resolution is the same as 720p, but the front porch/back porch/blanking timings as well as the refresh rate are different. The reason why this timing works is because the result of the formula that I explained in the earlier mail ("lengthA * clkB / clkA = lengthB") is integer for these settings. And if the result is integer the video timings are uniform in the DSI/HDMI clock domain and hence the monitor will be able to recognize the timings and display the image.
For the timing we are talking about the LDI clock is 72 MHz, the DSI clock is 297.6 Mhz, the total line length in the LDI clock domain is 1650.
The HDMI clock is DSI clock / 4. If you insert that into the above formula you get 1650 * (297.6 / 4) / 72.0 = 1705.0. That's why it works. But it's not 720p and not what the monitor says it supports, but most modern monitors are quite forgiving when it comes to timing as long as the active area is correct and the refresh rate is within reasonable bounds. But you'll not pass compliance testing with this.
- Lars
Hi,
modetest is the best way to test you drm/kms driver. You will get the list of supported modes per connectors in a human readable way and the raw EDID data. For example it give me this on my ST board:
modetest trying to open device 'sti'...success. Encoders: id crtc type possible crtcs possible clones 8 3 TMDS 0x00000003 0x00000002 12 0 DAC 0x00000003 0x00000001 14 0 LVDS 0x00000003 0x00000000
Connectors: id encoder status type size (mm) modes encoders 9 8 connected HDMI-A 480x270 35 8 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 flags: phsync, pvsync; type: preferred, driver 1920x1080 50 1920 2448 2492 2640 1080 1084 1089 1125 flags: phsync, pvsync; type: driver 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 flags: phsync, pvsync; type: driver 1920x1080 30 1920 2008 2052 2200 1080 1084 1089 1125 flags: phsync, pvsync; type: driver
Then you can test each mode with "modetest -s <args>"
The displayed modes are those validated by your driver connector function mode_valid().
Regards, Benjamin
2015-03-30 10:32 GMT+02:00 Lars-Peter Clausen lars-peter.clausen@analog.com:
On 03/30/2015 05:00 AM, George Grey wrote:
Hi Thank you - that will be very helpful
But, the import fact is that: Recent days i and our SoC guys are analyzing the HDMI signal issue. We have tested many mode timings on TV monitors and PC monitors and we found very a few mode timings can work, including the 720P. SoC guys said that TV monitors are follow the CEA 681 standard and our SoC can't math this standard and during our SoC design phase HDMI is not taken into account. I'm afraid this signal can't be fixed and our SoC can't support HDMI well.
Can you explain the problem and the limitations of the SoC in technical detail? You say that a few timings do work including 720p. Can you explain the technical reason for this? Is it possible to determine which timing/configurations will work and which will not?
It's not 720p that's working, at least not the CEA compliant 720p. It's a timings setting where the active resolution is the same as 720p, but the front porch/back porch/blanking timings as well as the refresh rate are different. The reason why this timing works is because the result of the formula that I explained in the earlier mail ("lengthA * clkB / clkA = lengthB") is integer for these settings. And if the result is integer the video timings are uniform in the DSI/HDMI clock domain and hence the monitor will be able to recognize the timings and display the image.
For the timing we are talking about the LDI clock is 72 MHz, the DSI clock is 297.6 Mhz, the total line length in the LDI clock domain is 1650.
The HDMI clock is DSI clock / 4. If you insert that into the above formula you get 1650 * (297.6 / 4) / 72.0 = 1705.0. That's why it works. But it's not 720p and not what the monitor says it supports, but most modern monitors are quite forgiving when it comes to timing as long as the active area is correct and the refresh rate is within reasonable bounds. But you'll not pass compliance testing with this.
- Lars
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer: William A. Martin, Margaret Seif
Hi Scott, I have look at X fails log carefully. The Xorg.0.log seems ok. And the dmesg log seems that mipi_init runs twice. That's because at first Debian turn on console and then turn off console to turn on X. So you can see mipi_init runs twice. That's the reason why X fails to display. Because recently we found that display can't come back to work again by turning on after a turn off. That's the issue i want to fix in recent days. Now i have fixed this issue and checked that X can load, i can see the desktop of Debian. Please see the pull requst 34: https://github.com/96boards/linux/pull/34 and have a check.
Thanks -Xinliang
On Monday, March 30, 2015 05:39 PM, Benjamin Gaignard wrote:
Hi,
modetest is the best way to test you drm/kms driver. You will get the list of supported modes per connectors in a human readable way and the raw EDID data. For example it give me this on my ST board:
modetest trying to open device 'sti'...success. Encoders: id crtc type possible crtcs possible clones 8 3 TMDS 0x00000003 0x00000002 12 0 DAC 0x00000003 0x00000001 14 0 LVDS 0x00000003 0x00000000
Connectors: id encoder status type size (mm) modes encoders 9 8 connected HDMI-A 480x270 35 8 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 flags: phsync, pvsync; type: preferred, driver 1920x1080 50 1920 2448 2492 2640 1080 1084 1089 1125 flags: phsync, pvsync; type: driver 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 flags: phsync, pvsync; type: driver 1920x1080 30 1920 2008 2052 2200 1080 1084 1089 1125 flags: phsync, pvsync; type: driver
Then you can test each mode with "modetest -s <args>"
The displayed modes are those validated by your driver connector function mode_valid().
Regards, Benjamin
2015-03-30 10:32 GMT+02:00 Lars-Peter Clausen lars-peter.clausen@analog.com:
On 03/30/2015 05:00 AM, George Grey wrote:
Hi Thank you - that will be very helpful
But, the import fact is that: Recent days i and our SoC guys are analyzing the HDMI signal issue. We have tested many mode timings on TV monitors and PC monitors and we found very a few mode timings can work, including the 720P. SoC guys said that TV monitors are follow the CEA 681 standard and our SoC can't math this standard and during our SoC design phase HDMI is not taken into account. I'm afraid this signal can't be fixed and our SoC can't support HDMI well.
Can you explain the problem and the limitations of the SoC in technical detail? You say that a few timings do work including 720p. Can you explain the technical reason for this? Is it possible to determine which timing/configurations will work and which will not?
It's not 720p that's working, at least not the CEA compliant 720p. It's a timings setting where the active resolution is the same as 720p, but the front porch/back porch/blanking timings as well as the refresh rate are different. The reason why this timing works is because the result of the formula that I explained in the earlier mail ("lengthA * clkB / clkA = lengthB") is integer for these settings. And if the result is integer the video timings are uniform in the DSI/HDMI clock domain and hence the monitor will be able to recognize the timings and display the image.
For the timing we are talking about the LDI clock is 72 MHz, the DSI clock is 297.6 Mhz, the total line length in the LDI clock domain is 1650.
The HDMI clock is DSI clock / 4. If you insert that into the above formula you get 1650 * (297.6 / 4) / 72.0 = 1705.0. That's why it works. But it's not 720p and not what the monitor says it supports, but most modern monitors are quite forgiving when it comes to timing as long as the active area is correct and the refresh rate is within reasonable bounds. But you'll not pass compliance testing with this.
- Lars
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer: William A. Martin, Margaret Seif
-
Benjamin Gaignard -
Lars-Peter Clausen -
xinliang