Framebuffer with banked memory

Framebuffer with banked memory

[alain volmat]

Hi,

I've been searching on the mailing list concerning the
case of writing a framebuffer for a video card which
DOESN'T have linear video memory. Actually I didn't
found any reply to my question.
(well this might means that there is no solution to my
problem .. but in that case I would like
confirmation).

As I said the video card I am now writing a
framebuffer for, doesn't have linear memory, which
means that I can only access a small part of the
memory at a time and then set offset registers in
order to access another part of the memory.

I would like to know if there is such case in current
framebuffer drivers ?? If so, what is the common
solution to do that ??

In fact the problem remains in the case of mmap (which
is the most common ;( of course), since the memory
seams to be accessed directly by pointer, there might
be no wait to detect if we need to set or not an
offset. In case of fb_read fb_write, it is possible to
do that before the actual write at the end (even if it
is not sooo beautiful ... ).

Anyway, it would be very helpful to me if I could get
an answer to this question.
Thanks by advance.

Alain Volmat

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: Framebuffer with banked memory

[Antonino Daplas]

On Wed, 2002-10-30 at 18:49, alain volmat wrote:
> Hi,
> 
> As I said the video card I am now writing a
> framebuffer for, doesn't have linear memory, which
> means that I can only access a small part of the
> memory at a time and then set offset registers in
> order to access another part of the memory.
> 
> I would like to know if there is such case in current
> framebuffer drivers ?? If so, what is the common
> solution to do that ??
None in the current drivers.  

> 
> In fact the problem remains in the case of mmap (which
> is the most common ;( of course), since the memory
> seams to be accessed directly by pointer, there might
> be no wait to detect if we need to set or not an
> offset. In case of fb_read fb_write, it is possible to
> do that before the actual write at the end (even if it
> is not sooo beautiful ... ).
The safest solution is to create custom fb_write? and fb_read? routines.
Maybe James will add these hooks for hardware like yours.
Then disallow mmap's except probably for the MMIO regions.

Creating a bank-switching mechanism, besides entailing a lot of work, is
not entirely safe.

Tony

PS:  What's your hardware?





-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

RE: Framebuffer with banked memory

[Sottek, Matthew J]

Alain,
   I worked on an i810 driver that would use the banked memory instead of
requiring agp to be functioning at boot time (See the other thread going on
now).  Basically the i810 can use banked memory OR have agpgart.
  The short answer to your problem is that, sadly, much of the 2.4
framebuffer is badly implemented, allowing device independent code to
directly access device memory etc. Some of this is cleaned up for 2.5, but
as I've not looked at it lately I'm not sure how much.  Here are some
pointers as to what is required for 2.4.

#1 The Boot penguin code directly accesses your video memory. If you have
banked memory this will likely fall off the end of a pointer and oops the
kernel or worse.

#2 Read/Write Access video memory directly. I had added a read/write
handler to the fb_ops to hook these out and switch banks. 
Read/write are also incorrect if your pitch != width.

#3 Memory map can't be done. I had coded up a working version that would
map a single back and page fault in the banks as necessary. This worked
but would get hung up on unaligned accesses where one instruction accessed
two memory banks at the same time. So memory map isn't possible.

 The jist was that I could disable memory map. Implement character drawing
with bank switching. Implement read/write handlers that did bank switching,
then make the read/write fops use the handlers. Then lastly redo the
penguin drawing code to use the write handler rather than direct access.
All this to get a console... and not much else.

-Matt



-----Original Message-----
From: alain volmat [mailto:avolmat@yahoo.fr]
Sent: Wednesday, October 30, 2002 2:49 AM
To: linux-fbdev-devel@lists.sourceforge.net
Subject: [Linux-fbdev-devel] Framebuffer with banked memory


Hi,

I've been searching on the mailing list concerning the
case of writing a framebuffer for a video card which
DOESN'T have linear video memory. Actually I didn't
found any reply to my question.
(well this might means that there is no solution to my
problem .. but in that case I would like
confirmation).

As I said the video card I am now writing a
framebuffer for, doesn't have linear memory, which
means that I can only access a small part of the
memory at a time and then set offset registers in
order to access another part of the memory.

I would like to know if there is such case in current
framebuffer drivers ?? If so, what is the common
solution to do that ??

In fact the problem remains in the case of mmap (which
is the most common ;( of course), since the memory
seams to be accessed directly by pointer, there might
be no wait to detect if we need to set or not an
offset. In case of fb_read fb_write, it is possible to
do that before the actual write at the end (even if it
is not sooo beautiful ... ).

Anyway, it would be very helpful to me if I could get
an answer to this question.
Thanks by advance.

Alain Volmat

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

RE: Framebuffer with banked memory

[James Simmons]

>   The short answer to your problem is that, sadly, much of the 2.4
> framebuffer is badly implemented, allowing device independent code to
> directly access device memory etc. Some of this is cleaned up for 2.5, but
> as I've not looked at it lately I'm not sure how much.  Here are some
> pointers as to what is required for 2.4.
>
> #1 The Boot penguin code directly accesses your video memory. If you have
> banked memory this will likely fall off the end of a pointer and oops the
> kernel or worse.

Fixed in 2.5.X. You use the image drawing function to draw the penguin.

> #2 Read/Write Access video memory directly. I had added a read/write
> handler to the fb_ops to hook these out and switch banks.
> Read/write are also incorrect if your pitch != width.

Fixed. I have hooks now. I didn't notice the pitch != width problem. Give
me time to fix up a patch, unless someone bets me to the punch.

> #3 Memory map can't be done. I had coded up a working version that would
> map a single back and page fault in the banks as necessary. This worked
> but would get hung up on unaligned accesses where one instruction accessed
> two memory banks at the same time. So memory map isn't possible.

:-( Even with providing your own mmap function you still couldn't get it
to work.




-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: Framebuffer with banked memory

[alain volmat]

> The safest solution is to create custom fb_write?
> and fb_read? routines.
> Maybe James will add these hooks for hardware like
> yours.
> Then disallow mmap's except probably for the MMIO
> regions.
> 

What about adding fb_write / fb_read function in the
framebuffer (device dependant) driver. The same way as
for fb_mmap. I saw that at the beginning of fb_mmap in
fbmem.c, there is a test to see if the device driver
contains its own fb_mmap function, if so the device
driver fb_mmap will be used instead of the "generic"
fb_mmap. What about doing the same thing for fb_write
/ fb_read.

> PS:  What's your hardware?
Well actually it's a custom chip.

Alain

 --- Antonino Daplas <adaplas@pol.net> a écrit : > On
Wed, 2002-10-30 at 18:49, alain volmat wrote:
> > Hi,
> > 
> > As I said the video card I am now writing a
> > framebuffer for, doesn't have linear memory, which
> > means that I can only access a small part of the
> > memory at a time and then set offset registers in
> > order to access another part of the memory.
> > 
> > I would like to know if there is such case in
> current
> > framebuffer drivers ?? If so, what is the common
> > solution to do that ??
> None in the current drivers.  
> 
> > 
> > In fact the problem remains in the case of mmap
> (which
> > is the most common ;( of course), since the memory
> > seams to be accessed directly by pointer, there
> might
> > be no wait to detect if we need to set or not an
> > offset. In case of fb_read fb_write, it is
> possible to
> > do that before the actual write at the end (even
> if it
> > is not sooo beautiful ... ).
> The safest solution is to create custom fb_write?
> and fb_read? routines.
> Maybe James will add these hooks for hardware like
> yours.
> Then disallow mmap's except probably for the MMIO
> regions.
> 
> Creating a bank-switching mechanism, besides
> entailing a lot of work, is
> not entirely safe.
> 
> Tony
> 
> PS:  What's your hardware?
> 
> 
> 


___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: Framebuffer with banked memory

[Antonino Daplas]

On Thu, 2002-10-31 at 12:02, alain volmat wrote:
> 
> What about adding fb_write / fb_read function in the
> framebuffer (device dependant) driver. The same way as
> for fb_mmap. I saw that at the beginning of fb_mmap in
> fbmem.c, there is a test to see if the device driver
> contains its own fb_mmap function, if so the device
> driver fb_mmap will be used instead of the "generic"
> fb_mmap. What about doing the same thing for fb_write
> / fb_read.
> 
I've seen a post by James sometimes ago about adding fb_write and
fb_read to info->fbops.  

Tony



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: Framebuffer with banked memory

[James Simmons]

> On Thu, 2002-10-31 at 12:02, alain volmat wrote:
> >
> > What about adding fb_write / fb_read function in the
> > framebuffer (device dependant) driver. The same way as
> > for fb_mmap. I saw that at the beginning of fb_mmap in
> > fbmem.c, there is a test to see if the device driver
> > contains its own fb_mmap function, if so the device
> > driver fb_mmap will be used instead of the "generic"
> > fb_mmap. What about doing the same thing for fb_write
> > / fb_read.
> >
> I've seen a post by James sometimes ago about adding fb_write and
> fb_read to info->fbops.

Correct. The next set of fbdev changes will include this plus I added
fb_sync!!! Iknow this will make you happy:-)



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: Framebuffer with banked memory

[Antonino Daplas]

On Fri, 2002-11-01 at 05:44, James Simmons wrote:
> 
> > On Thu, 2002-10-31 at 12:02, alain volmat wrote:
> > >
> > > What about adding fb_write / fb_read function in the
> > > framebuffer (device dependant) driver. The same way as
> > > for fb_mmap. I saw that at the beginning of fb_mmap in
> > > fbmem.c, there is a test to see if the device driver
> > > contains its own fb_mmap function, if so the device
> > > driver fb_mmap will be used instead of the "generic"
> > > fb_mmap. What about doing the same thing for fb_write
> > > / fb_read.
> > >
> > I've seen a post by James sometimes ago about adding fb_write and
> > fb_read to info->fbops.
> 
> Correct. The next set of fbdev changes will include this plus I added
> fb_sync!!! Iknow this will make you happy:-)
> 

Indeed :-), not just me, but others too, I guess. Selective hardware
syncs will maximize the graphics instruction pipeline.

Tony



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

RE: Framebuffer with banked memory

[Sottek, Matthew J]

>:-( Even with providing your own mmap function you still couldn't get it
>to work.

Is that a question?
I did make it work. It worked just fine however when a client accesses a
bank via the mmap you have to fault in that bank and _unmap_ the other
bank from the client's mmap. This isn't something the kernel lets you
do from a module (for good reason).

The problem is that when one instruction accesses two banks at the same
time there is no possible way to have both banks present and the fault
handler would get stuck trying to satisfy the impossible. It doesn't
happen in normal aligned accesses (I had XFree running on it) but it
is a timebomb waiting to go off so I stopped pursuing it.

-Matt




-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en