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

Re: [Linux-fbdev-devel] [RFC][PATCH] omapfb: Reorder Register_framebuffer call

[Hiremath, V. <hva...@ti...>]

> -----Original Message-----
> From: lin...@vg... [mailto:linux-omap-
> ow...@vg...] On Behalf Of Gadiyar, Anand
> Sent: Friday, September 04, 2009 12:15 PM
> To: Aguirre Rodriguez, Sergio Alberto; linux-fbdev-
> de...@li...
> Cc: Imre Deak; lin...@vg...
> Subject: RE: [RFC][PATCH] omapfb: Reorder Register_framebuffer call
> 
> > From: Sergio Aguirre <saa...@ti...>
> >
> > This fixes the issue in which mm_lock mutex was attempted to be
> > used without initializing previously.
> >
> > Signed-off-by: Sergio Aguirre <saa...@ti...>
> 
> Tested-by: Anand Gadiyar <ga...@ti...>
> 
> This patch on top of current linux-omap kernel allows me to
> boot with the default SDP defconfig on a 3430 SDP.
> 
[Hiremath, Vaibhav] I have tried it on OMAP3EVM and it allowed me to boot, which was crashing before.

Thanks,
Vaibhav

> - Anand
> 
> 
> > ---
> >  drivers/video/omap/omapfb_main.c |   20 +++++++++++---------
> >  1 files changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/video/omap/omapfb_main.c
> b/drivers/video/omap/omapfb_main.c
> > index 125e605..60f9482 100644
> > --- a/drivers/video/omap/omapfb_main.c
> > +++ b/drivers/video/omap/omapfb_main.c
> > @@ -1503,12 +1503,21 @@ static int fbinfo_init(struct
> omapfb_device *fbdev, struct fb_info *info)
> >  	var->rotate	  = def_rotate;
> >  	var->bits_per_pixel = fbdev->panel->bpp;
> >
> > +	r = register_framebuffer(info);
> > +	if (r != 0) {
> > +		dev_err(fbdev->dev,
> > +			"registering framebuffer failed\n");
> > +		return r;
> > +	}
> > +
> >  	set_fb_var(info, var);
> >  	set_fb_fix(info);
> >
> >  	r = fb_alloc_cmap(&info->cmap, 16, 0);
> > -	if (r != 0)
> > +	if (r != 0) {
> >  		dev_err(fbdev->dev, "unable to allocate color map
> memory\n");
> > +		unregister_framebuffer(info);
> > +	}
> >
> >  	return r;
> >  }
> > @@ -1773,15 +1782,8 @@ static int omapfb_do_probe(struct
> platform_device *pdev,
> >  	init_state++;
> >
> >  	vram = 0;
> > -	for (i = 0; i < fbdev->mem_desc.region_cnt; i++) {
> > -		r = register_framebuffer(fbdev->fb_info[i]);
> > -		if (r != 0) {
> > -			dev_err(fbdev->dev,
> > -				"registering framebuffer %d failed\n", i);
> > -			goto cleanup;
> > -		}
> > +	for (i = 0; i < fbdev->mem_desc.region_cnt; i++)
> >  		vram += fbdev->mem_desc.region[i].size;
> > -	}
> >
> >  	fbdev->state = OMAPFB_ACTIVE;
> >
> > --
> > 1.6.3.2
> >
> > --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linux-fbdev-devel] [RFC][PATCH] omapfb: Reorder Register_framebuffer call

[Gadiyar, A. <ga...@ti...>]

> From: Sergio Aguirre <saa...@ti...>
> 
> This fixes the issue in which mm_lock mutex was attempted to be
> used without initializing previously.
> 
> Signed-off-by: Sergio Aguirre <saa...@ti...>

Tested-by: Anand Gadiyar <ga...@ti...>

This patch on top of current linux-omap kernel allows me to
boot with the default SDP defconfig on a 3430 SDP.

- Anand


> ---
>  drivers/video/omap/omapfb_main.c |   20 +++++++++++---------
>  1 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
> index 125e605..60f9482 100644
> --- a/drivers/video/omap/omapfb_main.c
> +++ b/drivers/video/omap/omapfb_main.c
> @@ -1503,12 +1503,21 @@ static int fbinfo_init(struct omapfb_device *fbdev, struct fb_info *info)
>  	var->rotate	  = def_rotate;
>  	var->bits_per_pixel = fbdev->panel->bpp;
>  
> +	r = register_framebuffer(info);
> +	if (r != 0) {
> +		dev_err(fbdev->dev,
> +			"registering framebuffer failed\n");
> +		return r;
> +	}
> +
>  	set_fb_var(info, var);
>  	set_fb_fix(info);
>  
>  	r = fb_alloc_cmap(&info->cmap, 16, 0);
> -	if (r != 0)
> +	if (r != 0) {
>  		dev_err(fbdev->dev, "unable to allocate color map memory\n");
> +		unregister_framebuffer(info);
> +	}
>  
>  	return r;
>  }
> @@ -1773,15 +1782,8 @@ static int omapfb_do_probe(struct platform_device *pdev,
>  	init_state++;
>  
>  	vram = 0;
> -	for (i = 0; i < fbdev->mem_desc.region_cnt; i++) {
> -		r = register_framebuffer(fbdev->fb_info[i]);
> -		if (r != 0) {
> -			dev_err(fbdev->dev,
> -				"registering framebuffer %d failed\n", i);
> -			goto cleanup;
> -		}
> +	for (i = 0; i < fbdev->mem_desc.region_cnt; i++)
>  		vram += fbdev->mem_desc.region[i].size;
> -	}
>  
>  	fbdev->state = OMAPFB_ACTIVE;
>  
> -- 
> 1.6.3.2
> 
> 

Re: [Linux-fbdev-devel] [OT] - Is the sister "user" list still alive?

[Randy D. <rd...@xe...>]

On Thu, 3 Sep 2009 08:06:00 +0200 Geert Uytterhoeven wrote:

> On 2009-08-31, Randy Dunlap <rd...@xe...> wrote:
> > On Mon, 31 Aug 2009 21:52:03 +0200 Florian Tobias Schandinat wrote:
> >> Randy Dunlap schrieb:
> >> > On Mon, 31 Aug 2009 21:26:44 +0200 Florian Tobias Schandinat wrote:
> >> >> Randy Dunlap schrieb:
> >> >>> On Mon, 31 Aug 2009 13:55:22 -0400 Chris Jones wrote:
> >> >>>> I posted on linux-fbdev-users list re: an issued with dpms a couple
> >> >>>> of
> >> >>>> days ago and I was wondering if anyone is still subscribed to this
> >> >>>> list
> >> >>>> apart from myself.
> >> >>> Hi,
> >> >>> The -users mailing list has had 12 postings in 2009.
> >> >>> I'd say it's mostly dead.  Just use this (fbdev-devel) list.
> >> >> After having a look at the archive I agree.
> >> >> If this is the consensus wouldn't it be a good idea to shut the users
> >> >> list down and point to the devel mailing list to avoid misleading
> >> >> anyone? (perhaps -announce too?)
> >> >
> >> > Yes, that's a good idea.  Is it possible?
> >> > It used to be nearly impossible to kill off a mailing list at
> >> > sourceforge.net...
> >>
> >> I think it is.
> >> I was subscribed to a mailing list of this project:
> >> http://sourceforge.net/projects/rt2400/
> >> until they decided to move away from sourceforge and in this process
> >> shut the mailing lists they had there down. So it seems possible
> >> although I don't know the technical details how to do this.
> >
> > OK, thanks.
> >
> > Hi Otto,
> > Do you still maintain linux-fbdev.sf.net ?
> >
> > If so:  the fbdev-users mailing list is no longer being used.
> > Please try to shut it down and don't mention it on the FBDEV project web
> > pages.
> > Also, the fbdev-devel mailing list should be added to the project web pages
> > (lin...@li...).
> 
> My plan was to merge both lists and move them to vger. That would also
> relieve me from
> having to moderate postings from non-subscribers.
> 
> Unfortunately that hasn't happened yet due to my lack of time...

Other than asking davem for a new vger mailing list, what do you
plan to do?  Did you plan to auto-subscribe people to the new list?

I would just announce on the old lists that they will be dead
in one week's time -- don't try to subscribe people to the new list,
let them do that.

---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

[Linux-fbdev-devel] [PATCH v2 3/3] [ARM] s3c-fb: Added wait for VSYNC support.

[Pawel O. <p.o...@sa...>]

Added FBIO_WAITFORVSYNC ioctl that allows sleeping on vsync
waitqueue.

Reviewed-by: Marek Szyprowski <m.s...@sa...>
Reviewed-by: Kyungmin Park <kyu...@sa...>
Signed-off-by: Pawel Osciak <p.o...@sa...>

---
 drivers/video/s3c-fb.c |  170 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 168 insertions(+), 2 deletions(-)

diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 3dd4327..001a1a1 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -21,6 +21,8 @@
 #include <linux/clk.h>
 #include <linux/fb.h>
 #include <linux/io.h>
+#include <linux/uaccess.h>
+#include <linux/interrupt.h>
 
 #include <mach/map.h>
 #include <mach/regs-fb.h>
@@ -48,6 +50,13 @@
 	__raw_writel(v, r); } while(0)
 #endif /* FB_S3C_DEBUG_REGWRITE */
 
