lkml.org 
[lkml]   [2006]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.19-rc1 update 2] drivers: add LCD support
Miguel Ojeda Sandonis wrote:
> Andrew, here it is the patch for converting the cfag12864b driver
> to a framebuffer driver as Pavel requested and as I promised :)

Very nice :)

Just a few comments, see below.

> Pavel, yep, now I can login in my tiny 128x64 LCD.
> It is pretty amazing to run vi on it... ;)
>
> Tested and working fine.
> ---
[...]
> +static void cfag12864b_update(void *arg)
[...]
> + for (i = 0; i < CFAG12864B_CONTROLLERS; i++) {
> + cfag12864b_controller(i);
> + cfag12864b_nop();
> + for (j = 0; j < CFAG12864B_PAGES; j++) {
> + cfag12864b_page(j);
> + cfag12864b_nop();
> + for (k = 0; k < CFAG12864B_ADDRESSES; k++) {
> + cfag12864b_address(k);
> + cfag12864b_nop();
> + cfag12864b_nop();

Doesn't the LCD controller automatically advance the address when
writing data?

If it does, the address should only be needed before this loop and you
could write 64 bytes in a row without any "nop"'s. This should really
improve the time it takes to refresh the display.

Also, keeping a "low level cache" of the physical display state and only
sending bytes that have actually changed might be a good improvement too.

Remember, the host CPU is probably much much faster than your interface
to the LCD, so if it takes a few cycles to check the cache and decide
not to send a byte, it's already a big win. A simple memcmp might be
used skip full pages.

Also, what do these "nop"'s do? Isn't there a way to read the "busy"
status from the controller and just write as fast as possible?

> [...]
> + The LCD framebuffer driver can be attached to a console.
> + It will work fine. However, you can't attach it to the fbdev driver
> + of the xorg server.

This is probably because your driver can't be mmapped, no?

Although the controller is only accessible through the parallel port, it
might be possible to mmap it. I vaguely remember that when I was reading
LDD3, I thought that this should be doable in a sequence like:

- accept the mmap as if you had the memory for the device available
- at "nopage" time, mark the buffer as "dirty" and map it to user space
- using a timer at the actual refresh rate, check the dirty flag. If
it is dirty, unmap the buffer and refresh the display

I'm not describing the locking details (and a lot of other details,
too), but it should work in principle.

It will probably make things easier if your buffer size is PAGE_SIZE,
and your "internal" operations (fillrect, copyarea, imageblit) also work
over the same buffer and just mark the buffer as dirty.

I don't know if X will be able to run in 128x64, but it is easier to
make applications mmap the buffer and use it directly.

--
Paulo Marques - www.grupopie.com

"The face of a child can say it all, especially the
mouth part of the face."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-10-12 16:15    [W:0.101 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site