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

[Linux-fbdev-devel] [PATCH 00/20] omapfb: Add support for new LCDs / misc fixes

[Imre D. <imr...@no...>]

Hi,

I'd like to ask for the merging of this patchset into Linus' tree.
It adds support for new LCDs on OMAP based boards (01-12) and fixes
generic parts of the omapfb driver (13-20). The changes have been
staged in the Linux OMAP tree for quite a long time, so they should
be safe to be merged.

Note that this is about the existing "DSS1" FB driver which will
eventually be replaced by Tomi Valkeinen's DSS2 FB driver.

Thanks,
Imre

[PATCH 01/20] omapfb: Add support for the Apollon LCD
[PATCH 02/20] omapfb: Add support for MIPI-DCS compatible LCDs
[PATCH 03/20] N770: Enable LCD MIPI-DCS in Kconfig
[PATCH 04/20] omapfb: Add support for the Amstrad Delta LCD
[PATCH 05/20] omapfb: Add support for the 2430SDP LCD
[PATCH 06/20] omapfb: Add support for the OMAP2EVM LCD
[PATCH 07/20] omapfb: Add support for the 3430SDP LCD
[PATCH 08/20] omapfb: Add support for the OMAP3 EVM LCD
[PATCH 09/20] omapfb: Add support for the OMAP3 Beagle DVI output
[PATCH 10/20] omapfb: Add support for the Gumstix Overo LCD
[PATCH 11/20] omapfb: Add support for the ZOOM MDK LCD
[PATCH 12/20] omapfb: Add support for rotation on the Blizzard LCD ctrl
[PATCH 13/20] omapfb: dispc: Various typo fixes
[PATCH 14/20] omapfb: dispc: Disable iface clocks along with func clocks
[PATCH 15/20] omapfb: dispc: Enable wake up capability
[PATCH 16/20] omapfb: dispc: Allow multiple external IRQ handlers
[PATCH 17/20] omapfb: suspend/resume only if FB device is already initialized
[PATCH 18/20] omapfb: Fix coding style / remove dead line
[PATCH 19/20] omapfb: Add FB manual update option to Kconfig
[PATCH 20/20] omapfb: HWA742: fix pointer to be const

Re: [Linux-fbdev-devel] [PATCH] fb: add support for handoff from firmware to hw framebuffers

[Peter J. <pj...@re...>]

