On Sat, May 4, 2013 at 10:45 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote:
This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The interface is simplified (because the base and size parameters to drm_mtrr_del never did anything) and it uses mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems that don't need them.
Signed-off-by: Andy Lutomirski luto@amacapital.net
Tbh I'm not a big fan of the drm_ indirection. Historically that was useful as an OS abstraction layer so that the same drivers could be used unchanged on Linux and the *BSD. But those days are long gone and drm drivers are now proper Linux drivers, and generally OS HALs seem to be frowned upon.
Is there another reason than just being consistent with the historic stuff here? If we need dummy functions for !CONFIG_MTRR I think those should simply be in the core.
I admit to a bit of cargo-culting. There was a layer of indirection, so I kept it. I'll just call mtrr_add/del_wc_if_needed directly in v2 (I added those functions in patch 1 of this series).
I'd assume you're okay with skipping mtrr addition if PAT is available since i915 already does it :) (Although the current logic is buggy -- cpu_has_pat is the wrong flag to check -- I think pat_enabled is better.)
Note to self: I should remove #include <asm/pat.h> in i915_dma.c in v2.
--Andy