All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Andrzej Hajda <a.hajda@samsung.com>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>,
	Thierry Reding <treding@nvidia.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support
Date: Fri, 13 Dec 2013 13:29:17 +0200	[thread overview]
Message-ID: <52AAEF8D.7040804@ti.com> (raw)
In-Reply-To: <52AAEDEB.5090102@samsung.com>


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

On 2013-12-13 13:22, Andrzej Hajda wrote:
> On 12/12/2013 01:19 PM, Thierry Reding wrote:
>> On Tue, Dec 10, 2013 at 11:19:54AM +0200, Tomi Valkeinen wrote:
>>> On 2013-12-09 18:10, Thierry Reding wrote:
>>>
>>> Btw, about single linux device handling multiple VC IDs: I noticed that
>>> the DSI spec has an example, in which a DSI peripheral receives
>>> interlaced video, and the video packets containing even field have VC ID
>>> 0 and packets for odd field have VC ID 1. I'm not sure how relevant
>>> interlaced video is, but I think there's an example where having
>>> separate linux devices for each VC ID would be somewhat clumsy.
>> Ugh... that's pretty bad.
> I wonder if this scenario could not be solved just
> by allowing range of VCs per device, for example:
> dsi {
>         #address-cells = <1>;
>         #size-cells = <1>;
>         panel_with_interleaved_vc@0 {
>              reg = <0, 2>;
>         };
> };

I don't think range is good, as then you can't have, say, VC IDs 0 and
2. But giving the VC IDs individually as I did in my recent reply,
should do the same thing as above, without ranges.

It's still open to me if that method is good or not.

 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-12-13 11:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 16:25 [RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support Andrzej Hajda
2013-11-22 17:41 ` Thierry Reding
2013-11-25 15:05   ` Andrzej Hajda
2013-11-27 10:54     ` Thierry Reding
2013-11-29 15:28       ` Andrzej Hajda
2013-12-02 10:22         ` Thierry Reding
2013-12-05 14:37       ` Tomi Valkeinen
2013-12-06 12:54         ` Thierry Reding
2013-12-09 11:34           ` Tomi Valkeinen
2013-12-09 13:10             ` Thierry Reding
2013-12-09 15:05               ` Tomi Valkeinen
2013-12-09 16:10                 ` Thierry Reding
2013-12-10  9:19                   ` Tomi Valkeinen
2013-12-12 12:19                     ` Thierry Reding
2013-12-13 11:21                       ` Tomi Valkeinen
2013-12-13 11:22                       ` Andrzej Hajda
2013-12-13 11:29                         ` Tomi Valkeinen [this message]
2013-12-13 12:06                           ` Thierry Reding
2013-12-13 12:23                             ` Tomi Valkeinen

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=52AAEF8D.7040804@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=a.hajda@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kyungmin.park@samsung.com \
    --cc=thierry.reding@gmail.com \
    --cc=treding@nvidia.com \
    /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.