Menu
▾
▴
linux-fbdev-devel
|
From: Sottek, M. J <mat...@in...> - 2002-10-30 21:10:02
|
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.=20 Read/write are also incorrect if your pitch !=3D 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:av...@ya...] Sent: Wednesday, October 30, 2002 2:49 AM To: lin...@li... 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=E7ais ! Yahoo! Mail : http://fr.mail.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by: Influence the future=20 of Java(TM) technology. Join the Java Community=20 Process(SM) (JCP(SM)) program now.=20 http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en _______________________________________________ Linux-fbdev-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
|
From: <av...@ya...> - 2002-10-31 04:02:29
|
> 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 <ad...@po...> 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 |
|
From: Antonino D. <ad...@po...> - 2002-10-31 11:07:49
|
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 |
|
From: James S. <jsi...@in...> - 2002-10-31 20:51:12
|
> 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:-) |
|
From: Antonino D. <ad...@po...> - 2002-10-31 21:21:32
|
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 |
|
From: Sottek, M. J <mat...@in...> - 2002-10-31 21:18:41
|
>:-( 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 |
|
From: James S. <jsi...@in...> - 2002-10-31 20:54:59
|
> 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. |
Thanks for helping keep SourceForge clean.
X