On Fri, 2012-05-25 at 19:49 +0530, S, Venkatraman wrote:
> On Thu, May 24, 2012 at 10:56 PM, John Stultz wrote:
> > Hey Arnd, Rob,
> >So after Arnd's help sorting a workaround for the mmc driver, I'm now
> > trying to sort out the following HDMI failure I'm seeing w/ the current
> > 3.5-rc wit
On Tue, 2011-09-20 at 23:20 +0200, Patrik Jakobsson wrote:
> Ok, not sure I understand the complexity of DSI. Can overlay composition
> occur after/at the DSI stage (through MCS perhaps)? Or is it a matter of
> panels requiring special scanout buffer formats that for instance V4L needs
> to know a
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote:
> On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen
> wrote:
>
> > 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
>
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
On Thu, 2011-09-15 at 19:55 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen
> wrote:
>
> > 2) panel drivers, handles panel specific things. Each panel may support
> > custom commands and features, for which we need a dedicated driver. And
&
On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon whi
On Thu, 2011-09-15 at 09:59 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen
> wrote:
>
> > This was a very rough and quite short proposal, but I'm happy to improve
> > and extend it if it's not totally shot down.
>
> Jes
Hi,
I am the author of OMAP display driver, and while developing it I've
often felt that there's something missing in Linux's display area. I've
been planning to write a post about this for a few years already, but I
never got to it. So here goes at last!
---
First I want to (try to) describe sh
On Wed, 2011-09-07 at 15:00 +0900, Inki Dae wrote:
> Hello, Rob.
>
> > -Original Message-
> > From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
> > Clark
> > Sent: Tuesday, September 06, 2011 1:05 AM
> > To: Inki Dae
> > Cc: dri-de...@lists.freedesktop.org; linaro-dev
On Tue, 2011-06-21 at 10:18 +0530, Tushar Behera wrote:
> Hi,
>
> On Monday 20 June 2011 06:36 PM, Tomi Valkeinen wrote:
> > On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
> >> Currently display support for omap2 is selected by default and
> >> it gets
On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
> Currently display support for omap2 is selected by default and
> it gets built for all the configurations.
>
> Instead of it being a built-in feature, it's compilation should
> depend on the config option CONFIG_FB_OMAP2.
No, I don't think
On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
> In certain board files, there are references to vram related functions
> which are defined in drivers/video/omap2/vram.c. Because of this direct
> dependency, CONFIG_FB_OMAP2 should be a built-in feature.
arch/arm/plat-omap/include/plat/vra
12 matches
Mail list logo
