Re: [git pull] drm: previous pull req + 1.

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.