Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932259AbbHSPD2 (ORCPT ); Wed, 19 Aug 2015 11:03:28 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:10737 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932137AbbHSPDY (ORCPT ); Wed, 19 Aug 2015 11:03:24 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Wed, 19 Aug 2015 08:00:06 -0700 Date: Wed, 19 Aug 2015 17:02:09 +0200 From: Thierry Reding To: Lucas Stach CC: Archit Taneja , , , , Subject: Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus Message-ID: <20150819150207.GJ15607@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> <1439995944.31432.34.camel@pengutronix.de> MIME-Version: 1.0 In-Reply-To: <1439995944.31432.34.camel@pengutronix.de> X-NVConfidentiality: public User-Agent: Mutt/1.5.23+89 (0255b37be491) (2014-03-12) X-Originating-IP: [10.2.69.210] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VMt1DrMGOVs3KQwf" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6042 Lines: 171 --VMt1DrMGOVs3KQwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, > > >=20 > [...] > > > > Perhaps a better way would be to invert this relationship. Accordin= g to > > > > your proposal we'd have to have DT like this: > > > >=20 > > > > i2c@... { > > > > ... > > > >=20 > > > > dsi-device@... { > > > > ... > > > > dsi-bus =3D <&dsi>; > > > > ... > > > > }; > > > >=20 > > > > ... > > > > }; > > > >=20 > > > > dsi@... { > > > > ... > > > > }; > > > >=20 > > > > Inversing the relationship would become something like this: > > > >=20 > > > > i2c@... { > > > > ... > > > > }; > > > >=20 > > > > dsi@... { > > > > ... > > > >=20 > > > > peripheral@... { > > > > ... > > > > i2c-bus =3D <&i2c>; > > > > ... > > > > }; > > > >=20 > > > > ... > > > > }; > > > >=20 > > > > 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). > > > >=20 > > > > So how about we create two devices in the device tree and fuse them= at > > > > the driver level: > > > >=20 > > > > i2c@... { > > > > ... > > > >=20 > > > > i2cdsi: dsi-device@... { > > > > ... > > > > }; > > > >=20 > > > > ... > > > > }; > > > >=20 > > > > dsi@... { > > > > ... > > > >=20 > > > > peripheral@... { > > > > ... > > > > control =3D <&i2cdsi>; > > > > ... > > > > }; > > > >=20 > > > > ... > > > > }; > > > >=20 > > > > 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. > > > >=20 > > > I don't really like to see that you are inventing yet-another-way to > > > handle devices connected to multiple buses. > > >=20 > > > 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 clear= ly > > > a child of the i2c master controller and only of that one. > >=20 > > 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. > >=20 > 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? 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. > > > If you need to model connections between devices that are not reflect= ed > > > through the control bus hierarchy you should really consider using the > > > standardized of-graph bindings. > > > (Documentation/devicetree/bindings/graph.txt) > >=20 > > 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. > >=20 > 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. >=20 > 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. Thierry --VMt1DrMGOVs3KQwf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV1JptAAoJEN0jrNd/PrOhj8AQAIVDP0sstOelRIWrOQOim0Ap 3WKkcjhFp2GY6gF0yDaV3Zr7CVN0ZTUhELBUeBBY8PJmEmCHfhOnMQFDWKHxfLzI /8vX0yqouuy9Grdl6vUwzTIWpFHpivUkFFUwA1jxP/6vcPiirW/BSf061l5agc23 aR8W1AG8fOIhkvvkfHFelktGKXFS3jyZj10qu3g59GDTgbid4DNK2+jP5c1wWiai +sx1MYVsmZSsbLEUEkfRLm2nK6moiBnNZCc8XPV361EikuwuT0qHrYnT3+9d9+NA coOrHuVoDxEGuWU+z6H8xNbE2pMJNrXB2NdVmoRPutqyDPk+hMogbS9Gu1JfS0V1 J+MLZQts7cX++c8hJ1Zviwk7tZtkWy01vIEebt/92Qhqud+ntA6zn5IyHdvj93s4 vNZuiBB1j/LV7qsk4jJP1hK0wFnjrYIxgPv1i2G3Tt2YSxpiEmTPO3Ga9bQIcLAN dVRRcXwW7x/Di7Rc3r2BArgEUQJNHTi3ZJOR6DG+HyXdH8f5VN8+5mR8YSavwWKh uE6Eh0Z9nCcgtmGGzGUPSwTD3Q9KWBt7KKt3HJ6ClEwpG6GWkgXXXnGD4fO9GfiC cEEAz9KkEGKbCN+OjTNDtjrw+ovazO3/WxzVyOmQ2sAij/zITgMa1Vo0by4QJFdz VWP3xnzwKYbcSjbylefd =n08G -----END PGP SIGNATURE----- --VMt1DrMGOVs3KQwf-- -- 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/