Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Jesse Barnes <jesse.barnes@intel.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	Tom Gall <tom.gall@linaro.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	linux-media@vger.kernel.org,
	Stephen Warren <swarren@wwwdotorg.org>,
	Mark Zhang <markz@nvidia.com>,
	Alexandre Courbot <acourbot@nvidia.com>,
	Ragesh Radhakrishnan <Ragesh.R@linaro.org>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Sunil Joshi <joshi@samsung.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Vikas Sajjan <vikas.sajjan@linaro.org>,
	Marcus Lorentzon <marcus.lorentzon@huawei.com>
Subject: Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Date: Fri, 06 Sep 2013 16:09:13 +0200	[thread overview]
Message-ID: <9919519.TaAubJ8jzD@avalon> (raw)
In-Reply-To: <521B37BA.50706@ti.com>

[-- Attachment #1.1: Type: text/plain, Size: 2220 bytes --]

Hi Tomi,

On Monday 26 August 2013 14:10:50 Tomi Valkeinen wrote:
> On 09/08/13 20:14, Laurent Pinchart wrote:
> > MIPI DBI is a configurable-width parallel display bus that transmits
> > commands and data.
> > 
> > Add a new DBI Linux bus type that implements the usual bus
> > infrastructure (including devices and drivers (un)registration and
> > matching, and bus configuration and access functions).
> 
> This has been discussed before, but I don't remember that the issue would
> have been cleared, so I'm bringing it up again.
> 
> What benefit does a real Linux DBI (or DSI) bus give us, compared to
> representing the DBI the same way as DPI? DBI & DSI are in practice point-
> to-point buses, and they do not support probing. Is it just that because DBI
> and DSI can be used to control a device, they have to be Linux buses?

The idea was to reuse the Linux bus infrastructure to benefit from features 
such as power management. Implementing DBI/DSI control functions using a 
DBI/DSI bus is also pretty easy, and would allow controlling DBI/DSI entities 
much like we control I2C entities. I don't like the idea of using an I2C bus 
with I2C access functions on one side, and embedding the DBI/DSI access 
functions as part of CDF entity operations on the other side very much.

This being said, this isn't the part of CDF that matters the most to me (it's 
actually not part of CDF strictly speaking). If your model works well enough 
it won't be too hard to convince me :-)

> How do you see handling the devices where DBI or DSI is used for video only,
> and the control is handled via, say, i2c? The module has to register two
> drivers, and try to keep those in sync? I feel that could get rather hacky.

If DBI or DSI is used for video only you don't need DBI/DSI control 
operations, right ? So the entity driver will just be a regular I2C device 
driver.

> A real Linux bus would be necessary if we had devices that used DBI or DSI
> only for control, and some other video bus for video data. But that sounds
> so silly that I think we can just forget about the case.

I certainly hope so :-)

> Thus DBI and DSI are used either for video only, or video and control.

-- 
Regards,

Laurent Pinchart

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel