[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMeQTsbP-_ut7BA3YQ+qgtqfM1tzM4qn3jxHT8B8_0hdPbP3Jg@mail.gmail.com>
Date: Tue, 20 Sep 2011 10:29:23 +0200
From: Patrik Jakobsson <patrik.r.jakobsson@...il.com>
To: Tomi Valkeinen <tomi.valkeinen@...com>
Cc: Keith Packard <keithp@...thp.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linaro-dev@...ts.linaro.org,
"Clark, Rob" <rob@...com>, Archit Taneja <archit@...com>
Subject: Re: Proposal for a low-level Linux display framework
On Mon, Sep 19, 2011 at 9:29 AM, Tomi Valkeinen wrote:
>> So DSI is more like i2c than the DisplayPort aux channel or DDC. That
>
> Well, not quite. DSI is like DisplayPort and DisplayPort aux combined;
> there's only one bus, DSI, which is used to transfer video data and
> commands.
>
> For DSI video mode, the transfer is somewhat like traditional displays,
> and video data is send according to a pixel clock as a constant stream.
> However, before the video stream is enabled the bus can be used in
> bi-directional communication. And even when the video stream is enabled,
> there can be other communication in the blanking periods.
This sounds a lot like SDVO. You communicate with the SDVO chip through
i2c and then do a bus switch to get to the DDC. You also have the GMBus
with interrupt support that can help you do the i2c transfers.
SDVO supports many connectors and can have multiple in and out channels
so some setups are a bit complicated.
It would be nice to have a model that fits both DSI and SDVO, and the option
to configure some of it from userspace.
I thought the purpose of drm_encoder was to abstract hardware like this?
-Patrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists