[PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Gupta, Pekon]

Hi Daren, Guido,

>From: Etheridge, Darren
>>On 06/26/2014 10:40 AM, Guido Martínez wrote:
>> I had some issues with this patch. Booting linux-next on a BeagleBone
>> Black with this exact LCD left me with an unusable white screen. Please
>> see below for some details.
>>
>>> On Tue, Jun 24, 2014 at 05:54:26PM +0530, Pekon Gupta wrote:
>>> This patch adds support for LCD4 cape as advertised on
>>>    http://elinux.org/CircuitCo:BeagleBone_LCD4
>>>
>>> This cape has:
>>> * 480x272 TFT-LCD panel
>>>   - LCD panel datasheet and timing information are sourced from [1]
>>>   - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
>>>     enabling backlight power-supply. So 'gpio-backlight' driver is used instead
>>>     of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
>>>
>>> * 4-wire resistive Touchscreen
>>>
>>> *Known constrains*
>>> As LCD panel pins (lcd_data, hsync, vsync, pclk) are shared with on-board
>>> NXP HDMI framer, so either HDMI or LCD-cape can be used at time. Thus while
>>> using this cape 'hdmi' DT node needs to be disabled in am335x-boneblack.dts
>>>
>>> [1] www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
>>>      www.newhavendisplay.com/app_notes/OTA5180A.pdf
>>>
>>> Signed-off-by: Pekon Gupta <pekon at ti.com>
>>> ---
>
><snip>
>
>>> +
>>> +	panel {
>>> +		status = "disabled";
>>> +		compatible = "ti,tilcdc,panel";
>>> +		pinctrl-names = "default";
>>> +		pinctrl-0 = <&bbcape_lcd_pins>;
>>> +		panel-info {
>>> +			ac-bias           = <255>;
>>> +			ac-bias-intrpt    = <0>;
>>> +			dma-burst-sz      = <16>;
>>> +			bpp               = <16>;
>>> +			fdd               = <0x80>;
>>> +			sync-edge         = <0>;
>>> +			sync-ctrl         = <0>;
>> I had to set this to <1>. Does that make sense?
>>
Yes, I'll check this one again at my end.

>>> +			raster-order      = <0>;
>>> +			fifo-th           = <0>;
>>> +		};
>>> +		display-timings {
>>> +			native-mode = <&timing0>;
>>> +			/* www.newhavendisplay.com/app_notes/OTA5180A.pdf */
>>> +			timing0: 480x272 {
>>> +				clock-frequency = <30000000>;
>>> +				hactive = <480>;
>>> +				vactive = <272>;
>>> +				hfront-porch = <8>;
>>> +				hback-porch = <47>;
>>> +				hsync-len = <41>;
>>> +				vback-porch = <2>;
>>> +				vfront-porch = <3>;
>>> +				vsync-len = <10>;
>>> +				hsync-active = <0>;
>>> +				vsync-active = <0>;
>>> +				de-active = <1>;
>>> +				pixelclk-active = <0>;
>> Are you sure these timings are ok? When enabling the sync control I get
>> an usable display, but it looks a bit funny. For example an all black
>> display looks very clear and has a dotted pattern.
>>
>> I tried to take a picture of it but it doesn't show.
>>
I could run and test 'fbtest' and 'fbconsole' on this cape, using following configs
CONFIG_DRM=y
CONFIG_DRM_TILCDC=y
[...]
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FRAMEBUFFER_CONSOLE=y


>These timings look wrong to me, for instance this sets a clock frequency
>of 30MHz where as the linked app-note says 9MHz.  I think the LCD4 cape
>uses the same LCD panel as is used on the AM335x EVMSK.  Therefore the
>display timings from my DT patch for the EVMSK should work:
>https://patchwork.kernel.org/patch/4144801/
>
Yes, probably I got the pixel-clock timing wrong, I'll fix this.
It should be 9.2MHz as per
www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
Table: Electrical Characteristics
But as 'hsync' timings are relative to pixel-clock somehow it worked for me.

I got other vsync and hsync timings from following reference:
	www.newhavendisplay.com/app_notes/OTA5180A.pdf
	Table: 8.4.1 480XRGBX272 Vertical Timing
	Table: 8.4.2 480XRGBX272 Horizontal Timing
And I/O signal polarity for vsync-active and hsync-active from
	Table: 5. SIGNAL DESCRIPTIONS


with regards, pekon