RE: Framebuffer with banked memory

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

  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