newbie: fb specs and indirect VRAM access

newbie: fb specs and indirect VRAM access

[Jorge Marques Pelizzoni]

Hi, all!

I am considering implementing a frame buffer device for a mobile platform
(LPC2400 on uCLinux) that, as far as I can tell, seems to lack one. Well,
I am a newbie to all things frame buffer-related (though familiar with
kernel/device module implementation) and would most appreciate it if you
could answer the following questions:

1 - are there documents specifying frame buffer devices and how
applications are expected to handle them (in short, their API)?

2 - my CPU cannot address "real" VRAM directly, all control being carried
out by means of a parallel interface. I gathered that an fb user is
expected to write to (virtual) VRAM directly via a pointer provided by the
driver and never notifies the driver of changes. Have you seen such a
set-up before and do you think these requirements can be reconciled? The
only way round this I can currently see is making the driver periodically
check the virtual VRAM for changes and transmit only changed parts. All in
all, a costly operation, as everything must be carried out by the same
CPU. Could whatever is used to implement mmap be called into play (without
whatever is used to implement msync)?

Thank you very much in advance.

Cheers,

Jorge M. Pelizzoni.





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: newbie: fb specs and indirect VRAM access

[Jorge Marques Pelizzoni]

Hi all,

A few days ago I sent the message below asking about framebuffer device
documentation and explaining my specific situation. Nobody aswered and I
wonder why. If those are not questions for this list, can someone please
redirect me to the right forum?

Thanks in advance.

Cheers,

Jorge.

Jorge Marques Pelizzoni escreveu:
> Hi, all!
>
> I am considering implementing a frame buffer device for a mobile platform
> (LPC2400 on uCLinux) that, as far as I can tell, seems to lack one. Well,
> I am a newbie to all things frame buffer-related (though familiar with
> kernel/device module implementation) and would most appreciate it if you
> could answer the following questions:
>
> 1 - are there documents specifying frame buffer devices and how
> applications are expected to handle them (in short, their API)?
>
> 2 - my CPU cannot address "real" VRAM directly, all control being carried
> out by means of a parallel interface. I gathered that an fb user is
> expected to write to (virtual) VRAM directly via a pointer provided by the
> driver and never notifies the driver of changes. Have you seen such a
> set-up before and do you think these requirements can be reconciled? The
> only way round this I can currently see is making the driver periodically
> check the virtual VRAM for changes and transmit only changed parts. All in
> all, a costly operation, as everything must be carried out by the same
> CPU. Could whatever is used to implement mmap be called into play (without
> whatever is used to implement msync)?
>
> Thank you very much in advance.
>
> Cheers,
>
> Jorge M. Pelizzoni.
>
>
>
>


Jorge M. Pelizzoni
ICMC - Universidade de São Paulo

call me at http://www.jaxtr.com/jpeliz


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: newbie: fb specs and indirect VRAM access

[Geert Uytterhoeven]

On Thu, 21 Aug 2008, Jorge Marques Pelizzoni wrote:
> A few days ago I sent the message below asking about framebuffer device
> documentation and explaining my specific situation. Nobody aswered and I
> wonder why. If those are not questions for this list, can someone please
> redirect me to the right forum?

I had hoped somebody else would find time to respond ;-)

> Jorge Marques Pelizzoni escreveu:
> > I am considering implementing a frame buffer device for a mobile platform
> > (LPC2400 on uCLinux) that, as far as I can tell, seems to lack one. Well,
> > I am a newbie to all things frame buffer-related (though familiar with
> > kernel/device module implementation) and would most appreciate it if you
> > could answer the following questions:
> >
> > 1 - are there documents specifying frame buffer devices and how
> > applications are expected to handle them (in short, their API)?

linux/Documentation/fb/framebuffer.txt
linux/include/linux/fb.h

> > 2 - my CPU cannot address "real" VRAM directly, all control being carried
> > out by means of a parallel interface. I gathered that an fb user is
> > expected to write to (virtual) VRAM directly via a pointer provided by the
> > driver and never notifies the driver of changes. Have you seen such a
> > set-up before and do you think these requirements can be reconciled? The
> > only way round this I can currently see is making the driver periodically
> > check the virtual VRAM for changes and transmit only changed parts. All in
> > all, a costly operation, as everything must be carried out by the same
> > CPU. Could whatever is used to implement mmap be called into play (without
> > whatever is used to implement msync)?

linux/Documentation/fb/deferred_io.txt

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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: newbie: fb specs and indirect VRAM access

