Hi Tomi,
On Monday 16 December 2013 12:49:03 Tomi Valkeinen wrote:
> 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?Would it be feasible to put the pinctrl properties in the port or endpoint nodes ? That could require changes to the pinctrl core, most probably just exporting a few internal functions (possibly requiring a bit of refactoring), but it might make the result simpler. > 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? Ports and endpoints is the way we have come up with to describe a graph in DT. I wouldn't call it needlessly complex, as I believe it's both generic and simple, but I agree it's a bit on the verbose side. Omitting the ports and port nodes as a shortcut might be a good way to reduce the verbosity. Regarding moving this to the device core, I'm not opposed to it, but I'd like to see interest from other users first. -- Regards, Laurent Pinchart
signature.asc
Description: This is a digitally signed message part.
