On Wed, 5 May 2004, Lucas Correia Villa Real wrote:
I'm starting to write a device driver for a display managed by a controller.
It's an LCD with 65x132 pixels produced by Sitronix (ST7565), and is being
used on an ARM-based embedded through an SPI interface (that is, I cannot
directly memory-map it's address, since the communication will be done by
this serial interface).
So you cannot access the frame buffer memory from the CPU, except through
sending commands to the LCD controller, right?
I've read some device drivers code for other LCD devices, and I could have a
good idea of how things work. By the way, a few questions couldn't be
answered just by looking into their sources:
- how is the "refresh" done by fbdev? I don't want to keep sending the same
data to the display if there isn't any update to be done.
If the frame buffer memory is accessible directly by the CPU, it will be
updated automatically. If not, things get more difficult:
- For text console output, 2.4.x will do direct accesses to the frame buffer,
which won't work.
In 2.6.x, fbcon will call the fb_{fillrect,copyarea,imageblit}() routines
of your fbdev driver, so you can handle that easily
- For graphics from user space, things are more complex, since the
application cannot mmap() your frame buffer memory. Either you use a shadow
frame buffer that updates the hardware periodically, or teach your
application to talk to the LCD controller directly.
- also related to this refresh: I haven't seen any interrupt being handled by
many fbdev drivers. Is this ok? How will fbdev knows when the card is trying
to communicate with the CPU?
Most drivers don't use interrupts yet, because until recently (speaking about
2.6), you could not use them there.
- given that I can be told when the user is going to write some data to the
fbdev (should I implement my own fb_read and fb_write operations?), is there
an automatic way to get only the pixels that he's modifying? This would save
a lot of unnecessary transfers to the display as well.
You should implement your own fb_{read,write}() if the CPU cannot access the
frame buffer memory directly.
Just forgot to tell that I'm running Linux 2.4.20 for ARM.
2.6 would make life simpler for you :-)
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 Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
On Thursday 06 May 2004 06:17, Geert Uytterhoeven wrote:
...
So you cannot access the frame buffer memory from the CPU, except through
sending commands to the LCD controller, right?
Right, but today I discovered that the display controller allows to have DMA
access for every "page" (8 lines on the display). Cool! ;-)
quoted
...
- how is the "refresh" done by fbdev? I don't want to keep sending the
same data to the display if there isn't any update to be done.
If the frame buffer memory is accessible directly by the CPU, it will be
updated automatically. If not, things get more difficult:
- For text console output, 2.4.x will do direct accesses to the frame
buffer, which won't work.
In 2.6.x, fbcon will call the fb_{fillrect,copyarea,imageblit}()
routines of your fbdev driver, so you can handle that easily
- For graphics from user space, things are more complex, since the
application cannot mmap() your frame buffer memory. Either you use a
shadow frame buffer that updates the hardware periodically, or teach your
application to talk to the LCD controller directly.
Given that DMA facility, I started to write the code with a frame buffer of
the same size of the screen and installed an interrupt handler for the DMA;
when a transfer of a page is done, it interrupts and I can switch this page
and select another "page" to be automatically updated to the display.
It won't update the entire display at a single time, but it will probably make
the magic. At least I got the impression that this could be a good logic,
I'll do some tests tomorrow and will tell if everything worked fine then :-)
quoted
- also related to this refresh: I haven't seen any interrupt being
handled by many fbdev drivers. Is this ok? How will fbdev knows when the
card is trying to communicate with the CPU?
Most drivers don't use interrupts yet, because until recently (speaking
about 2.6), you could not use them there.
I've seen some LCD display drivers for embedded devices that handled it
directly with request_irq() on 2.4. As I could see from the bottom layers of
fbdev, an interrupt handler in a driver doesn't seem to hurt anyone there..
or am I wrong?
quoted
- given that I can be told when the user is going to write some data to
the fbdev (should I implement my own fb_read and fb_write operations?),
is there an automatic way to get only the pixels that he's modifying?
This would save a lot of unnecessary transfers to the display as well.
You should implement your own fb_{read,write}() if the CPU cannot access
the frame buffer memory directly.
quoted
Just forgot to tell that I'm running Linux 2.4.20 for ARM.
2.6 would make life simpler for you :-)
Sure, I'll give a look for 2.6 fbdev ASAP, it already seems to have a better
interface, just by looking into the headers.
Cheers, and thanks for the reply,
Lucas
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
On Friday 07 May 2004 11:26, Lucas Correia Villa Real wrote:
On Thursday 06 May 2004 06:17, Geert Uytterhoeven wrote:
...
I've seen some LCD display drivers for embedded devices that handled it
directly with request_irq() on 2.4. As I could see from the bottom layers
of fbdev, an interrupt handler in a driver doesn't seem to hurt anyone
there.. or am I wrong?
Within the console, you probably can't use interrupts, at least in 2.4.x.
However, there are patches around that uses an interrupt service especially
with waiting for vrefresh. I've done it with the i810fb (around 2.4.18), and
I think matroxfb has one too.
Tony
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
On Friday 07 May 2004 10:33, Antonino A. Daplas wrote:
On Friday 07 May 2004 11:26, Lucas Correia Villa Real wrote:
quoted
On Thursday 06 May 2004 06:17, Geert Uytterhoeven wrote:
...
I've seen some LCD display drivers for embedded devices that handled it
directly with request_irq() on 2.4. As I could see from the bottom layers
of fbdev, an interrupt handler in a driver doesn't seem to hurt anyone
there.. or am I wrong?
Within the console, you probably can't use interrupts, at least in 2.4.x.
However, there are patches around that uses an interrupt service especially
with waiting for vrefresh. I've done it with the i810fb (around 2.4.18),
and I think matroxfb has one too.
Hi Tony,
I took a read into drivers/char/console.c, but it isn't clear to me why it's
not possible (or better yet, advised) to install interrupt handlers within
the console. Is it because tty devices are already called from interrupts?
Cheers,
Lucas
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3