[Jaya Kumar]

On Thu, Aug 21, 2008 at 8:54 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, 21 Aug 2008, Jorge Marques Pelizzoni wrote:
>> A few days ago I sent the message below asking about framebuffer device
>> documentation and explaining my specific situation. Nobody aswered and I
>> wonder why. If those are not questions for this list, can someone please
>> redirect me to the right forum?
>
> I had hoped somebody else would find time to respond ;-)
>
>> Jorge Marques Pelizzoni escreveu:
>> > I am considering implementing a frame buffer device for a mobile platform
>> > (LPC2400 on uCLinux) that, as far as I can tell, seems to lack one. Well,
>> > I am a newbie to all things frame buffer-related (though familiar with
>> > kernel/device module implementation) and would most appreciate it if you
>> > could answer the following questions:
>> >
>> > 1 - are there documents specifying frame buffer devices and how
>> > applications are expected to handle them (in short, their API)?
>
> linux/Documentation/fb/framebuffer.txt
> linux/include/linux/fb.h
>
>> > 2 - my CPU cannot address "real" VRAM directly, all control being carried
>> > out by means of a parallel interface. I gathered that an fb user is
>> > expected to write to (virtual) VRAM directly via a pointer provided by the
>> > driver and never notifies the driver of changes. Have you seen such a
>> > set-up before and do you think these requirements can be reconciled? The
>> > only way round this I can currently see is making the driver periodically
>> > check the virtual VRAM for changes and transmit only changed parts. All in
>> > all, a costly operation, as everything must be carried out by the same
>> > CPU. Could whatever is used to implement mmap be called into play (without
>> > whatever is used to implement msync)?
>
> linux/Documentation/fb/deferred_io.txt

One note about this. If you're using LPC2400, I think that's an ARM7.
TDMI so no MMU which I think matches your mention of uclinux.
Unfortunately, defio has a dependency on MMU. There are other
possibilities to achieve the same effect but I'm not familiar with the
2400 and I'm not sure if it can do it.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: newbie: fb specs and indirect VRAM access

[Geert Uytterhoeven]

On Thu, 21 Aug 2008, Jaya Kumar wrote:
> On Thu, Aug 21, 2008 at 8:54 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Thu, 21 Aug 2008, Jorge Marques Pelizzoni wrote:
> >> Jorge Marques Pelizzoni escreveu:
> >> > I am considering implementing a frame buffer device for a mobile platform
> >> > (LPC2400 on uCLinux) that, as far as I can tell, seems to lack one. Well,

> > linux/Documentation/fb/deferred_io.txt
> 
> One note about this. If you're using LPC2400, I think that's an ARM7.
> TDMI so no MMU which I think matches your mention of uclinux.
> Unfortunately, defio has a dependency on MMU. There are other
> possibilities to achieve the same effect but I'm not familiar with the
> 2400 and I'm not sure if it can do it.

Oops, sorry, didn't notice that part. Yes, it depends on the presence of
a MMU.

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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: newbie: fb specs and indirect VRAM access

[Jorge Marques Pelizzoni]

Thank you all for your replies!

Jaya, that's exactly my case: an ARM7, with no MMU. If possible - and very
briefly - could you so much as cite the other possibilities you envision
so I can research them?

Thanks in advance.

Cheers,

Jorge.

Geert Uytterhoeven escreveu:
> On Thu, 21 Aug 2008, Jaya Kumar wrote:
>> On Thu, Aug 21, 2008 at 8:54 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > On Thu, 21 Aug 2008, Jorge Marques Pelizzoni wrote:
>> >> Jorge Marques Pelizzoni escreveu:
>> >> > I am considering implementing a frame buffer device for a mobile
>> platform
>> >> > (LPC2400 on uCLinux) that, as far as I can tell, seems to lack
one.
>> Well,
>
>> > linux/Documentation/fb/deferred_io.txt
>> One note about this. If you're using LPC2400, I think that's an ARM7.
TDMI so no MMU which I think matches your mention of uclinux.
>> Unfortunately, defio has a dependency on MMU. There are other
>> possibilities to achieve the same effect but I'm not familiar with the
2400 and I'm not sure if it can do it.
>
> Oops, sorry, didn't notice that part. Yes, it depends on the presence of
a MMU.
>
> 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
>


Jorge M. Pelizzoni
ICMC - Universidade de São Paulo

call me at http://www.jaxtr.com/jpeliz





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/