Hi,
On Thu, Feb 4, 2021 at 10:09 AM Marek Vasut <marex@xxxxxxx> wrote:
>
> On 2/4/21 6:15 PM, Doug Anderson wrote:
>
> Hi,
>
> [...]
>
> >> +properties:
> >> + compatible:
> >> + const: ti,sn65dsi83
> >> +
> >> + reg:
> >> + const: 0x2d
> >> +
> >> + enable-gpios:
> >> + maxItems: 1
> >> + description: GPIO specifier for bridge_en pin (active high).
> >
> > I see two regulators: vcc and vcore. Shouldn't those be listed?
>
> Those are not implemented and not tested, so if someone needs them later
> on, they can be added then.
Sure. I guess it can go either way. For the regulator it'd the kind
of thing that's super easy to add support for and hard to mess up.
> >> + endpoint:
> >> + type: object
> >> + additionalProperties: false
> >> + properties:
> >> + remote-endpoint: true
> >> + data-lanes:
> >> + description: array of physical DSI data lane indexes.
> >
> > The chip doesn't allow for arbitrary remapping here, right? So you're
> > just using this as the official way to specify the number of lanes? I
> > guess the only valid values are:
> >
> > <0>
> > <0 1>
> > <0 1 2>
> > <0 1 2 3>
>
> Shouldn't that be <1 2 3 4> ?
The data manual refers to the channels starting at 0, so if it's
arbitrary that seems a better way to go?
> > In sn65dsi86 we attempted to enforce that a valid option was selected
> > for the output lanes. Could you do something similar? If nothing
> > else adding a description of the valid options would be good.
>
> I saw the binding, but I was under the impressions the DSI86 can do lane
> reordering, isn't that the case ? Maybe I misunderstood it.
DSI86 can reorder the output lanes quite flexibly. It can't reorder
the input lanes, though.
> But yes, if you have a suggestion how to make a non-cryptic list of
> those four lane mapping options, please do share this info.
I doubt I can write this correctly without a whole lot of futzing /
messing, but maybe something like:
data-lanes:
oneOf:
- items:
- 0
- items:
- 0
- 1
- items:
- 0
- 1
- 2
- items:
- 0
- 1
- 2
- 3
