diff mbox

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

Message ID 1403612666-31197-4-git-send-email-pekon@ti.com
State Not Applicable
Headers show

Commit Message

pekon gupta June 24, 2014, 12:24 p.m. UTC 
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@ti.com>
---
 arch/arm/boot/dts/am335x-bone-display-cape.dts | 104 +++++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts              |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts         |   1 +
 3 files changed, 106 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bone-display-cape.dts

Comments

Ezequiel Garcia June 24, 2014, 3:03 p.m. UTC | #1 
Hello Pekon,

On 24 Jun 05:54 PM, 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).
> 

I'm confused about this, can you clarify why you are not using pwm-backlight?
Jason Kridner June 24, 2014, 3:24 p.m. UTC | #2 
On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta <pekon@ti.com> 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@ti.com>
> ---
>  arch/arm/boot/dts/am335x-bone-display-cape.dts | 104 +++++++++++++++++++++++++
>  arch/arm/boot/dts/am335x-bone.dts              |   1 +
>  arch/arm/boot/dts/am335x-boneblack.dts         |   1 +
>  3 files changed, 106 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am335x-bone-display-cape.dts
>
> diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-display-cape.dts

If this is mean to be included, why not use the .dtsi extension rather
than .dts. .dts implies it is a top-level file.