+/* Bit in irq_flags used to mark that interrupts are activated in device */
+#define S3C_FB_IRQ_ENABLED_BIT	0
+
+#ifndef FBIO_WAITFORVSYNC
+#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)
+#endif
+
 struct s3c_fb;
 
 /**
@@ -59,6 +68,7 @@ struct s3c_fb;
  * @pseudo_palette: For use in TRUECOLOUR modes for entries 0..15/
  * @index: The window number of this window.
  * @palette: The bitfields for changing r/g/b into a hardware palette entry.
+ * @vsync: Vsync handling helper.
  */
 struct s3c_fb_win {
 	struct s3c_fb_pd_win	*windata;
@@ -72,6 +82,16 @@ struct s3c_fb_win {
 };
 
 /**
+ * struct s3c_fb_vsync - vsync information for display.
+ * @vsync_queue: A queue for processes waiting for vsync.
+ * @vsync_count: Vsync interrupt count.
+ */
+struct s3c_fb_vsync {
+	wait_queue_head_t	vsync_queue;
+	unsigned long		vsync_count;
+};
+
+/**
  * struct s3c_fb - overall hardware state of the hardware
  * @dev: The device that we bound to, for printing, etc.
  * @regs_res: The resource we claimed for the IO registers.
@@ -80,6 +100,8 @@ struct s3c_fb_win {
  * @enabled: A bitmask of enabled hardware windows.
  * @pdata: The platform configuration data passed with the device.
  * @windows: The hardware windows that have been claimed.
+ * @irq_no: IRQ number for the device (acquired from platform data).
+ * @vsync_info: VSYNC-related information (count, queues...)
  */
 struct s3c_fb {
 	struct device		*dev;
@@ -87,10 +109,15 @@ struct s3c_fb {
 	struct clk		*bus_clk;
 	void __iomem		*regs;
 
-	unsigned char		 enabled;
+	unsigned char		enabled;
 
 	struct s3c_fb_platdata	*pdata;
 	struct s3c_fb_win	*windows[S3C_FB_MAX_WIN];
+
+	unsigned int		irq_no;
+	unsigned long		irq_flags;
+
+	struct s3c_fb_vsync	vsync_info;
 };
 
 /**
@@ -643,6 +670,103 @@ static int s3c_fb_blank(int blank_mode, struct fb_info *info)
 }
 
 /**
+ * s3c_fb_enable_irq() - enable interrupts in hardware.
+ * @sfb: The base resources for the hardware.
+ */
+static int s3c_fb_enable_irq(struct s3c_fb *sfb)
+{
+	u32	     irq_ctrl_reg;
+	void __iomem *regs = sfb->regs;
+
+	if (!test_and_set_bit(S3C_FB_IRQ_ENABLED_BIT, &sfb->irq_flags)) {
+		/* IRQ was disabled, enable it */
+		irq_ctrl_reg = readl(regs + VIDINTCON0);
+
+		irq_ctrl_reg |= VIDINTCON0_INT_ENABLE;
+		irq_ctrl_reg |= VIDINTCON0_INT_FRAME;
+
+		irq_ctrl_reg &= ~VIDINTCON0_FRAMESEL0_MASK;
+		irq_ctrl_reg |= VIDINTCON0_FRAMESEL0_VSYNC;
+		irq_ctrl_reg &= ~VIDINTCON0_FRAMESEL1_MASK;
+		irq_ctrl_reg |= VIDINTCON0_FRAMESEL1_NONE;
+
+		writel(irq_ctrl_reg, regs + VIDINTCON0);
+	}
+
+	return 0;
+}
+
+/**
+ * s3c_fb_disable_irq() - disable interrupts in hardware.
+ * @sfb: The base resources for the hardware.
+ */
+static int s3c_fb_disable_irq(struct s3c_fb *sfb)
+{
+	u32	     irq_ctrl_reg;
+	void __iomem *regs = sfb->regs;
+
+	if (test_and_clear_bit(S3C_FB_IRQ_ENABLED_BIT, &sfb->irq_flags)) {
+		/* IRQ was enabled, disable it */
+		irq_ctrl_reg = readl(regs + VIDINTCON0);
+
+		irq_ctrl_reg &= ~VIDINTCON0_INT_FRAME;
+		irq_ctrl_reg &= ~VIDINTCON0_INT_ENABLE;
+
+		writel(irq_ctrl_reg, regs + VIDINTCON0);
+	}
+
+	return 0;
+}
+
+static irqreturn_t s3c_fb_interrupt(int irq, void *dev_id)
+{
+	u32	      irq_sts_reg;
+	struct s3c_fb *sfb = dev_id;
+	void __iomem  *regs = sfb->regs;
+
+	irq_sts_reg = readl(regs + VIDINTCON1);
+
+	if (irq_sts_reg & VIDINTCON1_INT_FRAME) {
+
+		/* VSYNC interrupt, accept it */
+		writel(VIDINTCON1_INT_FRAME, regs + VIDINTCON1);
+
+		sfb->vsync_info.vsync_count++;
+		wake_up_interruptible(&sfb->vsync_info.vsync_queue);
+	}
+
+	/* We support only waiting for VSYNC interrupt for now,
+	 * so it's safe to disable irqs here. */
+	s3c_fb_disable_irq(sfb);
+
+	return IRQ_HANDLED;
+}
+
+/**
+ * s3c_fb_wait_for_vsync() - sleep until next VSYNC interrupt or timeout.
+ * @sfb: The base resources for the hardware.
+ * @crtc: Head index.
+ */
+static int s3c_fb_wait_for_vsync(struct s3c_fb *sfb, u32 crtc)
+{
+	unsigned long count;
+	int ret;
+
+	if (crtc != 0)
+		return -ENODEV;
+
+	s3c_fb_enable_irq(sfb);
+	count = sfb->vsync_info.vsync_count;
+	ret = wait_event_interruptible_timeout(sfb->vsync_info.vsync_queue,
+				       count != sfb->vsync_info.vsync_count,
+				       HZ / 10);
+	if (ret == 0)
+		return -ETIMEDOUT;
+
+	return 0;
+}
+
+/**
  * s3c_fb_pan_display() - Pan the display.
  *
  * Note, that the offsets can be written to the device at any time, as their
@@ -697,6 +821,27 @@ static int s3c_fb_pan_display(struct fb_var_screeninfo *var,
 	return 0;
 }
 
+static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
+			unsigned long arg)
+{
+	struct s3c_fb_win *win = info->par;
+	struct s3c_fb *sfb = win->parent;
+
+	switch (cmd) {
+	case FBIO_WAITFORVSYNC: {
+		u32 crtc;
+		if (get_user(crtc, (u32 __user *)arg))
+			return -EFAULT;
+
+		return s3c_fb_wait_for_vsync(sfb, crtc);
+		}
+	default:
+		return -ENOTTY;
+	}
+
+	return 0;
+}
+
 static struct fb_ops s3c_fb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_check_var	= s3c_fb_check_var,
@@ -706,6 +851,7 @@ static struct fb_ops s3c_fb_ops = {
 	.fb_fillrect	= cfb_fillrect,
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
+	.fb_ioctl	= s3c_fb_ioctl,
 	.fb_pan_display	= s3c_fb_pan_display,
 };
 
@@ -931,6 +1077,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
 
 	sfb->dev = dev;
 	sfb->pdata = pd;
+	init_waitqueue_head(&sfb->vsync_info.vsync_queue);
 
 	sfb->bus_clk = clk_get(dev, "lcd");
 	if (IS_ERR(sfb->bus_clk)) {
@@ -962,6 +1109,20 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
 		goto err_req_region;
 	}
 
+	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	if (!res) {
+		dev_err(dev, "failed to acquire irq resource\n");
+		ret = -ENOENT;
+		goto err_ioremap;
+	}
+	sfb->irq_no = res->start;
+	ret = request_irq(sfb->irq_no, s3c_fb_interrupt,
+			  0, "s3c_fb", sfb);
+	if (ret) {
+		dev_err(dev, "irq request failed\n");
+		goto err_ioremap;
+	}
+
 	dev_dbg(dev, "got resources (regs %p), probing windows\n", sfb->regs);
 
 	/* setup gpio and output polarity controls */
@@ -986,7 +1147,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
 			dev_err(dev, "failed to create window %d\n", win);
 			for (; win >= 0; win--)
 				s3c_fb_release_win(sfb, sfb->windows[win]);
-			goto err_ioremap;
+			goto err_irq;
 		}
 	}
 
@@ -994,6 +1155,9 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
 
 	return 0;
 
+err_irq:
+	free_irq(sfb->irq_no, sfb);
+
 err_ioremap:
 	iounmap(sfb->regs);
 
@@ -1026,6 +1190,8 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
 		if (sfb->windows[win])
 			s3c_fb_release_win(sfb, sfb->windows[win]);
 
+	free_irq(sfb->irq_no, sfb);
+
 	iounmap(sfb->regs);
 
 	clk_disable(sfb->bus_clk);
-- 
1.6.4.2.253.g0b1fac

[Linux-fbdev-devel] [PATCH v2 1/3] [ARM] s3c-fb: Corrected defines for framesel1 register.

[Pawel O. <p.o...@sa...>]

Reviewed-by: Marek Szyprowski <m.s...@sa...>
Reviewed-by: Kyungmin Park <kyu...@sa...>
Signed-off-by: Pawel Osciak <p.o...@sa...>

---
 arch/arm/plat-s3c/include/plat/regs-fb.h |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/plat-s3c/include/plat/regs-fb.h b/arch/arm/plat-s3c/include/plat/regs-fb.h
index e9ee599..8048cae 100644
--- a/arch/arm/plat-s3c/include/plat/regs-fb.h
+++ b/arch/arm/plat-s3c/include/plat/regs-fb.h
@@ -291,11 +291,12 @@
 #define VIDINTCON0_FRAMESEL0_ACTIVE		(0x2 << 15)
 #define VIDINTCON0_FRAMESEL0_FRONTPORCH		(0x3 << 15)
 
-#define VIDINTCON0_FRAMESEL1			(1 << 14)
-#define VIDINTCON0_FRAMESEL1_NONE		(0x0 << 14)
-#define VIDINTCON0_FRAMESEL1_BACKPORCH		(0x1 << 14)
-#define VIDINTCON0_FRAMESEL1_VSYNC		(0x2 << 14)
-#define VIDINTCON0_FRAMESEL1_FRONTPORCH		(0x3 << 14)
+#define VIDINTCON0_FRAMESEL1_MASK		(0x3 << 13)
+#define VIDINTCON0_FRAMESEL1_SHIFT		(13)
+#define VIDINTCON0_FRAMESEL1_NONE		(0x0 << 13)
+#define VIDINTCON0_FRAMESEL1_BACKPORCH		(0x1 << 13)
+#define VIDINTCON0_FRAMESEL1_VSYNC		(0x2 << 13)
+#define VIDINTCON0_FRAMESEL1_FRONTPORCH		(0x3 << 13)
 
 #define VIDINTCON0_INT_FRAME			(1 << 12)
 #define VIDINTCON0_FIFIOSEL_MASK		(0x7f << 5)
-- 
1.6.4.2.253.g0b1fac

[Linux-fbdev-devel] [PATCH v2 2/3] [ARM] s3c-fb: Added support for panning the display in both directions.

[Pawel O. <p.o...@sa...>]

This patch supports all bpp modes.

It includes a feature (a "protect" register) that blocks in-hardware
updates of registers which store start and end addresses of the fb memory
while it is turned on.

This prevents display corruption in case we don't make it before vsync with
updating both start and end registers.


Reviewed-by: Marek Szyprowski <m.s...@sa...>
Reviewed-by: Kyungmin Park <kyu...@sa...>
Signed-off-by: Pawel Osciak <p.o...@sa...>

---
 arch/arm/mach-s3c6400/include/mach/regs-fb.h |    5 ++
 drivers/video/s3c-fb.c                       |   58 ++++++++++++++++++++++++++
 2 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s3c6400/include/mach/regs-fb.h b/arch/arm/mach-s3c6400/include/mach/regs-fb.h
index 4701979..6339426 100644
--- a/arch/arm/mach-s3c6400/include/mach/regs-fb.h
+++ b/arch/arm/mach-s3c6400/include/mach/regs-fb.h
@@ -29,6 +29,11 @@
 #define S3C_FB_MAX_WIN (5)  /* number of hardware windows available. */
 #define VIDCON1_FSTATUS_EVEN	(1 << 15)
 
+/* Protect control register, turns on/off per-frame shadow registers update */
+#define PRTCON					(0x0C)
+#define PRTCON_PROTECT				(1 << 11)
+#define PRTCON_NOPROTECT			(0 << 11)
+
 /* Video timing controls */
 #define VIDTCON0				(0x10)
 #define VIDTCON1				(0x14)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 5a72083..3dd4327 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -294,6 +294,8 @@ static int s3c_fb_set_par(struct fb_info *info)
 	}
 
 	info->fix.line_length = (var->xres_virtual * var->bits_per_pixel) / 8;
+	info->fix.xpanstep = info->var.xres_virtual > info->var.xres ? 1 : 0;
+	info->fix.ypanstep = info->var.yres_virtual > info->var.yres ? 1 : 0;
 
 	/* disable the window whilst we update it */
 	writel(0, regs + WINCON(win_no));
@@ -640,6 +642,61 @@ static int s3c_fb_blank(int blank_mode, struct fb_info *info)
 	return 0;
 }
 
+/**
+ * s3c_fb_pan_display() - Pan the display.
+ *
+ * Note, that the offsets can be written to the device at any time, as their
+ * values are latched at each vsync automatically. This also means that only
+ * the last call to this function will have any effect on next vsync, but
+ * there is no need to sleep waiting for it to prevent tearing.
+ *
+ * @var: The screen information to verify.
+ * @info: The framebuffer device.
+ */
+static int s3c_fb_pan_display(struct fb_var_screeninfo *var,
+			      struct fb_info *info)
+{
+	struct s3c_fb_win *win	= info->par;
+	struct s3c_fb *sfb	= win->parent;
+	unsigned int start_byte_offset, end_byte_offset;
+
+	/* Offset in bytes to the start of the displayed area */
+	start_byte_offset = var->yoffset * info->fix.line_length;
+	/* X offset depends on the current bpp */
+	if (info->var.bits_per_pixel >= 8) {
+		start_byte_offset +=
+			var->xoffset * (info->var.bits_per_pixel >> 3);
+	} else {
+		switch (info->var.bits_per_pixel) {
+		case 4:
+			start_byte_offset += var->xoffset >> 1;
+			break;
+		case 2:
+			start_byte_offset += var->xoffset >> 2;
+			break;
+		case 1:
+			start_byte_offset += var->xoffset >> 3;
+			break;
+		default:
+			dev_err(sfb->dev, "invalid bpp\n");
+			return -EINVAL;
+		}
+	}
+	/* Offset in bytes to the end of the displayed area */
+	end_byte_offset = start_byte_offset + var->yres * info->fix.line_length;
+
+	/* Temporarily turn off per-frame shadow registers update until both
+	 * start and end are updated to prevent corruption */
+	writel(PRTCON_PROTECT, sfb->regs + PRTCON);
+	writel(info->fix.smem_start + start_byte_offset,
+	       sfb->regs + VIDW_BUF_START(win->index));
+	writel(info->fix.smem_start + end_byte_offset,
+	       sfb->regs + VIDW_BUF_END(win->index));
+	writel(PRTCON_NOPROTECT, sfb->regs + PRTCON);
+
+	return 0;
+}
+
 static struct fb_ops s3c_fb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_check_var	= s3c_fb_check_var,
@@ -649,6 +706,7 @@ static struct fb_ops s3c_fb_ops = {
 	.fb_fillrect	= cfb_fillrect,
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
+	.fb_pan_display	= s3c_fb_pan_display,
 };
 
 /**
-- 
1.6.4.2.253.g0b1fac

[Linux-fbdev-devel] [PATCH v2 0/3] v2: s3c-fb panning and vsync support

[Pawel O. <p.o...@sa...>]

Hello,

this is the second version of my previous patchset, corrected after your feedback (thank you).

[v2]:

In the panning patch:
* panning is done per-byte (the unit used in VIDW_BUF_START) and has been tested for different
bpps, including bpp < 8

* introduced the PRTCON register, which basically disables in-hardware updates from
shadow registers for VIDW_BUF_START/END (and a couple of others):
- shadow registers are updated on vsync (in hw)
- the update will not occur if PRTCON protection is enabled
This way we are safe when updating them at any time, even though they are separate.

In VSYNC patch:
* removed open() and release() functions as suggested (they were to disable interrupts at
release(), but this is already being taken care of in the isr)


The series contains:

[PATCH v2 1/3] [ARM] s3c-fb: Corrected defines for framesel1 register.
[PATCH v2 2/3] [ARM] s3c-fb: Added support for panning the display in both directions.
[PATCH v2 3/3] [ARM] s3c-fb: Added wait for VSYNC support.


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center

Re: [Linux-fbdev-devel] [OT] - Is the sister "user" list still alive?

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

On 2009-08-31, Randy Dunlap <rd...@xe...> wrote:
> On Mon, 31 Aug 2009 21:52:03 +0200 Florian Tobias Schandinat wrote:
>> Randy Dunlap schrieb:
>> > On Mon, 31 Aug 2009 21:26:44 +0200 Florian Tobias Schandinat wrote:
>> >> Randy Dunlap schrieb:
>> >>> On Mon, 31 Aug 2009 13:55:22 -0400 Chris Jones wrote:
>> >>>> I posted on linux-fbdev-users list re: an issued with dpms a couple
>> >>>> of
>> >>>> days ago and I was wondering if anyone is still subscribed to this
>> >>>> list
>> >>>> apart from myself.
>> >>> Hi,
>> >>> The -users mailing list has had 12 postings in 2009.
>> >>> I'd say it's mostly dead.  Just use this (fbdev-devel) list.
>> >> After having a look at the archive I agree.
>> >> If this is the consensus wouldn't it be a good idea to shut the users
>> >> list down and point to the devel mailing list to avoid misleading
>> >> anyone? (perhaps -announce too?)
>> >
>> > Yes, that's a good idea.  Is it possible?
>> > It used to be nearly impossible to kill off a mailing list at
>> > sourceforge.net...
>>
>> I think it is.
>> I was subscribed to a mailing list of this project:
>> http://sourceforge.net/projects/rt2400/
>> until they decided to move away from sourceforge and in this process
>> shut the mailing lists they had there down. So it seems possible
>> although I don't know the technical details how to do this.
>
> OK, thanks.
>
> Hi Otto,
> Do you still maintain linux-fbdev.sf.net ?
>
> If so:  the fbdev-users mailing list is no longer being used.
> Please try to shut it down and don't mention it on the FBDEV project web
> pages.
> Also, the fbdev-devel mailing list should be added to the project web pages
> (lin...@li...).

My plan was to merge both lists and move them to vger. That would also
relieve me from
having to moderate postings from non-subscribers.

Unfortunately that hasn't happened yet due to my lack of time...

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 4/4] video: add driver for PXA3xx 2D graphics accelerator

[Daniel M. <da...@ca...>]

On Wed, Jul 22, 2009 at 02:04:33PM +0200, Daniel Mack wrote:
> On Mon, Jul 20, 2009 at 10:45:35PM +0800, Eric Miao wrote:
> > Daniel Mack wrote:
> > >> Cool - I'll find a time slot to test this, and maybe someone else wants to
> > >> have a try either. Thanks.
> > > 
> > > Will that accelerator ID patch (the one I sent today) go thru your
> > > channel or are the fbdev people supposed to pick it?
> > > 
> > 
> > Better to go through fbdev people - or at least I need an Ack before it
> > goes through my tree.
> > 
> > Krzysztof Cc'ed.
> 
> Krzysztof,
> 
> resending this because I don't known whether you got the first copy of
> that patch.

I'm sending this patch for the the forth time now, this time with the
fbdev-devel list copied. Maybe that helps.

This is fairly simple, but it's blocking the pxa3xx-gcu driver to be
merged.

Any feedback is appreciated.

Thanks,
Daniel

>From 8b200756251e3dcdc91d506e9dbc9846ccaa91d3 Mon Sep 17 00:00:00 2001
From: Daniel Mack <da...@ca...>
Date: Mon, 20 Jul 2009 11:18:43 +0200
Subject: [PATCH] video: add PXA3xx accelerator ID

Add ID 99 for PXA3xx frame buffers and use it in pxafb when running on a
pxa with acceleration enabled.

Signed-off-by: Daniel Mack <da...@ca...>
Cc: Eric Miao <eri...@ma...>
Cc: lin...@li...
Cc: Dennis Oliver Kropp <do...@di...>
Cc: Sven Neumann <s.n...@ra...>
---
 drivers/video/pxafb.c |    5 +++++
 include/linux/fb.h    |    1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 3951cc5..922ed8a 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -2083,6 +2083,11 @@ static int __devinit pxafb_probe(struct platform_device *dev)
 		goto failed;
 	}
 
+#ifdef CONFIG_PXA3XX_GCU
+	if (cpu_is_pxa3xx())
+		fbi->fb.fix.accel = FB_ACCEL_PXA3XX;
+#endif
+
 	fbi->backlight_power = inf->pxafb_backlight_power;
 	fbi->lcd_power = inf->pxafb_lcd_power;
 
diff --git a/include/linux/fb.h b/include/linux/fb.h
index f847df9..a34bdf5 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -133,6 +133,7 @@ struct dentry;
 #define FB_ACCEL_NEOMAGIC_NM2230 96	/* NeoMagic NM2230              */
 #define FB_ACCEL_NEOMAGIC_NM2360 97	/* NeoMagic NM2360              */
 #define FB_ACCEL_NEOMAGIC_NM2380 98	/* NeoMagic NM2380              */
+#define FB_ACCEL_PXA3XX		 99	/* PXA3xx			*/
 
 #define FB_ACCEL_SAVAGE4        0x80	/* S3 Savage4                   */
 #define FB_ACCEL_SAVAGE3D       0x81	/* S3 Savage3D                  */
-- 
1.6.3.1

Re: [Linux-fbdev-devel] Garbled data on radeon KMS

[Rui S. <rs...@gr...>]

Alex Deucher wrote:
> On Tue, Sep 1, 2009 at 11:52 AM, Rui Santos<rs...@gr...> wrote:
>   
>> Hi all,
>>
>>    I'm trying to setup a secondary video card through radeon KMS
>> driver. I'm only using fbcon, no X.
>>    Every time I change to a console belonging to /dev/fb1 the kernel
>> crashes. I've setup a netconsole but I get no extra info from it. Just a
>> crash...
>>     
>
> What do you mean by crash?  lockup?  segfault?
>   
Hi Alex,

    It just locks.  fb0 is a i915 vesafb. fb1 is radeondrmfb. grub
contains fbcon=map:01. When I press Alt+F2, the secondary monitor gets
garbled and the machine just stops responding: No Alt+F1, no ping, no
info from netconsole, etc...

> Alex
>   
Rui

>   
>>    Here is the drm output:
>>
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Initialized drm 1.1.0
>>    20060810
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon default to
>>    kernel modesetting.
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon kernel
>>    modesetting enabled.
>>    Sep  1 15:42:54 ws1t1 user.info kernel: radeon 0000:01:0c.0:
>>    enabling device (0080 -> 0083)
>>    Sep  1 15:42:54 ws1t1 user.info kernel: radeon 0000:01:0c.0: PCI INT
>>    A -> GSI 18 (level, low) -> IRQ 18
>>    Sep  1 15:42:54 ws1t1 user.debug kernel: radeon 0000:01:0c.0:
>>    setting latency timer to 64
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: Initializing
>>    kernel modesetting.
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] register mmio base:
>>    0xFDEE0000
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] register mmio size: 65536
>>    Sep  1 15:42:54 ws1t1 user.debug kernel: Switched to high resolution
>>    mode on CPU 0
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] GPU reset succeed
>>    (RBBM_STATUS=0x00000140)
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] GPU not posted.
>>    posting now...
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Clocks initialized !
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Detected VRAM RAM=32M,
>>    BAR=128M
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] RAM width 32bits DDR
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: VRAM 32M
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: VRAM from
>>    0x00000000 to 0x03FFFFFF
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: VRAM less than
>>    aperture workaround enabled
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: GTT 512M
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: GTT from
>>    0x20000000 to 0x3FFFFFFF
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: irq initialized.
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [TTM] TTM available graphics
>>    memory: 247 MiB
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [TTM] TTM available object
>>    memory: 247 MiB
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: 32M of VRAM
>>    memory ready
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: 512M of GTT
>>    memory ready.
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] GART: num cpu pages
>>    131072, num gpu pages 131072
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: cp idle
>>    (0x00008080)
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Loading R100 Microcode
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: ring at
>>    0x0000000020000000
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] ring test succeeded in
>>    1 usecs
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: ib pool ready.
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] ib test succeeded in 0
>>    usecs
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Radeon Display Connectors
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Connector 0:
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]   VGA
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]   DDC: 0x60 0x60 0x60
>>    0x60 0x60 0x60 0x60 0x60
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]   Encoders:
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]     CRT1: INTERNAL_DAC1
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] fb mappable at 0xD8040000
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] vram apper at 0xD8000000
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] size 5242880
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] fb depth is 24
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]    pitch is 5120
>>    Sep  1 15:42:54 ws1t1 user.info kernel: fb1: radeondrmfb frame
>>    buffer device
>>    Sep  1 15:42:54 ws1t1 user.info kernel: registered panic notifier
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: kernel
>>    modesetting successfully initialized.
>>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Initialized radeon
>>    2.0.0 20080528 for 0000:01:0c.0 on minor 0
>>
>>    lspci -vvv:
>>
>> 01:0c.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
>> [Radeon 7000/VE] (prog-if 00 [VGA controller])
>>        Subsystem: ATI Technologies Inc Device 013b
>>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping+ SERR- FastB2B- DisINTx-
>>        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>        Latency: 64 (2000ns min), Cache Line Size: 64 bytes
>>        Interrupt: pin A routed to IRQ 18
>>        Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
>>        Region 1: I/O ports at dc00 [size=256]
>>        Region 2: Memory at fdee0000 (32-bit, non-prefetchable) [size=64K]
>>        Expansion ROM at fde00000 [disabled] [size=128K]
>>        Capabilities: [50] Power Management version 2
>>                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>        Kernel driver in use: radeon
>>        Kernel modules: radeonfb
>>
>>    Can anyone help me with some debug or, maybe I'm not just doing it
>> right... I also found little documentation on the subject...
>>
>> Thanks for you help,
>> Rui Santos
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Linux-fbdev-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>>
>>     
>
>
>
>   

-- 

Cumprimentos

*Rui Santos*
Dep. Testes

*GrupoPIE Portugal, S.A.*
Tel:   +351 252 290 600
Fax:  +351 252 290 601

Email: rs...@gr... <mailto:rs...@gr...>
Web: www.grupopie.com <http://www.grupopie.com/>

/WinREST /EVERYWHERE

Re: [Linux-fbdev-devel] Garbled data on radeon KMS

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

On Tue, Sep 1, 2009 at 11:52 AM, Rui Santos<rs...@gr...> wrote:
> Hi all,
>
>    I'm trying to setup a secondary video card through radeon KMS
> driver. I'm only using fbcon, no X.
>    Every time I change to a console belonging to /dev/fb1 the kernel
> crashes. I've setup a netconsole but I get no extra info from it. Just a
> crash...

What do you mean by crash?  lockup?  segfault?

Alex

>    Here is the drm output:
>
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Initialized drm 1.1.0
>    20060810
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon default to
>    kernel modesetting.
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon kernel
>    modesetting enabled.
>    Sep  1 15:42:54 ws1t1 user.info kernel: radeon 0000:01:0c.0:
>    enabling device (0080 -> 0083)
>    Sep  1 15:42:54 ws1t1 user.info kernel: radeon 0000:01:0c.0: PCI INT
>    A -> GSI 18 (level, low) -> IRQ 18
>    Sep  1 15:42:54 ws1t1 user.debug kernel: radeon 0000:01:0c.0:
>    setting latency timer to 64
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: Initializing
>    kernel modesetting.
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] register mmio base:
>    0xFDEE0000
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] register mmio size: 65536
>    Sep  1 15:42:54 ws1t1 user.debug kernel: Switched to high resolution
>    mode on CPU 0
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] GPU reset succeed
>    (RBBM_STATUS=0x00000140)
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] GPU not posted.
>    posting now...
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Clocks initialized !
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Detected VRAM RAM=32M,
>    BAR=128M
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] RAM width 32bits DDR
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: VRAM 32M
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: VRAM from
>    0x00000000 to 0x03FFFFFF
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: VRAM less than
>    aperture workaround enabled
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: GTT 512M
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: GTT from
>    0x20000000 to 0x3FFFFFFF
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: irq initialized.
>    Sep  1 15:42:54 ws1t1 user.info kernel: [TTM] TTM available graphics
>    memory: 247 MiB
>    Sep  1 15:42:54 ws1t1 user.info kernel: [TTM] TTM available object
>    memory: 247 MiB
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: 32M of VRAM
>    memory ready
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: 512M of GTT
>    memory ready.
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] GART: num cpu pages
>    131072, num gpu pages 131072
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: cp idle
>    (0x00008080)
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Loading R100 Microcode
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: ring at
>    0x0000000020000000
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] ring test succeeded in
>    1 usecs
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: ib pool ready.
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] ib test succeeded in 0
>    usecs
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Radeon Display Connectors
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Connector 0:
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]   VGA
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]   DDC: 0x60 0x60 0x60
>    0x60 0x60 0x60 0x60 0x60
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]   Encoders:
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]     CRT1: INTERNAL_DAC1
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] fb mappable at 0xD8040000
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] vram apper at 0xD8000000
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] size 5242880
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] fb depth is 24
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]    pitch is 5120
>    Sep  1 15:42:54 ws1t1 user.info kernel: fb1: radeondrmfb frame
>    buffer device
>    Sep  1 15:42:54 ws1t1 user.info kernel: registered panic notifier
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: kernel
>    modesetting successfully initialized.
>    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Initialized radeon
>    2.0.0 20080528 for 0000:01:0c.0 on minor 0
>
>    lspci -vvv:
>
> 01:0c.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
> [Radeon 7000/VE] (prog-if 00 [VGA controller])
>        Subsystem: ATI Technologies Inc Device 013b
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping+ SERR- FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>        Latency: 64 (2000ns min), Cache Line Size: 64 bytes
>        Interrupt: pin A routed to IRQ 18
>        Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
>        Region 1: I/O ports at dc00 [size=256]
>        Region 2: Memory at fdee0000 (32-bit, non-prefetchable) [size=64K]
>        Expansion ROM at fde00000 [disabled] [size=128K]
>        Capabilities: [50] Power Management version 2
>                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>        Kernel driver in use: radeon
>        Kernel modules: radeonfb
>
>    Can anyone help me with some debug or, maybe I'm not just doing it
> right... I also found little documentation on the subject...
>
> Thanks for you help,
> Rui Santos
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

[Linux-fbdev-devel] Garbled data on radeon KMS

[Rui S. <rs...@gr...>]

Hi all,

    I'm trying to setup a secondary video card through radeon KMS
driver. I'm only using fbcon, no X.
    Every time I change to a console belonging to /dev/fb1 the kernel
crashes. I've setup a netconsole but I get no extra info from it. Just a
crash...
    Here is the drm output:

    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Initialized drm 1.1.0
    20060810
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon default to
    kernel modesetting.
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon kernel
    modesetting enabled.
    Sep  1 15:42:54 ws1t1 user.info kernel: radeon 0000:01:0c.0:
    enabling device (0080 -> 0083)
    Sep  1 15:42:54 ws1t1 user.info kernel: radeon 0000:01:0c.0: PCI INT
    A -> GSI 18 (level, low) -> IRQ 18
    Sep  1 15:42:54 ws1t1 user.debug kernel: radeon 0000:01:0c.0:
    setting latency timer to 64
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: Initializing
    kernel modesetting.
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] register mmio base:
    0xFDEE0000
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] register mmio size: 65536
    Sep  1 15:42:54 ws1t1 user.debug kernel: Switched to high resolution
    mode on CPU 0
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] GPU reset succeed
    (RBBM_STATUS=0x00000140)
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] GPU not posted.
    posting now...
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Clocks initialized !
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Detected VRAM RAM=32M,
    BAR=128M
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] RAM width 32bits DDR
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: VRAM 32M
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: VRAM from
    0x00000000 to 0x03FFFFFF
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: VRAM less than
    aperture workaround enabled
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: GTT 512M
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: GTT from
    0x20000000 to 0x3FFFFFFF
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: irq initialized.
    Sep  1 15:42:54 ws1t1 user.info kernel: [TTM] TTM available graphics
    memory: 247 MiB
    Sep  1 15:42:54 ws1t1 user.info kernel: [TTM] TTM available object
    memory: 247 MiB
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: 32M of VRAM
    memory ready
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: 512M of GTT
    memory ready.
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] GART: num cpu pages
    131072, num gpu pages 131072
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: cp idle
    (0x00008080)
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Loading R100 Microcode
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: ring at
    0x0000000020000000
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] ring test succeeded in
    1 usecs
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: ib pool ready.
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] ib test succeeded in 0
    usecs
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Radeon Display Connectors
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Connector 0:
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]   VGA
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]   DDC: 0x60 0x60 0x60
    0x60 0x60 0x60 0x60 0x60
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]   Encoders:
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]     CRT1: INTERNAL_DAC1
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] fb mappable at 0xD8040000
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] vram apper at 0xD8000000
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] size 5242880
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] fb depth is 24
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm]    pitch is 5120
    Sep  1 15:42:54 ws1t1 user.info kernel: fb1: radeondrmfb frame
    buffer device
    Sep  1 15:42:54 ws1t1 user.info kernel: registered panic notifier
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] radeon: kernel
    modesetting successfully initialized.
    Sep  1 15:42:54 ws1t1 user.info kernel: [drm] Initialized radeon
    2.0.0 20080528 for 0000:01:0c.0 on minor 0

    lspci -vvv:

01:0c.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE] (prog-if 00 [VGA controller])
        Subsystem: ATI Technologies Inc Device 013b
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (2000ns min), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at dc00 [size=256]
        Region 2: Memory at fdee0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at fde00000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: radeon
        Kernel modules: radeonfb

    Can anyone help me with some debug or, maybe I'm not just doing it
right... I also found little documentation on the subject...

Thanks for you help,
Rui Santos

Re: [Linux-fbdev-devel] [OT] - Is the sister "user" list still alive?

[Randy D. <rd...@xe...>]

On Mon, 31 Aug 2009 21:52:03 +0200 Florian Tobias Schandinat wrote:

> Hi,
> 
> Randy Dunlap schrieb:
> > On Mon, 31 Aug 2009 21:26:44 +0200 Florian Tobias Schandinat wrote:
> > 
> >> Hi,
> >>
> >> Randy Dunlap schrieb:
> >>> On Mon, 31 Aug 2009 13:55:22 -0400 Chris Jones wrote:
> >>>
> >>>> I posted on linux-fbdev-users list re: an issued with dpms a couple of
> >>>> days ago and I was wondering if anyone is still subscribed to this list
> >>>> apart from myself.
> >>> Hi,
> >>> The -users mailing list has had 12 postings in 2009.
> >>> I'd say it's mostly dead.  Just use this (fbdev-devel) list.
> >> After having a look at the archive I agree.
> >> If this is the consensus wouldn't it be a good idea to shut the users 
> >> list down and point to the devel mailing list to avoid misleading 
> >> anyone? (perhaps -announce too?)
> > 
> > Yes, that's a good idea.  Is it possible?
> > It used to be nearly impossible to kill off a mailing list at sourceforge.net...
> 
> I think it is.
> I was subscribed to a mailing list of this project:
> http://sourceforge.net/projects/rt2400/
> until they decided to move away from sourceforge and in this process 
> shut the mailing lists they had there down. So it seems possible 
> although I don't know the technical details how to do this.

OK, thanks.

Hi Otto,
Do you still maintain linux-fbdev.sf.net ?

If so:  the fbdev-users mailing list is no longer being used.
Please try to shut it down and don't mention it on the FBDEV project web pages.
Also, the fbdev-devel mailing list should be added to the project web pages
(lin...@li...).


thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [Linux-fbdev-devel] [OT] - Is the sister "user" list still alive?

[Florian T. S. <Flo...@gm...>]

Hi,

Randy Dunlap schrieb:
> On Mon, 31 Aug 2009 21:26:44 +0200 Florian Tobias Schandinat wrote:
> 
>> Hi,
>>
>> Randy Dunlap schrieb:
>>> On Mon, 31 Aug 2009 13:55:22 -0400 Chris Jones wrote:
>>>
>>>> I posted on linux-fbdev-users list re: an issued with dpms a couple of
>>>> days ago and I was wondering if anyone is still subscribed to this list
>>>> apart from myself.
>>> Hi,
>>> The -users mailing list has had 12 postings in 2009.
>>> I'd say it's mostly dead.  Just use this (fbdev-devel) list.
>> After having a look at the archive I agree.
>> If this is the consensus wouldn't it be a good idea to shut the users 
>> list down and point to the devel mailing list to avoid misleading 
>> anyone? (perhaps -announce too?)
> 
> Yes, that's a good idea.  Is it possible?
> It used to be nearly impossible to kill off a mailing list at sourceforge.net...

I think it is.
I was subscribed to a mailing list of this project:
http://sourceforge.net/projects/rt2400/
until they decided to move away from sourceforge and in this process 
shut the mailing lists they had there down. So it seems possible 
although I don't know the technical details how to do this.


Regards,

Florian Tobias Schandinat

Re: [Linux-fbdev-devel] [OT] - Is the sister "user" list still alive?

[Randy D. <rd...@xe...>]

On Mon, 31 Aug 2009 21:26:44 +0200 Florian Tobias Schandinat wrote:

> Hi,
> 
> Randy Dunlap schrieb:
> > On Mon, 31 Aug 2009 13:55:22 -0400 Chris Jones wrote:
> > 
> >> I posted on linux-fbdev-users list re: an issued with dpms a couple of
> >> days ago and I was wondering if anyone is still subscribed to this list
> >> apart from myself.
> > 
> > Hi,
> > The -users mailing list has had 12 postings in 2009.
> > I'd say it's mostly dead.  Just use this (fbdev-devel) list.
> 
> After having a look at the archive I agree.
> If this is the consensus wouldn't it be a good idea to shut the users 
> list down and point to the devel mailing list to avoid misleading 
> anyone? (perhaps -announce too?)

Yes, that's a good idea.  Is it possible?
It used to be nearly impossible to kill off a mailing list at sourceforge.net...


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [Linux-fbdev-devel] [OT] - Is the sister "user" list still alive?

[Florian T. S. <Flo...@gm...>]

Hi,

Randy Dunlap schrieb:
> On Mon, 31 Aug 2009 13:55:22 -0400 Chris Jones wrote:
> 
>> I posted on linux-fbdev-users list re: an issued with dpms a couple of
>> days ago and I was wondering if anyone is still subscribed to this list
>> apart from myself.
> 
> Hi,
> The -users mailing list has had 12 postings in 2009.
> I'd say it's mostly dead.  Just use this (fbdev-devel) list.

After having a look at the archive I agree.
If this is the consensus wouldn't it be a good idea to shut the users 
list down and point to the devel mailing list to avoid misleading 
anyone? (perhaps -announce too?)


Regards,

Florian Tobias Schandinat

[Linux-fbdev-devel] Turn off LCD back light.

[Chris J. <cjn...@gm...>]

Hopefully, this is the correct place to ask such questions - I tried the
fbdev-users mailing list a couple of days ago, but is looks like it's
not currently very active.

I would like my laptop's  LCD panel to switch itself off automatically
after a few minutes of inactivity.

The /etc/kbd/config file specifies:

BLANK_DPMS=on
POWERDOWN_TIME=2

The /etc/init.d/console-screen.kbd.sh script appears to issue a setterm
command with the above options a boot time, yet nothing happens.

I issued the corresponding "setterm" command manually also to no effect.

Is there something that I need to configure in the linux kernel?

Is this a limitation of the frambuffer console with the atyfb driver?

Manually executing "vbetool dpms off" does the trick, so it doesn't look
like this is a hardware limitation per se.

The video card is an ATI Technologies Rage Mobility P/M AGP 2x (rev 64).

Relevant (?) software:

linux-image      :       2.6.26-1-686
acpid            :       1.0.8-1
util-linux       :       2.13.1.1-1
kbd              :       1.14.1-4

Thanks,

CJ.

Re: [Linux-fbdev-devel] [OT] - Is the sister "user" list still alive?

[Chris J. <cjn...@gm...>]

On Mon, Aug 31, 2009 at 02:01:24PM EDT, Randy Dunlap wrote:
> On Mon, 31 Aug 2009 13:55:22 -0400 Chris Jones wrote:
> 
> > I posted on linux-fbdev-users list re: an issued with dpms a couple
> > of days ago and I was wondering if anyone is still subscribed to
> > this list apart from myself.

> Hi,
> The -users mailing list has had 12 postings in 2009.
> I'd say it's mostly dead.  Just use this (fbdev-devel) list.

Thanks, pretty much confirms what I saw in the list's archive.

CJ

Re: [Linux-fbdev-devel] [OT] - Is the sister "user" list still alive?

[Randy D. <rd...@xe...>]

On Mon, 31 Aug 2009 13:55:22 -0400 Chris Jones wrote:

> I posted on linux-fbdev-users list re: an issued with dpms a couple of
> days ago and I was wondering if anyone is still subscribed to this list
> apart from myself.

Hi,
The -users mailing list has had 12 postings in 2009.
I'd say it's mostly dead.  Just use this (fbdev-devel) list.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

[Linux-fbdev-devel] [OT] - Is the sister "user" list still alive?

[Chris J. <cjn...@gm...>]

I posted on linux-fbdev-users list re: an issued with dpms a couple of
days ago and I was wondering if anyone is still subscribed to this list
apart from myself.

Thanks,

CJ

[Linux-fbdev-devel] [PATCH] viafb: 2D engine rewrite

[Florian T. S. <Flo...@gm...>]

viafb: 2D engine rewrite

This patch is a completly rewritten 2D engine. The engine is no longer
in a default state but reinitialized every time to allow usage for both
framebuffers regardless of their settings.
The whole engine handling is concentrated in a big function which takes
16 parameters. Although the number of parameters is worryingly it is
good to have a single funtion to deal with this stuff as it allows to
easily support different engines and avoids some code duplication.
On the way support for the new 2D engine in VX800 was added. As the
difference is only in the register addresses it could be done in a way
with less code duplication but it is probably better to duplicate the
code as this way is easier to walk if VIA ever decides to release a new
engine which changes anything the driver touches.
The engine support for VX800 gives a notable boost in speed. There are
no known regressions but as this patch changes paths I do neither have
the hardware nor documentation to check and has the possibility to put
the system in a critical state heavy testing is appreciated.

Signed-off-by: Florian Tobias Schandinat <Flo...@gm...>
---
 accel.c    |  311 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
 accel.h    |    7 +-
 viafbdev.c |  224 +++++++++++--------------------------------
 viafbdev.h |    8 ++
 4 files changed, 329 insertions(+), 221 deletions(-)

diff --git a/drivers/video/via/accel.c b/drivers/video/via/accel.c
index b3e7e82..09615fe 100644
--- a/drivers/video/via/accel.c
+++ b/drivers/video/via/accel.c
@@ -20,8 +20,264 @@
  */
 #include "global.h"
 
-void viafb_init_accel(void)
+static int hw_bitblt_1(void __iomem *engine, u8 op, u32 width, u32 height,
+	u8 dst_bpp, u32 dst_addr, u32 dst_pitch, u32 dst_x, u32 dst_y,
+	u32 *src_mem, u32 src_addr, u32 src_pitch, u32 src_x, u32 src_y,
+	u32 fg_color, u32 bg_color, u8 fill_rop)
 {
+	u32 tmp, i;
+
+	if (!op || op > 3) {
+		printk(KERN_WARNING "hw_bitblt_1: Invalid operation: %d\n", op);
+		return -EINVAL;
+	}
+
+	switch (dst_bpp) {
+	case 8:
+		tmp = 0x00000000;
+		break;
+	case 16:
+		tmp = 0x00000100;
+		break;
+	case 32:
+		tmp = 0x00000300;
+		break;
+	default:
+		printk(KERN_WARNING "hw_bitblt_1: Unsupported bpp %d\n",
+			dst_bpp);
+		return -EINVAL;
+	}
+	writel(tmp, engine + 0x04);
+
+	if (op != VIA_BITBLT_FILL) {
+		if (src_x & (op == VIA_BITBLT_MONO ? 0xFFFF8000 : 0xFFFFF000)
+			|| src_y & 0xFFFFF000) {
+			printk(KERN_WARNING "hw_bitblt_1: Unsupported source "
+				"x/y %d %d\n", src_x, src_y);
+			return -EINVAL;
+		}
+		tmp = src_x | (src_y << 16);
+		writel(tmp, engine + 0x08);
+	}
+
+	if (dst_x & 0xFFFFF000 || dst_y & 0xFFFFF000) {
+		printk(KERN_WARNING "hw_bitblt_1: Unsupported destination x/y "
+			"%d %d\n", dst_x, dst_y);
+		return -EINVAL;
+	}
+	tmp = dst_x | (dst_y << 16);
+	writel(tmp, engine + 0x0C);
+
+	if ((width - 1) & 0xFFFFF000 || (height - 1) & 0xFFFFF000) {
+		printk(KERN_WARNING "hw_bitblt_1: Unsupported width/height "
+			"%d %d\n", width, height);
+		return -EINVAL;
+	}
+	tmp = (width - 1) | ((height - 1) << 16);
+	writel(tmp, engine + 0x10);
+
+	if (op != VIA_BITBLT_COLOR)
+		writel(fg_color, engine + 0x18);
+
+	if (op == VIA_BITBLT_MONO)
+		writel(bg_color, engine + 0x1C);
+
+	if (op != VIA_BITBLT_FILL) {
+		tmp = src_mem ? 0 : src_addr;
+		if (dst_addr & 0xE0000007) {
+			printk(KERN_WARNING "hw_bitblt_1: Unsupported source "
+				"address %X\n", tmp);
+			return -EINVAL;
+		}
+		tmp >>= 3;
+		writel(tmp, engine + 0x30);
+	}
+
+	if (dst_addr & 0xE0000007) {
+		printk(KERN_WARNING "hw_bitblt_1: Unsupported destination "
+			"address %X\n", dst_addr);
+		return -EINVAL;
+	}
+	tmp = dst_addr >> 3;
+	writel(tmp, engine + 0x34);
+
+	if (op == VIA_BITBLT_FILL)
+		tmp = 0;
+	else
+		tmp = src_pitch;
+	if (tmp & 0xFFFFC007 || dst_pitch & 0xFFFFC007) {
+		printk(KERN_WARNING "hw_bitblt_1: Unsupported pitch %X %X\n",
+			tmp, dst_pitch);
+		return -EINVAL;
+	}
+	tmp = (tmp >> 3) | (dst_pitch << (16 - 3));
+	writel(tmp, engine + 0x38);
+
+	tmp = 0;
+	if (op == VIA_BITBLT_FILL)
+		tmp |= fill_rop << 24 | 0x00002000 | 0x00000001;
+	else {
+		tmp = 0xCC000000; /* ROP=SRCCOPY */
+		if (src_mem)
+			tmp |= 0x00000040;
+		if (op == VIA_BITBLT_MONO)
+			tmp |= 0x00000002 | 0x00000100 | 0x00020000;
+		else
+			tmp |= 0x00000001;
+	}
+	writel(tmp, engine);
+
+	if (op == VIA_BITBLT_FILL || !src_mem)
+		return 0;
+
+	tmp = (width * height * (op == VIA_BITBLT_MONO ? 1 : (dst_bpp >> 3)) +
+		3) >> 2;
+
+	for (i = 0; i < tmp; i++)
+		writel(src_mem[i], engine + VIA_MMIO_BLTBASE);
+
+	return 0;
+}
+
+static int hw_bitblt_2(void __iomem *engine, u8 op, u32 width, u32 height,
+	u8 dst_bpp, u32 dst_addr, u32 dst_pitch, u32 dst_x, u32 dst_y,
+	u32 *src_mem, u32 src_addr, u32 src_pitch, u32 src_x, u32 src_y,
+	u32 fg_color, u32 bg_color, u8 fill_rop)
+{
+	u32 tmp, i;
+
+	if (!op || op > 3) {
+		printk(KERN_WARNING "hw_bitblt_2: Invalid operation: %d\n", op);
+		return -EINVAL;
+	}
+
+	switch (dst_bpp) {
+	case 8:
+		tmp = 0x00000000;
+		break;
+	case 16:
+		tmp = 0x00000100;
+		break;
+	case 32:
+		tmp = 0x00000300;
+		break;
+	default:
+		printk(KERN_WARNING "hw_bitblt_2: Unsupported bpp %d\n",
+			dst_bpp);
+		return -EINVAL;
+	}
+	writel(tmp, engine + 0x04);
+
+	if (op == VIA_BITBLT_FILL)
+		tmp = 0;
+	else
+		tmp = src_pitch;
+	if (tmp & 0xFFFFC007 || dst_pitch & 0xFFFFC007) {
+		printk(KERN_WARNING "hw_bitblt_2: Unsupported pitch %X %X\n",
+			tmp, dst_pitch);
+		return -EINVAL;
+	}
+	tmp = (tmp >> 3) | (dst_pitch << (16 - 3));
+	writel(tmp, engine + 0x08);
+
+	if ((width - 1) & 0xFFFFF000 || (height - 1) & 0xFFFFF000) {
+		printk(KERN_WARNING "hw_bitblt_2: Unsupported width/height "
+			"%d %d\n", width, height);
+		return -EINVAL;
+	}
+	tmp = (width - 1) | ((height - 1) << 16);
+	writel(tmp, engine + 0x0C);
+
+	if (dst_x & 0xFFFFF000 || dst_y & 0xFFFFF000) {
+		printk(KERN_WARNING "hw_bitblt_2: Unsupported destination x/y "
+			"%d %d\n", dst_x, dst_y);
+		return -EINVAL;
+	}
+	tmp = dst_x | (dst_y << 16);
+	writel(tmp, engine + 0x10);
+
+	if (dst_addr & 0xE0000007) {
+		printk(KERN_WARNING "hw_bitblt_2: Unsupported destination "
+			"address %X\n", dst_addr);
+		return -EINVAL;
+	}
+	tmp = dst_addr >> 3;
+	writel(tmp, engine + 0x14);
+
+	if (op != VIA_BITBLT_FILL) {
+		if (src_x & (op == VIA_BITBLT_MONO ? 0xFFFF8000 : 0xFFFFF000)
+			|| src_y & 0xFFFFF000) {
+			printk(KERN_WARNING "hw_bitblt_2: Unsupported source "
+				"x/y %d %d\n", src_x, src_y);
+			return -EINVAL;
+		}
+		tmp = src_x | (src_y << 16);
+		writel(tmp, engine + 0x18);
+
+		tmp = src_mem ? 0 : src_addr;
+		if (dst_addr & 0xE0000007) {
+			printk(KERN_WARNING "hw_bitblt_2: Unsupported source "
+				"address %X\n", tmp);
+			return -EINVAL;
+		}
+		tmp >>= 3;
+		writel(tmp, engine + 0x1C);
+	}
+
+	if (op != VIA_BITBLT_COLOR)
+		writel(fg_color, engine + 0x4C);
+
+	if (op == VIA_BITBLT_MONO)
+		writel(bg_color, engine + 0x50);
+
+	tmp = 0;
+	if (op == VIA_BITBLT_FILL)
+		tmp |= fill_rop << 24 | 0x00002000 | 0x00000001;
+	else {
+		tmp = 0xCC000000; /* ROP=SRCCOPY */
+		if (src_mem)
+			tmp |= 0x00000040;
+		if (op == VIA_BITBLT_MONO)
+			tmp |= 0x00000002 | 0x00000100 | 0x00020000;
+		else
+			tmp |= 0x00000001;
+	}
+	writel(tmp, engine);
+
+	if (op == VIA_BITBLT_FILL || !src_mem)
+		return 0;
+
+	tmp = (width * height * (op == VIA_BITBLT_MONO ? 1 : (dst_bpp >> 3)) +
+		3) >> 2;
+
+	for (i = 0; i < tmp; i++)
+		writel(src_mem[i], engine + VIA_MMIO_BLTBASE);
+
+	return 0;
+}
+
+void viafb_init_accel(struct viafb_shared *shared)
+{
+	switch (shared->chip_info.gfx_chip_name) {
+	case UNICHROME_CLE266:
+	case UNICHROME_K400:
+	case UNICHROME_K800:
+	case UNICHROME_PM800:
+	case UNICHROME_CN700:
+	case UNICHROME_CX700:
+	case UNICHROME_CN750:
+	case UNICHROME_K8M890:
+	case UNICHROME_P4M890:
+	case UNICHROME_P4M900:
+		shared->hw_bitblt = hw_bitblt_1;
+		break;
+	case UNICHROME_VX800:
+		shared->hw_bitblt = hw_bitblt_2;
+		break;
+	default:
+		shared->hw_bitblt = NULL;
+	}
+
 	viaparinfo->fbmem_free -= CURSOR_SIZE;
 	viaparinfo->cursor_start = viaparinfo->fbmem_free;
 	viaparinfo->fbmem_used += CURSOR_SIZE;
@@ -30,30 +286,14 @@ void viafb_init_accel(void)
 	viaparinfo->fbmem_free -= (CURSOR_SIZE + VQ_SIZE);
 	viaparinfo->VQ_start = viaparinfo->fbmem_free;
 	viaparinfo->VQ_end = viaparinfo->VQ_start + VQ_SIZE - 1;
-	viaparinfo->fbmem_used += (CURSOR_SIZE + VQ_SIZE); }
+	viaparinfo->fbmem_used += (CURSOR_SIZE + VQ_SIZE);
+}
 
 void viafb_init_2d_engine(void)
 {
-	u32 dwVQStartAddr, dwVQEndAddr, linesize;
+	u32 dwVQStartAddr, dwVQEndAddr;
 	u32 dwVQLen, dwVQStartL, dwVQEndL, dwVQStartEndH;
 
-	/* init 2D engine regs to reset 2D engine */
-	writel(0x0, viaparinfo->io_virt + VIA_REG_GEMODE);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_SRCPOS);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_DSTPOS);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_DIMENSION);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_PATADDR);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_FGCOLOR);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_BGCOLOR);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_CLIPTL);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_CLIPBR);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_OFFSET);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_KEYCONTROL);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_SRCBASE);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_DSTBASE);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_PITCH);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_MONOPAT1);
-
 	/* Init AGP and VQ regs */
 	switch (viaparinfo->chip_info->gfx_chip_name) {
 	case UNICHROME_K8M890:
@@ -190,37 +430,6 @@ void viafb_init_2d_engine(void)
 			break;
 		}
 	}
-
-	viafb_set_2d_color_depth(viafbinfo->var.bits_per_pixel);
-
-	writel(0x0, viaparinfo->io_virt + VIA_REG_SRCBASE);
-	writel(0x0, viaparinfo->io_virt + VIA_REG_DSTBASE);
-
-	linesize = viafbinfo->var.xres * viafbinfo->var.bits_per_pixel >> 3;
-	writel(VIA_PITCH_ENABLE | (linesize >> 3) | ((linesize >> 3) << 16),
-		viaparinfo->io_virt + VIA_REG_PITCH);
-}
-
-void viafb_set_2d_color_depth(int bpp)
-{
-	u32 dwGEMode;
-
-	dwGEMode = readl(viaparinfo->io_virt + 0x04) & 0xFFFFFCFF;
-
-	switch (bpp) {
-	case 16:
-		dwGEMode |= VIA_GEM_16bpp;
-		break;
-	case 32:
-		dwGEMode |= VIA_GEM_32bpp;
-		break;
-	default:
-		dwGEMode |= VIA_GEM_8bpp;
-		break;
-	}
-
-	/* Set BPP and Pitch */
-	writel(dwGEMode, viaparinfo->io_virt + VIA_REG_GEMODE);
 }
 
 void viafb_hw_cursor_init(void)
diff --git a/drivers/video/via/accel.h b/drivers/video/via/accel.h
index 29bf854..4d93eba 100644
--- a/drivers/video/via/accel.h
+++ b/drivers/video/via/accel.h
@@ -159,9 +159,12 @@
 
 #define MAXLOOP                 0xFFFFFF
 
-void viafb_init_accel(void);
+#define VIA_BITBLT_COLOR	1
+#define VIA_BITBLT_MONO		2
+#define VIA_BITBLT_FILL		3
+
+void viafb_init_accel(struct viafb_shared *shared);
 void viafb_init_2d_engine(void);
-void set_2d_color_depth(int);
 void viafb_hw_cursor_init(void);
 void viafb_show_hw_cursor(struct fb_info *info, int Status); int
 viafb_wait_engine_idle(void); void viafb_set_2d_color_depth(int bpp);
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 4a8853a..8906c50 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -95,11 +95,8 @@ static int viafb_check_var(struct fb_var_screeninfo *var,
 	struct fb_info *info)
 {
 	int vmode_index, htotal, vtotal;
-	struct viafb_par *ppar;
+	struct viafb_par *ppar = info->par;
 	u32 long_refresh;
-	struct viafb_par *p_viafb_par;
-	ppar = info->par;
-
 
 	DEBUG_MSG(KERN_INFO "viafb_check_var!\n");
 	/* Sanity check */
@@ -144,22 +141,17 @@ static int viafb_check_var(struct fb_var_screeninfo *var,
 	/* Adjust var according to our driver's own table */
 	viafb_fill_var_timing_info(var, viafb_refresh, vmode_index);
 
-	/* This is indeed a patch for VT3353 */
-	if (!info->par)
-		return -1;
-	p_viafb_par = (struct viafb_par *)info->par;
-	if (p_viafb_par->chip_info->gfx_chip_name == UNICHROME_VX800)
-		var->accel_flags = 0;
-
 	return 0;
 }
 
 static int viafb_set_par(struct fb_info *info)
 {
+	struct viafb_par *viapar = info->par;
 	int vmode_index;
 	int vmode_index1 = 0;
 	DEBUG_MSG(KERN_INFO "viafb_set_par!\n");
 
+	viapar->depth = fb_get_color_depth(&info->var, &info->fix);
 	viafb_update_device_setting(info->var.xres, info->var.yres,
 			      info->var.bits_per_pixel, viafb_refresh, 0);
 
@@ -190,9 +182,6 @@ static int viafb_set_par(struct fb_info *info)
 		viafb_bpp = info->var.bits_per_pixel;
 		/* Update viafb_accel, it is necessary to our 2D accelerate */
 		viafb_accel = info->var.accel_flags;
-
-		if (viafb_accel)
-			viafb_set_2d_color_depth(info->var.bits_per_pixel);
 	}
 
 	return 0;
@@ -777,10 +766,10 @@ static int viafb_ioctl(struct fb_info *info, u_int cmd, u_long arg)
 static void viafb_fillrect(struct fb_info *info,
 	const struct fb_fillrect *rect)
 {
-	u32 col = 0, rop = 0;
-	int pitch;
+	struct viafb_par *viapar = info->par;
+	u32 fg_color;
 
-	if (!viafb_accel) {
+	if (!viapar->shared->hw_bitblt) {
 		cfb_fillrect(info, rect);
 		return;
 	}
@@ -788,67 +777,25 @@ static void viafb_fillrect(struct fb_info *info,
 	if (!rect->width || !rect->height)
 		return;
 
-	switch (rect->rop) {
-	case ROP_XOR:
-		rop = 0x5A;
-		break;
-	case ROP_COPY:
-	default:
-		rop = 0xF0;
-		break;
-	}
-
-	switch (info->var.bits_per_pixel) {
-	case 8:
-		col = rect->color;
-		break;
-	case 16:
-		col = ((u32 *) (info->pseudo_palette))[rect->color];
-		break;
-	case 32:
-		col = ((u32 *) (info->pseudo_palette))[rect->color];
-		break;
-	}
-
-	/* BitBlt Source Address */
-	writel(0x0, viaparinfo->io_virt + VIA_REG_SRCPOS);
-	/* Source Base Address */
-	writel(0x0, viaparinfo->io_virt + VIA_REG_SRCBASE);
-	/* Destination Base Address */
-	writel((info->fix.smem_start - viafbinfo->fix.smem_start) >> 3,
-		   viaparinfo->io_virt + VIA_REG_DSTBASE);
-	/* Pitch */
-	pitch = (info->var.xres_virtual + 7) & ~7;
-	writel(VIA_PITCH_ENABLE |
-		   (((pitch *
-		      info->var.bits_per_pixel >> 3) >> 3) |
-		      (((pitch * info->
-		      var.bits_per_pixel >> 3) >> 3) << 16)),
-		      viaparinfo->io_virt + VIA_REG_PITCH);
-	/* BitBlt Destination Address */
-	writel(((rect->dy << 16) | rect->dx),
-		viaparinfo->io_virt + VIA_REG_DSTPOS);
-	/* Dimension: width & height */
-	writel((((rect->height - 1) << 16) | (rect->width - 1)),
-		viaparinfo->io_virt + VIA_REG_DIMENSION);
-	/* Forground color or Destination color */
-	writel(col, viaparinfo->io_virt + VIA_REG_FGCOLOR);
-	/* GE Command */
-	writel((0x01 | 0x2000 | (rop << 24)),
-		viaparinfo->io_virt + VIA_REG_GECMD);
+	if (info->fix.visual == FB_VISUAL_TRUECOLOR)
+		fg_color = ((u32 *)info->pseudo_palette)[rect->color];
+	else
+		fg_color = rect->color;
 
+	DEBUG_MSG(KERN_DEBUG "viafb 2D engine: fillrect\n");
+	if (viapar->shared->hw_bitblt(viapar->io_virt, VIA_BITBLT_FILL,
+		rect->width, rect->height, info->var.bits_per_pixel,
+		viapar->vram_addr, info->fix.line_length, rect->dx, rect->dy,
+		NULL, 0, 0, 0, 0, fg_color, 0, rect->rop))
+		cfb_fillrect(info, rect);
 }
 
 static void viafb_copyarea(struct fb_info *info,
 	const struct fb_copyarea *area)
 {
-	u32 dy = area->dy, sy = area->sy, direction = 0x0;
-	u32 sx = area->sx, dx = area->dx, width = area->width;
-	int pitch;
-
-	DEBUG_MSG(KERN_INFO "viafb_copyarea!!\n");
+	struct viafb_par *viapar = info->par;
 
-	if (!viafb_accel) {
+	if (!viapar->shared->hw_bitblt) {
 		cfb_copyarea(info, area);
 		return;
 	}
@@ -856,113 +803,48 @@ static void viafb_copyarea(struct fb_info *info,
 	if (!area->width || !area->height)
 		return;
 
-	if (sy < dy) {
-		dy += area->height - 1;
-		sy += area->height - 1;
-		direction |= 0x4000;
-	}
-
-	if (sx < dx) {
-		dx += width - 1;
-		sx += width - 1;
-		direction |= 0x8000;
-	}
-
-	/* Source Base Address */
-	writel((info->fix.smem_start - viafbinfo->fix.smem_start) >> 3,
-		   viaparinfo->io_virt + VIA_REG_SRCBASE);
-	/* Destination Base Address */
-	writel((info->fix.smem_start - viafbinfo->fix.smem_start) >> 3,
-		   viaparinfo->io_virt + VIA_REG_DSTBASE);
-	/* Pitch */
-	pitch = (info->var.xres_virtual + 7) & ~7;
-	/* VIA_PITCH_ENABLE can be omitted now. */
-	writel(VIA_PITCH_ENABLE |
-		   (((pitch *
-		      info->var.bits_per_pixel >> 3) >> 3) | (((pitch *
-								info->var.
-								bits_per_pixel
-								>> 3) >> 3)
-							      << 16)),
-				viaparinfo->io_virt + VIA_REG_PITCH);
-	/* BitBlt Source Address */
-	writel(((sy << 16) | sx), viaparinfo->io_virt + VIA_REG_SRCPOS);
-	/* BitBlt Destination Address */
-	writel(((dy << 16) | dx), viaparinfo->io_virt + VIA_REG_DSTPOS);
-	/* Dimension: width & height */
-	writel((((area->height - 1) << 16) | (area->width - 1)),
-		   viaparinfo->io_virt + VIA_REG_DIMENSION);
-	/* GE Command */
-	writel((0x01 | direction | (0xCC << 24)),
-		viaparinfo->io_virt + VIA_REG_GECMD);
-
+	DEBUG_MSG(KERN_DEBUG "viafb 2D engine: copyarea\n");
+	if (viapar->shared->hw_bitblt(viapar->io_virt, VIA_BITBLT_COLOR,
+		area->width, area->height, info->var.bits_per_pixel,
+		viapar->vram_addr, info->fix.line_length, area->dx, area->dy,
+		NULL, viapar->vram_addr, info->fix.line_length,
+		area->sx, area->sy, 0, 0, 0))
+		cfb_copyarea(info, area);
 }
 
 static void viafb_imageblit(struct fb_info *info,
 	const struct fb_image *image)
 {
-	u32 size, bg_col = 0, fg_col = 0, *udata;
-	int i;
-	int pitch;
+	struct viafb_par *viapar = info->par;
+	u32 fg_color = 0, bg_color = 0;
+	u8 op;
 
-	if (!viafb_accel) {
+	if (!viapar->shared->hw_bitblt ||
+		(image->depth != 1 && image->depth != viapar->depth)) {
 		cfb_imageblit(info, image);
 		return;
 	}
 
-	udata = (u32 *) image->data;
-
-	switch (info->var.bits_per_pixel) {
-	case 8:
-		bg_col = image->bg_color;
-		fg_col = image->fg_color;
-		break;
-	case 16:
-		bg_col = ((u32 *) (info->pseudo_palette))[image->bg_color];
-		fg_col = ((u32 *) (info->pseudo_palette))[image->fg_color];
-		break;
-	case 32:
-		bg_col = ((u32 *) (info->pseudo_palette))[image->bg_color];
-		fg_col = ((u32 *) (info->pseudo_palette))[image->fg_color];
-		break;
-	}
-	size = image->width * image->height;
-
-	/* Source Base Address */
-	writel(0x0, viaparinfo->io_virt + VIA_REG_SRCBASE);
-	/* Destination Base Address */
-	writel((info->fix.smem_start - viafbinfo->fix.smem_start) >> 3,
-		   viaparinfo->io_virt + VIA_REG_DSTBASE);
-	/* Pitch */
-	pitch = (info->var.xres_virtual + 7) & ~7;
-	writel(VIA_PITCH_ENABLE |
-		   (((pitch *
-		      info->var.bits_per_pixel >> 3) >> 3) | (((pitch *
-								info->var.
-								bits_per_pixel
-								>> 3) >> 3)
-							      << 16)),
-				viaparinfo->io_virt + VIA_REG_PITCH);
-	/* BitBlt Source Address */
-	writel(0x0, viaparinfo->io_virt + VIA_REG_SRCPOS);
-	/* BitBlt Destination Address */
-	writel(((image->dy << 16) | image->dx),
-		viaparinfo->io_virt + VIA_REG_DSTPOS);
-	/* Dimension: width & height */
-	writel((((image->height - 1) << 16) | (image->width - 1)),
-		   viaparinfo->io_virt + VIA_REG_DIMENSION);
-	/* fb color */
-	writel(fg_col, viaparinfo->io_virt + VIA_REG_FGCOLOR);
-	/* bg color */
-	writel(bg_col, viaparinfo->io_virt + VIA_REG_BGCOLOR);
-	/* GE Command */
-	writel(0xCC020142, viaparinfo->io_virt + VIA_REG_GECMD);
-
-	for (i = 0; i < size / 4; i++) {
-		writel(*udata, viaparinfo->io_virt + VIA_MMIO_BLTBASE);
-		udata++;
-	}
+	if (image->depth == 1) {
+		op = VIA_BITBLT_MONO;
+		if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
+			fg_color =
+				((u32 *)info->pseudo_palette)[image->fg_color];
+			bg_color =
+				((u32 *)info->pseudo_palette)[image->bg_color];
+		} else {
+			fg_color = image->fg_color;
+			bg_color = image->bg_color;
+		}
+	} else
+		op = VIA_BITBLT_COLOR;
 
+	DEBUG_MSG(KERN_DEBUG "viafb 2D engine: imageblit\n");
+	if (viapar->shared->hw_bitblt(viapar->io_virt, op,
+		image->width, image->height, info->var.bits_per_pixel,
+		viapar->vram_addr, info->fix.line_length, image->dx, image->dy,
+		(u32 *)image->data, 0, 0, 0, 0, fg_color, bg_color, 0))
+		cfb_imageblit(info, image);
 }
 
 static int viafb_cursor(struct fb_info *info, struct fb_cursor *cursor)
@@ -1961,6 +1843,7 @@ static int __devinit via_pci_probe(void)
 
 	viaparinfo = (struct viafb_par *)viafbinfo->par;
 	viaparinfo->shared = viafbinfo->par + viafb_par_length;
+	viaparinfo->vram_addr = 0;
 	viaparinfo->tmds_setting_info = &viaparinfo->shared->tmds_setting_info;
 	viaparinfo->lvds_setting_info = &viaparinfo->shared->lvds_setting_info;
 	viaparinfo->lvds_setting_info2 =
@@ -2007,7 +1890,7 @@ static int __devinit via_pci_probe(void)
 
 	viafbinfo->pseudo_palette = pseudo_pal;
 	if (viafb_accel) {
-		viafb_init_accel();
+		viafb_init_accel(viaparinfo->shared);
 		viafb_init_2d_engine();
 		viafb_hw_cursor_init();
 	}
@@ -2110,6 +1993,7 @@ static int __devinit via_pci_probe(void)
 		}
 		viaparinfo1 = viafbinfo1->par;
 		memcpy(viaparinfo1, viaparinfo, viafb_par_length);
+		viaparinfo1->vram_addr = viafb_second_offset;
 		viaparinfo1->memsize = viaparinfo->memsize -
 			viafb_second_offset;
 		viaparinfo->memsize = viafb_second_offset;
@@ -2157,12 +2041,16 @@ static int __devinit via_pci_probe(void)
 		viafb_check_var(&default_var, viafbinfo1);
 		viafbinfo1->var = default_var;
 		viafb_update_fix(viafbinfo1);
+		viaparinfo1->depth = fb_get_color_depth(&viafbinfo1->var,
+			&viafbinfo1->fix);
 	}
 
 	viafb_setup_fixinfo(&viafbinfo->fix, viaparinfo);
 	viafb_check_var(&default_var, viafbinfo);
 	viafbinfo->var = default_var;
 	viafb_update_fix(viafbinfo);
+	viaparinfo->depth = fb_get_color_depth(&viafbinfo->var,
+		&viafbinfo->fix);
 	default_var.activate = FB_ACTIVATE_NOW;
 	fb_alloc_cmap(&viafbinfo->cmap, 256, 0);
 
diff --git a/drivers/video/via/viafbdev.h b/drivers/video/via/viafbdev.h
index 1d1fe35..beb4703 100644
--- a/drivers/video/via/viafbdev.h
+++ b/drivers/video/via/viafbdev.h
@@ -49,9 +49,17 @@ struct viafb_shared {
 	struct lvds_setting_information lvds_setting_info;
 	struct lvds_setting_information lvds_setting_info2;
 	struct chip_information chip_info;
+
+	/* hardware acceleration stuff */
+	int (*hw_bitblt)(void __iomem *engine, u8 op, u32 width, u32 height,
+		u8 dst_bpp, u32 dst_addr, u32 dst_pitch, u32 dst_x, u32 dst_y,
+		u32 *src_mem, u32 src_addr, u32 src_pitch, u32 src_x, u32 src_y,
+		u32 fg_color, u32 bg_color, u8 fill_rop);
 };
 
 struct viafb_par {
+	u8 depth;
+	u32 vram_addr;
 	void __iomem *io_virt;	/*iospace virtual memory address */
 	unsigned int fbmem;	/*framebuffer physical memory address */
 	unsigned int memsize;	/*size of fbmem */
-- 
1.6.3.2

Re: [Linux-fbdev-devel] open and close semanthics

[Alessio S. <al...@ma...>]

> On Tue, Aug 25, 2009 at 03:48:57PM -0700, Alessio Sangalli wrote:
>> Hi, can somebody give me an authoritative answer:

Thank you for all answers.

bye
as

Re: [Linux-fbdev-devel] open and close semanthics

[Ondrej Z. <san...@cr...>]

On Tue, Aug 25, 2009 at 03:48:57PM -0700, Alessio Sangalli wrote:
> Hi, can somebody give me an authoritative answer:
> what is the semanthics associated to the "open" and "release" (close) calls?
> 
> More specifically, "open" and "release" can/must/must not change any 
> setting (resolution etc)?

Many drivers for non-embedded (VGA compatible) cards assume that they
should not touch hardware if their device is not open. So they configure
device during the first open and restore original state during the
last close. The framebuffer console counts as one user, and therefore
keeps the device configured.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: san...@cr...)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: [Linux-fbdev-devel] open and close semanthics

[Florian T. S. <Flo...@gm...>]

Hi,

this is not authoritative but I hope that's better than no answer:

Alessio Sangalli schrieb:
> Hi, can somebody give me an authoritative answer:
> what is the semanthics associated to the "open" and "release" (close) calls?
> 
> More specifically, "open" and "release" can/must/must not change any 
> setting (resolution etc)?
> 
> Should those functions keep a "counter" of how many programs opened it?

I'd say that's not well defined. skeletonfb lists them even as optional. 
I've read that some drivers use it for mode changes, some keep counters 
and others just return 0.
If you are writing a driver: use it as you need it or don't use it at all.
If you write something that needs this behavior: there is none you can 
expect along all drivers, sorry.

For more information:
http://www.linux-fbdev.org/HOWTO/4.html
<linux kernel tree>/drivers/video/skeletonfb.c


Regards,

Florian Tobias Schandinat

Re: [Linux-fbdev-devel] open and close semanthics

[Alessio S. <al...@ma...>]

No indications on this request?
thank you
Alessio




Alessio Sangalli wrote:
> Hi, can somebody give me an authoritative answer:
> what is the semanthics associated to the "open" and "release" (close) calls?
> 
> More specifically, "open" and "release" can/must/must not change any 
> setting (resolution etc)?
> 
> Should those functions keep a "counter" of how many programs opened it?