From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752633AbbHSNOS (ORCPT ); Wed, 19 Aug 2015 09:14:18 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:5700 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750958AbbHSNOQ (ORCPT ); Wed, 19 Aug 2015 09:14:16 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Wed, 19 Aug 2015 06:14:16 -0700 Date: Wed, 19 Aug 2015 15:13:02 +0200 From: Thierry Reding To: Archit Taneja CC: , , , , , , , Subject: Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus Message-ID: <20150819131300.GC15607@ulmo.nvidia.com> References: <1435641851-27295-1-git-send-email-architt@codeaurora.org> <55D40F2A.6000208@codeaurora.org> MIME-Version: 1.0 In-Reply-To: <55D40F2A.6000208@codeaurora.org> X-NVConfidentiality: public User-Agent: Mutt/1.5.23+89 (0255b37be491) (2014-03-12) X-Originating-IP: [10.2.69.210] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 19, 2015 at 10:37:54AM +0530, Archit Taneja wrote: > Hi, >=20 > 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! >=20 > 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 =3D <&dsi>; ... }; ... }; dsi@... { ... }; Inversing the relationship would become something like this: i2c@... { ... }; dsi@... { ... peripheral@... { ... i2c-bus =3D <&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 =3D <&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. Thierry --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV1IDaAAoJEN0jrNd/PrOhKyQP/iZtUpbL9anfU9eJg1/qmGD8 c7MaB+jRbOfT/yTJ/hWnrNxAaQaaeHlk+ipIpFGHgwiQIAXZ/pF8NwFoLtEjT6AZ zNQM+7lQ176pjLQHC0gx15hjayZ9s/qDnbYeinrgNYmLcLzqlx6aZAT2aujK0cm2 yVpB5/wjV0vEUDhtfMeUm1+pfJPD6eI4mwm+EuJ6LQ3azMxy8WN1SMPLdVuJWVMl p4vXA99wIZGnbI+5IBQZ62aTI65C682BfGwqhiNTBP2OGvop6KwiBFAUYGWX52vj 9a9FVThTCIjIFmdSl1U170uzZdFGFc+O/iagoZ67jBxs/iAxBWfgq+cpbbJ3swBM Ow8ebYgeFg36/pWVETs1opBr2VcMuDQsgn/6Sp8MA8uBolauofj8yJ4P6KFivkEI xU4+7ajZkMl7Fwg4oSQ45I23DP9Lum9WtKWlie7psVIj4qmLuUXNxq7q2SM6c2qL tkCocs0TpUFwDXVLyi/JlGi9prDzX/aGdDv6uYGfuwh9Jb2qrEfjKndWS2Wh8gCQ V3e0ZS0DARhQotIIHlL7FqOpkTWUr0Ec7wgnb/0u2Lh81b47Gn3/Fxb3Ud34lKkX O5cNdiMmzFmGZRo/zSYerlAL9pG/Q0DKeLgzKYg0WX6LjrxzfQkMaeB8iQrQgFt4 RAIk5/kFntifv1sDUZHh =t3R1 -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6--