Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
On Mon, Nov 11, 2019 at 11:29 AM Christoph Hellwig wrote: > > On Mon, Nov 11, 2019 at 11:27:27AM +0100, Arnd Bergmann wrote: > > Ok, fair enough. Let's just go with your version for now, if only to not > > hold your series up more. I'd still suggest we change atyfb to only > > use ioremap_uc() on i386 and maybe ia64. I can send a patch for that. > > I don't think we even need it on ia64. But lets kick off a dicussion > with the atyfb, x86 and ia64 maintainers after this series is in. > Which was kinda my plan anyway. I missed your reply and already sent my patch now. I guess it doesn't hurt to discuss that in parallel. Anyway I think that this patch is the last one you want an Ack from me for (let me know if I missed one), so Reviewed-by: Arnd Bergmann ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
On Mon, Nov 11, 2019 at 11:27:27AM +0100, Arnd Bergmann wrote: > Ok, fair enough. Let's just go with your version for now, if only to not > hold your series up more. I'd still suggest we change atyfb to only > use ioremap_uc() on i386 and maybe ia64. I can send a patch for that. I don't think we even need it on ia64. But lets kick off a dicussion with the atyfb, x86 and ia64 maintainers after this series is in. Which was kinda my plan anyway. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
On Mon, Nov 11, 2019 at 11:15 AM Christoph Hellwig wrote:
>
> On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote:
> > Maybe we could move the definition into the atyfb driver itself?
> >
> > As I understand it, the difference between ioremap()/ioremap_nocache()
> > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
> > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
> > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
> > anyway.
>
> That's not how I understood it. Based on the code and the UC-
> explanation ioremap_uc always overrides the MTRR, which can still
> be present on more modern x86 systems.
As I understand, the point is that on PAT-enabled systems, the
normal ioremap() *also* overrides the MTRR, citing from
Documentation/x86/pat.rst:
=== === = =
MTRR Non-PAT PAT Linux ioremap valueEffective memory type
=== === = =
PATNon-PAT | PAT
|PCD |
||PWT |
||||
WC000 WB _PAGE_CACHE_MODE_WB WC | WC
WC001 WC _PAGE_CACHE_MODE_WC WC* | WC
WC010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC
WC011 UC _PAGE_CACHE_MODE_UC UC | UC
=== === = =
> In fact I remember a patch
> floating around very recently adding another ioremap_uc caller in
> some Atom platform device driver that works around buggy MTRR
> tables. Also this series actually adds a new override and a few
> callers for ia64 platform code, which works very similar to x86
> based on the comments in the code. That being said I'm not sure
> the callers in ia64 are really required, but it was the safest thing
> to do as part of this cleanup.
Ok, fair enough. Let's just go with your version for now, if only to not
hold your series up more. I'd still suggest we change atyfb to only
use ioremap_uc() on i386 and maybe ia64. I can send a patch for that.
Arnd
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
