linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[James S. <jsi...@in...>]

> > Searching the TTM code I couldn't find the handle code so easily. I see
> > that the vmwgfx driver provides a example of using ttm.
> 
> So handles are purely a userspace interface, in-kernel we don't use handles
> for buffer management, the vmwgfx TTM interface has vmw_user_surface_lookup_handle
> to do the bo lookups.

Yeap, some how userland has to tell which buffer is which. I also noticed 
their is a ttm_base_object_lookup which does the same thing :-) 

Re: [Linux-fbdev-devel] [PATCH] fix Kconfig breakage in drivers/video

[David M. <da...@da...>]

From: Krzysztof Helt <krz...@po...>
Date: Sun, 14 Mar 2010 22:53:29 +0100

> From: Krzysztof Helt <krz...@wp...>
> 
> There are two new options inside the CONFIG_FB section which do not
> depend on the CONFIG_FB. This break Kconfig menu layout.
> 
> Fix it and reduce few conditions for sparc frame buffers
> as the FB_SBUS == ((FB = y) && SPARC).
> 
> Signed-off-by: Krzysztof Helt <krz...@wp...>

Acked-by: David S. Miller <da...@da...>

Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[James S. <jsi...@in...>]

> >> Can't it print the oops on whatever is currently displayed?
> >>
> >> It need not be a dedicated buffer as long as there is always some buffer.
> >>
> >> But perhaps this is more complex than that.
> >
> >        Yes it is very complex. Reading the code and drm specs you come to
> > realize buffer handling is done with GEM, TTM, or for older drivers drm_maps.
> > Drivers often handle a combine of those, meaning no real wrapper from one
> > api to another :-( From the code it appears GEM is the main userland interface
> > when using KMS. Some how TTM is also usable from userland but I never found a
> > clear example of how that is done. So to the average userland app writer it is
> > a mystery. As for hardware that has a static front buffer I can see how to
> > use drm_maps or TTM but I don't see a easy way to map it to the GEM api.
> > Also their exist ioctl for gem but it appears no one actually uses them
> > but instead write their own :-( So you can see the confusion here.
> 
> Userspace buffer management interfaces are pre-driver, the only requirement
> if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS drivers
> don't exist for the purposes of fb interaction, so drm_maps are ignorable from
> that pov.

 
> >        Outside of what I described above the drm_framebuffer handling is
> > a mess. From what I can see with the code you can only create a
> > drm_framebuffer with the GEM api. With this case the two most important
> > functions to provide are
> 
> This isn't correct. You get a drm_file and a handle, the driver then uses
> these to do whatever it wants to do. This means lookup a GEM object or
> whatever but there is no reliance on GEM or any other memory manager
> outside the driver. Again a handle a file priv are in no way GEM specific.

Searching the TTM code I couldn't find the handle code so easily. I see 
that the vmwgfx driver provides a example of using ttm.
 
> >        This gets me to point of where to go from here. We have two choices.
> > The first being we could just make the drm_framebuffer code totally gem
> > dependent thus we could cleanup the drivers code up by moving gem code
> > there. The second option is to make the drm_framebuffer code agnostic to the gem
> > layer. So I have been pondering on how to make the second option work.
> > There is one thing that all these layers do share in common. That is they
> > have some sort of drm_hash with a object lookup. Still pondering how that
> > would be done.
> 
> I'm not sure either of these makes sense, can you clearly state the
> goal and maybe we can work out what you need.

Sorry I should of stated what I was planing to do. I like to see drmfb 
have the ablitiy to change the resolution via fbset. To do that we need to 
be able to create and destory the framebuffer memory if the memory doesn't 
fit the size of the new resolution. Plus it gives us the bonus of being 
able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem 
is that the functions like fb_create are tied to a handle which is not 
present for the internal framebuffer used by fbdev. Sorry for the junk 
above. It just took me awhile to figure out the code. Their is steep 
learning curve. I have patches that should address this coming soon.

Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[James S. <jsi...@in...>]

On Thu, 11 Mar 2010, Michal Suchanek wrote:

> On 11 March 2010 16:17, James Simmons <jsi...@in...> wrote:
> >
> >> >> It would be nice to find a way to reclaim the console memory for X,
> >> >> but I'm not sure that can be done and still provide a good way to
> >> >> provide oops support.
> >> >
> >> > What do you think the average user will care about more?
> >> >
> >> >      * Seeing kernel oops/panic output about once in a lifetime.
> >> >      * Being able to start/use X in the first place and enabling it to
> >> >        use all of VRAM.
> >> >
> >> > Personally, I've never even seen any kernel oops/panic output despite
> >> > numerous opportunities for that in the couple of months I've been using
> >> > KMS. But I have spent considerable time and effort trying to get rid of
> >> > the pinned fbcon BO. If the oops/panic output is the only thing
> >> > preventing that, maybe that should only be enabled via some module
> >> > option for developers.
> >>
> >> I'm all for it!
> >
> > I'm looking into the details for this. It will require some changes to
> > internal apis to make it to work.
> >
> 
> Can't it print the oops on whatever is currently displayed?
> 
> It need not be a dedicated buffer as long as there is always some buffer.
> 
> But perhaps this is more complex than that.

	Yes it is very complex. Reading the code and drm specs you come to
realize buffer handling is done with GEM, TTM, or for older drivers drm_maps.
Drivers often handle a combine of those, meaning no real wrapper from one 
api to another :-( From the code it appears GEM is the main userland interface
when using KMS. Some how TTM is also usable from userland but I never found a
clear example of how that is done. So to the average userland app writer it is
a mystery. As for hardware that has a static front buffer I can see how to 
use drm_maps or TTM but I don't see a easy way to map it to the GEM api. 
Also their exist ioctl for gem but it appears no one actually uses them 
but instead write their own :-( So you can see the confusion here. 
	Outside of what I described above the drm_framebuffer handling is 
a mess. From what I can see with the code you can only create a 
drm_framebuffer with the GEM api. With this case the two most important 
functions to provide are

dev->mode_config.funcs->fb_create(dev, file_priv, r)

and

fb->funcs->create_handle(fb, file_priv, &r->handle);

As you can see if the functions they depend on a handle and a drm_file. To 
make it possible to create a framebuffer internally using a common code we 
would remove those requirements. 
	This gets me to point of where to go from here. We have two choices.
The first being we could just make the drm_framebuffer code totally gem 
dependent thus we could cleanup the drivers code up by moving gem code 
there. The second option is to make the drm_framebuffer code agnostic to the gem 
layer. So I have been pondering on how to make the second option work. 
There is one thing that all these layers do share in common. That is they 
have some sort of drm_hash with a object lookup. Still pondering how that 
would be done.

Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[James S. <jsi...@in...>]

> >> It would be nice to find a way to reclaim the console memory for X,
> >> but I'm not sure that can be done and still provide a good way to
> >> provide oops support.
> >
> > What do you think the average user will care about more?
> >
> >      * Seeing kernel oops/panic output about once in a lifetime.
> >      * Being able to start/use X in the first place and enabling it to
> >        use all of VRAM.
> >
> > Personally, I've never even seen any kernel oops/panic output despite
> > numerous opportunities for that in the couple of months I've been using
> > KMS. But I have spent considerable time and effort trying to get rid of
> > the pinned fbcon BO. If the oops/panic output is the only thing
> > preventing that, maybe that should only be enabled via some module
> > option for developers.
> 
> I'm all for it!

I'm looking into the details for this. It will require some changes to 
internal apis to make it to work.

Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[James S. <jsi...@in...>]

> > Yuck. See my other post about what fbdev really means in its historical
> > context. The struct fb_info really maps better to drm_crtc than to
> > drm_framebuffer. In fact take the case of the matrox fbdev driver. It
> > creates two framebuffer devices even tho it used one static framebuffer.
> > What the driver does is splits the framebuffer in two and assigned each
> > part to a CRTC.
> >
> 
> So you get the layering naturally. On fbset - fbev layer you can
> choose from the resolutions available in the current output setup, in
> kmset or whatever - drm layer you can set up the outputs, merge
> multiple outputs into single cloned fbdev or separate them, ..
> 
> It's obviously nice if you can set the resolution on all of fbcons,
> fbdev and drm layers but getting it work on at least one layer with
> proper propagation up and down also works. BTW I don't know any
> application which sets linux console (or xterm for that matter)
> resolution through the terminal API.

I agree. The mode setting should be done in one layer. Its a matter of 
doing the proper emulation of the fbdev layer.

Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[James S. <jsi...@in...>]

> >> Yuck. See my other post about what fbdev really means in its historical
> >> context. The struct fb_info really maps better to drm_crtc than to
> >> drm_framebuffer. In fact take the case of the matrox fbdev driver. It
> >> creates two framebuffer devices even tho it used one static framebuffer.
> >> What the driver does is splits the framebuffer in two and assigned each
> >> part to a CRTC.
> >
> > The only problem with that is that it eats a lot of memory for the
> > console which limits X when it starts. On cards with limited vram ,
> > you might not have enough memory left for any meaningful acceleration
> > when X starts.
> 
> It would be nice to find a way to reclaim the console memory for X,
> but I'm not sure that can be done and still provide a good way to
> provide oops support.

	Ah, the power of flags. We had the same issue with user requesting a mode
change or fbcon asking for a different mode. We handled it with the flag 
FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon you will
have to deal also with the ability to change the resolution with tools like stty.
I can easily see how to do this plus give you more memory like you want :-) 
	For the oops are you talking about printing oops to the screen 
while X is running ? Otherwise if you experience a oops and go back to 
console mode you should be able to view it. The console text buffer is 
independent of the graphics card memory system.

Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[James S. <jsi...@in...>]

> >> At the moment the problem with fbset is what to do with it in the
> >> dual head case. Currently we create an fb console that is lowest
> >> common size of the two heads and set native modes on both,
> >
> > Does that mean that fbset is supposed to work (set resolution) on drmfb?
> 
> No we've never hooked it up but it could be made work.

I had it to the point of almost working. I plan on working on getting it 
working again.
 
> > Schemes which would make a multihead setup look like a single screen
> > get complicated quite easily. Perhaps an option to turn off some
> > outputs so that the native resolution of one output is used (instead
> > of clone) would work.
> >
> 
> I've only really got two answer for this:
> 
> (a) hook up another /dev/dri/card_fb device and use the current KMS
> ioctls to control the framebuffer, have the drm callback into fbdev/fbcon
> to mention resizes etc. Or add one or two info gathering ioctls and
> allow use of the /dev/dri/control device to control stuff.
> 
> (b) add a lot of ioctls to KMS fbdev device, which implement some sort
> of sane multi-output settings.
> 
> Now the second sounds like a lot of work if not the correct solution,
> you basically needs a way to pretty much expose what the KMS ioctls
> expose on the fb device, and then upgrade fbset to make sense of it all.

Yuck. See my other post about what fbdev really means in its historical 
context. The struct fb_info really maps better to drm_crtc than to 
drm_framebuffer. In fact take the case of the matrox fbdev driver. It  
creates two framebuffer devices even tho it used one static framebuffer.
What the driver does is splits the framebuffer in two and assigned each 
part to a CRTC.

Re: [Linux-fbdev-devel] [PATCH 01/29] move acornfb's probe function to .devinit.text

[Uwe Kleine-K. <u.k...@pe...>]

On Sun, Jan 24, 2010 at 01:25:58 +0200, Alexey Dobriyan wrote:
> gods, can you just send one patch for all framebuffer drivers?
Well, I thought one logical change per changeset is the favourite way to
go.  And as the people Cc:d are different I think most people prefer it
this way.

On Sun, Jan 24, 2010 at 01:28:13AM +0200, Alexey Dobriyan wrote:
> On Sat, Jan 23, 2010 at 09:35:09PM +0100, Uwe Kleine-König wrote:
> > -static int __init acornfb_probe(struct platform_device *dev)
> > +static int __devinit acornfb_probe(struct platform_device *dev)
> 
> Even more, if this function is marked __devinit, some other functions
> can very well be marked __devinit, can you do this?
Probably, the big pro after my patch is that modpost can warn about
this.  Actually this applies to all (initially) over 50 patches in this
series.  If you take my patches, squash them together and fix all called
functions, I'm happy, too.

If you don't I might come back to this and do it myself.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Re: [Linux-fbdev-devel] [PATCH 01/29] move acornfb's probe function to .devinit.text

[Alexey D. <ado...@gm...>]

On Sat, Jan 23, 2010 at 09:35:09PM +0100, Uwe Kleine-König wrote:
> -static int __init acornfb_probe(struct platform_device *dev)
> +static int __devinit acornfb_probe(struct platform_device *dev)

Even more, if this function is marked __devinit, some other functions
can very well be marked __devinit, can you do this?

Re: [Linux-fbdev-devel] [PATCH 01/29] move acornfb's probe function to .devinit.text

[Alexey D. <ado...@gm...>]

On Sat, Jan 23, 2010 at 09:35:09PM +0100, Uwe Kleine-König wrote:
>  drivers/video/acornfb.c |    2 +-

gods, can you just send one patch for all framebuffer drivers?

[Linux-fbdev-devel] [PATCH 01/29] move acornfb's probe function to .devinit.text

[Uwe Kleine-K. <u.k...@pe...>]

A pointer to acornfb_probe is passed to the core via
platform_driver_register and so the function must not disappear when the
.init sections are discarded.  Otherwise (if also having HOTPLUG=y)
unbinding and binding a device to the driver via sysfs will result in an
oops as does a device being registered late.

An alternative to this patch is using platform_driver_probe instead of
platform_driver_register plus removing the pointer to the probe function
from the struct platform_driver.

Signed-off-by: Uwe Kleine-König <u.k...@pe...>
Cc: Christoph Hellwig <hc...@ls...>
Cc: Antonino Daplas <ad...@po...>
Cc: lin...@li...
Cc: Andrew Morton <ak...@li...>
---
 drivers/video/acornfb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/acornfb.c b/drivers/video/acornfb.c
index 0bcc59e..43d7d50 100644
--- a/drivers/video/acornfb.c
+++ b/drivers/video/acornfb.c
@@ -1221,7 +1221,7 @@ free_unused_pages(unsigned int virtual_start, unsigned int virtual_end)
 	printk("acornfb: freed %dK memory\n", mb_freed);
 }
 
-static int __init acornfb_probe(struct platform_device *dev)
+static int __devinit acornfb_probe(struct platform_device *dev)
 {
 	unsigned long size;
 	u_int h_sync, v_sync;
-- 
1.6.6

Re: [Linux-fbdev-devel] [PATCH] x86: allow fbdev primary video code on 64-bit.

[H. P. A. <hp...@zy...>]

On 01/06/2010 11:04 PM, Dave Airlie wrote:
> From: Dave Airlie <ai...@re...>
> 
> For some reason the 64-bit tree was doing this differently and
> I can't see why it would need to.
> 
> This correct behaviour when you have two GPUs plugged in and
> 32-bit put the console in one place and 64-bit in another.
> 
> Signed-off-by: Dave Airlie <ai...@re...>

Looks good... I presume this is for .34, though?

	-hpa

[Linux-fbdev-devel] [PATCH] fbdev: bf54x-lq043fb/bfin-t350mcqb-fb: drop custom mmap() handler

[Mike F. <va...@ge...>]

From: Michael Hennerich <mic...@an...>

The common Blackfin code implements the get_fb_unmapped_area() function,
so we no longer need to have our own mmap() handler.  The common fb code
will take care of everything for us now.

Signed-off-by: Michael Hennerich <mic...@an...>
Signed-off-by: Mike Frysinger <va...@ge...>
---
 drivers/video/bf54x-lq043fb.c    |   30 ------------------------------
 drivers/video/bfin-t350mcqb-fb.c |   29 -----------------------------
 2 files changed, 0 insertions(+), 59 deletions(-)

diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
index e49ae5e..814312a 100644
--- a/drivers/video/bf54x-lq043fb.c
+++ b/drivers/video/bf54x-lq043fb.c
@@ -82,7 +82,6 @@ struct bfin_bf54xfb_info {
 	unsigned char *fb_buffer;	/* RGB Buffer */
 
 	dma_addr_t dma_handle;
-	int lq043_mmap;
 	int lq043_open_cnt;
 	int irq;
 	spinlock_t lock;	/* lock */
@@ -316,7 +315,6 @@ static int bfin_bf54x_fb_release(struct fb_info *info, int user)
 	spin_lock(&fbi->lock);
 
 	fbi->lq043_open_cnt--;
-	fbi->lq043_mmap = 0;
 
 	if (fbi->lq043_open_cnt <= 0) {
 
@@ -374,33 +372,6 @@ static int bfin_bf54x_fb_check_var(struct fb_var_screeninfo *var,
 	return 0;
 }
 
-static int bfin_bf54x_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
-{
-
-	struct bfin_bf54xfb_info *fbi = info->par;
-
-	if (fbi->lq043_mmap)
-		return -1;
-
-	spin_lock(&fbi->lock);
-	fbi->lq043_mmap = 1;
-	spin_unlock(&fbi->lock);
-
-	vma->vm_start = (unsigned long)(fbi->fb_buffer);
-
-	vma->vm_end = vma->vm_start + info->fix.smem_len;
-	/* For those who don't understand how mmap works, go read
-	 *   Documentation/nommu-mmap.txt.
-	 * For those that do, you will know that the VM_MAYSHARE flag
-	 * must be set in the vma->vm_flags structure on noMMU
-	 *   Other flags can be set, and are documented in
-	 *   include/linux/mm.h
-	 */
-	vma->vm_flags |=  VM_MAYSHARE | VM_SHARED;
-
-	return 0;
-}
-
 int bfin_bf54x_fb_cursor(struct fb_info *info, struct fb_cursor *cursor)
 {
 	if (nocursor)
@@ -452,7 +423,6 @@ static struct fb_ops bfin_bf54x_fb_ops = {
 	.fb_fillrect = cfb_fillrect,
 	.fb_copyarea = cfb_copyarea,
 	.fb_imageblit = cfb_imageblit,
-	.fb_mmap = bfin_bf54x_fb_mmap,
 	.fb_cursor = bfin_bf54x_fb_cursor,
 	.fb_setcolreg = bfin_bf54x_fb_setcolreg,
 };
diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
index 2549c53..5653d08 100644
--- a/drivers/video/bfin-t350mcqb-fb.c
+++ b/drivers/video/bfin-t350mcqb-fb.c
@@ -87,7 +87,6 @@ struct bfin_t350mcqbfb_info {
 	struct device *dev;
 	unsigned char *fb_buffer;	/* RGB Buffer */
 	dma_addr_t dma_handle;
-	int lq043_mmap;
 	int lq043_open_cnt;
 	int irq;
 	spinlock_t lock;	/* lock */
@@ -235,7 +234,6 @@ static int bfin_t350mcqb_fb_release(struct fb_info *info, int user)
 	spin_lock(&fbi->lock);
 
 	fbi->lq043_open_cnt--;
-	fbi->lq043_mmap = 0;
 
 	if (fbi->lq043_open_cnt <= 0) {
 		bfin_t350mcqb_disable_ppi();
@@ -293,32 +291,6 @@ static int bfin_t350mcqb_fb_check_var(struct fb_var_screeninfo *var,
 	return 0;
 }
 
-static int bfin_t350mcqb_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
-{
-	struct bfin_t350mcqbfb_info *fbi = info->par;
-
-	if (fbi->lq043_mmap)
-		return -1;
-
-	spin_lock(&fbi->lock);
-	fbi->lq043_mmap = 1;
-	spin_unlock(&fbi->lock);
-
-	vma->vm_start = (unsigned long)(fbi->fb_buffer + ACTIVE_VIDEO_MEM_OFFSET);
-
-	vma->vm_end = vma->vm_start + info->fix.smem_len;
-	/* For those who don't understand how mmap works, go read
-	 *   Documentation/nommu-mmap.txt.
-	 * For those that do, you will know that the VM_MAYSHARE flag
-	 * must be set in the vma->vm_flags structure on noMMU
-	 *   Other flags can be set, and are documented in
-	 *   include/linux/mm.h
-	 */
-	vma->vm_flags |= VM_MAYSHARE | VM_SHARED;
-
-	return 0;
-}
-
 int bfin_t350mcqb_fb_cursor(struct fb_info *info, struct fb_cursor *cursor)
 {
 	if (nocursor)
@@ -370,7 +342,6 @@ static struct fb_ops bfin_t350mcqb_fb_ops = {
 	.fb_fillrect = cfb_fillrect,
 	.fb_copyarea = cfb_copyarea,
 	.fb_imageblit = cfb_imageblit,
-	.fb_mmap = bfin_t350mcqb_fb_mmap,
 	.fb_cursor = bfin_t350mcqb_fb_cursor,
 	.fb_setcolreg = bfin_t350mcqb_fb_setcolreg,
 };
-- 
1.6.5.4

Re: [Linux-fbdev-devel] [PATCH 5/5] OMAP3EVM: Kconfig option added for selection between SVIDEO and CVBS

[Randy D. <ran...@or...>]

On Thu, 17 Dec 2009 20:49:36 +0530 hva...@ti... wrote:

> From: Vaibhav Hiremath <hva...@ti...>
> 
> Config option added to arch/arm/plat-omap/Kconfig for selection
> of S-Video and Composite output interfaces. The default configuration would
> be S-Video.
> 
> Signed-off-by: Vaibhav Hiremath <hva...@ti...>
> ---
>  arch/arm/mach-omap2/board-omap3evm.c |    4 ++++
>  drivers/video/omap2/dss/Kconfig      |   15 +++++++++++++++
>  2 files changed, 19 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index e615254..549e58e 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -275,7 +275,11 @@ static struct omap_dss_device omap3_evm_tv_device = {
>  	.name			= "tv",
>  	.driver_name		= "venc",
>  	.type			= OMAP_DISPLAY_TYPE_VENC,
> +#if defined(CONFIG_OMAP2_VENC_OUT_TYPE_SVIDEO)
>  	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
> +#elif defined(CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE)
> +	.u.venc.type		= OMAP_DSS_VENC_TYPE_COMPOSITE,

	.u or .phy ?

> +#endif
>  	.platform_enable	= omap3_evm_enable_tv,
>  	.platform_disable	= omap3_evm_disable_tv,
>  };



---
~Randy

Re: [Linux-fbdev-devel] [PATCH 2/4] da850/omap-l138: Add callback to control LCD panel power

[Andrew M. <ak...@li...>]

On Tue, 08 Dec 2009 09:53:46 -0800
Kevin Hilman <kh...@de...> wrote:

> Chaithrika U S <cha...@ti...> writes:
> 
> > Add the platform specific callback to control LCD panel and
> > backlight power.
> >
> > Signed-off-by: Chaithrika U S <cha...@ti...>
> > ---
> > This patch applies to DaVinci GIT tree at
> > http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary
> 
> Andrew,
> 
> I see you have pulled this series into -mm.  Thanks.  The
> drivers/video/* changes in patches 1,3 and 4 should go upstream
> through you, but I'd like to request that you drop this patch (PATCH
> 2/4) from your queue, and I will queue it in davinci-next.

I autodrop patches when they turn up in linux-next.  So if you want to
merge something then please just merge away, then I'll drop my copy.

This way patches don't get lost, and I get to check whether the patch
which was in linux-next matches the version I had, and whether the patch
which was merged into linux-next is missing any followup patches which
I had accumulated against the original.

Re: [Linux-fbdev-devel] [PATCH 0/2] [RESEND] Amstrad Delta: add support for LCD contrast

[Tony L. <to...@at...>]

* Janusz Krzysztofik <jkr...@ti...> [091205 05:54]:
> Monday 23 November 2009 18:57:51 Janusz Krzysztofik napisał(a):
> > Initialy submitted on 2009-11-16
> > (http://www.spinics.net/lists/linux-omap/msg20629.html).
> > Resendig due to fbdev mailing list address changed.
> >
> > The series consists of 2 patches:
> >
> >  [PATCH 1/2] omapfb: lcd_ams_delta: add support for contrast control
> >  [PATCH 2/2] OMAP: ams_delta_defconfig: enable LCD class device support
> >
> > It is intended for 2.6.33, if it's not too late.
> 
> Hi,
> 
> Now that Tony has changed the series status from New to Awaiting Upstream in 
> his patchwork queue[1][2], chances of getting it in throungh linux-omap tree, 
> like a few other omapfb related patches managed to do lately, seem falling 
> down drastically to me if still not answered by anyone involved in omapfb 
> development.
> 
> Imre,
> Could you please take the patches, or give your ack for Tony to take them, or 
> just point me on the right way to the get them integrated or NAKed, if none 
> of the former is?
> 
> Tomi,
> I am not sure if you are the right person for bothering here, but maybe you 
> could give your comments that would help pushing it forward?

I'd prefer Tomi to merge all the drivers/video/omap code rather
than merge it via linux-omap tree. Ideally with an ack from
Imre where possible.

Tony

 
> Thanks,
> Janusz
> 
> [1] http://patchwork.kernel.org/patch/62248/
> [2] http://patchwork.kernel.org/patch/62249/

Re: [Linux-fbdev-devel] [IMPORTANT] linux-fbdev is moving to kernel.org

[Geert U. <ge...@li...>]

On Sun, Sep 6, 2009 at 16:07, Geert Uytterhoeven <ge...@li...> wrote:
> The linux-fbdev mailing lists (linux-fbdev-devel and
> linux-fbdev-users) are being

and linux-fbdev-announce.

> migrated from SourceForge.net to a single mailing list at kernel.org
> (Thanks David!).
>
> Your subscriptions to the old mailing lists are not automatically
> transfered to the new mailing list.To subscribe to the new linux-fbdev
> mailing list, please send an email to maj...@vg... with
> the following command in the body of your email message:
>
>    subscribe linux-fbdev
>
> In about a week from now, I'll setup auto-responders on the old
> mailing lists, to redirect people to the new mailing list.

Done.

> Sorry for any inconvenience this may cause.
>
> I haven't arranged archives of the new mailing list yet. I also

Done (at MARC, cfr. http://vger.kernel.org/vger-lists.html#linux-fbdev).

Still have to collect and send the mails that were sent before MARC
started archiving.

> haven't send a patch to Linus to update MAINTAINERS. I will do that in
> the coming days.

Done, in 2.6.32.

Let's hope I can start living in a spam-free moderation-less world...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

[Linux-fbdev-devel] [PATCH 4/4] fbcon: Replace vc_cursor_type mask 0x10 with CUR_USE_SW

[Henry N. <hen...@gm...>]

from: Henry Nestler <hen...@gm...>

Replace hard coded vc_cursor_type mask 0x10 with macro CUR_USE_SW.

Signed-off-by: Henry Nestler <hen...@gm...>
---

This patch depends on [patch 3/4], because it used new macro CUR_USE_SW 0x10.

Kernel version 2.6.32-rc8

 drivers/video/console/tileblit.c        |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/console/tileblit.c b/drivers/video/console/tileblit.c
--- a/drivers/video/console/tileblit.c
+++ b/drivers/video/console/tileblit.c
@@ -83,7 +83,7 @@ static void tile_cursor(struct vc_data *vc, struct
fb_info *info, int mode,
 			int softback_lines, int fg, int bg)
 {
 	struct fb_tilecursor cursor;
-	int use_sw = (vc->vc_cursor_type & 0x10);
+	int use_sw = (vc->vc_cursor_type & CUR_USE_SW);

 	cursor.sx = vc->vc_x;
 	cursor.sy = vc->vc_y;
===

[Linux-fbdev-devel] [PATCH 3/4] fbcon: Bugfix soft cursor detection in Tile Blitting

[Henry N. <hen...@gm...>]

from: Henry Nestler <hen...@gm...>

Use mask 0x10 for "soft cursor" detection on in function tile_cursor.
(Tile Blitting Operation in framebuffer console).

The old mask 0x01 for vc_cursor_type detects CUR_NONE, CUR_LOWER_THIRD
and every second mode value as "software cursor". This hides the cursor
for these modes (cursor.mode = 0). But, only CUR_NONE or "software cursor"
should hide the cursor.

Signed-off-by: Henry Nestler <hen...@gm...>
---
Kernel version 2.6.32-rc8

 drivers/video/console/tileblit.c        |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/console/tileblit.c b/drivers/video/console/tileblit.c
index 0056a41..15e8e1a 100644
--- a/drivers/video/console/tileblit.c
+++ b/drivers/video/console/tileblit.c
@@ -83,7 +83,7 @@ static void tile_cursor(struct vc_data *vc, struct
fb_info *info, int mode,
 			int softback_lines, int fg, int bg)
 {
 	struct fb_tilecursor cursor;
-	int use_sw = (vc->vc_cursor_type & 0x01);
+	int use_sw = (vc->vc_cursor_type & 0x10);

 	cursor.sx = vc->vc_x;
 	cursor.sy = vc->vc_y;
===

[Linux-fbdev-devel] [PATCH 2/4] fbcon: Macro CUR_USE_SW for vc_cursor_type mask 0x10

[Henry N. <hen...@gm...>]

from: Henry Nestler <hen...@gm...>

Replace hard coded 0x10 mask for vc_cursor_type with new macro CUR_USE_SW.

Signed-off-by: Henry Nestler <hen...@gm...>
---
Kernel version 2.6.32-rc8

 drivers/char/vt.c                       |    2 +-
 drivers/video/console/bitblit.c         |    2 +-
 drivers/video/console/fbcon.c           |    2 +-
 drivers/video/console/fbcon_ccw.c       |    2 +-
 drivers/video/console/fbcon_cw.c        |    2 +-
 drivers/video/console/fbcon_ud.c        |    2 +-
 include/linux/console_struct.h          |    1 +
 7 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 0c80c68..f8b0f58 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -566,7 +566,7 @@ static void add_softcursor(struct vc_data *vc)
 	int i = scr_readw((u16 *) vc->vc_pos);
 	u32 type = vc->vc_cursor_type;

-	if (! (type & 0x10)) return;
+	if (! (type & CUR_USE_SW)) return;
 	if (softcursor_original != -1) return;
 	softcursor_original = i;
 	i |= ((type >> 8) & 0xff00 );
diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c
b/drivers/usb/misc/sisusbvga/sisusb_con.c
diff --git a/drivers/video/console/bitblit.c b/drivers/video/console/bitblit.c
index 6b7c8fb..5858863 100644
--- a/drivers/video/console/bitblit.c
+++ b/drivers/video/console/bitblit.c
@@ -241,7 +241,7 @@ static void bit_cursor(struct vc_data *vc, struct
fb_info *info, int mode,
 	unsigned short charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
 	int w = DIV_ROUND_UP(vc->vc_font.width, 8), c;
 	int y = real_y(ops->p, vc->vc_y);
-	int attribute, use_sw = (vc->vc_cursor_type & 0x10);
+	int attribute, use_sw = (vc->vc_cursor_type & CUR_USE_SW);
 	int err = 1;
 	char *src;

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 3681c6a..d1074ec 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -1291,7 +1291,7 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
 	if (fbcon_is_inactive(vc, info) || vc->vc_deccm != 1)
 		return;

-	if (vc->vc_cursor_type & 0x10)
+	if (vc->vc_cursor_type & CUR_USE_SW)
 		fbcon_del_cursor_timer(info);
 	else
 		fbcon_add_cursor_timer(info);
diff --git a/drivers/video/console/fbcon_ccw.c
b/drivers/video/console/fbcon_ccw.c
index bdf913e..c6fd4a9 100644
--- a/drivers/video/console/fbcon_ccw.c
+++ b/drivers/video/console/fbcon_ccw.c
@@ -226,7 +226,7 @@ static void ccw_cursor(struct vc_data *vc, struct
fb_info *info, int mode,
 	unsigned short charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
 	int w = (vc->vc_font.height + 7) >> 3, c;
 	int y = real_y(ops->p, vc->vc_y);
-	int attribute, use_sw = (vc->vc_cursor_type & 0x10);
+	int attribute, use_sw = (vc->vc_cursor_type & CUR_USE_SW);
 	int err = 1, dx, dy;
 	char *src;
 	u32 vyres = GETVYRES(ops->p->scrollmode, info);
diff --git a/drivers/video/console/fbcon_cw.c b/drivers/video/console/fbcon_cw.c
index a6819b9..00ac747 100644
--- a/drivers/video/console/fbcon_cw.c
+++ b/drivers/video/console/fbcon_cw.c
@@ -210,7 +210,7 @@ static void cw_cursor(struct vc_data *vc, struct
fb_info *info, int mode,
 	unsigned short charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
 	int w = (vc->vc_font.height + 7) >> 3, c;
 	int y = real_y(ops->p, vc->vc_y);
-	int attribute, use_sw = (vc->vc_cursor_type & 0x10);
+	int attribute, use_sw = (vc->vc_cursor_type & CUR_USE_SW);
 	int err = 1, dx, dy;
 	char *src;
 	u32 vxres = GETVXRES(ops->p->scrollmode, info);
diff --git a/drivers/video/console/fbcon_ud.c b/drivers/video/console/fbcon_ud.c
index d9b5d6e..ee740e1 100644
--- a/drivers/video/console/fbcon_ud.c
+++ b/drivers/video/console/fbcon_ud.c
@@ -256,7 +256,7 @@ static void ud_cursor(struct vc_data *vc, struct
fb_info *info, int mode,
 	unsigned short charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
 	int w = (vc->vc_font.width + 7) >> 3, c;
 	int y = real_y(ops->p, vc->vc_y);
-	int attribute, use_sw = (vc->vc_cursor_type & 0x10);
+	int attribute, use_sw = (vc->vc_cursor_type & CUR_USE_SW);
 	int err = 1, dx, dy;
 	char *src;
 	u32 vyres = GETVYRES(ops->p->scrollmode, info);
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 38fe59d..c12b3b1 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -129,6 +129,7 @@ extern void vc_SAK(struct work_struct *work);
 #define CUR_BLOCK	6
 #define CUR_HWMASK	0x0f
 #define CUR_SWMASK	0xfff0
+#define CUR_USE_SW	0x10

 #define CUR_DEFAULT CUR_UNDERLINE

===

[Linux-fbdev-devel] [PATCH 1/4] vt: Replace mask 0x0f with macro CUR_HWMASK

[Henry N. <hen...@gm...>]

from: Henry Nestler <hen...@gm...>

Replace hard coded 0x0f with pre-defined macro CUR_HWMASK
to mask vc_cursor_type, and replace hard coded 1 with CUR_NONE.

Signed-off-by: Henry Nestler <hen...@gm...>
---
Kernel version 2.6.32-rc8

 drivers/char/vt.c                       |    2 +-
 drivers/usb/misc/sisusbvga/sisusb_con.c |    2 +-
 drivers/video/console/mdacon.c          |    2 +-
 drivers/video/console/sticon.c          |    2 +-
 drivers/video/console/tileblit.c        |    2 +-
 drivers/video/console/vgacon.c          |    2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 0c80c68..26cf397 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -606,7 +606,7 @@ static void set_cursor(struct vc_data *vc)
 		if (vc == sel_cons)
 			clear_selection();
 		add_softcursor(vc);
-		if ((vc->vc_cursor_type & 0x0f) != 1)
+		if ((vc->vc_cursor_type & CUR_HWMASK) != CUR_NONE)
 			vc->vc_sw->con_cursor(vc, CM_DRAW);
 	} else
 		hide_cursor(vc);
diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c
b/drivers/usb/misc/sisusbvga/sisusb_con.c
index b624320..7599765 100644
--- a/drivers/usb/misc/sisusbvga/sisusb_con.c
+++ b/drivers/usb/misc/sisusbvga/sisusb_con.c
@@ -806,7 +806,7 @@ sisusbcon_cursor(struct vc_data *c, int mode)

 	baseline = c->vc_font.height - (c->vc_font.height < 10 ? 1 : 2);

-	switch (c->vc_cursor_type & 0x0f) {
+	switch (c->vc_cursor_type & CUR_HWMASK) {
 		case CUR_BLOCK:		from = 1;
 					to   = c->vc_font.height;
 					break;
diff --git a/drivers/video/console/mdacon.c b/drivers/video/console/mdacon.c
index dd3eaaa..688837d 100644
--- a/drivers/video/console/mdacon.c
+++ b/drivers/video/console/mdacon.c
@@ -520,7 +520,7 @@ static void mdacon_cursor(struct vc_data *c, int mode)

 	mda_set_cursor(c->vc_y*mda_num_columns*2 + c->vc_x*2);

-	switch (c->vc_cursor_type & 0x0f) {
+	switch (c->vc_cursor_type & CUR_HWMASK) {

 		case CUR_LOWER_THIRD:	mda_set_cursor_size(10, 13); break;
 		case CUR_LOWER_HALF:	mda_set_cursor_size(7,  13); break;
diff --git a/drivers/video/console/sticon.c b/drivers/video/console/sticon.c
index 491c1c1..b7c3262 100644
--- a/drivers/video/console/sticon.c
+++ b/drivers/video/console/sticon.c
@@ -144,7 +144,7 @@ static void sticon_cursor(struct vc_data *conp, int mode)
 	break;
     case CM_MOVE:
     case CM_DRAW:
-	switch (conp->vc_cursor_type & 0x0f) {
+	switch (conp->vc_cursor_type & CUR_HWMASK) {
 	case CUR_UNDERLINE:
 	case CUR_LOWER_THIRD:
 	case CUR_LOWER_HALF:
diff --git a/drivers/video/console/tileblit.c b/drivers/video/console/tileblit.c
index 0056a41..33bb70d 100644
--- a/drivers/video/console/tileblit.c
+++ b/drivers/video/console/tileblit.c
@@ -91,7 +91,7 @@ static void tile_cursor(struct vc_data *vc, struct
fb_info *info, int mode,
 	cursor.fg = fg;
 	cursor.bg = bg;

-	switch (vc->vc_cursor_type & 0x0f) {
+	switch (vc->vc_cursor_type & CUR_HWMASK) {
 	case CUR_NONE:
 		cursor.shape = FB_TILE_CURSOR_NONE;
 		break;
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index da55cca..40bd8f8 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -703,7 +703,7 @@ static void vgacon_cursor(struct vc_data *c, int mode)
 	case CM_MOVE:
 	case CM_DRAW:
 		write_vga(14, (c->vc_pos - vga_vram_base) / 2);
-		switch (c->vc_cursor_type & 0x0f) {
+		switch (c->vc_cursor_type & CUR_HWMASK) {
 		case CUR_UNDERLINE:
 			vgacon_set_cursor_size(c->vc_x,
 					       c->vc_font.height -
===

[Linux-fbdev-devel] [PATCH 2/4] da850/omap-l138: Add callback to control LCD panel power

[Chaithrika U S <cha...@ti...>]

Add the platform specific callback to control LCD panel and
backlight power.

Signed-off-by: Chaithrika U S <cha...@ti...>
---
This patch applies to DaVinci GIT tree at
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary

 arch/arm/mach-davinci/board-da850-evm.c |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 8e0722f..63a6301 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -351,6 +351,15 @@ static struct davinci_mmc_config da850_mmc_config = {
 	.version	= MMC_CTLR_VERSION_2,
 };
 
+static void da850_panel_power_ctrl(int val)
+{
+	/* lcd backlight */
+	gpio_set_value(DA850_LCD_BL_PIN, val);
+
+	/* lcd power */
+	gpio_set_value(DA850_LCD_PWR_PIN, val);
+}
+
 static int da850_lcd_hw_init(void)
 {
 	int status;
@@ -368,17 +377,11 @@ static int da850_lcd_hw_init(void)
 	gpio_direction_output(DA850_LCD_BL_PIN, 0);
 	gpio_direction_output(DA850_LCD_PWR_PIN, 0);
 
-	/* disable lcd backlight */
-	gpio_set_value(DA850_LCD_BL_PIN, 0);
-
-	/* disable lcd power */
-	gpio_set_value(DA850_LCD_PWR_PIN, 0);
-
-	/* enable lcd power */
-	gpio_set_value(DA850_LCD_PWR_PIN, 1);
+	/* Switch off panel power and backlight */
+	da850_panel_power_ctrl(0);
 
-	/* enable lcd backlight */
-	gpio_set_value(DA850_LCD_BL_PIN, 1);
+	/* Switch on panel power and backlight */
+	da850_panel_power_ctrl(1);
 
 	return 0;
 }
@@ -686,6 +689,7 @@ static __init void da850_evm_init(void)
 		pr_warning("da850_evm_init: lcd initialization failed: %d\n",
 				ret);
 
+	sharp_lk043t1dg01_pdata.panel_power_ctrl = da850_panel_power_ctrl,
 	ret = da8xx_register_lcdc(&sharp_lk043t1dg01_pdata);
 	if (ret)
 		pr_warning("da850_evm_init: lcdc registration failed: %d\n",
-- 
1.5.6

[Linux-fbdev-devel] [PATCH 1/4] davinci: fb: Updates the driver in preparation for addition of power management features

[Chaithrika U S <cha...@ti...>]

Add a helper function to enable raster. Also add one member in the
private data structure to track the current blank status, another
function pointer which takes in the platform specific callback function
to control panel power.

These updates will help in adding suspend/resume and frame buffer blank
operation features.

Signed-off-by: Chaithrika U S <cha...@ti...>
---
 drivers/video/da8xx-fb.c |   43 +++++++++++++++++++++++++++----------------
 include/video/da8xx-fb.h |    1 +
 2 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 67550e6..b3c22e1 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -115,9 +115,11 @@ struct da8xx_fb_par {
 	unsigned int databuf_sz;
 	unsigned int palette_sz;
 	unsigned int pxl_clk;
+	int blank;
 #ifdef CONFIG_CPU_FREQ
 	struct notifier_block	freq_transition;
 #endif
+	void (*panel_power_ctrl)(int);
 };
 
 /* Variable Screen Information */
@@ -195,8 +197,18 @@ static struct da8xx_panel known_lcd_panels[] = {
 	},
 };
 
+/* Enable the Raster Engine of the LCD Controller */
+static inline void lcd_enable_raster(void)
+{
+	u32 reg;
+
+	reg = lcdc_read(LCD_RASTER_CTRL_REG);
+	if (!(reg & LCD_RASTER_ENABLE))
+		lcdc_write(reg | LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
+}
+
 /* Disable the Raster Engine of the LCD Controller */
-static void lcd_disable_raster(struct da8xx_fb_par *par)
+static inline void lcd_disable_raster(void)
 {
 	u32 reg;
 
@@ -448,8 +460,7 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
 static void lcd_reset(struct da8xx_fb_par *par)
 {
 	/* Disable the Raster if previously Enabled */
-	if (lcdc_read(LCD_RASTER_CTRL_REG) & LCD_RASTER_ENABLE)
-		lcd_disable_raster(par);
+	lcd_disable_raster();
 
 	/* DMA has to be disabled */
 	lcdc_write(0, LCD_DMA_CTRL_REG);
@@ -529,13 +540,11 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
 static irqreturn_t lcdc_irq_handler(int irq, void *arg)
 {
 	u32 stat = lcdc_read(LCD_STAT_REG);
-	u32 reg;
 
 	if ((stat & LCD_SYNC_LOST) && (stat & LCD_FIFO_UNDERFLOW)) {
-		reg = lcdc_read(LCD_RASTER_CTRL_REG);
-		lcdc_write(reg & ~LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
+		lcd_disable_raster();
 		lcdc_write(stat, LCD_STAT_REG);
-		lcdc_write(reg | LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
+		lcd_enable_raster();
 	} else
 		lcdc_write(stat, LCD_STAT_REG);
 
@@ -595,16 +604,13 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb,
 				     unsigned long val, void *data)
 {
 	struct da8xx_fb_par *par;
-	unsigned int reg;
 
 	par = container_of(nb, struct da8xx_fb_par, freq_transition);
 	if (val == CPUFREQ_PRECHANGE) {
-		reg = lcdc_read(LCD_RASTER_CTRL_REG);
-		lcdc_write(reg & ~LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
+		lcd_disable_raster();
 	} else if (val == CPUFREQ_POSTCHANGE) {
 		lcd_calc_clk_divider(par);
-		reg = lcdc_read(LCD_RASTER_CTRL_REG);
-		lcdc_write(reg | LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
+		lcd_enable_raster();
 	}
 
 	return 0;
@@ -635,8 +641,10 @@ static int __devexit fb_remove(struct platform_device *dev)
 #ifdef CONFIG_CPU_FREQ
 		lcd_da8xx_cpufreq_deregister(par);
 #endif
-		if (lcdc_read(LCD_RASTER_CTRL_REG) & LCD_RASTER_ENABLE)
-			lcd_disable_raster(par);
+		if (par->panel_power_ctrl)
+			par->panel_power_ctrl(0);
+
+		lcd_disable_raster();
 		lcdc_write(0, LCD_RASTER_CTRL_REG);
 
 		/* disable DMA  */
@@ -777,6 +785,10 @@ static int __init fb_probe(struct platform_device *device)
 	par = da8xx_fb_info->par;
 	par->lcdc_clk = fb_clk;
 	par->pxl_clk = lcdc_info->pxl_clk;
+	if (fb_pdata->panel_power_ctrl) {
+		par->panel_power_ctrl = fb_pdata->panel_power_ctrl;
+		par->panel_power_ctrl(1);
+	}
 
 	if (lcd_init(par, lcd_cfg, lcdc_info) < 0) {
 		dev_err(&device->dev, "lcd_init failed\n");
@@ -877,8 +889,7 @@ static int __init fb_probe(struct platform_device *device)
 #endif
 
 	/* enable raster engine */
-	lcdc_write(lcdc_read(LCD_RASTER_CTRL_REG) |
-			LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
+	lcd_enable_raster();
 
 	return 0;
 
diff --git a/include/video/da8xx-fb.h b/include/video/da8xx-fb.h
index c051a50..89d43b3 100644
--- a/include/video/da8xx-fb.h
+++ b/include/video/da8xx-fb.h
@@ -38,6 +38,7 @@ struct da8xx_lcdc_platform_data {
 	const char manu_name[10];
 	void *controller_data;
 	const char type[25];
+	void (*panel_power_ctrl)(int);
 };
 
 struct lcd_ctrl_config {
-- 
1.5.6

[Linux-fbdev-devel] [PATCH 4/4] davinci: fb: Add framebuffer blank operation

[Chaithrika U S <cha...@ti...>]

Implement frame buffer blank operation feature for DA8xx/OMAP-L1xx
driver.

Signed-off-by: Chaithrika U S <cha...@ti...>
---
 drivers/video/da8xx-fb.c |   30 ++++++++++++++++++++++++++++++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index fcaa344..a2fcd92 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -702,6 +702,35 @@ static int fb_ioctl(struct fb_info *info, unsigned int cmd,
 	return 0;
 }
 
+static int cfb_blank(int blank, struct fb_info *info)
+{
+	struct da8xx_fb_par *par = info->par;
+	int ret = 0;
+
+	if (par->blank == blank)
+		return 0;
+
+	par->blank = blank;
+	switch (blank) {
+	case FB_BLANK_UNBLANK:
+		if (par->panel_power_ctrl)
+			par->panel_power_ctrl(1);
+
+		lcd_enable_raster();
+		break;
+	case FB_BLANK_POWERDOWN:
+		if (par->panel_power_ctrl)
+			par->panel_power_ctrl(0);
+
+		lcd_disable_raster();
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
 static struct fb_ops da8xx_fb_ops = {
 	.owner = THIS_MODULE,
 	.fb_check_var = fb_check_var,
@@ -710,6 +739,7 @@ static struct fb_ops da8xx_fb_ops = {
 	.fb_fillrect = cfb_fillrect,
 	.fb_copyarea = cfb_copyarea,
 	.fb_imageblit = cfb_imageblit,
+	.fb_blank = cfb_blank,
 };
 
 static int __init fb_probe(struct platform_device *device)
-- 
1.5.6