linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Keith Packard <keithp@keithp.com>,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-dev@lists.linaro.org,
	"Clark, Rob" <rob@ti.com>, Archit Taneja <archit@ti.com>
Subject: Re: Proposal for a low-level Linux display framework
Date: Mon, 19 Sep 2011 06:33:34 +0000	[thread overview]
Message-ID: <1316414014.1978.12.camel@deskari> (raw)
In-Reply-To: <20110916175326.54567b14@lxorguk.ukuu.org.uk>

On Fri, 2011-09-16 at 17:53 +0100, Alan Cox wrote:
> > I'm not sure a common interface to all of these different
> > channels makes sense, but surely a DSI library and an aux channel
> > library would fit nicely alongside the existing DDC library.
> 
> DSI and the various other MIPI bits tend to be horribly panel and device
> specific. In one sense yes its a standard with standard commands,
> processes, queries etc, on the other a lot of stuff is oriented around
> the 'its a fixed configuration unit we don't need to have queries' view.

I think it's a bit more complex than that. True, there are MIPI
standards, for the video there are DPI, DBI, DSI, and for the commands
there is DCS. And, as you mentioned, many panels need custom
initialization, or support only parts of the DCS, or have other quirks.

However, I think the biggest thing to realize here is that DSI
peripherals can be anything. It's not always so that you have a DSI bus
and a single panel connected to it. You can have hubs, buffer chips,
etc.

We need DSI peripheral device drivers for those, a single "DSI output"
driver cannot work. And this is also the most important thing in my
original proposition.

> There also tends to be a lot of vendor magic initialisation logic both
> chipset and device dependant, and often 'plumbing dependant' on SoC

While I have DSI experience with only one SoC, I do believe it'd be
possible to create a DSI API that would allow us to have platform
independent DSI peripheral drivers.

Can you share any SoC side DSI peculiarities on Intel's SoCs?

 Tomi



  reply	other threads:[~2011-09-19  6:33 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-15 12:07 Proposal for a low-level Linux display framework Tomi Valkeinen
2011-09-15 14:59 ` Keith Packard
2011-09-15 15:29   ` Tomi Valkeinen
2011-09-15 15:50     ` Keith Packard
2011-09-15 17:05       ` Alan Cox
2011-09-17 21:36         ` Laurent Pinchart
2011-09-15 17:12       ` Florian Tobias Schandinat
2011-09-15 17:18         ` Alan Cox
2011-09-15 17:47           ` Florian Tobias Schandinat
2011-09-15 19:05             ` Alan Cox
2011-09-15 19:46               ` Florian Tobias Schandinat
2011-09-15 21:31                 ` Alan Cox
2011-09-15 17:52         ` Alex Deucher
2011-09-15 17:56           ` Geert Uytterhoeven
2011-09-15 18:04             ` Alex Deucher
2011-09-15 18:39           ` Florian Tobias Schandinat
2011-09-15 18:58             ` Alan Cox
2011-09-15 19:18               ` Florian Tobias Schandinat
     [not found]                 ` <4E724F93.1050203-Mmb7MZpHnFY@public.gmane.org>
2011-09-15 19:28                   ` Alan Cox
2011-09-15 19:45                 ` Alex Deucher
2011-09-17 14:44               ` Felipe Contreras
2011-09-17 15:16                 ` Rob Clark
2011-09-17 16:11                   ` Florian Tobias Schandinat
2011-09-17 16:47                     ` Dave Airlie
2011-09-17 18:15                       ` Florian Tobias Schandinat
2011-09-17 18:23                         ` Dave Airlie
2011-09-17 19:06                           ` Florian Tobias Schandinat
2011-09-17 19:25                             ` Corbin Simpson
2011-09-17 21:25                             ` Alex Deucher
2011-09-17 20:25                           ` Alan Cox
2011-10-31 20:24                             ` Jesse Barnes
2011-09-17 16:50                     ` Rob Clark
2011-09-16  4:53             ` Keith Packard
2011-09-17 23:12             ` Laurent Pinchart
2011-09-18 16:14               ` Rob Clark
2011-09-18 21:55                 ` Laurent Pinchart
     [not found]               ` <201109180112.15896.laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2011-09-18 22:23                 ` Alan Cox
2011-09-19  0:09                   ` Rob Clark
2011-09-20 23:32                     ` Laurent Pinchart
2011-09-15 18:12         ` Keith Packard
2011-09-15 17:21       ` Tomi Valkeinen
2011-09-15 18:32         ` Rob Clark
2011-09-16  0:55         ` Keith Packard
2011-09-16  6:38           ` Tomi Valkeinen
2011-09-16 14:17           ` Daniel Vetter
2011-09-16 16:53           ` Alan Cox
2011-09-19  6:33             ` Tomi Valkeinen [this message]
2011-09-19  6:53               ` Keith Packard
2011-09-19  7:29                 ` Tomi Valkeinen
2011-09-20  8:29                   ` Patrik Jakobsson
2011-09-20 15:55                     ` Keith Packard
2011-09-20 21:20                       ` Patrik Jakobsson
2011-09-21  6:01                         ` Tomi Valkeinen
2011-09-21 18:07                           ` Patrik Jakobsson
2011-09-15 15:03 ` Kyungmin Park
2011-09-21 13:26 ` Heiko Stübner

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=1316414014.1978.12.camel@deskari \
    --to=tomi.valkeinen@ti.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=archit@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=keithp@keithp.com \
    --cc=linaro-dev@lists.linaro.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).