All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.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, 6 Sep 2013 18:43:57 +0300	[thread overview]
Message-ID: <5229F83D.1010400@ti.com> (raw)
In-Reply-To: <9919519.TaAubJ8jzD@avalon>


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

On 06/09/13 17:09, Laurent Pinchart wrote:
> 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.

While I somewhat like the thought of having DBI and DSI as Linux buses,
I just don't see how it would work. Well, I'm mostly thinking about DSI
here, I have not used DBI for years.

Also, I might remember wrong, but I think I saw Linus expressing his
opinion at some point that he doesn't really like the idea of having a
Linux bus for simple point-to-point buses, which don't have probing
support, and so there isn't much "bus" to speak of, just a point to
point link.

And I think we get the same power management with just having a device
as a child device of another.

> 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.

Well, DSI can't be used just like that. You need to configure it.

The thing is, DSI is used for both control and video. They are really
the same thing, both are sent as DSI packets. Both need similar kind of
configuration for the bus. If the DSI peripheral sits on a DSI bus, I
imagine this configuration is done via the DSI bus support. But if
there's no DSI bus, how is the configuration done?

I guess a possibility is to have a fixed configuration that cannot be
changed dynamically. But I have a feeling that it'll be a bit limiting
for some cases.

And even with fixed configuration, I think the configuration would
somehow be passed as DSI bus parameters from the board files or in the
DT data (the same way as, say i2c bus speed). If there's no DSI bus, as
the DSI peripheral sits on the i2c bus, where are the parameters?

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 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

  reply	other threads:[~2013-09-06 15:44 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-09 17:14 [PATCH/RFC v3 00/19] Common Display Framework Laurent Pinchart
2013-08-09 17:14 ` [PATCH/RFC v3 01/19] OMAPDSS: panels: Rename Kconfig options to OMAP2_DISPLAY_* Laurent Pinchart
2013-08-09 17:14 ` [PATCH/RFC v3 02/19] video: Add Common Display Framework core Laurent Pinchart
2013-09-02  8:42   ` Tomi Valkeinen
2013-09-03 11:29     ` Laurent Pinchart
2013-08-09 17:14 ` [PATCH/RFC v3 03/19] video: display: Add video and stream control operations Laurent Pinchart
2013-08-09 17:14 ` [PATCH/RFC v3 04/19] video: display: Add display entity notifier Laurent Pinchart
2013-08-09 17:14 ` [PATCH/RFC v3 05/19] video: display: Graph helpers Laurent Pinchart
2013-08-09 17:14 ` [PATCH/RFC v3 06/19] video: display: OF support Laurent Pinchart
2013-08-13 14:37   ` Philipp Zabel
2013-08-21  1:02     ` Laurent Pinchart
2013-08-21  9:10       ` Philipp Zabel
2013-08-22  0:51         ` Laurent Pinchart
2013-08-09 17:14 ` [PATCH/RFC v3 07/19] video: display: Add pixel coding definitions Laurent Pinchart
2013-08-09 17:14 ` [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support Laurent Pinchart
2013-08-14  0:52   ` Rob Clark
2013-08-20 13:26     ` Laurent Pinchart
2013-08-26 11:10   ` Tomi Valkeinen
2013-09-06 14:09     ` Laurent Pinchart
2013-09-06 15:43       ` Tomi Valkeinen [this message]
2013-09-07  9:35         ` Tomi Valkeinen
2013-09-04 10:50   ` Vikas Sajjan
2013-09-06 14:37     ` Laurent Pinchart
2013-09-18 10:59       ` Vikas Sajjan
2013-09-04 12:52   ` Vikas Sajjan
2013-09-06 14:56     ` Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 09/19] video: panel: Add DPI panel support Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 10/19] video: panel: Add R61505 " Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 11/19] video: panel: Add R61517 " Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 12/19] video: display: Add VGA Digital to Analog Converter support Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 13/19] video: display: Add VGA connector support Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 14/19] ARM: shmobile: r8a7790: Add DU clocks for DT Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 15/19] ARM: shmobile: r8a7790: Add DU device node to device tree Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 16/19] ARM: shmobile: marzen: Port DU platform data to CDF Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 17/19] ARM: shmobile: lager: " Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 18/19] ARM: shmobile: lager-reference: Add display device nodes to device tree Laurent Pinchart
2013-08-09 17:15 ` [PATCH/RFC v3 19/19] drm/rcar-du: Port to the Common Display Framework Laurent Pinchart
2013-08-14  0:43 ` [PATCH/RFC v3 00/19] " Rob Clark
2013-08-20 15:24   ` Laurent Pinchart
2013-08-20 18:40     ` Rob Clark
2013-08-21  7:09       ` Sascha Hauer
2013-08-21 12:22         ` Rob Clark
2013-09-06 16:16           ` Laurent Pinchart
2013-09-09 12:12           ` Tomi Valkeinen
2013-09-09 14:17             ` Rob Clark
2013-09-09 14:58               ` Tomi Valkeinen
2013-09-09 15:10                 ` Rob Clark
2013-09-02 11:06 ` Tomi Valkeinen
2013-09-30 13:48 ` Tomi Valkeinen
2013-10-02 12:23   ` Andrzej Hajda
2013-10-02 12:23     ` Andrzej Hajda
2013-10-02 13:24     ` Tomi Valkeinen
2013-10-02 13:24       ` Tomi Valkeinen
2013-10-02 13:24       ` Tomi Valkeinen
2013-10-09 14:08       ` Andrzej Hajda
2013-10-09 14:08         ` Andrzej Hajda
2013-10-11  6:37         ` Tomi Valkeinen
2013-10-11  6:37           ` Tomi Valkeinen
2013-10-11  6:37           ` Tomi Valkeinen
2013-10-11 11:19           ` Andrzej Hajda
2013-10-11 11:19             ` Andrzej Hajda
2013-10-11 12:30             ` Tomi Valkeinen
2013-10-11 12:30               ` Tomi Valkeinen
2013-10-11 12:30               ` Tomi Valkeinen
2013-10-11 14:16               ` Andrzej Hajda
2013-10-11 14:16                 ` Andrzej Hajda
2013-10-11 14:45                 ` Tomi Valkeinen
2013-10-11 14:45                   ` Tomi Valkeinen
2013-10-11 14:45                   ` Tomi Valkeinen
2013-10-17  7:48                   ` Andrzej Hajda
2013-10-17  7:48                     ` Andrzej Hajda
2013-10-17  8:18                     ` Tomi Valkeinen
2013-10-17  8:18                       ` Tomi Valkeinen
2013-10-17  8:18                       ` Tomi Valkeinen
2013-10-17 12:26                       ` Andrzej Hajda
2013-10-17 12:26                         ` Andrzej Hajda
2013-10-17 12:55                         ` Tomi Valkeinen
2013-10-17 12:55                           ` Tomi Valkeinen
2013-10-17 12:55                           ` Tomi Valkeinen
2013-10-18 11:55                           ` Andrzej Hajda
2013-10-18 11:55                             ` Andrzej Hajda
2013-08-09 23:02 Laurent Pinchart
2013-08-09 23:03 ` [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support Laurent Pinchart
2013-08-09 23:03   ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5229F83D.1010400@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=Ragesh.R@linaro.org \
    --cc=acourbot@nvidia.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jesse.barnes@intel.com \
    --cc=joshi@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=marcus.lorentzon@huawei.com \
    --cc=markz@nvidia.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=swarren@wwwdotorg.org \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tom.gall@linaro.org \
    --cc=vikas.sajjan@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.