From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: Multiple parents in device driver model and Common Display Framework (CDF) Date: Tue, 12 Feb 2013 17:53:16 +0200 Message-ID: <511A656C.1050404@ti.com> References: <511A5A15.4000306@stericsson.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1673352618==" Return-path: Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by gabe.freedesktop.org (Postfix) with ESMTP id A1B0CE6408 for ; Tue, 12 Feb 2013 07:53:27 -0800 (PST) In-Reply-To: <511A5A15.4000306@stericsson.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: Marcus Lorentzon Cc: arnd@arndb.de, marcus.lorentzon@linaro.org, gregkh@linuxfoundation.org, "dri-devel@lists.freedesktop.org" , Laurent Pinchart , Daniel Vetter List-Id: dri-devel@lists.freedesktop.org --===============1673352618== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDE6B9334CD10E33E530243AF" --------------enigDE6B9334CD10E33E530243AF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marcus, On 2013-02-12 17:04, Marcus Lorentzon wrote: > Now we have some different types of panels which are attached on a > combination of busses: >=20 > a) control:DBI, data:DBI > b) control:I2C/SPI, data:I2C/SPI > c) control:static setup, data:DPI > d) control:I2C/SPI, data:DPI > e) control:DSI, data:DSI > f) control:I2C, data:DSI > g) control:DSI+I2C, data:DSI >=20 > As you could guess, g) is our issue. We have a device family that has > two control bus attachments and one data bus. The kernel device/driver > model only supports a single parent device which is normally the bus > device. >=20 > We will write drivers for all device types a-g implementing the CDF API= =2E > Those with only I2C/SPI bus attachemnt will of course be I2C drivers > registered to CDF, same probably goes for DBI and DSI panels if we > create a new bus type for them (if not - platform devices). But the CDF= > drivers still need some way to access the bus/host operations. So we > will have to create an API for the exposed operations possible for the > MIPI type busses (DBI/DSI/DPI), some control and some data bus related.= > For this problem we have discussed a few solutions, which is where we > need your guidance: >=20 > 1) Due to the fact there is no support for multiple parents in the > device driver model and the fact that there are no DSI/DBI busses in th= e > kernel, Tomi has come up with a sort of logical parent device for > displays (see video source section, top section is "CDF API"): > http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf= /include/video/display.h When I made that, I didn't even have in mind the case g). I made it because I think we have issues with case f) also (and, well, in some sense we have issues with all cases. see below). If we have a full linux bus for DSI and DBI, I don't quite understand how we should manage f), because we have both I2C and DSI busses to which the display device should belong. I also had these points in my mind why I chose the video_source approach in my version: - The display busses are very specialized, point-to-point busses, so a real linux bus doesn't give very much, I think. - You never have a video bus used only for control, for example, a panel controlled via DSI but video data sent via DPI. Yes, possible in theory, but that would be rather insane. - We anyway need some kind of non-bus approach for simple video data busses like DPI. And if we have that, the slightly more complex video busses like DSI fit quite easily in. - We need something to represent all the data busses (see below). > Pros: Simple, easy to implement, merging all bus types into one logical= > bus (simplicity) > Cons: Diverging from device driver model, merging all bus types into on= e > logical bus (scalability, maintainability), has to make a copy of many > things already in device driver model (pm, enumeration, registration, > relations, ...), solution only really needed for one special type (g) It's not only for g). We need something similar for all cases. We need to represent the chain of display devices with something, which is based on the data busses. The control bus plays no role in this chain (except when the data and control busses happen to be the same). My video_source really represents the data bus, but offers some extended features so that it also offers control bus operations for those video busses that have control and data in the same bus. If we go for a full DSI/DBI linux bus, we still need something to represent the video bus. Then we'll have two separate entities for DSI control (the real bus) and for DSI data (video_source or similar), which in the end go via the same physical DSI bus. Tomi --------------enigDE6B9334CD10E33E530243AF 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.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGmVsAAoJEPo9qoy8lh71iLEP/A8X37qAep3vfnepr/772mxa CsEvC81y7uW1JfgtPEJxd0JlLAxpSslpW1VFOJST1GbQF4vUbEWuLgw55RocWuvB 2ks03qTs0ei/UvpgFN+YEJRste0PU/lMGDwhRP23O2kDJxUCH0lEf/mMAKZgYfrE 2TtRLjY+vQYvgORJxjLmEV9uGQ7zYhzReP/y4nfqmK5/eECQoMQ69SdMhxr6fE17 9uWa9U8K/zOxKaq3RtFFC5cJXfi28dqB0aMaxQaDbCZKRmDWbC7mR2dwVrDtXW75 5LFB1Cw3M6zUPdhBbwzPd+hLefuGl7Ze+hjfkdNswdBjRz5hUTBgo7HU/7lk92We I6SxIi48WVjoNVaMT3cZ1WTAjJf/0gvgYgJfd7IeX5Iy1gxFQwE0ZMIFLXRUsJdd OMprn7xVG32GkscoRQZydgN8Vp3eoOehMm0Xr3b8wCaSp2S988TV2WpMxRwAri0I fX8Nr8VYUCr1J3V0eOaG8/NxiiNjgy2mW58SYKduFLGJwZ8K8cZCZpDAy/Poo/Js 23RRYN9zNOmxEvr9eKh7J9BJUZYDHwa4+Lm67SwCPxJvSqI4v7Xdrbmd/jHzugfK VNkzQRkWw9whpvaFf/otf+hc8IeeOho9nTfFDQxVsw3u75eVYcLZBQpujiJ81XY1 5UJQElSy2oV7cW5so7AX =qDg/ -----END PGP SIGNATURE----- --------------enigDE6B9334CD10E33E530243AF-- --===============1673352618== 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 --===============1673352618==--