These patches complete the am335x LCDC color errata fix[1]. The functional patches are now queued for v4.9.
The patch for am335x-boneblack.dts is delayed until v4.10 or v4.9-rc phase to avoid conflickt with BBB HDMI audio DTS patch that slipped into tda998x pull request.
[1] http://www.spinics.net/lists/devicetree/msg141246.html
Jyri Sarha (3): ARM: dts: am335x-evm: Add blue-and-red-wiring -property to lcdc node ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes ARM: dts: am335x-evmsk: Add blue-and-red-wiring -property to lcdc node
arch/arm/boot/dts/am335x-evm.dts | 2 ++ arch/arm/boot/dts/am335x-evmsk.dts | 42 ++++++++++++++++++++------------------ 2 files changed, 24 insertions(+), 20 deletions(-)
Add blue-and-red-wiring -property to lcdc node. The am335x-evm has blue and red wires crossed to get 24-bit RGB (and 16-bit BGR) support. After this patch am335x-evm supports BGR565, RGB888, and XRGB8888 color formats. See details in Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.
Signed-off-by: Jyri Sarha jsarha@ti.com Reviewed-by: Tomi Valkeinen tomi.valkeinen@ti.com --- arch/arm/boot/dts/am335x-evm.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts index 5d28712..c3cbce0 100644 --- a/arch/arm/boot/dts/am335x-evm.dts +++ b/arch/arm/boot/dts/am335x-evm.dts @@ -497,6 +497,8 @@
&lcdc { status = "okay"; + + blue-and-red-wiring = "crossed"; };
&elm {
On 09/16/2016 06:50 AM, Jyri Sarha wrote: [..]
- blue-and-red-wiring = "crossed";
Dumb question: Why is this a Linux generic property - does it make sense to have "blue-and-red-wiring" as a Linux generic property? I mean, it reminds me little of those movies "cut the blue or red wire to diffuse the bomb" ;)
"The am335x-evm has blue and red wires crossed to get 24-bit RGB (and 16-bit BGR". I mean, there has to be some sort of better description specific to lcdc if some product used yellow and green wires for the same signals crossed?
On 09/17/16 01:17, Nishanth Menon wrote:
On 09/16/2016 06:50 AM, Jyri Sarha wrote: [..]
- blue-and-red-wiring = "crossed";
Dumb question: Why is this a Linux generic property - does it make sense to have "blue-and-red-wiring" as a Linux generic property? I mean, it reminds me little of those movies "cut the blue or red wire to diffuse the bomb" ;)
It is a property of "ti,tilcdc" node. I did not think I should add a ti specific prefix for it. And after all if some other SoC or display chip has the same bug (eg. blue and red colour components swapped between two different colour modes), they could use the same property.
Of course in theory, if such bugs were common, a generic property that would describe how connections between different display data wires are drawn could make sense, but AFAIK am335x is the only one out there with such a bug [1].
"The am335x-evm has blue and red wires crossed to get 24-bit RGB (and 16-bit BGR". I mean, there has to be some sort of better description specific to lcdc if some product used yellow and green wires for the same signals crossed?
The property and why it is there is described in detail in the binding document referred to in the commit description.
The functional patches, with the binding document can be found here: http://www.spinics.net/lists/devicetree/msg141246.html
[1] For more details see section 3.1.1 in AM335x Silicon Errata: http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sp...
Best regards, Jyri
On 09/19/2016 02:55 AM, Jyri Sarha wrote: [...]
The functional patches, with the binding document can be found here: http://www.spinics.net/lists/devicetree/msg141246.html
[1] For more details see section 3.1.1 in AM335x Silicon Errata: http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sp...
Thanks for the detailed explanation. http://www.spinics.net/lists/devicetree/msg141248.html helped explain the same.
Whitespace cleanup of lcdc related nodes. Do all indentation and alignment with tabs instead of spaces.
Signed-off-by: Jyri Sarha jsarha@ti.com Reviewed-by: Tomi Valkeinen tomi.valkeinen@ti.com --- arch/arm/boot/dts/am335x-evmsk.dts | 40 +++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts index 09308d6..23b94e7 100644 --- a/arch/arm/boot/dts/am335x-evmsk.dts +++ b/arch/arm/boot/dts/am335x-evmsk.dts @@ -170,29 +170,29 @@ pinctrl-1 = <&lcd_pins_sleep>; status = "okay"; panel-info { - ac-bias = <255>; - ac-bias-intrpt = <0>; - dma-burst-sz = <16>; - bpp = <32>; - fdd = <0x80>; - sync-edge = <0>; - sync-ctrl = <1>; - raster-order = <0>; - fifo-th = <0>; + ac-bias = <255>; + ac-bias-intrpt = <0>; + dma-burst-sz = <16>; + bpp = <32>; + fdd = <0x80>; + sync-edge = <0>; + sync-ctrl = <1>; + raster-order = <0>; + fifo-th = <0>; }; display-timings { 480x272 { - hactive = <480>; - vactive = <272>; - hback-porch = <43>; - hfront-porch = <8>; - hsync-len = <4>; - vback-porch = <12>; - vfront-porch = <4>; - vsync-len = <10>; + hactive = <480>; + vactive = <272>; + hback-porch = <43>; + hfront-porch = <8>; + hsync-len = <4>; + vback-porch = <12>; + vfront-porch = <4>; + vsync-len = <10>; clock-frequency = <9000000>; - hsync-active = <0>; - vsync-active = <0>; + hsync-active = <0>; + vsync-active = <0>; }; }; }; @@ -711,5 +711,5 @@ };
&lcdc { - status = "okay"; + status = "okay"; };
Add blue-and-red-wiring -property to lcdc node. The am335x-evmsk has blue and red wires crossed to get 24-bit RGB (and 16-bit BGR) support. After this patch am335x-evmsk supports BGR565, RGB888, and XRGB8888 color formats. See details in Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.
Signed-off-by: Jyri Sarha jsarha@ti.com Reviewed-by: Tomi Valkeinen tomi.valkeinen@ti.com --- arch/arm/boot/dts/am335x-evmsk.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts index 23b94e7..034e117 100644 --- a/arch/arm/boot/dts/am335x-evmsk.dts +++ b/arch/arm/boot/dts/am335x-evmsk.dts @@ -712,4 +712,6 @@
&lcdc { status = "okay"; + + blue-and-red-wiring = "crossed"; };
* Jyri Sarha jsarha@ti.com [160916 04:50]:
These patches complete the am335x LCDC color errata fix[1]. The functional patches are now queued for v4.9.
The patch for am335x-boneblack.dts is delayed until v4.10 or v4.9-rc phase to avoid conflickt with BBB HDMI audio DTS patch that slipped into tda998x pull request.
OK. Are these safe to merge even if the dts changes get merged before the driver changes? Or does it break something if merged out of order?
Regards,
Tony
Jyri Sarha (3): ARM: dts: am335x-evm: Add blue-and-red-wiring -property to lcdc node ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes ARM: dts: am335x-evmsk: Add blue-and-red-wiring -property to lcdc node
arch/arm/boot/dts/am335x-evm.dts | 2 ++ arch/arm/boot/dts/am335x-evmsk.dts | 42 ++++++++++++++++++++------------------ 2 files changed, 24 insertions(+), 20 deletions(-)
-- 1.9.1
On 09/16/16 18:02, Tony Lindgren wrote:
- Jyri Sarha jsarha@ti.com [160916 04:50]:
These patches complete the am335x LCDC color errata fix[1]. The functional patches are now queued for v4.9.
The patch for am335x-boneblack.dts is delayed until v4.10 or v4.9-rc phase to avoid conflickt with BBB HDMI audio DTS patch that slipped into tda998x pull request.
OK. Are these safe to merge even if the dts changes get merged before the driver changes? Or does it break something if merged out of order?
Yes, they are safe. The new property just simply is not interpreted and everything works as before.
BR, Jyri
* Jyri Sarha jsarha@ti.com [160919 00:31]:
On 09/16/16 18:02, Tony Lindgren wrote:
- Jyri Sarha jsarha@ti.com [160916 04:50]:
These patches complete the am335x LCDC color errata fix[1]. The functional patches are now queued for v4.9.
The patch for am335x-boneblack.dts is delayed until v4.10 or v4.9-rc phase to avoid conflickt with BBB HDMI audio DTS patch that slipped into tda998x pull request.
OK. Are these safe to merge even if the dts changes get merged before the driver changes? Or does it break something if merged out of order?
Yes, they are safe. The new property just simply is not interpreted and everything works as before.
OK applying into omap-for-v4.9/dt-v2 thanks.
Tony
dri-devel@lists.freedesktop.org
-
Jyri Sarha -
Nishanth Menon -
Tony Lindgren