Messages in this thread | | | Date | Thu, 12 Oct 2006 15:11:38 +0100 | From | Paulo Marques <> | Subject | Re: [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/
| |