Questions about fbdriver integration

Questions about fbdriver integration

[Ico Doornekamp]

Hello,

I have just finished writing a framebuffer driver for a LCD display
connected to our embedded system (monochrome, 128x64, GPIO driven).
It's very similar to the hecubafb driver, and uses deferred IO. I've
included some of the drivers properties at the end of this mail.  Things
works fine when displaying images by doing write()s to /dev/fb0, so this
part seems to be ok.

I hope some of the regulars on this list can clear up some issues
I've run into when using this driver:

- My next step as to redirect the linux console to this framebuffer
  device. I've configured the kernel for framebuffer console, and when
  loading the fbcon module, the message 
    
     Console: switching to mono frame buffer device 16x4" 
     
  appears, and

     cat /sys/class/vtconsole/vtcon1/name -> (M) frame buffer device
     cat /sys/class/vtconsole/vtcon1/bind -> 1
  
  This seems just fine to me, but however, no output appears on the
  display: just a blank screen. 

  It seems that the console is doing *something*, since my driver gets
  triggered by the deferred IO every 200msec (blinking cursor?), problem
  is that the data arriving in my driver is all zeroes!

  So, what would I need to do to get the console working properly with
  my driver ?


- The other question is more a userspace issue: I was hoping to use the
  xorg fbdev server on my dislay, but unfortunately this does not seem
  to support 1 bit depth displays :

    (EE) FBDEV(0): unsupported number of bits per pixel: 1

  Is there a way to make X work on 1-bit fb devices, or am I out of luck
  here ?


Thank you,

Ico


#define DPY_W 128
#define DPY_H 64

static struct fb_fix_screeninfo mbarcfb_fix __devinitdata = {
        .id =           "mbarcfb",
        .type =         FB_TYPE_PACKED_PIXELS,
        .visual =       FB_VISUAL_MONO01,
        .xpanstep =     0,
        .ypanstep =     0,
        .ywrapstep =    0,
        .accel =        FB_ACCEL_NONE,
};

static struct fb_var_screeninfo mbarcfb_var __devinitdata = {
        .xres           = DPY_W,
        .yres           = DPY_H,
        .xres_virtual   = DPY_W,
        .yres_virtual   = DPY_H,
        .bits_per_pixel = 1,
        .nonstd         = 1,
};


-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Ico Doornekamp]

(Sorry for replying to my own post so soon)

* On 2007-11-24 Ico Doornekamp <fbdev@zevv.nl> wrote  :

> It's very similar to the hecubafb driver, and uses deferred IO.

Anyway, it is *supposed* to use deferred IO, but I suspect this is where
my problem is. If I understand right, the fb_defio code should handle
the mmap()ing of the framebuffer device for me, and run my callback
whenever a write occured to the fb memory. I guess something is not
right here, since the callback never gets to run when doing mmap() from
userspace, or when using the fbcon module. 

Is the deferred IO code currently known to work properly ?

Thanks again,

Ico

-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Ico Doornekamp]

(Sorry for replying to my own post this soon) 
 
* On 2007-11-24 Ico Doornekamp <fbdev@zevv.nl> wrote : 
 
> It's very similar to the hecubafb driver, and uses deferred IO. 
 
Anyway, it is *supposed* to use deferred IO, but I suspect this is where 
my problem is. If I understand right, the fb_defio code should handle 
the mmap()ing of the framebuffer device for me, and run my callback 
whenever a write occured to the fb memory. I guess something is not 
right here, since the callback never gets to run when doing mmap() from 
userspace, or when using the fbcon module. 
 
Is the deferred IO code currently known to work properly ? 
 
Thanks again, 
 
Ico 

-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Jaya Kumar]

On Nov 24, 2007 5:14 PM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> Is the deferred IO code currently known to work properly ?
>

The deferred IO code does not work properly at the moment. The symptom
is that only the first write to the framebuffer is detected. I have a
patch to fix this which I've tested to work on 2.6.22.10. You can
cherrypick the fb_defio.c changes from the following post.

http://marc.info/?l=linux-fbdev-devel&m=119412505902140&w=2

Best regards,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Ico Doornekamp]

* On 2007-11-24 Jaya Kumar <jayakumar.lkml@gmail.com> wrote  :

> On Nov 24, 2007 5:14 PM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> > Is the deferred IO code currently known to work properly ?
> >
> 
> The deferred IO code does not work properly at the moment. The symptom
> is that only the first write to the framebuffer is detected. I have a
> patch to fix this which I've tested to work on 2.6.22.10. You can
> cherrypick the fb_defio.c changes from the following post.
> 
> http://marc.info/?l=linux-fbdev-devel&m=119412505902140&w=2

This seems to fix my mmap problem, although the first mmap
access yields a kernel warning:

	WARNING: at fs/buffer.c:696 __set_page_dirty()
	[<c01622f8>] __set_page_dirty+0xb8/0xf0
	[<c0134169>] set_page_dirty+0x29/0x50
	[<c0134d5b>] set_page_dirty_balance+0xb/0x40
	[<c0139470>] __do_fault+0x160/0x340
	[<c013a9d3>] handle_mm_fault+0xd3/0x3d0

In spite of the warning, mmaping now works fine. Still no output from
the virtual console though.

Thank you,

Ico

-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Jaya Kumar]

On Nov 25, 2007 4:05 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
>
> This seems to fix my mmap problem, although the first mmap
> access yields a kernel warning:
>
>         WARNING: at fs/buffer.c:696 __set_page_dirty()
>         [<c01622f8>] __set_page_dirty+0xb8/0xf0
>         [<c0134169>] set_page_dirty+0x29/0x50
>         [<c0134d5b>] set_page_dirty_balance+0xb/0x40
>         [<c0139470>] __do_fault+0x160/0x340
>         [<c013a9d3>] handle_mm_fault+0xd3/0x3d0
>

Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe
it's a recent change. Just curious, which kernel are you using and on
which arch?

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Ico Doornekamp]

* On 2007-11-25 Jaya Kumar <jayakumar.lkml@gmail.com> wrote  :

> On Nov 25, 2007 4:05 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> >
> > This seems to fix my mmap problem, although the first mmap
> > access yields a kernel warning:
> >
> >         WARNING: at fs/buffer.c:696 __set_page_dirty()
> >         [<c01622f8>] __set_page_dirty+0xb8/0xf0
> >         [<c0134169>] set_page_dirty+0x29/0x50
> >         [<c0134d5b>] set_page_dirty_balance+0xb/0x40
> >         [<c0139470>] __do_fault+0x160/0x340
> >         [<c013a9d3>] handle_mm_fault+0xd3/0x3d0
> >
> 
> Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe
> it's a recent change. Just curious, which kernel are you using and on
> which arch?

I'm running 2.6.23.8 on i386. I can post the driver code if this would
be of any help.

Unfortunalely I'm not very familiar with the lowlevel paging and memory
handling, so this is a though one for me to debug myself.

-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Jaya Kumar]

On Nov 25, 2007 5:53 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
>
> I'm running 2.6.23.8 on i386. I can post the driver code if this would
> be of any help.
>

Yes, I think it'll help. I'll try to upgrade to top of tree as well.

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Ico Doornekamp]

> On Nov 25, 2007 5:53 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> >
> > I'm running 2.6.23.8 on i386. I can post the driver code if this would
> > be of any help.
> >
> 
> Yes, I think it'll help. I'll try to upgrade to top of tree as well.

The driver uses on-chip GPIO for communication with the LCD, which is
handled by the v86sxgpio_* functions.

mbarcfb_dpy_update() does a complete screen update; the layout of the
LCD is different from the fbdev, so the 'transpose' function is doing
some logic to find the proper pixels. This code is still far from
optimal.

The code needs some cleanup and #defines for magic numbers here and
there, but the general idea should be clear.

write() and mmap() from userspace both work fine at this moment, I'm
still working on getting the console to display.

Ico

/*
 * linux/drivers/video/mbarcfb.c -- FB driver for mbarc display
 *
 * Copyright (C) 2007, Ico Doornekamp
 * Based on the Hecuba driver
 *
 * This file is subject to the terms and conditions of the GNU General Public
 * License. See the file COPYING in the main directory of this archive for
 * more details.
 */

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/list.h>
#include <asm/uaccess.h>

#include <linux/v86sxgpio.h>

#define DPY_W 128
#define DPY_H 64

struct mbarcfb_par {
	struct v86sxgpio *gpio_data;
	struct v86sxgpio *gpio_ctrl;
	int ctrl_bits;
	struct fb_info *info;
};

static struct fb_fix_screeninfo mbarcfb_fix __devinitdata = {
	.id =		"mbarcfb",
	.type =		FB_TYPE_PACKED_PIXELS,
	.visual =	FB_VISUAL_MONO01,
	.xpanstep =	0,
	.ypanstep =	0,
	.ywrapstep =	0,
	.accel =	FB_ACCEL_NONE,
};

static struct fb_var_screeninfo mbarcfb_var __devinitdata = {
	.xres		= DPY_W,
	.yres		= DPY_H,
	.xres_virtual	= DPY_W,
	.yres_virtual	= DPY_H,
	.bits_per_pixel	= 1,
	.nonstd		= 1,
};

static DECLARE_WAIT_QUEUE_HEAD(mbarcfb_waitq);
static struct platform_device *mbarcfb_device;

#define DI_INSTR 0
#define DI_DATA 1

#define RW_WRITE 0
#define RW_READ 1

#define BIT_DI  (1<<0)
#define BIT_RW  (1<<1)
#define BIT_EN  (1<<2)
#define BIT_CS1 (1<<3)
#define BIT_CS2 (1<<4)
#define BIT_RST (1<<5)


static void mbarc_set(struct mbarcfb_par *par, int mask, int val)
{
	if(val) {
		par->ctrl_bits |= mask;
	} else {
		par->ctrl_bits &= ~mask;
	}
	v86sxgpio_set(par->gpio_ctrl, par->ctrl_bits);
}

static void mbarc_send(struct mbarcfb_par *par, int di, int val)
{
	mbarc_set(par, BIT_DI, di);
	mbarc_set(par, BIT_RW, RW_WRITE);
	v86sxgpio_set(par->gpio_data, val);
	mbarc_set(par, BIT_EN, 1);
	mbarc_set(par, BIT_EN, 0);
}

static int __devinit mbarc_init_control(struct mbarcfb_par *par)
{
	mbarc_set(par, BIT_RST, 0);
	mbarc_set(par, BIT_RST, 1);

	mbarc_send(par, DI_DATA, 0xff);
	mbarc_send(par, DI_DATA, 0xff);
	mbarc_send(par, DI_DATA, 0xff);
	mbarc_send(par, DI_INSTR, 0xe2);

	return 0;
}


u8 transpose(u8 *src, unsigned x, unsigned y)
{
	u8 b;
	int i;
	u8 mask;
	unsigned offset;

	mask = 1 << ( 7 - (x%8));

	b = 0;

	for(i=0; i<8; i++) {
		offset = (x + (y+i)*DPY_W) / 8;
		if( src[offset] & mask ) b |= (1<<i);
	}
	return b;
}


/* main mbarcfb functions */

static void mbarcfb_dpy_update(struct mbarcfb_par *par)
{
	unsigned char *buf = (unsigned char __force *)par->info->screen_base;
	unsigned c, x, cx, y;
	u8 *p;
	u8 b;

	p = buf;

	for(c=0; c<2; c++) {

		mbarc_set(par, BIT_CS1, c==0);
		mbarc_set(par, BIT_CS2, c==1);

		for(y=0; y<64; y+=8) {

			mbarc_send(par, DI_INSTR, 0x40);
			mbarc_send(par, DI_INSTR, 0xb8 + y/8);
			mbarc_send(par, DI_INSTR, 0xc0); /* display start line */
			
			for(cx=0; cx<64; cx++) {
				x = cx + c*64;
				b = transpose(buf, x, y);
				mbarc_send(par, DI_DATA, b);
				mbarc_send(par, DI_INSTR, 0x3f); /* wtf! */
			}
		}
	}
	
	for(c=0; c<2; c++) {
		mbarc_set(par, BIT_CS1, c==0);
		mbarc_set(par, BIT_CS2, c==1);
		mbarc_send(par, DI_INSTR, 0x3f); /* wtf! */
	}
}


/* this is called back from the deferred io workqueue */

static void mbarcfb_dpy_deferred_io(struct fb_info *info, struct list_head *pagelist)
{
	mbarcfb_dpy_update(info->par);
}


static void mbarcfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect)
{
	struct mbarcfb_par *par = info->par;

	sys_fillrect(info, rect);

	mbarcfb_dpy_update(par);
}


static void mbarcfb_copyarea(struct fb_info *info, const struct fb_copyarea *area)
{
	struct mbarcfb_par *par = info->par;

	sys_copyarea(info, area);

	mbarcfb_dpy_update(par);
}


static void mbarcfb_imageblit(struct fb_info *info, const struct fb_image *image)
{
	struct mbarcfb_par *par = info->par;

	sys_imageblit(info, image);

	mbarcfb_dpy_update(par);
}


/*
 * this is the slow path from userspace. they can seek and write to
 * the fb. it's inefficient to do anything less than a full screen draw
 */

static ssize_t mbarcfb_write(struct fb_info *info, const char __user *buf, size_t count, loff_t *ppos)
{
	unsigned long p;
	int err=-EINVAL;
	struct mbarcfb_par *par;
	unsigned int xres;
	unsigned int fbmemlength;

	p = *ppos;
	par = info->par;
	xres = info->var.xres;
	fbmemlength = (xres * info->var.yres)/8;

	if (p > fbmemlength)
		return -ENOSPC;

	err = 0;
	if ((count + p) > fbmemlength) {
		count = fbmemlength - p;
		err = -ENOSPC;
	}

	if (count) {
		char *base_addr;

		base_addr = (char __force *)info->screen_base;
		count -= copy_from_user(base_addr + p, buf, count);
		*ppos += count;
		err = -EFAULT;
	}

	mbarcfb_dpy_update(par);

	if (count)
		return count;

	return err;
}


static struct fb_ops mbarcfb_ops = {
	.owner		= THIS_MODULE,
	.fb_read        = fb_sys_read,
	.fb_write	= mbarcfb_write,
	.fb_fillrect	= mbarcfb_fillrect,
	.fb_copyarea	= mbarcfb_copyarea,
	.fb_imageblit	= mbarcfb_imageblit,
};


static struct fb_deferred_io mbarcfb_defio = {
	.delay		= HZ / 5,
	.deferred_io	= mbarcfb_dpy_deferred_io,
};


static int __devinit mbarcfb_probe(struct platform_device *dev)
{
	struct fb_info *info;
	int retval = -ENOMEM;
	int videomemorysize;
	unsigned char *videomemory;
	struct mbarcfb_par *par;

	videomemorysize = (DPY_W*DPY_H)/8;

	if (!(videomemory = vmalloc(videomemorysize)))
		return retval;

	memset(videomemory, 0, videomemorysize);

	info = framebuffer_alloc(sizeof(struct mbarcfb_par), &dev->dev);
	if (!info)
		goto err;

	info->screen_base = (char __iomem *) videomemory;
	info->fbops = &mbarcfb_ops;

	info->var = mbarcfb_var;
	info->fix = mbarcfb_fix;
	info->fix.smem_len = videomemorysize;
	par = info->par;
	par->info = info;

	par->gpio_ctrl = v86sxgpio_request("mbarcfb-ctrl", 0, 0, 6);
	if(!par->gpio_ctrl) {
		printk(KERN_WARNING "cant get ctrl gpio\n");
		goto err1;
	}
	v86sxgpio_ddr(par->gpio_ctrl, 0x3f);
	par->ctrl_bits = 0;
	
	par->gpio_data = v86sxgpio_request("mbarcfb-data", 1, 0, 8);
	if(!par->gpio_data) {
		printk(KERN_WARNING "cant get data gpio\n");
		goto err2;
	}
	v86sxgpio_ddr(par->gpio_data, 0xff);

	info->flags = FBINFO_FLAG_DEFAULT;
	info->fbdefio = &mbarcfb_defio;
	fb_deferred_io_init(info);

	retval = register_framebuffer(info);
	if (retval < 0)
		goto err3;
	platform_set_drvdata(dev, info);

	printk(KERN_INFO
	       "fb%d: Mbarc frame buffer device, using %dK of video memory\n",
	       info->node, videomemorysize >> 10);

	/* this inits the dpy */

	mbarc_init_control(par);

	return 0;


err3:
	v86sxgpio_release(par->gpio_data);
err2:
	v86sxgpio_release(par->gpio_ctrl);
err1:
	framebuffer_release(info);
err:
	vfree(videomemory);
	return retval;
}

static int __devexit mbarcfb_remove(struct platform_device *dev)
{
	struct fb_info *info = platform_get_drvdata(dev);
	struct mbarcfb_par *par;

	if (info) {
		fb_deferred_io_cleanup(info);
		unregister_framebuffer(info);
		vfree((void __force *)info->screen_base);
		framebuffer_release(info);

		par = info->par;
		v86sxgpio_release(par->gpio_data);
		v86sxgpio_release(par->gpio_ctrl);
	}
	

	return 0;
}


static struct platform_driver mbarcfb_driver = {
	.probe	= mbarcfb_probe,
	.remove = mbarcfb_remove,
	.driver	= {
		.name	= "mbarcfb",
	},
};


static int __init mbarcfb_init(void)
{
	int ret;

	ret = platform_driver_register(&mbarcfb_driver);
	if (!ret) {
		mbarcfb_device = platform_device_alloc("mbarcfb", 0);
		if (mbarcfb_device)
			ret = platform_device_add(mbarcfb_device);
		else
			ret = -ENOMEM;

		if (ret) {
			platform_device_put(mbarcfb_device);
			platform_driver_unregister(&mbarcfb_driver);
		}
	}
	return ret;

}


static void __exit mbarcfb_exit(void)
{
	platform_device_unregister(mbarcfb_device);
	platform_driver_unregister(&mbarcfb_driver);
}


module_init(mbarcfb_init);
module_exit(mbarcfb_exit);

MODULE_DESCRIPTION("fbdev driver for Mbarc board");
MODULE_AUTHOR("Ico Doornekamp");
MODULE_LICENSE("GPL");


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Ico Doornekamp]

Hello Jaya,

* On 2007-11-25 Jaya Kumar <jayakumar.lkml@gmail.com> wrote  :

> On Nov 25, 2007 4:05 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> >
> > This seems to fix my mmap problem, although the first mmap
> > access yields a kernel warning:
> >
> >         WARNING: at fs/buffer.c:696 __set_page_dirty()
> >         [<c01622f8>] __set_page_dirty+0xb8/0xf0
> >         [<c0134169>] set_page_dirty+0x29/0x50
> >         [<c0134d5b>] set_page_dirty_balance+0xb/0x40
> >         [<c0139470>] __do_fault+0x160/0x340
> >         [<c013a9d3>] handle_mm_fault+0xd3/0x3d0
> >
> 
> Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe
> it's a recent change. 

Just curious, did you happen to take a look at this issue, and were you
able to reproduce it ?

Thank you,

Ico

-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: Questions about fbdriver integration

[Jaya Kumar]

On Nov 28, 2007 6:40 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> * On 2007-11-25 Jaya Kumar <jayakumar.lkml@gmail.com> wrote  :
> > On Nov 25, 2007 4:05 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> > >
> > > This seems to fix my mmap problem, although the first mmap
> > > access yields a kernel warning:
> > >
> > >         WARNING: at fs/buffer.c:696 __set_page_dirty()
> > >         [<c01622f8>] __set_page_dirty+0xb8/0xf0
> > >         [<c0134169>] set_page_dirty+0x29/0x50
> > >         [<c0134d5b>] set_page_dirty_balance+0xb/0x40
> > >         [<c0139470>] __do_fault+0x160/0x340
> > >         [<c013a9d3>] handle_mm_fault+0xd3/0x3d0
> > >
> >
> > Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe
> > it's a recent change.
>
> Just curious, did you happen to take a look at this issue, and were you
> able to reproduce it ?
>

I haven't looked at it yet.

Thanks,
jaya

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: Questions about fbdriver integration

[Jaya Kumar]

On Nov 28, 2007 8:00 AM, Jaya Kumar <jayakumar.lkml@gmail.com> wrote:
> On Nov 28, 2007 6:40 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> > * On 2007-11-25 Jaya Kumar <jayakumar.lkml@gmail.com> wrote  :
> > > On Nov 25, 2007 4:05 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> > > >
> > > > This seems to fix my mmap problem, although the first mmap
> > > > access yields a kernel warning:
> > > >
> > > >         WARNING: at fs/buffer.c:696 __set_page_dirty()
> > > >         [<c01622f8>] __set_page_dirty+0xb8/0xf0
> > > >         [<c0134169>] set_page_dirty+0x29/0x50
> > > >         [<c0134d5b>] set_page_dirty_balance+0xb/0x40
> > > >         [<c0139470>] __do_fault+0x160/0x340
> > > >         [<c013a9d3>] handle_mm_fault+0xd3/0x3d0
> > > >
> > >
> > > Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe
> > > it's a recent change.
> >
> > Just curious, did you happen to take a look at this issue, and were you
> > able to reproduce it ?
> >
>
> I haven't looked at it yet.
>

I'm regretably tied up. Please feel free to look at it too of course.

Thanks,
jaya

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: Questions about fbdriver integration

[Ico Doornekamp]

* On 2007-11-28 Jaya Kumar <jayakumar.lkml@gmail.com> wrote  :

> On Nov 28, 2007 8:00 AM, Jaya Kumar <jayakumar.lkml@gmail.com> wrote:
> > On Nov 28, 2007 6:40 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> > > * On 2007-11-25 Jaya Kumar <jayakumar.lkml@gmail.com> wrote  :
> > > > On Nov 25, 2007 4:05 AM, Ico Doornekamp <fbdev@zevv.nl> wrote:
> > > > >
> > > > > This seems to fix my mmap problem, although the first mmap
> > > > > access yields a kernel warning:
> > > > >
> > > > >         WARNING: at fs/buffer.c:696 __set_page_dirty()
> > > > >         [<c01622f8>] __set_page_dirty+0xb8/0xf0
> > > > >         [<c0134169>] set_page_dirty+0x29/0x50
> > > > >         [<c0134d5b>] set_page_dirty_balance+0xb/0x40
> > > > >         [<c0139470>] __do_fault+0x160/0x340
> > > > >         [<c013a9d3>] handle_mm_fault+0xd3/0x3d0
> > > > >
> > > >
> > > > Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe
> > > > it's a recent change.
> > >
> > > Just curious, did you happen to take a look at this issue, and were you
> > > able to reproduce it ?
> > >
> >
> > I haven't looked at it yet.
> >
> 
> I'm regretably tied up. Please feel free to look at it too of course.

Yes, of course, I was about to, so that's why I asked.

Thank you,

Ico

-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: Questions about fbdriver integration

[Geert Uytterhoeven]

On Sat, 24 Nov 2007, Ico Doornekamp wrote:
> I have just finished writing a framebuffer driver for a LCD display
> connected to our embedded system (monochrome, 128x64, GPIO driven).
> It's very similar to the hecubafb driver, and uses deferred IO. I've
> included some of the drivers properties at the end of this mail.  Things
> works fine when displaying images by doing write()s to /dev/fb0, so this
> part seems to be ok.
> 
> I hope some of the regulars on this list can clear up some issues
> I've run into when using this driver:
> 
> - My next step as to redirect the linux console to this framebuffer
>   device. I've configured the kernel for framebuffer console, and when
>   loading the fbcon module, the message 
>     
>      Console: switching to mono frame buffer device 16x4" 
>      
>   appears, and
> 
>      cat /sys/class/vtconsole/vtcon1/name -> (M) frame buffer device
>      cat /sys/class/vtconsole/vtcon1/bind -> 1
>   
>   This seems just fine to me, but however, no output appears on the
>   display: just a blank screen. 
> 
>   It seems that the console is doing *something*, since my driver gets
>   triggered by the deferred IO every 200msec (blinking cursor?), problem
>   is that the data arriving in my driver is all zeroes!

Fbcon writes to the memory at fb_info.screen_base.

> - The other question is more a userspace issue: I was hoping to use the
>   xorg fbdev server on my dislay, but unfortunately this does not seem
>   to support 1 bit depth displays :
> 
>     (EE) FBDEV(0): unsupported number of bits per pixel: 1
> 
>   Is there a way to make X work on 1-bit fb devices, or am I out of luck
>   here ?

The old XF86_FBDev (from XFree86 3.x) definitely works with monochrome.
I expect (but never tried) KDrive also to support it.

It's a pity many frame buffer organizations were dropped in Xorg.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Ico Doornekamp]

* On 2007-11-25 Geert Uytterhoeven <geert@linux-m68k.org> wrote  :

> On Sat, 24 Nov 2007, Ico Doornekamp wrote:
> > I have just finished writing a framebuffer driver for a LCD display
> > connected to our embedded system (monochrome, 128x64, GPIO driven).
> > It's very similar to the hecubafb driver, and uses deferred IO. I've
> > included some of the drivers properties at the end of this mail.  Things
> > works fine when displaying images by doing write()s to /dev/fb0, so this
> > part seems to be ok.
> > 
> > I hope some of the regulars on this list can clear up some issues
> > I've run into when using this driver:
> > 
> > - My next step as to redirect the linux console to this framebuffer
> >   device. I've configured the kernel for framebuffer console, and when
> >   loading the fbcon module, the message 
> >     
> >      Console: switching to mono frame buffer device 16x4" 
> >      
> >   appears, and
> > 
> >      cat /sys/class/vtconsole/vtcon1/name -> (M) frame buffer device
> >      cat /sys/class/vtconsole/vtcon1/bind -> 1
> >   
> >   This seems just fine to me, but however, no output appears on the
> >   display: just a blank screen. 
> > 
> >   It seems that the console is doing *something*, since my driver gets
> >   triggered by the deferred IO every 200msec (blinking cursor?), problem
> >   is that the data arriving in my driver is all zeroes!
> 
> Fbcon writes to the memory at fb_info.screen_base.

That is what I expected. I'll have to do a bit more debugging here then.

> > - The other question is more a userspace issue: I was hoping to use the
> >   xorg fbdev server on my dislay, but unfortunately this does not seem
> >   to support 1 bit depth displays :
> > 
> >     (EE) FBDEV(0): unsupported number of bits per pixel: 1
> > 
> >   Is there a way to make X work on 1-bit fb devices, or am I out of luck
> >   here ?
> 
> The old XF86_FBDev (from XFree86 3.x) definitely works with monochrome.
> I expect (but never tried) KDrive also to support it.
> 
> It's a pity many frame buffer organizations were dropped in Xorg.

It is, yes. I'll give Kdrive a try, or as an alternative I can make my
framebuffer 8-bit greycale instead of monochrome, with a simple
threshold. I'll be using simple monochrome apps with some text only, so
that will probably be sufficient.

Thanks,

Ico

-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration

[Ico Doornekamp]

* On 2007-11-25 Ico Doornekamp <fbdev@zevv.nl> wrote  :

> > 
> > Fbcon writes to the memory at fb_info.screen_base.
> 
> That is what I expected. I'll have to do a bit more debugging here then.

It seems that my driver did not fill the line_length member of
fb_fix_screeninfo, and no gets was copied by fbcon when this is missing.

I filled in this field, but now

  BUG: unable to handle kernel paging request at virtual address c882a800

  [<c882450c>] mbarcfb_imageblit+0xc/0x20 [mbarcfb]
  [<c881315d>] soft_cursor+0x15d/0x1bc [softcursor]
  [<c8817b38>] bit_cursor+0x338/0x5a8 [bitblit]
  [<c01c5c53>] vsnprintf+0x303/0x690

happens. Back to do some more debugging.

Thanks for your time,

Ico


-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration (solved)

[Ico Doornekamp]

* On 2007-11-25 Ico Doornekamp <fbdev@zevv.nl> wrote  :

> * On 2007-11-25 Ico Doornekamp <fbdev@zevv.nl> wrote  :
> 
> > > Fbcon writes to the memory at fb_info.screen_base.
> > 
> > That is what I expected. I'll have to do a bit more debugging here then.
> 
> It seems that my driver did not fill the line_length member of
> fb_fix_screeninfo, and no gets was copied by fbcon when this is missing.
> 
> I filled in this field, but now
> 
>   BUG: unable to handle kernel paging request at virtual address c882a800
> 
>   [<c882450c>] mbarcfb_imageblit+0xc/0x20 [mbarcfb]
>   [<c881315d>] soft_cursor+0x15d/0x1bc [softcursor]
>   [<c8817b38>] bit_cursor+0x338/0x5a8 [bitblit]
>   [<c01c5c53>] vsnprintf+0x303/0x690
> 
> happens. Back to do some more debugging.

Ok, one more reply to myself: all problems seem to be solved now - I
changed my driver to support 8-bit pseudocolor instead of 1-bit mono,
and suddenly both the console and X are working just fine. It seems that
the MONO01 visual is just not well supported in various other parts
interacting with the framebuffer code.

The only issue remaining is the kernel warning I posted in an earlier
mail (__set_page_dirty), which I understood Jaya was already trying to
reproduce on his system.

Thank you both for your time and answers,

Ico

-- 
:wq
^X^Cy^K^X^C^C^C^C

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Questions about fbdriver integration (solved)

[Geert Uytterhoeven]

On Sun, 25 Nov 2007, Ico Doornekamp wrote:
> * On 2007-11-25 Ico Doornekamp <fbdev@zevv.nl> wrote  :
> > * On 2007-11-25 Ico Doornekamp <fbdev@zevv.nl> wrote  :
> > > > Fbcon writes to the memory at fb_info.screen_base.
> > > That is what I expected. I'll have to do a bit more debugging here then.
> > 
> > It seems that my driver did not fill the line_length member of
> > fb_fix_screeninfo, and no gets was copied by fbcon when this is missing.
> > 
> > I filled in this field, but now
> > 
> >   BUG: unable to handle kernel paging request at virtual address c882a800
> > 
> >   [<c882450c>] mbarcfb_imageblit+0xc/0x20 [mbarcfb]
> >   [<c881315d>] soft_cursor+0x15d/0x1bc [softcursor]
> >   [<c8817b38>] bit_cursor+0x338/0x5a8 [bitblit]
> >   [<c01c5c53>] vsnprintf+0x303/0x690
> > 
> > happens. Back to do some more debugging.
> 
> Ok, one more reply to myself: all problems seem to be solved now - I

Good!

> changed my driver to support 8-bit pseudocolor instead of 1-bit mono,
> and suddenly both the console and X are working just fine. It seems that
> the MONO01 visual is just not well supported in various other parts
> interacting with the framebuffer code.

That's strange. Monochrome is known to work on Amiga. Last one I tried
was 2.6.24-rcX.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/