Hi Tomi,
On Wednesday 19 September 2012 14:45:29 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > While working on DT bindings for the Renesas Mobile SoC display controller
> > (a.k.a. LCDC) I quickly realized that display panel implementation based
> > on board code callbacks would need to be replaced by a driver-based panel
> > framework.
>
> I thought I'd try to approach the common panel framework by creating
> device tree examples that OMAP would need. I only thought about the
> connections and organization, not individual properties, so I have not
> filled any "compatible" or such properties.
>
> What I have below is first DT data for OMAP SoC (more or less what omap4
> has), then display examples of different board setups. The hardware
> examples I have here are all real, so no imaginary use cases =).
>
> We don't need to implement support for all these at once, but I think
> the DT data structure should be right from the start, so I'm posting
> this to get discussion about the format.
Thank you for working on this proposal.
> OMAP SoC
> ========
>
> So here's first the SoC specific display nodes. OMAP has a DSS (display
> subsystem) block, which contains the following elements:
>
> - DISPC (display controller) reads the pixels from memory and outputs
> them using specified video timings. DISPC has three outputs, LCD0, LCD1
> and TV. These are SoC internal outputs, they do not go outside the SoC.
>
> - DPI gets its data from DISPC's LCD0, and outputs MIPI DPI (parallel
> RBG)
>
> - Two independent DSI modules, which get their data from LCD0 or LCD1,
> and output MIPI DSI (a serial two-way video bus)
>
> - HDMI, gets data from DISPC's TV output and outputs HDMI
>
> / {
> ocp {
> dss {
> dispc {
> dss-lcd0: output@0 {
> };
>
> dss-lcd1: output@1 {
> };
>
> dss-tv: output@2 {
> };
> };
>
> dpi: dpi {
> video-source = <&dss-lcd0>;
> };
>
> dsi0: dsi@0 {
> video-source = <&dss-lcd0>;
> };
>
> dsi1: dsi@1 {
> video-source = <&dss-lcd1>;
> };
>
> hdmi: hdmi {
> video-source = <&dss-tv>;
> };
> };
> };
> };
>
> I have defined all the relevant nodes, and video-source property is used
> to point to the source for video data. I also define aliases for the SoC
> outputs so that panels can use them.
>
> One thing to note is that the video sources for some of the blocks, like
> DSI, are not hardcoded in the HW, so dsi0 could get its data from LCD0
> or LCD1.
What about the source that are hardwired in hardware ? Shouldn't those be
hardcoded in the driver instead ?
> However, I don't think they are usually changed during runtime, and the dss
> driver cannot change them independently for sure (meaning that some upper
> layer should tell it how to change the config). Thus I specify sane defaults
> here, but the board dts files can of course override the video sources.
I'm not sure whether default settings like those really belong to the DT. I'm
no expert on that topic though.
> Another thing to note is that we have more outputs from OMAP than we have
> outputs from DISPC. This means that the same video source is used by
> multiple sinks (LCD0 used by DPI and DSI0). DPI and DSI0 cannot be used at
> the same time, obviously.
It might not be really obvious, as I don't see what prevents DPI and DSI0 to
be used at the same time :-) Do they share physical pins ?
> And third thing to note, DISPC node defines outputs explicitly, as it has
> multiple outputs, whereas the external outputs do not as they have only one
> output. Thus the node's output is implicitly the node itself. So, instead of
> having:
>
> ds0: dsi@0 {
> video-source = <&dss-lcd0>;
> dsi0-out0: output@0 {
> };
> };
>
> I have:
>
> dsi0: dsi@0 {
> video-source = <&dss-lcd0>;
> };
What about defining the data sinks instead of the data sources ? I find it
more logical for the DSS to get the panel it's connected to than the other way
around.
> Of this I'm a bit unsure. I believe in most cases there's only one output,
> so it'd be nice to have a shorter representation, but I'm not sure if it's
> good to handle the cases for single and multiple outputs differently. Or if
> it's good to mix control and data busses, as, for example, dsi0 can be used
> as both control and data bus. Having the output defined explicitly would
> separate the control and data bus nodes.
>
>
> Simple DPI panel
> ================
>
> Here a board has a DPI panel, which is controlled via i2c. Panel nodes
> are children of the control bus, so in this case we define the panel
> under i2c2.
>
> &i2c2 {
> dpi-lcd-panel {
> video-source = <&dpi>;
>
> };
> };
>
>
> HDMI
> ====
>
> OMAP has a HDMI output, but it cannot be connected directly to an HDMI
> cable. TI uses tpd12s015 chip in its board, which provides ESD,
> level-shifting and whatnot (I'm an SW guy, google for the chip to read
> the details =). tpd12s015 has a few GPIOs and powers that need to be
> controlled, so we need a driver for it.
>
> There's no control bus for the tpd12s015, so it's platform device. Then
> there's the device for the HDMI monitor, and the DDC lines are connected
> to OMAP's i2c4, thus the hdmi monitor device is a child of i2c.
>
> / {
> hdmi-connector: tpd12s015 {
> video-source = <&hdmi>;
> };
> };
>
> &i2c4 {
> hdmi-monitor {
> video-source = <&hdmi-connector>;
> };
> };
So this implied we would have the following chain ?
DISPC (on SoC) -> HDMI (on SoC) -> TPD12S015 (on board) -> HDMI monitor (off
board)
Should we then have a driver for the HDMI monitor ?
> DSI bridge chip
> ===============
>
> In this board we have a DSI bridge chip that is controlled via DSI, and
> gets the pixel data via DSI video mode stream. The chip converts this to
> LVDS. We then have an LVDS panel connected to this bridge chip, which is
> controlled via SPI.
>
> &dsi0 {
> dsi2lvds: dsi2lvds {
> video-source = <&dsi0>;
>
> };
> };
>
> &spi2 {
> lvds-lcd-panel {
> video-source = <&dsi2lvds>;
> };
> };
>
>
> High res dual-DSI panel
> =======================
>
> Here we have a DSI video mode panel that gets its data from two DSI
> buses. This allows it to get the combined bandwidth of the DSI buses,
> achieving higher resolution than with single DSI bus. The panel is
> controlled via the first DSI bus.
>
> &dsi0 {
> dual-dsi-panel {
> video-source-1 = <&dsi0>;
> video-source-2 = <&dsi1>;
>
> };
> };
>
>
> DSI buffer chip with two outputs
> ================================
>
> This board has a DSI command mode buffer chip, that contains its own
> framebuffer. The buffer chip has two DPI outputs, which get the pixels
> from the framebuffer. Similar to OMAP's DISPC this chip has multiple
> outputs so they need to be defined explicitly. And we also have two
> dummy DPI panels connected to this buffer chip.
>
> &dsi0 {
> dsibuf {
> video-source = <&dsi0>;
>
> dsibuf-dpi0: output@0 {
> };
>
> dsibuf-dpi1: output@1 {
> };
> };
> };
>
> / {
> dpi-lcd-panel@0 {
> video-source = <&dsibuf-dpi0>;
>
> };
>
> dpi-lcd-panel@1 {
> video-source = <&dsibuf-dpi1>;
>
> };
> };
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
