Re: Fbdev magics

Re: Fbdev magics

[Geert Uytterhoeven]

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

Re: Re: Fbdev magics

[Lucas Correia Villa Real]

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! ;-)

> > ...
> > - 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 :-)


> > - 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?

> > - 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 :-)

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

Re: Re: Fbdev magics

[Antonino A. Daplas]

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

Re: Re: Fbdev magics

[Lucas Correia Villa Real]

On Friday 07 May 2004 10:33, Antonino A. Daplas wrote:
> 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.

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