Messages in this thread | | | Subject | Re: [git pull] drm: previous pull req + 1. | From | Benjamin Herrenschmidt <> | Date | Tue, 23 Jun 2009 09:57:43 +1000 |
| |
On Sun, 2009-06-21 at 12:47 -0700, Linus Torvalds wrote: > > What *has* changed is that we have a newradeon driver, and it looks > like > that new radeon driver is crap, and does this: > > info->fix.smem_start = (unsigned long)fbptr; > > which is totally screwed up. It assigns a _virtual_ address to that > "smem_start" thing, even though it should be a physical one.
BTW. While we are at it that there's an additional problem (old fbdev design issue) with that which is smem_start is an unsigned long, which is too small to hold a physical address on a variety of 32-bit platforms.
Dave, what about we split those structures into a "sane" in-kernel one and a "user visible" one ? At that point, we can create new saner variants of the user ones using separate ioctls ...
> I don't know the radeon driver, so I don't know where to find the > physical address. It's also possible that there is no good single > physical address, and the radeon driver should implement a "fb_mmap" > function. > > Does this patch make the warning and the oops at least go away? > Obviously it won't result in a working frame buffer, but that's a > separate issue
There should be a physical address but it's nasty to let userspace map it directly without using the DRM for access control, not sure what David plans here, but it may need surface control set properly etc...
Dave ? Should the fbdev mmap go down the DRM object map path or similar ?
Cheers, Ben.
| |