• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 101 subscribers
  • Views 3097 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.

Supporting a Data Image TFT Colour LCD with the AM335x and Linux 3.12

Peter M
Intellectual 680 points
Other Parts Discussed in Thread: DA8XX, DS90CF363B

I need to get a Data Image 640 - 480 TFT 18-bit Data Image LCD to work the an am335x with Linux 3.12.

So, I need some assistance in making this happen. Unfortunately, I am a novice LCD person so I aplogize for my lack of knowledge.

1) The exact LCD spec is not available to share yet. But it is compatible with Data Images standard FG050720DSSWDG01  I googled and found a company that posted the timing/spec's for the FG050720DSSWDG01  at  http://www.hy-line.de/fileadmin/hy-line/computer/csv/datasheets/FG050720DSSWDG01.pdf.

2) We are going through a DS90CF363B LVDS transmitter beween the AM335x to minimize the connections between our board and are LCD assembly. The other end is a DS90CF366B LVDS receiver.

3) I followed the instructions in the Port guide

Here is the device tree setup.

		lcd_pins_default: lcd_pins_default {
			pinctrl-single,pins = <
				0x38 (PIN_OUTPUT_PULLDOWN | MUX_MODE1)  /* gpmc_ad14.lcd_data17, NOTE On EVM DTS = 20 gpmc_ad8.lcd_data16   */
				0x3C (PIN_OUTPUT_PULLDOWN | MUX_MODE1)  /* gpmc_ad15.lcd_data16, NOTE on EVM DTS = 24 gpmc_ad9.lcd_data17   */
				0xa0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data0.lcd_data0,     */
				0xa4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data1.lcd_data1,     */
				0xa8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data2.lcd_data2,     */
				0xac (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data3.lcd_data3,     */
				0xb0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data4.lcd_data4,     */
				0xb4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data5.lcd_data5,     */
				0xb8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data6.lcd_data6,     */
				0xbc (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data7.lcd_data7,     */
				0xc0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data8.lcd_data8,     */
				0xc4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data9.lcd_data9,     */
				0xc8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data10.lcd_data10,   */
				0xcc (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data11.lcd_data11,   */
				0xd0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data12.lcd_data12,   */
				0xd4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data13.lcd_data13,   */
				0xd8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data14.lcd_data14,   */
				0xdc (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_data15.lcd_data15,   */
				0xe0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_vsync.lcd_vsync,     */
				0xe4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_hsync.lcd_hsync,     */
				0xe8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_pclk.lcd_pclk,       */
				0xec (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* lcd_ac_bias_en.lcd_ac_bias_en, */
				0x28 (PIN_OUTPUT_PULLUP   | MUX_MODE7)  /* gpmc.ad10.gpio0.26 */
			>;
		};

		lcd_pins_sleep: lcd_pins_sleep {
			pinctrl-single,pins = <
				0x38 (PIN_INPUT_PULLDOWN | MUX_MODE7)	/* gpmc_ad8.lcd_data16 NOTE On EVM DTS = 20 gpmc_ad8.lcd_data16*/
				0x3C (PIN_INPUT_PULLDOWN | MUX_MODE7)	/* gpmc_ad9.lcd_data17 NOTE on EVM DTS = 24 gpmc_ad9.lcd_data17*/
				0xa0 (PULL_DISABLE | MUX_MODE7)		/* lcd_data0.lcd_data0 */
				0xa4 (PULL_DISABLE | MUX_MODE7)		/* lcd_data1.lcd_data1 */
				0xa8 (PULL_DISABLE | MUX_MODE7)		/* lcd_data2.lcd_data2 */
				0xac (PULL_DISABLE | MUX_MODE7)		/* lcd_data3.lcd_data3 */
				0xb0 (PULL_DISABLE | MUX_MODE7)		/* lcd_data4.lcd_data4 */
				0xb4 (PULL_DISABLE | MUX_MODE7)		/* lcd_data5.lcd_data5 */
				0xb8 (PULL_DISABLE | MUX_MODE7)		/* lcd_data6.lcd_data6 */
				0xbc (PULL_DISABLE | MUX_MODE7)		/* lcd_data7.lcd_data7 */
				0xc0 (PULL_DISABLE | MUX_MODE7)		/* lcd_data8.lcd_data8 */
				0xc4 (PULL_DISABLE | MUX_MODE7)		/* lcd_data9.lcd_data9 */
				0xc8 (PULL_DISABLE | MUX_MODE7)		/* lcd_data10.lcd_data10 */
				0xcc (PULL_DISABLE | MUX_MODE7)		/* lcd_data11.lcd_data11 */
				0xd0 (PULL_DISABLE | MUX_MODE7)		/* lcd_data12.lcd_data12 */
				0xd4 (PULL_DISABLE | MUX_MODE7)		/* lcd_data13.lcd_data13 */
				0xd8 (PULL_DISABLE | MUX_MODE7)		/* lcd_data14.lcd_data14 */
				0xdc (PULL_DISABLE | MUX_MODE7)		/* lcd_data15.lcd_data15 */
				0xe0 (PIN_INPUT_PULLDOWN | MUX_MODE7)	/* lcd_vsync.lcd_vsync, OUTPUT | MODE0 */
				0xe4 (PIN_INPUT_PULLDOWN | MUX_MODE7)	/* lcd_hsync.lcd_hsync */
				0xe8 (PIN_INPUT_PULLDOWN | MUX_MODE7)	/* lcd_pclk.lcd_pclk */
				0xec (PIN_INPUT_PULLDOWN | MUX_MODE7)	/* lcd_ac_bias_en.lcd_ac_bias_en */
				0x28 (PIN_OUTPUT_PULLUP  | MUX_MODE7)   /* gpmc.ad10.gpio0.26 */
			>;

		lcdc: lcdc@0x4830e000 {		
			pinctrl-names = "default", "sleep";
			pinctrl-0 = <&lcd_pins_default>;
			pinctrl-1 = <&lcd_pins_sleep>;
			status = "okay";
			display-timings {
				640x480p62 {
					clock-frequency = <23000000 25000000 30000000>;
					hactive = <640>;       
					vactive = <480>;
					hfront-porch = <1 16 116>;
					hback-porch = <1 114 139>;
					hsync-len = <5 30 133>;
					vback-porch = <30 32 34>;
					vfront-porch = <1 10 45>;
					vsync-len = <1 3 5>;
					hsync-active = <1>;
					vsync-active = <1>;
					pixelclk-active = <1>;
				};
			};


4) We have configured the kernel to use fbdev. Therefore the following .config options are set

    • CONFIG_FB_DA8XX
    • CONFIG_FB_DA8XX_TDA99x

5) The backlight hasn't been configured hardware wise yet so the backlight is kept ON and not adjusted yet.

6) When I boot up the board, the LCD does appear to be trying to display the standard logo. However, we are getting flicker and 3 images of the logo.

To me it looks like we have a scanning/sync issue.

7) The documentation for the LCD says to use either SYNC mode or DE mode.

I am not sure how to configure that either via the .config or via a device tree. 

Therefore I am not sure whether DE is being enabled or not. (NOTE: DE on the LCD is connected to lcd_ac_bias_en.lcd_ac_bias_en from the am335x LCD controller).

8) So, the question is there anything else I need to consider? Do I need to create a specific LCD driver for this part or will the am335x LCD controller be sufficient?

 

Anyway, further insight or suggestion would be greatly appreciated.

 

Peter M.

 

  • 0
    TI__Guru**** 393215 points

    Hi Peter,

    Have you followed the color assignment of the LCD data pins as described in AM335X Errata Usage Note 3.1.1? Have you measured the actual pixel clock frequency?

  • 0 in reply to Biser Gatchev-XID
    Intellectual 680 points
    Hi Biser,

    Yes, we followed the 24-bit configuration. But please note that the LCD that we have is 18-bit colour.
    So, we have assigned the following:

    Assigned AM335X signals LCD_DATA[10:5] to our LCD GREEN[5:0]
    Assigned AM335X signals LCD_DATA[15:11] to our display LCD BLUE[5:1], LCD_DATA17 is BLUE0
    Assigned AM335X signals LCD_DATA[4:0] to our display LCD RED[5:1], LCD_DATA16 is RED0

    I haven't yet measured the pixel clock (DCLK).

    According to the LCD doc, the clock is supposed to be 25Mhz.

    We are also going through a LVDS and using the DCLK as the clock in.

    So, we are observing the standard Linux Logo at startup but there are 3 images of it and the LCD is flickering quite a bit.
  • 0 in reply to Peter M
    TI__Guru**** 393215 points

    Here is a wiki article about LCD connectivity that you may find helpful: http://processors.wiki.ti.com/index.php/LCD_connectivity

  • 0 in reply to Biser Gatchev-XID
    Intellectual 680 points
    Thanks Biser. The article was helpful. And like the article indicated, we are using 24 bit mode but only connecting the upper 6 bits.

    In AM335x Errata, it has the following assignments for the colours on the LCD data

    LCD Data 0 - 4 = Red3 - Red7
    LCD Data 5 - 10 = Green2 - Green7
    LCD Data 11 - 15 = Blue3 - Blue7
    LCD Data 16 = Red2
    LCD Data 17 = Blue2
    LCD Data 18 = Red1
    LCD Data 19 = Green1
    LCD Data 20 = Blue1
    LCD Data 21 = Red0
    LCD Data 22 = Green0
    LCD Data 23 = Blue0

    Which is different that the article you mention. It has
    DSS 0 - 7 = Blue0 - Blue7
    DSS 8 - 15 = Green0 - Green7
    DSS 16 - 23 = Red0 - Red7

    So, I assume that that article is using a different LCD controller then the AM335x
  • 0 in reply to Peter M
    TI__Guru**** 393215 points

    Yes, you are right. This is an old article based on OMAP processors. The important part is how the color bits are packed in the LVDS transmitter (which color bit goes to which LVDS input).

  • 0 in reply to Biser Gatchev-XID
    Intellectual 680 points
    Hi Biser,

    We check the lines into the LVDS and we beliee they are correct (and follow similar to your wiki above).
    So, I scope the lines.
    1) DCLK looks correct.
    2) VSYNC and HSYNC do not. I would have expected VSYNC to occur every so many HYSNC, but that doesn't seem to be happening. They do not seem to have any relationship and their period doesn't make what I was expected when I setup the device tree.

    3) I am simply sending a 24-bit BMP to the framebuffer (as per this link http://processors.wiki.ti.com/index.php/AM335x_LCD_Controller_Driver's_Guide
    and I am not getting the expected pattern on the screen.

    I have the DA8X enabled (configured as per the above guide as well.

    So, do I need to dig into the DA8Xx to figure out why the timing is incorrect?

    Is that normal practice, even though I configure the Device Tree up (see below)?

    Do you have a document that describes how the graphic system works and which code it calls so that I can make sure I am tracing it correct?

    Any other suggestions would be appreciated.

    lcd_pins_default: lcd_pins_default {
    pinctrl-single,pins = <
    0x38 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* gpmc_ad14.lcd_data17, NOTE On EVM DTS = 20 gpmc_ad8.lcd_data16 */
    0x3C (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* gpmc_ad15.lcd_data16, NOTE on EVM DTS = 24 gpmc_ad9.lcd_data17 */
    0xa0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data0.lcd_data0, */
    0xa4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data1.lcd_data1, */
    0xa8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data2.lcd_data2, */
    0xac (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data3.lcd_data3, */
    0xb0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data4.lcd_data4, */
    0xb4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data5.lcd_data5, */
    0xb8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data6.lcd_data6, */
    0xbc (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data7.lcd_data7, */
    0xc0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data8.lcd_data8, */
    0xc4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data9.lcd_data9, */
    0xc8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data10.lcd_data10, */
    0xcc (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data11.lcd_data11, */
    0xd0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data12.lcd_data12, */
    0xd4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data13.lcd_data13, */
    0xd8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data14.lcd_data14, */
    0xdc (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_data15.lcd_data15, */
    0xe0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_vsync.lcd_vsync, */
    0xe4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_hsync.lcd_hsync, */
    0xe8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_pclk.lcd_pclk, */
    0xec (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_ac_bias_en.lcd_ac_bias_en, */
    0x28 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc.ad10.gpio0.26 */
    >;
    };



    lcdc: lcdc@0x4830e000 {
    pinctrl-names = "default", "sleep";
    pinctrl-0 = <&lcd_pins_default>;
    pinctrl-1 = <&lcd_pins_sleep>;
    status = "okay";
    display-timings {
    640x480p62 {
    clock-frequency = <25000000>;
    hactive = <640>;
    vactive = <480>;
    hfront-porch = <16>;
    hback-porch = <114>;
    hsync-len = <30>;
    vback-porch = <32>;
    vfront-porch = <10>;
    vsync-len = <3>;
    hsync-active = <0>;
    vsync-active = <0>;
    pixelclk-active = <1>;
    };
    };
  • 0 in reply to Peter M
    TI__Guru**** 393215 points

    Have you checked what happens at the other end of the LVDS pair? Do you see DE signal toggling?

  • 0 in reply to Biser Gatchev-XID
    Intellectual 680 points
    Hi Biser,

    The display supports both DE and VSYNC/HSYNC and the data sheets says that when using VSYNC/HSYNC, DE should be set to low, which is what we did.

    Peter Montgomery
  • 0 in reply to Peter M
    TI__Guru**** 393215 points

    Peter,

    Just an idea - could you turn DE on to see if the LCD will respond? Otherwise without having the actual LCD datasheet I'm afraid I can't help. Everything you've done seems proper from the LCD driver chip perspective, but I think you need the real datasheet.

  • 0 in reply to Biser Gatchev-XID
    Intellectual 680 points
    Hi Biser,

    I compared the VSYNC and HSYNC signals from the AM335X against the same signals going into the actual LCD. I wanted to make sure that the LVDS was multiplexing/demultiplexing (using a scope). I noticed that the signals were different, which shouldn't have happened.

    I dropped the pixel clock speed significantly down to see if it would make a difference and the VSYNC and HSYNC signals 'started' to look better but there was still differences.

    The hardware folks took a closer look at the LVDS spec's and they did notice that a terminating resister was required between the differential paris (between the LVDS's).

    As mentioned before, we are using DS90CF363B LVDS transmitter beween the AM335x to minimize the connections between our board and are LCD assembly. The other end is a DS90CF366B LVDS receiver.

    Once we added the 150 ohm terminating resistors between each of the differential paris, the VSYNC and HSYNC signals look correct and the LCD displayed the correct image (at the correct clock speed as well).
  • 0 in reply to Peter M
    TI__Guru**** 393215 points

    Glad to hear you solved this!

  • 0 in reply to Biser Gatchev-XID
    Intellectual 680 points
    Hey Biser,

    Now that I have tackled the LCD image beast, I need to get the touch screen to work.
    So, our display is a 4-wire resistive touch.
    And the hardware folks have tied the AIN0 - AIN3 to the corresponding 4 wires on the display (X LEFT, X RIGHT, Y UP, Y DOWN).
    Now, here is where I start to be unsure.
    The assumption is that the TSC and ADC would use the same lines. So in the device tree, I have the following:
    &tscadc {
    status = "okay";
    tsc {
    ti,wires = <4>;
    ti,x-plate-resistance = <300>;
    ti,coordinate-readouts = <5>;
    ti,wire-config = <0x01 0x10 0x22 0x33>;
    };

    adc {
    ti,adc-channels = <0 1 2 3>;
    };
    };

    Now, my questions are:
    1) Do I still need to update the pinmux to configure the AD lines?
    2) Does the TI_am335x_TSC adc driver support this type of configuration, where the TSC and ADC are interleaved?
  • 0 in reply to Peter M
    TI__Guru**** 393215 points

    I'm not a software expert, but TSC/ADC interleaving will not work, they need to be on separate channels. See this wiki for details on the driver: http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User's_Guide

  • 0 in reply to Biser Gatchev-XID
    Intellectual 680 points
    Hi Biser,
    Sorry for the long delay.

    I got the touchscreen to work. My final TSC was
    &tscadc {
    status = "okay";
    tsc {
    ti,wires = <4>;
    ti,x-plate-resistance = <300>;
    ti,coordinate-readouts = <5>;
    ti,wire-config = <0x00 0x11 0x22 0x33>;
    };
    };

    And I am currently not using the ADC so I didn't need to add them to the DT.