>>> Thomas Schlichter <thomas.schlich...@web.de> 12.10.09 20:32 >>>
>@@ -268,11 +269,14 @@ EXPORT_SYMBOL(ioremap_nocache);
>  */
> void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
> {
>-      if (pat_enabled)
>-              return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
>-                                      __builtin_return_address(0));
>-      else
>-              return ioremap_nocache(phys_addr, size);
>+      if (!pat_enabled) {
>+              void __iomem *ret = ioremap_nocache(phys_addr, size);
>+              if (ret)
>+                      mtrr_add(phys_addr, size, MTRR_TYPE_WRCOMB, false);

This won't work if phys_addr or size aren't page aligned, or if size isn't
a power of two.

>+              return ret;
>+      }
>+      return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
>+                              __builtin_return_address(0));
> }
> EXPORT_SYMBOL(ioremap_wc);
> 
>@@ -1010,8 +1011,13 @@ int set_memory_wc(unsigned long addr, int numpages)
> {
>       int ret;
> 
>-      if (!pat_enabled)
>-              return set_memory_uc(addr, numpages);
>+      if (!pat_enabled) {
>+              ret = set_memory_uc(addr, numpages);
>+              if (!ret)
>+                      mtrr_add(__pa(addr), numpages * PAGE_SIZE,
>+                               MTRR_TYPE_WRCOMB, false);

Similarly, this requires numpages to be a power of two.

>+              return ret;
>+      }
> 
>       ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
>               _PAGE_CACHE_WC, NULL);

I think user mode code handles this by splitting the request and trying to
establish as many entries as possible (and those as big as possible).

Also, in all cases you pass 'false' for the 'increment' parameter, in order
to avoid having to tear down the established entries. While this may be
reasonable for kernel initiated mappings, I don't think that's acceptable
for such originating from user mode.

Jan


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to