Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information

On 2013-12-13 05:24, Laurent Pinchart wrote:

quoted

Then DPI, which I think is mostly just level shifters. It's really just
a port, as you say.

SDI is a bit unclear to me. The registers for it are in the dss_core.
There's only a few registers, but it does have a PHY and a PLL. But I
guess it's also more of a port than a separate module.

After a quick look at the documentation I would say so. I would be tempted to 
consider RFBI as part of the DSS core, but that's less clear.

I had a look at this, mainly the DPI side so far. There's one extra
complication, which actually affects all other outputs also (and CDF):
pinctrl.

In the current series, I just have pinctrl for each device, with
"default" name, which ends up being used by default without any code on
my part.

However, if DPI is no longer a device, it can't have pinctrl entry. But
this is a wider issue, as the pinctrl should really be per endpoint, not
per device. When an endpoint is selected to be used, a particular
pinmuxing should be taken into use.

I'm not sure what would be the cleanest solution to this. I currently
have this working:

&dss {
	pinctrl-names = "default-0-0";
	pinctrl-0 = <&dss_dpi_pins>;

	port@0 {
		dpi_out: endpoint {
			remote-endpoint = <&tfp410_in>;
			data-lines = <24>;
		};
	};
};

So here I have 'port@0' for DSS, which is the DPI output, and it has a
single endpoint. For DSS device, I have pinctrl data.

When the DPI endpoint is initialized, the code looks for pinctrl with
name "default-<portnum>-<endpointnum>". As the DPI is port 0, and just
one endpoint, the code looks for "default-0-0".

For omap3 board with both DPI and SDI as options (they can't be used at
the same time, though), I imagine it'd be like:

&dss {
	vdds_dsi-supply = <&vpll2>;
	vdds_sdi-supply = <&vpll2>;

	pinctrl-names = "default-0-0", "default-1-0";
	pinctrl-0 = <&dss_dpi_pins>;
	pinctrl-1 = <&dss_sdi_pins>;

	ports {
		#address-cells = <1>;
		#size-cells = <0>;

		port@0 {
			reg = <0>;
			dpi_out: endpoint {
			};
		};

		port@1 {
			reg = <1>;
			sdi_out: endpoint {
			};
		};
	};
};

Any thoughts?

Every time I work with ports/endpoints, I feel that this is needlessly
complex. But I have never come up with any cleaner or simpler way to
handle this.

I also think this multiple-peripherals-per-single-port is not really
display related, although, for some reason, it seems like display is the
most abused hardware. Maybe ports/endpoints or similar should be in the
common driver framework?

 Tomi