From: moinejf@free.fr (Jean-Francois Moine)
To: linux-arm-kernel@lists.infradead.org
Subject: DT binding review for Armada display subsystem
Date: Fri, 12 Jul 2013 20:39:52 +0200 [thread overview]
Message-ID: <20130712203952.6b7aa927@armhf> (raw)
In-Reply-To: <20130712164428.AC3D2FAAE9@dev.laptop.org>
On Fri, 12 Jul 2013 12:44:28 -0400 (EDT)
Daniel Drake <dsd@laptop.org> wrote:
> Hi,
>
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as something for the driver to bind
> to, needed because there is no clear one device that controls all the
> others, and also to distinguish between the Armada 510 possible use cases
> of having one video card with two outputs, or two independent video cards.
> It uses node-to-node linking beyond that point, V4L2 style.
>
> I have some questions still:
>
> 1. What names does the Armada 510 datasheet give to the components? Below
> I renamed the "LCD controllers" (which don't control LCDs on any of the
> current target hardware) to "display controllers". For what we were
> previously referring to as DCON, I renamed to "output selector". I would
> like to match the docs.
>
> Actually the output selector is not mentioned as per Sebastian's
> suggestion, but I believe it would fit in the below design once the first
> user comes along (e.g. it would slot in the graph between dcon0 and tda99x).
>
> 2. On that topic, what names does the Armada 510 datasheet give to the
> available clocks? Lets make them match the docs.
>
> 3. What is the "remote" property in the video interfaces binding? Doesn't
> seem to be documented. But I think I copied its usage style below.
Hi Daniel,
The Armada 510 spec is:
http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
> Marvell Armada Display Subsystem
>
> Design considerations
> ---------------------
>
> The display device that emerges from this subsystem is quite heavily
> componentized and the formation of the composite device will vary by SoC and
> by board. The DT binding is designed with this flexibility in mind.
>
> For example, there are 2 display controllers on the Armada 510.
> They could legitametely be used to form two independent video cards, or
> they could be combined into a single video card with two outputs, depending
> on board wiring and use case.
>
> As there is no clear component that controls the other components, especially
> when we wish to combine the two display controllers into one virtual device, we
> define a top-level "super node" that describes the basic composition of the
> overall display device. That node uses phandles to define the start of the
> graph of display components.
>
> In the bindings for the individual display components, phandle properties
> are used to represent direct, fixed links to other components. We use the
> port/endpoint abstraction from bindings/media/video-interfaces.txt to
> represent these links.
>
>
> display super node
> ------------------
>
> Required properties:
> - compatible: "marvell,armada-display"
> - marvell,video-devices : List of phandles to the display controllers that
> form this composite device.
>
> Optional properties;
> - reg: Memory address and size of a RAM allocation designated as graphics
> memory
> - linux,video-memory-size: If reg is not provided, this property defines
> how much memory to cut out of regular available RAM to be used as graphics
> memory.
>
>
> display-controller node
> -----------------------
>
> Required properties:
> - compatible: "marvell,armada-510-display", "marvell,mmp2-display" or
> "marvell,mmp3-display"
> - reg: Register space for this display controller
> - clocks: List of clocks available to this device. From common clock binding.
> - clock-names: Names of the given clocks (see below)
> - ports: From video interface binding
>
> Valid clock names for Armada 510: extclk0 extclk1 axi pll
>
> Valid clock names for MMP2: lcd1 lcd2 axi hdmi
>
> Valid clock names for MMP3: lcd1 lcd2 axi hdmi dsi lvds
>
>
> Example:
>
> display {
> ?? ?? compatible = "marvell,armada-display";
> ?? ?? ?? reg = <0 0x3f000000 0x1000000>; /* video-mem hole */
> ?? ?? ?? marvell,video-devices = <&dcon0>;
> ?? ?? };
>
> dcon0: display-controller at 20000 {
> compatible = "marvell,armada-510-display-controller";
> ?? ?? ?? reg = <0x20000 0x1000>;
> ?? ?? ?? interrupts = <47>;
> ?? ?? ?? clocks = <&ext_clk0>;
> ?? ?? ?? clock-names = "extclk0";
>
> port {
> dcon0_1: endpoint {
> remote = <&tda998x>;
> };
> };
> };
>
> &i2c0 {
> ?? ?? tda998x: hdmi-transmitter at 60 {
> ?? ?? ?? compatible = "nxp,tda19988";
> ?? ?? ?? ?? reg = <0x60>;
> port {
> tda998x_1: endpoint {
> remote-endpoint = <&dcon0_1>;
> };
> };
> ?? ?? ?? };
> };
Some remarks:
- I think it is better to keep the names 'lcd' for the memory to dumb panel
sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
named in the spec.
- the phandles to the clocks does not tell how the clock may be set by
the driver (it is an array index in the 510).
- I don't see the use of the phandles in the leaves (dcon and tda998x).
Well, here is how I feel the DTs:
- for the Cubox (one LCD, the DCON is not used, TDA998x for HDMI/DVI
output):
video {
compatible = "marvell,armada-video";
marvell,video-devices = <&lcd0> /* only one device */
};
/* the LCD reg and interrupts are described in dove.dtsi */
&lcd0 {
status = "okay";
clocks = <&core_clk 3>, <&lcdclk>, <&si5351 0>;
marvell,clock-type = <0>, <2>, <3>; /* how to set the clock */
marvell,connector-type = <11>; /* HDMIA */
marvell,external-encoder = <&tda998x>;
};
&i2c0 {
si5351: clock-generator {
...
};
tda998x: hdmi-encoder {
compatible = "nxp,tda998x";
reg = <0x70>;
interrupt-parent = <&gpio0>;
interrupts = <27 2>; /* falling edge */
};
};
- for some tablet based on the Armada 510 with a LCD and a VGA connector:
video {
compatible = "marvell,armada-video";
marvell,video-devices = <&lcd0>, <&lcd1>, <&dcon>
};
/* the LCDs reg and interrupts are described in dove.dtsi */
&lcd0 { /* LCD */
status = "okay";
clocks = <&lcdclk>; /* only the LCD clock */
marvell,clock-type = <2>;
marvell,connector-type = <7>; /* LVDS */
display-timings {
mode {
hactive = <1920>;
vactive = <1080>;
hfront-porch = <88>;
hsync-len = <44>;
hback-porch = <148>;
vfront-porch = <4>;
vsync-len = <5>;
vback-porch = <36>;
clock = <148500>;
};
};
};
&lcd1 { /* VGA */
status = "okay";
clocks = <&core_clk 3>, <&lcdclk>; /* only the AXI and LCD clocks */
marvell,clock-type = <0>, <2>; /* how to set the clock */
marvell,port-type = <1>; /* VGA */
/* there may be some external encoder to handle DAC */
};
/* the DCON reg and interrupts are described in dove.dtsi */
&dcon { status = "okay"; };
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Francois Moine <moinejf@free.fr>
To: Daniel Drake <dsd@laptop.org>
Cc: devicetree-discuss@lists.ozlabs.org,
dri-devel@lists.freedesktop.org, grant.likely@secretlab.ca,
rmk@arm.linux.org.uk, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org,
sebastian.hesselbarth@gmail.com
Subject: Re: DT binding review for Armada display subsystem
Date: Fri, 12 Jul 2013 20:39:52 +0200 [thread overview]
Message-ID: <20130712203952.6b7aa927@armhf> (raw)
In-Reply-To: <20130712164428.AC3D2FAAE9@dev.laptop.org>
On Fri, 12 Jul 2013 12:44:28 -0400 (EDT)
Daniel Drake <dsd@laptop.org> wrote:
> Hi,
>
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as something for the driver to bind
> to, needed because there is no clear one device that controls all the
> others, and also to distinguish between the Armada 510 possible use cases
> of having one video card with two outputs, or two independent video cards.
> It uses node-to-node linking beyond that point, V4L2 style.
>
> I have some questions still:
>
> 1. What names does the Armada 510 datasheet give to the components? Below
> I renamed the "LCD controllers" (which don't control LCDs on any of the
> current target hardware) to "display controllers". For what we were
> previously referring to as DCON, I renamed to "output selector". I would
> like to match the docs.
>
> Actually the output selector is not mentioned as per Sebastian's
> suggestion, but I believe it would fit in the below design once the first
> user comes along (e.g. it would slot in the graph between dcon0 and tda99x).
>
> 2. On that topic, what names does the Armada 510 datasheet give to the
> available clocks? Lets make them match the docs.
>
> 3. What is the "remote" property in the video interfaces binding? Doesn't
> seem to be documented. But I think I copied its usage style below.
Hi Daniel,
The Armada 510 spec is:
http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
> Marvell Armada Display Subsystem
>
> Design considerations
> ---------------------
>
> The display device that emerges from this subsystem is quite heavily
> componentized and the formation of the composite device will vary by SoC and
> by board. The DT binding is designed with this flexibility in mind.
>
> For example, there are 2 display controllers on the Armada 510.
> They could legitametely be used to form two independent video cards, or
> they could be combined into a single video card with two outputs, depending
> on board wiring and use case.
>
> As there is no clear component that controls the other components, especially
> when we wish to combine the two display controllers into one virtual device, we
> define a top-level "super node" that describes the basic composition of the
> overall display device. That node uses phandles to define the start of the
> graph of display components.
>
> In the bindings for the individual display components, phandle properties
> are used to represent direct, fixed links to other components. We use the
> port/endpoint abstraction from bindings/media/video-interfaces.txt to
> represent these links.
>
>
> display super node
> ------------------
>
> Required properties:
> - compatible: "marvell,armada-display"
> - marvell,video-devices : List of phandles to the display controllers that
> form this composite device.
>
> Optional properties;
> - reg: Memory address and size of a RAM allocation designated as graphics
> memory
> - linux,video-memory-size: If reg is not provided, this property defines
> how much memory to cut out of regular available RAM to be used as graphics
> memory.
>
>
> display-controller node
> -----------------------
>
> Required properties:
> - compatible: "marvell,armada-510-display", "marvell,mmp2-display" or
> "marvell,mmp3-display"
> - reg: Register space for this display controller
> - clocks: List of clocks available to this device. From common clock binding.
> - clock-names: Names of the given clocks (see below)
> - ports: From video interface binding
>
> Valid clock names for Armada 510: extclk0 extclk1 axi pll
>
> Valid clock names for MMP2: lcd1 lcd2 axi hdmi
>
> Valid clock names for MMP3: lcd1 lcd2 axi hdmi dsi lvds
>
>
> Example:
>
> display {
> Â Â compatible = "marvell,armada-display";
> Â Â Â reg = <0 0x3f000000 0x1000000>; /* video-mem hole */
> Â Â Â marvell,video-devices = <&dcon0>;
> Â Â };
>
> dcon0: display-controller@20000 {
> compatible = "marvell,armada-510-display-controller";
> Â Â Â reg = <0x20000 0x1000>;
> Â Â Â interrupts = <47>;
> Â Â Â clocks = <&ext_clk0>;
> Â Â Â clock-names = "extclk0";
>
> port {
> dcon0_1: endpoint {
> remote = <&tda998x>;
> };
> };
> };
>
> &i2c0 {
> Â Â tda998x: hdmi-transmitter@60 {
> Â Â Â compatible = "nxp,tda19988";
> Â Â Â Â reg = <0x60>;
> port {
> tda998x_1: endpoint {
> remote-endpoint = <&dcon0_1>;
> };
> };
> Â Â Â };
> };
Some remarks:
- I think it is better to keep the names 'lcd' for the memory to dumb panel
sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
named in the spec.
- the phandles to the clocks does not tell how the clock may be set by
the driver (it is an array index in the 510).
- I don't see the use of the phandles in the leaves (dcon and tda998x).
Well, here is how I feel the DTs:
- for the Cubox (one LCD, the DCON is not used, TDA998x for HDMI/DVI
output):
video {
compatible = "marvell,armada-video";
marvell,video-devices = <&lcd0> /* only one device */
};
/* the LCD reg and interrupts are described in dove.dtsi */
&lcd0 {
status = "okay";
clocks = <&core_clk 3>, <&lcdclk>, <&si5351 0>;
marvell,clock-type = <0>, <2>, <3>; /* how to set the clock */
marvell,connector-type = <11>; /* HDMIA */
marvell,external-encoder = <&tda998x>;
};
&i2c0 {
si5351: clock-generator {
...
};
tda998x: hdmi-encoder {
compatible = "nxp,tda998x";
reg = <0x70>;
interrupt-parent = <&gpio0>;
interrupts = <27 2>; /* falling edge */
};
};
- for some tablet based on the Armada 510 with a LCD and a VGA connector:
video {
compatible = "marvell,armada-video";
marvell,video-devices = <&lcd0>, <&lcd1>, <&dcon>
};
/* the LCDs reg and interrupts are described in dove.dtsi */
&lcd0 { /* LCD */
status = "okay";
clocks = <&lcdclk>; /* only the LCD clock */
marvell,clock-type = <2>;
marvell,connector-type = <7>; /* LVDS */
display-timings {
mode {
hactive = <1920>;
vactive = <1080>;
hfront-porch = <88>;
hsync-len = <44>;
hback-porch = <148>;
vfront-porch = <4>;
vsync-len = <5>;
vback-porch = <36>;
clock = <148500>;
};
};
};
&lcd1 { /* VGA */
status = "okay";
clocks = <&core_clk 3>, <&lcdclk>; /* only the AXI and LCD clocks */
marvell,clock-type = <0>, <2>; /* how to set the clock */
marvell,port-type = <1>; /* VGA */
/* there may be some external encoder to handle DAC */
};
/* the DCON reg and interrupts are described in dove.dtsi */
&dcon { status = "okay"; };
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2013-07-12 18:39 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 16:44 DT binding review for Armada display subsystem Daniel Drake
2013-07-12 16:44 ` Daniel Drake
2013-07-12 18:39 ` Jean-Francois Moine [this message]
2013-07-12 18:39 ` Jean-Francois Moine
2013-07-12 19:00 ` Daniel Drake
2013-07-12 19:00 ` Daniel Drake
2013-07-13 8:35 ` Jean-Francois Moine
2013-07-13 8:35 ` Jean-Francois Moine
2013-07-13 10:56 ` Sylwester Nawrocki
2013-07-13 10:56 ` Sylwester Nawrocki
2013-07-13 11:12 ` Russell King - ARM Linux
2013-07-13 11:12 ` Russell King - ARM Linux
2013-07-13 17:44 ` Sebastian Hesselbarth
2013-07-13 17:44 ` Sebastian Hesselbarth
2013-07-13 20:43 ` Sylwester Nawrocki
2013-07-13 20:43 ` Sylwester Nawrocki
2013-07-13 21:02 ` Russell King - ARM Linux
2013-07-13 21:02 ` Russell King - ARM Linux
2013-07-13 22:16 ` Sylwester Nawrocki
2013-07-13 22:16 ` Sylwester Nawrocki
2013-07-13 23:09 ` Russell King - ARM Linux
2013-07-13 23:09 ` Russell King - ARM Linux
2013-07-15 20:35 ` Tomasz Figa
2013-07-15 20:35 ` Tomasz Figa
2013-07-13 20:51 ` Russell King - ARM Linux
2013-07-13 20:51 ` Russell King - ARM Linux
2013-07-13 14:25 ` Daniel Drake
2013-07-13 14:25 ` Daniel Drake
2013-07-13 17:36 ` Sebastian Hesselbarth
2013-07-13 17:36 ` Sebastian Hesselbarth
2013-07-13 17:38 ` Russell King - ARM Linux
2013-07-13 17:38 ` Russell King - ARM Linux
2013-07-15 20:23 ` Daniel Drake
2013-07-15 20:23 ` Daniel Drake
2013-07-15 21:09 ` Sascha Hauer
2013-07-15 21:09 ` Sascha Hauer
2013-07-17 17:50 ` Daniel Drake
2013-07-17 17:50 ` Daniel Drake
2013-07-17 18:30 ` Jean-Francois Moine
2013-07-17 18:30 ` Jean-Francois Moine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130712203952.6b7aa927@armhf \
--to=moinejf@free.fr \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.