From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support Date: Fri, 6 Dec 2013 13:54:25 +0100 Message-ID: <20131206125424.GA30625@ulmo.nvidia.com> References: <1384791923-11424-1-git-send-email-a.hajda@samsung.com> <20131122174127.GA30591@ulmo.nvidia.com> <52936745.1070209@samsung.com> <20131127105401.GB9639@ulmo.nvidia.com> <52A08FB3.5040800@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0038128938==" Return-path: Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by gabe.freedesktop.org (Postfix) with ESMTP id 5A0DCFA50B for ; Fri, 6 Dec 2013 04:55:30 -0800 (PST) Received: by mail-bk0-f53.google.com with SMTP id na10so281796bkb.12 for ; Fri, 06 Dec 2013 04:55:28 -0800 (PST) In-Reply-To: <52A08FB3.5040800@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Tomi Valkeinen Cc: Andrzej Hajda , Kyungmin Park , Thierry Reding , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0038128938== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 05, 2013 at 04:37:39PM +0200, Tomi Valkeinen wrote: > On 2013-11-27 12:54, Thierry Reding wrote: >=20 > >> I am not sure about hardwiring devices to virtual channels. > >> There could be devices which uses more than one virtual channel, > >> in fact exynos-drm docs suggests that such hardware exists. > >=20 > > In that case, why not make them two logically separate devices within > > the kernel. We need the channel number so that the device can be > > addressed in the first place, so I don't see what's wrong with using > > that number in the device's name. > >=20 > > The whole point of this patch is to add MIPI DSI bus infrastructure, and > > the virtual channel is one of the fundamental aspects of that bus, so I > > think we need to make it an integral part of the implementation. >=20 > (I speak here more in the context of OMAP display subsystem and CDF, and > this might not be totally applicable to DRM). >=20 > In my opinion, DSI shouldn't be though of in the same way as other buses. >=20 > In most of the cases, there's just one DSI peripheral connected. This > peripheral may answer to multiple DSI VC IDs, though. I don't like the > idea of having to split one device driver into multiple drivers, just to > manage multiple DSI VC IDs. If they respond to multiple VCs, then I suppose they would be logically separate devices, even if only a single physical device. What would be the point of addressing them individually if they are just the same device? > In some rare cases (I've never seen one in production) there may be a > DSI hub, and one or two DSI peripherals behind it. But the hub is not > really a hub, but a router, and the router requires configuration. The > case here is not really one DSI bus with two or more peripherals, but > two or more independent 1-to-1 DSI buses. =46rom the CPUs perspective there's still only one bus. Or perhaps to put it another way, there is a single address space, because that's what's implied by how the virtual channel number is defined. So you would still represent the DSI hub as one device with a specific VC and the two peripherals behind it with different VC numbers. The VC number space simply doesn't allow much else to be done. > I have never seen a pure hub, i.e. something that would just > forward/broadcast the DSI packet to two or more DSI peripherals. >=20 > So I think we should consider DSI as a one-to-one link, and let the DSI > peripheral manage the VC IDs as it wants. But doing so would prevent us from supporting setups where we have two separate peripherals with different VC numbers. > I don't see any benefit in trying to create a similar linux bus for > DSI as we have for, say, i2c or spi. > > Without that fixed virtual channel number we can't use the device in the > > first place. How are you going to address the device if you don't know > > its virtual channel? >=20 > The DSI peripheral driver must know the VC IDs. Often they are hardcoded > values, and they can be defined in the driver code. When you say "often", can you make a guarantee that it will always be the case? I don't think so. I can easily imagine somebody making the VC configurable via straps, which would come in handy if you wanted to use the same IC multiple times within the same design. In that case you still need some way to specify the VC on a per-board basis, either in DT or "platform data". > I don't see why the DSI host driver would need to know the VC IDs, as > it can't really do anything independently with the peripheral anyway. > All the transactions should be started by the DSI peripheral driver. There are things that are standardized in DSI. The core could for instance try to probe peripherals by reading the DDB. But even that aside, we'll still need some way to store a device's VC number somewhere. Even if the DSI host doesn't have any explicit knowledge about it, you still need to pass it along when you want to send a message to a device. So when you start a transaction from within a device driver, you still need to get the VC number from somewhere. The proposal is to store that number in struct mipi_dsi_device. It's a logical choice because it is something that characterises a device. It is also a property of every device, so by storing it within a common structure gives drivers a standard way of accessing it instead of having each driver come up with it's own way to store it. Thierry --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSockAAAoJEN0jrNd/PrOh8NsQAIx/wMKYX9G1kPnOeCLlSxsZ xEHECxMLnPSFbLcZ6Il1bGSrpJyXn3xkALIDQuD/ybvpL0tGvBiWJR8Y0/RrzV1/ kSTzqANZhV/q5PGLmjCB9F/n2bBSvz3C2kSNNOofP5Ng5SuBMXLCuG7yV3nZDJms ILSAkDhoWM6Yr78mUe8fvKSU+YOofwWZcJhH3n6LSONvzNgMNPcp8mJYmUdthX09 +u8r3uJdrA+n+EU6Po8eNG654DUI2UXl1mfEo7rw3qZE7Pw8KCpm45QoDBBIeqDI Ub9PA5avP7DNpYg5SA7yx+jxEO9jIGBIi4Fp6L308KrkGFPrb7pbRu/ZfS4yoX75 0nyiYr2CvTcy3CdQW0CHgBkgznCdJjdGPdUq53d4UQiUdPH2HDBgA0alGHS3KQwn xJXqIuAz1kHmayNIsesfsD84mThFD/2DnVBCL9OM/Bu1aNTr0a6c8ayxUmG0BRJF 4MGr7HB0SmrNPoyqkSgH+rZ5L84a7KLjT8bzMNxMfFmru5xYwBZwJIt359FanAba N7ZP5BT78McPcJmMHpC6+Vi/fJqZ7NN1HBpsr9Il5QZihgCQa6ec1yr68DJq9vD0 yDAFHgwELbX7QmjQup/s0A33nB/9o+e2jfWpdseMjaO8+ddMBzfMVRHnkXIWCJeH pWRFhodzyUrwBhw5u95t =TbbS -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- --===============0038128938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0038128938==--