On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
> Hi Thierry, Archit,
>
> Am Mittwoch, den 19.08.2015, 15:13 +0200 schrieb Thierry Reding:
> > On Wed, Aug 19, 2015 at 10:37:54AM +0530, Archit Taneja wrote:
> > > Hi,
> > >
> > > On 06/30/2015 10:54 AM, Archit Taneja wrote:
> > > >We are currently restricted when it comes to supporting DSI on devices
> > > >that have a non-DSI control bus. For example, DSI encoder chips are
> > > >available in the market that are configured via i2c. Configuring their
> > > >registers via DSI bus is either optional or not available at all.
> > > >
> > > >These devices still need to pass DSI parameters (data lanes, mode flags
> > > >etc) to the DSI host they are connected to. We don't have a way to do
> > > >that at the moment.
> > > >
> > > >The method presented in these patches is to provide an API to create a
> > > >'dummy' mipi_dsi_device. This device is populated with the desired DSI
> > > >params, which are passed on to the host via mipi_dsi_attach().
> > > >
> > > >This method will require the device driver to get a phandle to the DSI
> > > >host since there is no parent-child relation between the two.
> > > >
> > > >Is there a better way to do this? Please let me know!
> > >
> > > Any comments on this?
> >
> > 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.
> 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.
> 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.
Thierry
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
