On 2013-12-13 05:24, Laurent Pinchart wrote:
>> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
