On Tue, 2016-06-28 at 14:01 +0200, Benjamin Herrenschmidt wrote: > On Tue, 2016-06-28 at 13:42 +0200, Gerhard Pircher wrote: > > The question is, if a compile time option that simply clear ?s > > CPU_FTR_NEED_COHERENT after identify_cpu() would be acceptable. And > > then I still wonder why KVM needs its own similar fix to work on the > > AmigaOne. I specifically had to remove/clear the PTE_M bit > > inarch/powerpc/kvm/book3s_32_mmu_host.c for th > > No we could just add something to early_init_devtree that does clear > that bit if it sees the relevant piece of broken HW, it's not the AmigaOne > per-se, it's the northbridge right ? Does that work for CPU_FTR_NEED_COHERENT, given that the feature fixups are done right after identify_cpu() and instructions within BEGIN_FTR_SECTION and END_FTR_SECTION* are patched out (if I understand this mechanism correctly) !? But yes, the specific northbridge is the problem here.
> We could also make non-coherent cache a runtime option if we really > wanted, it's just more churn ... Yeah, I remember a discussion or two about this topic and I always wondered how driver code would differentiate then between non-coherent and coherent DMA, given that they sometimes require different handling of the DMA addresses (e.g. if I look at /sound/core/pcm_native.c or the DRM code). > > > Do we know where the lockups come from btw ? A problem with the > > > northbridge ? > > Yes, it's a problem with the northbridge...as usual. :-( > > Marvell ? No, the one with the dreaded "A" name: MAI Logic's "Articia S" :-) BR, Gerhard _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
