On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
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,
Does it really have 2 control interfaces that are used at the same time?Perhaps a better way would be to invert this relationship. According toI don't really like to see that you are inventing yet-another-way 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.
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.
Or is the DSI connection a passive data bus if the register control
happens through i2c?
The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.
I see that the having dummy device is the least desirable solution. ButIf 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.
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.
But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
add some sort of quirk to the DSI controller binding to allow it to
hook up with a control endpoint. And then you'll need more quirks
to describe what kind of DSI device this is.
On the other hand if you properly instantiate the DSI device you can
easily write a driver for it, and the driver will set up the correct
properties as implied by the compatible string. Once you have that you
can easily hook it up to the I2C control interface in whatever way you
like, be that an OF graph or just a simple unidirectional link by
phandle.