[lkml]   [2006]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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 -

    "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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-10-12 16:15    [W:0.025 / U:18.176 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site