Re: [git pull] drm: previous pull req + 1.
From: Benjamin Herrenschmidt
Date: Mon Jun 22 2009 - 19:58:38 EST
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
> 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
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"
> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/