[Intel-gfx] [PATCH] make KMS resource mappings exclusive
Jesse Barnes
jbarnes at virtuousgeek.org
Tue Mar 17 00:35:46 CET 2009
On Thursday, March 12, 2009 10:42:22 am Jesse Barnes wrote:
> On Monday, March 9, 2009 3:29:40 am Simon Farnsworth wrote:
> > Eric Anholt wrote:
> > > On Mon, 2009-01-19 at 13:00 -0800, Jesse Barnes wrote:
> > >> This should help avoid problems with unsupported userspace programs or
> > >> configurations running on top of a KMS enabled driver. Updates the
> > >> ioremap to nocache as well, since that's really what we want to track.
> > >>
> > >> Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> > >
> > > For the record: the reason I've avoided doing this one is that when
> > > jbarnes and I talked, we figured that this prevents userland from
> > > mapping at all, though we really only care about preventing write
> > > mapping of the registers/aperture. Since we've still got a bunch of
> > > really useful userland tools for debugging that rely on read-only
> > > mapping of registers, we're pending this until we get that information
> > > into the kernel somehow.
> >
> > Is there a reason why booting with iomem=relaxed isn't enough to let the
> > userspace tools work?
>
> No, that should work, but it does make things a lot more difficult for
> testers, since it means they'd likely have to reboot to collect dumps,
> rather than just collecting them when they run into a problem. Eventually
> we'll be able to restrict the mappings though, after we support dumping the
> relevant info from debugfs instead.
On second thought it's probably ok to apply this patch. If users are having
display problems they're likely to be rebooting a lot anyway, so the
iomem=relaxed parameter will work.
Eric, what do you think? We definitely have users running into the non-KMS 2D
on top of KMS failure mode; preventing it seems like a good idea even if it
means slightly less convenient debugging...
--
Jesse Barnes, Intel Open Source Technology Center
More information about the Intel-gfx
mailing list