On 06/04/2009 12:46 AM, Dave Airlie wrote:
> From: Dave Airlie <ai...@re...>
> 
> With KMS we have ran into an issue where we really want the KMS fb driver
> to be the one running the console, so panics etc can be shown by switching
> out of X etc.
> 
> However with vesafb/efifb built-in, we end up with those on fb0 and the
> KMS fb driver on fb1, driving the same piece of hw, so this adds an fb info
> flag to denote a firmware fbdev, and adds a new aperture base/size range
> which can be compared when the hw drivers are installed to see if there
> is a conflict with a firmware driver, and if there is the firmware driver is
> unregistered and the hw driver takes over.
> 
> It uses new aperture_base/size members instead of comparing on the fix
> smem_start/length, as smem_start/length might for example only cover the
> first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB
> into the aperture, thus they would never overlap.
> 
> Signed-off-by: Dave Airlie <ai...@re...>
> ---
>  drivers/gpu/drm/i915/intel_fb.c |    8 ++++++++
>  drivers/video/efifb.c           |    5 ++++-
>  drivers/video/fbmem.c           |   24 ++++++++++++++++++++++++
>  drivers/video/vesafb.c          |    6 +++++-
>  include/linux/fb.h              |    9 ++++++++-
>  5 files changed, 49 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
> index e4652dc..f1849d3 100644
> --- a/drivers/gpu/drm/i915/intel_fb.c
> +++ b/drivers/gpu/drm/i915/intel_fb.c
> @@ -504,6 +504,14 @@ static int intelfb_create(struct drm_device *dev, uint32_t fb_width,
>  	info->fbops = &intelfb_ops;
>  
>  	info->fix.line_length = fb->pitch;
> +
> +	/* setup aperture base/size for vesafb takeover */
> +	info->aperture_base = dev->mode_config.fb_base;
> +	if (IS_I9XX(dev))
> +		info->aperture_size = pci_resource_len(dev->pdev, 2);
> +	else
> +		info->aperture_size = pci_resource_len(dev->pdev, 0);
> +
>  	info->fix.smem_start = dev->mode_config.fb_base + obj_priv->gtt_offset;
>  	info->fix.smem_len = size;
>  
> diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
> index 8dea2bc..eb12182 100644
> --- a/drivers/video/efifb.c
> +++ b/drivers/video/efifb.c
> @@ -280,6 +280,9 @@ static int __init efifb_probe(struct platform_device *dev)
>  	info->pseudo_palette = info->par;
>  	info->par = NULL;
>  
> +	info->aperture_base = efifb_fix.smem_start;
> +	info->aperture_size = size_total;
> +

It seems like we aught to be looking up the PCI BAR here, reserving it, and
using that as aperture_{base,size} -- though that's not strictly required by
fb_compare_aperture_sizes() .

>  	info->screen_base = ioremap(efifb_fix.smem_start, efifb_fix.smem_len);
>  	if (!info->screen_base) {
>  		printk(KERN_ERR "efifb: abort, cannot ioremap video memory "
> @@ -337,7 +340,7 @@ static int __init efifb_probe(struct platform_device *dev)
>  	info->fbops = &efifb_ops;
>  	info->var = efifb_defined;
>  	info->fix = efifb_fix;
> -	info->flags = FBINFO_FLAG_DEFAULT;
> +	info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
>  
>  	if ((err = fb_alloc_cmap(&info->cmap, 256, 0)) < 0) {
>  		printk(KERN_ERR "efifb: cannot allocate colormap\n");
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index d412a1d..3dd033b 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1462,6 +1462,16 @@ static int fb_check_foreignness(struct fb_info *fi)
>  	return 0;
>  }
>  
> +static bool fb_compare_aperture_sizes(struct fb_info *gen, struct fb_info *hw)

The name here seems weird -- something like fb_do_apertures_overlap() or even just fb_compare_apertures() would be more clear to me.

> +{
> +	/* is the generic aperture base the same as the HW one */
> +	if (gen->aperture_base == hw->aperture_base)
> +		return true;
> +	/* is the generic aperture base inside the hw base->hw base+size */
> +	if (gen->aperture_base > hw->aperture_base && gen->aperture_base <= hw->aperture_base + hw->aperture_size)
> +		return true;
> +	return false;
> +}
>  /**
>   *	register_framebuffer - registers a frame buffer device
>   *	@fb_info: frame buffer info structure
> @@ -1485,6 +1495,20 @@ register_framebuffer(struct fb_info *fb_info)
>  	if (fb_check_foreignness(fb_info))
>  		return -ENOSYS;
>  
> +	/* check all firmware fbs and kick off if the base addr overlaps */
> +	for (i = 0 ; i < FB_MAX; i++) {
> +		if (!registered_fb[i])
> +			continue;
> +
> +		if (registered_fb[i]->flags & FBINFO_MISC_FIRMWARE) {
> +			if (fb_compare_aperture_sizes(registered_fb[i], fb_info)) {
> +				printk("fb: conflicting fb hw usage - removing generic driver\n", registered_fb[i]->aperture_base, fb_info->aperture_base);
> +				unregister_framebuffer(registered_fb[i]);
> +				break;
> +			}
> +		}
> +	}

Seems like we should we also have a "nomodeset" check in this codepath.

> +
>  	num_registered_fb++;
>  	for (i = 0 ; i < FB_MAX; i++)
>  		if (!registered_fb[i])
> diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
> index d6856f4..52f03b2 100644
> --- a/drivers/video/vesafb.c
> +++ b/drivers/video/vesafb.c
> @@ -286,6 +286,10 @@ static int __init vesafb_probe(struct platform_device *dev)
>  	info->pseudo_palette = info->par;
>  	info->par = NULL;
>  
> +	/* set vesafb aperture size for generic probing */
> +	info->aperture_base = screen_info.lfb_base;
> +	info->aperture_size = size_total;
> +
>  	info->screen_base = ioremap(vesafb_fix.smem_start, vesafb_fix.smem_len);
>  	if (!info->screen_base) {
>  		printk(KERN_ERR
> @@ -437,7 +441,7 @@ static int __init vesafb_probe(struct platform_device *dev)
>  	info->fbops = &vesafb_ops;
>  	info->var = vesafb_defined;
>  	info->fix = vesafb_fix;
> -	info->flags = FBINFO_FLAG_DEFAULT |
> +	info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
>  		(ypan ? FBINFO_HWACCEL_YPAN : 0);
>  
>  	if (!ypan)
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 330c4b1..88cbe56 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -786,6 +786,8 @@ struct fb_tile_ops {
>  #define FBINFO_MISC_USEREVENT          0x10000 /* event request
>  						  from userspace */
>  #define FBINFO_MISC_TILEBLITTING       0x20000 /* use tile blitting */
> +#define FBINFO_MISC_FIRMWARE           0x40000 /* a replaceable firmware 
> +						  inited framebuffer */
>  
>  /* A driver may set this flag to indicate that it does want a set_par to be
>   * called every time when fbcon_switch is executed. The advantage is that with
> @@ -854,7 +856,12 @@ struct fb_info {
>  	u32 state;			/* Hardware state i.e suspend */
>  	void *fbcon_par;                /* fbcon use-only private area */
>  	/* From here on everything is device dependent */
> -	void *par;	
> +	void *par;
> +	/* we need the PCI or similiar aperture base/size not
> +	   smem_start/size as smem_start may just be an object
> +	   allocated inside the aperture so may not actually overlap */
> +	resource_size_t aperture_base;
> +	resource_size_t aperture_size;
>  };
>  
>  #ifdef MODULE

-- 
        Peter

Re: [Linux-fbdev-devel] [REPOST][PATCH 0/7] sparc32: use standard fields for framebuffer physical address and length

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

From: Krzysztof Helt <krz...@po...>
Date: Sun, 17 May 2009 14:30:00 +0200

> This is a series of patches to convert some drivers to use standard
> smem_start and smem_len fields from the fb_info.fix structure.
> One of reasons to make these patches is to unify fbdev layer to
> use the smem_start and smem_len so it is easy to track where
> they are set.
> 
> The patches were already sent to the sparc-linux mailing list and
> the conclusion of discussion with David Miller was here:
> 
> http://marc.info/?l=linux-fbdev-devel&m=124172182126376&w=3
> 
> I assume he acked the whole series.

All applied to sparc-next-2.6, thanks!

Re: [Linux-fbdev-devel] [PATCH] fb: add support for handoff from firmware to hw framebuffers

[Geert U. <gee...@gm...>]

On Thu, Jun 4, 2009 at 06:50, Dave Airlie <ai...@gm...> wrote:
> On Thu, Jun 4, 2009 at 2:46 PM, Dave Airlie <ai...@gm...> wrote:
>> From: Dave Airlie <ai...@re...>
>>
>> With KMS we have ran into an issue where we really want the KMS fb driver
>> to be the one running the console, so panics etc can be shown by switching
>> out of X etc.
>
> btw so far this is just an RFC.

But if it's accepted, you also want to add this support to offb.c, and
probably even macfb.c (dupes with valkyriefb.c).

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

Re: [Linux-fbdev-devel] [PATCH] fb: add support for handoff from firmware to hw framebuffers

[Dave A. <ai...@gm...>]

On Thu, Jun 4, 2009 at 2:46 PM, Dave Airlie <ai...@gm...> wrote:
> From: Dave Airlie <ai...@re...>
>
> With KMS we have ran into an issue where we really want the KMS fb driver
> to be the one running the console, so panics etc can be shown by switching
> out of X etc.

btw so far this is just an RFC.

Dave.

[Linux-fbdev-devel] [PATCH] fb: add support for handoff from firmware to hw framebuffers

[Dave A. <ai...@gm...>]

From: Dave Airlie <ai...@re...>

With KMS we have ran into an issue where we really want the KMS fb driver
to be the one running the console, so panics etc can be shown by switching
out of X etc.

However with vesafb/efifb built-in, we end up with those on fb0 and the
KMS fb driver on fb1, driving the same piece of hw, so this adds an fb info
flag to denote a firmware fbdev, and adds a new aperture base/size range
which can be compared when the hw drivers are installed to see if there
is a conflict with a firmware driver, and if there is the firmware driver is
unregistered and the hw driver takes over.

It uses new aperture_base/size members instead of comparing on the fix
smem_start/length, as smem_start/length might for example only cover the
first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB
into the aperture, thus they would never overlap.

Signed-off-by: Dave Airlie <ai...@re...>
---
 drivers/gpu/drm/i915/intel_fb.c |    8 ++++++++
 drivers/video/efifb.c           |    5 ++++-
 drivers/video/fbmem.c           |   24 ++++++++++++++++++++++++
 drivers/video/vesafb.c          |    6 +++++-
 include/linux/fb.h              |    9 ++++++++-
 5 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index e4652dc..f1849d3 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -504,6 +504,14 @@ static int intelfb_create(struct drm_device *dev, uint32_t fb_width,
 	info->fbops = &intelfb_ops;
 
 	info->fix.line_length = fb->pitch;
+
+	/* setup aperture base/size for vesafb takeover */
+	info->aperture_base = dev->mode_config.fb_base;
+	if (IS_I9XX(dev))
+		info->aperture_size = pci_resource_len(dev->pdev, 2);
+	else
+		info->aperture_size = pci_resource_len(dev->pdev, 0);
+
 	info->fix.smem_start = dev->mode_config.fb_base + obj_priv->gtt_offset;
 	info->fix.smem_len = size;
 
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 8dea2bc..eb12182 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -280,6 +280,9 @@ static int __init efifb_probe(struct platform_device *dev)
 	info->pseudo_palette = info->par;
 	info->par = NULL;
 
+	info->aperture_base = efifb_fix.smem_start;
+	info->aperture_size = size_total;
+
 	info->screen_base = ioremap(efifb_fix.smem_start, efifb_fix.smem_len);
 	if (!info->screen_base) {
 		printk(KERN_ERR "efifb: abort, cannot ioremap video memory "
@@ -337,7 +340,7 @@ static int __init efifb_probe(struct platform_device *dev)
 	info->fbops = &efifb_ops;
 	info->var = efifb_defined;
 	info->fix = efifb_fix;
-	info->flags = FBINFO_FLAG_DEFAULT;
+	info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
 
 	if ((err = fb_alloc_cmap(&info->cmap, 256, 0)) < 0) {
 		printk(KERN_ERR "efifb: cannot allocate colormap\n");
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index d412a1d..3dd033b 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1462,6 +1462,16 @@ static int fb_check_foreignness(struct fb_info *fi)
 	return 0;
 }
 
+static bool fb_compare_aperture_sizes(struct fb_info *gen, struct fb_info *hw)
+{
+	/* is the generic aperture base the same as the HW one */
+	if (gen->aperture_base == hw->aperture_base)
+		return true;
+	/* is the generic aperture base inside the hw base->hw base+size */
+	if (gen->aperture_base > hw->aperture_base && gen->aperture_base <= hw->aperture_base + hw->aperture_size)
+		return true;
+	return false;
+}
 /**
  *	register_framebuffer - registers a frame buffer device
  *	@fb_info: frame buffer info structure
@@ -1485,6 +1495,20 @@ register_framebuffer(struct fb_info *fb_info)
 	if (fb_check_foreignness(fb_info))
 		return -ENOSYS;
 
+	/* check all firmware fbs and kick off if the base addr overlaps */
+	for (i = 0 ; i < FB_MAX; i++) {
+		if (!registered_fb[i])
+			continue;
+
+		if (registered_fb[i]->flags & FBINFO_MISC_FIRMWARE) {
+			if (fb_compare_aperture_sizes(registered_fb[i], fb_info)) {
+				printk("fb: conflicting fb hw usage - removing generic driver\n", registered_fb[i]->aperture_base, fb_info->aperture_base);
+				unregister_framebuffer(registered_fb[i]);
+				break;
+			}
+		}
+	}
+
 	num_registered_fb++;
 	for (i = 0 ; i < FB_MAX; i++)
 		if (!registered_fb[i])
diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
index d6856f4..52f03b2 100644
--- a/drivers/video/vesafb.c
+++ b/drivers/video/vesafb.c
@@ -286,6 +286,10 @@ static int __init vesafb_probe(struct platform_device *dev)
 	info->pseudo_palette = info->par;
 	info->par = NULL;
 
+	/* set vesafb aperture size for generic probing */
+	info->aperture_base = screen_info.lfb_base;
+	info->aperture_size = size_total;
+
 	info->screen_base = ioremap(vesafb_fix.smem_start, vesafb_fix.smem_len);
 	if (!info->screen_base) {
 		printk(KERN_ERR
@@ -437,7 +441,7 @@ static int __init vesafb_probe(struct platform_device *dev)
 	info->fbops = &vesafb_ops;
 	info->var = vesafb_defined;
 	info->fix = vesafb_fix;
-	info->flags = FBINFO_FLAG_DEFAULT |
+	info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
 		(ypan ? FBINFO_HWACCEL_YPAN : 0);
 
 	if (!ypan)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 330c4b1..88cbe56 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -786,6 +786,8 @@ struct fb_tile_ops {
 #define FBINFO_MISC_USEREVENT          0x10000 /* event request
 						  from userspace */
 #define FBINFO_MISC_TILEBLITTING       0x20000 /* use tile blitting */
+#define FBINFO_MISC_FIRMWARE           0x40000 /* a replaceable firmware 
+						  inited framebuffer */
 
 /* A driver may set this flag to indicate that it does want a set_par to be
  * called every time when fbcon_switch is executed. The advantage is that with
@@ -854,7 +856,12 @@ struct fb_info {
 	u32 state;			/* Hardware state i.e suspend */
 	void *fbcon_par;                /* fbcon use-only private area */
 	/* From here on everything is device dependent */
-	void *par;	
+	void *par;
+	/* we need the PCI or similiar aperture base/size not
+	   smem_start/size as smem_start may just be an object
+	   allocated inside the aperture so may not actually overlap */
+	resource_size_t aperture_base;
+	resource_size_t aperture_size;
 };
 
 #ifdef MODULE
-- 
1.5.4.1

Re: [Linux-fbdev-devel] [PATCH] ARM: Move clk_add_alias() to arch/arm/common/clkdev.c (Re: [PATCH 05/10] ARM: OMAP1: Make 770 LCD work)

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

* Tony Lindgren <to...@at...> [090528 14:05]:
> * Russell King - ARM Linux <li...@ar...> [090528 12:53]:
> > On Thu, May 28, 2009 at 11:20:48AM -0700, Tony Lindgren wrote:
> > > > +int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
> > > > +	struct device *dev)
> > > > +{
> > > > +	struct clk *r = clk_get(dev, id);
> > > > +	struct clk_lookup *l;
> > > > +
> > > > +	if (!r)
> > > > +		return -ENODEV;
> > > > +
> > > > +	l = clkdev_alloc(r, alias, alias_dev_name);
> > > > +	clk_put(r);
> > > > +	if (!l)
> > > > +		return -ENODEV;
> > > > +	clkdev_add(l);
> > > > +	return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(clk_add_alias);
> > 
> > Oh, and a really good thing to do would be to fix the error checking and
> > returning in there (why did I miss it in the original PXA version...)
> 
> How about this? The prototype is in clk.h now, is that OK?

Added to patch tracking as 5536/1.
 
> Tony

> From e4e651822967b0530a9d092894c04149e28efe39 Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <to...@at...>
> Date: Thu, 28 May 2009 13:24:12 -0700
> Subject: [PATCH] ARM: Move clk_add_alias() to arch/arm/common/clkdev.c
> 
> This can be used for other arm platforms too as discussed
> on the linux-arm-kernel list.
> 
> Also check the return value with IS_ERR and return PTR_ERR
> as suggested by Russell King.
> 
> Signed-off-by: Tony Lindgren <to...@at...>
> 
> diff --git a/arch/arm/common/clkdev.c b/arch/arm/common/clkdev.c
> index 5589444..f37afd9 100644
> --- a/arch/arm/common/clkdev.c
> +++ b/arch/arm/common/clkdev.c
> @@ -135,6 +135,24 @@ struct clk_lookup *clkdev_alloc(struct clk *clk, const char *con_id,
>  }
>  EXPORT_SYMBOL(clkdev_alloc);
>  
> +int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
> +	struct device *dev)
> +{
> +	struct clk *r = clk_get(dev, id);
> +	struct clk_lookup *l;
> +
> +	if (IS_ERR(r))
> +		return PTR_ERR(r);
> +
> +	l = clkdev_alloc(r, alias, alias_dev_name);
> +	clk_put(r);
> +	if (!l)
> +		return -ENODEV;
> +	clkdev_add(l);
> +	return 0;
> +}
> +EXPORT_SYMBOL(clk_add_alias);
> +
>  /*
>   * clkdev_drop - remove a clock dynamically allocated
>   */
> diff --git a/arch/arm/mach-pxa/clock.c b/arch/arm/mach-pxa/clock.c
> index db52d2c..49ae382 100644
> --- a/arch/arm/mach-pxa/clock.c
> +++ b/arch/arm/mach-pxa/clock.c
> @@ -86,20 +86,3 @@ void clks_register(struct clk_lookup *clks, size_t num)
>  	for (i = 0; i < num; i++)
>  		clkdev_add(&clks[i]);
>  }
> -
> -int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
> -	struct device *dev)
> -{
> -	struct clk *r = clk_get(dev, id);
> -	struct clk_lookup *l;
> -
> -	if (!r)
> -		return -ENODEV;
> -
> -	l = clkdev_alloc(r, alias, alias_dev_name);
> -	clk_put(r);
> -	if (!l)
> -		return -ENODEV;
> -	clkdev_add(l);
> -	return 0;
> -}
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 1db9bbf..1d37f42 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -142,4 +142,17 @@ struct clk *clk_get_parent(struct clk *clk);
>   */
>  struct clk *clk_get_sys(const char *dev_id, const char *con_id);
>  
> +/**
> + * clk_add_alias - add a new clock alias
> + * @alias: name for clock alias
> + * @alias_dev_name: device name
> + * @id: platform specific clock name
> + * @dev: device
> + *
> + * Allows using generic clock names for drivers by adding a new alias.
> + * Assumes clkdev, see clkdev.h for more info.
> + */
> +int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
> +			struct device *dev);
> +
>  #endif

[Linux-fbdev-devel] [RESEND] [PATCH] Fix a bug in intelfb initialization.

[Paul M. <pau...@us...>]

Dear hackers,


I sent this message already some time ago but probably not to the
correct people. (Now I took the one from MAINTAINERS and the ones from
this message [1].)


Bests,

Paul


[1] http://marc.info/?l=linux-fbdev-devel&m=124388452327831&w=2

--
When changing video timing dynamically via fbset the screen sporadically
is rendered black.

With the attached fix which disables VCO prior to timing register
change the problem disappears.

I had a look at the Xserver register setup code. Here the VCO is
disabled in the same way [1].

This patch is taken from vga-sync-field version 0.0.11 [2][3].

[1] http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/i830_driver.c
[2] http://lowbyte.de/vga-sync-fields/vga-sync-fields-0.0.11.tgz
[3] http://easy-vdr.de/git?p=frc.git/.git;a=commit;h=dcc3b863e5a663652587619c357bd20075af6896

Signed-off-by: Thomas Hilber <sp...@lo...>
Signed-off-by: Paul Menzel <pau...@us...>
---
 drivers/video/intelfb/intelfbdrv.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/video/intelfb/intelfbdrv.c b/drivers/video/intelfb/intelfbdrv.c
index 6d8e541..7ba8db5 100644
--- a/drivers/video/intelfb/intelfbdrv.c
+++ b/drivers/video/intelfb/intelfbdrv.c
@@ -1364,6 +1364,11 @@ static int intelfb_set_par(struct fb_info *info)
 	DBG_MSG("intelfb_set_par (%dx%d-%d)\n", info->var.xres,
 		info->var.yres, info->var.bits_per_pixel);
 
+	/*
+	 * Disable VCO prior to timing register change.
+	 */
+	OUTREG(DPLL_A, INREG(DPLL_A) & ~DPLL_VCO_ENABLE);
+
 	intelfb_blank(FB_BLANK_POWERDOWN, info);
 
 	if (ACCEL(dinfo, info))
-- 
1.6.2.4

Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly

[Michal S. <hra...@ce...>]

2009/6/2 Andrew Morton <ak...@li...>:
> On Sat, 30 May 2009 13:58:33 +0200
> Krzysztof Helt <krz...@po...> wrote:
>
>> The intelfb driver sets color map depending on currently active pipe. However, if an LVDS
>> display is attached (like in laptop) the active pipe variable is never set. The default value is
>> PIPE_A and can be wrong.
>> Set up the pipe variable during driver initialization after hardware state was read.
>>
>> Also, the detection of the active display (and hence the pipe) is wrong. The pipes are assigned
>> to so called planes. Both pipes are always enabled on my laptop but only one plane is enabled
>> (the plane A for the CRT or the plane B for the LVDS). Change active pipe detection code
>> to take into account a status of the plane assigned to each pipe.
>>
>> The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color
>> entries are displayed correctly.
>>
>> The graphics chip description is here (G45 vol. 3):
>> http://intellinuxgraphics.org/documentation.html
>>
>> Signed-off-by: Krzysztof Helt <krz...@wp...>
>>
>> ---
>> The second version of the fix to this problem. Now, it is much more sophisticated
>> based on the knowledge gained from documentation available at http://intellinuxgraphics.org/.
>>
>> It does not change a default behaviour (assumed pipe A) for all cases except the case that only
>> the plane assigned to the pipe B is active. It is enough to fix the issue for me.
>
> I queued this.
>
>> Please test it.
>
> But it would great be Dean and/or Michal were to be able to test it, please.
>

Thanks for the patch.

Unfortunately I did not get to testing the patch yet.

According to the description it is supposed to resolve some confusion
over what pipe is enabled or not.

X server reports the pipes connected as follows:
(II) intel(0):   Pipe A is on
(II) intel(0):   Display plane A is now enabled and connected to pipe A.
(II) intel(0):   Pipe B is off
(II) intel(0):   Display plane B is now disabled and connected to pipe A.
(II) intel(0):   Output VGA is connected to pipe none
(II) intel(0):   Output TMDS-1 is connected to pipe A
(II) intel(0):   Output TV is connected to pipe none

However, I also get this warning before the outputs are listed:
(WW) intel(0): Couldn't detect panel mode.  Disabling panel

Is this a configuration that would likely be affected by the issue
fixed here or do I have a different problem?

I am currently not using intelfb because last time I tried it produced
even worse results than efifb (which does suffer from the wrong colors
as well).

Thanks

Michal

Re: [Linux-fbdev-devel] aty128fb artifacts

[Jonathan N. <jrn...@gm...>]

Alex Deucher wrote:

> The display engine is very similar the radeon display engine and is
> well documented in the xorg r128 and radeon drivers:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-r128/
> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/

Thanks for the pointers! I'll check them out.

Regards,
Jonathan

Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly

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

On Sat, 30 May 2009 13:58:33 +0200
Krzysztof Helt <krz...@po...> wrote:

> The intelfb driver sets color map depending on currently active pipe. However, if an LVDS 
> display is attached (like in laptop) the active pipe variable is never set. The default value is 
> PIPE_A and can be wrong.
> Set up the pipe variable during driver initialization after hardware state was read.
> 
> Also, the detection of the active display (and hence the pipe) is wrong. The pipes are assigned
> to so called planes. Both pipes are always enabled on my laptop but only one plane is enabled
> (the plane A for the CRT or the plane B for the LVDS). Change active pipe detection code
> to take into account a status of the plane assigned to each pipe.
> 
> The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color
> entries are displayed correctly.
> 
> The graphics chip description is here (G45 vol. 3):
> http://intellinuxgraphics.org/documentation.html
> 
> Signed-off-by: Krzysztof Helt <krz...@wp...>
> 
> ---
> The second version of the fix to this problem. Now, it is much more sophisticated
> based on the knowledge gained from documentation available at http://intellinuxgraphics.org/.
> 
> It does not change a default behaviour (assumed pipe A) for all cases except the case that only 
> the plane assigned to the pipe B is active. It is enough to fix the issue for me.

I queued this.

> Please test it.

But it would great be Dean and/or Michal were to be able to test it, please.

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Linus T. <tor...@li...>]

On Tue, 2 Jun 2009, Alan Cox wrote:
> 
> I'll fix those over the next few days to copy first, its pretty trivial
> stuff

Btw, it's probably best to put them in functions of their own, and make 
sure they are marked "noinline". Because otherwise gcc will easily inline 
them and because they then presumably have these "struct termios" etc as 
local variables, if that happens gcc will blow your stack to kingdom come.

			Linus

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Alan C. <al...@lx...>]

> And then there is TIOCGSOFTCAR, which is just insane, and apparently gets 
> the lock in order to just test _one_ bit (C_CLOCAL). Never mind that if 

If you don't take it there are cases where it gets cleared by drivers
momentarily and put back so you would give the wrong answer.

> something is changing it, we really don't care _which_ case we return, so 
> the lock is likely pointless to begin with (can "termios" actually change 
> as a pointer?). But then does the user space access with the lock held.

I'll fix those over the next few days to copy first, its pretty trivial
stuff

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Linus T. <tor...@li...>]

On Tue, 2 Jun 2009, Linus Torvalds wrote:
> 
> I thought we already always copied things to a buffer (for conversion 
> reasons, ie doing the whole "ktermios<->random-user-termios-of-the-day" 
> thing), but I guess I was wrong.

Ahh. We do it in the other direction (ie set_termios), and for some 
limited form of to-user (get_sgttyb, get_tchars etc) but apparently not 
for TCGETS*.

There's a few other odd corners there too. Look at TCGETA - it doesn't get 
the lock at all. Why are TCGETS* and TCGETA so different?

I wonder if we even really need that lock for TCGETS*. We clearly don't do 
it for "struct termio" (TCGETA).

The same imbalance seems to exist for get_termiox vs set_termiox. The 
"set" part does the nice "copy outside the lock", while the "get" part 
copies to user space inside the lock.

And then there is TIOCGSOFTCAR, which is just insane, and apparently gets 
the lock in order to just test _one_ bit (C_CLOCAL). Never mind that if 
something is changing it, we really don't care _which_ case we return, so 
the lock is likely pointless to begin with (can "termios" actually change 
as a pointer?). But then does the user space access with the lock held.

		Linus

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Linus T. <tor...@li...>]

On Tue, 2 Jun 2009, Alan Cox wrote:
>
> > ie the fact that the TTY layer does user-mode copies while holding some 
> > tty lock. So now the tty layer introduces that chain from some random lock 
> > to the mmap_sem.
> 
> Its basically holding the termios lock to copy from the struct termios to
> user space which means its trivial to do copy to a stack buffer first. I
> can fix that pretty easily if you want.

It would be good. I don't know if it matters for any other path, but 
mmap_sem has always been a total _bitch_ to work around for deadlocks, so 
it's always good to try to avoid holding another lock while doing copying 
to/from user. 

I thought we already always copied things to a buffer (for conversion 
reasons, ie doing the whole "ktermios<->random-user-termios-of-the-day" 
thing), but I guess I was wrong.

		Linus

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Alan C. <al...@lx...>]

> ie the fact that the TTY layer does user-mode copies while holding some 
> tty lock. So now the tty layer introduces that chain from some random lock 
> to the mmap_sem.

Its basically holding the termios lock to copy from the struct termios to
user space which means its trivial to do copy to a stack buffer first. I
can fix that pretty easily if you want.

Alan

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Linus T. <tor...@li...>]

Alan cc'd due to the terminal layer locking thing.

On Tue, 2 Jun 2009, Krzysztof Helt wrote:
> 
> Not only. The patch uncovers another lockdep. My fb_mmap patch was applied
> during this test.
> 
> I will investigate the fb_notifier_list.rwsem issue and how to solve this 
> but not for the 2.6.30 (I don't enough time).

Sure.  Thanks for testing. This one still seems to be all about the fb 
registration phase (ie no runtime deadlocks), an I guess a 

        lockdep_off();
        ...
        lockdep_on();

around just the registration part would have been the much better thing to 
do (ie snip the lockdep chains at the actual point we don't care about).

That said, this particular lockdep chain does point to an interesting 
chain in the loop:

> -> #3 (&mm->mmap_sem){++++++}:
>        [<c0243b3d>] validate_chain+0xa8d/0xfd0
>        [<c0244318>] __lock_acquire+0x298/0x9e0
>        [<c0244ad4>] lock_acquire+0x74/0xa0
>        [<c026a967>] might_fault+0x77/0xa0
>        [<c031aa93>] copy_to_user+0x33/0x60
>        [<c0351a38>] tty_mode_ioctl+0x98/0x4c0
>        [<c0351e9a>] n_tty_ioctl_helper+0x3a/0x180
>        [<c034ed67>] n_tty_ioctl+0x27/0xd0
>        [<c034d96e>] tty_ioctl+0xae/0x850
>        [<c0288610>] vfs_ioctl+0x20/0x70
>        [<c0288a34>] do_vfs_ioctl+0x2c4/0x4c0
>        [<c0288c69>] sys_ioctl+0x39/0x60
>        [<c0202c65>] syscall_call+0x7/0xb
>        [<ffffffff>] 0xffffffff

ie the fact that the TTY layer does user-mode copies while holding some 
tty lock. So now the tty layer introduces that chain from some random lock 
to the mmap_sem.

(Which is not a deadlock in itself, but is now a very strong link in a 
chain of locking for any device driver that does both mmap() and acts as a 
tty. Admittedly fbcon is perhaps fairly unique in that).

I thought we had gotten rid of all of those. And we probably did - on the 
read/write side. But apparently not termios_lock.

> -> #2 (&tty->termios_mutex){+.+...}:
>        [<c0243b3d>] validate_chain+0xa8d/0xfd0
>        [<c0244318>] __lock_acquire+0x298/0x9e0
>        [<c0244ad4>] lock_acquire+0x74/0xa0
>        [<c044d4c3>] mutex_lock_nested+0x53/0x280
>        [<c034c5c2>] tty_do_resize+0x22/0xe0
>        [<c035f06d>] vc_do_resize+0x2fd/0x380
>        [<c035f15b>] vc_resize+0x1b/0x30
>        [<c03382eb>] fbcon_init+0x19b/0x400
>        [<c035aec0>] visual_init+0x80/0xc0
>        [<c035ea28>] bind_con_driver+0x158/0x2e0
>        [<c035ebe3>] take_over_console+0x33/0x50
>        [<c03385b2>] fbcon_takeover+0x62/0xb0
>        [<c0339175>] fbcon_event_notify+0x815/0x8f0
>        [<c0237f1e>] notifier_call_chain+0x4e/0x90
>        [<c0238124>] __blocking_notifier_call_chain+0x44/0x60
>        [<c023815a>] blocking_notifier_call_chain+0x1a/0x20
>        [<c032c291>] fb_notifier_call_chain+0x11/0x20
>        [<c032e3d7>] register_framebuffer+0x177/0x240

And here we have the other link in the chain. Again, it's to that fairly 
uninteresting "register_framebuffer()", so in practice none of this will 
ever deadlock, but it shows how easy it is to get subtle chains like that.

			Linus

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Krzysztof H. <krz...@po...>]

On Mon, 1 Jun 2009 13:38:40 -0700 (PDT)
Linus Torvalds <tor...@li...> wrote:

> 
> Btw - one thing you could try on the whole lockdep front - and I realize 
> that this is a _total_ hack - is to try the patch below.
> 
> The _only_ thing it does is to hide the sysfs_mutex -> mm_lock chain from 
> lockdep, by using the (incorrect) __copy_to_user_inatomic() instead of the 
> (correct) copy_to_user(). But I'd like to hear if that sysfs_mutex in 
> readdir is the only way you can get a chain.
> 

Not only. The patch uncovers another lockdep. My fb_mmap patch was applied
during this test.

I will investigate the fb_notifier_list.rwsem issue and how to solve this 
but not for the 2.6.30 (I don't enough time).

Regards,
Krzysztof

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.30-rc7 #5
-------------------------------------------------------
mplayer/1267 is trying to acquire lock:
 (&fb_info->lock){+.+.+.}, at: [<c032c71f>] fb_release+0x1f/0x60

but task is already holding lock:
 (&mm->mmap_sem){++++++}, at: [<c026e072>] sys_munmap+0x22/0x50

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #3 (&mm->mmap_sem){++++++}:
       [<c0243b3d>] validate_chain+0xa8d/0xfd0
       [<c0244318>] __lock_acquire+0x298/0x9e0
       [<c0244ad4>] lock_acquire+0x74/0xa0
       [<c026a967>] might_fault+0x77/0xa0
       [<c031aa93>] copy_to_user+0x33/0x60
       [<c0351a38>] tty_mode_ioctl+0x98/0x4c0
       [<c0351e9a>] n_tty_ioctl_helper+0x3a/0x180
       [<c034ed67>] n_tty_ioctl+0x27/0xd0
       [<c034d96e>] tty_ioctl+0xae/0x850
       [<c0288610>] vfs_ioctl+0x20/0x70
       [<c0288a34>] do_vfs_ioctl+0x2c4/0x4c0
       [<c0288c69>] sys_ioctl+0x39/0x60
       [<c0202c65>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

-> #2 (&tty->termios_mutex){+.+...}:
       [<c0243b3d>] validate_chain+0xa8d/0xfd0
       [<c0244318>] __lock_acquire+0x298/0x9e0
       [<c0244ad4>] lock_acquire+0x74/0xa0
       [<c044d4c3>] mutex_lock_nested+0x53/0x280
       [<c034c5c2>] tty_do_resize+0x22/0xe0
       [<c035f06d>] vc_do_resize+0x2fd/0x380
       [<c035f15b>] vc_resize+0x1b/0x30
       [<c03382eb>] fbcon_init+0x19b/0x400
       [<c035aec0>] visual_init+0x80/0xc0
       [<c035ea28>] bind_con_driver+0x158/0x2e0
       [<c035ebe3>] take_over_console+0x33/0x50
       [<c03385b2>] fbcon_takeover+0x62/0xb0
       [<c0339175>] fbcon_event_notify+0x815/0x8f0
       [<c0237f1e>] notifier_call_chain+0x4e/0x90
       [<c0238124>] __blocking_notifier_call_chain+0x44/0x60
       [<c023815a>] blocking_notifier_call_chain+0x1a/0x20
       [<c032c291>] fb_notifier_call_chain+0x11/0x20
       [<c032e3d7>] register_framebuffer+0x177/0x240
       [<ccacc5a6>] radeonfb_pci_register+0x9d6/0xd70 [radeonfb]
       [<c032804e>] local_pci_probe+0xe/0x10
       [<c0328c8c>] pci_device_probe+0x5c/0x80
       [<c0371548>] driver_probe_device+0x68/0x140
       [<c0371695>] __driver_attach+0x75/0x80
       [<c0370b23>] bus_for_each_dev+0x43/0x70
       [<c03713e9>] driver_attach+0x19/0x20
       [<c03711a3>] bus_add_driver+0x1b3/0x250
       [<c03718ea>] driver_register+0x5a/0x120
       [<c032902e>] __pci_register_driver+0x4e/0xb0
       [<ccad5017>] 0xccad5017
       [<c020102b>] _stext+0x2b/0x150
       [<c024ce05>] sys_init_module+0x85/0x1c0
       [<c0202c65>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

-> #1 ((fb_notifier_list).rwsem){.+.+.+}:
       [<c0243b3d>] validate_chain+0xa8d/0xfd0
       [<c0244318>] __lock_acquire+0x298/0x9e0
       [<c0244ad4>] lock_acquire+0x74/0xa0
       [<c044dc47>] down_read+0x47/0x60
       [<c023810a>] __blocking_notifier_call_chain+0x2a/0x60
       [<c023815a>] blocking_notifier_call_chain+0x1a/0x20
       [<c032c291>] fb_notifier_call_chain+0x11/0x20
       [<c032e3d7>] register_framebuffer+0x177/0x240
       [<ccacc5a6>] radeonfb_pci_register+0x9d6/0xd70 [radeonfb]
       [<c032804e>] local_pci_probe+0xe/0x10
       [<c0328c8c>] pci_device_probe+0x5c/0x80
       [<c0371548>] driver_probe_device+0x68/0x140
       [<c0371695>] __driver_attach+0x75/0x80
       [<c0370b23>] bus_for_each_dev+0x43/0x70
       [<c03713e9>] driver_attach+0x19/0x20
       [<c03711a3>] bus_add_driver+0x1b3/0x250
       [<c03718ea>] driver_register+0x5a/0x120
       [<c032902e>] __pci_register_driver+0x4e/0xb0
       [<ccad5017>] 0xccad5017
       [<c020102b>] _stext+0x2b/0x150
       [<c024ce05>] sys_init_module+0x85/0x1c0
       [<c0202c65>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

-> #0 (&fb_info->lock){+.+.+.}:
       [<c024362b>] validate_chain+0x57b/0xfd0
       [<c0244318>] __lock_acquire+0x298/0x9e0
       [<c0244ad4>] lock_acquire+0x74/0xa0
       [<c044d4c3>] mutex_lock_nested+0x53/0x280
       [<c032c71f>] fb_release+0x1f/0x60
       [<c027d9a6>] __fput+0xc6/0x1c0
       [<c027dcf8>] fput+0x18/0x20
       [<c026c53c>] remove_vma+0x3c/0x60
       [<c026d015>] do_munmap+0x1f5/0x260
       [<c026e07f>] sys_munmap+0x2f/0x50
       [<c0202c65>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

other info that might help us debug this:

1 lock held by mplayer/1267:
 #0:  (&mm->mmap_sem){++++++}, at: [<c026e072>] sys_munmap+0x22/0x50

stack backtrace:
Pid: 1267, comm: mplayer Tainted: G        W  2.6.30-rc7 #5
Call Trace:
 [<c0242f48>] print_circular_bug_tail+0x78/0xc0
 [<c0240de3>] ? print_circular_bug_entry+0x43/0x50
 [<c024362b>] validate_chain+0x57b/0xfd0
 [<c0244318>] __lock_acquire+0x298/0x9e0
 [<c0241e6b>] ? trace_hardirqs_on+0xb/0x10
 [<c0244ad4>] lock_acquire+0x74/0xa0
 [<c032c71f>] ? fb_release+0x1f/0x60
 [<c044d4c3>] mutex_lock_nested+0x53/0x280
 [<c032c71f>] ? fb_release+0x1f/0x60
 [<c026a708>] ? free_pgd_range+0x128/0x170
 [<c032c71f>] fb_release+0x1f/0x60
 [<c027d9a6>] __fput+0xc6/0x1c0
 [<c027dcf8>] fput+0x18/0x20
 [<c026c53c>] remove_vma+0x3c/0x60
 [<c026d015>] do_munmap+0x1f5/0x260
 [<c026e07f>] sys_munmap+0x2f/0x50
 [<c0202c65>] syscall_call+0x7/0xb

----------------------------------------------------------------------
Audi kilka tysiecy zlotych taniej? Przebieraj wsrod tysiecy ogloszen!
Sprawdz >>> http://link.interia.pl/f21b7

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Krzysztof H. <krz...@po...>]

On Mon, 1 Jun 2009 13:38:40 -0700 (PDT)
Linus Torvalds <tor...@li...> wrote:

> 
> 
> On Mon, 1 Jun 2009, Krzysztof Helt wrote:
> > If the revert to BKL is rejected this patch may wait till 2.6.31.
> 
> Ahh, so this one helps clean up locking, but doesn't fix any actual 
> regressions? I was going to ask you about that.
> 

There is a problem with multihead configuration with and without the patch.
I realize that it is late stage of the 2.6.30 so IMO it is not worth pushing it at 
this moment .
The patch is quite an improvement for smem_start/smem_len handling
so it should find its way into the tree.

> Btw - one thing you could try on the whole lockdep front - and I realize 
> that this is a _total_ hack - is to try the patch below.
> 
> The _only_ thing it does is to hide the sysfs_mutex -> mm_lock chain from 
> lockdep, by using the (incorrect) __copy_to_user_inatomic() instead of the 
> (correct) copy_to_user(). But I'd like to hear if that sysfs_mutex in 
> readdir is the only way you can get a chain.
> 

I'll test this.

Best regards,
Krzysztof

----------------------------------------------------------------------
Chcesz miec nawigacje GPS ?
Zamow lub przedluz umowe na neostrade, a nawigacja bedzie Twoja.
Kliknij na link po szczegoly! http://link.interia.pl/f219a

Re: [Linux-fbdev-devel] [PATCH] fb: add support of LCD display controller on pxa168/910 (base layer)

[Eric M. <eri...@gm...>]

On Mon, Jun 1, 2009 at 11:28 PM, Krzysztof Helt <krz...@po...> wrote:
> On Wed, 27 May 2009 16:21:11 +0800
> Eric Miao <eri...@gm...> wrote:
>
>> Hi Krzysztof,
>>
>> Sorry for late reply, and thanks for the time reviewing this.
>> See the revised version below with changes:
>>
>> 1. removed the unnecessary error checking of pseudo color
>> in check_var(). The pseudo color mode is actually be well
>> supported.
>>
>> 2. determine_best_pix_fmt() moved into check_var(), and
>> set_pix_fmt() is called to ensure a correct var.
>>
>> 3. set_graphics_start() removed from set_par
>>
>> 4. removed duplicate fields in pxa168fb_info and fb_info
>>
>> 5. correct the error exiting path
>>
>> 6. add __init attribute to pxa168fb_init_mode()
>>
>> ===================>8=======================
>>
>> From 27a53df0467f379de5ca2d6d117852fbaf93c2fc Mon Sep 17 00:00:00 2001
>> From: Lennert Buytenhek <bu...@ma...>
>> Date: Wed, 11 Feb 2009 17:25:24 +0800
>> Subject: [PATCH] fb: add support of LCD display controller on
>> pxa168/910 (base layer)
>>
>> This driver is originally written by Lennert, modified by Green to be
>> feature complete,  and ported by Jun Nie and Kevin Liu for pxa168/910
>> processors.
>>
>> The patch adds support for the on-chip LCD display controller, it
>> currently supports the base (graphics) layer only.
>>
>> Signed-off-by: Lennert Buytenhek <bu...@ma...>
>> Signed-off-by: Green Wan <gw...@ma...>
>> Cc: Peter Liao <pl...@ma...>
>> Signed-off-by: Jun Nie <nj...@ma...>
>> Signed-off-by: Kevin Liu <kl...@ma...>
>> Signed-off-by: Eric Miao <eri...@ma...>
>> ---
>
> Acked-by: Krzysztof Helt <krz...@wp...>
>
> You probably want to sent this patch to the RMK's tree.
> If not please sent it to Andrew Morton.

OK. And a big thanks for the time.

Re: [Linux-fbdev-devel] [PATCH] GXT400P and GXT6500P support

[Benjamin H. <be...@ke...>]

On Mon, 2009-06-01 at 09:32 +0200, Giuseppe Coviello wrote:

> 
> Signed-off-by: Nico Macrionitis <ac...@cr...>
> Signed-off-by: Giuseppe Coviello <cj...@cr...>

As long as you guys have verified that it actually works, I have
no objection.

Ack.

Cheers,
Ben.

> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 0048f11..7ee1e65 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -1964,14 +1964,16 @@ config FB_PNX4008_DUM_RGB
>  	  Say Y here to enable support for PNX4008 RGB Framebuffer
>  
>  config FB_IBM_GXT4500
> -	tristate "Framebuffer support for IBM GXT4500P adaptor"
> +	tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
>  	depends on FB && PPC
>  	select FB_CFB_FILLRECT
>  	select FB_CFB_COPYAREA
>  	select FB_CFB_IMAGEBLIT
>  	---help---
> -	  Say Y here to enable support for the IBM GXT4500P display
> -	  adaptor, found on some IBM System P (pSeries) machines.
> +	  Say Y here to enable support for the IBM GXT4000P/6000P and
> +	  GXT4500P/6500P display adaptor based on Raster Engine RC1000,
> +	  found on some IBM System P (pSeries) machines. This driver
> +	  doesn't use Geometry Engine GT1000.
>  
>  config FB_PS3
>  	tristate "PS3 GPU framebuffer driver"
> diff --git a/drivers/video/gxt4500.c b/drivers/video/gxt4500.c
> index 896e53d..a3c4d41 100644
> --- a/drivers/video/gxt4500.c
> +++ b/drivers/video/gxt4500.c
> @@ -1,5 +1,6 @@
>  /*
> - * Frame buffer device for IBM GXT4500P and GXT6000P display adaptors
> + * Frame buffer device for IBM GXT4500P/6500P and GXT4000P/6000P
> + * display adaptors
>   *
>   * Copyright (C) 2006 Paul Mackerras, IBM Corp. <pa...@sa...>
>   */
> @@ -14,6 +15,8 @@
>  #include <linux/string.h>
>  
>  #define PCI_DEVICE_ID_IBM_GXT4500P	0x21c
> +#define PCI_DEVICE_ID_IBM_GXT6500P      0x21b
> +#define PCI_DEVICE_ID_IBM_GXT4000P      0x16e
>  #define PCI_DEVICE_ID_IBM_GXT6000P	0x170
>  
>  /* GXT4500P registers */
> @@ -173,6 +176,8 @@ static const struct fb_videomode defaultmode __devinitdata = {
>  /* List of supported cards */
>  enum gxt_cards {
>  	GXT4500P,
> +	GXT6500P,
> +	GXT4000P,
>  	GXT6000P
>  };
>  
> @@ -182,6 +187,8 @@ static const struct cardinfo {
>  	const char *cardname;
>  } cardinfo[] = {
>  	[GXT4500P] = { .refclk_ps = 9259, .cardname = "IBM GXT4500P" },
> +	[GXT6500P] = { .refclk_ps = 9259, .cardname = "IBM GXT6500P" },
> +	[GXT4000P] = { .refclk_ps = 40000, .cardname = "IBM GXT4000P" },
>  	[GXT6000P] = { .refclk_ps = 40000, .cardname = "IBM GXT6000P" },
>  };
>  
> @@ -736,6 +743,10 @@ static void __devexit gxt4500_remove(struct pci_dev *pdev)
>  static const struct pci_device_id gxt4500_pci_tbl[] = {
>  	{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4500P),
>  	  .driver_data = GXT4500P },
> +	{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6500P),
> +	  .driver_data = GXT6500P },
> +	{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4000P),
> +	  .driver_data = GXT4000P },
>  	{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6000P),
>  	  .driver_data = GXT6000P },
>  	{ 0 }
> @@ -768,7 +779,7 @@ static void __exit gxt4500_exit(void)
>  module_exit(gxt4500_exit);
>  
>  MODULE_AUTHOR("Paul Mackerras <pa...@sa...>");
> -MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6000P");
> +MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6500P and GXT4000P/6000P");
>  MODULE_LICENSE("GPL");
>  module_param(mode_option, charp, 0);
>  MODULE_PARM_DESC(mode_option, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\"");
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Lin...@oz...
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Ingo M. <mi...@el...>]

* Linus Torvalds <tor...@li...> wrote:

> On Mon, 1 Jun 2009, Krzysztof Helt wrote:
> > 
> > I will fix it.
> 
> Thanks.
> 
> > If the revert to BKL is rejected this patch may wait till 
> > 2.6.31.
> 
> Ahh, so this one helps clean up locking, but doesn't fix any 
> actual regressions? I was going to ask you about that.
> 
> Btw - one thing you could try on the whole lockdep front - and I 
> realize that this is a _total_ hack - is to try the patch below.

One thing that might be less obscure is to add:

	lockdep_off();
	...
	lockdep_on();

to around those user-copies.

Those cause lockdep to totally ignore those dependencies. It's an 
ugly hack - but at least a readable hack IMO. With big red warning 
signs, a promise to fix this ASAP, etc.

It's still much better than a big ugly revert back to the BKL (of 
course - and regardless of how late we are in the cycle) - and 
probably a bit better than the atomic-copy hack.

Or am i missing something?

	Ingo

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Linus T. <tor...@li...>]

