linux-kernel - Re: [PATCH 2.6.19-rc1 update 2] drivers: add LCD support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <452E4D1A.9000409@grupopie.com>
Date:	Thu, 12 Oct 2006 15:11:38 +0100
From:	Paulo Marques <pmarques@...popie.com>
To:	Miguel Ojeda Sandonis <maxextreme@...il.com>
CC:	akpm@...l.org, linux-kernel@...r.kernel.org
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/