* Re: Future desktop on dumb frame buffers?
From: Alex Deucher @ 2011-03-21 21:46 UTC (permalink / raw)
To: Ondrej Zary
Cc: Linux Fbdev development list, Geert Uytterhoeven,
timofonic timofonic, dri-devel, wayland-devel
In-Reply-To: <201103212213.51565.linux@rainbow-software.org>
On Mon, Mar 21, 2011 at 5:13 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
>> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org>
> wrote:
>> > On Mon, 21 Mar 2011 19:19:43 +0000
>> >
>> > timofonic timofonic <timofonic@gmail.com> wrote:
>> >> So if KMS is so cool and provides many advantages over fbdev and
>> >> such... Why isn't more widely used intead of still relying on fbdev?
>> >> Why still using fbdev emulation (that is partial and somewhat broken,
>> >> it seems) instead using KMS directly?
>> >
>> > Used by what? All three major GPU device classes have KMS support
>> > (Intel, ATI, and nVidia). If you want it for a particular device, you
>> > can always port it over.
>> >
>> > As for fbdev emulation, what's still using it? There's nothing
>> > stopping projects from converting over; X and Wayland can already
>> > handle KMS APIs just fine.
>> >
>> >> I know the graphic driver situation is quite bad on Linux, especially
>> >> on the embedded world. Fbdev seems is still quite used there by binary
>> >> blob drivers.
>> >
>> > Probably for a couple of reasons:
>> > 1) inertia: fbdev has been around a lot longer, and provides most of
>> > what embedded devices need anyway
>> > 2) feature set: why bother doing a full KMS driver if you're not
>> > going to use any of the additional features it would provide (output
>> > management, memory management, execution management)
>>
>> Related: We are still missing basic userspace tools (kmsset, e.g.),
>> some kind of direct KMS console (kmscon would work, if it existed),
>> and an xf86-video-modesetting which compiles and works (this is
>> actually possible now, with some patches that landed in 2.6.38 for
>> generic KMS access.)
>
> This looks interesting. If existing *fb drivers could be easily converted to
> KMS (including 2D acceleration) and then used in X with a common driver, it
> would be great. Let's say, convert cyber2000fb driver to KMS and use it in X
> with 2D acceleration.
You'd need to update the existing DDX to work with KMS. Generally you
need some sort of userspace driver to allocate the buffers, deal with
acceleration alignment, build the acceleration command buffers, and
interface with X.
Alex
>
>> This is important to me, as the various old drivers I've been hacking
>> on won't be accepted upstream without some sort of userspace which can
>> work with them. One of the big goals of KMS was a generic
>> userspace-facing API, like FB, but without the suck.
>
>
> --
> Ondrej Zary
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Matt Turner @ 2011-03-21 21:37 UTC (permalink / raw)
To: Alan Cox
Cc: Linux Fbdev development list, dri-devel, wayland-devel,
Geert Uytterhoeven, timofonic timofonic
In-Reply-To: <20110321212008.384711f0@lxorguk.ukuu.org.uk>
On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> 1) inertia: fbdev has been around a lot longer, and provides most of
>> what embedded devices need anyway
>> 2) feature set: why bother doing a full KMS driver if you're not
>> going to use any of the additional features it would provide (output
>> management, memory management, execution management)
>
> 3) its got documentation
My summer of code project's purpose was to create something of a
tutorial for writing a KMS driver. The code, split out into something
like 15 step-by-step patches, and accompanying documentation are
available from Google's website.
http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz
My repository (doesn't include the documentation) is available here:
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary
There's a 'rebased' branch that contains API changes required for the
code to work with 2.6.37~.
It's nothing fantastic, but I've had a number of people tell me that
it was useful for them.
Thanks,
Matt
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 21:22 UTC (permalink / raw)
To: Alan Cox
Cc: timofonic timofonic, Geert Uytterhoeven,
Linux Fbdev development list,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20110321212008.384711f0-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
On Mon, 21 Mar 2011 21:20:08 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > 1) inertia: fbdev has been around a lot longer, and provides most of
> > what embedded devices need anyway
> > 2) feature set: why bother doing a full KMS driver if you're not
> > going to use any of the additional features it would provide (output
> > management, memory management, execution management)
>
> 3) its got documentation
Jeez, some people want it all.
You looking for docs for the ioctls and such?
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Alan Cox @ 2011-03-21 21:20 UTC (permalink / raw)
To: Jesse Barnes
Cc: timofonic timofonic, Geert Uytterhoeven,
Linux Fbdev development list, dri-devel, wayland-devel
In-Reply-To: <20110321122518.6b7ec7e4@jbarnes-desktop>
> 1) inertia: fbdev has been around a lot longer, and provides most of
> what embedded devices need anyway
> 2) feature set: why bother doing a full KMS driver if you're not
> going to use any of the additional features it would provide (output
> management, memory management, execution management)
3) its got documentation
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Ondrej Zary @ 2011-03-21 21:13 UTC (permalink / raw)
To: dri-devel
Cc: Linux Fbdev development list, wayland-devel, Geert Uytterhoeven,
timofonic timofonic
In-Reply-To: <AANLkTi=kRdC1LoHxqwKxYKZJf99vBEU=OmQoY+zS1dK-@mail.gmail.com>
On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org>
wrote:
> > On Mon, 21 Mar 2011 19:19:43 +0000
> >
> > timofonic timofonic <timofonic@gmail.com> wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what? All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia). If you want it for a particular device, you
> > can always port it over.
> >
> > As for fbdev emulation, what's still using it? There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
> >
> >> I know the graphic driver situation is quite bad on Linux, especially
> >> on the embedded world. Fbdev seems is still quite used there by binary
> >> blob drivers.
> >
> > Probably for a couple of reasons:
> > 1) inertia: fbdev has been around a lot longer, and provides most of
> > what embedded devices need anyway
> > 2) feature set: why bother doing a full KMS driver if you're not
> > going to use any of the additional features it would provide (output
> > management, memory management, execution management)
>
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)
This looks interesting. If existing *fb drivers could be easily converted to
KMS (including 2D acceleration) and then used in X with a common driver, it
would be great. Let's say, convert cyber2000fb driver to KMS and use it in X
with 2D acceleration.
> This is important to me, as the various old drivers I've been hacking
> on won't be accepted upstream without some sort of userspace which can
> work with them. One of the big goals of KMS was a generic
> userspace-facing API, like FB, but without the suck.
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH 16/20] video: msm: Set the EBI1 clock to 128MHz when performing
From: Stephen Boyd @ 2011-03-21 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485562-27560-1-git-send-email-carlv@codeaurora.org>
On 03/18/2011 02:59 PM, Carl Vanderlip wrote:
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index b03204d..0bb19fa 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -656,6 +657,13 @@ int mdp_probe(struct platform_device *pdev)
> goto error_get_mdp_clk;
> }
>
> + mdp->ebi1_clk = clk_get(NULL, "ebi1_clk");
Please pass a device pointer as the first argument so we can match up
the ebi1_clk to the right device. MSM supports clkdev now so it's fairly
simple to do this.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Alex Deucher @ 2011-03-21 20:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: dri-devel, timofonic timofonic, Linux Fbdev development list,
wayland-devel
In-Reply-To: <AANLkTikAeQ=z-M3kW2zPgVRK-bmoiTeA5ktjjTokEybW@mail.gmail.com>
On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> On Mon, 21 Mar 2011 19:19:43 +0000
>> timofonic timofonic <timofonic@gmail.com> wrote:
>>> So if KMS is so cool and provides many advantages over fbdev and
>>> such... Why isn't more widely used intead of still relying on fbdev?
>>> Why still using fbdev emulation (that is partial and somewhat broken,
>>> it seems) instead using KMS directly?
>>
>> Used by what? All three major GPU device classes have KMS support
>> (Intel, ATI, and nVidia). If you want it for a particular device, you
>> can always port it over.
>
> The three major GPU device classes on PC...
Sadly it gets worse. A lot of the SoC vendors are adding an fbdev
emulation layer on top of v4l rather than using fbdev directly or
using KMS and v4l has grown it's own edid, hdmi, and cec handling.
Alex
>
>> As for fbdev emulation, what's still using it? There's nothing
>> stopping projects from converting over; X and Wayland can already
>> handle KMS APIs just fine.
>
> Can Wayland handle fbdev APIs ...
>
>>> I know the graphic driver situation is quite bad on Linux, especially
>>> on the embedded world. Fbdev seems is still quite used there by binary
>>> blob drivers.
>>
>> Probably for a couple of reasons:
>> 1) inertia: fbdev has been around a lot longer, and provides most of
>> what embedded devices need anyway
>> 2) feature set: why bother doing a full KMS driver if you're not
>> going to use any of the additional features it would provide (output
>> management, memory management, execution management)
>
> ... if no additional features of KMS are needed?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 19:59 UTC (permalink / raw)
To: Corbin Simpson
Cc: timofonic timofonic, Geert Uytterhoeven,
Linux Fbdev development list, dri-devel, wayland-devel
In-Reply-To: <AANLkTi=kRdC1LoHxqwKxYKZJf99vBEU=OmQoY+zS1dK-@mail.gmail.com>
On Mon, 21 Mar 2011 12:34:38 -0700
Corbin Simpson <mostawesomedude@gmail.com> wrote:
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)
Yeah, we used to call that drmcon, and it's still a big open. I think
there are some projects that sit on top of fbdev and provide a good
text console with fancy character and input support, but I don't know
if any of them have been ported to KMS to handle multiple outputs or
with an aim toward integrating into a distro as a VT replacement.
kmsset or something would be pretty easy to do; the modetest program in
the drm repo would be a good starting point for that. One limitation
there is handling fbcon, which makes reallocation of the framebuffer
somewhat difficult.
IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 19:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: timofonic timofonic, Linux Fbdev development list, dri-devel,
wayland-devel
In-Reply-To: <AANLkTikAeQ=z-M3kW2zPgVRK-bmoiTeA5ktjjTokEybW@mail.gmail.com>
On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Mon, 21 Mar 2011 19:19:43 +0000
> > timofonic timofonic <timofonic@gmail.com> wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what? All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia). If you want it for a particular device, you
> > can always port it over.
>
> The three major GPU device classes on PC...
Yes, good point. :)
> > As for fbdev emulation, what's still using it? There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
>
> Can Wayland handle fbdev APIs ...
Yes. Fundamentally, the Wayland protocol just assumes a way to share
buffers between processes. For the software raster version of the Qt
port, Kristian created a shmem interface for doing that to allow the
results of CPU rendering to be passed around without copying. On an
embedded device that would be one way to go.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Geert Uytterhoeven @ 2011-03-21 19:50 UTC (permalink / raw)
To: Jesse Barnes
Cc: timofonic timofonic, Linux Fbdev development list, dri-devel,
wayland-devel
In-Reply-To: <20110321122518.6b7ec7e4@jbarnes-desktop>
On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 21 Mar 2011 19:19:43 +0000
> timofonic timofonic <timofonic@gmail.com> wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what? All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia). If you want it for a particular device, you
> can always port it over.
The three major GPU device classes on PC...
> As for fbdev emulation, what's still using it? There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.
Can Wayland handle fbdev APIs ...
>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
> 1) inertia: fbdev has been around a lot longer, and provides most of
> what embedded devices need anyway
> 2) feature set: why bother doing a full KMS driver if you're not
> going to use any of the additional features it would provide (output
> management, memory management, execution management)
... if no additional features of KMS are needed?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Corbin Simpson @ 2011-03-21 19:34 UTC (permalink / raw)
To: Jesse Barnes
Cc: timofonic timofonic, Geert Uytterhoeven,
Linux Fbdev development list, dri-devel, wayland-devel
In-Reply-To: <20110321122518.6b7ec7e4@jbarnes-desktop>
On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 21 Mar 2011 19:19:43 +0000
> timofonic timofonic <timofonic@gmail.com> wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what? All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia). If you want it for a particular device, you
> can always port it over.
>
> As for fbdev emulation, what's still using it? There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.
>
>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
> 1) inertia: fbdev has been around a lot longer, and provides most of
> what embedded devices need anyway
> 2) feature set: why bother doing a full KMS driver if you're not
> going to use any of the additional features it would provide (output
> management, memory management, execution management)
Related: We are still missing basic userspace tools (kmsset, e.g.),
some kind of direct KMS console (kmscon would work, if it existed),
and an xf86-video-modesetting which compiles and works (this is
actually possible now, with some patches that landed in 2.6.38 for
generic KMS access.)
This is important to me, as the various old drivers I've been hacking
on won't be accepted upstream without some sort of userspace which can
work with them. One of the big goals of KMS was a generic
userspace-facing API, like FB, but without the suck.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
<MostAwesomeDude@gmail.com>
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 19:25 UTC (permalink / raw)
To: timofonic timofonic
Cc: Linux Fbdev development list, Geert Uytterhoeven,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <AANLkTimjOs8ZuKRUt1aOizhbRw2-Ni4bTPty-dKpZ-rz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic <timofonic@gmail.com> wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using KMS directly?
Used by what? All three major GPU device classes have KMS support
(Intel, ATI, and nVidia). If you want it for a particular device, you
can always port it over.
As for fbdev emulation, what's still using it? There's nothing
stopping projects from converting over; X and Wayland can already
handle KMS APIs just fine.
> I know the graphic driver situation is quite bad on Linux, especially
> on the embedded world. Fbdev seems is still quite used there by binary
> blob drivers.
Probably for a couple of reasons:
1) inertia: fbdev has been around a lot longer, and provides most of
what embedded devices need anyway
2) feature set: why bother doing a full KMS driver if you're not
going to use any of the additional features it would provide (output
management, memory management, execution management)
Jesse
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: timofonic timofonic @ 2011-03-21 19:19 UTC (permalink / raw)
To: Jesse Barnes
Cc: Linux Fbdev development list, Geert Uytterhoeven,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20110321110040.6f1ea6d3@jbarnes-desktop>
Hello.
I have some rants and questions about fbdev, KMS and graphics stuff to
Linux. I'm just a mere user and occasional system administrator (and
going to start computer programming soon), but I hope to be able to
understand this situation better.
So if KMS is so cool and provides many advantages over fbdev and
such... Why isn't more widely used intead of still relying on fbdev?
Why still using fbdev emulation (that is partial and somewhat broken,
it seems) instead using KMS directly?
I know the graphic driver situation is quite bad on Linux, especially
on the embedded world. Fbdev seems is still quite used there by binary
blob drivers.
I was a fan of projects like DirectFB and such, but it seems they lack
the manpower or fuel to keep the project relevant. Maybe Wayland can
be their substitute and even have a broader usage too.
I hope KMS gets stronger and the graphic drivers get more into the
open source world (instead violating GPL and doing an attitude I think
should be illegal), that news about open source PowerVR SGX drivers
seems very positive (and surprising, because Imagination Technologies
seems quite against FOSS).
I hope all this gets to suck a bit less. Linux graphics stack
foundation based on KMS, TTM/GEM, advanced hardware accelerated video
decoding of most formats (by using OpenCL plus FFMpeg/LibAV, for
example), Gallium3D and full OpenGL 4.x support could make me very
happy as user and future developer...
Sadly, stuff like S3TC and such makes me very sad. I hope it gets
resolved sucessfully, patents are the nightmare of the technology...
Regards.
On Mon, Mar 21, 2011 at 6:00 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Sat, 19 Mar 2011 12:20:24 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
>> As noone responded to my question in
>> http://www.spinics.net/lists/dri-devel/msg08851.html
>> (yes, it was a bit hidden in a thread), I'm asking it here again (and
>> also on the Wayland
>> mailing list).
>>
>> Basically I'm still puzzled about this KMS thing. If the name "Kernel
>> Mode Setting"
>> covers it, then how does it compare to plain fbdev? Just additional frame buffer
>> memory management?
>> Also, some people may remember we did have kernel messages (e.g. oops, panic)
>> on graphical consoles with fbdev, until people started not liking them
>> showing up
>> on their X desktops...
>
> We support panic these days as well, but people still don't like seeing
> them. :)
>
> The DRM KMS APIs provide everything fbdev provides, plus memory
> management, a way to expose acceleration (via GEM or TTM), and a way to
> manage multiple outputs reasonably.
>
>> Furthermore, everybody states that "future desktop" (that's
>> http://wayland.freedesktop.org/)
>> will require KMS drivers.
>> How do/will we handle this on dumb frame buffers? It's not like we can't do
>> "advanced" things like compositing using the CPU. Transparency may stretch
>> it a bit on lower end CPUs, but you don't always need that.
>
> There's nothing in DRM that precludes doing simple fbdev-like drivers
> as well, though for many embedded uses I wouldn't expect it to provide
> a whole lot of benefit.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: Tomi Valkeinen @ 2011-03-21 18:17 UTC (permalink / raw)
To: John S; +Cc: Paul Mundt, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org
In-Reply-To: <AANLkTi=_zTJ0XeVC=MxqN6CzFqaXW0H6TbHEao3OihRb@mail.gmail.com>
On Mon, 2011-03-21 at 12:43 -0500, John S wrote:
> On Mon, Mar 21, 2011 at 3:21 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Hi Paul,
> >
> > Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a
> > bit of them, and many changes also in arch/arm/mach-omap2, which
> > unfortunately couldn't go through Tony's linux-omap tree due to
> > dependencies on DSS driver code.
<snip>
> some of these patches had problems related to HDMI:
> http://www.spinics.net/lists/linux-omap/msg48740.html
> Was this issue resolved?
No. We haven't been able to reproduce, and I haven't heard of anyone
else reporting problems. So I believe the patches are good enough for
rc1.
Tomi
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 18:00 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux Fbdev development list, dri-devel, wayland-devel
In-Reply-To: <AANLkTimJWpebAskcjA+qQUDWXjiH6aHta4fri9z6OxRN@mail.gmail.com>
On Sat, 19 Mar 2011 12:20:24 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> As noone responded to my question in
> http://www.spinics.net/lists/dri-devel/msg08851.html
> (yes, it was a bit hidden in a thread), I'm asking it here again (and
> also on the Wayland
> mailing list).
>
> Basically I'm still puzzled about this KMS thing. If the name "Kernel
> Mode Setting"
> covers it, then how does it compare to plain fbdev? Just additional frame buffer
> memory management?
> Also, some people may remember we did have kernel messages (e.g. oops, panic)
> on graphical consoles with fbdev, until people started not liking them
> showing up
> on their X desktops...
We support panic these days as well, but people still don't like seeing
them. :)
The DRM KMS APIs provide everything fbdev provides, plus memory
management, a way to expose acceleration (via GEM or TTM), and a way to
manage multiple outputs reasonably.
> Furthermore, everybody states that "future desktop" (that's
> http://wayland.freedesktop.org/)
> will require KMS drivers.
> How do/will we handle this on dumb frame buffers? It's not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.
There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though for many embedded uses I wouldn't expect it to provide
a whole lot of benefit.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: John S @ 2011-03-21 17:55 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Paul Mundt, linux-fbdev, linux-omap
In-Reply-To: <1300701083.2891.77.camel@deskari>
On Mon, Mar 21, 2011 at 3:21 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Paul,
>
> Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a
> bit of them, and many changes also in arch/arm/mach-omap2, which
> unfortunately couldn't go through Tony's linux-omap tree due to
> dependencies on DSS driver code.
>
> The patches are mostly aiming to get OMAP4 display support up and
> running and both HDMI and DVI outputs should now work on Blaze and Panda
> boards.
>
> One problem I noticed just now, the committer names seem a bit messed
> up. For example, Archit Taneja has three different style names there. Do
> you think I should rebase and fix them? Not a big job, but it'll mean,
> well, rebasing.
>
> There's a minor conflict in Overo's board file. I have pushed
> "for-paul-merged" branch to gitorious, which contains a merge with
> Linus' tree. I'm not sure that is the best way to show how to fix the
> conflict, but hopefully it'll give the idea.
>
> Tomi
>
>
> The following changes since commit a44f99c7efdb88fa41128065c9a9445c19894e34:
>
> Merge branch 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-03-20 18:14:55 -0700)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-omap-dss2/linux.git for-paul
>
> Archit Taneja (9):
> OMAP2PLUS: DSS2: Generalize naming of PRCM related clock enums in DSS driver
> OMAP2PLUS: DSS2: Generalize external clock names in struct dss of dss.c
> OMAP2PLUS: DSS2: FEATURES: DISPC overlay code cleanup
> OMAP2PLUS: DSS2: FEATURES: Function to Provide the max fck supported
> OMAP2PLUS: DSS2: Make members of dss_clk_source generic
> OMAP2PLUS: DSS2: Use dss features to get clock source names of current OMAP
> OMAP2PLUS: DSS2: DSI: Generalize DSI PLL Clock Naming
> OMAP: DSS2: Functions to request/release DSI VCs
> OMAP: DSS2: Use request / release calls in Taal for DSI Virtual Channels.
>
> Jani Nikula (1):
> OMAP: DSS2: Fix def_disp module param description
>
> Janorkar, Mayuresh (2):
> OMAPFB: Adding a check for timings in set_def_mode
> OMAP: OMAPFB: Adding help for FB_OMAP_LCD_VGA option
>
> Jarkko Nikula (1):
> omapfb: Fix linker error in drivers/video/omap/lcd_2430sdp.c
>
> K, Mythri P (1):
> OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 PANDA
>
> Mayuresh Janorkar (2):
> OMAP2PLUS: DSS2: Add OMAP4 Kconfig support
> OMAP4: DSS2: Add hwmod device names for OMAP4.
>
> Murthy, Raghuveer (5):
> OMAP: DSS2: Adding dss_features for independent core clk divider
> OMAP: DSS2: Renaming register macro DISPC_DIVISOR(ch)
> OMAP4: DSS2: Using dss_features to set independent core clock divider
> OMAP: DSS2: Implement OMAP4 DSS fclk support
> OMAP4: PandaBoard: Adding DVI support
>
> Mythri P K (9):
> OMAP4: DSS2: Add display type HDMI to DSS2
> OMAP4: DSS2: HDMI: Select between HDMI VENC clock source.
> OMAP4: DSS2: HDMI: Dispc gamma enable set/reset function for TV.
> OMAP4: DSS2: HDMI: HDMI driver header file addition
> OMAP4: DSS2: HDMI: HDMI driver addition in the DSS
> OMAP4: DSS2: HDMI: HDMI panel driver addition in the DSS
> OMAP4: DSS2: HDMI: Add makefile and kconfig changes to enable HDMI in OMAP4
> OMAP4: DSS: HDMI: Call to HDMI module init to register driver.
> OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 SDP
>
> Samreen (1):
> OMAP2/3/4: DSS2: Enable Display SubSystem as modules
>
> Semwal, Sumit (2):
> OMAP2PLUS:DSS2: add opt_clock_available in pdata
> OMAP2PLUS:DSS2: Use opt_clock_available from pdata
>
> Senthilvadivu Guruswamy (9):
> OMAP2,3: DSS2: Build omap_device for each DSS HWIP
> OMAP2, 3: DSS2: DSS: create platform_driver, move init, exit to driver
> OMAP2, 3: DSS2: Move clocks from core driver to dss driver
> OMAP2, 3: DSS2: RFBI: create platform_driver, move init, exit to driver
> OMAP2, 3: DSS2: DISPC: create platform_driver, move init, exit to driver
> OMAP2, 3: DSS2: VENC: create platform_driver, move init, exit to driver
> OMAP2, 3: DSS2: DSI: create platform_driver, move init, exit to driver
> OMAP2,3: DSS2: Use platform device to get baseaddr
> OMAP2,3: DSS2: Get DSS IRQ from platform device
>
> Steve Sakoman (5):
> OMAP: DSS2: Add support for LG Philips LB035Q02 panel
> OMAP: DSS2: Add DSS2 support for Overo
> omap: overo: Add regulator for ads7846
> OMAP: Add gpio-leds support for Overo
> OMAP: Add gpio-keys support for Overo
>
> Sumit Semwal (4):
> OMAP2, 3: DSS2: remove forced clk-disable from omap_dss_remove
> OMAP2,3: DSS2: replace printk with dev_dbg in init
> OMAP2PLUS: clocks: Align DSS clock names and roles
> OMAP4: DSS2: clocks: Add ick as dummy clock
>
> Taneja, Archit (5):
> OMAP2PLUS: DSS2: Cleanup clock source related code
> OMAP4: DSS2: Clock source changes for OMAP4
> OMAP2PLUS: DSS2: FEATURES: Fix usage of dss_reg_field and dss_clk_source_name
> OMAP: DSS2: FEATURES: Functions to return min and max values of parameters
> OMAP: DSS2: FEATURES: DSI PLL parameter cleanup
>
> Tomi Valkeinen (25):
> OMAP: 3430SDP: Remove unused vdda_dac supply
> OMAP: DSS2: Delay regulator_get() calls
> OMAP: DSS2: Support for Samsung LTE430WQ-F0C
> MAINTAINERS: Update OMAP DSS maintainer
> OMAP: DSS2: Clean up a switch-case
> OMAP: DSS2: FEATURES: Remove SDI from 3630 displays
> OMAP: DSS2: FEATURES: Remove DSI & SDI from OMAP2
> OMAP: DSS2: Check for SDI HW before accessing SDI registers
> OMAP: DSS2: Remove unused list
> OMAP: DSS2: DSI: remove unused function
> OMAP: DSS2: Remove FB_OMAP_BOOTLOADER_INIT support
> OMAP: DSS2: Remove pdev argument from dpi_init
> OMAP: DSS2: Move DPI & SDI init into DSS plat driver
> OMAP: DSS2: Remove unneeded cpu_is_xxx checks
> HACK: OMAP: DSS2: Fix OMAP2_DSS_USE_DSI_PLL
> HACK: OMAP: DSS2: add delay after enabling clocks
> OMAP: DSS2: fix omap_dispc_register_isr() fail path
> HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to prevent crash
> OMAP: DSS2: DSI: Restructure IRQ handler
> OMAP: DSS2: DSI: Add ISR support
> OMAP: DSS2: DSI: use ISR in send_bta_sync
> OMAP: DSS2: DSI: use ISR for BTA in framedone
> OMAP: DSS2: DSI: catch DSI errors in send_bta_sync
> OMAP: DSS2: DSI: fix IRQ debug prints
> OMAP: DSS2: Clean up for dpll4_m4_ck handling
>
> archit taneja (1):
> OMAP: DSS2: Have separate irq handlers for DISPC and DSI
>
some of these patches had problems related to HDMI:
http://www.spinics.net/lists/linux-omap/msg48740.html
Was this issue resolved?
> MAINTAINERS | 4 +-
> arch/arm/configs/omap2plus_defconfig | 11 +
> arch/arm/mach-omap2/board-3430sdp.c | 6 +-
> arch/arm/mach-omap2/board-4430sdp.c | 75 ++
> arch/arm/mach-omap2/board-cm-t35.c | 2 +-
> arch/arm/mach-omap2/board-devkit8000.c | 12 +-
> arch/arm/mach-omap2/board-igep0020.c | 10 +-
> arch/arm/mach-omap2/board-omap3beagle.c | 12 +-
> arch/arm/mach-omap2/board-omap3evm.c | 12 +-
> arch/arm/mach-omap2/board-omap3pandora.c | 3 +-
> arch/arm/mach-omap2/board-omap3stalker.c | 12 +-
> arch/arm/mach-omap2/board-omap4panda.c | 203 +++-
> arch/arm/mach-omap2/board-overo.c | 357 +++++-
> arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
> arch/arm/mach-omap2/board-zoom-peripherals.c | 12 +-
> arch/arm/mach-omap2/clock2420_data.c | 8 +-
> arch/arm/mach-omap2/clock2430_data.c | 8 +-
> arch/arm/mach-omap2/clock3xxx_data.c | 14 +-
> arch/arm/mach-omap2/clock44xx_data.c | 15 +-
> arch/arm/mach-omap2/display.c | 80 ++
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 13 +-
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 12 +-
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 23 +-
> arch/arm/plat-omap/include/plat/display.h | 15 +-
> drivers/video/omap/Kconfig | 7 +-
> drivers/video/omap2/displays/Kconfig | 6 +
> drivers/video/omap2/displays/Makefile | 1 +
> drivers/video/omap2/displays/panel-generic-dpi.c | 25 +
> .../omap2/displays/panel-lgphilips-lb035q02.c | 279 ++++
> drivers/video/omap2/displays/panel-taal.c | 123 +-
> drivers/video/omap2/dss/Kconfig | 14 +-
> drivers/video/omap2/dss/Makefile | 2 +
> drivers/video/omap2/dss/core.c | 480 +-------
> drivers/video/omap2/dss/dispc.c | 335 ++++--
> drivers/video/omap2/dss/display.c | 35 +-
> drivers/video/omap2/dss/dpi.c | 45 +-
> drivers/video/omap2/dss/dsi.c | 967 +++++++++++----
> drivers/video/omap2/dss/dss.c | 763 +++++++++--
> drivers/video/omap2/dss/dss.h | 153 ++-
> drivers/video/omap2/dss/dss_features.c | 163 ++-
> drivers/video/omap2/dss/dss_features.h | 27 +
> drivers/video/omap2/dss/hdmi.c | 1332 ++++++++++++++++++++
> drivers/video/omap2/dss/hdmi.h | 415 ++++++
> drivers/video/omap2/dss/hdmi_omap4_panel.c | 222 ++++
> drivers/video/omap2/dss/manager.c | 13 +-
> drivers/video/omap2/dss/overlay.c | 10 +-
> drivers/video/omap2/dss/rfbi.c | 128 ++-
> drivers/video/omap2/dss/sdi.c | 62 +-
> drivers/video/omap2/dss/venc.c | 128 ++-
> drivers/video/omap2/omapfb/Kconfig | 6 +-
> drivers/video/omap2/omapfb/omapfb-main.c | 23 +-
> 51 files changed, 5323 insertions(+), 1362 deletions(-)
> create mode 100644 drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
> create mode 100644 drivers/video/omap2/dss/hdmi.c
> create mode 100644 drivers/video/omap2/dss/hdmi.h
> create mode 100644 drivers/video/omap2/dss/hdmi_omap4_panel.c
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v3] matroxfb: remove incorrect Matrox G200eV support
From: Gary Hade @ 2011-03-21 17:28 UTC (permalink / raw)
To: linux-fbdev, linux-kernel, Linus Torvalds
Cc: Darrick J. Wong, Krzysztof Helt, Petr Vandrovec, Andrew Morton,
Christian Toutant, Gary Hade
From: Gary Hade <garyhade@us.ibm.com>
Remove incorrect Matrox G200eV support that was previously
added by commit e3a1938805d2e81b27d3d348788644f3bad004f2
A serious issue with the incorrect G200eV support that reproduces
on the Matrox G200eV equipped IBM x3650 M2 is the total lack of
text (login banner, login prompt, etc) on the console when X is
not running and total lack of text on all of the virtual consoles
after X is started.
Any concerns that the incorrect code (upstream since October 2008)
has been successfully used on non-IBM G200eV equipped system(s)
appear to be unwarranted. In addition to the serious/non-intermittent
nature of issues that have been spotted on IBM systems, complete
removal of the incorrect code is clearly supported by the following
Matrox (Yannick Heneault) provided input.
"It impossible that this patch should have work on a system.
The patch only declare the G200eV as a regular G200 which is
not case. Many registers are different, including at least the
PLL programming sequence. If the G200eV is programmed like a
regular G200, it will not display anything."
v1 - Initial patch that removed the incorrect code for _all_
G200eV equipped systems.
v2 - Darrick Wong provided patch that blacklisted the incorrect
code on G200eV equipped IBM systems leaving it enabled on
all G200eV equipped non-IBM systems.
v3 - Same code changes included with v1 plus additional
justification for complete removal of the incorrect code.
Signed-off-by: Gary Hade <garyhade@us.ibm.com>
Cc: Darrick J. Wong <djwong@us.ibm.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yannick Heneault <yannick_heneault@matrox.com>
Cc: Christian Toutant <ctoutant@matrox.com>
---
drivers/video/matrox/matroxfb_base.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_base.c b/drivers/video/matrox/matroxfb_base.c
index a082deb..a74439a 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -1461,13 +1461,6 @@ static struct board {
MGA_G100,
&vbG100,
"MGA-G100 (AGP)"},
- {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200EV_PCI, 0xFF,
- 0, 0,
- DEVF_G200,
- 230000,
- MGA_G200,
- &vbG200,
- "MGA-G200eV (PCI)"},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_PCI, 0xFF,
0, 0,
DEVF_G200,
@@ -2119,8 +2112,6 @@ static struct pci_device_id matroxfb_devices[] = {
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G100_AGP,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200EV_PCI,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_PCI,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_AGP,
^ permalink raw reply related
* Re: [PATCH 08/20] video: msm: Refactor mdp_regs
From: Brian Swetland @ 2011-03-21 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D8789AA.8050803@codeaurora.org>
On Mon, Mar 21, 2011 at 10:23 AM, Bryan Huntsman <bryanh@codeaurora.org> wrote:
> On 03/20/2011 10:17 PM, Janorkar, Mayuresh wrote:
>>> diff --git a/drivers/video/msm/mdp_ppp.h b/drivers/video/msm/mdp_ppp.h
>>> new file mode 100644
>>> index 0000000..ef3b125
>>> --- /dev/null
>>> +++ b/drivers/video/msm/mdp_ppp.h
>>> @@ -0,0 +1,50 @@
>>> +/* drivers/video/msm/mdp_ppp.h
>>> + *
>>> + * Copyright (C) 2009 Google Incorporated
>>
>> If you want correct copyright info (to 2009-2011) here.
>
> Carl is submitting a change made by Google in 2009. I believe having
> 2009 as the only copyright year is correct. Carl/Brian, please correct
> me here if the date of the change was more than 2009. Thanks.
Google is fine with leaving our copyright line as originally authored.
No need to modify it.
Thanks,
Brian
^ permalink raw reply
* Re: [PATCH 08/20] video: msm: Refactor mdp_regs
From: Bryan Huntsman @ 2011-03-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB033D22EB6E@dbde02.ent.ti.com>
On 03/20/2011 10:17 PM, Janorkar, Mayuresh wrote:
...
>> diff --git a/drivers/video/msm/mdp_ppp.h b/drivers/video/msm/mdp_ppp.h
>> new file mode 100644
>> index 0000000..ef3b125
>> --- /dev/null
>> +++ b/drivers/video/msm/mdp_ppp.h
>> @@ -0,0 +1,50 @@
>> +/* drivers/video/msm/mdp_ppp.h
>> + *
>> + * Copyright (C) 2009 Google Incorporated
>
> If you want correct copyright info (to 2009-2011) here.
Carl is submitting a change made by Google in 2009. I believe having
2009 as the only copyright year is correct. Carl/Brian, please correct
me here if the date of the change was more than 2009. Thanks.
- Bryan
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 07/20] video: msm: Allow users to request a larger x
From: Russell King - ARM Linux @ 2011-03-21 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB033D22EAE7@dbde02.ent.ti.com>
On Mon, Mar 21, 2011 at 10:10:09AM +0530, Janorkar, Mayuresh wrote:
> > + fix->line_length = var->xres * var->bits_per_pixel / 8;
> Why to divide by 8? Atleast use >>3, bitwise operations that would take
> less cpu cycles)
> As I stated earlier define a new macro for var also.
Modern compilers know about such things. >> 3 vs / 8 (probably) makes no
difference to the generated code with the toolchains we use.
^ permalink raw reply
* Re: Xrandr and udlfb
From: Alexander Todorov @ 2011-03-21 15:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <4D84BB47.2030100@otb.bg>
На 19.03.2011 16:18, Alexander Todorov написа:
> Hello folks,
> does udlfb support Xrandr? What I need is to be able to rotate the display which
> for some reason I can't.
>
Hello,
I've found this post about udlfb rotation:
http://plugable.com/2010/01/02/displaylink-linux-rotation/
As it seems there are some drawbacks.
Can anyone give information about current status of rotation support for udlfb
and which is the preferred way to implement it?
Thanks,
Alexander.
^ permalink raw reply
* [patch v2] fbdev: sh_mobile_lcdc: checking NULL instead of IS_ERR()
From: Dan Carpenter @ 2011-03-21 15:03 UTC (permalink / raw)
To: linux-fbdev
backlight_device_register() returns an ERR_PTR. It doesn't return NULL.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
V2: print the error code as well.
This patch is againts linux-next, in case you missed that earlier.
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index bf2629f..757665b 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1088,8 +1088,9 @@ static struct backlight_device *sh_mobile_lcdc_bl_probe(struct device *parent,
bl = backlight_device_register(ch->cfg.bl_info.name, parent, ch,
&sh_mobile_lcdc_bl_ops, NULL);
- if (!bl) {
- dev_err(parent, "unable to register backlight device\n");
+ if (IS_ERR(bl)) {
+ dev_err(parent, "unable to register backlight device: %ld\n",
+ PTR_ERR(bl));
return NULL;
}
^ permalink raw reply related
* Re: [PATCH 18/20] video: msm: Prevent DMA lockups when switching
From: Sergei Shtylyov @ 2011-03-21 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485585-27640-1-git-send-email-carlv@codeaurora.org>
Hello.
Carl Vanderlip wrote:
> Forces the lcdc off and waits a frame vsync period to prevent the MDP DMA
> engine crashing if the DMA bit depth is changed. A sleep cannot be used
> because lcdc_dma_start is called in irq context.
Maybe I'm blind again but I don't see any waiting...
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> drivers/video/msm/mdp.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index b3f334ad..49d956a 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -564,6 +564,13 @@ void mdp_hw_init(struct mdp_info *mdp)
> mdp_writel(mdp, 1, 0x60);
> mdp_writel(mdp, 1, MDP_EBI2_PORTMAP_MODE);
>
> + /* disable lcdc */
> + mdp_writel(mdp, 0, MDP_LCDC_CTL);
> + /* enable auto clock gating for all blocks by default */
> + mdp_writel(mdp, 0xffffffff, MDP_CGC_EN);
> + /* reset color/gamma correct parms */
> + mdp_writel(mdp, 0, MDP_DMA_P_COLOR_CORRECT_CONFIG);
> +
> mdp_writel(mdp, 0, MDP_CMD_DEBUG_ACCESS_BASE + 0x01f8);
> mdp_writel(mdp, 0, MDP_CMD_DEBUG_ACCESS_BASE + 0x01fc);
> mdp_writel(mdp, 1, 0x60);
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 17/20] video: msm: Prevent framebuffer glitch during initialization
From: Sergei Shtylyov @ 2011-03-21 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485574-27600-1-git-send-email-carlv@codeaurora.org>
Hello.
Carl Vanderlip wrote:
> Holds a reference to the mdp_clk until lateinit, and moves the frambuffer
> initialization to device_init.
Maybe I'm just blind but I don't see where the patch does the latter...
> The framebuffer lcdc driver will grab a
> reference to mdp_clk, which prevents the clock from being disabled by
> clock_late_init.
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> drivers/video/msm/mdp.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 0bb19fa..b3f334ad 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -38,6 +38,7 @@ struct class *mdp_class;
>
> static DECLARE_WAIT_QUEUE_HEAD(mdp_ppp_waitqueue);
> static unsigned int mdp_irq_mask;
> +struct clk *mdp_clk_to_disable_later;
Why not just 'mdp_clk'? :-)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 15/20] video: msm: convert printk to pr_*
From: Sergei Shtylyov @ 2011-03-21 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485552-27519-1-git-send-email-carlv@codeaurora.org>
Hello.
Carl Vanderlip wrote:
> Reword debugging messages to use pr_err and pr_warning
> Authors:
> Dima Zavin <dima@android.com>
> Rebecca Schultz Zavin <rebecca@android.com>
> Colin Cross <ccross@android.com>
> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
> ---
> drivers/video/msm/mdp.c | 11 ++++-------
> 1 files changed, 4 insertions(+), 7 deletions(-)
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 8184ca9..b03204d 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -42,16 +42,13 @@ DEFINE_MUTEX(mdp_mutex);
>
> static int locked_enable_mdp_irq(struct mdp_info *mdp, uint32_t mask)
> {
> - int ret = 0;
> -
> BUG_ON(!mask);
>
> /* if the mask bits are already set return an error, this interrupt
> * is already enabled */
> if (mdp_irq_mask & mask) {
> - printk(KERN_ERR "mdp irq already on already on %x %x\n",
> - mdp_irq_mask, mask);
> - ret = -1;
> + pr_err("mdp irq already on %x %x\n", mdp_irq_mask, mask);
> + return -1;
This change to *return* is not described.
WBR, Sergei
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox