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

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

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

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.

Kind 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

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

[Stelios X. <sx...@ce...>]

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?

Thanks,

Stelios

Re: [Linux-fbdev-devel] [PATCH 05/10] ARM: OMAP1: Make 770 LCD work

[Kalle V. <kal...@ik...>]

Andrew de Quincey <ad...@li...> writes:

> Out of interest, what is the best practice way to pass platform
> specific GPIOs around? There are a number of other n770 related
> drivers I'm intending on cleaning up, several of which have GPIO
> numbers hardcoded in them. Should these be passed in platform
> structures, or is there something analogous to the clk_alias for
> GPIOs?

I was told that platform structures are the preferred way. For wl12xx (a
wi-fi driver) I created a set_power function pointer which will control
the power gpio line:

27 struct wl12xx_platform_data {
28         void (*set_power)(bool enable);
29 };

http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=blob;f=include/linux/spi/wl12xx.h;h=11430cab2aad71242946ebfc7c0ce778d8bf26a1;hb=HEAD

And the irq is configured in the board file and provided to wl12xx with
struct spi_device.irq. So wl12xx doesn't use gpio code at all, it's all
done in the board file. 

Please comment if this isn't the correct way to do this.

-- 
Kalle Valo

Re: [Linux-fbdev-devel] aty128fb artifacts

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

On Mon, Jun 1, 2009 at 3:07 AM, Jonathan Nieder <jrn...@gm...> wrote:

> I am interested to hear your thoughts. So far, I have found no
> documentation on the Rage M3's internals so I am clueless when faced
> with all these symptoms.

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/

Alex

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

[Giuseppe C. <cj...@cr...>]

Il giorno sab, 30/05/2009 alle 13.42 +0200, Krzysztof Helt ha scritto:
> On Wed, 27 May 2009 20:57:55 +0200
> Giuseppe Coviello <cj...@cr...> wrote:
> 
> > This patch adds support for GXT4000P and GXT6500P cards found on some
> > IBM pSeries machines.
> > GXT4000P/6000P and GXT4500P/6500P  couples are  identical from
> > software's point of view and are based on the same  Raster Engine
> > (RC1000), except for a different reference clock for the PLL.
> > GXT6x00P models are equipped with an additional Geometry Engine
> > (GT1000) but this driver doesn't use it.
> > 
> > Regards, Giuseppe
> > 
> > 
> 
> Please also change name of the option to reflect the fact it supports
> more than just the GXT4500P, e.g.
> 
> "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
> 
> Please cc the updated patch to the lin...@oz....
> 
> Regards,
> Krzysztof

I've made the changes that you have suggested.

Regards, Giuseppe

Signed-off-by: Nico Macrionitis <ac...@cr...>
Signed-off-by: Giuseppe Coviello <cj...@cr...>
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>]\"");

[Linux-fbdev-devel] aty128fb artifacts

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

Hi fbdev developers,

On the laptop I use, the built-in display is a single-resolution
1024x768 TFT, and the imperfect anti-aliasing makes it much harder to
read text in the standard console than in X. I decided to try out
fbcon so the console could have the appropriate resolution. Eventually
I should learn to switch resolutions, but first I would like to report
the quirks I have noticed so far. I am not knowledgeable enough to
know what should trouble me and what is normal.

The laptop is an Inspiron 4000, the video card a Rage Mobility M3 AGP
2x [1002:4c46], and the display a Samsung LT141X8-L02. The kernel is
Linus's v2.6.30-rc7-11-ga0c1af1, plus some wireless fixes.  I tested
by running "modprobe aty128fb" and then "modprobe fbcon" and was
impressed to see the console usable right away. But:

 * A sort of gray stripe with vertical bands of various shades of gray
was present on the bottom quarter-centimeter of the screen.  When I
switched consoles, let the screen blank and wake up, switched to X and
back, and so on, the color of the bands would change (sometimes red or
green, different greys, ...).

 * There were black horizontal stripes through the (gpm) mouse block
cursor whenever I moved it.  They would go away once the mouse stopped
moving.

 * When I tried "fbset -xres 1024 -yres 768 -depth 16" (presumably
this was a bad idea), a few vertical bands covering the entire height
of the screen blinked black, then green, then black, then various
colors. I quickly rebooted after that.

 * After a soft reboot (back to vgacon), the console was mostly back
to normal but something had happened to the cursor. The usual blinking
underline was present until the cursor reached the bottom of the
screen and then it disappeared.  Clearing the screen with ^L resulted
in the cursor appearing approx halfway down.  I needed a cold boot to
get the cursor back to normal. This same effect occurs whenever I load
aty128fb and fbcon and soft reboot.

 * When I tried "fbset 1024x768", a sort of speckled glow appeared in
the middle of the screen and spread out, and I quickly rebooted.

 * With X driver "fbdev", the resolution was still 640x480 (I think),
but the screen looked very strange. The virtual desktop was squished
horizontally to leave about an inch to the right entirely black except
at the bottom.  The grey rectangle at the bottom of approx a half a cm
was still present, covering the entire width of the display. With my X
setup, when X starts there is only a red border surrounding a black
terminal. The grey rectangle appeared to reflect that border, with a
vertical red band 1 pixel to the left of the right edge of the red
rectangle.

 * When switching from VT6 (fbcon) to VT7 (X with fbdev driver) the
text turned blue before the X desktop was shown. It was nice to see
that the switch was smooth aside from that, since there are normally
artifacts when I switch between vgacon and X with the r128 driver.

I had no success unloading the fbcon driver. "vbetool vbestate
restore" with state from the VGA console mangled the screen; switching
to X and back revealed that it had output the text "Function not
supported."

I am interested to hear your thoughts. So far, I have found no
documentation on the Rage M3's internals so I am clueless when faced
with all these symptoms.

Regards,
Jonathan

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

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

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.

The extra annotations are helpful only if you have a function that does 
something _unexpected_ to a lock, like first releasing it and then 
re-aqcuiring it, or releasing it without acquiring it at all. Then the 
extra annotations (a) tell sparse not to complain about odd locking, and 
(b) act as visual notification to users that this function drops a lock in 
the middle.

I haven't actually looked at the patch yet, I just reacted to this part of 
it.

		Linus

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

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

From: Krzysztof Helt <krz...@wp...>

Add a mutex to avoid a circular locking problem between the mm layer semaphore 
and fbdev ioctl mutex through the fb_mmap() call.

Also, add mutex to all places where smem_start and smem_len fields change
so the mutex inside the fb_mmap() is actually used. Changing of these fields
before calling the framebuffer_register() are not mutexed.

Signed-off-by: Krzysztof Helt <krz...@wp...>
---
This is the promised patch.

Please decide if this is 2.6.30 material or not. It removes one lockdep (fb_mmap()
and register_framebuffer()) but there is still another one (fb_release() and register_framebuffer()).
It also cleans up handling of the smem_start and smem_len fields used by mutexed 
section of the fb_mmap().

Kind regards,
Krzysztof

diff --git a/drivers/video/atafb.c b/drivers/video/atafb.c
index 018850c..c6f43c3 100644
--- a/drivers/video/atafb.c
+++ b/drivers/video/atafb.c
@@ -2406,6 +2406,8 @@ static int do_fb_set_var(struct fb_var_screeninfo *var, int isactive)
 }
 
 static int atafb_get_fix(struct fb_fix_screeninfo *fix, struct fb_info *info)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct atafb_par par;
 	int err;
@@ -2414,7 +2416,10 @@ static int atafb_get_fix(struct fb_fix_screeninfo *fix, struct fb_info *info)
 	if (err)
 		return err;
 	memset(fix, 0, sizeof(struct fb_fix_screeninfo));
-	return fbhw->encode_fix(fix, &par);
+	mutex_lock(&info->mm_lock);
+	err = fbhw->encode_fix(fix, &par);
+	mutex_unlock(&info->mm_lock);
+	return err;
 }
 
 static int atafb_get_var(struct fb_var_screeninfo *var, struct fb_info *info)
@@ -2738,12 +2743,16 @@ static int atafb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
 	/* actually set hw par by decoding var, then setting hardware from
 	 * hw par just decoded */
 static int atafb_set_par(struct fb_info *info)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct atafb_par *par = (struct atafb_par *)info->par;
 
 	/* Decode wanted screen parameters */
 	fbhw->decode_var(&info->var, par);
+	mutex_lock(&info->mm_lock);
 	fbhw->encode_fix(&info->fix, par);
+	mutex_unlock(&info->mm_lock);
 
 	/* Set new videomode */
 	ata_set_par(par);
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 2fb63f6..40eb1b4 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -263,6 +263,8 @@ static inline void atmel_lcdfb_free_video_memory(struct atmel_lcdfb_info *sinfo)
  *	@sinfo: the frame buffer to allocate memory for
  */
 static int atmel_lcdfb_alloc_video_memory(struct atmel_lcdfb_info *sinfo)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct fb_info *info = sinfo->info;
 	struct fb_var_screeninfo *var = &info->var;
@@ -270,7 +272,9 @@ static int atmel_lcdfb_alloc_video_memory(struct atmel_lcdfb_info *sinfo)
 
 	smem_len = (var->xres_virtual * var->yres_virtual
 		    * ((var->bits_per_pixel + 7) / 8));
+	mutex_lock(&info->mm_lock);
 	info->fix.smem_len = max(smem_len, sinfo->smem_len);
+	mutex_unlock(&info->mm_lock);
 
 	info->screen_base = dma_alloc_writecombine(info->device, info->fix.smem_len,
 					(dma_addr_t *)&info->fix.smem_start, GFP_KERNEL);
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index d412a1d..c173683 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1310,8 +1310,8 @@ static long fb_compat_ioctl(struct file *file, unsigned int cmd,
 
 static int
 fb_mmap(struct file *file, struct vm_area_struct * vma)
-__acquires(&info->lock)
-__releases(&info->lock)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	int fbidx = iminor(file->f_path.dentry->d_inode);
 	struct fb_info *info = registered_fb[fbidx];
@@ -1325,16 +1325,14 @@ __releases(&info->lock)
 	off = vma->vm_pgoff << PAGE_SHIFT;
 	if (!fb)
 		return -ENODEV;
+	mutex_lock(&info->mm_lock);
 	if (fb->fb_mmap) {
 		int res;
-		mutex_lock(&info->lock);
 		res = fb->fb_mmap(info, vma);
-		mutex_unlock(&info->lock);
+		mutex_unlock(&info->mm_lock);
 		return res;
 	}
 
-	mutex_lock(&info->lock);
-
 	/* frame buffer memory */
 	start = info->fix.smem_start;
 	len = PAGE_ALIGN((start & ~PAGE_MASK) + info->fix.smem_len);
@@ -1342,13 +1340,13 @@ __releases(&info->lock)
 		/* memory mapped io */
 		off -= len;
 		if (info->var.accel_flags) {
-			mutex_unlock(&info->lock);
+			mutex_unlock(&info->mm_lock);
 			return -EINVAL;
 		}
 		start = info->fix.mmio_start;
 		len = PAGE_ALIGN((start & ~PAGE_MASK) + info->fix.mmio_len);
 	}
-	mutex_unlock(&info->lock);
+	mutex_unlock(&info->mm_lock);
 	start &= PAGE_MASK;
 	if ((vma->vm_end - vma->vm_start + off) > len)
 		return -EINVAL;
@@ -1491,6 +1489,7 @@ register_framebuffer(struct fb_info *fb_info)
 			break;
 	fb_info->node = i;
 	mutex_init(&fb_info->lock);
+	mutex_init(&fb_info->mm_lock);
 
 	fb_info->dev = device_create(fb_class, fb_info->device,
 				     MKDEV(FB_MAJOR, i), NULL, "fb%d", i);
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index f153c58..ca664f5 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -748,37 +748,45 @@ static void update_lcdc(struct fb_info *info)
 }
 
 static int map_video_memory(struct fb_info *info)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	phys_addr_t phys;
+	u32 smem_len = info->fix.line_length * info->var.yres_virtual;
 
 	pr_debug("info->var.xres_virtual = %d\n", info->var.xres_virtual);
 	pr_debug("info->var.yres_virtual = %d\n", info->var.yres_virtual);
 	pr_debug("info->fix.line_length  = %d\n", info->fix.line_length);
+	pr_debug("MAP_VIDEO_MEMORY: smem_len = %u\n", smem_len);
 
-	info->fix.smem_len = info->fix.line_length * info->var.yres_virtual;
-	pr_debug("MAP_VIDEO_MEMORY: smem_len = %d\n", info->fix.smem_len);
-	info->screen_base = fsl_diu_alloc(info->fix.smem_len, &phys);
+	info->screen_base = fsl_diu_alloc(smem_len, &phys);
 	if (info->screen_base == NULL) {
 		printk(KERN_ERR "Unable to allocate fb memory\n");
 		return -ENOMEM;
 	}
+	mutex_lock(&info->mm_lock);
 	info->fix.smem_start = (unsigned long) phys;
+	info->fix.smem_len = smem_len;
+	mutex_unlock(&info->mm_lock);
 	info->screen_size = info->fix.smem_len;
 
 	pr_debug("Allocated fb @ paddr=0x%08lx, size=%d.\n",
-				info->fix.smem_start,
-		info->fix.smem_len);
+		 info->fix.smem_start, info->fix.smem_len);
 	pr_debug("screen base %p\n", info->screen_base);
 
 	return 0;
 }
 
 static void unmap_video_memory(struct fb_info *info)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	fsl_diu_free(info->screen_base, info->fix.smem_len);
+	mutex_lock(&info->mm_lock);
 	info->screen_base = NULL;
 	info->fix.smem_start = 0;
 	info->fix.smem_len = 0;
+	mutex_unlock(&info->mm_lock);
 }
 
 /*
diff --git a/drivers/video/i810/i810_main.c b/drivers/video/i810/i810_main.c
index 2e94019..fac172d 100644
--- a/drivers/video/i810/i810_main.c
+++ b/drivers/video/i810/i810_main.c
@@ -1084,14 +1084,18 @@ static int i810_check_params(struct fb_var_screeninfo *var,
  * This will set up parameters that are unmodifiable by the user.
  */
 static int encode_fix(struct fb_fix_screeninfo *fix, struct fb_info *info)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct i810fb_par *par = info->par;
 
     	memset(fix, 0, sizeof(struct fb_fix_screeninfo));
 
     	strcpy(fix->id, "I810");
+	mutex_lock(&info->mm_lock);
     	fix->smem_start = par->fb.physical;
     	fix->smem_len = par->fb.size;
+	mutex_unlock(&info->mm_lock);
     	fix->type = FB_TYPE_PACKED_PIXELS;
     	fix->type_aux = 0;
 	fix->xpanstep = 8;
diff --git a/drivers/video/matrox/matroxfb_base.c b/drivers/video/matrox/matroxfb_base.c
index 8e7a275..b6bf28f 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -720,12 +720,16 @@ static void matroxfb_init_fix(WPMINFO2)
 }
 
 static void matroxfb_update_fix(WPMINFO2)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct fb_fix_screeninfo *fix = &ACCESS_FBINFO(fbcon).fix;
 	DBG(__func__)
 
+	mutex_lock(&ACCESS_FBINFO(fbcon).mm_lock);
 	fix->smem_start = ACCESS_FBINFO(video.base) + ACCESS_FBINFO(curr.ydstorg.bytes);
 	fix->smem_len = ACCESS_FBINFO(video.len_usable) - ACCESS_FBINFO(curr.ydstorg.bytes);
+	mutex_unlock(&ACCESS_FBINFO(fbcon).mm_lock);
 }
 
 static int matroxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
@@ -2081,6 +2085,7 @@ static int matroxfb_probe(struct pci_dev* pdev, const struct pci_device_id* dumm
 	spin_lock_init(&ACCESS_FBINFO(lock.accel));
 	init_rwsem(&ACCESS_FBINFO(crtc2.lock));
 	init_rwsem(&ACCESS_FBINFO(altout.lock));
+	mutex_init(&ACCESS_FBINFO(fbcon).mm_lock);
 	ACCESS_FBINFO(irq_flags) = 0;
 	init_waitqueue_head(&ACCESS_FBINFO(crtc1.vsync.wait));
 	init_waitqueue_head(&ACCESS_FBINFO(crtc2.vsync.wait));
diff --git a/drivers/video/matrox/matroxfb_crtc2.c b/drivers/video/matrox/matroxfb_crtc2.c
index 7ac4c5f..7ad14d0 100644
--- a/drivers/video/matrox/matroxfb_crtc2.c
+++ b/drivers/video/matrox/matroxfb_crtc2.c
@@ -289,13 +289,18 @@ static int matroxfb_dh_release(struct fb_info* info, int user) {
 #undef m2info
 }
 
-static void matroxfb_dh_init_fix(struct matroxfb_dh_fb_info *m2info) {
+static void matroxfb_dh_init_fix(struct matroxfb_dh_fb_info *m2info)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
+{
 	struct fb_fix_screeninfo *fix = &m2info->fbcon.fix;
 
 	strcpy(fix->id, "MATROX DH");
 
+	mutex_lock(&m2info->fbcon.mm_lock);
 	fix->smem_start = m2info->video.base;
 	fix->smem_len = m2info->video.len_usable;
+	mutex_unlock(&m2info->fbcon.mm_lock);
 	fix->ypanstep = 1;
 	fix->ywrapstep = 0;
 	fix->xpanstep = 8;	/* TBD */
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index 9894de1..fb57795 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -669,7 +669,7 @@ static uint32_t bpp_to_pixfmt(int bpp)
 }
 
 static int mx3fb_blank(int blank, struct fb_info *fbi);
-static int mx3fb_map_video_memory(struct fb_info *fbi);
+static int mx3fb_map_video_memory(struct fb_info *fbi, unsigned int mem_len);
 static int mx3fb_unmap_video_memory(struct fb_info *fbi);
 
 /**
@@ -742,8 +742,7 @@ static int mx3fb_set_par(struct fb_info *fbi)
 		if (fbi->fix.smem_start)
 			mx3fb_unmap_video_memory(fbi);
 
-		fbi->fix.smem_len = mem_len;
-		if (mx3fb_map_video_memory(fbi) < 0) {
+		if (mx3fb_map_video_memory(fbi, mem_len) < 0) {
 			mutex_unlock(&mx3_fbi->mutex);
 			return -ENOMEM;
 		}
@@ -1198,6 +1197,7 @@ static int mx3fb_resume(struct platform_device *pdev)
 /**
  * mx3fb_map_video_memory() - allocates the DRAM memory for the frame buffer.
  * @fbi:	framebuffer information pointer
+ * @mem_len:	length of mapped memory
  * @return:	Error code indicating success or failure
  *
  * This buffer is remapped into a non-cached, non-buffered, memory region to
@@ -1205,23 +1205,28 @@ static int mx3fb_resume(struct platform_device *pdev)
  * area is remapped, all virtual memory access to the video memory should occur
  * at the new region.
  */
-static int mx3fb_map_video_memory(struct fb_info *fbi)
+static int mx3fb_map_video_memory(struct fb_info *fbi, unsigned int mem_len)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	int retval = 0;
 	dma_addr_t addr;
 
 	fbi->screen_base = dma_alloc_writecombine(fbi->device,
-						  fbi->fix.smem_len,
+						  mem_len,
 						  &addr, GFP_DMA);
 
 	if (!fbi->screen_base) {
 		dev_err(fbi->device, "Cannot allocate %u bytes framebuffer memory\n",
-			fbi->fix.smem_len);
+			mem_len);
 		retval = -EBUSY;
 		goto err0;
 	}
 
+	mutex_lock(&fbi->mm_lock);
 	fbi->fix.smem_start = addr;
+	fbi->fix.smem_len = mem_len;
+	mutex_unlock(&fbi->mm_lock);
 
 	dev_dbg(fbi->device, "allocated fb @ p=0x%08x, v=0x%p, size=%d.\n",
 		(uint32_t) fbi->fix.smem_start, fbi->screen_base, fbi->fix.smem_len);
@@ -1246,13 +1251,17 @@ err0:
  * @return:	error code indicating success or failure
  */
 static int mx3fb_unmap_video_memory(struct fb_info *fbi)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	dma_free_writecombine(fbi->device, fbi->fix.smem_len,
 			      fbi->screen_base, fbi->fix.smem_start);
 
 	fbi->screen_base = 0;
+	mutex_lock(&fbi->mm_lock);
 	fbi->fix.smem_start = 0;
 	fbi->fix.smem_len = 0;
+	mutex_unlock(&fbi->mm_lock);
 	return 0;
 }
 
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 060d72f..eccf4bd 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -384,6 +384,8 @@ static void omapfb_sync(struct fb_info *fbi)
  * When calling this fb_info.var must be set up already.
  */
 static void set_fb_fix(struct fb_info *fbi)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct fb_fix_screeninfo *fix = &fbi->fix;
 	struct fb_var_screeninfo *var = &fbi->var;
@@ -393,8 +395,10 @@ static void set_fb_fix(struct fb_info *fbi)
 
 	rg = &plane->fbdev->mem_desc.region[plane->idx];
 	fbi->screen_base	= rg->vaddr;
+	mutex_lock(&fbi->mm_lock);
 	fix->smem_start		= rg->paddr;
 	fix->smem_len		= rg->size;
+	mutex_unlock(&fbi->mm_lock);
 
 	fix->type = FB_TYPE_PACKED_PIXELS;
 	bpp = var->bits_per_pixel;
@@ -824,6 +828,8 @@ static int omapfb_query_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
 }
 
 static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct omapfb_plane_struct *plane = fbi->par;
 	struct omapfb_device *fbdev = plane->fbdev;
@@ -886,8 +892,10 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
 				 * plane memory is dealloce'd, the other
 				 * screen parameters in var / fix are invalid.
 				 */
+				mutex_lock(&fbi->mm_lock);
 				fbi->fix.smem_start = 0;
 				fbi->fix.smem_len = 0;
+				mutex_unlock(&fbi->mm_lock);
 			}
 		}
 	}
diff --git a/drivers/video/platinumfb.c b/drivers/video/platinumfb.c
index 03b3670..1600ee7 100644
--- a/drivers/video/platinumfb.c
+++ b/drivers/video/platinumfb.c
@@ -122,6 +122,8 @@ static int platinumfb_check_var (struct fb_var_screeninfo *var, struct fb_info *
  * Applies current var to display
  */
 static int platinumfb_set_par (struct fb_info *info)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct fb_info_platinum *pinfo = info->par;
 	struct platinum_regvals *init;
@@ -141,7 +143,9 @@ static int platinumfb_set_par (struct fb_info *info)
   		offset = 0x10;
 
 	info->screen_base = pinfo->frame_buffer + init->fb_offset + offset;
+	mutex_lock(&info->mm_lock);
 	info->fix.smem_start = (pinfo->frame_buffer_phys) + init->fb_offset + offset;
+	mutex_unlock(&info->mm_lock);
 	info->fix.visual = (pinfo->cmode == CMODE_8) ?
 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
  	info->fix.line_length = vmode_attrs[pinfo->vmode-1].hres * (1<<pinfo->cmode)
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 0889d50..140c692 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -783,6 +783,8 @@ static int overlayfb_check_var(struct fb_var_screeninfo *var,
 }
 
 static int overlayfb_map_video_memory(struct pxafb_layer *ofb)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct fb_var_screeninfo *var = &ofb->fb.var;
 	int pfor = NONSTD_TO_PFOR(var->nonstd);
@@ -815,8 +817,10 @@ static int overlayfb_map_video_memory(struct pxafb_layer *ofb)
 	ofb->video_mem_phys = virt_to_phys(ofb->video_mem);
 	ofb->video_mem_size = size;
 
+	mutex_lock(&ofb->fb.mm_lock);
 	ofb->fb.fix.smem_start	= ofb->video_mem_phys;
 	ofb->fb.fix.smem_len	= ofb->fb.fix.line_length * var->yres_virtual;
+	mutex_unlock(&ofb->fb.mm_lock);
 	ofb->fb.screen_base	= ofb->video_mem;
 	return 0;
 }
diff --git a/drivers/video/sh7760fb.c b/drivers/video/sh7760fb.c
index 653bdfe..9f6d6e6 100644
--- a/drivers/video/sh7760fb.c
+++ b/drivers/video/sh7760fb.c
@@ -120,18 +120,6 @@ static int sh7760_setcolreg (u_int regno,
 	return 0;
 }
 
-static void encode_fix(struct fb_fix_screeninfo *fix, struct fb_info *info,
-		       unsigned long stride)
-{
-	memset(fix, 0, sizeof(struct fb_fix_screeninfo));
-	strcpy(fix->id, "sh7760-lcdc");
-
-	fix->smem_start = (unsigned long)info->screen_base;
-	fix->smem_len = info->screen_size;
-
-	fix->line_length = stride;
-}
-
 static int sh7760fb_get_color_info(struct device *dev,
 				   u16 lddfr, int *bpp, int *gray)
 {
@@ -334,7 +322,8 @@ static int sh7760fb_set_par(struct fb_info *info)
 
 	iowrite32(ldsarl, par->base + LDSARL);	/* mem for lower half of DSTN */
 
-	encode_fix(&info->fix, info, stride);
+	info->fix.line_length = stride;
+
 	sh7760fb_check_var(&info->var, info);
 
 	sh7760fb_blank(FB_BLANK_UNBLANK, info);	/* panel on! */
@@ -435,6 +424,8 @@ static int sh7760fb_alloc_mem(struct fb_info *info)
 
 	info->screen_base = fbmem;
 	info->screen_size = vram;
+	info->fix.smem_start = (unsigned long)info->screen_base;
+	info->fix.smem_len = info->screen_size;
 
 	return 0;
 }
@@ -520,6 +511,8 @@ static int __devinit sh7760fb_probe(struct platform_device *pdev)
 	info->var.transp.length = 0;
 	info->var.transp.msb_right = 0;
 
+	strcpy(info->fix.id, "sh7760-lcdc");
+
 	/* set the DON2 bit now, before cmap allocation, as it will randomize
 	 * palette memory.
 	 */
diff --git a/drivers/video/sis/sis_main.c b/drivers/video/sis/sis_main.c
index 7e17ee9..59f5faf 100644
--- a/drivers/video/sis/sis_main.c
+++ b/drivers/video/sis/sis_main.c
@@ -1840,6 +1840,8 @@ static int	sisfb_ioctl(struct fb_info *info, unsigned int cmd,
 
 static int
 sisfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct fb_info *info)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct sis_video_info *ivideo = (struct sis_video_info *)info->par;
 
@@ -1847,8 +1849,10 @@ sisfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct fb_info *info)
 
 	strcpy(fix->id, ivideo->myid);
 
+	mutex_lock(&info->mm_lock);
 	fix->smem_start  = ivideo->video_base + ivideo->video_offset;
 	fix->smem_len    = ivideo->sisfb_mem;
+	mutex_unlock(&info->mm_lock);
 	fix->type        = FB_TYPE_PACKED_PIXELS;
 	fix->type_aux    = 0;
 	fix->visual      = (ivideo->video_bpp == 8) ? FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
index eb5d73a..1285b70 100644
--- a/drivers/video/sm501fb.c
+++ b/drivers/video/sm501fb.c
@@ -145,7 +145,7 @@ static inline void sm501fb_sync_regs(struct sm501fb_info *info)
 #define SM501_MEMF_ACCEL		(8)
 
 static int sm501_alloc_mem(struct sm501fb_info *inf, struct sm501_mem *mem,
-			   unsigned int why, size_t size)
+			   unsigned int why, size_t size, u32 smem_len)
 {
 	struct sm501fb_par *par;
 	struct fb_info *fbi;
@@ -172,7 +172,7 @@ static int sm501_alloc_mem(struct sm501fb_info *inf, struct sm501_mem *mem,
 		if (ptr > 0)
 			ptr &= ~(PAGE_SIZE - 1);
 
-		if (fbi && ptr < fbi->fix.smem_len)
+		if (fbi && ptr < smem_len)
 			return -ENOMEM;
 
 		break;
@@ -197,7 +197,7 @@ static int sm501_alloc_mem(struct sm501fb_info *inf, struct sm501_mem *mem,
 
 	case SM501_MEMF_ACCEL:
 		fbi = inf->fb[HEAD_CRT];
-		ptr = fbi ? fbi->fix.smem_len : 0;
+		ptr = fbi ? smem_len : 0;
 
 		fbi = inf->fb[HEAD_PANEL];
 		if (fbi) {
@@ -405,6 +405,8 @@ static int sm501fb_check_var_pnl(struct fb_var_screeninfo *var,
 
 static int sm501fb_set_par_common(struct fb_info *info,
 				  struct fb_var_screeninfo *var)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct sm501fb_par  *par = info->par;
 	struct sm501fb_info *fbi = par->info;
@@ -413,6 +415,7 @@ static int sm501fb_set_par_common(struct fb_info *info,
 	unsigned int mem_type;
 	unsigned int clock_type;
 	unsigned int head_addr;
+	unsigned int smem_len;
 
 	dev_dbg(fbi->dev, "%s: %dx%d, bpp = %d, virtual %dx%d\n",
 		__func__, var->xres, var->yres, var->bits_per_pixel,
@@ -453,18 +456,20 @@ static int sm501fb_set_par_common(struct fb_info *info,
 
 	/* allocate fb memory within 501 */
 	info->fix.line_length = (var->xres_virtual * var->bits_per_pixel)/8;
-	info->fix.smem_len    = info->fix.line_length * var->yres_virtual;
+	smem_len = info->fix.line_length * var->yres_virtual;
 
 	dev_dbg(fbi->dev, "%s: line length = %u\n", __func__,
 		info->fix.line_length);
 
-	if (sm501_alloc_mem(fbi, &par->screen, mem_type,
-			    info->fix.smem_len)) {
+	if (sm501_alloc_mem(fbi, &par->screen, mem_type, smem_len, smem_len)) {
 		dev_err(fbi->dev, "no memory available\n");
 		return -ENOMEM;
 	}
 
+	mutex_lock(&info->mm_lock);
 	info->fix.smem_start = fbi->fbmem_res->start + par->screen.sm_addr;
+	info->fix.smem_len   = smem_len;
+	mutex_unlock(&info->mm_lock);
 
 	info->screen_base = fbi->fbmem + par->screen.sm_addr;
 	info->screen_size = info->fix.smem_len;
@@ -637,7 +642,8 @@ static int sm501fb_set_par_crt(struct fb_info *info)
 	if ((control & SM501_DC_CRT_CONTROL_SEL) == 0) {
 		/* the head is displaying panel data... */
 
-		sm501_alloc_mem(fbi, &par->screen, SM501_MEMF_CRT, 0);
+		sm501_alloc_mem(fbi, &par->screen, SM501_MEMF_CRT, 0,
+				info->fix.smem_len);
 		goto out_update;
 	}
 
@@ -1289,7 +1295,8 @@ static int sm501_init_cursor(struct fb_info *fbi, unsigned int reg_base)
 
 	par->cursor_regs = info->regs + reg_base;
 
-	ret = sm501_alloc_mem(info, &par->cursor, SM501_MEMF_CURSOR, 1024);
+	ret = sm501_alloc_mem(info, &par->cursor, SM501_MEMF_CURSOR, 1024,
+			      fbi->fix.smem_len);
 	if (ret < 0)
 		return ret;
 
diff --git a/drivers/video/w100fb.c b/drivers/video/w100fb.c
index d0674f1..05356d3 100644
--- a/drivers/video/w100fb.c
+++ b/drivers/video/w100fb.c
@@ -510,6 +510,8 @@ static int w100fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
  *  by looking at the values in info.var
  */
 static int w100fb_set_par(struct fb_info *info)
+__acquires(&info->mm_lock)
+__releases(&info->mm_lock)
 {
 	struct w100fb_par *par=info->par;
 
@@ -523,6 +525,7 @@ static int w100fb_set_par(struct fb_info *info)
 		info->fix.ywrapstep = 0;
 		info->fix.line_length = par->xres * BITS_PER_PIXEL / 8;
 
+		mutex_lock(&info->mm_lock);
 		if ((par->xres*par->yres*BITS_PER_PIXEL/8) > (MEM_INT_SIZE+1)) {
 			par->extmem_active = 1;
 			info->fix.smem_len = par->mach->mem->size+1;
@@ -530,6 +533,7 @@ static int w100fb_set_par(struct fb_info *info)
 			par->extmem_active = 0;
 			info->fix.smem_len = MEM_INT_SIZE+1;
 		}
+		mutex_unlock(&info->mm_lock);
 
 		w100fb_activate_var(par);
 	}
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 330c4b1..89a4d91 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -814,6 +814,7 @@ struct fb_info {
 	int node;
 	int flags;
 	struct mutex lock;		/* Lock for open/release/ioctl funcs */
+	struct mutex mm_lock;		/* Lock for fb_mmap and smem_* fields */
 	struct fb_var_screeninfo var;	/* Current var */
 	struct fb_fix_screeninfo fix;	/* Current fix */
 	struct fb_monspecs monspecs;	/* Current Monitor specs */

----------------------------------------------------------------------
Kup wlasne mieszkanie za 33 tys. zl.
Sprawdz >>> http://link.interia.pl/f21a3

[Linux-fbdev-devel] [PATCH] fbdev: use framebuffer_relase for freeing fb_info structures

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

From: Krzysztof Helt <krz...@wp...>

Use the framebuffer_relase() for freeing fb_info structures
allocated with framebuffer_alloc().

Signed-off-by: Krzysztof Helt <krz...@wp...>
---

This is just a clean up. The patch does not fix any existing bugs. 
It is not for the 2.6.30 release.

 drivers/video/offb.c         |    2 +-
 drivers/video/pm2fb.c        |    2 +-
 drivers/video/sis/sis_main.c |    4 ++--
 drivers/video/stifb.c        |    2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/video/offb.c b/drivers/video/offb.c
index bb915a4..4d8c54c 100644
--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -493,7 +493,7 @@ static void __init offb_init_fb(const char *name, const char *full_name,
 		iounmap(par->cmap_adr);
 		par->cmap_adr = NULL;
 		iounmap(info->screen_base);
-		kfree(info);
+		framebuffer_release(info);
 		release_mem_region(res_start, res_size);
 		return;
 	}
diff --git a/drivers/video/pm2fb.c b/drivers/video/pm2fb.c
index c6dd924..36436ee 100644
--- a/drivers/video/pm2fb.c
+++ b/drivers/video/pm2fb.c
@@ -1748,7 +1748,7 @@ static void __devexit pm2fb_remove(struct pci_dev *pdev)
 	pci_set_drvdata(pdev, NULL);
 	fb_dealloc_cmap(&info->cmap);
 	kfree(info->pixmap.addr);
-	kfree(info);
+	framebuffer_release(info);
 }
 
 static struct pci_device_id pm2fb_id_table[] = {
diff --git a/drivers/video/sis/sis_main.c b/drivers/video/sis/sis_main.c
index 7e17ee9..7072d19 100644
--- a/drivers/video/sis/sis_main.c
+++ b/drivers/video/sis/sis_main.c
@@ -5928,7 +5928,7 @@ sisfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 		if(pci_enable_device(pdev)) {
 			if(ivideo->nbridge) pci_dev_put(ivideo->nbridge);
 			pci_set_drvdata(pdev, NULL);
-			kfree(sis_fb_info);
+			framebuffer_release(sis_fb_info);
 			return -EIO;
 		}
 	}
@@ -6134,7 +6134,7 @@ error_3:	vfree(ivideo->bios_abase);
 		pci_set_drvdata(pdev, NULL);
 		if(!ivideo->sisvga_enabled)
 			pci_disable_device(pdev);
-		kfree(sis_fb_info);
+		framebuffer_release(sis_fb_info);
 		return ret;
 	}
 
diff --git a/drivers/video/stifb.c b/drivers/video/stifb.c
index eabaad7..d25c75c 100644
--- a/drivers/video/stifb.c
+++ b/drivers/video/stifb.c
@@ -1380,7 +1380,7 @@ stifb_cleanup(void)
 				if (info->screen_base)
 					iounmap(info->screen_base);
 		        fb_dealloc_cmap(&info->cmap);
-		        kfree(info); 
+		        framebuffer_release(info); 
 		}
 		sti->info = NULL;
 	}
-- 
1.6.0.3


----------------------------------------------------------------------
Apartamenty z widokiem na morze!
Sprawdz >>> http://link.interia.pl/f21a4

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

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

From: Krzysztof Helt <krz...@wp...>

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.

Please test it.

diff -urp linux-ref/drivers/video/intelfb/intelfbdrv.c linux-2.6.30-rc7/drivers/video/intelfb/intelfbdrv.c
--- linux-ref/drivers/video/intelfb/intelfbdrv.c	2009-05-23 23:47:00.000000000 +0200
+++ linux-2.6.30-rc7/drivers/video/intelfb/intelfbdrv.c	2009-05-29 07:37:27.000000000 +0200
@@ -874,6 +874,9 @@ static int __devinit intelfb_pci_registe
 	if (bailearly == 18)
 		bailout(dinfo);
 
+	/* read active pipe */
+	dinfo->pipe = intelfbhw_active_pipe(&dinfo->save_state);
+
 	/* Cursor initialisation */
 	if (dinfo->hwcursor) {
 		intelfbhw_cursor_init(dinfo);
diff -urp linux-ref/drivers/video/intelfb/intelfbhw.c linux-2.6.30-rc7/drivers/video/intelfb/intelfbhw.c
--- linux-ref/drivers/video/intelfb/intelfbhw.c	2009-05-23 23:47:00.000000000 +0200
+++ linux-2.6.30-rc7/drivers/video/intelfb/intelfbhw.c	2009-05-29 07:42:06.000000000 +0200
@@ -469,6 +469,32 @@ void intelfbhw_do_blank(int blank, struc
 }
 
 
+/* Check which pipe is connected to an active display plane. */
+int intelfbhw_active_pipe(const struct intelfb_hwstate *hw)
+{
+	int pipe = -1;
+
+	/* keep old default behaviour - prefer PIPE_A */
+	if (hw->disp_b_ctrl & DISPPLANE_PLANE_ENABLE) {
+		pipe = (hw->disp_b_ctrl >> DISPPLANE_SEL_PIPE_SHIFT);
+		pipe &= PIPE_MASK;
+		if (unlikely(pipe == PIPE_A))
+			return PIPE_A;
+	}
+	if (hw->disp_a_ctrl & DISPPLANE_PLANE_ENABLE) {
+		pipe = (hw->disp_a_ctrl >> DISPPLANE_SEL_PIPE_SHIFT);
+		pipe &= PIPE_MASK;
+		if (likely(pipe == PIPE_A))
+			return PIPE_A;
+	}
+	/* Impossible that no pipe is selected - return PIPE_A */
+	WARN_ON(pipe == -1);
+	if (unlikely(pipe == -1))
+		pipe = PIPE_A;
+
+	return pipe;
+}
+
 void intelfbhw_setcolreg(struct intelfb_info *dinfo, unsigned regno,
 			 unsigned red, unsigned green, unsigned blue,
 			 unsigned transp)
@@ -1019,7 +1045,7 @@ int intelfbhw_mode_to_hw(struct intelfb_
 			 struct intelfb_hwstate *hw,
 			 struct fb_var_screeninfo *var)
 {
-	int pipe = PIPE_A;
+	int pipe = intelfbhw_active_pipe(hw);
 	u32 *dpll, *fp0, *fp1;
 	u32 m1, m2, n, p1, p2, clock_target, clock;
 	u32 hsync_start, hsync_end, hblank_start, hblank_end, htotal, hactive;
@@ -1033,12 +1059,6 @@ int intelfbhw_mode_to_hw(struct intelfb_
 	/* Disable VGA */
 	hw->vgacntrl |= VGA_DISABLE;
 
-	/* Check whether pipe A or pipe B is enabled. */
-	if (hw->pipe_a_conf & PIPECONF_ENABLE)
-		pipe = PIPE_A;
-	else if (hw->pipe_b_conf & PIPECONF_ENABLE)
-		pipe = PIPE_B;
-
 	/* Set which pipe's registers will be set. */
 	if (pipe == PIPE_B) {
 		dpll = &hw->dpll_b;
@@ -1262,7 +1282,6 @@ int intelfbhw_mode_to_hw(struct intelfb_
 int intelfbhw_program_mode(struct intelfb_info *dinfo,
 			   const struct intelfb_hwstate *hw, int blank)
 {
-	int pipe = PIPE_A;
 	u32 tmp;
 	const u32 *dpll, *fp0, *fp1, *pipe_conf;
 	const u32 *hs, *ht, *hb, *vs, *vt, *vb, *ss;
@@ -1272,7 +1291,7 @@ int intelfbhw_program_mode(struct intelf
 	u32 src_size_reg;
 	u32 count, tmp_val[3];
 
-	/* Assume single pipe, display plane A, analog CRT. */
+	/* Assume single pipe */
 
 #if VERBOSE > 0
 	DBG_MSG("intelfbhw_program_mode\n");
@@ -1283,15 +1302,9 @@ int intelfbhw_program_mode(struct intelf
 	tmp |= VGA_DISABLE;
 	OUTREG(VGACNTRL, tmp);
 
-	/* Check whether pipe A or pipe B is enabled. */
-	if (hw->pipe_a_conf & PIPECONF_ENABLE)
-		pipe = PIPE_A;
-	else if (hw->pipe_b_conf & PIPECONF_ENABLE)
-		pipe = PIPE_B;
+	dinfo->pipe = intelfbhw_active_pipe(hw);
 
-	dinfo->pipe = pipe;
-
-	if (pipe == PIPE_B) {
+	if (dinfo->pipe == PIPE_B) {
 		dpll = &hw->dpll_b;
 		fp0 = &hw->fpb0;
 		fp1 = &hw->fpb1;
diff -urp linux-ref/drivers/video/intelfb/intelfbhw.h linux-2.6.30-rc7/drivers/video/intelfb/intelfbhw.h
--- linux-ref/drivers/video/intelfb/intelfbhw.h	2009-05-23 23:47:00.000000000 +0200
+++ linux-2.6.30-rc7/drivers/video/intelfb/intelfbhw.h	2009-05-29 07:43:54.000000000 +0200
@@ -604,5 +604,6 @@ extern void intelfbhw_cursor_reset(struc
 extern int intelfbhw_enable_irq(struct intelfb_info *dinfo);
 extern void intelfbhw_disable_irq(struct intelfb_info *dinfo);
 extern int intelfbhw_wait_for_vsync(struct intelfb_info *dinfo, u32 pipe);
+extern int intelfbhw_active_pipe(const struct intelfb_hwstate *hw);
 
 #endif /* _INTELFBHW_H */



----------------------------------------------------------------------
Kup wlasne mieszkanie za 33 tys. zl.
Sprawdz >>> http://link.interia.pl/f21a3

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

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

On Wed, 27 May 2009 20:57:55 +0200
Giuseppe Coviello <cj...@cr...> wrote:

> This patch adds support for GXT4000P and GXT6500P cards found on some
> IBM pSeries machines.
> GXT4000P/6000P and GXT4500P/6500P  couples are  identical from
> software's point of view and are based on the same  Raster Engine
> (RC1000), except for a different reference clock for the PLL.
> GXT6x00P models are equipped with an additional Geometry Engine
> (GT1000) but this driver doesn't use it.
> 
> Regards, Giuseppe
> 
> 
> Signed-off-by: Nico Macrionitis <ac...@cr...>
> Signed-off-by: Giuseppe Coviello <cj...@cr...>
> 
> --- /usr/src/linux-2.6.30-rc3/drivers/video/Kconfig	2009-04-22
> 05:07:00.000000000 +0200
> +++ Kconfig	2009-05-05 10:55:17.000000000 +0200
> @@ -1985,8 +1985,10 @@
>  	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.
> 

Please also change name of the option to reflect the fact it supports
more than just the GXT4500P, e.g.

"Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"

Please cc the updated patch to the lin...@oz....

Regards,
Krzysztof

----------------------------------------------------------------------
Przekaz dalej wiadomosc: Zawsze warto oszczedzac. Teraz 5,5%!
Sprawdz > http://link.interia.pl/f21b1

Re: [Linux-fbdev-devel] s3c-fb: CPUFREQ frequency scaling support

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

On Thu, 28 May 2009 22:04:30 +0100
Ben Dooks <be...@si...> wrote:

> Add support for CPU frequency scaling in the S3C24XX video driver.
> 

Looks nice and neat.

Did you get to look at Krzysztof's
s3c-fb-fix-resource-releasing-on-error-during-probing.patch, btw?  Is
it 2.6.30 material?

> 
> ---
>  drivers/video/s3c2410fb.c |   67 ++++++++++++++++++++++++++++++++++++++++++++--
>  drivers/video/s3c2410fb.h |    5 +++
>  2 files changed, 70 insertions(+), 2 deletions(-)
> 
> Index: b/drivers/video/s3c2410fb.c
> ===================================================================
> --- a/drivers/video/s3c2410fb.c	2009-02-02 11:30:38.372867510 +0000
> +++ b/drivers/video/s3c2410fb.c	2009-02-02 11:30:58.703595503 +0000
> @@ -24,6 +24,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/platform_device.h>
>  #include <linux/clk.h>
> +#include <linux/cpufreq.h>
>  
>  #include <asm/io.h>
>  #include <asm/div64.h>
> @@ -89,7 +90,7 @@ static void s3c2410fb_set_lcdaddr(struct
>  static unsigned int s3c2410fb_calc_pixclk(struct s3c2410fb_info *fbi,
>  					  unsigned long pixclk)
>  {
> -	unsigned long clk = clk_get_rate(fbi->clk);
> +	unsigned long clk = fbi->clk_rate;
>  	unsigned long long div;
>  
>  	/* pixclk is in picoseconds, our clock is in Hz
> @@ -758,6 +759,57 @@ static irqreturn_t s3c2410fb_irq(int irq
>  	return IRQ_HANDLED;
>  }
>  
> +#ifdef CONFIG_CPU_FREQ
> +
> +static int s3c2410fb_cpufreq_transition(struct notifier_block *nb,
> +					unsigned long val, void *data)
> +{
> +	struct cpufreq_freqs *freqs = data;
> +	struct s3c2410fb_info *info;
> +	struct fb_info *fbinfo;
> +	long delta_f;
> +
> +	info = container_of(nb, struct s3c2410fb_info, freq_transition);
> +	fbinfo = platform_get_drvdata(to_platform_device(info->dev));
> +
> +	/* work out change, <0 for speed-up */
> +	delta_f = info->clk_rate - clk_get_rate(info->clk);
> +
> +	if ((val == CPUFREQ_POSTCHANGE && delta_f > 0) ||
> +	    (val == CPUFREQ_PRECHANGE && delta_f < 0)) {
> +		info->clk_rate = clk_get_rate(info->clk);
> +		s3c2410fb_activate_var(fbinfo);
> +	}
> +
> +	return 0;
> +}
> +
> +static inline int s3c2410fb_cpufreq_register(struct s3c2410fb_info *info)
> +{
> +	info->freq_transition.notifier_call = s3c2410fb_cpufreq_transition;
> +
> +	return cpufreq_register_notifier(&info->freq_transition,
> +					 CPUFREQ_TRANSITION_NOTIFIER);
> +}
> +
> +static inline void s3c2410fb_cpufreq_deregister(struct s3c2410fb_info *info)
> +{
> +	cpufreq_unregister_notifier(&info->freq_transition,
> +				    CPUFREQ_TRANSITION_NOTIFIER);
> +}
> +
> +#else
> +static inline int s3c2410fb_cpufreq_register(struct s3c2410fb_info *info)
> +{
> +	return 0;
> +}
> +
> +static inline void s3c2410fb_cpufreq_deregister(struct s3c2410fb_info *info)
> +{
> +}
> +#endif
> +
> +
>  static char driver_name[] = "s3c2410fb";
>  
>  static int __init s3c24xxfb_probe(struct platform_device *pdev,
> @@ -875,6 +927,8 @@ static int __init s3c24xxfb_probe(struct
>  
>  	msleep(1);
>  
> +	info->clk_rate = clk_get_rate(info->clk);
> +
>  	/* find maximum required memory size for display */
>  	for (i = 0; i < mach_info->num_displays; i++) {
>  		unsigned long smem_len = mach_info->displays[i].xres;
> @@ -904,11 +958,17 @@ static int __init s3c24xxfb_probe(struct
>  
>  	s3c2410fb_check_var(&fbinfo->var, fbinfo);
>  
> +	ret = s3c2410fb_cpufreq_register(info);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Failed to register cpufreq\n");
> +		goto free_video_memory;
> +	}
> +
>  	ret = register_framebuffer(fbinfo);
>  	if (ret < 0) {
>  		printk(KERN_ERR "Failed to register framebuffer device: %d\n",
>  			ret);
> -		goto free_video_memory;
> +		goto free_cpufreq;
>  	}
>  
>  	/* create device files */
> @@ -922,6 +982,8 @@ static int __init s3c24xxfb_probe(struct
>  
>  	return 0;
>  
> + free_cpufreq:
> +	s3c2410fb_cpufreq_deregister(info);
>  free_video_memory:
>  	s3c2410fb_unmap_video_memory(fbinfo);
>  release_clock:
> @@ -961,6 +1023,7 @@ static int s3c2410fb_remove(struct platf
>  	int irq;
>  
>  	unregister_framebuffer(fbinfo);
> +	s3c2410fb_cpufreq_deregister(info);
>  
>  	s3c2410fb_lcd_enable(info, 0);
>  	msleep(1);
> Index: b/drivers/video/s3c2410fb.h
> ===================================================================
> --- a/drivers/video/s3c2410fb.h	2009-02-02 11:29:48.488096579 +0000
> +++ b/drivers/video/s3c2410fb.h	2009-02-02 11:30:58.723594471 +0000
> @@ -29,8 +29,13 @@ struct s3c2410fb_info {
>  	enum s3c_drv_type	drv_type;
>  	struct s3c2410fb_hw	regs;
>  
> +	unsigned long		clk_rate;
>  	unsigned int		palette_ready;
>  
> +#ifdef CONFIG_CPU_FREQ
> +	struct notifier_block	freq_transition;
> +#endif
> +
>  	/* keep these registers in case we need to re-write palette */
>  	u32			palette_buffer[256];
>  	u32			pseudo_pal[16];
> 

afacit freq_transition.priority never gets initialised.

afacit this is a cpufreq bug, as cpufreq_register_notifier() has no
interface to set the notifier_block.priority and probably it's not the
role of cpufreq clients to be diddling the notifier priority.

I'd expect this problem to trigger kmemcheck warnings, at least.

Re: [Linux-fbdev-devel] [PATCH] [drivers] [fb] S3C-fb: PM fix

[Marek S. <m.s...@sa...>]

Hello,

On Thursday, May 28, 2009 8:33 AM Andrew Morton wrote:

> On Mon, 18 May 2009 08:05:46 +0200 Marek Szyprowski
> <m.s...@sa...> wrote:
> 
> > Restore correctly FrameBuffer registers state in resume function.
> >
> > Reviewed-by: Kyungmin Park <kyu...@sa...>
> > Signed-off-by: Marek Szyprowski <m.s...@sa...>
> > [...]

> What are the consequences of the bug whcih you fixed?  Device
> inoperative after resume, I assume?  Does it affect all supported
> hardware, or just some particualr device(s)?

Yes, the framebuffer was inoperative after resume. This bug was triggered on
a system that has a power management circuit which disabled power in most
S3C SOC power domains in suspend mode. In such case drivers need to restore
all its registers state after resume.

> See, this is the sort of information whcih shuld be in the changelog,
> please, so I (and others) can make decisions about which kernel
> version(s) the patch should be merged into.

Ok. I will describe my patches more in detail in the future. Thanks for your
comments.

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center

Re: [Linux-fbdev-devel] [PATCH 05/10] ARM: OMAP1: Make 770 LCD work

[Andrew de Q. <ad...@li...>]

Quoting Russell King - ARM Linux <li...@ar...>:

> On Thu, May 28, 2009 at 11:20:48AM -0700, Tony Lindgren wrote:
>> * Andrew de Quincey <ad...@li...> [090525 09:41]:
>> > Quoting Andrew de Quincey <ad...@li...>:
>> >
>> >> Quoting Russell King - ARM Linux <li...@ar...>:
>> >>
>> >>> On Tue, May 19, 2009 at 04:37:32PM -0700, Tony Lindgren wrote:
>> >>>> Make 770 LCD work by passing the clock from platform data.
>> >>>> Also remove the old unused functions.
>> >>>
>> >>> I don't like this - because its passing struct clk's through platform
>> >>> data.  That's not how things are supposed to work.
>> >>>
>> >>> The way PXA solves this problem is to have clock aliases - see
>> >>> clk_add_alias().
>> >>
>> >> Interesting idea - I now have a prototype patch implementing this,
>> >> which I'll send when I get home (otherwise it would be an "it
>> >> compiles" "test" :)
>> >>
>> >> There isn't a common definition of clk_add_alias() though - that
>> >> symbol is defined in arch/arm/mach-pxa/clock.c, so I had to copy it
>> >> into arch/arm/plat-omap/clock.c
>> >
>> > Attached is a patch implementing this method. I don't like the
>> > duplication of the clk_alias code, but I imagine that could be resolved
>> > if this method was chosen....
>>
>> Andrew, can you please reply with your Signed-off-by?
>
> Actually, I'm very tempted to suggest that clk_add_alias() should go
> into arch/arm/common/clkdev.c if we're going to have more people use it.

Cool!

Out of interest, what is the best practice way to pass platform  
specific GPIOs around? There are a number of other n770 related  
drivers I'm intending on cleaning up, several of which have GPIO  
numbers hardcoded in them. Should these be passed in platform  
structures, or is there something analogous to the clk_alias for GPIOs?

Re: [Linux-fbdev-devel] [PATCH 05/10] ARM: OMAP1: Make 770 LCD work, v3

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

* Tony Lindgren <to...@at...> [090528 12:12]:
> * Andrew de Quincey <ad...@li...> [090528 11:44]:
> > Quoting Tony Lindgren <to...@at...>:
> >
> >> * Andrew de Quincey <ad...@li...> [090525 09:41]:
> >>> Quoting Andrew de Quincey <ad...@li...>:
> >>>
> >>>> Quoting Russell King - ARM Linux <li...@ar...>:
> >>>>
> >>>>> On Tue, May 19, 2009 at 04:37:32PM -0700, Tony Lindgren wrote:
> >>>>>> Make 770 LCD work by passing the clock from platform data.
> >>>>>> Also remove the old unused functions.
> >>>>>
> >>>>> I don't like this - because its passing struct clk's through platform
> >>>>> data.  That's not how things are supposed to work.
> >>>>>
> >>>>> The way PXA solves this problem is to have clock aliases - see
> >>>>> clk_add_alias().
> >>>>
> >>>> Interesting idea - I now have a prototype patch implementing this,
> >>>> which I'll send when I get home (otherwise it would be an "it
> >>>> compiles" "test" :)
> >>>>
> >>>> There isn't a common definition of clk_add_alias() though - that
> >>>> symbol is defined in arch/arm/mach-pxa/clock.c, so I had to copy it
> >>>> into arch/arm/plat-omap/clock.c
> >>>
> >>> Attached is a patch implementing this method. I don't like the
> >>> duplication of the clk_alias code, but I imagine that could be resolved
> >>> if this method was chosen....
> >>
> >> Andrew, can you please reply with your Signed-off-by?
> >
> > Sure - sorry I was holding off in case there were any comments on the  
> > method...
> 
> I added a note about maybe moving the clk_add_alias() to
> arch/arm/common/clkdev.c later.
> 
> Also noticed there were some whitespace errors, updated version below.

One more time with clk_add_alias() in a separate patch.

Tony

[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...>]

* 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?

Tony

Re: [Linux-fbdev-devel] [PATCH 05/10] ARM: OMAP1: Make 770 LCD work

[Russell K. - A. L. <li...@ar...>]

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...)

Re: [Linux-fbdev-devel] [PATCH 05/10] ARM: OMAP1: Make 770 LCD work

[Russell K. - A. L. <li...@ar...>]

On Thu, May 28, 2009 at 11:20:48AM -0700, Tony Lindgren wrote:
> * Andrew de Quincey <ad...@li...> [090525 09:41]:
> > Quoting Andrew de Quincey <ad...@li...>:
> >
> >> Quoting Russell King - ARM Linux <li...@ar...>:
> >>
> >>> On Tue, May 19, 2009 at 04:37:32PM -0700, Tony Lindgren wrote:
> >>>> Make 770 LCD work by passing the clock from platform data.
> >>>> Also remove the old unused functions.
> >>>
> >>> I don't like this - because its passing struct clk's through platform
> >>> data.  That's not how things are supposed to work.
> >>>
> >>> The way PXA solves this problem is to have clock aliases - see
> >>> clk_add_alias().
> >>
> >> Interesting idea - I now have a prototype patch implementing this,  
> >> which I'll send when I get home (otherwise it would be an "it  
> >> compiles" "test" :)
> >>
> >> There isn't a common definition of clk_add_alias() though - that  
> >> symbol is defined in arch/arm/mach-pxa/clock.c, so I had to copy it  
> >> into arch/arm/plat-omap/clock.c
> >
> > Attached is a patch implementing this method. I don't like the  
> > duplication of the clk_alias code, but I imagine that could be resolved 
> > if this method was chosen....
> 
> Andrew, can you please reply with your Signed-off-by?

Actually, I'm very tempted to suggest that clk_add_alias() should go
into arch/arm/common/clkdev.c if we're going to have more people use it.

Re: [Linux-fbdev-devel] [PATCH 05/10] ARM: OMAP1: Make 770 LCD work, v2

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

* Andrew de Quincey <ad...@li...> [090528 11:44]:
> Quoting Tony Lindgren <to...@at...>:
>
>> * Andrew de Quincey <ad...@li...> [090525 09:41]:
>>> Quoting Andrew de Quincey <ad...@li...>:
>>>
>>>> Quoting Russell King - ARM Linux <li...@ar...>:
>>>>
>>>>> On Tue, May 19, 2009 at 04:37:32PM -0700, Tony Lindgren wrote:
>>>>>> Make 770 LCD work by passing the clock from platform data.
>>>>>> Also remove the old unused functions.
>>>>>
>>>>> I don't like this - because its passing struct clk's through platform
>>>>> data.  That's not how things are supposed to work.
>>>>>
>>>>> The way PXA solves this problem is to have clock aliases - see
>>>>> clk_add_alias().
>>>>
>>>> Interesting idea - I now have a prototype patch implementing this,
>>>> which I'll send when I get home (otherwise it would be an "it
>>>> compiles" "test" :)
>>>>
>>>> There isn't a common definition of clk_add_alias() though - that
>>>> symbol is defined in arch/arm/mach-pxa/clock.c, so I had to copy it
>>>> into arch/arm/plat-omap/clock.c
>>>
>>> Attached is a patch implementing this method. I don't like the
>>> duplication of the clk_alias code, but I imagine that could be resolved
>>> if this method was chosen....
>>
>> Andrew, can you please reply with your Signed-off-by?
>
> Sure - sorry I was holding off in case there were any comments on the  
> method...

I added a note about maybe moving the clk_add_alias() to
arch/arm/common/clkdev.c later.

Also noticed there were some whitespace errors, updated version below.

Regards,

Tony

> Signed-off-by: Andrew de Quincey <ad...@li...>
>

Re: [Linux-fbdev-devel] [PATCH 05/10] ARM: OMAP1: Make 770 LCD work

[Andrew de Q. <ad...@li...>]

Quoting Tony Lindgren <to...@at...>:

> * Andrew de Quincey <ad...@li...> [090525 09:41]:
>> Quoting Andrew de Quincey <ad...@li...>:
>>
>>> Quoting Russell King - ARM Linux <li...@ar...>:
>>>
>>>> On Tue, May 19, 2009 at 04:37:32PM -0700, Tony Lindgren wrote:
>>>>> Make 770 LCD work by passing the clock from platform data.
>>>>> Also remove the old unused functions.
>>>>
>>>> I don't like this - because its passing struct clk's through platform
>>>> data.  That's not how things are supposed to work.
>>>>
>>>> The way PXA solves this problem is to have clock aliases - see
>>>> clk_add_alias().
>>>
>>> Interesting idea - I now have a prototype patch implementing this,
>>> which I'll send when I get home (otherwise it would be an "it
>>> compiles" "test" :)
>>>
>>> There isn't a common definition of clk_add_alias() though - that
>>> symbol is defined in arch/arm/mach-pxa/clock.c, so I had to copy it
>>> into arch/arm/plat-omap/clock.c
>>
>> Attached is a patch implementing this method. I don't like the
>> duplication of the clk_alias code, but I imagine that could be resolved
>> if this method was chosen....
>
> Andrew, can you please reply with your Signed-off-by?

Sure - sorry I was holding off in case there were any comments on the  
method...

Signed-off-by: Andrew de Quincey <ad...@li...>

Re: [Linux-fbdev-devel] [PATCH 05/10] ARM: OMAP1: Make 770 LCD work

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

* Andrew de Quincey <ad...@li...> [090525 09:41]:
> Quoting Andrew de Quincey <ad...@li...>:
>
>> Quoting Russell King - ARM Linux <li...@ar...>:
>>
>>> On Tue, May 19, 2009 at 04:37:32PM -0700, Tony Lindgren wrote:
>>>> Make 770 LCD work by passing the clock from platform data.
>>>> Also remove the old unused functions.
>>>
>>> I don't like this - because its passing struct clk's through platform
>>> data.  That's not how things are supposed to work.
>>>
>>> The way PXA solves this problem is to have clock aliases - see
>>> clk_add_alias().
>>
>> Interesting idea - I now have a prototype patch implementing this,  
>> which I'll send when I get home (otherwise it would be an "it  
>> compiles" "test" :)
>>
>> There isn't a common definition of clk_add_alias() though - that  
>> symbol is defined in arch/arm/mach-pxa/clock.c, so I had to copy it  
>> into arch/arm/plat-omap/clock.c
>
> Attached is a patch implementing this method. I don't like the  
> duplication of the clk_alias code, but I imagine that could be resolved 
> if this method was chosen....

Andrew, can you please reply with your Signed-off-by?

Thanks,

Tony

> diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
> index 8780ca6..e70fc7c 100644
> --- a/arch/arm/mach-omap1/board-nokia770.c
> +++ b/arch/arm/mach-omap1/board-nokia770.c
> @@ -33,9 +33,11 @@
>  #include <mach/common.h>
>  #include <mach/dsp_common.h>
>  #include <mach/omapfb.h>
> +#include <mach/hwa742.h>
>  #include <mach/lcd_mipid.h>
>  #include <mach/mmc.h>
>  #include <mach/usb.h>
> +#include <mach/clock.h>
>  
>  #define ADS7846_PENDOWN_GPIO	15
>  
> @@ -163,6 +165,15 @@ static struct spi_board_info nokia770_spi_board_info[] __initdata = {
>  	},
>  };
>  
> +static struct hwa742_platform_data nokia770_hwa742_platform_data = {
> +	.te_connected		= 1,
> +};
> +
> +static void hwa742_dev_init(void)
> +{
> +	clk_add_alias("hwa_sys_ck", NULL, "bclk", NULL);
> +	omapfb_set_ctrl_platform_data(&nokia770_hwa742_platform_data);
> +}
>  
>  /* assume no Mini-AB port */
>  
> @@ -371,6 +382,7 @@ static void __init omap_nokia770_init(void)
>  	omap_serial_init();
>  	omap_register_i2c_bus(1, 100, NULL, 0);
>  	omap_dsp_init();
> +	hwa742_dev_init();
>  	ads7846_dev_init();
>  	mipid_dev_init();
>  	omap_usb_init(&nokia770_usb_config);
> diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
> index 29efc27..862eefd 100644
> --- a/arch/arm/plat-omap/clock.c
> +++ b/arch/arm/plat-omap/clock.c
> @@ -24,6 +24,7 @@
>  #include <linux/debugfs.h>
>  #include <linux/io.h>
>  
> +#include <asm/clkdev.h>
>  #include <mach/clock.h>
>  
>  static LIST_HEAD(clocks);
> @@ -359,6 +360,24 @@ static int __init clk_disable_unused(void)
>  late_initcall(clk_disable_unused);
>  #endif
>  
> +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);												
> +
>  int __init clk_init(struct clk_functions * custom_clocks)
>  {
>  	if (!custom_clocks) {
> diff --git a/arch/arm/plat-omap/include/mach/clock.h b/arch/arm/plat-omap/include/mach/clock.h
> index 073a2c5..b53b047 100644
> --- a/arch/arm/plat-omap/include/mach/clock.h
> +++ b/arch/arm/plat-omap/include/mach/clock.h
> @@ -127,12 +127,14 @@ extern void propagate_rate(struct clk *clk);
>  extern void recalculate_root_clocks(void);
>  extern unsigned long followparent_recalc(struct clk *clk);
>  extern void clk_enable_init_clocks(void);
> +extern int clk_add_alias(const char *alias, const char *alias_dev_name, char *id, struct device *dev); 	
>  #ifdef CONFIG_CPU_FREQ
>  extern void clk_init_cpufreq_table(struct cpufreq_frequency_table **table);
>  #endif
>  
>  extern const struct clkops clkops_null;
>  
> +
>  /* Clock flags */
>  /* bit 0 is free */
>  #define RATE_FIXED		(1 << 1)	/* Fixed clock rate */
> diff --git a/arch/arm/plat-omap/include/mach/hwa742.h b/arch/arm/plat-omap/include/mach/hwa742.h
> index 577f492..886248d 100644
> --- a/arch/arm/plat-omap/include/mach/hwa742.h
> +++ b/arch/arm/plat-omap/include/mach/hwa742.h
> @@ -2,10 +2,6 @@
>  #define _HWA742_H
>  
>  struct hwa742_platform_data {
> -	void		(*power_up)(struct device *dev);
> -	void		(*power_down)(struct device *dev);
> -	unsigned long	(*get_clock_rate)(struct device *dev);
> -
>  	unsigned	te_connected:1;
>  };
>  
> diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c
> index 8aa6e47..5d4f348 100644
> --- a/drivers/video/omap/hwa742.c
> +++ b/drivers/video/omap/hwa742.c
> @@ -133,8 +133,7 @@ struct {
>  	struct lcd_ctrl_extif	*extif;
>  	struct lcd_ctrl		*int_ctrl;
>  
> -	void			(*power_up)(struct device *dev);
> -	void			(*power_down)(struct device *dev);
> +	struct clk		*sys_ck;
>  } hwa742;
>  
>  struct lcd_ctrl hwa742_ctrl;
> @@ -915,14 +914,13 @@ static void hwa742_suspend(void)
>  	hwa742_set_update_mode(OMAPFB_UPDATE_DISABLED);
>  	/* Enable sleep mode */
>  	hwa742_write_reg(HWA742_POWER_SAVE, 1 << 1);
> -	if (hwa742.power_down != NULL)
> -		hwa742.power_down(hwa742.fbdev->dev);
> +	clk_disable(hwa742.sys_ck);
>  }
>  
>  static void hwa742_resume(void)
>  {
> -	if (hwa742.power_up != NULL)
> -		hwa742.power_up(hwa742.fbdev->dev);
> +	clk_enable(hwa742.sys_ck);
> +
>  	/* Disable sleep mode */
>  	hwa742_write_reg(HWA742_POWER_SAVE, 0);
>  	while (1) {
> @@ -955,14 +953,13 @@ static int hwa742_init(struct omapfb_device *fbdev, int ext_mode,
>  	omapfb_conf = fbdev->dev->platform_data;
>  	ctrl_conf = omapfb_conf->ctrl_platform_data;
>  
> -	if (ctrl_conf == NULL || ctrl_conf->get_clock_rate == NULL) {
> +	if (ctrl_conf == NULL) {
>  		dev_err(fbdev->dev, "HWA742: missing platform data\n");
>  		r = -ENOENT;
>  		goto err1;
>  	}
>  
> -	hwa742.power_down = ctrl_conf->power_down;
> -	hwa742.power_up = ctrl_conf->power_up;
> +	hwa742.sys_ck = clk_get(NULL, "hwa_sys_ck");
>  
>  	spin_lock_init(&hwa742.req_lock);
>  
> @@ -972,12 +969,11 @@ static int hwa742_init(struct omapfb_device *fbdev, int ext_mode,
>  	if ((r = hwa742.extif->init(fbdev)) < 0)
>  		goto err2;
>  
> -	ext_clk = ctrl_conf->get_clock_rate(fbdev->dev);
> +	ext_clk = clk_get_rate(hwa742.sys_ck);
>  	if ((r = calc_extif_timings(ext_clk, &extif_mem_div)) < 0)
>  		goto err3;
>  	hwa742.extif->set_timings(&hwa742.reg_timings);
> -	if (hwa742.power_up != NULL)
> -		hwa742.power_up(fbdev->dev);
> +	clk_enable(hwa742.sys_ck);
>  
>  	calc_hwa742_clk_rates(ext_clk, &sys_clk, &pix_clk);
>  	if ((r = calc_extif_timings(sys_clk, &extif_mem_div)) < 0)
> @@ -1040,8 +1036,7 @@ static int hwa742_init(struct omapfb_device *fbdev, int ext_mode,
>  
>  	return 0;
>  err4:
> -	if (hwa742.power_down != NULL)
> -		hwa742.power_down(fbdev->dev);
> +	clk_disable(hwa742.sys_ck);
>  err3:
>  	hwa742.extif->cleanup();
>  err2:
> @@ -1055,8 +1050,7 @@ static void hwa742_cleanup(void)
>  	hwa742_set_update_mode(OMAPFB_UPDATE_DISABLED);
>  	hwa742.extif->cleanup();
>  	hwa742.int_ctrl->cleanup();
> -	if (hwa742.power_down != NULL)
> -		hwa742.power_down(hwa742.fbdev->dev);
> +	clk_disable(hwa742.sys_ck);
>  }
>  
>  struct lcd_ctrl hwa742_ctrl = {

Re: [Linux-fbdev-devel] [PATCH] atmel_lcdfb: Correct fifo size for some products

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

On Fri, 15 May 2009 12:34:18 +0200 Nicolas Ferre <nic...@at...> wrote:

> Remove wrong fifo size definition for some AT91 products.
> 
> Due to a misunderstanding of some AT91 datasheets, a fifo size of 2048 (words)
> has been introduced by mistake. In fact, all products (AT91/AT32) are sharing
> the same fifo size of 512 words.
> 

Changelog fails to describe the impact of the bug, so people who are
working out which kernel versions it should be ported into don't know
what to do.

Furthermore, people who are hitting a bug in this driver in older
kernel versions will have difficulty working out whether this patch
might fix their bug.

> Can we consider this fix for .30-final ?

Sure, but for what reason?

What about 2.6.29.x, 2.6.28.x, earlier?

> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -29,14 +29,8 @@
>  
>  /* configurable parameters */
>  #define ATMEL_LCDC_CVAL_DEFAULT		0xc8
> -#define ATMEL_LCDC_DMA_BURST_LEN	8
> -
> -#if defined(CONFIG_ARCH_AT91SAM9263) || defined(CONFIG_ARCH_AT91CAP9) || \
> -	defined(CONFIG_ARCH_AT91SAM9RL)
> -#define ATMEL_LCDC_FIFO_SIZE		2048
> -#else
> -#define ATMEL_LCDC_FIFO_SIZE		512
> -#endif
> +#define ATMEL_LCDC_DMA_BURST_LEN	8	/* words */
> +#define ATMEL_LCDC_FIFO_SIZE		512	/* words */
>  
>  #if defined(CONFIG_ARCH_AT91)
>  #define	ATMEL_LCDFB_FBINFO_DEFAULT	(FBINFO_DEFAULT \

Re: [Linux-fbdev-devel] [PATCH] radeon: P2G2CLK_ALWAYS_ONb tested twice, should 2nd be P2G2CLK_DAC_ALWAYS_ONb?

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

On Wed, 2009-05-27 at 23:54 -0700, Andrew Morton wrote:
> On Fri, 15 May 2009 22:45:27 +0200 Roel Kluin <roe...@gm...> wrote:
> 
> > P2G2CLK_ALWAYS_ONb is tested twice, 2nd should be P2G2CLK_DAC_ALWAYS_ONb.
> > 
> > Signed-off-by: Roel Kluin <roe...@gm...>
> > ---
> > Is this correct? I am only guessing. Please review.
> 
> Nobody knows?

It looks ok, I've acked it, we'll see how it goes :-)

Cheers,
Ben.

> > diff --git a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c
> > index 97a1f09..100112f 100644
> > --- a/drivers/video/aty/radeon_pm.c
> > +++ b/drivers/video/aty/radeon_pm.c
> > @@ -395,7 +395,7 @@ static void radeon_pm_enable_dynamic_mode(struct radeonfb_info *rinfo)
> >  			PIXCLKS_CNTL__R300_PIXCLK_TRANS_ALWAYS_ONb      |
> >  			PIXCLKS_CNTL__R300_PIXCLK_TVO_ALWAYS_ONb        |
> >  			PIXCLKS_CNTL__R300_P2G2CLK_ALWAYS_ONb           |
> > -			PIXCLKS_CNTL__R300_P2G2CLK_ALWAYS_ONb);
> > +			PIXCLKS_CNTL__R300_P2G2CLK_DAC_ALWAYS_ONb);
> >  		OUTPLL(pllPIXCLKS_CNTL, tmp);
> >  
> >  		tmp = INPLL(pllMCLK_MISC);
> 
> The same thing happens at line 215:
> 
>                 tmp &= ~(PIXCLKS_CNTL__PIX2CLK_ALWAYS_ONb		|
> 			 PIXCLKS_CNTL__PIX2CLK_DAC_ALWAYS_ONb		|
> 			 PIXCLKS_CNTL__DISP_TVOUT_PIXCLK_TV_ALWAYS_ONb	|
> 			 PIXCLKS_CNTL__R300_DVOCLK_ALWAYS_ONb		|
> 			 PIXCLKS_CNTL__PIXCLK_BLEND_ALWAYS_ONb		|
> 			 PIXCLKS_CNTL__PIXCLK_GV_ALWAYS_ONb		|
> 			 PIXCLKS_CNTL__R300_PIXCLK_DVO_ALWAYS_ONb	|
> 			 PIXCLKS_CNTL__PIXCLK_LVDS_ALWAYS_ONb		|
> 			 PIXCLKS_CNTL__PIXCLK_TMDS_ALWAYS_ONb		|
> 			 PIXCLKS_CNTL__R300_PIXCLK_TRANS_ALWAYS_ONb	|
> 			 PIXCLKS_CNTL__R300_PIXCLK_TVO_ALWAYS_ONb	|
> 			 PIXCLKS_CNTL__R300_P2G2CLK_ALWAYS_ONb		|
> 			 PIXCLKS_CNTL__R300_P2G2CLK_ALWAYS_ONb		|
> 			 PIXCLKS_CNTL__R300_DISP_DAC_PIXCLK_DAC2_BLANK_OFF);
> 
> but that's easier to fix.

Re: [Linux-fbdev-devel] [PATCH] radeon: P2G2CLK_ALWAYS_ONb tested twice, should 2nd be P2G2CLK_DAC_ALWAYS_ONb?

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

On Fri, 15 May 2009 22:45:27 +0200 Roel Kluin <roe...@gm...> wrote:

> P2G2CLK_ALWAYS_ONb is tested twice, 2nd should be P2G2CLK_DAC_ALWAYS_ONb.
> 
> Signed-off-by: Roel Kluin <roe...@gm...>
> ---
> Is this correct? I am only guessing. Please review.

Nobody knows?

> diff --git a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c
> index 97a1f09..100112f 100644
> --- a/drivers/video/aty/radeon_pm.c
> +++ b/drivers/video/aty/radeon_pm.c
> @@ -395,7 +395,7 @@ static void radeon_pm_enable_dynamic_mode(struct radeonfb_info *rinfo)
>  			PIXCLKS_CNTL__R300_PIXCLK_TRANS_ALWAYS_ONb      |
>  			PIXCLKS_CNTL__R300_PIXCLK_TVO_ALWAYS_ONb        |
>  			PIXCLKS_CNTL__R300_P2G2CLK_ALWAYS_ONb           |
> -			PIXCLKS_CNTL__R300_P2G2CLK_ALWAYS_ONb);
> +			PIXCLKS_CNTL__R300_P2G2CLK_DAC_ALWAYS_ONb);
>  		OUTPLL(pllPIXCLKS_CNTL, tmp);
>  
>  		tmp = INPLL(pllMCLK_MISC);

The same thing happens at line 215:

                tmp &= ~(PIXCLKS_CNTL__PIX2CLK_ALWAYS_ONb		|
			 PIXCLKS_CNTL__PIX2CLK_DAC_ALWAYS_ONb		|
			 PIXCLKS_CNTL__DISP_TVOUT_PIXCLK_TV_ALWAYS_ONb	|
			 PIXCLKS_CNTL__R300_DVOCLK_ALWAYS_ONb		|
			 PIXCLKS_CNTL__PIXCLK_BLEND_ALWAYS_ONb		|
			 PIXCLKS_CNTL__PIXCLK_GV_ALWAYS_ONb		|
			 PIXCLKS_CNTL__R300_PIXCLK_DVO_ALWAYS_ONb	|
			 PIXCLKS_CNTL__PIXCLK_LVDS_ALWAYS_ONb		|
			 PIXCLKS_CNTL__PIXCLK_TMDS_ALWAYS_ONb		|
			 PIXCLKS_CNTL__R300_PIXCLK_TRANS_ALWAYS_ONb	|
			 PIXCLKS_CNTL__R300_PIXCLK_TVO_ALWAYS_ONb	|
			 PIXCLKS_CNTL__R300_P2G2CLK_ALWAYS_ONb		|
			 PIXCLKS_CNTL__R300_P2G2CLK_ALWAYS_ONb		|
			 PIXCLKS_CNTL__R300_DISP_DAC_PIXCLK_DAC2_BLANK_OFF);

but that's easier to fix.

Re: [Linux-fbdev-devel] [PATCH] [drivers] [fb] S3C-fb: PM fix

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

On Mon, 18 May 2009 08:05:46 +0200 Marek Szyprowski <m.s...@sa...> wrote:

> Restore correctly FrameBuffer registers state in resume function.
> 
> Reviewed-by: Kyungmin Park <kyu...@sa...>
> Signed-off-by: Marek Szyprowski <m.s...@sa...>
> 
> --- 
> 
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 5e9c630..d3a568e 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -947,7 +947,8 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
>  	int win;
>  
>  	for (win = 0; win <= S3C_FB_MAX_WIN; win++)
> -		s3c_fb_release_win(sfb, sfb->windows[win]);
> +		if (sfb->windows[win])
> +			s3c_fb_release_win(sfb, sfb->windows[win]);
>  
>  	iounmap(sfb->regs);
>  
> @@ -985,11 +986,20 @@ static int s3c_fb_suspend(struct platform_device *pdev, pm_message_t state)
>  static int s3c_fb_resume(struct platform_device *pdev)
>  {
>  	struct s3c_fb *sfb = platform_get_drvdata(pdev);
> +	struct s3c_fb_platdata *pd = sfb->pdata;
>  	struct s3c_fb_win *win;
>  	int win_no;
>  
>  	clk_enable(sfb->bus_clk);
>  
> +	/* setup registers */
> +	writel(pd->vidcon1, sfb->regs + VIDCON1);
> +
> +	/* zero all windows before we do anything */
> +	for (win_no = 0; win_no < S3C_FB_MAX_WIN; win_no++)
> +		s3c_fb_clear_win(sfb, win_no);
> +
> +	/* restore framebuffers */
>  	for (win_no = 0; win_no < S3C_FB_MAX_WIN; win_no++) {
>  		win = sfb->windows[win_no];
>  		if (!win)

What are the consequences of the bug whcih you fixed?  Device
inoperative after resume, I assume?  Does it affect all supported
hardware, or just some particualr device(s)?

See, this is the sort of information whcih shuld be in the changelog,
please, so I (and others) can make decisions about which kernel
version(s) the patch should be merged into.

I assume we want it in 2.6.30.