On Mon, 1 Jun 2009, Krzysztof Helt wrote:
> 
> I will fix it. 

Thanks.

> If the revert to BKL is rejected this patch may wait till 2.6.31.

Ahh, so this one helps clean up locking, but doesn't fix any actual 
regressions? I was going to ask you about that.

Btw - one thing you could try on the whole lockdep front - and I realize 
that this is a _total_ hack - is to try the patch below.

The _only_ thing it does is to hide the sysfs_mutex -> mm_lock chain from 
lockdep, by using the (incorrect) __copy_to_user_inatomic() instead of the 
(correct) copy_to_user(). But I'd like to hear if that sysfs_mutex in 
readdir is the only way you can get a chain.

So this is in _no_ way meant to be a serious patch, and is literally just 
a test to see if "ok, readdir and sysfs_mutex is really the only real 
deadlock case" is true. Or are there possibly other cases that trigger 
this?

Because if it's really just this chain through sysfs_mutex, then the 
deadlock scenario should boil down to just the "two different fbcon's and 
really unlucky activity just as you register the second of them". Which is 
still a bug, of course - it's just not ever going to bite anybody in 
practice.

		Linus

---
 fs/readdir.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/readdir.c b/fs/readdir.c
index 7723401..431f647 100644
--- a/fs/readdir.c
+++ b/fs/readdir.c
@@ -172,7 +172,7 @@ static int filldir(void * __buf, const char * name, int namlen, loff_t offset,
 		goto efault;
 	if (__put_user(reclen, &dirent->d_reclen))
 		goto efault;
-	if (copy_to_user(dirent->d_name, name, namlen))
+	if (__copy_to_user_inatomic(dirent->d_name, name, namlen))
 		goto efault;
 	if (__put_user(0, dirent->d_name + namlen))
 		goto efault;
@@ -256,7 +256,7 @@ static int filldir64(void * __buf, const char * name, int namlen, loff_t offset,
 		goto efault;
 	if (__put_user(d_type, &dirent->d_type))
 		goto efault;
-	if (copy_to_user(dirent->d_name, name, namlen))
+	if (__copy_to_user_inatomic(dirent->d_name, name, namlen))
 		goto efault;
 	if (__put_user(0, dirent->d_name + namlen))
 		goto efault;

Re: [Linux-fbdev-devel] [PATCH] add mutex to fbdev for fb_mmap locking

[Krzysztof H. <krz...@po...>]

On Sun, 31 May 2009 10:09:01 -0700 (PDT)
Linus Torvalds <tor...@li...> wrote:

> 
> 
> On Sun, 31 May 2009, Krzysztof Helt wrote:
> >  
> >  static int atafb_get_fix(struct fb_fix_screeninfo *fix, struct fb_info *info)
> > +__acquires(&info->mm_lock)
> > +__releases(&info->mm_lock)
> 
> Btw, you shouldn't do this when things nest "correctly" - sparse will see 
> the fact that the function acquires and releases a lock and is perfectly 
> happy.
> 

I will fix it. 
If the revert to BKL is rejected this patch may wait till 2.6.31.

Regards,
Krzysztof

Re: [Linux-fbdev-devel] Question about radeon 3000 driver

[Alex D. <ale...@gm...>]

On Mon, Jun 1, 2009 at 11:13 AM, Stelios Xanthakis
<sx...@ce...> wrote:
> Hi.
>
> I have a PC with an integrated radeon 3000 gfx card
> (pci id 9616) and I'd really like to be able to use
> the linux framebuffer with a proper driver because
> vesafb has all sorts of problems.
>
> I plan to start with the usual procedure of copying
> stuff from the xf86-video-ati drivers, since this
> card is already supported by xf86-video-ati-12.
>
> The question is, are there any pending patches for
> the radeon drivers, or git trees that may have
> relevant work for the R600 chipsets?

Support for modesetting and hence fb devices is being added to the radeon drm:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-rawhide
http://cgit.freedesktop.org/~glisse/drm-next/log/?h=drm-next-radeon

We hope to get support for r1xx-r5xx chips into 2.6.31.  Modesetting
support for r6xx/r7xx chips is already in place, but they are still
missing some memory management bits.

Alex