Message-ID: <1439995944.31432.34.camel@pengutronix.de>
Subject: Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus
From: Lucas Stach <l.stach@pengutronix.de>
To: Thierry Reding <treding@nvidia.com>
Cc: Archit Taneja <architt@codeaurora.org>, linux-arm-msm@vger.kernel.org,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        a.hajda@samsung.com
Date: Wed, 19 Aug 2015 16:52:24 +0200
In-Reply-To: <20150819143452.GH15607@ulmo.nvidia.com>
References: <1435641851-27295-1-git-send-email-architt@codeaurora.org>
	 <55D40F2A.6000208@codeaurora.org> <20150819131300.GC15607@ulmo.nvidia.com>
	 <1439993828.31432.28.camel@pengutronix.de>
	 <20150819143452.GH15607@ulmo.nvidia.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4503
Lines: 136

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
> On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
> > Hi Thierry, Archit,
> > 
[...]
> > > Perhaps a better way would be to invert this relationship. According to
> > > your proposal we'd have to have DT like this:
> > > 
> > > 	i2c@... {
> > > 		...
> > > 
> > > 		dsi-device@... {
> > > 			...
> > > 			dsi-bus = <&dsi>;
> > > 			...
> > > 		};
> > > 
> > > 		...
> > > 	};
> > > 
> > > 	dsi@... {
> > > 		...
> > > 	};
> > > 
> > > Inversing the relationship would become something like this:
> > > 
> > > 	i2c@... {
> > > 		...
> > > 	};
> > > 
> > > 	dsi@... {
> > > 		...
> > > 
> > > 		peripheral@... {
> > > 			...
> > > 			i2c-bus = <&i2c>;
> > > 			...
> > > 		};
> > > 
> > > 		...
> > > 	};
> > > 
> > > Both of those aren't fundamentally different, and they both have the
> > > disavantage of lacking ways to transport configuration data that the
> > > other bus needs to instantiate the dummy device (such as the reg
> > > property for example, denoting the I2C slave address or the DSI VC).
> > > 
> > > So how about we create two devices in the device tree and fuse them at
> > > the driver level:
> > > 
> > > 	i2c@... {
> > > 		...
> > > 
> > > 		i2cdsi: dsi-device@... {
> > > 			...
> > > 		};
> > > 
> > > 		...
> > > 	};
> > > 
> > > 	dsi@... {
> > > 		...
> > > 
> > > 		peripheral@... {
> > > 			...
> > > 			control = <&i2cdsi>;
> > > 			...
> > > 		};
> > > 
> > > 		...
> > > 	};
> > > 
> > > This way we'll get both an I2C device and a DSI device that we can fully
> > > describe using the standard device tree bindings. At driver time we can
> > > get the I2C device from the phandle in the control property of the DSI
> > > device and use it to execute I2C transactions.
> > > 
> > I don't really like to see that you are inventing yet-another-way to
> > handle devices connected to multiple buses.
> > 
> > Devicetree is structured along the control buses, even if the devices
> > are connected to multiple buses, in the DT they are always children of
> > the bus that is used to control their registers from the CPUs
> > perspective. So a DSI encoder that is controlled through i2c is clearly
> > a child of the i2c master controller and only of that one.
> 
> I think that's a flawed interpretation of what's going on here. The
> device in fact has two interfaces: one is I2C, the other is DSI. In my
> opinion that's reason enough to represent it as two logical devices.
> 
Does it really have 2 control interfaces that are used at the same time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?

> > If you need to model connections between devices that are not reflected
> > through the control bus hierarchy you should really consider using the
> > standardized of-graph bindings.
> > (Documentation/devicetree/bindings/graph.txt)
> 
> The problem is that the original proposal would instantiate a dummy
> device, so it wouldn't be represented in DT at all. So unless you do add
> two logical devices to DT (one for each bus interface), you don't have
> anything to glue together with an OF graph.
> 
I see that the having dummy device is the least desirable solution. But
if there is only one control bus to the device I think it should be one
device sitting beneath the control bus.

You can then use of-graph to model the data path between the DSI encoder
and device.

> > Multiple device drivers in both the media and DRM universe have shown
> > that they are a working way to represent those data bus connections
> > between devices.
> > I know this might make things a bit more complicated for Tegra DRM,
> > where you have a nice parent<->child relationship between the components
> > even on the control path so far, but we should really move into the
> > direction of more drivers using the standardized bindings for this
> > stuff, instead of doing another round of NIH.
> 
> Why are you bringing up Tegra DRM? I don't see how it's relevant in any
> way to this discussion.
> 
Just disregard this comment then. Lets concentrate on the points above.

Regards,
Lucas 
-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/