Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

2016-06-28 Thread Benjamin Herrenschmidt 
On Tue, 2016-06-28 at 15:25 +0200, Gerhard Pircher wrote:
> > 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) !?

Right that's a problem. We do the fixup before early_init_devtree() on
ppc32 (we don't on ppc64) ... ugh. I'll have to think about it. We can
try to make them match by moving the fixup but that means making
sure that the transition to the "initial" MMU mapping use for
machine_init() can be done without the fixups being applied.

I can have a quick sweep of the init code later today or tomorrow to
see how bad that would be.

Otherwise, compile option...

> 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" :-)

Heh ok.

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

2016-06-28 Thread Gerhard Pircher 
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

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

2016-06-28 Thread Benjamin Herrenschmidt 
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 ?

We could also make non-coherent cache a runtime option if we really
wanted, it's just more churn ...

> 206 pteg0 = ((eaddr & 0x0fff) >> 22) | (vsid << 7) |
> PTE_V |
> 207 (primary ? 0 : PTE_SEC);
> 208 pteg1 = hpaddr | PTE_M | PTE_R | PTE_C;
>  ^
> 
> > 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 ?

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

2016-06-28 Thread Gerhard Pircher 
On Mon, 2016-06-27 at 23:40 +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2016-06-27 at 22:42 +0200, Gerhard Pircher wrote:
> > This patch series reminds me of a long-standing issue with the
> > AmigaOne platform code, which would have to clear the coherence
> > (M) flag for every memory mapping to avoid lockups (especially
> > on G4 CPUs) - as you can read in the comment below your patch
> > above.
> > 
> > Now the follow-up code in amigaone/setup.c to clear the
> > corresponding CPU feature flag is essentially dead code (it used
> > to work with a second call of do_feature_fixups() before the
> > handling of the CPU_FTR_NEED_COHERENT flag was changed/inverted
> > somewhere around v2.6.30). Also it doesn't seem to fix all
> > deadlocks, as e.g. KVM virtual machines can still inject memory
> > mappings with the M flag set AFAICT.
> > 
> > Now I wonder, if there is a reasonably clean way to clear the M
> > flag in all hardware page table and BAT entries without defacing
> > generic kernel code too much. Any ideas?
> 
> Other than a compile time option ?
Well, I guess a runtime option would always be preferable, but I don't
see how this could be implemented without moving probe_machine() in
front of identify_cpu() (which doesn't look easy either). On the other
side the AmigaOne also requires CONFIG_NOT_COHERENT_CACHE set and this
one is still a compile time option, too.
The question is, if a compile time option that simply clears
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 in
arch/powerpc/kvm/book3s_32_mmu_host.c for this:

206 pteg0 = ((eaddr & 0x0fff) >> 22) | (vsid << 7) | PTE_V |
207 (primary ? 0 : PTE_SEC);
208 pteg1 = hpaddr | PTE_M | PTE_R | PTE_C;
 ^

> Do we know where the lockups come from btw ? A problem with the
> northbridge ?
Yes, it's a problem with the northbridge...as usual. :-(

> Cheers,
> Ben.

Thanks!

BR,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

2016-06-27 Thread Benjamin Herrenschmidt 
On Mon, 2016-06-27 at 22:42 +0200, Gerhard Pircher wrote:
> This patch series reminds me of a long-standing issue with the
> AmigaOne platform code, which would have to clear the coherence
> (M) flag for every memory mapping to avoid lockups (especially
> on G4 CPUs) - as you can read in the comment below your patch
> above.
> 
> Now the follow-up code in amigaone/setup.c to clear the
> corresponding CPU feature flag is essentially dead code (it used
> to work with a second call of do_feature_fixups() before the
> handling of the CPU_FTR_NEED_COHERENT flag was changed/inverted
> somewhere around v2.6.30). Also it doesn't seem to fix all
> deadlocks, as e.g. KVM virtual machines can still inject memory
> mappings with the M flag set AFAICT.
> 
> Now I wonder, if there is a reasonably clean way to clear the M
> flag in all hardware page table and BAT entries without defacing
> generic kernel code too much. Any ideas?

Other than a compile time option ? Do we know where the lockups come
from btw ? A problem with the northbridge ?

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

2016-06-27 Thread Gerhard Pircher 
Am 2016-06-27 um 13:29 schrieb Benjamin Herrenschmidt:
> This converts all the 32-bit platforms to use the expanded device-tree
> which is a pretty mechanical change. Unlike 64-bit, the 32-bit kernel
> didn't rely on platform initializations to setup the MMU since it
> sets it up entirely before probe_machine() so the move has comparatively
> less consequences though it's a bigger patch.
> 
> Signed-off-by: Benjamin Herrenschmidt 

[...]

> diff --git a/arch/powerpc/platforms/amigaone/setup.c 
> b/arch/powerpc/platforms/amigaone/setup.c
> index 2fe1204..a030d3b 100644
> --- a/arch/powerpc/platforms/amigaone/setup.c
> +++ b/arch/powerpc/platforms/amigaone/setup.c
> @@ -143,9 +143,7 @@ void amigaone_restart(char *cmd)
>  
>  static int __init amigaone_probe(void)
>  {
> - unsigned long root = of_get_flat_dt_root();
> -
> - if (of_flat_dt_is_compatible(root, "eyetech,amigaone")) {
> + if (of_machine_is_compatible("eyetech,amigaone")) {
>   /*
>* Coherent memory access cause complete system lockup! Thus
>* disable this CPU feature, even if the CPU needs it.
This patch series reminds me of a long-standing issue with the
AmigaOne platform code, which would have to clear the coherence
(M) flag for every memory mapping to avoid lockups (especially
on G4 CPUs) - as you can read in the comment below your patch
above.

Now the follow-up code in amigaone/setup.c to clear the
corresponding CPU feature flag is essentially dead code (it used
to work with a second call of do_feature_fixups() before the
handling of the CPU_FTR_NEED_COHERENT flag was changed/inverted
somewhere around v2.6.30). Also it doesn't seem to fix all
deadlocks, as e.g. KVM virtual machines can still inject memory
mappings with the M flag set AFAICT.

Now I wonder, if there is a reasonably clean way to clear the M
flag in all hardware page table and BAT entries without defacing
generic kernel code too much. Any ideas?

BR,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

2016-06-27 Thread Benjamin Herrenschmidt 
This converts all the 32-bit platforms to use the expanded device-tree
which is a pretty mechanical change. Unlike 64-bit, the 32-bit kernel
didn't rely on platform initializations to setup the MMU since it
sets it up entirely before probe_machine() so the move has comparatively
less consequences though it's a bigger patch.

Signed-off-by: Benjamin Herrenschmidt 
---
 arch/powerpc/kernel/setup_32.c| 35 +++-
 arch/powerpc/platforms/40x/ep405.c|  4 +--
 arch/powerpc/platforms/40x/ppc40x_simple.c|  2 +-
 arch/powerpc/platforms/40x/virtex.c   |  4 +--
 arch/powerpc/platforms/40x/walnut.c   |  4 +--
 arch/powerpc/platforms/44x/canyonlands.c  |  5 ++-
 arch/powerpc/platforms/44x/ebony.c|  4 +--
 arch/powerpc/platforms/44x/iss4xx.c   |  4 +--
 arch/powerpc/platforms/44x/ppc44x_simple.c|  3 +-
 arch/powerpc/platforms/44x/ppc476.c   |  6 ++--
 arch/powerpc/platforms/44x/sam440ep.c |  4 +--
 arch/powerpc/platforms/44x/virtex.c   |  4 +--
 arch/powerpc/platforms/44x/warp.c |  4 +--
 arch/powerpc/platforms/512x/mpc5121_ads.c |  4 +--
 arch/powerpc/platforms/512x/mpc512x_generic.c |  2 +-
 arch/powerpc/platforms/512x/pdm360ng.c|  4 +--
 arch/powerpc/platforms/52xx/efika.c   |  3 +-
 arch/powerpc/platforms/52xx/lite5200.c|  2 +-
 arch/powerpc/platforms/52xx/media5200.c   |  2 +-
 arch/powerpc/platforms/52xx/mpc5200_simple.c  |  2 +-
 arch/powerpc/platforms/82xx/ep8248e.c |  3 +-
 arch/powerpc/platforms/82xx/km82xx.c  |  3 +-
 arch/powerpc/platforms/82xx/mpc8272_ads.c |  3 +-
 arch/powerpc/platforms/82xx/pq2fads.c |  3 +-
 arch/powerpc/platforms/83xx/asp834x.c |  3 +-
 arch/powerpc/platforms/83xx/km83xx.c  |  3 +-
 arch/powerpc/platforms/83xx/mpc830x_rdb.c |  2 +-
 arch/powerpc/platforms/83xx/mpc831x_rdb.c |  2 +-
 arch/powerpc/platforms/83xx/mpc832x_mds.c |  4 +--
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |  4 +--
 arch/powerpc/platforms/83xx/mpc834x_itx.c |  4 +--
 arch/powerpc/platforms/83xx/mpc834x_mds.c |  4 +--
 arch/powerpc/platforms/83xx/mpc836x_mds.c |  4 +--
 arch/powerpc/platforms/83xx/mpc836x_rdk.c |  4 +--
 arch/powerpc/platforms/83xx/mpc837x_mds.c |  4 +--
 arch/powerpc/platforms/83xx/mpc837x_rdb.c |  2 +-
 arch/powerpc/platforms/83xx/sbc834x.c |  4 +--
 arch/powerpc/platforms/85xx/bsc913x_qds.c |  4 +--
 arch/powerpc/platforms/85xx/bsc913x_rdb.c |  4 +--
 arch/powerpc/platforms/85xx/c293pcie.c|  4 +--
 arch/powerpc/platforms/85xx/corenet_generic.c |  5 ++-
 arch/powerpc/platforms/85xx/ge_imp3a.c|  4 +--
 arch/powerpc/platforms/85xx/ksi8560.c |  4 +--
 arch/powerpc/platforms/85xx/mpc8536_ds.c  |  4 +--
 arch/powerpc/platforms/85xx/mpc85xx_ads.c |  4 +--
 arch/powerpc/platforms/85xx/mpc85xx_cds.c |  4 +--
 arch/powerpc/platforms/85xx/mpc85xx_ds.c  | 12 ++-
 arch/powerpc/platforms/85xx/mpc85xx_mds.c | 12 ++-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 40 ++-
 arch/powerpc/platforms/85xx/mvme2500.c|  4 +--
 arch/powerpc/platforms/85xx/p1010rdb.c|  6 ++--
 arch/powerpc/platforms/85xx/p1022_ds.c|  4 +--
 arch/powerpc/platforms/85xx/p1022_rdk.c   |  4 +--
 arch/powerpc/platforms/85xx/p1023_rdb.c   |  4 +--
 arch/powerpc/platforms/85xx/ppa8548.c |  4 +--
 arch/powerpc/platforms/85xx/qemu_e500.c   |  4 +--
 arch/powerpc/platforms/85xx/sbc8548.c |  4 +--
 arch/powerpc/platforms/85xx/socrates.c|  4 +--
 arch/powerpc/platforms/85xx/stx_gp3.c |  4 +--
 arch/powerpc/platforms/85xx/tqm85xx.c |  2 +-
 arch/powerpc/platforms/85xx/twr_p102x.c   |  4 +--
 arch/powerpc/platforms/85xx/xes_mpc85xx.c | 12 ++-
 arch/powerpc/platforms/86xx/gef_ppc9a.c   |  4 +--
 arch/powerpc/platforms/86xx/gef_sbc310.c  |  4 +--
 arch/powerpc/platforms/86xx/gef_sbc610.c  |  4 +--
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c|  4 +--
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|  6 ++--
 arch/powerpc/platforms/86xx/sbc8641d.c|  4 +--
 arch/powerpc/platforms/8xx/adder875.c |  3 +-
 arch/powerpc/platforms/8xx/ep88xc.c   |  3 +-
 arch/powerpc/platforms/8xx/mpc86xads_setup.c  |  3 +-
 arch/powerpc/platforms/8xx/mpc885ads_setup.c  |  3 +-
 arch/powerpc/platforms/8xx/tqm8xx_setup.c |  4 +--
 arch/powerpc/platforms/amigaone/setup.c   |  4 +--
 arch/powerpc/platforms/embedded6xx/c2k.c  |  4 +--
 arch/powerpc/platforms/embedded6xx/gamecube.c |  5 +--