Re: [PATCH v3] powerpc/xics: Work around limitations of OPAL XICS priority handling

2017-03-06 Thread Benjamin Herrenschmidt
On Mon, 2017-03-06 at 20:36 +1100, Michael Ellerman wrote: > > According to the HW guys, that should be 5ms in case the powerbus > > is > > really really busy. > > Is that a metric or imperial "really really" ?  :D No idea ;-) Could be the amount of time after which their own timeouts kick in.

Re: [PATCH v3] powerpc/xics: Work around limitations of OPAL XICS priority handling

2017-03-06 Thread Michael Ellerman
Benjamin Herrenschmidt writes: > On Sat, 2017-03-04 at 23:03 +1100, Michael Ellerman wrote: >> + >> +   /* Allow "sufficient" time to drop any inflight IRQ's */ >> +   mdelay(1); >> + > > According to the HW guys, that should be 5ms in case the powerbus is > really

Re: [PATCH v3] powerpc/xics: Work around limitations of OPAL XICS priority handling

2017-03-05 Thread Benjamin Herrenschmidt
On Sat, 2017-03-04 at 23:03 +1100, Michael Ellerman wrote: > + > +   /* Allow "sufficient" time to drop any inflight IRQ's */ > +   mdelay(1); > + According to the HW guys, that should be 5ms in case the powerbus is really really busy. Cheers, Ben.

[PATCH v3] powerpc/xics: Work around limitations of OPAL XICS priority handling

2017-03-04 Thread Michael Ellerman
From: Balbir Singh The CPPR (Current Processor Priority Register) of a XICS interrupt presentation controller contains a value N, such that only interrupts with a priority "more favoured" than N will be received by the CPU, where "more favoured" means "less than". So if