[PATCH 6/6] drm/msm/dsi: Parse DSI lanes via DT

[Tomi Valkeinen]

On 23/02/16 12:43, Archit Taneja wrote:
> 
> 
> On 02/23/2016 02:48 PM, Tomi Valkeinen wrote:
>>
>> On 22/02/16 22:10, Rob Herring wrote:
>>
>>>> If we want all DSI host controllers to use a common binding to describe
>>>> lanes, we'd need to go with the most flexible one, and the driver
>>>> restricts it to the subsets that we support.
>>
>> True, but I wonder if that's necessary. The lane property for the SoC
>> should be read by the SoC specific driver, right? So the DT property can
>> be anything. I'm not sure if there's ever a reason for a generic code to
>> observe the DSI lane setup.
> 
> Yeah, it is very SoC specific.
> 
> The only place where it might matter is if a panel/bridge ever needs to
> know what pins implement what lanes on the platform. A common binding
> there might help us keep the panel driver generic. Although, this need
> itself is a bit hypothetical.

My opinion here is that if the panel/bridge needs to know something
about the DSI lanes/pins, we should have that data in the
panel's/bridge's endpoint data.

So if both SoC and the DSI peripheral need complex DSI pin/lane setup,
you might have very similar data on both sides. There's possibly some
duplication there, but I think it keeps things much simpler.

For example, if the SoC needs OMAP style DSI pin data, and the DSI
peripheral needs to know the amount of DSI lanes used (but nothing
else), you might think it's nice if the DSI peripheral would peek at the
SoC side data, finding out about the DSI lanes.

But I think in that case you should just add a "num-lanes" property to
the DSI peripheral. The DT data for a device should be private to the
driver handling the device, except for some special cases like following
the graph.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160223/e34fcbd9/attachment.sig>