From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrik Jakobsson Date: Wed, 21 Sep 2011 18:07:15 +0000 Subject: Re: Proposal for a low-level Linux display framework Message-Id: List-Id: References: <1316088425.11294.78.camel@lappyti> <1316100594.23214.65.camel@deskari> <1316107275.23214.99.camel@deskari> <20110916175326.54567b14@lxorguk.ukuu.org.uk> <1316414014.1978.12.camel@deskari> <1316417361.1978.48.camel@deskari> <1316584875.1949.4.camel@deskari> In-Reply-To: <1316584875.1949.4.camel@deskari> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tomi Valkeinen Cc: linaro-dev@lists.linaro.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Archit Taneja , "Clark, Rob" On Wed, Sep 21, 2011 at 8:01 AM, Tomi Valkeinen wrote: > I don't know what MCS is. MCS is manufacturer specific commands (Manufacturer Command Set). > But DSI is just a bi-directional transfer > protocol between the SoC and the peripheral, you can send arbitrary data > over it. > > Normally the SoC composes a pixel stream using overlays and whatnot, > which goes to the DSI hardware, which then serializes the data and sends > it to the peripheral. > > But you can as well send any data, like commands, and the peripheral can > respond with any relevant data. Ok it makes sense now, and I see how it can get more complicated than SDVO. A DSI lib is a good idea and interfaces for stuff like backlight and mechanisms for queuing commands that need to go in during blanking. Thanks for clearing it up -Patrik