> new file mode 100644
> index 0000000..f3b7cef
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bone-display-cape.dts
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This DTS adds supports for display capes using LCD interface for display
> + * and GPIO or PWM interface for backlight controls.
> + */
> +
> +
> +&am33xx_pinmux {
> +       bbcape_backlight_pins: bbcape_backlight_pins {
> +               pinctrl-single,pins = <
> +                       0x48  (PIN_OUTPUT | MUX_MODE7)          /* gpmc_a[2].GPIO1[18] (backlight control) */
> +               >;
> +       };
> +
> +       bbcape_lcd_pins: bbcape_lcd_pins {
> +               pinctrl-single,pins = <
> +                       0xa0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data0.lcd_data0 */
> +                       0xa4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data1.lcd_data1 */
> +                       0xa8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data2.lcd_data2 */
> +                       0xac (PIN_OUTPUT | MUX_MODE0)           /* lcd_data3.lcd_data3 */
> +                       0xb0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data4.lcd_data4 */
> +                       0xb4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data5.lcd_data5 */
> +                       0xb8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data6.lcd_data6 */
> +                       0xbc (PIN_OUTPUT | MUX_MODE0)           /* lcd_data7.lcd_data7 */
> +                       0xc0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data8.lcd_data8 */
> +                       0xc4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data9.lcd_data9 */
> +                       0xc8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data10.lcd_data10 */
> +                       0xcc (PIN_OUTPUT | MUX_MODE0)           /* lcd_data11.lcd_data11 */
> +                       0xd0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data12.lcd_data12 */
> +                       0xd4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data13.lcd_data13 */
> +                       0xd8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data14.lcd_data14 */
> +                       0xdc (PIN_OUTPUT | MUX_MODE0)           /* lcd_data15.lcd_data15 */
> +                       0xe0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_vsync.lcd_vsync */
> +                       0xe4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_hsync.lcd_hsync */
> +                       0xe8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_pclk.lcd_pclk */
> +                       0xec (PIN_OUTPUT | MUX_MODE0)           /* lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */
> +                       0x1a4 (PIN_OUTPUT_PULLUP | MUX_MODE7)   /* mcasp0_fsr.gpio3[19] (lcd_disen) */
> +               >;
> +       };
> +
> +       bbcape_touchscreen_pins: bbcape_touchscreen_pins {
> +               pinctrl-single,pins = <
> +                       0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* uart1_txd.gpio0[15] (enter) */
> +                       0x40  (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* gpmc_a0.gpio1[16] (left) */
> +                       0x44  (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* gpmc_a1.gpio1[17] (right) */
> +                       0x4c  (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* gpmc_a3.gpio1[19] (up) */
> +                       0x198 (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* mcasp0_axr0.gpio3[16] (down) */
> +               >;
> +       };
> +};
> +
> +
> +/ {
> +       backlight {
> +               status = "disabled";
> +               compatible = "gpio-backlight";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&bbcape_backlight_pins>;
> +               gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
> +               default-on;
> +       };
> +
> +       panel {
> +               status = "disabled";

Where are you expecting to enable this? I'm guessing through your
u-boot hacking? Certainly I can see editing the boot script to make
this work, but I don't see how this results in the average user simply
plugging in the cape and having it work without having to edit files.
Perhaps you can put some real logic into the bootloader that looks at
the cape EEPROMs?

Have you considered using tools like pinmux-helper as is done with the
cape-universal overlay?
https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-universal-00A0.dts

I've been hacking with adding all of these pinmux helpers to the main
.dts. I think you are encouraging me to add it to include files to
make it a bit more granular.

http://paste.debian.net/106319/

> +               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>;
> +                       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>;
> +                       };
> +               };
> +       };
> +};

I appreciate the enthusiasm to get this support into the mainline. If
it goes, I'll try to follow with a bunch of other outstanding changes
we have sitting in the vendor tree right now.

Have you looked at the features in the devicetree for this cape that
is currently pushed in the vendor tree?

https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-BONE-LCD4-01-00A1.dts

> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index f16bfcf..41439dc 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -10,6 +10,7 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  #include "am335x-bone-memory-cape.dts"
> +#include "am335x-bone-display-cape.dts"
>
>  &ldo3_reg {
>         regulator-min-microvolt = <1800000>;
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
> index e6d7e54..03232c7 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -10,6 +10,7 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  #include "am335x-bone-memory-cape.dts"
> +#include "am335x-bone-display-cape.dts"
>
>  &ldo3_reg {
>         regulator-min-microvolt = <1800000>;
> --
> 1.8.5.1.163.gd7aced9
>
pekon gupta June 25, 2014, 4:38 a.m. UTC | #3 
>From: Ezequiel Garcia
>>On 24 Jun 05:54 PM, 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).
>>
>
>I'm confused about this, can you clarify why you are not using pwm-backlight?
>

As per the schematics of this LCD4 cape board, "EHRPWM1A" pin controls
enabling/disabling of the power to backlight LED. It does not control the
voltage levels (brightness levels) of the LED. Thus it wasn't making sense
to use pwm-backlight driver which more suitable in cases where you have
multiple levels of brightness.
Here, you have only 2 levels "backlight=off | on", so I used gpio-backlight driver.
Though you can use pwm-backlight driver also, but the backlight turns ON
only when you set the /sys/class/backlight/<backlight_device>/brighteness
to maximum level (as set in DT).


with regards, pekon
pekon gupta June 25, 2014, 5:49 a.m. UTC | #4 
>From: Jason Kridner [mailto:jkridner@gmail.com]
>On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta <pekon@ti.com> wrote:
>> This patch adds support for LCD4 cape as advertised on
>>   http://elinux.org/CircuitCo:BeagleBone_LCD4
[...]

>>
>> diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-
>display-cape.dts
>
>If this is mean to be included, why not use the .dtsi extension rather
>than .dts. .dts implies it is a top-level file.
>
I followed the ideology given in in below discussion
http://comments.gmane.org/gmane.linux.drivers.devicetree/13921

As I understood .dtsi file extension should be used for silicon DT data which
which remains common for all the boards using that silicon (like am33xx.dtsi).
And .dts is for board specific DT data.
However, anything works for me, as its just matter of file-name-extension.	
So should I rename all files to .dtsi ?

[...]

>> +/ {
>> +       backlight {
>> +               status = "disabled";
>> +               compatible = "gpio-backlight";
>> +               pinctrl-names = "default";
>> +               pinctrl-0 = <&bbcape_backlight_pins>;
>> +               gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
>> +               default-on;
>> +       };
>> +
>> +       panel {
>> +               status = "disabled";
>
>Where are you expecting to enable this? I'm guessing through your
>u-boot hacking? Certainly I can see editing the boot script to make
>this work, but I don't see how this results in the average user simply
>plugging in the cape and having it work without having to edit files.
>
Yes, using u-boot commands, *without touching any source file*.
I'm planning to send patch for adding following helper commands  in u-boot
u-boot> fdt node enable <node-path>
u-boot> fdt node disable <node-path>
If that's accepted, enabling disabling capes will become very easy.
And, as you said user can put these commands in scripts (like Uenv.txt)
or environment variable, and execute them automatically at each boot.


>Perhaps you can put some real logic into the bootloader that looks at
>the cape EEPROMs?
>
No, I don't want to go the EEPROM way, because of reasons suggested
in earlier mail. It's not scalable, especially when you don't have control
over what type and how third-party is developing the capes.


>Have you considered using tools like pinmux-helper as is done with the
>cape-universal overlay?
>https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-universal-
>00A0.dts
>
Yes, I have seen that. In pin-mux helper pins are configured not based on
their actual names but as they appear on P8 and P9 headers of Beaglebone.
- For shared pins, you have defined all possible functionality.
- For dedicated pins, there is single fragment.
Now there are two questions..
(1) Do we need to update this cape-universal-xx.dts everytime a new
Cape in market uses some dedicated pin for some muxed functionality ?
(2) I'm not sure but kernel does _not_ free the memory allocated to 
DT fragment. If so, this universal fragment which has pin-mux for all
P8 and P9 pins will block the memory forever. Would be good to know
the in-memory size required for this universal fragment ?


>I've been hacking with adding all of these pinmux helpers to the main
>.dts. I think you are encouraging me to add it to include files to
>make it a bit more granular.
>
>http://paste.debian.net/106319/
>
Yes, using include files would be good.
Also one minor feedback. Please use macros for Pin directions, Pulls, etc
instead of hex numbers, it make it more readable. And then you don't need
to specify that in comments.
-  0xa0 0x08	/* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
+ 0xa0	(OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA)    /* lcd_data0.lcd_data0 */


>I appreciate the enthusiasm to get this support into the mainline. If
>it goes, I'll try to follow with a bunch of other outstanding changes
>we have sitting in the vendor tree right now.
>
Thanks. Waiting for Tony to at-least 'Ack' or say if this is acceptable approach.


>Have you looked at the features in the devicetree for this cape that
>is currently pushed in the vendor tree?
>
>https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-BONE-LCD4-
>01-00A1.dts
>
Yes, I have not added touchscreen support.
I developed this DTS independently while debugging some Display v/s NAND issue.
If these DTS patches are acceptable, then I'll refine them further.


with regards, pekon
Ezequiel Garcia June 25, 2014, 2:59 p.m. UTC | #5 
On 25 Jun 04:38 AM, Gupta, Pekon wrote:
> >From: Ezequiel Garcia
> >>On 24 Jun 05:54 PM, 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).
> >>
> >
> >I'm confused about this, can you clarify why you are not using pwm-backlight?
> >
> 
> As per the schematics of this LCD4 cape board, "EHRPWM1A" pin controls
> enabling/disabling of the power to backlight LED. It does not control the
> voltage levels (brightness levels) of the LED. Thus it wasn't making sense
> to use pwm-backlight driver which more suitable in cases where you have
> multiple levels of brightness.
> Here, you have only 2 levels "backlight=off | on", so I used gpio-backlight driver.
> Though you can use pwm-backlight driver also, but the backlight turns ON
> only when you set the /sys/class/backlight/<backlight_device>/brighteness
> to maximum level (as set in DT).
> 

Hm, I didn't know that. Thanks for this information.
Jason Kridner June 26, 2014, 4:30 a.m. UTC | #6 
On Wed, Jun 25, 2014 at 1:49 AM, Gupta, Pekon <pekon@ti.com> wrote:
>>From: Jason Kridner [mailto:jkridner@gmail.com]
>>On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta <pekon@ti.com> wrote:
>>> This patch adds support for LCD4 cape as advertised on
>>>   http://elinux.org/CircuitCo:BeagleBone_LCD4
> [...]
>
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-
>>display-cape.dts
>>
>>If this is mean to be included, why not use the .dtsi extension rather
>>than .dts. .dts implies it is a top-level file.
>>
> I followed the ideology given in in below discussion
> http://comments.gmane.org/gmane.linux.drivers.devicetree/13921
>
> As I understood .dtsi file extension should be used for silicon DT data which
> which remains common for all the boards using that silicon (like am33xx.dtsi).
> And .dts is for board specific DT data.
> However, anything works for me, as its just matter of file-name-extension.
> So should I rename all files to .dtsi ?

I believe the thread is not thinking of "board-level" as being add-on
boards. I don't think it disagrees that if it is an include file, it
should be called .dtsi. If it is called .dts, the assumption should be
that it results in a .dtb (or .dtbo if for an overlay --- not yet a
solution in mainline).

>
> [...]
>
>>> +/ {
>>> +       backlight {
>>> +               status = "disabled";
>>> +               compatible = "gpio-backlight";
>>> +               pinctrl-names = "default";
>>> +               pinctrl-0 = <&bbcape_backlight_pins>;
>>> +               gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
>>> +               default-on;
>>> +       };
>>> +
>>> +       panel {
>>> +               status = "disabled";
>>
>>Where are you expecting to enable this? I'm guessing through your
>>u-boot hacking? Certainly I can see editing the boot script to make
>>this work, but I don't see how this results in the average user simply
>>plugging in the cape and having it work without having to edit files.
>>
> Yes, using u-boot commands, *without touching any source file*.
> I'm planning to send patch for adding following helper commands  in u-boot
> u-boot> fdt node enable <node-path>
> u-boot> fdt node disable <node-path>
> If that's accepted, enabling disabling capes will become very easy.
> And, as you said user can put these commands in scripts (like Uenv.txt)
> or environment variable, and execute them automatically at each boot.
>
>
>>Perhaps you can put some real logic into the bootloader that looks at
>>the cape EEPROMs?
>>
> No, I don't want to go the EEPROM way, because of reasons suggested
> in earlier mail. It's not scalable, especially when you don't have control
> over what type and how third-party is developing the capes.

Well, I have no interest in needing to manually switch my uEnv.txt
file based on whatever cape I have installed. Your patches to put
by-default-disabled disabled support for various capes into the the
main .dtb feels useful to me. I'm just going to optimize my systems to
utilize the EEPROM (when provided) to trigger loading the
configuration for me.

>
>
>>Have you considered using tools like pinmux-helper as is done with the
>>cape-universal overlay?
>>https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-universal-
>>00A0.dts
>>
> Yes, I have seen that. In pin-mux helper pins are configured not based on
> their actual names but as they appear on P8 and P9 headers of Beaglebone.
> - For shared pins, you have defined all possible functionality.
> - For dedicated pins, there is single fragment.
> Now there are two questions..
> (1) Do we need to update this cape-universal-xx.dts everytime a new
> Cape in market uses some dedicated pin for some muxed functionality ?

cape-universalXXX.dts needs to be moved into the main .dtb (via
.dtsi). Can you give an example of what you mean by shared pins and
dedicated pins here? It seems to me all the pins have multiple
fragments except ADC pins and perhaps the I2C port used for expansion
EEPROMs, but even that one CAN be muxed.

> (2) I'm not sure but kernel does _not_ free the memory allocated to
> DT fragment. If so, this universal fragment which has pin-mux for all
> P8 and P9 pins will block the memory forever. Would be good to know
> the in-memory size required for this universal fragment ?

How can I check easily? Obviously loading all of these drivers is
going to have an impact.

>
>
>>I've been hacking with adding all of these pinmux helpers to the main
>>.dts. I think you are encouraging me to add it to include files to
>>make it a bit more granular.
>>
>>http://paste.debian.net/106319/
>>
> Yes, using include files would be good.
> Also one minor feedback. Please use macros for Pin directions, Pulls, etc
> instead of hex numbers, it make it more readable. And then you don't need
> to specify that in comments.
> -  0xa0 0x08    /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> + 0xa0  (OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA)    /* lcd_data0.lcd_data0 */

If those are supported in the syntax and exist in some headers, I will use them.

>
>
>>I appreciate the enthusiasm to get this support into the mainline. If
>>it goes, I'll try to follow with a bunch of other outstanding changes
>>we have sitting in the vendor tree right now.
>>
> Thanks. Waiting for Tony to at-least 'Ack' or say if this is acceptable approach.
>
>
>>Have you looked at the features in the devicetree for this cape that
>>is currently pushed in the vendor tree?
>>
>>https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-BONE-LCD4-
>>01-00A1.dts
>>
> Yes, I have not added touchscreen support.
> I developed this DTS independently while debugging some Display v/s NAND issue.
> If these DTS patches are acceptable, then I'll refine them further.
>
>
> with regards, pekon
Guido Martínez June 26, 2014, 3:40 p.m. UTC | #7 
Hi Pekon,

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@ti.com>
> ---
>  arch/arm/boot/dts/am335x-bone-display-cape.dts | 104 +++++++++++++++++++++++++
>  arch/arm/boot/dts/am335x-bone.dts              |   1 +
>  arch/arm/boot/dts/am335x-boneblack.dts         |   1 +
>  3 files changed, 106 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am335x-bone-display-cape.dts
> 
> diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-display-cape.dts
> new file mode 100644
> index 0000000..f3b7cef
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bone-display-cape.dts
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This DTS adds supports for display capes using LCD interface for display
> + * and GPIO or PWM interface for backlight controls.
> + */
> +
> +
> +&am33xx_pinmux {
> +	bbcape_backlight_pins: bbcape_backlight_pins {
> +		pinctrl-single,pins = <
> +			0x48  (PIN_OUTPUT | MUX_MODE7)		/* gpmc_a[2].GPIO1[18] (backlight control) */
> +		>;
> +	};
> +
> +	bbcape_lcd_pins: bbcape_lcd_pins {
> +		pinctrl-single,pins = <
> +			0xa0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data0.lcd_data0 */
> +			0xa4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data1.lcd_data1 */
> +			0xa8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data2.lcd_data2 */
> +			0xac (PIN_OUTPUT | MUX_MODE0)		/* lcd_data3.lcd_data3 */
> +			0xb0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data4.lcd_data4 */
> +			0xb4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data5.lcd_data5 */
> +			0xb8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data6.lcd_data6 */
> +			0xbc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data7.lcd_data7 */
> +			0xc0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data8.lcd_data8 */
> +			0xc4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data9.lcd_data9 */
> +			0xc8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data10.lcd_data10 */
> +			0xcc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data11.lcd_data11 */
> +			0xd0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data12.lcd_data12 */
> +			0xd4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data13.lcd_data13 */
> +			0xd8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data14.lcd_data14 */
> +			0xdc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data15.lcd_data15 */
> +			0xe0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_vsync.lcd_vsync */
> +			0xe4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_hsync.lcd_hsync */
> +			0xe8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_pclk.lcd_pclk */
> +			0xec (PIN_OUTPUT | MUX_MODE0)		/* lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */
> +			0x1a4 (PIN_OUTPUT_PULLUP | MUX_MODE7)	/* mcasp0_fsr.gpio3[19] (lcd_disen) */
> +		>;
> +	};
> +
> +	bbcape_touchscreen_pins: bbcape_touchscreen_pins {
> +		pinctrl-single,pins = <
> +			0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* uart1_txd.gpio0[15] (enter) */
> +			0x40  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a0.gpio1[16] (left) */
> +			0x44  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a1.gpio1[17] (right) */
> +			0x4c  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a3.gpio1[19] (up) */
> +			0x198 (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* mcasp0_axr0.gpio3[16] (down) */
> +		>;
> +	};
> +};
> +
> +
> +/ {
> +	backlight {
> +		status = "disabled";
> +		compatible = "gpio-backlight";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bbcape_backlight_pins>;
> +		gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
> +		default-on;
> +	};
> +
> +	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? 

> +			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.

Also I'm just guessing about the timings, maybe it's something else?

> +			};
> +		};
> +	};
> +};
> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index f16bfcf..41439dc 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -10,6 +10,7 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  #include "am335x-bone-memory-cape.dts"
> +#include "am335x-bone-display-cape.dts"
>  
>  &ldo3_reg {
>  	regulator-min-microvolt = <1800000>;
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
> index e6d7e54..03232c7 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -10,6 +10,7 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  #include "am335x-bone-memory-cape.dts"
> +#include "am335x-bone-display-cape.dts"
>  
>  &ldo3_reg {
>  	regulator-min-microvolt = <1800000>;
> -- 
> 1.8.5.1.163.gd7aced9
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Etheridge, Darren June 26, 2014, 6:35 p.m. UTC | #8 
Guido, Pekon,

On 06/26/2014 10:40 AM, Guido Martínez wrote:
> Hi Pekon,
>
> 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@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?
>
>> +			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.

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/

Darren

>
> Also I'm just guessing about the timings, maybe it's something else?
>
>> +			};
>> +		};
>> +	};
>> +};
>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>> index f16bfcf..41439dc 100644
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> @@ -10,6 +10,7 @@
>>   #include "am33xx.dtsi"
>>   #include "am335x-bone-common.dtsi"
>>   #include "am335x-bone-memory-cape.dts"
>> +#include "am335x-bone-display-cape.dts"
>>
>>   &ldo3_reg {
>>   	regulator-min-microvolt = <1800000>;
>> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
>> index e6d7e54..03232c7 100644
>> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> @@ -10,6 +10,7 @@
>>   #include "am33xx.dtsi"
>>   #include "am335x-bone-common.dtsi"
>>   #include "am335x-bone-memory-cape.dts"
>> +#include "am335x-bone-display-cape.dts"
>>
>>   &ldo3_reg {
>>   	regulator-min-microvolt = <1800000>;
>> --
>> 1.8.5.1.163.gd7aced9
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
pekon gupta June 27, 2014, 11:38 a.m. UTC | #9 
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@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
diff mbox

Patch

diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-display-cape.dts
new file mode 100644
index 0000000..f3b7cef
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-display-cape.dts
@@ -0,0 +1,104 @@ 
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This DTS adds supports for display capes using LCD interface for display
+ * and GPIO or PWM interface for backlight controls.
+ */
+
+
+&am33xx_pinmux {
+	bbcape_backlight_pins: bbcape_backlight_pins {
+		pinctrl-single,pins = <
+			0x48  (PIN_OUTPUT | MUX_MODE7)		/* gpmc_a[2].GPIO1[18] (backlight control) */
+		>;
+	};
+
+	bbcape_lcd_pins: bbcape_lcd_pins {
+		pinctrl-single,pins = <
+			0xa0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data0.lcd_data0 */
+			0xa4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data1.lcd_data1 */
+			0xa8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data2.lcd_data2 */
+			0xac (PIN_OUTPUT | MUX_MODE0)		/* lcd_data3.lcd_data3 */
+			0xb0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data4.lcd_data4 */
+			0xb4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data5.lcd_data5 */
+			0xb8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data6.lcd_data6 */
+			0xbc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data7.lcd_data7 */
+			0xc0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data8.lcd_data8 */
+			0xc4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data9.lcd_data9 */
+			0xc8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data10.lcd_data10 */
+			0xcc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data11.lcd_data11 */
+			0xd0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data12.lcd_data12 */
+			0xd4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data13.lcd_data13 */
+			0xd8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data14.lcd_data14 */
+			0xdc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data15.lcd_data15 */
+			0xe0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_vsync.lcd_vsync */
+			0xe4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_hsync.lcd_hsync */
+			0xe8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_pclk.lcd_pclk */
+			0xec (PIN_OUTPUT | MUX_MODE0)		/* lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */
+			0x1a4 (PIN_OUTPUT_PULLUP | MUX_MODE7)	/* mcasp0_fsr.gpio3[19] (lcd_disen) */
+		>;
+	};
+
+	bbcape_touchscreen_pins: bbcape_touchscreen_pins {
+		pinctrl-single,pins = <
+			0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* uart1_txd.gpio0[15] (enter) */
+			0x40  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a0.gpio1[16] (left) */
+			0x44  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a1.gpio1[17] (right) */
+			0x4c  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a3.gpio1[19] (up) */
+			0x198 (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* mcasp0_axr0.gpio3[16] (down) */
+		>;
+	};
+};
+
+
+/ {
+	backlight {
+		status = "disabled";
+		compatible = "gpio-backlight";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bbcape_backlight_pins>;
+		gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+		default-on;
+	};
+
+	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>;
+			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>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index f16bfcf..41439dc 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,7 @@ 
 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
 #include "am335x-bone-memory-cape.dts"
+#include "am335x-bone-display-cape.dts"
 
 &ldo3_reg {
 	regulator-min-microvolt = <1800000>;
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index e6d7e54..03232c7 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -10,6 +10,7 @@ 
 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
 #include "am335x-bone-memory-cape.dts"
+#include "am335x-bone-display-cape.dts"
 
 &ldo3_reg {
 	regulator-min-microvolt = <1800000>;