| Message ID | 1403612666-31197-4-git-send-email-pekon@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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?
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 > -- 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
>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 -- 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
>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
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.
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 -- 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
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
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 > -- 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
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 -- 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
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>;
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