linux-kernel - Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1439995944.31432.34.camel@pengutronix.de>
Date:	Wed, 19 Aug 2015 16:52:24 +0200
From:	Lucas Stach <l.stach@...gutronix.de>
To:	Thierry Reding <treding@...dia.com>
Cc:	Archit Taneja <architt@...eaurora.org>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, a.hajda@...sung.com
Subject: Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/