From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support Date: Thu, 5 Dec 2013 16:37:39 +0200 Message-ID: <52A08FB3.5040800@ti.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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1822395597==" Return-path: Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by gabe.freedesktop.org (Postfix) with ESMTP id A9D64FB929 for ; Thu, 5 Dec 2013 06:37:43 -0800 (PST) In-Reply-To: <20131127105401.GB9639@ulmo.nvidia.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Thierry Reding , Andrzej Hajda Cc: Kyungmin Park , Thierry Reding , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1822395597== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mkuFqpH78bBiJOvjCHh0B8opHMIWE13dm" --mkuFqpH78bBiJOvjCHh0B8opHMIWE13dm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-27 12:54, Thierry Reding wrote: >> 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, an= d > 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. (I speak here more in the context of OMAP display subsystem and CDF, and this might not be totally applicable to DRM). In my opinion, DSI shouldn't be though of in the same way as other buses.= 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. 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. I have never seen a pure hub, i.e. something that would just forward/broadcast the DSI packet to two or more DSI peripherals. 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. I don't see any benefit in trying to create a similar linux bus for DSI as we have for, say, i2c or spi. >> I can also imagine scenarios when dynamic virtual channel (re-)associa= tion >> can be useful and DSI specs are not against it AFAIK. >=20 > How is that going to work? There's no hotplug support or similar in DSI= , > so why would anyone want to reassign virtual channels. >=20 > Supposing even that we wanted to support this eventually, I think a mor= e > appropriate solution would be to completely remove the device and add a= > new one, because that also takes care of keeping the channel number > embedded within the struct mipi_dsi_device up to date. >=20 >> reg property means device is at fixed virtual channel. >> DSI specs says nothing about it IMHO. >=20 > Without that fixed virtual channel number we can't use the device in th= e > first place. How are you going to address the device if you don't know > its virtual channel? The DSI peripheral driver must know the VC IDs. Often they are hardcoded values, and they can be defined in the driver code. 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. Tomi --mkuFqpH78bBiJOvjCHh0B8opHMIWE13dm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSoI+zAAoJEPo9qoy8lh714/UP/iz6OoAi1NGdNl6vwssPqQbG mmye1DjFhGnpk4fbOCUL66rwEgCzt1ebeqX69wOR+2ONamT+VZWEy4RIsBJr9baq eCLjNi8DrmRFmnrxL+/B8A0MgCgyONNnUi/fWSS3rtgv4akqBkk3dIDWg/CPoBIF Nqf1CztsIqQl/25O0clIhcsToawdgvUEXD1NIJoo31fS02Gwapn4AHKbgjeoPeAa Cv7tFPpVA1vm3nEK0mRBYBQWYNB8woe/0pWkZYAIVCslJ/IR9+NejiwImdN1yVnn m7+FKhuEMb21e7LM+pCuz7X9y4YUaOhnox7jmqOm3eVwUSRm9JZhND5STPI4zrK+ 86CJDP/t7CgVDTK9xsf8rjkjuECrusZpL0AXzjhBIiPfMj64iqH0XpAv0mImcbwb tfZArASIIpnakhTUe/3ZuAux1U0ZVV7ZELMnXzsLO+TkB1IDmSv02TuYfhhzxQCp ReJAON8Ap6pNu9/tKp0Ysai7/rhmES1oWR0NJiap7ROSypRlJtQr0KkM/UW8m4ye NY73I8+y2ipA4lIG97WbW9eJDgixVh6/691dfZ6iSp4Lxlz6CZ+gzOEWC9MjOlAc xNGfZ8e7My3bo1UCDUP7OEtRmKfeeADlFhIoT8zqaKIVmbwwW7myat10Tl4Mgken n6mz/krwouFCyxbKxYue =g7V4 -----END PGP SIGNATURE----- --mkuFqpH78bBiJOvjCHh0B8opHMIWE13dm-- --===============1822395597== 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 --===============1822395597==--