[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ia64
Subject:    Re: pgprot_writecombine & shub 1.x
From:       Jesse Barnes <jbarnes () engr ! sgi ! com>
Date:       2005-01-12 19:32:51
Message-ID: 200501121132.51722.jbarnes () engr ! sgi ! com
[Download RAW message or body]

On Wednesday, January 12, 2005 10:51 am, Jim Hull wrote:
> Jesse Barnes wrote:
> > But what about places that unconditionally set the WC bit
> > regardless of what the EFI memory map says?
>
> To be blunt - those places are broken, at least from the perspective of the
> IPF (ia64 if you prefer) architecture.  IPF declares that it is the
> platform which gets to decide the supported attributes for each address
> range, and provides the EFI memory map to inform the OS of this support.
>
> > pci_mmap_page_range does this for
> > example if the write_combine flag is set on the vma.
> > I'm looking for a way to abstract out
> > uses like that, so that shub 1.x systems don't set the bit.
>
> I'm not really qualified to design the right linux interfaces, but to be
> IPF compliant, you need to change all such places to first consult the EFI
> memory map.  Whether you do this once at boot time, on every call, whether
> to fail an unsupported request or remap the attribute to something the
> platform can support (e.g., mapping WC to UC), is all up to you.

Thanks for clarifying, that would certainly make things easier from our 
perspective.  I suppose that potentially makes the pgprot_* calls a bit more 
expensive, but with the benefit that they won't clash with what EFI tells the 
kernel about how memory works.

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]