Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
On Tue, 2014-10-07 at 19:47 -0400, Alex Deucher wrote: > > This moves the setting of the quirk flag to the audio driver. > > > > While recent ASICs have that problem fixed, they don't seem to > > be listed in the PCI IDs of the current driver, so let's quirk all > > the ATI HDMI for now. The consequences are nil on x86 anyway. > > > > Signed-off-by: Alex Deucher > > Signed-off-by: Benjamin Herrenschmidt > > CC: > > Further discussion with the hw teams have revealed that this is still > an issue on newer asics so I think your original patch is correct > after all. Just disable 64 bit MSIs on all AMD audio PCI ids. Allright, I won't resend the whole series, I can just pickup my previous patch. Takashi, Bjorn, Dave, this series covers your 3 areas of maintainership, how do you want to proceed ? I'm happy to merge the whole lot via powerpc ASAP (since it's all CC'ed stable) if you guys send me the appropriate acks, otherwise, let me know. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
On Wed, Oct 8, 2014 at 1:28 AM, Benjamin Herrenschmidt wrote: > On Tue, 2014-10-07 at 19:47 -0400, Alex Deucher wrote: >> > This moves the setting of the quirk flag to the audio driver. >> > >> > While recent ASICs have that problem fixed, they don't seem to >> > be listed in the PCI IDs of the current driver, so let's quirk all >> > the ATI HDMI for now. The consequences are nil on x86 anyway. >> > >> > Signed-off-by: Alex Deucher >> > Signed-off-by: Benjamin Herrenschmidt >> > CC: >> >> Further discussion with the hw teams have revealed that this is still >> an issue on newer asics so I think your original patch is correct >> after all. Just disable 64 bit MSIs on all AMD audio PCI ids. > > Allright, I won't resend the whole series, I can just pickup my previous > patch. Takashi, Bjorn, Dave, this series covers your 3 areas of > maintainership, how do you want to proceed ? I'm happy to merge the > whole lot via powerpc ASAP (since it's all CC'ed stable) if you guys > send me the appropriate acks, otherwise, let me know. > I don't remember if I gave my formal review of your original patch, so if not, Reviewed-by: Alex Deucher Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc: mitigate impact of decrementer reset
Paul,
what if your tb wraps during the test?
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+heinz.wrobel=freescale@lists.ozlabs.org] On Behalf Of Paul
> Clarke
> Sent: Tuesday, October 07, 2014 21:13
> To: linuxppc-dev@lists.ozlabs.org
> Subject: [PATCH] powerpc: mitigate impact of decrementer reset
>
> The POWER ISA defines an always-running decrementer which can be used to
> schedule interrupts after a certain time interval has elapsed.
> The decrementer counts down at the same frequency as the Time Base, which
> is 512 MHz. The maximum value of the decrementer is 0x7fff.
> This works out to a maximum interval of about 4.19 seconds.
>
> If a larger interval is desired, the kernel will set the decrementer to its
> maximum value and reset it after it expires (underflows) a sufficient number
> of
> times until the desired interval has elapsed.
>
> The negative effect of this is that an unwanted latency spike will impact
> normal
> processing at most every 4.19 seconds. On an IBM POWER8-based system, this
> spike was measured at about 25-30 microseconds, much of which was basic,
> opportunistic housekeeping tasks that could otherwise have waited.
>
> This patch short-circuits the reset of the decrementer, exiting after the
> decrementer reset, but before the housekeeping tasks if the only need for the
> interrupt is simply to reset it. After this patch, the latency spike was
> measured
> at about 150 nanoseconds.
>
> Signed-off-by: Paul A. Clarke
> ---
> arch/powerpc/kernel/time.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index
> 368ab37..962a06b 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -528,6 +528,7 @@ void timer_interrupt(struct pt_regs * regs)
> {
> struct pt_regs *old_regs;
> u64 *next_tb = &__get_cpu_var(decrementers_next_tb);
> + u64 now;
>
> /* Ensure a positive value is written to the decrementer, or else
>* some CPUs will continue to take decrementer exceptions.
> @@ -550,6 +551,18 @@ void timer_interrupt(struct pt_regs * regs)
>*/
> may_hard_irq_enable();
>
> + /* If this is simply the decrementer expiring (underflow) due to
> + * the limited size of the decrementer, and not a set timer,
> + * reset (if needed) and return
> + */
> + now = get_tb_or_rtc();
> + if (now < *next_tb) {
What if "now" and *next_tb are not on the same wrap count? They are both modulo
values AFACS.
Shouldn't this be right here more like a "if ((*next_tb - now) < 2^63)" style
test to check for deltas within the range instead of absolute values?
> + now = *next_tb - now;
> + if (now <= DECREMENTER_MAX)
> + set_dec((int)now);
> + __get_cpu_var(irq_stat).timer_irqs_others++;
> + return;
> + }
>
> #if defined(CONFIG_PPC32) && defined(CONFIG_PPC_PMAC)
> if (atomic_read(&ppc_n_lost_interrupts) != 0)
> --
> 2.1.2.330.g565301e
BR,
Heinz
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3,16/16] cxl: Add documentation for userspace APIs
On Tue, 2014-07-10 at 10:48:22 UTC, Michael Neuling wrote: > From: Ian Munsie > > This documentation gives an overview of the hardware architecture, userspace > APIs via /dev/cxl/afu0.0 and the syfs files. It also adds a MAINTAINERS file Elsewhere you talk about /dev/cxl/afuM.N, please be consistent. > diff --git a/Documentation/ABI/testing/sysfs-class-cxl > b/Documentation/ABI/testing/sysfs-class-cxl > new file mode 100644 > index 000..ca429fc > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-class-cxl > @@ -0,0 +1,142 @@ > +Slave contexts (eg. /sys/class/cxl/afu0.0): Don't slave contexts end with 's' ? > + > +What:/sys/class/cxl//irqs_max > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling We just had to fix up a bunch of these for someone who left IBM. Would it be better if they just pointed to linuxppc-dev ? > +Description: read only > + Maximum number of interrupts that can be requested by userspace. > + The default on probe is the maximum that hardware can support > + (eg. 2037). Write values will limit userspace applications to I thought it was read only? > + that many userspace interrupts. Must be >= irqs_min. Decimal, hex? > +What:/sys/class/cxl//irqs_min > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: read only > + The minimum number of interrupts that userspace must request > + on a CXL_START_WORK ioctl. Userspace may omit the > + num_interrupts field in the START_WORK IOCTL to get this > + minimum automatically. > + > +What:/sys/class/cxl//mmio_size > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: read only > + Size of the MMIO space that may be mmaped by userspace. Decimal, hex? Bytes, KB ? > +What:/sys/class/cxl//models_supported > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: read only > + List of the models this AFU supports. So there can be more than one? How are multiple values separated? > + Valid entries are: "dedicated_process" and "afu_directed" > + > +What:/sys/class/cxl//model > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: read/write > + The current model the AFU is using. Will be one of the models > + given in models_supported. Writing will change the model > + provided that no user contexts are attached. > + > + > +What:/sys/class/cxl//prefault_mode > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: read/write > + Set the mode for prefaulting in segments into the segment table > + when performing the START_WORK ioctl. Possible values: > + none: No prefaulting (default) > + wed: Treat the wed as an effective address and prefault > it > + all: all segments this process currently maps "this" process is not entirely clear. You mean "the process that calls START_WORK" ? > +What:/sys/class/cxl//reset > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: write only > + Reset the AFU. How does this interact with the chardev API? Do my contexts go away or stop working or anything? > +What:/sys/class/cxl//api_version > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: read only > + List the current version of the kernel/user API. Show not List. Decimal, hex? > +What:/sys/class/cxl//api_version_com > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: read only > + List the lowest version the kernel/user API this > + kernel is compatible with. Show not List. Decimal, hex? And needs to be clearer: "The lowest version of the userspace API that this kernel supports." > +Master contexts (eg. /sys/class/cxl/afu0.0m) > + > +What:/sys/class/cxl/m/mmio_size > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: read only > + Size of the MMIO space that may be mmaped by userspace. This > + includes all slave contexts space also. Units. > +What:/sys/class/cxl/m/pp_mmio_len > +Date:September 2014 > +Contact: Ian Munsie , > + Michael Neuling > +Description: read only > + Per Process MMIO space l
Re: [RFC PATCH v3 1/3] powerpc: Fix warning reported by verify_cpu_node_mapping()
On 二, 2014-10-07 at 08:33 -0700, Nishanth Aravamudan wrote: > On 07.10.2014 [17:28:38 +1100], Michael Ellerman wrote: > > On Fri, 2014-10-03 at 16:26 -0700, Nishanth Aravamudan wrote: > > > On 03.10.2014 [10:50:20 +1000], Michael Ellerman wrote: > > > > On Thu, 2014-10-02 at 14:13 -0700, Nishanth Aravamudan wrote: > > > > > Ben & Michael, > > > > > > > > > > What's the status of these patches? > > > > > > > > Been in my next for a week :) > > > > > > > > https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=next > > > > > > Ah ok, thanks -- I wasn't following your tree, my fault. > > > > Not really your fault, I hadn't announced my trees existence :) > > > > > Do we want these to go back to 3.17-stable, as they fix some annoying > > > splats > > > during boot (non-fatal afaict, though)? > > > > Up to you really, I don't know how often/bad they were. I haven't added CC > > stable tags to the commits, so if you want them in stable you should send > > them > > explicitly. > > I think they occur every boot, unconditionally, on pseries. Doesn't > prevent boot, just really noisy. I think it'd be good to get them into > -stable. > > Li Zhong, can you push them once they get sent upstream? Ok, I will send these patches to stable mailing list after it is merged. Thanks, Zhong > > Thanks, > Nish ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH tty-next 14/22] tty: Remove tty_wait_until_sent_from_close()
On 06/17/2014 07:03 AM, David Laight wrote: > From: Peter Hurley > ... >>> I don't understand the second half of the changelog, it doesn't seem >>> to fit here: there deadlock that we are trying to avoid here happens >>> when the *same* tty needs the lock to complete the function that >>> sends the pending data. I don't think we do still do that any more, >>> but it doesn't seem related to the tty lock being system-wide or not. >> >> The tty lock is not used in the i/o path; it's purpose is to >> mutually exclude state changes in open(), close() and hangup(). >> >> The commit that added this [1] comments that _other_ ttys may wait >> for this tty to complete, and comments in the code note that this >> function should be removed when the system-wide tty mutex was removed >> (which happened with the commit noted in the changelog). I just wanted to revisit this discussion briefly so I can clarify the situation regarding holding the tty lock while closing, and how that affects parallel opens. I've unnested the tty lock from the tty mutex (which I'm still testing) but will be submitting after the merge window re-opens for 3.19. So this is more relevant now. The original patch that led to this thread is here: https://lkml.org/lkml/2014/6/16/306 > What happens if another process tries to do a non-blocking open > while you are sleeping in close waiting for output to drain? > > Hopefully this returns before that data has drained. Current mainline blocks on _any_ racing re-open while this lock is dropped in tty_wait_until_sent_from_close(); blocking while ASYNC_CLOSING has been in mainline since at least 2.6.29 and that just merged existing code together. See tty_port_block_til_ready(); note the test for O_NONBLOCK is after the wait while ASYNC_CLOSING. IOW, currently a non-blocking open will sleep for the _entire_ duration of a parallel hardware shutdown, and when it wakes, the error return will cause a release of its tty, and it will restart with a fresh attempt to open. Same with a blocking open that is already waiting; when its woken the hardware shutdown has already completed so ASYNC_INITIALIZED is cleared, which forces a release and restart too. The point being that holding the tty lock across the _entire_ close is equivalent to the current outcome, regardless of O_NONBLOCK. I'm reluctant to start returning EGAIN for non-blocking tty opens because no tty driver does that now, and I don't think userspace will deal well with new return codes from tty opens. Regards, Peter Hurley ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
> -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, October 01, 2014 8:44 AM > To: Guenter Roeck > Cc: Jojy Varghese; Benjamin Herrenschmidt; Paul Mackerras; Michael > Ellerman; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; > Guenter Roeck; Jia Hongtao-B38951 > Subject: Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check > exception on E500MC / E5500 > > On Tue, 2014-09-30 at 08:50 -0700, Guenter Roeck wrote: > > On Mon, Sep 29, 2014 at 06:31:06PM -0500, Scott Wood wrote: > > > On Mon, 2014-09-29 at 23:03 +, Jojy Varghese wrote: > > > > > > > > On 9/29/14 12:06 PM, "Guenter Roeck" wrote: > > > > > > > > >Those are errors related to PCIe hotplug, and are seen with > > > > >unexpected PCIe device removals (triggered, for example, by > > > > >removing power from a PCIe adapter). > > > > >The behavior we see on E5500 is quite similar to the same > > > > >behavior on > > > > >E500: > > > > >If unhandled, the CPU keeps executing the same instruction over > > > > >and over again if there is an error on a PCIe access and thus > > > > >stalls. I don't know if this is considered an erratum or expected > > > > >behavior, but it is one we have to address since we have to be > > > > >able to handle that condition. > > > > > > The reason I ask is that the handling for e500 was described as an > > > erratum workaround. If it is an erratum it would be nice to know > > > the erratum number and the full list of affected chips. > > > > > My understanding, which may be wrong, was that this is expected > > behavior, at least for E5500. I actually thought I had seen it > > somewhere in the specification (response to PCIe errors), but I don't > recall where exactly. > > > > At least for my part I am not aware of an erratum. > > Jia Hongtao, can you comment here? I did not find any related erratum either. > > > > > >Ultimately, we'll want > > > > >to > > > > >implement PCIe error handlers for the affected drivers, but that > > > > >will be a next step. > > > > > > For now can we at least print a ratelimited error message? I don't > > > like the idea of silently ignoring these errors. I suppose it's a > > > separate issue from extending the workaround to cover e500mc, though. > > > > > I don't really like the idea of printing an error message pretty much > > each time when an unexpected hotplug event occurs. > > Unexpected events seem like the sort of thing you'd want to log, but my > concern is that this might not be the only cause of PCI errors. > > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, September 30, 2014 2:36 AM
> To: Guenter Roeck
> Cc: Benjamin Herrenschmidt; Paul Mackerras; Michael Ellerman; linuxppc-
> d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Jojy G Varghese;
> Guenter Roeck; Jia Hongtao-B38951
> Subject: Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check
> exception on E500MC / E5500
>
> On Mon, 2014-09-29 at 09:48 -0700, Guenter Roeck wrote:
> > From: Jojy G Varghese
> >
> > For E500MC and E5500, a machine check exception in pci(e) memory space
> > crashes the kernel.
> >
> > Testing shows that the MCAR(U) register is zero on a MC exception for
> > the
> > E5500 core. At the same time, DEAR register has been found to have the
> > address of the faulty load address during an MC exception for this core.
> >
> > This fix changes the current behavior to fixup the result register and
> > instruction pointers in the case of a load operation on a faulty PCI
> > address.
> >
> > The changes are:
> > - Added the hook to pci machine check handing to the e500mc machine
> check
> > exception handler.
> > - For the E5500 core, load faulting address from SPRN_DEAR register.
> > As mentioned above, this is necessary because the E5500 core does not
> > report the fault address in the MCAR register.
> >
> > Cc: Scott Wood
> > Signed-off-by: Jojy G Varghese [Guenter Roeck:
> > updated description]
> > Signed-off-by: Guenter Roeck
> > Signed-off-by: Guenter Roeck
> > ---
> > arch/powerpc/kernel/traps.c | 3 ++-
> > arch/powerpc/sysdev/fsl_pci.c | 5 +
> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> > index 0dc43f9..ecb709b 100644
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -494,7 +494,8 @@ int machine_check_e500mc(struct pt_regs *regs)
> > int recoverable = 1;
> >
> > if (reason & MCSR_LD) {
> > - recoverable = fsl_rio_mcheck_exception(regs);
> > + recoverable = fsl_rio_mcheck_exception(regs) ||
> > + fsl_pci_mcheck_exception(regs);
> > if (recoverable == 1)
> > goto silent_out;
> > }
> > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > b/arch/powerpc/sysdev/fsl_pci.c index c507767..bdb956b 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > @@ -1021,6 +1021,11 @@ int fsl_pci_mcheck_exception(struct pt_regs
> > *regs) #endif
> > addr += mfspr(SPRN_MCAR);
> >
> > +#ifdef CONFIG_E5500_CPU
> > + if (mfspr(SPRN_EPCR) & SPRN_EPCR_ICM)
> > + addr = PFN_PHYS(vmalloc_to_pfn((void *)mfspr(SPRN_DEAR)));
> #endif
>
> Kconfig tells you what hardware is supported, not what hardware you're
> actually running on.
>
> Jia Hongtao, do you know anything about this issue? Is there an erratum?
Sorry for the late response, I just return from my vacation.
I don't know this issue.
> What chips are affected by the the erratum covered by
>
RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
> -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, September 30, 2014 7:58 AM > To: Tang Yuantian-B29983 > Cc: Mike Turquette; linuxppc-dev@lists.ozlabs.org; > linux-ker...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; Lu Jingchang-B35083 > Subject: Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add > CLK_OF_DECLARE support > > On Sat, 2014-09-27 at 21:18 -0500, Tang Yuantian-B29983 wrote: > > > -Original Message- > > > From: Linuxppc-dev > > > [mailto:linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org] > > > On Behalf Of Mike Turquette > > > Sent: Saturday, September 27, 2014 7:29 AM > > > To: Wood Scott-B07421 > > > Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; > > > linux-arm-ker...@lists.infradead.org; Lu Jingchang-B35083 > > > Subject: Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add > > > CLK_OF_DECLARE support > > > > > > Quoting Scott Wood (2014-09-25 15:56:20) > > > > On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote: > > > > > Quoting Scott Wood (2014-09-25 13:08:00) > > > > > > Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be > > > > > > made to work on PPC rather than have the driver carry around > > > > > > two binding methods. > > > > > > > > > > I guess that is an existing problem, and not related directly to > > > > > this patch? This patch is essentially just renames (though the > > > > > V1.0/V2.0 stuff seems weird). > > > > > > > > This patch is adding CLK_OF_DECLARE. > > > > > > I'm fine taking this patch but your comments are still unresolved. > > > What do you think needs to be done to fix the problems that you see? > > > > > CLK_OF_DECLARE is totally worked on PPC. I will do it in a separate patch. > > Regarding V1.0 and V2.0, it is not wired just same for now. But we are not > > sure > if it is same for v3.0 in the future. > > > > Besides updating drivers/cpufreq/Kconfig.powerpc, there is one more thing I > am not comfortable with: > > This patch uses " fixed-clock" as sysclk's compatible string, while on PPC > > we > treated it as " fsl,qoriq-sysclk-[1-2].0". > > That's inconsistent on both ARM and PPC platforms, neither did on bindings. > > fsl,qoriq-sysclk-XXX is the way it is because of compatibility with the > fixups in > existing U-Boots. It shouldn't be used as a model. > > That said, I don't think you really mean "this patch", as it doesn't contain > the > device tree updates, and "fixed-clock" does not appear. > "fixed-clock" will appear when ls102x platform DTS gets upstreamed eventually. That would be fine if you don't think "fsl,qoriq-sysclk-xxx" having different meaning on ARM and PowerPC is a issue. Thanks, Yuantian > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: mitigate impact of decrementer reset
On Tue, 2014-07-10 at 19:13:24 UTC, Paul Clarke wrote: > The POWER ISA defines an always-running decrementer which can be used > to schedule interrupts after a certain time interval has elapsed. > The decrementer counts down at the same frequency as the Time Base, > which is 512 MHz. The maximum value of the decrementer is 0x7fff. > This works out to a maximum interval of about 4.19 seconds. > > If a larger interval is desired, the kernel will set the decrementer > to its maximum value and reset it after it expires (underflows) > a sufficient number of times until the desired interval has elapsed. > > The negative effect of this is that an unwanted latency spike will > impact normal processing at most every 4.19 seconds. On an IBM > POWER8-based system, this spike was measured at about 25-30 > microseconds, much of which was basic, opportunistic housekeeping > tasks that could otherwise have waited. > > This patch short-circuits the reset of the decrementer, exiting after > the decrementer reset, but before the housekeeping tasks if the only > need for the interrupt is simply to reset it. After this patch, > the latency spike was measured at about 150 nanoseconds. Hi Paul, Thanks for the excellent changelog. But this patch makes me a bit nervous :) Do you know where the latency is coming from? Is it primarily the irq work? If so I'd prefer if we could move the short circuit into __timer_interrupt() itself. That way we'd still have the trace points usable, and it would hopefully result in less duplicated logic. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3, 08/16] powerpc/powerpc: Add new PCIe functions for allocating cxl interrupts
On Wed, 2014-10-08 at 09:59 +1100, Michael Ellerman wrote: > On Tue, 2014-07-10 at 10:48:14 UTC, Michael Neuling wrote: > > From: Ian Munsie > > > > This adds a number of functions for allocating IRQs under powernv PCIe for > > cxl. > > > > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c > > b/arch/powerpc/platforms/powernv/pci-ioda.c > > index baf3de6..3b67010b 100644 > > --- a/arch/powerpc/platforms/powernv/pci-ioda.c > > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c > > @@ -38,6 +38,8 @@ > > #include > > #include > > > > +#include > > You should be including pnv-pci.h here. > > Otherwise the header and the implementation could get out of sync, it will > also > fix these: > > arch/powerpc/platforms/powernv/pci-ioda.c:1365:5: warning: symbol > 'pnv_phb_to_cxl' was not declared. Should it be static? > arch/powerpc/platforms/powernv/pci-ioda.c:1389:5: warning: symbol > 'pnv_cxl_alloc_hwirqs' was not declared. Should it be static? > arch/powerpc/platforms/powernv/pci-ioda.c:1404:6: warning: symbol > 'pnv_cxl_release_hwirqs' was not declared. Should it be static? > arch/powerpc/platforms/powernv/pci-ioda.c:1413:6: warning: symbol > 'pnv_cxl_release_hwirq_ranges' was not declared. Should it be static? > arch/powerpc/platforms/powernv/pci-ioda.c:1433:5: warning: symbol > 'pnv_cxl_alloc_hwirq_ranges' was not declared. Should it be static? > arch/powerpc/platforms/powernv/pci-ioda.c:1470:5: warning: symbol > 'pnv_cxl_get_irq_count' was not declared. Should it be static? > arch/powerpc/platforms/powernv/pci-ioda.c:1479:5: warning: symbol > 'pnv_cxl_ioda_msi_setup' was not declared. Should it be static? Ok... will fix. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3,12/16] cxl: Add base builtin support
On Wed, 2014-10-08 at 10:04 +1100, Michael Ellerman wrote: > On Tue, 2014-07-10 at 10:48:18 UTC, Michael Neuling wrote: > > From: Ian Munsie > > > > This adds the base cxl support that needs to be build into the kernel to use > > cxl as a module. This is needed so that the cxl call backs from the core > > powerpc mm code always exist irrespective of if the cxl module is loaded or > > not. This is similar to how cell works with CONFIG_SPU_BASE. > > > > This adds a cxl_slbia() call (similar to spu_flush_all_slbs()) which checks > > for > > the cxl module being loaded. If the modules is not loaded we return, > > otherwise > > we call into the cxl SLB invalidation code. > > > > This also adds the cxl_ctx_in_use() function for use in the mm code to see > > if > > any cxl contexts are currently in use. This is used by the tlbie() to > > determine if it can do local TLB invalidations or not. This also adds > > get/put > > calls for the cxl driver module to refcount the active cxl contexts. > > This last paragraph is no longer true. Yep, thanks. I'll move it to patch 7 where it does apply. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
On Tue, Oct 7, 2014 at 7:49 PM, Benjamin Herrenschmidt wrote: > On Tue, 2014-10-07 at 19:47 -0400, Alex Deucher wrote: >> > While recent ASICs have that problem fixed, they don't seem to >> > be listed in the PCI IDs of the current driver, so let's quirk all >> > the ATI HDMI for now. The consequences are nil on x86 anyway. >> > >> > Signed-off-by: Alex Deucher >> > Signed-off-by: Benjamin Herrenschmidt >> > CC: >> >> Further discussion with the hw teams have revealed that this is still >> an issue on newer asics so I think your original patch is correct >> after all. Just disable 64 bit MSIs on all AMD audio PCI ids. > > Ok. You confirm that this is however good on newer video side right ? > Yes, this was definitely fixed on the GPU side. > Also, is there a known issue that if MSI were once enabled, the chip > still shoots them even if we disable them in config space ? > > When testing my new patch set, I was trying to test the error path > when the arch does *not* honor the limitation. The error went back > up to the driver as far as I can tell (ie, pci_enable_msi() failed), > but the system still got into error state as if the card had tried > to shoot an MSI to the wrong address. > > (I suspect the graphics side) I'm not aware of any such issue, but I can ask the hw guys if there is anything special required to disable MSIs beyond the pci config space settings. Alex > > Cheers, > Ben. > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/44] kernel: Move pm_power_off to common code
On Monday, October 06, 2014 10:28:10 PM Guenter Roeck wrote: > pm_power_off is defined for all architectures. Move it to common code. > > Have all architectures call do_kernel_poweroff instead of pm_power_off. > Some architectures point pm_power_off to machine_power_off. For those, > call do_kernel_poweroff from machine_power_off instead. ACK -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
On Tue, 2014-10-07 at 19:47 -0400, Alex Deucher wrote: > > While recent ASICs have that problem fixed, they don't seem to > > be listed in the PCI IDs of the current driver, so let's quirk all > > the ATI HDMI for now. The consequences are nil on x86 anyway. > > > > Signed-off-by: Alex Deucher > > Signed-off-by: Benjamin Herrenschmidt > > CC: > > Further discussion with the hw teams have revealed that this is still > an issue on newer asics so I think your original patch is correct > after all. Just disable 64 bit MSIs on all AMD audio PCI ids. Ok. You confirm that this is however good on newer video side right ? Also, is there a known issue that if MSI were once enabled, the chip still shoots them even if we disable them in config space ? When testing my new patch set, I was trying to test the error path when the arch does *not* honor the limitation. The error went back up to the driver as far as I can tell (ie, pci_enable_msi() failed), but the system still got into error state as if the card had tried to shoot an MSI to the wrong address. (I suspect the graphics side) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
On Tue, Oct 7, 2014 at 12:38 AM, Benjamin Herrenschmidt
wrote:
> From: Signed-off-by: Alex Deucher
>
> A number of radeon cards have a HW limitation causing them to be
> unable to generate the full 64-bit of address bits for MSIs. This
> breaks MSIs on some platforms such as POWER machines.
>
> We used to have a powerpc specific quirk to address that on a
> single card, but this doesn't scale very well, this is better
> put under control of the drivers who know precisely what a given
> HW revision can do.
>
> This moves the setting of the quirk flag to the audio driver.
>
> While recent ASICs have that problem fixed, they don't seem to
> be listed in the PCI IDs of the current driver, so let's quirk all
> the ATI HDMI for now. The consequences are nil on x86 anyway.
>
> Signed-off-by: Alex Deucher
> Signed-off-by: Benjamin Herrenschmidt
> CC:
Further discussion with the hw teams have revealed that this is still
an issue on newer asics so I think your original patch is correct
after all. Just disable 64 bit MSIs on all AMD audio PCI ids.
Alex
> ---
> sound/pci/hda/hda_intel.c | 96
> +--
> sound/pci/hda/hda_priv.h | 1 +
> 2 files changed, 69 insertions(+), 28 deletions(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 99b367b..af38ed9 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1506,9 +1506,14 @@ static int azx_first_init(struct azx *chip)
> return -ENXIO;
> }
>
> - if (chip->msi)
> + if (chip->msi) {
> + if (chip->driver_caps & AZX_DCAPS_NO_MSI64) {
> + dev_dbg(card->dev, "Disabling 64bit MSI\n");
> + pci->no_64bit_msi = true;
> + }
> if (pci_enable_msi(pci) < 0)
> chip->msi = 0;
> + }
>
> if (azx_acquire_irq(chip, 0) < 0)
> return -EBUSY;
> @@ -2070,58 +2075,93 @@ static const struct pci_device_id azx_ids[] = {
> { PCI_DEVICE(0x1022, 0x780d),
> .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
> /* ATI HDMI */
> - { PCI_DEVICE(0x1002, 0x793b),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + { PCI_DEVICE(0x1002, 0x1314),
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0x7919),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> + { PCI_DEVICE(0x1002, 0x7969),
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> + { PCI_DEVICE(0x1002, 0x793b),
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0x960f),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> + { PCI_DEVICE(0x1002, 0x9646),
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0x970f),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaa00),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaa08),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaa10),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaa18),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaa20),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaa28),
> - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaa30),
> -
Re: [PATCH 44/44] kernel: Remove pm_power_off
On Monday, October 06, 2014 10:28:46 PM Guenter Roeck wrote:
> No users of pm_power_off are left, so it is safe to remove the function.
>
> Cc: Rafael J. Wysocki
> Cc: Pavel Machek
> Cc: Len Brown
> Signed-off-by: Guenter Roeck
ACK
> ---
> include/linux/pm.h | 1 -
> kernel/power/poweroff_handler.c | 10 +-
> 2 files changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index 45271b5..fce7645 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -31,7 +31,6 @@
> /*
> * Callbacks for platform drivers to implement.
> */
> -extern void (*pm_power_off)(void);
> extern void (*pm_power_off_prepare)(void);
>
> /*
> diff --git a/kernel/power/poweroff_handler.c b/kernel/power/poweroff_handler.c
> index 96f59ef..01a3a39 100644
> --- a/kernel/power/poweroff_handler.c
> +++ b/kernel/power/poweroff_handler.c
> @@ -20,12 +20,6 @@
> #include
>
> /*
> - * If set, calling this function will power off the system immediately.
> - */
> -void (*pm_power_off)(void);
> -EXPORT_SYMBOL(pm_power_off);
> -
> -/*
> * Notifier list for kernel code which wants to be called
> * to power off the system.
> */
> @@ -163,8 +157,6 @@ int register_poweroff_handler_simple(void
> (*handler)(void), int priority)
> */
> void do_kernel_poweroff(void)
> {
> - if (pm_power_off)
> - pm_power_off();
> atomic_notifier_call_chain(&poweroff_handler_list, 0, NULL);
> }
>
> @@ -175,6 +167,6 @@ void do_kernel_poweroff(void)
> */
> bool have_kernel_poweroff(void)
> {
> - return pm_power_off != NULL || poweroff_handler_list.head != NULL;
> + return poweroff_handler_list.head != NULL;
> }
> EXPORT_SYMBOL(have_kernel_poweroff);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/44] hibernate: Call have_kernel_poweroff instead of checking pm_power_off
On Monday, October 06, 2014 10:28:05 PM Guenter Roeck wrote: > Poweroff handlers may now be installed with register_poweroff_handler. > Use the new API function have_kernel_poweroff to determine if a poweroff > handler has been installed. > > Cc: Rafael J. Wysocki > Cc: Pavel Machek > Cc: Len Brown > Signed-off-by: Guenter Roeck ACK > --- > kernel/power/hibernate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c > index a9dfa79..20353c5 100644 > --- a/kernel/power/hibernate.c > +++ b/kernel/power/hibernate.c > @@ -602,7 +602,7 @@ static void power_down(void) > case HIBERNATION_PLATFORM: > hibernation_platform_enter(); > case HIBERNATION_SHUTDOWN: > - if (pm_power_off) > + if (have_kernel_poweroff()) > kernel_power_off(); > break; > #ifdef CONFIG_SUSPEND > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3,12/16] cxl: Add base builtin support
On Tue, 2014-07-10 at 10:48:18 UTC, Michael Neuling wrote: > From: Ian Munsie > > This adds the base cxl support that needs to be build into the kernel to use > cxl as a module. This is needed so that the cxl call backs from the core > powerpc mm code always exist irrespective of if the cxl module is loaded or > not. This is similar to how cell works with CONFIG_SPU_BASE. > > This adds a cxl_slbia() call (similar to spu_flush_all_slbs()) which checks > for > the cxl module being loaded. If the modules is not loaded we return, otherwise > we call into the cxl SLB invalidation code. > > This also adds the cxl_ctx_in_use() function for use in the mm code to see if > any cxl contexts are currently in use. This is used by the tlbie() to > determine if it can do local TLB invalidations or not. This also adds get/put > calls for the cxl driver module to refcount the active cxl contexts. This last paragraph is no longer true. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3, 08/16] powerpc/powerpc: Add new PCIe functions for allocating cxl interrupts
On Tue, 2014-07-10 at 10:48:14 UTC, Michael Neuling wrote: > From: Ian Munsie > > This adds a number of functions for allocating IRQs under powernv PCIe for > cxl. > > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c > b/arch/powerpc/platforms/powernv/pci-ioda.c > index baf3de6..3b67010b 100644 > --- a/arch/powerpc/platforms/powernv/pci-ioda.c > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c > @@ -38,6 +38,8 @@ > #include > #include > > +#include You should be including pnv-pci.h here. Otherwise the header and the implementation could get out of sync, it will also fix these: arch/powerpc/platforms/powernv/pci-ioda.c:1365:5: warning: symbol 'pnv_phb_to_cxl' was not declared. Should it be static? arch/powerpc/platforms/powernv/pci-ioda.c:1389:5: warning: symbol 'pnv_cxl_alloc_hwirqs' was not declared. Should it be static? arch/powerpc/platforms/powernv/pci-ioda.c:1404:6: warning: symbol 'pnv_cxl_release_hwirqs' was not declared. Should it be static? arch/powerpc/platforms/powernv/pci-ioda.c:1413:6: warning: symbol 'pnv_cxl_release_hwirq_ranges' was not declared. Should it be static? arch/powerpc/platforms/powernv/pci-ioda.c:1433:5: warning: symbol 'pnv_cxl_alloc_hwirq_ranges' was not declared. Should it be static? arch/powerpc/platforms/powernv/pci-ioda.c:1470:5: warning: symbol 'pnv_cxl_get_irq_count' was not declared. Should it be static? arch/powerpc/platforms/powernv/pci-ioda.c:1479:5: warning: symbol 'pnv_cxl_ioda_msi_setup' was not declared. Should it be static? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 4/5] kexec: Add IND_FLAGS macro
Add a new kexec preprocessor macro IND_FLAGS, which is the bitwise OR of
all the possible kexec IND_ kimage_entry indirection flags. Having this
macro allows for simplified code in the prosessing of the kexec
kimage_entry items. Also, remove the local powerpc definition and use
the generic one.
Signed-off-by: Geoff Levand
Cc: Benjamin Herrenschmidt
Acked-by: Vivek Goyal
---
From V2: Folded patch 5 into patch 4.
arch/powerpc/kernel/machine_kexec_64.c | 2 --
include/linux/kexec.h | 1 +
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 879b3aa..75652a32 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -96,8 +96,6 @@ int default_machine_kexec_prepare(struct kimage *image)
return 0;
}
-#define IND_FLAGS (IND_DESTINATION | IND_INDIRECTION | IND_DONE | IND_SOURCE)
-
static void copy_segments(unsigned long ind)
{
unsigned long entry;
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 8c628ca..a4758f9 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -10,6 +10,7 @@
#define IND_INDIRECTION (1 << IND_INDIRECTION_BIT)
#define IND_DONE (1 << IND_DONE_BIT)
#define IND_SOURCE (1 << IND_SOURCE_BIT)
+#define IND_FLAGS (IND_DESTINATION | IND_INDIRECTION | IND_DONE | IND_SOURCE)
#if !defined(__ASSEMBLY__)
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: mitigate impact of decrementer reset
The POWER ISA defines an always-running decrementer which can be used
to schedule interrupts after a certain time interval has elapsed.
The decrementer counts down at the same frequency as the Time Base,
which is 512 MHz. The maximum value of the decrementer is 0x7fff.
This works out to a maximum interval of about 4.19 seconds.
If a larger interval is desired, the kernel will set the decrementer
to its maximum value and reset it after it expires (underflows)
a sufficient number of times until the desired interval has elapsed.
The negative effect of this is that an unwanted latency spike will
impact normal processing at most every 4.19 seconds. On an IBM
POWER8-based system, this spike was measured at about 25-30
microseconds, much of which was basic, opportunistic housekeeping
tasks that could otherwise have waited.
This patch short-circuits the reset of the decrementer, exiting after
the decrementer reset, but before the housekeeping tasks if the only
need for the interrupt is simply to reset it. After this patch,
the latency spike was measured at about 150 nanoseconds.
Signed-off-by: Paul A. Clarke
---
arch/powerpc/kernel/time.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 368ab37..962a06b 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -528,6 +528,7 @@ void timer_interrupt(struct pt_regs * regs)
{
struct pt_regs *old_regs;
u64 *next_tb = &__get_cpu_var(decrementers_next_tb);
+ u64 now;
/* Ensure a positive value is written to the decrementer, or else
* some CPUs will continue to take decrementer exceptions.
@@ -550,6 +551,18 @@ void timer_interrupt(struct pt_regs * regs)
*/
may_hard_irq_enable();
+ /* If this is simply the decrementer expiring (underflow) due to
+* the limited size of the decrementer, and not a set timer,
+* reset (if needed) and return
+*/
+ now = get_tb_or_rtc();
+ if (now < *next_tb) {
+ now = *next_tb - now;
+ if (now <= DECREMENTER_MAX)
+ set_dec((int)now);
+ __get_cpu_var(irq_stat).timer_irqs_others++;
+ return;
+ }
#if defined(CONFIG_PPC32) && defined(CONFIG_PPC_PMAC)
if (atomic_read(&ppc_n_lost_interrupts) != 0)
--
2.1.2.330.g565301e
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/20] powerpc: Convert power off logic to pm_power_off
On Tue, Oct 07, 2014 at 07:47:35PM +0200, Alexander Graf wrote: > > > On 07.10.14 19:00, Guenter Roeck wrote: > > On Tue, Oct 07, 2014 at 01:35:07PM +0200, Alexander Graf wrote: > >> > >> > >> On 07.10.14 08:25, Michael Ellerman wrote: > >>> On Mon, 2014-10-06 at 12:00 +0200, Alexander Graf wrote: > > On 03.10.14 06:42, Michael Ellerman wrote: > > On Wed, 2014-10-01 at 15:27 +0200, Alexander Graf wrote: > >> The generic Linux framework to power off the machine is a function > >> pointer > >> called pm_power_off. The trick about this pointer is that device > >> drivers can > >> potentially implement it rather than board files. > >> > >> Today on PowerPC we set pm_power_off to invoke our generic full > >> machine power > >> off logic which then calls ppc_md.power_off to invoke machine specific > >> power > >> off. > >> > >> To fix this up, let's get rid of the ppc_md.power_off logic and just > >> always use > >> pm_power_off as was intended. Then individual drivers such as the GPIO > >> power off > >> driver can implement power off logic via that function pointer. > > > > This looks OK to me with one caveat. > > > > In several of the patches you're replacing a static initialisation with > > a > > runtime one, and you're doing the runtime initialisation in > > xxx_setup_arch(). > > That's reasonably late, so I'd prefer you did it in xxx_probe(). > > Heh, I had it in xxx_probe() originally and then realized that > > a) the power off function is basically a driver. Driver initialization > happens in xxx_setup_arch() and > > b) the maple target already does overwrite its power_off callback in > xxx_setup_arch and > > c) on all targets xxx_probe() is very slim and doesn't do much > > but I'll happily change it back to put the bits in xxx_probe() instead. > >>> > >>> Thanks. > >>> > >>> That way you shouldn't be changing behaviour. > >>> > >>> It may still be the case that some power off routines don't actually work > >>> until > >>> later, but that's an existing problem. Some power off routines *do* work > >>> before > >>> setup_arch(), so they will continue to work. > >> > >> Ok, works for me :). Just wanted to make sure you're aware of the > >> reasoning why I didn't do it in probe(). > >> > >>> Also, how does your series interact with Guenter's that removes > >>> pm_power_off ? > >>> It seems at the moment they are unaware of each other. > >> > >> Guenters patches convert users of pm_power_off to his new scheme. We're > >> not even at that stage at all yet in the powerpc tree. Converting > >> everything to pm_power_off is basically a first step. His patch set > >> maintains pm_power_off, so there shouldn't be nasty conflicts. > >> > > Onlly the first m68k patch, though. The very last patch in the series > > remvoes pm_power_off. > > And there go my patch reading skills ... :). > > For which window are you targeting this? 3.18 or 3.19? If you're trying > to hit 3.18, I can easily wait with my patch set and base it on top of > yours. > Definitely 3.19; this is way too late for 3.18 and will need some time to mature in -next. I can merge with your code once it is ready to go and you can make an immutable branch available. Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V25/5] powerpc/kexec: Use global IND_FLAGS macro
On Tue, Oct 07, 2014 at 12:21:30AM +, Geoff Levand wrote:
> linux/kexec.h now defines an IND_FLAGS macro. Remove the local powerpc
> definition and use the generic one.
>
> Signed-off-by: Geoff Levand
I think this patch should be merged in previous patch. I guess after
applying patch4, series might not be compilable as there are two
definitions of IND_FLAGS now.
Thanks
Vivek
> ---
> arch/powerpc/kernel/machine_kexec_64.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c
> b/arch/powerpc/kernel/machine_kexec_64.c
> index 879b3aa..75652a32 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
> @@ -96,8 +96,6 @@ int default_machine_kexec_prepare(struct kimage *image)
> return 0;
> }
>
> -#define IND_FLAGS (IND_DESTINATION | IND_INDIRECTION | IND_DONE | IND_SOURCE)
> -
> static void copy_segments(unsigned long ind)
> {
> unsigned long entry;
> --
> 1.9.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/20] powerpc: Convert power off logic to pm_power_off
On 07.10.14 19:00, Guenter Roeck wrote: > On Tue, Oct 07, 2014 at 01:35:07PM +0200, Alexander Graf wrote: >> >> >> On 07.10.14 08:25, Michael Ellerman wrote: >>> On Mon, 2014-10-06 at 12:00 +0200, Alexander Graf wrote: On 03.10.14 06:42, Michael Ellerman wrote: > On Wed, 2014-10-01 at 15:27 +0200, Alexander Graf wrote: >> The generic Linux framework to power off the machine is a function >> pointer >> called pm_power_off. The trick about this pointer is that device drivers >> can >> potentially implement it rather than board files. >> >> Today on PowerPC we set pm_power_off to invoke our generic full machine >> power >> off logic which then calls ppc_md.power_off to invoke machine specific >> power >> off. >> >> To fix this up, let's get rid of the ppc_md.power_off logic and just >> always use >> pm_power_off as was intended. Then individual drivers such as the GPIO >> power off >> driver can implement power off logic via that function pointer. > > This looks OK to me with one caveat. > > In several of the patches you're replacing a static initialisation with a > runtime one, and you're doing the runtime initialisation in > xxx_setup_arch(). > That's reasonably late, so I'd prefer you did it in xxx_probe(). Heh, I had it in xxx_probe() originally and then realized that a) the power off function is basically a driver. Driver initialization happens in xxx_setup_arch() and b) the maple target already does overwrite its power_off callback in xxx_setup_arch and c) on all targets xxx_probe() is very slim and doesn't do much but I'll happily change it back to put the bits in xxx_probe() instead. >>> >>> Thanks. >>> >>> That way you shouldn't be changing behaviour. >>> >>> It may still be the case that some power off routines don't actually work >>> until >>> later, but that's an existing problem. Some power off routines *do* work >>> before >>> setup_arch(), so they will continue to work. >> >> Ok, works for me :). Just wanted to make sure you're aware of the >> reasoning why I didn't do it in probe(). >> >>> Also, how does your series interact with Guenter's that removes >>> pm_power_off ? >>> It seems at the moment they are unaware of each other. >> >> Guenters patches convert users of pm_power_off to his new scheme. We're >> not even at that stage at all yet in the powerpc tree. Converting >> everything to pm_power_off is basically a first step. His patch set >> maintains pm_power_off, so there shouldn't be nasty conflicts. >> > Onlly the first m68k patch, though. The very last patch in the series > remvoes pm_power_off. And there go my patch reading skills ... :). For which window are you targeting this? 3.18 or 3.19? If you're trying to hit 3.18, I can easily wait with my patch set and base it on top of yours. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On 10/07/14 11:59, David Daney wrote: > On 10/07/2014 09:31 AM, Guenter Roeck wrote: >> On Tue, Oct 07, 2014 at 11:21:11AM -0500, Rob Landley wrote: >>> On 10/07/14 00:28, Guenter Roeck wrote: Devicetree bindings are supposed to be operating system independent and should thus not describe how a specific functionality is implemented in Linux. >>> >>> So your argument is that linux/Documentation/devicetree/bindings should >>> not be specific to Linux. Merely hosted in the Linux kernel source >>> repository. >>> >>> Well that's certainly a point of view. >>> >> Not specifically my argument, really, and nothing new either. But, >> yes, I do >> think that devicetree bindings descriptions should not include >> implementation >> details, especially since those may change over time (as is the case >> here). >> > > I fully agree. > > Many device trees come from outside the kernel (i.e. they are supplied > by the system boot environment). Obviously these device trees cannot be > changed at the whim of kernel developers, *and* it is perfectly > reasonable to think that software other than the Linux kernel will run > on this type of system too. > > So yes, it is really true, device trees are not a Linux kernel private > implementation detail, they are really an external ABI that, although > documented in the kernel source tree, cannot be changed in incompatible > ways as time progresses. Ah. Existing thing with backstory among the in-crowd, so I'll assume "git subtree" was previously suggested and you had that discussion already and decided against it. Carry on, Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/20] powerpc: Convert power off logic to pm_power_off
On Tue, Oct 07, 2014 at 01:35:07PM +0200, Alexander Graf wrote: > > > On 07.10.14 08:25, Michael Ellerman wrote: > > On Mon, 2014-10-06 at 12:00 +0200, Alexander Graf wrote: > >> > >> On 03.10.14 06:42, Michael Ellerman wrote: > >>> On Wed, 2014-10-01 at 15:27 +0200, Alexander Graf wrote: > The generic Linux framework to power off the machine is a function > pointer > called pm_power_off. The trick about this pointer is that device drivers > can > potentially implement it rather than board files. > > Today on PowerPC we set pm_power_off to invoke our generic full machine > power > off logic which then calls ppc_md.power_off to invoke machine specific > power > off. > > To fix this up, let's get rid of the ppc_md.power_off logic and just > always use > pm_power_off as was intended. Then individual drivers such as the GPIO > power off > driver can implement power off logic via that function pointer. > >>> > >>> This looks OK to me with one caveat. > >>> > >>> In several of the patches you're replacing a static initialisation with a > >>> runtime one, and you're doing the runtime initialisation in > >>> xxx_setup_arch(). > >>> That's reasonably late, so I'd prefer you did it in xxx_probe(). > >> > >> Heh, I had it in xxx_probe() originally and then realized that > >> > >> a) the power off function is basically a driver. Driver initialization > >> happens in xxx_setup_arch() and > >> > >> b) the maple target already does overwrite its power_off callback in > >> xxx_setup_arch and > >> > >> c) on all targets xxx_probe() is very slim and doesn't do much > >> > >> but I'll happily change it back to put the bits in xxx_probe() instead. > > > > Thanks. > > > > That way you shouldn't be changing behaviour. > > > > It may still be the case that some power off routines don't actually work > > until > > later, but that's an existing problem. Some power off routines *do* work > > before > > setup_arch(), so they will continue to work. > > Ok, works for me :). Just wanted to make sure you're aware of the > reasoning why I didn't do it in probe(). > > > Also, how does your series interact with Guenter's that removes > > pm_power_off ? > > It seems at the moment they are unaware of each other. > > Guenters patches convert users of pm_power_off to his new scheme. We're > not even at that stage at all yet in the powerpc tree. Converting > everything to pm_power_off is basically a first step. His patch set > maintains pm_power_off, so there shouldn't be nasty conflicts. > Onlly the first m68k patch, though. The very last patch in the series remvoes pm_power_off. Guenter > Once we converted from ppc_md tables to actual code, we can just run a > simple coccinelle patch to convert from pm_power_off to his new scheme > later. > > > Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On 10/07/2014 09:31 AM, Guenter Roeck wrote: On Tue, Oct 07, 2014 at 11:21:11AM -0500, Rob Landley wrote: On 10/07/14 00:28, Guenter Roeck wrote: Devicetree bindings are supposed to be operating system independent and should thus not describe how a specific functionality is implemented in Linux. So your argument is that linux/Documentation/devicetree/bindings should not be specific to Linux. Merely hosted in the Linux kernel source repository. Well that's certainly a point of view. Not specifically my argument, really, and nothing new either. But, yes, I do think that devicetree bindings descriptions should not include implementation details, especially since those may change over time (as is the case here). I fully agree. Many device trees come from outside the kernel (i.e. they are supplied by the system boot environment). Obviously these device trees cannot be changed at the whim of kernel developers, *and* it is perfectly reasonable to think that software other than the Linux kernel will run on this type of system too. So yes, it is really true, device trees are not a Linux kernel private implementation detail, they are really an external ABI that, although documented in the kernel source tree, cannot be changed in incompatible ways as time progresses. David Daney ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 05:21:11PM +0100, Rob Landley wrote: > On 10/07/14 00:28, Guenter Roeck wrote: > > Devicetree bindings are supposed to be operating system independent > > and should thus not describe how a specific functionality is implemented > > in Linux. > > So your argument is that linux/Documentation/devicetree/bindings should > not be specific to Linux. Merely hosted in the Linux kernel source > repository. Precisely. If nothing else as a general guideline this keeps us honest, and prevents us from embedding arbitrary implementation details into bidnings that cause pain later when we want to change things at either end. There are already otehr users of these bindings, so we can't really claim they're strictly Linux-specific anyhow. > Well that's certainly a point of view. As far as I am aware, it's the point of view shared by the device tree maintainers, and it's been that way for a while. I don't really follow your concern. For one thing were this followed more strictly this file wouldn't need patching at all to correct for this Linux-internal rework... Thanks, Mark. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 11:21:11AM -0500, Rob Landley wrote: > On 10/07/14 00:28, Guenter Roeck wrote: > > Devicetree bindings are supposed to be operating system independent > > and should thus not describe how a specific functionality is implemented > > in Linux. > > So your argument is that linux/Documentation/devicetree/bindings should > not be specific to Linux. Merely hosted in the Linux kernel source > repository. > > Well that's certainly a point of view. > Not specifically my argument, really, and nothing new either. But, yes, I do think that devicetree bindings descriptions should not include implementation details, especially since those may change over time (as is the case here). Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 29/44] staging: nvec: Register with kernel poweroff handler
On Mon, Oct 06, 2014 at 10:28:31PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Register with default priority value of 128 since we don't know > any better. > > Cc: Julian Andres Klode > Cc: Marc Dietrich > Cc: Greg Kroah-Hartman > Signed-off-by: Guenter Roeck > --- > drivers/staging/nvec/nvec.c | 24 +++- > drivers/staging/nvec/nvec.h | 2 ++ > 2 files changed, 17 insertions(+), 9 deletions(-) Acked-by: Greg Kroah-Hartman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On 10/07/14 00:28, Guenter Roeck wrote: > Devicetree bindings are supposed to be operating system independent > and should thus not describe how a specific functionality is implemented > in Linux. So your argument is that linux/Documentation/devicetree/bindings should not be specific to Linux. Merely hosted in the Linux kernel source repository. Well that's certainly a point of view. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
On Mon, Oct 06, 2014 at 10:28:09PM -0700, Guenter Roeck wrote: > Replace reference to pm_power_off (which is an implementation detail) > and replace it with a more generic description of the driver's functionality. Acked-by: Andrew Lunn Thanks Andrew > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Signed-off-by: Guenter Roeck > --- > Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > index af25e77..1e2260a 100644 > --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > @@ -3,8 +3,8 @@ > QNAP NAS devices have a microcontroller controlling the main power > supply. This microcontroller is connected to UART1 of the Kirkwood and > Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the > -microcontroller to turn the power off. This driver adds a handler to > -pm_power_off which is called to turn the power off. > +microcontroller to turn the power off. This driver installs a handler > +to power off the system. > > Synology NAS devices use a similar scheme, but a different baud rate, > 9600, and a different character, '1'. > -- > 1.9.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings
On Mon, Oct 06, 2014 at 10:28:08PM -0700, Guenter Roeck wrote: > pm_power_off is an implementation detail. Replace it with a more generic > description of the driver's functionality. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Signed-off-by: Guenter Roeck Acked-by: Andrew Lunn Thanks Andrew > --- > Documentation/devicetree/bindings/gpio/gpio-poweroff.txt | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > index d4eab92..c95a1a6 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > @@ -2,12 +2,12 @@ Driver a GPIO line that can be used to turn the power off. > > The driver supports both level triggered and edge triggered power off. > At driver load time, the driver will request the given gpio line and > -install a pm_power_off handler. If the optional properties 'input' is > -not found, the GPIO line will be driven in the inactive > +install a handler to power off the system. If the optional properties > +'input' is not found, the GPIO line will be driven in the inactive > state. Otherwise its configured as an input. > > -When the pm_power_off is called, the gpio is configured as an output, > -and drive active, so triggering a level triggered power off > +When the the poweroff handler is called, the gpio is configured as an > +output, and drive active, so triggering a level triggered power off > condition. This will also cause an inactive->active edge condition, so > triggering positive edge triggered power off. After a delay of 100ms, > the GPIO is set to inactive, thus causing an active->inactive edge, > @@ -24,7 +24,7 @@ Required properties: > > Optional properties: > - input : Initially configure the GPIO line as an input. Only reconfigure > - it to an output when the pm_power_off function is called. If this optional > + it to an output when the poweroff handler is called. If this optional >property is not specified, the GPIO is initialized as an output in its >inactive state. > > -- > 1.9.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 20/44] power/reset: restart-poweroff: Register with kernel poweroff handler
On Mon, Oct 06, 2014 at 10:28:22PM -0700, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of seting pm_power_off
> directly. Register as poweroff handler of last resort since the driver
> does not really power off the system but executes a restart.
I would not say last resort, this is how it is designed to work. There
is no way to turn the power off from with linux, it is designed that
u-boot will put the hardware into minimal power consumption until the
"power" button is pressed.
Other than that,
Acked-by: Andrew Lunn
Thanks
Andrew
>
> Cc: Sebastian Reichel
> Cc: Dmitry Eremin-Solenikov
> Cc: David Woodhouse
> Signed-off-by: Guenter Roeck
> ---
> drivers/power/reset/restart-poweroff.c | 25 -
> 1 file changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/power/reset/restart-poweroff.c
> b/drivers/power/reset/restart-poweroff.c
> index edd707e..5437697 100644
> --- a/drivers/power/reset/restart-poweroff.c
> +++ b/drivers/power/reset/restart-poweroff.c
> @@ -12,35 +12,34 @@
> */
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
> -#include
>
> -static void restart_poweroff_do_poweroff(void)
> +static int restart_poweroff_do_poweroff(struct notifier_block *this,
> + unsigned long unused1, void *unused2)
> {
> reboot_mode = REBOOT_HARD;
> machine_restart(NULL);
> +
> + return NOTIFY_DONE;
> }
>
> +static struct notifier_block restart_poweroff_handler = {
> + .notifier_call = restart_poweroff_do_poweroff,
> +};
> +
> static int restart_poweroff_probe(struct platform_device *pdev)
> {
> - /* If a pm_power_off function has already been added, leave it alone */
> - if (pm_power_off != NULL) {
> - dev_err(&pdev->dev,
> - "pm_power_off function already registered");
> - return -EBUSY;
> - }
> -
> - pm_power_off = &restart_poweroff_do_poweroff;
> - return 0;
> + return register_poweroff_handler(&restart_poweroff_handler);
> }
>
> static int restart_poweroff_remove(struct platform_device *pdev)
> {
> - if (pm_power_off == &restart_poweroff_do_poweroff)
> - pm_power_off = NULL;
> + unregister_poweroff_handler(&restart_poweroff_handler);
>
> return 0;
> }
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 23/44] power/reset: qnap-poweroff: Register with kernel poweroff handler
On Mon, Oct 06, 2014 at 10:28:25PM -0700, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Register with default priority value of 128 to reflect that
> the original code generates an error if another poweroff handler has
> already been registered when the driver is loaded.
>
> Cc: Sebastian Reichel
> Cc: Dmitry Eremin-Solenikov
> Cc: David Woodhouse
> Signed-off-by: Guenter Roeck
Acked-by: Andrew Lunn
Thanks
Andrew
> ---
> drivers/power/reset/qnap-poweroff.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/power/reset/qnap-poweroff.c
> b/drivers/power/reset/qnap-poweroff.c
> index a75db7f..c474980 100644
> --- a/drivers/power/reset/qnap-poweroff.c
> +++ b/drivers/power/reset/qnap-poweroff.c
> @@ -16,7 +16,9 @@
>
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -55,7 +57,8 @@ static void __iomem *base;
> static unsigned long tclk;
> static const struct power_off_cfg *cfg;
>
> -static void qnap_power_off(void)
> +static int qnap_power_off(struct notifier_block *this, unsigned long unused1,
> + void *unused2)
> {
> const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
>
> @@ -72,14 +75,20 @@ static void qnap_power_off(void)
>
> /* send the power-off command to PIC */
> writel(cfg->cmd, UART1_REG(TX));
> +
> + return NOTIFY_DONE;
> }
>
> +static struct notifier_block qnap_poweroff_nb = {
> + .notifier_call = qnap_power_off,
> + .priority = 128,
> +};
> +
> static int qnap_power_off_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct resource *res;
> struct clk *clk;
> - char symname[KSYM_NAME_LEN];
>
> const struct of_device_id *match =
> of_match_node(qnap_power_off_of_match_table, np);
> @@ -106,22 +115,13 @@ static int qnap_power_off_probe(struct platform_device
> *pdev)
>
> tclk = clk_get_rate(clk);
>
> - /* Check that nothing else has already setup a handler */
> - if (pm_power_off) {
> - lookup_symbol_name((ulong)pm_power_off, symname);
> - dev_err(&pdev->dev,
> - "pm_power_off already claimed %p %s",
> - pm_power_off, symname);
> - return -EBUSY;
> - }
> - pm_power_off = qnap_power_off;
> -
> - return 0;
> + return register_poweroff_handler(&qnap_poweroff_nb);
> }
>
> static int qnap_power_off_remove(struct platform_device *pdev)
> {
> - pm_power_off = NULL;
> + unregister_poweroff_handler(&qnap_poweroff_nb);
> +
> return 0;
> }
>
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 21/44] power/reset: gpio-poweroff: Register with kernel poweroff handler
On Mon, Oct 06, 2014 at 10:28:23PM -0700, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Register with a low priority value of 64 to reflect that
> the original code only sets pm_power_off if it was not already set.
>
> Other changes:
>
> Drop note that there can not be an additional instance of this driver.
> The original reason no longer applies, it should be obvious that there
> can only be one instance of the driver if static variables are used to
> reflect its state, and support for multiple instances can now be added
> easily if needed by avoiding static variables.
>
> Do not create an error message if another poweroff handler has already been
> registered. This is perfectly normal and acceptable.
>
> Do not display a warning traceback if the poweroff handler fails to
> power off the system. There may be other poweroff handlers.
I would prefer to keep the warning traceback. We found on some
hardware the GPIO transitions were too fast and it failed to power
off. Seeing the traceback gives an idea where to go look for the
problem.
Other than that,
Acked-by: Andrew Lunn
>
> Cc: Sebastian Reichel
> Cc: Dmitry Eremin-Solenikov
> Cc: David Woodhouse
> Signed-off-by: Guenter Roeck
> ---
> drivers/power/reset/gpio-poweroff.c | 36 ++--
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/power/reset/gpio-poweroff.c
> b/drivers/power/reset/gpio-poweroff.c
> index ce849bc..e95a7a1 100644
> --- a/drivers/power/reset/gpio-poweroff.c
> +++ b/drivers/power/reset/gpio-poweroff.c
> @@ -14,18 +14,18 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> #include
>
> -/*
> - * Hold configuration here, cannot be more than one instance of the driver
> - * since pm_power_off itself is global.
> - */
> static struct gpio_desc *reset_gpio;
>
> -static void gpio_poweroff_do_poweroff(void)
> +static int gpio_poweroff_do_poweroff(struct notifier_block *this,
> + unsigned long unused1, void *unused2)
> +
> {
> BUG_ON(!reset_gpio);
>
> @@ -42,20 +42,18 @@ static void gpio_poweroff_do_poweroff(void)
> /* give it some time */
> mdelay(3000);
>
> - WARN_ON(1);
> + return NOTIFY_DONE;
> }
>
> +static struct notifier_block gpio_poweroff_nb = {
> + .notifier_call = gpio_poweroff_do_poweroff,
> + .priority = 64,
> +};
> +
> static int gpio_poweroff_probe(struct platform_device *pdev)
> {
> bool input = false;
> -
> - /* If a pm_power_off function has already been added, leave it alone */
> - if (pm_power_off != NULL) {
> - dev_err(&pdev->dev,
> - "%s: pm_power_off function already registered",
> -__func__);
> - return -EBUSY;
> - }
> + int err;
>
> reset_gpio = devm_gpiod_get(&pdev->dev, NULL);
> if (IS_ERR(reset_gpio))
> @@ -77,14 +75,16 @@ static int gpio_poweroff_probe(struct platform_device
> *pdev)
> }
> }
>
> - pm_power_off = &gpio_poweroff_do_poweroff;
> - return 0;
> + err = register_poweroff_handler(&gpio_poweroff_nb);
> + if (err)
> + dev_err(&pdev->dev, "Failed to register poweroff handler\n");
> +
> + return err;
> }
>
> static int gpio_poweroff_remove(struct platform_device *pdev)
> {
> - if (pm_power_off == &gpio_poweroff_do_poweroff)
> - pm_power_off = NULL;
> + unregister_poweroff_handler(&gpio_poweroff_nb);
>
> return 0;
> }
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 12:02:19PM +0100, Mark Rutland wrote: > On Tue, Oct 07, 2014 at 06:28:09AM +0100, Guenter Roeck wrote: > > Replace reference to pm_power_off (which is an implementation detail) > > and replace it with a more generic description of the driver's > > functionality. > > > > Cc: Rob Herring > > Cc: Pawel Moll > > Cc: Mark Rutland > > Signed-off-by: Guenter Roeck > > --- > > Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > > b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > > index af25e77..1e2260a 100644 > > --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > > +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > > @@ -3,8 +3,8 @@ > > QNAP NAS devices have a microcontroller controlling the main power > > supply. This microcontroller is connected to UART1 of the Kirkwood and > > Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the > > -microcontroller to turn the power off. This driver adds a handler to > > -pm_power_off which is called to turn the power off. > > +microcontroller to turn the power off. This driver installs a handler > > +to power off the system. > > I'd remove the last sentence -- the driver is also independent of the > HW, and the description of how the power off works at the HW level is > sufficient. > Done. > With that: > > Acked-by: Mark Rutland > Thanks! Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 1/3] powerpc: Fix warning reported by verify_cpu_node_mapping()
On 07.10.2014 [17:28:38 +1100], Michael Ellerman wrote: > On Fri, 2014-10-03 at 16:26 -0700, Nishanth Aravamudan wrote: > > On 03.10.2014 [10:50:20 +1000], Michael Ellerman wrote: > > > On Thu, 2014-10-02 at 14:13 -0700, Nishanth Aravamudan wrote: > > > > Ben & Michael, > > > > > > > > What's the status of these patches? > > > > > > Been in my next for a week :) > > > > > > https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=next > > > > Ah ok, thanks -- I wasn't following your tree, my fault. > > Not really your fault, I hadn't announced my trees existence :) > > > Do we want these to go back to 3.17-stable, as they fix some annoying splats > > during boot (non-fatal afaict, though)? > > Up to you really, I don't know how often/bad they were. I haven't added CC > stable tags to the commits, so if you want them in stable you should send them > explicitly. I think they occur every boot, unconditionally, on pseries. Doesn't prevent boot, just really noisy. I think it'd be good to get them into -stable. Li Zhong, can you push them once they get sent upstream? Thanks, Nish ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mpc85xx: dts: Remove SPI and NAND partition from bsc9131rdb.dtsi
* Run "mtdparts default" on u-boot to create dynamic partitions
* Or use dynamic mtd partition with the help of bootargs in u-boot
Append bootargs with:
"mtdparts=ff80.flash:1m(nand_uboot),512K(nand_dtb),8m(nand_kernel),-(fs);\
spiff707000.0:1m(spi_uboot),4m(spi_kernel),512k(spi_dtb),-(fs)'"
Signed-off-by: Ashish Kumar
---
arch/powerpc/boot/dts/bsc9131rdb.dtsi | 50 -
1 files changed, 0 insertions(+), 50 deletions(-)
diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
index 9e6c013..45efcba 100644
--- a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
+++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
@@ -40,31 +40,6 @@
compatible = "fsl,ifc-nand";
reg = <0x0 0x0 0x4000>;
- partition@0 {
- /* This location must not be altered */
- /* 3MB for u-boot Bootloader Image */
- reg = <0x0 0x0030>;
- label = "NAND U-Boot Image";
- read-only;
- };
-
- partition@30 {
- /* 1MB for DTB Image */
- reg = <0x0030 0x0010>;
- label = "NAND DTB Image";
- };
-
- partition@40 {
- /* 8MB for Linux Kernel Image */
- reg = <0x0040 0x0080>;
- label = "NAND Linux Kernel Image";
- };
-
- partition@c0 {
- /* Rest space for Root file System Image */
- reg = <0x00c0 0x0740>;
- label = "NAND RFS Image";
- };
};
};
@@ -82,31 +57,6 @@
reg = <0>;
spi-max-frequency = <5000>;
- /* 512KB for u-boot Bootloader Image */
- partition@0 {
- reg = <0x0 0x0008>;
- label = "SPI Flash U-Boot Image";
- read-only;
- };
-
- /* 512KB for DTB Image */
- partition@8 {
- reg = <0x0008 0x0008>;
- label = "SPI Flash DTB Image";
- };
-
- /* 4MB for Linux Kernel Image */
- partition@10 {
- reg = <0x0010 0x0040>;
- label = "SPI Flash Kernel Image";
- };
-
- /*11MB for RFS Image */
- partition@50 {
- reg = <0x0050 0x00B0>;
- label = "SPI Flash RFS Image";
- };
-
};
};
--
1.7.6.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/44] kernel: Move pm_power_off to common code
Am 07.10.2014 07:28, schrieb Guenter Roeck: > arch/um/kernel/reboot.c| 2 -- Acked-by: Richard Weinberger Thanks, //richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] net: fs_enet: Add NAPI TX
When using a MPC8xx as a router, 'perf' shows a significant time spent in
fs_enet_interrupt() and fs_enet_start_xmit().
'perf annotate' shows that the time spent in fs_enet_start_xmit is indeed spent
between spin_unlock_irqrestore() and the following instruction, hence in
interrupt handling. This is due to the TX complete interrupt that fires after
each transmitted packet.
This patch modifies the handling of TX complete to use NAPI.
With this patch, my NAT router offers a throughput improved by 21%
Original performance:
[root@localhost tmp]# scp toto pgs:/tmp
toto 100% 256MB 2.8MB/s 01:31
Performance with the patch:
[root@localhost tmp]# scp toto pgs:/tmp
toto 100% 256MB 3.4MB/s 01:16
Signed-off-by: Christophe Leroy
---
.../net/ethernet/freescale/fs_enet/fs_enet-main.c | 47 +-
drivers/net/ethernet/freescale/fs_enet/fs_enet.h | 9 -
drivers/net/ethernet/freescale/fs_enet/mac-fcc.c | 29 +
drivers/net/ethernet/freescale/fs_enet/mac-fec.c | 29 +
drivers/net/ethernet/freescale/fs_enet/mac-scc.c | 29 +
5 files changed, 132 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 71a25b4..c92c3b7 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -215,17 +215,23 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int
budget)
return received;
}
-static void fs_enet_tx(struct net_device *dev)
+static int fs_enet_tx_napi(struct napi_struct *napi, int budget)
{
- struct fs_enet_private *fep = netdev_priv(dev);
+ struct fs_enet_private *fep = container_of(napi, struct fs_enet_private,
+ napi_tx);
+ struct net_device *dev = fep->ndev;
cbd_t __iomem *bdp;
struct sk_buff *skb;
int dirtyidx, do_wake, do_restart;
u16 sc;
+ int has_tx_work = 0;
spin_lock(&fep->tx_lock);
bdp = fep->dirty_tx;
+ /* clear TX status bits for napi*/
+ (*fep->ops->napi_clear_tx_event)(dev);
+
do_wake = do_restart = 0;
while (((sc = CBDR_SC(bdp)) & BD_ENET_TX_READY) == 0) {
dirtyidx = bdp - fep->tx_bd_base;
@@ -278,7 +284,7 @@ static void fs_enet_tx(struct net_device *dev)
/*
* Free the sk buffer associated with this last transmit.
*/
- dev_kfree_skb_irq(skb);
+ dev_kfree_skb(skb);
fep->tx_skbuff[dirtyidx] = NULL;
/*
@@ -295,6 +301,7 @@ static void fs_enet_tx(struct net_device *dev)
*/
if (!fep->tx_free++)
do_wake = 1;
+ has_tx_work = 1;
}
fep->dirty_tx = bdp;
@@ -302,10 +309,19 @@ static void fs_enet_tx(struct net_device *dev)
if (do_restart)
(*fep->ops->tx_restart)(dev);
+ if (!has_tx_work) {
+ napi_complete(napi);
+ (*fep->ops->napi_enable_tx)(dev);
+ }
+
spin_unlock(&fep->tx_lock);
if (do_wake)
netif_wake_queue(dev);
+
+ if (has_tx_work)
+ return budget;
+ return 0;
}
/*
@@ -350,8 +366,17 @@ fs_enet_interrupt(int irq, void *dev_id)
__napi_schedule(&fep->napi);
}
- if (int_events & fep->ev_tx)
- fs_enet_tx(dev);
+ if (int_events & fep->ev_tx) {
+ napi_ok = napi_schedule_prep(&fep->napi_tx);
+
+ (*fep->ops->napi_disable_tx)(dev);
+ (*fep->ops->clear_int_events)(dev, fep->ev_napi_tx);
+
+ /* NOTE: it is possible for FCCs in NAPI mode*/
+ /* to submit a spurious interrupt while in poll */
+ if (napi_ok)
+ __napi_schedule(&fep->napi_tx);
+ }
}
handled = nr > 0;
@@ -484,7 +509,6 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
cbd_t __iomem *bdp;
int curidx;
u16 sc;
- unsigned long flags;
#ifdef CONFIG_FS_ENET_MPC5121_FEC
if (((unsigned long)skb->data) & 0x3) {
@@ -499,7 +523,7 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
}
}
#endif
- spin_lock_irqsave(&fep->tx_lock, flags);
+ spin_lock(&fep->tx_lock);
/*
* Fill in a Tx ring entry
@@ -508,7 +532,7 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
if (!fep->tx_free || (CBDR_SC(bdp) & BD_ENET_TX_READY)) {
netif_stop_queue(dev);
-
[PATCH 1/2] net: fs_enet: Remove non NAPI RX
In the probe function, use_napi is inconditionnaly set to 1. This patch removes
all the code which is conditional to !use_napi, and removes use_napi which has
then become useless.
Signed-off-by: Christophe Leroy
---
.../net/ethernet/freescale/fs_enet/fs_enet-main.c | 164 ++---
include/linux/fs_enet_pd.h | 1 -
2 files changed, 15 insertions(+), 150 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 748fd24..71a25b4 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -215,128 +215,6 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int
budget)
return received;
}
-/* non NAPI receive function */
-static int fs_enet_rx_non_napi(struct net_device *dev)
-{
- struct fs_enet_private *fep = netdev_priv(dev);
- const struct fs_platform_info *fpi = fep->fpi;
- cbd_t __iomem *bdp;
- struct sk_buff *skb, *skbn, *skbt;
- int received = 0;
- u16 pkt_len, sc;
- int curidx;
- /*
-* First, grab all of the stats for the incoming packet.
-* These get messed up if we get called due to a busy condition.
-*/
- bdp = fep->cur_rx;
-
- while (((sc = CBDR_SC(bdp)) & BD_ENET_RX_EMPTY) == 0) {
-
- curidx = bdp - fep->rx_bd_base;
-
- /*
-* Since we have allocated space to hold a complete frame,
-* the last indicator should be set.
-*/
- if ((sc & BD_ENET_RX_LAST) == 0)
- dev_warn(fep->dev, "rcv is not +last\n");
-
- /*
-* Check for errors.
-*/
- if (sc & (BD_ENET_RX_LG | BD_ENET_RX_SH | BD_ENET_RX_CL |
- BD_ENET_RX_NO | BD_ENET_RX_CR | BD_ENET_RX_OV)) {
- fep->stats.rx_errors++;
- /* Frame too long or too short. */
- if (sc & (BD_ENET_RX_LG | BD_ENET_RX_SH))
- fep->stats.rx_length_errors++;
- /* Frame alignment */
- if (sc & (BD_ENET_RX_NO | BD_ENET_RX_CL))
- fep->stats.rx_frame_errors++;
- /* CRC Error */
- if (sc & BD_ENET_RX_CR)
- fep->stats.rx_crc_errors++;
- /* FIFO overrun */
- if (sc & BD_ENET_RX_OV)
- fep->stats.rx_crc_errors++;
-
- skb = fep->rx_skbuff[curidx];
-
- dma_unmap_single(fep->dev, CBDR_BUFADDR(bdp),
- L1_CACHE_ALIGN(PKT_MAXBUF_SIZE),
- DMA_FROM_DEVICE);
-
- skbn = skb;
-
- } else {
-
- skb = fep->rx_skbuff[curidx];
-
- dma_unmap_single(fep->dev, CBDR_BUFADDR(bdp),
- L1_CACHE_ALIGN(PKT_MAXBUF_SIZE),
- DMA_FROM_DEVICE);
-
- /*
-* Process the incoming frame.
-*/
- fep->stats.rx_packets++;
- pkt_len = CBDR_DATLEN(bdp) - 4; /* remove CRC */
- fep->stats.rx_bytes += pkt_len + 4;
-
- if (pkt_len <= fpi->rx_copybreak) {
- /* +2 to make IP header L1 cache aligned */
- skbn = netdev_alloc_skb(dev, pkt_len + 2);
- if (skbn != NULL) {
- skb_reserve(skbn, 2); /* align IP
header */
- skb_copy_from_linear_data(skb,
- skbn->data, pkt_len);
- /* swap */
- skbt = skb;
- skb = skbn;
- skbn = skbt;
- }
- } else {
- skbn = netdev_alloc_skb(dev, ENET_RX_FRSIZE);
-
- if (skbn)
- skb_align(skbn, ENET_RX_ALIGN);
- }
-
- if (skbn != NULL) {
- skb_put(skb, pkt_len); /* Make room */
- skb->protocol = eth_type_trans(skb, dev);
- received++;
- netif_rx(skb);
- } else {
- fep->stats.rx_dropped++;
- skbn = skb;
- }
- }
-
- fep->r
[PATCH 0/2] net: fs_enet: Remove non NAPI RX and add NAPI for TX
When using a MPC8xx as a router, 'perf' shows a significant time spent in fs_enet_interrupt() and fs_enet_start_xmit(). 'perf annotate' shows that the time spent in fs_enet_start_xmit is indeed spent between spin_unlock_irqrestore() and the following instruction, hence in interrupt handling. This is due to the TX complete interrupt that fires after each transmitted packet. This patchset first remove all non NAPI handling as NAPI has become the only mode for RX, then adds NAPI for handling TX complete. This improves NAT TCP throughput by 21% on MPC885 with FEC. Tested on MPC885 with FEC. [PATCH 1/2] net: fs_enet: Remove non NAPI RX [PATCH 2/2] net: fs_enet: Add NAPI TX Signed-off-by: Christophe Leroy --- .../net/ethernet/freescale/fs_enet/fs_enet-main.c | 211 ++--- .../net/ethernet/freescale/fs_enet/fs_enet.h | 9 +- .../net/ethernet/freescale/fs_enet/mac-fcc.c | 29 +++ .../net/ethernet/freescale/fs_enet/mac-fec.c | 29 +++ .../net/ethernet/freescale/fs_enet/mac-scc.c | 29 +++ linux/include/linux/fs_enet_pd.h | 1 - 6 files changed, 147 insertions(+), 161 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 0/3] Add new PowerPC specific ELF core notes
On 07/24/2014 12:22 PM, Sam Bobroff wrote:
>> Outstanding Issues
>> ==
>> (1) Running DSCR register value inside a transaction does not seem to be
>> saved
>> at thread.dscr when the process stops for ptrace examination.
>
> Since this is fixed by 96d016108640bc2b7fb0ee800737f80923847294, which
> is already upstream, you might want to rebase and re-test. It should
> pass and then you can remove the outstanding issues :-)
Sure will do that.
>
>>
>> Test programs
>
> program
>
> When I posted the patch I mentioned above, I was asked to move the test
> code into the powerpc kernel selftests so you may want to do this too.
Yes, I will add these ptrace related tests as tm/tm-ptrace.c test case.
>
> Also, your test program covers everything mine did and more so you might
> want to remove mine if you do add this to the selftests.
The new one will be more ptrace specific, so wont remove yours which tests
the context saved DSCR value.
>
>> =
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>
> You should include sys/wait.h for waitpid().
Will do.
> status, i and flags are all unused.
Will remove them.
>> else
>> printf("DSCR FAILED\n");
>>
>> /* TM checkpointed GPR */
>> iov.iov_base = (struct pt_regs *) malloc(sizeof(struct
>> pt_regs));;
>> iov.iov_len = sizeof(struct pt_regs);
>> ret = ptrace(PTRACE_GETREGSET, child, NT_PPC_TM_CGPR,
>> &iov);
>> if (ret == -1) {
>> printf("PTRACE_GETREGSET: NT_PPC_TM_CGPR
>> failed: %s\n", strerror(errno));
>> exit(-1);
>> }
>>
>> if (iov.iov_len != sizeof(struct pt_regs)) {
>> printf("NT_PPC_TM_CGPR: Length returned is
>> wrong\n");
>> exit(-1);
>> }
>>
>> pregs1 = iov.iov_base;
>> printf("---TM checkpointed GPR-\n");
>> printf("TM CH GPR[1]: %x\n", pregs1->gpr[1]);
>> printf("TM CH GPR[2]: %x\n", pregs1->gpr[2]);
>> printf("TM CH NIP: %x\n", pregs1->nip);
>> printf("TM CH LINK: %x\n", pregs1->link);
>> printf("TM CH CCR: %x\n", pregs1->ccr);
>
> I get a compiler warning for these printfs: they should be "%lx".
Okay.
>
>>
>> if (pregs1->gpr[1] == VAL1)
>> printf("GPR[1] PASSED\n");
>> else
>> printf("GPR[1] FAILED\n");
>>
>> if (pregs1->gpr[2] == VAL2)
>> printf("GPR[2] PASSED\n");
>> else
>> printf("GPR[2] FAILED\n");
>>
>> /* TM running GPR */
>> ret = ptrace(PTRACE_GETREGS, child, NULL, pregs2);
>> if (ret == -1) {
>> printf("PTRACE_GETREGS fail: %s\n",
>> strerror(errno));
>> exit(-1);
>> }
>>
>> printf("---TM running GPR-\n");
>> printf("TM RN GPR[1]: %x\n", pregs2->gpr[1]);
>> printf("TM RN GPR[2]: %x\n", pregs2->gpr[2]);
>> printf("TM RN NIP: %x\n", pregs2->nip);
>> printf("TM RN LINK: %x\n", pregs2->link);
>> printf("TM RN CCR: %x\n", pregs2->ccr);
>
> Same as above, I get warnings and they should be "%lx".
Okay. Will fix them.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix sys_call_table declaration
On Fri, 2014-10-03 at 11:00 +0100, Romeo Cane wrote:
> On Fri, Oct 03, 2014 at 07:34:34AM +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2014-10-02 at 15:41 +0100, Romeo Cane wrote:
> > > Declaring sys_call_table as a pointer causes the compiler to generate the
> > > wrong lookup code in arch_syscall_addr
> >
> > Care to elaborate ?
> >
> > > diff --git a/arch/powerpc/include/asm/syscall.h
> > > b/arch/powerpc/include/asm/syscall.h
> > > index b54b2ad..528ba9d 100644
> > > --- a/arch/powerpc/include/asm/syscall.h
> > > +++ b/arch/powerpc/include/asm/syscall.h
> > > @@ -17,7 +17,7 @@
> > >
> > > /* ftrace syscalls requires exporting the sys_call_table */
> > > #ifdef CONFIG_FTRACE_SYSCALLS
> > > -extern const unsigned long *sys_call_table;
> > > +extern const unsigned long sys_call_table[];
> > > #endif /* CONFIG_FTRACE_SYSCALLS */
> > >
> > > static inline long syscall_get_nr(struct task_struct *task,
>
> Hi Ben,
>
> this is the arch_syscall_addr function from kernel/trace/trace_syscalls.c:
>
> unsigned long __init __weak arch_syscall_addr(int nr)
> {
> return (unsigned long)sys_call_table[nr];
> }
>
> on my platform (E500MC) the generated assembly code is as follows:
>
> without the patch:
> :
> lis r9,-16384
> rlwinm r3,r3,2,0,29
> lwz r11,30640(r9)
> lwzxr3,r11,r3
> blr
>
> with the patch:
> :
> lis r9,-16384
> rlwinm r3,r3,2,0,29
> addir9,r9,30640
> lwzxr3,r9,r3
> blr
>
>
> the goal of the function is to retrieve the n-th element of the table (i.e.
> the address of a syscall)
> Without the patch, the returned value is in fact the memory content pointed
> by the address of the first syscall plus an offset, that is not what we want.
> The consequence is that ftrace of syscalls doesn't work.
>
> That table has always been declared as a pointer since the support for
> syscalls tracing has been introduced for powerpc years ago, so I'm wondering
> why nobody else had this problem before.
> Other architectures are not affected since in their includes the table is
> already declared as an array.
Yeah looks like you're right.
I've only ever used the raw_syscall tracing, which does work.
Worringly we also use sys_call_table as extern unsigned long * in vdso.c, so I
wonder if that is also broken.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/20] powerpc: Convert power off logic to pm_power_off
On 07.10.14 08:25, Michael Ellerman wrote: > On Mon, 2014-10-06 at 12:00 +0200, Alexander Graf wrote: >> >> On 03.10.14 06:42, Michael Ellerman wrote: >>> On Wed, 2014-10-01 at 15:27 +0200, Alexander Graf wrote: The generic Linux framework to power off the machine is a function pointer called pm_power_off. The trick about this pointer is that device drivers can potentially implement it rather than board files. Today on PowerPC we set pm_power_off to invoke our generic full machine power off logic which then calls ppc_md.power_off to invoke machine specific power off. To fix this up, let's get rid of the ppc_md.power_off logic and just always use pm_power_off as was intended. Then individual drivers such as the GPIO power off driver can implement power off logic via that function pointer. >>> >>> This looks OK to me with one caveat. >>> >>> In several of the patches you're replacing a static initialisation with a >>> runtime one, and you're doing the runtime initialisation in >>> xxx_setup_arch(). >>> That's reasonably late, so I'd prefer you did it in xxx_probe(). >> >> Heh, I had it in xxx_probe() originally and then realized that >> >> a) the power off function is basically a driver. Driver initialization >> happens in xxx_setup_arch() and >> >> b) the maple target already does overwrite its power_off callback in >> xxx_setup_arch and >> >> c) on all targets xxx_probe() is very slim and doesn't do much >> >> but I'll happily change it back to put the bits in xxx_probe() instead. > > Thanks. > > That way you shouldn't be changing behaviour. > > It may still be the case that some power off routines don't actually work > until > later, but that's an existing problem. Some power off routines *do* work > before > setup_arch(), so they will continue to work. Ok, works for me :). Just wanted to make sure you're aware of the reasoning why I didn't do it in probe(). > Also, how does your series interact with Guenter's that removes pm_power_off ? > It seems at the moment they are unaware of each other. Guenters patches convert users of pm_power_off to his new scheme. We're not even at that stage at all yet in the powerpc tree. Converting everything to pm_power_off is basically a first step. His patch set maintains pm_power_off, so there shouldn't be nasty conflicts. Once we converted from ppc_md tables to actual code, we can just run a simple coccinelle patch to convert from pm_power_off to his new scheme later. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 01/16] powerpc/cell: Move spu_handle_mm_fault() out of cell platform
> > +int copro_data_segment(struct mm_struct *mm, u64 ea, u64 *esid, u64 *vsid); > > This function is otherwise not included in this patch, so it should > probably be removed (as the next patch removes it anyway). Yeah, looks like I screwed it up slightly in the packing of these patches. Thanks. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 01/16] powerpc/cell: Move spu_handle_mm_fault() out of cell platform
Hi Mikey, On Tue, 7 Oct 2014 21:48:07 +1100 Michael Neuling wrote: > > diff --git a/arch/powerpc/include/asm/copro.h > b/arch/powerpc/include/asm/copro.h > new file mode 100644 > index 000..2858108 > --- /dev/null > +++ b/arch/powerpc/include/asm/copro.h > @@ -0,0 +1,18 @@ > +/* > + * Copyright 2014 IBM Corp. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version > + * 2 of the License, or (at your option) any later version. > + */ > + > +#ifndef _ASM_POWERPC_COPRO_H > +#define _ASM_POWERPC_COPRO_H > + > +int copro_handle_mm_fault(struct mm_struct *mm, unsigned long ea, > + unsigned long dsisr, unsigned *flt); > + > +int copro_data_segment(struct mm_struct *mm, u64 ea, u64 *esid, u64 *vsid); This function is otherwise not included in this patch, so it should probably be removed (as the next patch removes it anyway). -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 06:28:08AM +0100, Guenter Roeck wrote: > pm_power_off is an implementation detail. Replace it with a more generic > description of the driver's functionality. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland Acked-by: Mark Rutland > Signed-off-by: Guenter Roeck > --- > Documentation/devicetree/bindings/gpio/gpio-poweroff.txt | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > index d4eab92..c95a1a6 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > @@ -2,12 +2,12 @@ Driver a GPIO line that can be used to turn the power off. > > The driver supports both level triggered and edge triggered power off. > At driver load time, the driver will request the given gpio line and > -install a pm_power_off handler. If the optional properties 'input' is > -not found, the GPIO line will be driven in the inactive > +install a handler to power off the system. If the optional properties > +'input' is not found, the GPIO line will be driven in the inactive > state. Otherwise its configured as an input. > > -When the pm_power_off is called, the gpio is configured as an output, > -and drive active, so triggering a level triggered power off > +When the the poweroff handler is called, the gpio is configured as an > +output, and drive active, so triggering a level triggered power off > condition. This will also cause an inactive->active edge condition, so > triggering positive edge triggered power off. After a delay of 100ms, > the GPIO is set to inactive, thus causing an active->inactive edge, > @@ -24,7 +24,7 @@ Required properties: > > Optional properties: > - input : Initially configure the GPIO line as an input. Only reconfigure > - it to an output when the pm_power_off function is called. If this optional > + it to an output when the poweroff handler is called. If this optional >property is not specified, the GPIO is initialized as an output in its >inactive state. > > -- > 1.9.1 > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 06:28:09AM +0100, Guenter Roeck wrote: > Replace reference to pm_power_off (which is an implementation detail) > and replace it with a more generic description of the driver's functionality. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Signed-off-by: Guenter Roeck > --- > Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > index af25e77..1e2260a 100644 > --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > @@ -3,8 +3,8 @@ > QNAP NAS devices have a microcontroller controlling the main power > supply. This microcontroller is connected to UART1 of the Kirkwood and > Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the > -microcontroller to turn the power off. This driver adds a handler to > -pm_power_off which is called to turn the power off. > +microcontroller to turn the power off. This driver installs a handler > +to power off the system. I'd remove the last sentence -- the driver is also independent of the HW, and the description of how the power off works at the HW level is sufficient. With that: Acked-by: Mark Rutland Thanks, Mark. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 06:28:07AM +0100, Guenter Roeck wrote: > Devicetree bindings are supposed to be operating system independent > and should thus not describe how a specific functionality is implemented > in Linux. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Signed-off-by: Guenter Roeck > --- > Documentation/devicetree/bindings/mfd/as3722.txt | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Thanks for the fix-up! Acked-by: Mark Rutland Mark. > > diff --git a/Documentation/devicetree/bindings/mfd/as3722.txt > b/Documentation/devicetree/bindings/mfd/as3722.txt > index 4f64b2a..0b2a609 100644 > --- a/Documentation/devicetree/bindings/mfd/as3722.txt > +++ b/Documentation/devicetree/bindings/mfd/as3722.txt > @@ -122,8 +122,7 @@ Following are properties of regulator subnode. > > Power-off: > = > -AS3722 supports the system power off by turning off all its rail. This > -is provided through pm_power_off. > +AS3722 supports the system power off by turning off all its rails. > The device node should have the following properties to enable this > functionality > ams,system-power-controller: Boolean, to enable the power off functionality > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 16/16] cxl: Add documentation for userspace APIs
From: Ian Munsie This documentation gives an overview of the hardware architecture, userspace APIs via /dev/cxl/afu0.0 and the syfs files. It also adds a MAINTAINERS file entry for cxl. Signed-off-by: Ian Munsie Signed-off-by: Michael Neuling --- Documentation/ABI/testing/sysfs-class-cxl | 142 Documentation/ioctl/ioctl-number.txt | 1 + Documentation/powerpc/00-INDEX| 2 + Documentation/powerpc/cxl.txt | 346 ++ MAINTAINERS | 7 + 5 files changed, 498 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-cxl create mode 100644 Documentation/powerpc/cxl.txt diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl new file mode 100644 index 000..ca429fc --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-cxl @@ -0,0 +1,142 @@ +Slave contexts (eg. /sys/class/cxl/afu0.0): + +What: /sys/class/cxl//irqs_max +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + Maximum number of interrupts that can be requested by userspace. + The default on probe is the maximum that hardware can support + (eg. 2037). Write values will limit userspace applications to + that many userspace interrupts. Must be >= irqs_min. + +What: /sys/class/cxl//irqs_min +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + The minimum number of interrupts that userspace must request + on a CXL_START_WORK ioctl. Userspace may omit the + num_interrupts field in the START_WORK IOCTL to get this + minimum automatically. + +What: /sys/class/cxl//mmio_size +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + Size of the MMIO space that may be mmaped by userspace. + + +What: /sys/class/cxl//models_supported +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + List of the models this AFU supports. + Valid entries are: "dedicated_process" and "afu_directed" + +What: /sys/class/cxl//model +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read/write + The current model the AFU is using. Will be one of the models + given in models_supported. Writing will change the model + provided that no user contexts are attached. + + +What: /sys/class/cxl//prefault_mode +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read/write + Set the mode for prefaulting in segments into the segment table + when performing the START_WORK ioctl. Possible values: + none: No prefaulting (default) + wed: Treat the wed as an effective address and prefault it + all: all segments this process currently maps + +What: /sys/class/cxl//reset +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: write only + Reset the AFU. + +What: /sys/class/cxl//api_version +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + List the current version of the kernel/user API. + +What: /sys/class/cxl//api_version_com +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + List the lowest version the kernel/user API this + kernel is compatible with. + + + +Master contexts (eg. /sys/class/cxl/afu0.0m) + +What: /sys/class/cxl/m/mmio_size +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + Size of the MMIO space that may be mmaped by userspace. This + includes all slave contexts space also. + +What: /sys/class/cxl/m/pp_mmio_len +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + Per Process MMIO space length. + +What: /sys/class/cxl/m/pp_mmio_off +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + Per Process MMIO space offset. + + +Card info (eg. /sys/class/cxl/card0) + +What: /sys/class/cxl//caia_version +Date: September 2014 +Contact: Ian Munsie , + Michael Neuling +Description: read only + Identifies the
[PATCH v3 15/16] cxl: Add driver to Kbuild and Makefiles
From: Ian Munsie Signed-off-by: Ian Munsie Signed-off-by: Michael Neuling --- drivers/misc/cxl/Kconfig | 10 ++ drivers/misc/cxl/Makefile | 2 ++ 2 files changed, 12 insertions(+) diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig index 5cdd319..585d6e3 100644 --- a/drivers/misc/cxl/Kconfig +++ b/drivers/misc/cxl/Kconfig @@ -6,3 +6,13 @@ config CXL_BASE bool default n select PPC_COPRO_BASE + +config CXL + tristate "Support for IBM Coherent Accelerators (CXL)" + depends on PPC_POWERNV && PCI_MSI + select CXL_BASE + default m + help + Select this option to enable userspace driver support for IBM + Coherent Accelerators (CXL). CXL is otherwise known as Coherent + Accelerator Processor Interface (CAPI). diff --git a/drivers/misc/cxl/Makefile b/drivers/misc/cxl/Makefile index e30ad0a..165e98f 100644 --- a/drivers/misc/cxl/Makefile +++ b/drivers/misc/cxl/Makefile @@ -1 +1,3 @@ +cxl-y += main.o file.o irq.o fault.o native.o context.o sysfs.o debugfs.o pci.o +obj-$(CONFIG_CXL) += cxl.o obj-$(CONFIG_CXL_BASE) += base.o -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 14/16] cxl: Userspace header file.
From: Ian Munsie
This defines structs and magic numbers required for userspace to interact with
the kernel cxl driver via /dev/cxl/afu0.0.
It adds this header file Kbuild so it's exported when doing make
headers_installs.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
include/uapi/Kbuild | 1 +
include/uapi/misc/Kbuild | 2 ++
include/uapi/misc/cxl.h | 86
3 files changed, 89 insertions(+)
create mode 100644 include/uapi/misc/Kbuild
create mode 100644 include/uapi/misc/cxl.h
diff --git a/include/uapi/Kbuild b/include/uapi/Kbuild
index 81d2106..245aa6e 100644
--- a/include/uapi/Kbuild
+++ b/include/uapi/Kbuild
@@ -12,3 +12,4 @@ header-y += video/
header-y += drm/
header-y += xen/
header-y += scsi/
+header-y += misc/
diff --git a/include/uapi/misc/Kbuild b/include/uapi/misc/Kbuild
new file mode 100644
index 000..e96cae7
--- /dev/null
+++ b/include/uapi/misc/Kbuild
@@ -0,0 +1,2 @@
+# misc Header export list
+header-y += cxl.h
diff --git a/include/uapi/misc/cxl.h b/include/uapi/misc/cxl.h
new file mode 100644
index 000..0aaecf3
--- /dev/null
+++ b/include/uapi/misc/cxl.h
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2014 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _UAPI_ASM_CXL_H
+#define _UAPI_ASM_CXL_H
+
+#include
+#include
+
+/* Structs for IOCTLS for userspace to talk to the kernel */
+struct cxl_ioctl_start_work {
+ __u64 flags;
+ __u64 wed;
+ __u64 amr;
+ __s16 num_interrupts;
+ __s16 reserved1;
+ __s32 reserved2;
+ __u64 reserved3;
+ __u64 reserved4;
+ __u64 reserved5;
+ __u64 reserved6;
+};
+#define CXL_START_WORK_AMR 0x0001ULL
+#define CXL_START_WORK_NUM_IRQS0x0002ULL
+#define CXL_START_WORK_ALL (CXL_START_WORK_AMR |\
+CXL_START_WORK_NUM_IRQS)
+
+/* IOCTL numbers */
+#define CXL_MAGIC 0xCA
+#define CXL_IOCTL_START_WORK _IOW(CXL_MAGIC, 0x00, struct
cxl_ioctl_start_work)
+#define CXL_IOCTL_GET_PROCESS_ELEMENT _IOR(CXL_MAGIC, 0x01, int)
+
+/* Events from read() */
+#define CXL_READ_MIN_SIZE 0x1000 /* 4K */
+enum cxl_event_type {
+ CXL_EVENT_RESERVED = 0,
+ CXL_EVENT_AFU_INTERRUPT = 1,
+ CXL_EVENT_DATA_STORAGE = 2,
+ CXL_EVENT_AFU_ERROR = 3,
+};
+
+struct cxl_event_header {
+ __u16 type;
+ __u16 size;
+ __u16 process_element;
+ __u16 reserved1;
+};
+
+struct cxl_event_afu_interrupt {
+ __u16 flags;
+ __u16 irq; /* Raised AFU interrupt number */
+ __u32 reserved1;
+};
+
+struct cxl_event_data_storage {
+ __u16 flags;
+ __u16 reserved1;
+ __u32 reserved2;
+ __u64 addr;
+ __u64 dsisr;
+ __u64 reserved3;
+};
+
+struct cxl_event_afu_error {
+ __u16 flags;
+ __u16 reserved1;
+ __u32 reserved2;
+ __u64 err;
+};
+
+struct cxl_event {
+ struct cxl_event_header header;
+ union {
+ struct cxl_event_afu_interrupt irq;
+ struct cxl_event_data_storage fault;
+ struct cxl_event_afu_error afu_err;
+ };
+};
+
+#endif
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 12/16] cxl: Add base builtin support
From: Ian Munsie
This adds the base cxl support that needs to be build into the kernel to use
cxl as a module. This is needed so that the cxl call backs from the core
powerpc mm code always exist irrespective of if the cxl module is loaded or
not. This is similar to how cell works with CONFIG_SPU_BASE.
This adds a cxl_slbia() call (similar to spu_flush_all_slbs()) which checks for
the cxl module being loaded. If the modules is not loaded we return, otherwise
we call into the cxl SLB invalidation code.
This also adds the cxl_ctx_in_use() function for use in the mm code to see if
any cxl contexts are currently in use. This is used by the tlbie() to
determine if it can do local TLB invalidations or not. This also adds get/put
calls for the cxl driver module to refcount the active cxl contexts.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/cxl/Kconfig | 8 +
drivers/misc/cxl/Makefile | 1 +
drivers/misc/cxl/base.c | 86 +++
5 files changed, 97 insertions(+)
create mode 100644 drivers/misc/cxl/Kconfig
create mode 100644 drivers/misc/cxl/Makefile
create mode 100644 drivers/misc/cxl/base.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b841180..bbeb451 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -527,4 +527,5 @@ source "drivers/misc/vmw_vmci/Kconfig"
source "drivers/misc/mic/Kconfig"
source "drivers/misc/genwqe/Kconfig"
source "drivers/misc/echo/Kconfig"
+source "drivers/misc/cxl/Kconfig"
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5497d02..7d5c4cd 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,3 +55,4 @@ obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
+obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
new file mode 100644
index 000..5cdd319
--- /dev/null
+++ b/drivers/misc/cxl/Kconfig
@@ -0,0 +1,8 @@
+#
+# IBM Coherent Accelerator (CXL) compatible devices
+#
+
+config CXL_BASE
+ bool
+ default n
+ select PPC_COPRO_BASE
diff --git a/drivers/misc/cxl/Makefile b/drivers/misc/cxl/Makefile
new file mode 100644
index 000..e30ad0a
--- /dev/null
+++ b/drivers/misc/cxl/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CXL_BASE) += base.o
diff --git a/drivers/misc/cxl/base.c b/drivers/misc/cxl/base.c
new file mode 100644
index 000..0654ad8
--- /dev/null
+++ b/drivers/misc/cxl/base.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2014 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include "cxl.h"
+
+/* protected by rcu */
+static struct cxl_calls *cxl_calls;
+
+atomic_t cxl_use_count = ATOMIC_INIT(0);
+EXPORT_SYMBOL(cxl_use_count);
+
+#ifdef CONFIG_CXL_MODULE
+
+static inline struct cxl_calls *cxl_calls_get(void)
+{
+ struct cxl_calls *calls = NULL;
+
+ rcu_read_lock();
+ calls = rcu_dereference(cxl_calls);
+ if (calls && !try_module_get(calls->owner))
+ calls = NULL;
+ rcu_read_unlock();
+
+ return calls;
+}
+
+static inline void cxl_calls_put(struct cxl_calls *calls)
+{
+ BUG_ON(calls != cxl_calls);
+
+ /* we don't need to rcu this, as we hold a reference to the module */
+ module_put(cxl_calls->owner);
+}
+
+#else /* !defined CONFIG_CXL_MODULE */
+
+static inline struct cxl_calls *cxl_calls_get(void)
+{
+ return cxl_calls;
+}
+
+static inline void cxl_calls_put(struct cxl_calls *calls) { }
+
+#endif /* CONFIG_CXL_MODULE */
+
+void cxl_slbia(struct mm_struct *mm)
+{
+ struct cxl_calls *calls;
+
+ calls = cxl_calls_get();
+ if (!calls)
+ return;
+
+ if (cxl_ctx_in_use())
+ calls->cxl_slbia(mm);
+
+ cxl_calls_put(calls);
+}
+
+int register_cxl_calls(struct cxl_calls *calls)
+{
+ if (cxl_calls)
+ return -EBUSY;
+
+ rcu_assign_pointer(cxl_calls, calls);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(register_cxl_calls);
+
+void unregister_cxl_calls(struct cxl_calls *calls)
+{
+ BUG_ON(cxl_calls->owner != calls->owner);
+ RCU_INIT_POINTER(cxl_calls, NULL);
+ synchronize_rcu();
+}
+EXPORT_SYMBOL_GPL(unregister_cxl_calls);
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 11/16] powerpc/mm: Add hooks for cxl
From: Ian Munsie
This add a hook into tlbie() so that we use global invalidations when there are
cxl contexts active.
Normally cxl snoops broadcast tlbie. cxl can have TLB entries invalidated via
MMIO, but we aren't doing that yet. So for now we are just disabling local
tlbies when cxl contexts are active. In future we can make tlbie() local mode
smarter so that it invalidates cxl contexts explicitly when it needs to.
This also adds a hooks for when SLBs are invalidated to ensure any
corresponding SLBs in cxl are also invalidated at the same time.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
arch/powerpc/mm/copro_fault.c| 2 ++
arch/powerpc/mm/hash_native_64.c | 6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
index 222ef9b..55791fc 100644
--- a/arch/powerpc/mm/copro_fault.c
+++ b/arch/powerpc/mm/copro_fault.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
/*
* This ought to be kept in sync with the powerpc specific do_page_fault
@@ -143,5 +144,6 @@ void copro_flush_all_slbs(struct mm_struct *mm)
#ifdef CONFIG_SPU_BASE
spu_flush_all_slbs(mm);
#endif
+ cxl_slbia(mm);
}
EXPORT_SYMBOL_GPL(copro_flush_all_slbs);
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index afc0a82..ae4962a 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -29,6 +29,8 @@
#include
#include
+#include
+
#ifdef DEBUG_LOW
#define DBG_LOW(fmt...) udbg_printf(fmt)
#else
@@ -149,9 +151,11 @@ static inline void __tlbiel(unsigned long vpn, int psize,
int apsize, int ssize)
static inline void tlbie(unsigned long vpn, int psize, int apsize,
int ssize, int local)
{
- unsigned int use_local = local && mmu_has_feature(MMU_FTR_TLBIEL);
+ unsigned int use_local;
int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+ use_local = local && mmu_has_feature(MMU_FTR_TLBIEL) &&
!cxl_ctx_in_use();
+
if (use_local)
use_local = mmu_psize_defs[psize].tlbiel;
if (lock_tlbie && !use_local)
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 10/16] powerpc/opal: Add PHB to cxl mode call
From: Ian Munsie
This adds the OPAL call to change a PHB into cxl mode.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/opal.h| 2 ++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
2 files changed, 3 insertions(+)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 86055e5..84c37c4dbc 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -146,6 +146,7 @@ struct opal_sg_list {
#define OPAL_GET_PARAM 89
#define OPAL_SET_PARAM 90
#define OPAL_DUMP_RESEND 91
+#define OPAL_PCI_SET_PHB_CXL_MODE 93
#define OPAL_DUMP_INFO294
#define OPAL_PCI_EEH_FREEZE_SET97
#define OPAL_HANDLE_HMI98
@@ -924,6 +925,7 @@ int64_t opal_sensor_read(uint32_t sensor_hndl, int token,
__be32 *sensor_data);
int64_t opal_handle_hmi(void);
int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
int64_t opal_unregister_dump_region(uint32_t id);
+int64_t opal_pci_set_phb_cxl_mode(uint64_t phb_id, uint64_t mode, uint64_t
pe_number);
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 2e6ce1b..0fb56dc 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -247,3 +247,4 @@ OPAL_CALL(opal_set_param, OPAL_SET_PARAM);
OPAL_CALL(opal_handle_hmi, OPAL_HANDLE_HMI);
OPAL_CALL(opal_register_dump_region, OPAL_REGISTER_DUMP_REGION);
OPAL_CALL(opal_unregister_dump_region, OPAL_UNREGISTER_DUMP_REGION);
+OPAL_CALL(opal_pci_set_phb_cxl_mode, OPAL_PCI_SET_PHB_CXL_MODE);
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 09/16] powerpc/mm: Add new hash_page_mm()
From: Ian Munsie
This adds a new function hash_page_mm() based on the existing hash_page().
This version allows any struct mm to be passed in, rather than assuming
current. This is useful for servicing co-processor faults which are not in the
context of the current running process.
We need to be careful here as the current hash_page() assumes current in a few
places.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/mmu-hash64.h | 1 +
arch/powerpc/mm/hash_utils_64.c | 24 +---
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-hash64.h
b/arch/powerpc/include/asm/mmu-hash64.h
index 6d0b7a2..f84e5a5 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -322,6 +322,7 @@ extern int __hash_page_64K(unsigned long ea, unsigned long
access,
unsigned int local, int ssize);
struct mm_struct;
unsigned int hash_page_do_lazy_icache(unsigned int pp, pte_t pte, int trap);
+extern int hash_page_mm(struct mm_struct *mm, unsigned long ea, unsigned long
access, unsigned long trap);
extern int hash_page(unsigned long ea, unsigned long access, unsigned long
trap);
int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long
vsid,
pte_t *ptep, unsigned long trap, int local, int ssize,
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index bbdb054..698834d 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -904,7 +904,7 @@ void demote_segment_4k(struct mm_struct *mm, unsigned long
addr)
return;
slice_set_range_psize(mm, addr, 1, MMU_PAGE_4K);
copro_flush_all_slbs(mm);
- if (get_paca_psize(addr) != MMU_PAGE_4K) {
+ if ((get_paca_psize(addr) != MMU_PAGE_4K) && (current->mm == mm)) {
get_paca()->context = mm->context;
slb_flush_and_rebolt();
}
@@ -989,12 +989,11 @@ static void check_paca_psize(unsigned long ea, struct
mm_struct *mm,
* -1 - critical hash insertion error
* -2 - access not permitted by subpage protection mechanism
*/
-int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
+int hash_page_mm(struct mm_struct *mm, unsigned long ea, unsigned long access,
unsigned long trap)
{
enum ctx_state prev_state = exception_enter();
pgd_t *pgdir;
unsigned long vsid;
- struct mm_struct *mm;
pte_t *ptep;
unsigned hugeshift;
const struct cpumask *tmp;
@@ -1008,7 +1007,6 @@ int hash_page(unsigned long ea, unsigned long access,
unsigned long trap)
switch (REGION_ID(ea)) {
case USER_REGION_ID:
user_region = 1;
- mm = current->mm;
if (! mm) {
DBG_LOW(" user region with no mm !\n");
rc = 1;
@@ -1019,7 +1017,6 @@ int hash_page(unsigned long ea, unsigned long access,
unsigned long trap)
vsid = get_vsid(mm->context.id, ea, ssize);
break;
case VMALLOC_REGION_ID:
- mm = &init_mm;
vsid = get_kernel_vsid(ea, mmu_kernel_ssize);
if (ea < VMALLOC_END)
psize = mmu_vmalloc_psize;
@@ -1104,7 +1101,8 @@ int hash_page(unsigned long ea, unsigned long access,
unsigned long trap)
WARN_ON(1);
}
#endif
- check_paca_psize(ea, mm, psize, user_region);
+ if (current->mm == mm)
+ check_paca_psize(ea, mm, psize, user_region);
goto bail;
}
@@ -1145,7 +1143,8 @@ int hash_page(unsigned long ea, unsigned long access,
unsigned long trap)
}
}
- check_paca_psize(ea, mm, psize, user_region);
+ if (current->mm == mm)
+ check_paca_psize(ea, mm, psize, user_region);
#endif /* CONFIG_PPC_64K_PAGES */
#ifdef CONFIG_PPC_HAS_HASH_64K
@@ -1180,6 +1179,17 @@ bail:
exception_exit(prev_state);
return rc;
}
+EXPORT_SYMBOL_GPL(hash_page_mm);
+
+int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
+{
+ struct mm_struct *mm = current->mm;
+
+ if (REGION_ID(ea) == VMALLOC_REGION_ID)
+ mm = &init_mm;
+
+ return hash_page_mm(mm, ea, access, trap);
+}
EXPORT_SYMBOL_GPL(hash_page);
void hash_preload(struct mm_struct *mm, unsigned long ea,
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 08/16] powerpc/powerpc: Add new PCIe functions for allocating cxl interrupts
From: Ian Munsie
This adds a number of functions for allocating IRQs under powernv PCIe for cxl.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/pnv-pci.h| 27 ++
arch/powerpc/platforms/powernv/pci-ioda.c | 153 ++
2 files changed, 180 insertions(+)
create mode 100644 arch/powerpc/include/asm/pnv-pci.h
diff --git a/arch/powerpc/include/asm/pnv-pci.h
b/arch/powerpc/include/asm/pnv-pci.h
new file mode 100644
index 000..71717b5
--- /dev/null
+++ b/arch/powerpc/include/asm/pnv-pci.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright 2014 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _ASM_PNV_PCI_H
+#define _ASM_PNV_PCI_H
+
+#include
+#include
+
+int pnv_phb_to_cxl(struct pci_dev *dev);
+int pnv_cxl_ioda_msi_setup(struct pci_dev *dev, unsigned int hwirq,
+ unsigned int virq);
+int pnv_cxl_alloc_hwirqs(struct pci_dev *dev, int num);
+void pnv_cxl_release_hwirqs(struct pci_dev *dev, int hwirq, int num);
+int pnv_cxl_alloc_hwirq_ranges(struct cxl_irq_ranges *irqs,
+ struct pci_dev *dev, int num);
+void pnv_cxl_release_hwirq_ranges(struct cxl_irq_ranges *irqs,
+ struct pci_dev *dev);
+int pnv_cxl_get_irq_count(struct pci_dev *dev);
+
+#endif
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index baf3de6..3b67010b 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -38,6 +38,8 @@
#include
#include
+#include
+
#include "powernv.h"
#include "pci.h"
@@ -1329,6 +1331,157 @@ static void set_msi_irq_chip(struct pnv_phb *phb,
unsigned int virq)
irq_set_chip(virq, &phb->ioda.irq_chip);
}
+#ifdef CONFIG_CXL_BASE
+
+struct device_node *pnv_pci_to_phb_node(struct pci_dev *dev)
+{
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+
+ return hose->dn;
+}
+EXPORT_SYMBOL(pnv_pci_to_phb_node);
+
+int pnv_phb_to_cxl(struct pci_dev *dev)
+{
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+ struct pnv_phb *phb = hose->private_data;
+ struct pnv_ioda_pe *pe;
+ int rc;
+
+ pe = pnv_ioda_get_pe(dev);
+ if (!pe)
+ return -ENODEV;
+
+ pe_info(pe, "Switching PHB to CXL\n");
+
+ rc = opal_pci_set_phb_cxl_mode(phb->opal_id, 1, pe->pe_number);
+ if (rc)
+ dev_err(&dev->dev, "opal_pci_set_phb_cxl_mode failed: %i\n",
rc);
+
+ return rc;
+}
+EXPORT_SYMBOL(pnv_phb_to_cxl);
+
+/* Find PHB for cxl dev and allocate MSI hwirqs?
+ * Returns the absolute hardware IRQ number
+ */
+int pnv_cxl_alloc_hwirqs(struct pci_dev *dev, int num)
+{
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+ struct pnv_phb *phb = hose->private_data;
+ int hwirq = msi_bitmap_alloc_hwirqs(&phb->msi_bmp, num);
+
+ if (hwirq < 0) {
+ dev_warn(&dev->dev, "Failed to find a free MSI\n");
+ return -ENOSPC;
+ }
+
+ return phb->msi_base + hwirq;
+}
+EXPORT_SYMBOL(pnv_cxl_alloc_hwirqs);
+
+void pnv_cxl_release_hwirqs(struct pci_dev *dev, int hwirq, int num)
+{
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+ struct pnv_phb *phb = hose->private_data;
+
+ msi_bitmap_free_hwirqs(&phb->msi_bmp, hwirq - phb->msi_base, num);
+}
+EXPORT_SYMBOL(pnv_cxl_release_hwirqs);
+
+void pnv_cxl_release_hwirq_ranges(struct cxl_irq_ranges *irqs,
+ struct pci_dev *dev)
+{
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+ struct pnv_phb *phb = hose->private_data;
+ int i, hwirq;
+
+ for (i = 1; i < CXL_IRQ_RANGES; i++) {
+ if (!irqs->range[i])
+ continue;
+ pr_devel("cxl release irq range 0x%x: offset: 0x%lx limit:
%ld\n",
+i, irqs->offset[i],
+irqs->range[i]);
+ hwirq = irqs->offset[i] - phb->msi_base;
+ msi_bitmap_free_hwirqs(&phb->msi_bmp, hwirq,
+ irqs->range[i]);
+ }
+}
+EXPORT_SYMBOL(pnv_cxl_release_hwirq_ranges);
+
+int pnv_cxl_alloc_hwirq_ranges(struct cxl_irq_ranges *irqs,
+ struct pci_dev *dev, int num)
+{
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+ struct pnv_phb *phb = hose->private_data;
+ int i, hwirq, try;
+
+ memset(irqs, 0, sizeof(struct cxl_irq_ranges));
+
+ /* 0 is reserved for the multiplexed PSL DSI interrupt */
+ for (i = 1; i < CXL_IRQ_RANGES && num; i++) {
+ try = num;
+ while (try) {
+
[PATCH v3 07/16] cxl: Add new header for call backs and structs
From: Ian Munsie
This new header adds callbacks and structs needed by the rest of the kernel to
hook into the cxl infrastructure.
cxl_ctx_get/put/in_use are static inlined here as they are called in tlbie
which we want to be fast (mpe's suggestion).
Empty functions are provided when CONFIG_CXL_BASE is not enabled.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
include/misc/cxl.h | 48
1 file changed, 48 insertions(+)
create mode 100644 include/misc/cxl.h
diff --git a/include/misc/cxl.h b/include/misc/cxl.h
new file mode 100644
index 000..10cb742
--- /dev/null
+++ b/include/misc/cxl.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright 2014 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _MISC_CXL_H
+#define _MISC_CXL_H
+
+#define CXL_IRQ_RANGES 4
+
+struct cxl_irq_ranges {
+ irq_hw_number_t offset[CXL_IRQ_RANGES];
+ irq_hw_number_t range[CXL_IRQ_RANGES];
+};
+
+#ifdef CONFIG_CXL_BASE
+
+extern atomic_t cxl_use_count;
+
+static inline bool cxl_ctx_in_use(void)
+{
+ return (atomic_read(&cxl_use_count) != 0);
+}
+
+static inline void cxl_ctx_get(void)
+{
+ atomic_inc(&cxl_use_count);
+}
+
+static inline void cxl_ctx_put(void)
+{
+ atomic_dec(&cxl_use_count);
+}
+
+void cxl_slbia(struct mm_struct *mm);
+
+#else /* CONFIG_CXL_BASE */
+
+static inline bool cxl_ctx_in_use(void) { return false; }
+static inline void cxl_slbia(struct mm_struct *mm) {}
+
+#endif /* CONFIG_CXL_BASE */
+
+#endif
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 06/16] powerpc/powernv: Split out set MSI IRQ chip code
From: Ian Munsie
Some of the MSI IRQ code in pnv_pci_ioda_msi_setup() is generically useful so
split it out.
This will be used by some of the cxl PCIe code later.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
arch/powerpc/platforms/powernv/pci-ioda.c | 42 ++-
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index df241b1..baf3de6 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1306,14 +1306,35 @@ static void pnv_ioda2_msi_eoi(struct irq_data *d)
icp_native_eoi(d);
}
+
+static void set_msi_irq_chip(struct pnv_phb *phb, unsigned int virq)
+{
+ struct irq_data *idata;
+ struct irq_chip *ichip;
+
+ if (phb->type != PNV_PHB_IODA2)
+ return;
+
+ if (!phb->ioda.irq_chip_init) {
+ /*
+* First time we setup an MSI IRQ, we need to setup the
+* corresponding IRQ chip to route correctly.
+*/
+ idata = irq_get_irq_data(virq);
+ ichip = irq_data_get_irq_chip(idata);
+ phb->ioda.irq_chip_init = 1;
+ phb->ioda.irq_chip = *ichip;
+ phb->ioda.irq_chip.irq_eoi = pnv_ioda2_msi_eoi;
+ }
+ irq_set_chip(virq, &phb->ioda.irq_chip);
+}
+
static int pnv_pci_ioda_msi_setup(struct pnv_phb *phb, struct pci_dev *dev,
unsigned int hwirq, unsigned int virq,
unsigned int is_64, struct msi_msg *msg)
{
struct pnv_ioda_pe *pe = pnv_ioda_get_pe(dev);
struct pci_dn *pdn = pci_get_pdn(dev);
- struct irq_data *idata;
- struct irq_chip *ichip;
unsigned int xive_num = hwirq - phb->msi_base;
__be32 data;
int rc;
@@ -1365,22 +1386,7 @@ static int pnv_pci_ioda_msi_setup(struct pnv_phb *phb,
struct pci_dev *dev,
}
msg->data = be32_to_cpu(data);
- /*
-* Change the IRQ chip for the MSI interrupts on PHB3.
-* The corresponding IRQ chip should be populated for
-* the first time.
-*/
- if (phb->type == PNV_PHB_IODA2) {
- if (!phb->ioda.irq_chip_init) {
- idata = irq_get_irq_data(virq);
- ichip = irq_data_get_irq_chip(idata);
- phb->ioda.irq_chip_init = 1;
- phb->ioda.irq_chip = *ichip;
- phb->ioda.irq_chip.irq_eoi = pnv_ioda2_msi_eoi;
- }
-
- irq_set_chip(virq, &phb->ioda.irq_chip);
- }
+ set_msi_irq_chip(phb, virq);
pr_devel("%s: %s-bit MSI on hwirq %x (xive #%d),"
" address=%x_%08x data=%x PE# %d\n",
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 05/16] powerpc/mm: Export mmu_kernel_ssize and mmu_linear_psize
From: Ian Munsie Export mmu_kernel_ssize and mmu_linear_psize. These are needed by the cxl driver which has it's own MMU. To setup the MMU cxl need access to these. Signed-off-by: Ian Munsie Signed-off-by: Michael Neuling --- arch/powerpc/mm/hash_utils_64.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index 5c0738d..bbdb054 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -98,6 +98,7 @@ unsigned long htab_size_bytes; unsigned long htab_hash_mask; EXPORT_SYMBOL_GPL(htab_hash_mask); int mmu_linear_psize = MMU_PAGE_4K; +EXPORT_SYMBOL_GPL(mmu_linear_psize); int mmu_virtual_psize = MMU_PAGE_4K; int mmu_vmalloc_psize = MMU_PAGE_4K; #ifdef CONFIG_SPARSEMEM_VMEMMAP @@ -105,6 +106,7 @@ int mmu_vmemmap_psize = MMU_PAGE_4K; #endif int mmu_io_psize = MMU_PAGE_4K; int mmu_kernel_ssize = MMU_SEGSIZE_256M; +EXPORT_SYMBOL_GPL(mmu_kernel_ssize); int mmu_highuser_ssize = MMU_SEGSIZE_256M; u16 mmu_slb_size = 64; EXPORT_SYMBOL_GPL(mmu_slb_size); -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 04/16] powerpc/msi: Improve IRQ bitmap allocator
From: Ian Munsie
Currently msi_bitmap_alloc_hwirqs() will round up any IRQ allocation requests
to the nearest power of 2. eg. ask for 5 IRQs and you'll get 8. This wastes a
lot of IRQs which can be a scarce resource.
For cxl we may require multiple IRQs for every context that is attached to the
accelerator. There may be 1000s of contexts attached, hence we can easily run
out of IRQs, especially if we are needlessly wasting them.
This changes the msi_bitmap_alloc_hwirqs() to allocate only the required number
of IRQs, hence avoiding this wastage. It keeps the natural alignment
requirement though.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
arch/powerpc/sysdev/msi_bitmap.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 2ff6302..56c8b13 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -20,32 +20,37 @@ int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int num)
int offset, order = get_count_order(num);
spin_lock_irqsave(&bmp->lock, flags);
- /*
-* This is fast, but stricter than we need. We might want to add
-* a fallback routine which does a linear search with no alignment.
-*/
- offset = bitmap_find_free_region(bmp->bitmap, bmp->irq_count, order);
+
+ offset = bitmap_find_next_zero_area(bmp->bitmap, bmp->irq_count, 0,
+ num, (1 << order) - 1);
+ if (offset > bmp->irq_count)
+ goto err;
+
+ bitmap_set(bmp->bitmap, offset, num);
spin_unlock_irqrestore(&bmp->lock, flags);
- pr_debug("msi_bitmap: allocated 0x%x (2^%d) at offset 0x%x\n",
-num, order, offset);
+ pr_debug("msi_bitmap: allocated 0x%x at offset 0x%x\n", num, offset);
return offset;
+err:
+ spin_unlock_irqrestore(&bmp->lock, flags);
+ return -ENOMEM;
}
+EXPORT_SYMBOL(msi_bitmap_alloc_hwirqs);
void msi_bitmap_free_hwirqs(struct msi_bitmap *bmp, unsigned int offset,
unsigned int num)
{
unsigned long flags;
- int order = get_count_order(num);
- pr_debug("msi_bitmap: freeing 0x%x (2^%d) at offset 0x%x\n",
-num, order, offset);
+ pr_debug("msi_bitmap: freeing 0x%x at offset 0x%x\n",
+num, offset);
spin_lock_irqsave(&bmp->lock, flags);
- bitmap_release_region(bmp->bitmap, offset, order);
+ bitmap_clear(bmp->bitmap, offset, num);
spin_unlock_irqrestore(&bmp->lock, flags);
}
+EXPORT_SYMBOL(msi_bitmap_free_hwirqs);
void msi_bitmap_reserve_hwirq(struct msi_bitmap *bmp, unsigned int hwirq)
{
@@ -180,6 +185,12 @@ void __init test_basics(void)
msi_bitmap_free_hwirqs(&bmp, size / 2, 1);
check(msi_bitmap_alloc_hwirqs(&bmp, 1) == size / 2);
+ /* Check we get a naturally aligned offset */
+ check(msi_bitmap_alloc_hwirqs(&bmp, 2) % 2 == 0);
+ check(msi_bitmap_alloc_hwirqs(&bmp, 4) % 4 == 0);
+ check(msi_bitmap_alloc_hwirqs(&bmp, 8) % 8 == 0);
+ check(msi_bitmap_alloc_hwirqs(&bmp, 9) % 16 == 0);
+
msi_bitmap_free(&bmp);
/* Clients may check bitmap == NULL for "not-allocated" */
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 03/16] powerpc/cell: Make spu_flush_all_slbs() generic
From: Ian Munsie
This moves spu_flush_all_slbs() into a generic call copro_flush_all_slbs().
This will be useful when we add cxl which also needs a similar SLB flush call.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/copro.h | 6 ++
arch/powerpc/mm/copro_fault.c| 9 +
arch/powerpc/mm/hash_utils_64.c | 10 +++---
arch/powerpc/mm/slice.c | 10 +++---
4 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/copro.h b/arch/powerpc/include/asm/copro.h
index 9badb09..6897431 100644
--- a/arch/powerpc/include/asm/copro.h
+++ b/arch/powerpc/include/asm/copro.h
@@ -20,4 +20,10 @@ int copro_handle_mm_fault(struct mm_struct *mm, unsigned
long ea,
int copro_calc_slb(struct mm_struct *mm, u64 ea, struct copro_slb *slb);
+
+#ifdef CONFIG_PPC_COPRO_BASE
+void copro_flush_all_slbs(struct mm_struct *mm);
+#else
+static inline void copro_flush_all_slbs(struct mm_struct *mm) {}
+#endif
#endif /* _ASM_POWERPC_COPRO_H */
diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
index 367ea01..222ef9b 100644
--- a/arch/powerpc/mm/copro_fault.c
+++ b/arch/powerpc/mm/copro_fault.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/*
* This ought to be kept in sync with the powerpc specific do_page_fault
@@ -136,3 +137,11 @@ int copro_calc_slb(struct mm_struct *mm, u64 ea, struct
copro_slb *slb)
return 0;
}
EXPORT_SYMBOL_GPL(copro_calc_slb);
+
+void copro_flush_all_slbs(struct mm_struct *mm)
+{
+#ifdef CONFIG_SPU_BASE
+ spu_flush_all_slbs(mm);
+#endif
+}
+EXPORT_SYMBOL_GPL(copro_flush_all_slbs);
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index daee7f4..5c0738d 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -51,7 +51,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -901,9 +901,7 @@ void demote_segment_4k(struct mm_struct *mm, unsigned long
addr)
if (get_slice_psize(mm, addr) == MMU_PAGE_4K)
return;
slice_set_range_psize(mm, addr, 1, MMU_PAGE_4K);
-#ifdef CONFIG_SPU_BASE
- spu_flush_all_slbs(mm);
-#endif
+ copro_flush_all_slbs(mm);
if (get_paca_psize(addr) != MMU_PAGE_4K) {
get_paca()->context = mm->context;
slb_flush_and_rebolt();
@@ -1141,9 +1139,7 @@ int hash_page(unsigned long ea, unsigned long access,
unsigned long trap)
"to 4kB pages because of "
"non-cacheable mapping\n");
psize = mmu_vmalloc_psize = MMU_PAGE_4K;
-#ifdef CONFIG_SPU_BASE
- spu_flush_all_slbs(mm);
-#endif
+ copro_flush_all_slbs(mm);
}
}
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index b0c75cc..a81791c 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -32,7 +32,7 @@
#include
#include
#include
-#include
+#include
/* some sanity checks */
#if (PGTABLE_RANGE >> 43) > SLICE_MASK_SIZE
@@ -232,9 +232,7 @@ static void slice_convert(struct mm_struct *mm, struct
slice_mask mask, int psiz
spin_unlock_irqrestore(&slice_convert_lock, flags);
-#ifdef CONFIG_SPU_BASE
- spu_flush_all_slbs(mm);
-#endif
+ copro_flush_all_slbs(mm);
}
/*
@@ -671,9 +669,7 @@ void slice_set_psize(struct mm_struct *mm, unsigned long
address,
spin_unlock_irqrestore(&slice_convert_lock, flags);
-#ifdef CONFIG_SPU_BASE
- spu_flush_all_slbs(mm);
-#endif
+ copro_flush_all_slbs(mm);
}
void slice_set_range_psize(struct mm_struct *mm, unsigned long start,
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 02/16] powerpc/cell: Move data segment faulting code out of cell platform
From: Ian Munsie
__spu_trap_data_seg() currently contains code to determine the VSID and ESID
required for a particular EA and mm struct.
This code is generically useful for other co-processors. This moves the code
of the cell platform so it can be used by other powerpc code. It also adds 1TB
segment handling which Cell didn't have.
This also moves the internal struct spu_slb to a generic struct copro_slb which
is now used in the spu and copro code. We use this new struct instead of the
us passing around esid and vsid parameters.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/copro.h | 7 -
arch/powerpc/include/asm/mmu-hash64.h | 7 -
arch/powerpc/mm/copro_fault.c | 46
arch/powerpc/mm/slb.c | 3 --
arch/powerpc/platforms/cell/spu_base.c | 55 ++
5 files changed, 67 insertions(+), 51 deletions(-)
diff --git a/arch/powerpc/include/asm/copro.h b/arch/powerpc/include/asm/copro.h
index 2858108..9badb09 100644
--- a/arch/powerpc/include/asm/copro.h
+++ b/arch/powerpc/include/asm/copro.h
@@ -10,9 +10,14 @@
#ifndef _ASM_POWERPC_COPRO_H
#define _ASM_POWERPC_COPRO_H
+struct copro_slb
+{
+ u64 esid, vsid;
+};
+
int copro_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
unsigned long dsisr, unsigned *flt);
-int copro_data_segment(struct mm_struct *mm, u64 ea, u64 *esid, u64 *vsid);
+int copro_calc_slb(struct mm_struct *mm, u64 ea, struct copro_slb *slb);
#endif /* _ASM_POWERPC_COPRO_H */
diff --git a/arch/powerpc/include/asm/mmu-hash64.h
b/arch/powerpc/include/asm/mmu-hash64.h
index d765144..6d0b7a2 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -189,7 +189,12 @@ static inline unsigned int mmu_psize_to_shift(unsigned int
mmu_psize)
#define LP_MASK(i) ((0xFF >> (i)) << LP_SHIFT)
#ifndef __ASSEMBLY__
-
+static inline int slb_vsid_shift(int ssize)
+{
+ if (ssize == MMU_SEGSIZE_256M)
+ return SLB_VSID_SHIFT;
+ return SLB_VSID_SHIFT_1T;
+}
static inline int segment_shift(int ssize)
{
if (ssize == MMU_SEGSIZE_256M)
diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
index ba7df14..367ea01 100644
--- a/arch/powerpc/mm/copro_fault.c
+++ b/arch/powerpc/mm/copro_fault.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
/*
* This ought to be kept in sync with the powerpc specific do_page_fault
@@ -90,3 +91,48 @@ out_unlock:
return ret;
}
EXPORT_SYMBOL_GPL(copro_handle_mm_fault);
+
+int copro_calc_slb(struct mm_struct *mm, u64 ea, struct copro_slb *slb)
+{
+ u64 vsid;
+ int psize, ssize;
+
+ slb->esid = (ea & ESID_MASK) | SLB_ESID_V;
+
+ switch (REGION_ID(ea)) {
+ case USER_REGION_ID:
+ pr_devel("%s: 0x%llx -- USER_REGION_ID\n", __func__, ea);
+ psize = get_slice_psize(mm, ea);
+ ssize = user_segment_size(ea);
+ vsid = get_vsid(mm->context.id, ea, ssize);
+ break;
+ case VMALLOC_REGION_ID:
+ pr_devel("%s: 0x%llx -- VMALLOC_REGION_ID\n", __func__, ea);
+ if (ea < VMALLOC_END)
+ psize = mmu_vmalloc_psize;
+ else
+ psize = mmu_io_psize;
+ ssize = mmu_kernel_ssize;
+ vsid = get_kernel_vsid(ea, mmu_kernel_ssize);
+ break;
+ case KERNEL_REGION_ID:
+ pr_devel("%s: 0x%llx -- KERNEL_REGION_ID\n", __func__, ea);
+ psize = mmu_linear_psize;
+ ssize = mmu_kernel_ssize;
+ vsid = get_kernel_vsid(ea, mmu_kernel_ssize);
+ break;
+ default:
+ pr_debug("%s: invalid region access at %016llx\n", __func__,
ea);
+ return 1;
+ }
+
+ vsid = (vsid << slb_vsid_shift(ssize)) | SLB_VSID_USER;
+
+ vsid |= mmu_psize_defs[psize].sllp |
+ ((ssize == MMU_SEGSIZE_1T) ? SLB_VSID_B_1T : 0);
+
+ slb->vsid = vsid;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(copro_calc_slb);
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 0399a67..6e450ca 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -46,9 +46,6 @@ static inline unsigned long mk_esid_data(unsigned long ea,
int ssize,
return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
}
-#define slb_vsid_shift(ssize) \
- ((ssize) == MMU_SEGSIZE_256M? SLB_VSID_SHIFT: SLB_VSID_SHIFT_1T)
-
static inline unsigned long mk_vsid_data(unsigned long ea, int ssize,
unsigned long flags)
{
diff --git a/arch/powerpc/platforms/cell/spu_base.c
b/arch/powerpc/platforms/cell/spu_base.c
index 2930d1e..bdb24de 100644
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -76,10 +76,6 @@ static LI
[PATCH v3 01/16] powerpc/cell: Move spu_handle_mm_fault() out of cell platform
From: Ian Munsie
Currently spu_handle_mm_fault() is in the cell platform.
This code is generically useful for other non-cell co-processors on powerpc.
This patch moves this function out of the cell platform into arch/powerpc/mm so
that others may use it.
Signed-off-by: Ian Munsie
Signed-off-by: Michael Neuling
---
arch/powerpc/Kconfig | 4
arch/powerpc/include/asm/copro.h | 18 ++
arch/powerpc/include/asm/spu.h | 5 ++---
arch/powerpc/mm/Makefile | 1 +
.../{platforms/cell/spu_fault.c => mm/copro_fault.c} | 14 ++
arch/powerpc/platforms/cell/Kconfig| 1 +
arch/powerpc/platforms/cell/Makefile | 2 +-
arch/powerpc/platforms/cell/spufs/fault.c | 4 ++--
8 files changed, 35 insertions(+), 14 deletions(-)
create mode 100644 arch/powerpc/include/asm/copro.h
rename arch/powerpc/{platforms/cell/spu_fault.c => mm/copro_fault.c} (89%)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4bc7b62..8f094e9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -603,6 +603,10 @@ config PPC_SUBPAGE_PROT
to set access permissions (read/write, readonly, or no access)
on the 4k subpages of each 64k page.
+config PPC_COPRO_BASE
+ bool
+ default n
+
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
depends on PPC64 && SMP
diff --git a/arch/powerpc/include/asm/copro.h b/arch/powerpc/include/asm/copro.h
new file mode 100644
index 000..2858108
--- /dev/null
+++ b/arch/powerpc/include/asm/copro.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright 2014 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _ASM_POWERPC_COPRO_H
+#define _ASM_POWERPC_COPRO_H
+
+int copro_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
+ unsigned long dsisr, unsigned *flt);
+
+int copro_data_segment(struct mm_struct *mm, u64 ea, u64 *esid, u64 *vsid);
+
+#endif /* _ASM_POWERPC_COPRO_H */
diff --git a/arch/powerpc/include/asm/spu.h b/arch/powerpc/include/asm/spu.h
index 37b7ca3..a6e6e2b 100644
--- a/arch/powerpc/include/asm/spu.h
+++ b/arch/powerpc/include/asm/spu.h
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#define LS_SIZE (256 * 1024)
#define LS_ADDR_MASK (LS_SIZE - 1)
@@ -277,9 +279,6 @@ void spu_remove_dev_attr(struct device_attribute *attr);
int spu_add_dev_attr_group(struct attribute_group *attrs);
void spu_remove_dev_attr_group(struct attribute_group *attrs);
-int spu_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
- unsigned long dsisr, unsigned *flt);
-
/*
* Notifier blocks:
*
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index d0130ff..325e861 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += hugepage-hash64.o
obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
obj-$(CONFIG_HIGHMEM) += highmem.o
+obj-$(CONFIG_PPC_COPRO_BASE) += copro_fault.o
diff --git a/arch/powerpc/platforms/cell/spu_fault.c
b/arch/powerpc/mm/copro_fault.c
similarity index 89%
rename from arch/powerpc/platforms/cell/spu_fault.c
rename to arch/powerpc/mm/copro_fault.c
index 641e727..ba7df14 100644
--- a/arch/powerpc/platforms/cell/spu_fault.c
+++ b/arch/powerpc/mm/copro_fault.c
@@ -1,5 +1,5 @@
/*
- * SPU mm fault handler
+ * CoProcessor (SPU/AFU) mm fault handler
*
* (C) Copyright IBM Deutschland Entwicklung GmbH 2007
*
@@ -23,16 +23,14 @@
#include
#include
#include
-
-#include
-#include
+#include
/*
* This ought to be kept in sync with the powerpc specific do_page_fault
* function. Currently, there are a few corner cases that we haven't had
* to handle fortunately.
*/
-int spu_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
+int copro_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
unsigned long dsisr, unsigned *flt)
{
struct vm_area_struct *vma;
@@ -58,12 +56,12 @@ int spu_handle_mm_fault(struct mm_struct *mm, unsigned long
ea,
goto out_unlock;
}
- is_write = dsisr & MFC_DSISR_ACCESS_PUT;
+ is_write = dsisr & DSISR_ISSTORE;
if (is_write) {
if (!(vma->vm_flags & VM_WRITE))
goto out_unlock;
} else {
- if (dsisr & MFC_DSISR_ACCESS_DENIED)
+ if (dsisr & DSISR_PROTFAULT)
goto out_unlock;
if (!(vma->vm_flags & (VM_READ | VM_EXEC)))
goto out_unlock;
@@ -91,4 +89,4
[PATCH v3 0/16] POWER8 Coherent Accelerator device driver
This is the latest version of the cxl driver. Change log below: v3: - Updates based on comments from mpe, benh, aneesh and offline reviews. - Fixed bug freeing AFU IRQs that also freed the multiplexed PSL IRQ - Change copro_flush_all_slbs to a static inline as suggested by mpe - Implement sanitisation routines to clear out more registers and do full adapter wide tlbia and slbia when initialising hardware - Add self testcase to msi_bitmap to test allocations are aligned to a power of 2 and cleanup comment as suggested by mpe - Clean up cxl_use_count - Split out detach_process_native into two logical functions - Improve comment in set_msi_irq_chip as requested by mpe - Move cxl functions in pci-ioda.c to be under just one #ifdef CONFIG_CXL_BASE - Cleanup hash_page and hash_page_mm from mpes and Aneesh' reviews - Remove dead code in cxl_alloc_sst - Add timeout in afu_slbia_native - Remove cxl backend and driver ops abstractions - Removed separate cxl-pci module - Merged cxl pci module init calls into main driver init - Refactor afu_read() to be a bit simpler and more closely follow exising patterns in the kernel - Userspace API updates from reviews: - Added ioctl to get the process element number, and removed it as a return from the start work ioctl - Alter cxl_event to have one common header struct - Dropped check error ioctl - Added current and binary compatible API version numbers to sysfs - read() now takes a 4K (or greater) buffer - Pack event structs to reduce unecessary reserved fields - Event sizes can now differ - All event sizes are 64bit multiples to allow future event coalescing - Add flags fields to indicate which fields contain valid data - Add BUILD_BUG_ONs to protect against inadvertantly changing API without bumping version number and/or flags - Update documentation - Skip CXL SLBIA codepath if CXL is not in use - Split cxl_slbia_core into two functions to be easier to read - Refactor copro_data_segment (renamed to copro_calc_slb) since we are no longer merging with hash_page and cleaned up parameters. - Some renames: - struct cxl_t -> struct cxl - struct cxl_afu_t -> struct cxl_afu - struct cxl_context_t -> struct cxl_context - copro_data_segment -> copro_calc_slb - ctx->ph -> ctx->pe - Added ctx->status mutex lock around for start and release context v2: - Updates based on comments from, Anton, Gavin, Aneesh, jk and offline reviews - Simplified copro_data_segment() and merged code with hash_page_mm() (New patch 10/17) - PCIe code simplifications based on Gavin's review - Removed redundant comment in msi_bitmap_alloc_hwirqs() - Fix for locking in idr_remove in core driver - Ensure PSL is enabled when PHB is flipped to CXL mode - Added CONFIG_PPC_COPRO_BASE to compile copro_fault.c - Merged SPU and cxl slb flushing calls into copro_flush_all_slbs() (New patch 03/17) - Moved slb_vsid_shift() to static inline from #define - Don't write paca->context when demoting segments and mm != current - Fix minor typos in documentation v1: - Initial post This add support for the Coherent Accelerator (cxl) attached to POWER8 processors. This coherent accelerator interface is designed to allow the coherent connection of FPGA based accelerators (and other devices) to a POWER systems. IBM refers to this as the Coherent Accelerator Processor Interface or CAPI. In this driver it's referred to by the name cxl to avoid confusion with the ISDN CAPI subsystem. An overview of the patches: Patches 1-3: Split some of the old Cell co-processor code out so it can be reused. Patches 4-10: Add infrastructure to arch/powerpc needed by cxl. Patches 11: Add call backs needed for invalidating cxl mm contexts. Patch12: Add cxl specific support that needs to be built in to the kernel (can't be a module). Patches 13-15: Add the majority of the device driver and API header. Patch16: Documentation. The documentation in this last patch gives an overview of the hardware architecture as well as the userspace API. The cxl driver has a user-space interface described in include/uapi/misc/cxl.h and Documentation/powerpc/cxl.txt. There are two ioctls which can be used to talk to the driver once the new /dev/cxl/afu0.0 device is opened. This device can also be read and mmaped. There's also sysfs entries used to communicate information about the cxl configuration to userspace. These are documented in Documentation/ABI/testing/sysfs-class-cxl. Many contributed to this device driver but Ian Munsie is the principal author. Driver can also be found here (based on 3.17-rc5): git://github.com/mikey/linux.git cxl https://github.com/mikey/linux/commits/cxl (Series rebases on recent linux-next with one trivial include file conflict) Please consider for inclusion. Feedback welcome! Regards, Mikey _
[PATCH] powerpc/book3s: Don't clear MSR_RI in hmi handler.
From: Mahesh Salgaonkar In HMI interrupt handler we don't touch SRR0/SRR1, instead we touch HSRR0/HSRR1. Hence we don't need to clear MSR_RI bit. Signed-off-by: Mahesh Salgaonkar --- arch/powerpc/kernel/exceptions-64s.S |5 - 1 file changed, 5 deletions(-) diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 050f79a..72e783e 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -1270,11 +1270,6 @@ hmi_exception_early: addir3,r1,STACK_FRAME_OVERHEAD bl hmi_exception_realmode /* Windup the stack. */ - /* Clear MSR_RI before setting SRR0 and SRR1. */ - li r0,MSR_RI - mfmsr r9 /* get MSR value */ - andcr9,r9,r0 - mtmsrd r9,1/* Clear MSR_RI */ /* Move original HSRR0 and HSRR1 into the respective regs */ ld r9,_MSR(r1) mtspr SPRN_HSRR1,r9 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/5] powerpc/powernv: Add winkle infrastructure
On Tuesday 07 October 2014 11:03 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2014-10-01 at 13:16 +0530, Shreyas B. Prabhu wrote:
>> Winkle causes power to be gated off to the entire chiplet. Hence the
>> hypervisor/firmware state in the entire chiplet is lost.
>>
>> This patch adds necessary infrastructure to support waking up from
>> hypervisor state loss. Specifically does following:
>> - Before entering winkle, save state of registers that need to be
>> restored on wake up (SDR1, HFSCR)
>
> Add ... to your list, it's not exhaustive, is it ?
I use interrupt stack frame for only SDR1 and HFSCR. The rest of the
SPRs are restored via PORE in the next patch. I'll change the comments
to better reflect this.
>
>> - SRR1 bits 46:47 which is used to identify which power saving mode cpu
>> woke up from is '11' for both winkle and sleep. Hence introduce a flag
>> in PACA to distinguish b/w winkle and sleep.
>>
>> - Upon waking up, restore all saved registers, recover slb
>>
>> Cc: Benjamin Herrenschmidt
>> Cc: Paul Mackerras
>> Cc: Michael Ellerman
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Suggested-by: Vaidyanathan Srinivasan
>> Signed-off-by: Shreyas B. Prabhu
>> ---
>> arch/powerpc/include/asm/machdep.h | 1 +
>> arch/powerpc/include/asm/paca.h| 3 ++
>> arch/powerpc/include/asm/ppc-opcode.h | 2 +
>> arch/powerpc/include/asm/processor.h | 2 +
>> arch/powerpc/kernel/asm-offsets.c | 1 +
>> arch/powerpc/kernel/exceptions-64s.S | 8 ++--
>> arch/powerpc/kernel/idle.c | 11 +
>> arch/powerpc/kernel/idle_power7.S | 81
>> +-
>> arch/powerpc/platforms/powernv/setup.c | 24 ++
>> 9 files changed, 127 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/machdep.h
>> b/arch/powerpc/include/asm/machdep.h
>> index f37014f..0a3ced9 100644
>> --- a/arch/powerpc/include/asm/machdep.h
>> +++ b/arch/powerpc/include/asm/machdep.h
>> @@ -301,6 +301,7 @@ struct machdep_calls {
>> /* Idle handlers */
>> void(*setup_idle)(void);
>> unsigned long (*power7_sleep)(void);
>> +unsigned long (*power7_winkle)(void);
>> };
>
> Why does it need to be ppc_md ? Same comments as for sleep
>
>> extern void e500_idle(void);
>> diff --git a/arch/powerpc/include/asm/paca.h
>> b/arch/powerpc/include/asm/paca.h
>> index a5139ea..3358f09 100644
>> --- a/arch/powerpc/include/asm/paca.h
>> +++ b/arch/powerpc/include/asm/paca.h
>> @@ -158,6 +158,9 @@ struct paca_struct {
>> * early exception handler for use by high level C handler
>> */
>> struct opal_machine_check_event *opal_mc_evt;
>> +
>> +/* Flag to distinguish b/w sleep and winkle */
>> +u8 offline_state;
>
> Not fan of the name. I'd rather you call it "wakeup_state_loss" or
> something a bit more explicit about what that actually means if it's
> going to be a boolean value. Otherwise make it an enumeration of
> constants.
>
Okay. I'll change this.
>> #endif
>> #ifdef CONFIG_PPC_BOOK3S_64
>> /* Exclusive emergency stack pointer for machine check exception. */
>> diff --git a/arch/powerpc/include/asm/ppc-opcode.h
>> b/arch/powerpc/include/asm/ppc-opcode.h
>> index 6f85362..5155be7 100644
>> --- a/arch/powerpc/include/asm/ppc-opcode.h
>> +++ b/arch/powerpc/include/asm/ppc-opcode.h
>> @@ -194,6 +194,7 @@
>>
>> #define PPC_INST_NAP0x4c000364
>> #define PPC_INST_SLEEP 0x4c0003a4
>> +#define PPC_INST_WINKLE 0x4c0003e4
>>
>> /* A2 specific instructions */
>> #define PPC_INST_ERATWE 0x7c0001a6
>> @@ -374,6 +375,7 @@
>>
>> #define PPC_NAP stringify_in_c(.long PPC_INST_NAP)
>> #define PPC_SLEEP stringify_in_c(.long PPC_INST_SLEEP)
>> +#define PPC_WINKLE stringify_in_c(.long PPC_INST_WINKLE)
>>
>> /* BHRB instructions */
>> #define PPC_CLRBHRB stringify_in_c(.long PPC_INST_CLRBHRB)
>> diff --git a/arch/powerpc/include/asm/processor.h
>> b/arch/powerpc/include/asm/processor.h
>> index 41953cd..00e3df9 100644
>> --- a/arch/powerpc/include/asm/processor.h
>> +++ b/arch/powerpc/include/asm/processor.h
>> @@ -455,6 +455,8 @@ extern void arch_setup_idle(void);
>> extern void power7_nap(int check_irq);
>> extern unsigned long power7_sleep(void);
>> extern unsigned long __power7_sleep(void);
>> +extern unsigned long power7_winkle(void);
>> +extern unsigned long __power7_winkle(void);
>> extern void flush_instruction_cache(void);
>> extern void hard_reset_now(void);
>> extern void poweroff_now(void);
>> diff --git a/arch/powerpc/kernel/asm-offsets.c
>> b/arch/powerpc/kernel/asm-offsets.c
>> index 9d7dede..ea98817 100644
>> --- a/arch/powerpc/kernel/asm-offsets.c
>> +++ b/arch/powerpc/kernel/asm-offsets.c
>> @@ -731,6 +731,7 @@ int main(void)
>> DEFINE(OPAL_MC_SRR0, offsetof(struct opal_machine_check_event, srr0));
>> DEFINE(OPAL_MC_SRR1, offsetof(stru
Re: [v2] powerpc/vphn: fix endian issue in NUMA device node code
On Fri, 2014-03-10 at 09:13:17 UTC, Greg Kurz wrote: > The associativity domain numbers are obtained from the hypervisor through > registers and written into memory by the guest: the packed array passed to > vphn_unpack_associativity() is then native-endian, unlike what was assumed > in the following commit: > > This patch does two things: > - extract values from the packed array with shifts, in order to be endian > neutral > - convert the resulting values to be32 as expected > > Suggested-by: Anton Blanchard > Signed-off-by: Greg Kurz > Reviewed-by: Nishanth Aravamudan > Tested-by: Nishanth Aravamudan Hi Greg, I'm a bit dense, it's after 8pm, but this seems like it's more complicated than it needs to be? We get six 64-bit registers back from the hypervisor, they're cpu endian obviously, and each is defined to consist of four 2 byte fields. So to unpack them, can't we just iterate over those six 64-bit values, which if we load them as 64-bit values will be back in cpu endian? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 35/44] m68k: Register with kernel poweroff handler
On Tue, Oct 7, 2014 at 7:28 AM, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly.
>
> Cc: Geert Uytterhoeven
> Cc: Joshua Thompson
> Signed-off-by: Guenter Roeck
As someone already mentioned, having #defines instead of hardcoded
numbers for the priorities would be nice.
Apart from that:
Acked-by: Geert Uytterhoeven
> + register_poweroff_handler_simple(nf_poweroff, 128);
> + register_poweroff_handler_simple(mac_poweroff, 128);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/44] kernel: Move pm_power_off to common code
On Tue, Oct 7, 2014 at 7:28 AM, Guenter Roeck wrote:
> pm_power_off is defined for all architectures. Move it to common code.
>
> Have all architectures call do_kernel_poweroff instead of pm_power_off.
> Some architectures point pm_power_off to machine_power_off. For those,
> call do_kernel_poweroff from machine_power_off instead.
> arch/m68k/kernel/process.c | 6 +-
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/44] m68k: Replace mach_power_off with pm_power_off
On Tue, Oct 7, 2014 at 7:28 AM, Guenter Roeck wrote:
> Replace mach_power_off with pm_power_off to simplify the subsequent
> move of pm_power_off to generic code.
Thanks!
> Cc: Geert Uytterhoeven
> Cc: Greg Ungerer
> Cc: Joshua Thompson
> Signed-off-by: Guenter Roeck
Looks OK, so since you said it builds ;-)
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/book3s: Fix an issue where guest is paused on receiving HMI.
From: Mahesh Salgaonkar When we get an HMI while in guest enter/exit path, we see that guest enters into paused state. The reason is, in kvmppc_handle_exit_hv it falls through default path and returns to host instead of resuming guest. This causes guest to enter into paused state. HMI is hypervisor only interrupt and it is safe to resume guest since host has handled it already. This patch adds switch case to handle HMI and resume guest. Without this patch we see guest entering into pasued state with following console messages: [ 3003.329351] Severe Hypervisor Maintenance interrupt [Recovered] [ 3003.329356] Error detail: Timer facility experienced an error [ 3003.329359] HMER: 0840 [ 3003.329360] TFMR: 4a12000980a84000 [ 3003.329366] vcpu c007c35094c0 (40): [ 3003.329368] pc = c00c2ba0 msr = 80009032 trap = e60 [ 3003.329370] r 0 = c021ddc0 r16 = 0046 [ 3003.329372] r 1 = c0007a02bbd0 r17 = 327d5d98 [ 3003.329375] r 2 = c10980b8 r18 = 1fc9a0b0 [ 3003.329377] r 3 = c142d6b8 r19 = c142d6b8 [ 3003.329379] r 4 = 0002 r20 = [ 3003.329381] r 5 = c524a110 r21 = [ 3003.329383] r 6 = 0001 r22 = [ 3003.329386] r 7 = r23 = c524a110 [ 3003.329388] r 8 = r24 = 0001 [ 3003.329391] r 9 = 0001 r25 = c0007c31da38 [ 3003.329393] r10 = c14280b8 r26 = 0002 [ 3003.329395] r11 = 746f6f6c2f68656c r27 = c524a110 [ 3003.329397] r12 = 28004484 r28 = c0007c31da38 [ 3003.329399] r13 = cfe01400 r29 = 0002 [ 3003.329401] r14 = 0046 r30 = c3011e00 [ 3003.329403] r15 = ffba r31 = 0002 [ 3003.329404] ctr = c041a670 lr = c0272520 [ 3003.329405] srr0 = c007e8d8 srr1 = 90001002 [ 3003.329406] sprg0 = sprg1 = cfe01400 [ 3003.329407] sprg2 = cfe01400 sprg3 = 0005 [ 3003.329408] cr = 48004482 xer = 2000 dsisr = 4200 [ 3003.329409] dar = 010015020048 [ 3003.329410] fault dar = 010015020048 dsisr = 4200 [ 3003.329411] SLB (8 entries): [ 3003.329412] ESID = c800 VSID = 40016e7779000510 [ 3003.329413] ESID = d801 VSID = 400142add1000510 [ 3003.329414] ESID = f804 VSID = 4000eb1a81000510 [ 3003.329415] ESID = 1f00080b VSID = 40004fda0a000d90 [ 3003.329416] ESID = 3f00080c VSID = 400039f536000d90 [ 3003.329417] ESID = 180d VSID = 0001251b35150d90 [ 3003.329417] ESID = 0100080e VSID = 4001e4609d90 [ 3003.329418] ESID = d8000819 VSID = 40013d349c000400 [ 3003.329419] lpcr = c04881847001 sdr1 = 001b1906 last_inst = [ 3003.329421] trap=0xe60 | pc=0xc00c2ba0 | msr=0x80009032 [ 3003.329524] Severe Hypervisor Maintenance interrupt [Recovered] [ 3003.329526] Error detail: Timer facility experienced an error [ 3003.329527] HMER: 0840 [ 3003.329527] TFMR: 4a12000980a94000 [ 3006.359786] Severe Hypervisor Maintenance interrupt [Recovered] [ 3006.359792] Error detail: Timer facility experienced an error [ 3006.359795] HMER: 0840 [ 3006.359797] TFMR: 4a12000980a84000 # virsh list --all IdName State 2 guest2 running 3 guest3 paused 4 guest4 running Signed-off-by: Mahesh Salgaonkar --- arch/powerpc/kvm/book3s_hv.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index 27cced9..c2d30be 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -745,6 +745,8 @@ static int kvmppc_handle_exit_hv(struct kvm_run *run, struct kvm_vcpu *vcpu, vcpu->stat.ext_intr_exits++; r = RESUME_GUEST; break; + /* HMI is hypervisor interrupt and host has handled it. Resume guest.*/ + case BOOK3S_INTERRUPT_HMI: case BOOK3S_INTERRUPT_PERFMON: r = RESUME_GUEST; break; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 31/44] arm: Register with kernel poweroff handler
On 07/10/2014 07:28, Guenter Roeck :
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Always use register_poweroff_handler_simple as there is no
> indication that more than one poweroff handler is registered.
>
> If the poweroff handler only resets the system or puts the CPU in sleep mode,
> select a priority of 0 to indicate that the poweroff handler is one of last
> resort. If the poweroff handler powers off the system, select a priority
> of 128.
>
> Cc: Russell King
> Cc: Andrew Victor
> Cc: Nicolas Ferre
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Stephen Warren
> Cc: Christian Daudt
> Cc: Matt Porter
> Cc: Anton Vorontsov
> Cc: Rob Herring
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Imre Kaloz
> Cc: Krzysztof Halasa
> Cc: Tony Lindgren
> Cc: Jason Cooper
> Cc: Andrew Lunn
> Cc: Sebastian Hesselbarth
> Cc: Eric Miao
> Cc: Haojian Zhuang
> Cc: Robert Jarzmik
> Cc: Marek Vasut
> Cc: Ben Dooks
> Cc: Kukjin Kim
> Cc: Linus Walleij
> Cc: Tony Prisk
> Cc: Stefano Stabellini
> Signed-off-by: Guenter Roeck
> ---
> arch/arm/kernel/psci.c | 2 +-
> arch/arm/mach-at91/board-gsia18s.c | 2 +-
> arch/arm/mach-at91/setup.c | 4 ++--
For the 2 files above: NAK just because:
for the first one -> this file will be removed during 3.19 dev cycle.
for the second one -> the poweroff handlers are removed during the 3.18
cycle and converted in the appropriate poweroff drivers (in
drivers/power/reset/at91-poweroff.c).
So, can you remove these changes from your patch?
Thanks for your work, bye.
> arch/arm/mach-bcm/board_bcm2835.c | 2 +-
> arch/arm/mach-cns3xxx/cns3420vb.c | 2 +-
> arch/arm/mach-cns3xxx/core.c | 2 +-
> arch/arm/mach-highbank/highbank.c | 2 +-
> arch/arm/mach-imx/mach-mx31moboard.c | 2 +-
> arch/arm/mach-iop32x/em7210.c | 2 +-
> arch/arm/mach-iop32x/glantank.c| 2 +-
> arch/arm/mach-iop32x/iq31244.c | 2 +-
> arch/arm/mach-iop32x/n2100.c | 2 +-
> arch/arm/mach-ixp4xx/dsmg600-setup.c | 2 +-
> arch/arm/mach-ixp4xx/nas100d-setup.c | 2 +-
> arch/arm/mach-ixp4xx/nslu2-setup.c | 2 +-
> arch/arm/mach-omap2/board-omap3touchbook.c | 2 +-
> arch/arm/mach-orion5x/board-mss2.c | 2 +-
> arch/arm/mach-orion5x/dns323-setup.c | 6 +++---
> arch/arm/mach-orion5x/kurobox_pro-setup.c | 2 +-
> arch/arm/mach-orion5x/ls-chl-setup.c | 2 +-
> arch/arm/mach-orion5x/ls_hgl-setup.c | 2 +-
> arch/arm/mach-orion5x/lsmini-setup.c | 2 +-
> arch/arm/mach-orion5x/mv2120-setup.c | 2 +-
> arch/arm/mach-orion5x/net2big-setup.c | 2 +-
> arch/arm/mach-orion5x/terastation_pro2-setup.c | 2 +-
> arch/arm/mach-orion5x/ts209-setup.c| 2 +-
> arch/arm/mach-orion5x/ts409-setup.c| 2 +-
> arch/arm/mach-pxa/corgi.c | 2 +-
> arch/arm/mach-pxa/mioa701.c| 2 +-
> arch/arm/mach-pxa/poodle.c | 2 +-
> arch/arm/mach-pxa/spitz.c | 2 +-
> arch/arm/mach-pxa/tosa.c | 2 +-
> arch/arm/mach-pxa/viper.c | 2 +-
> arch/arm/mach-pxa/z2.c | 6 +++---
> arch/arm/mach-pxa/zeus.c | 6 +++---
> arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
> arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
> arch/arm/mach-s3c24xx/mach-vr1000.c| 2 +-
> arch/arm/mach-s3c64xx/mach-smartq.c| 2 +-
> arch/arm/mach-sa1100/generic.c | 2 +-
> arch/arm/mach-sa1100/simpad.c | 2 +-
> arch/arm/mach-u300/regulator.c | 2 +-
> arch/arm/mach-vt8500/vt8500.c | 2 +-
> arch/arm/xen/enlighten.c | 2 +-
> 44 files changed, 51 insertions(+), 51 deletions(-)
>
> diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
> index f73891b..dd58d86 100644
> --- a/arch/arm/kernel/psci.c
> +++ b/arch/arm/kernel/psci.c
> @@ -264,7 +264,7 @@ static int psci_0_2_init(struct device_node *np)
>
> arm_pm_restart = psci_sys_reset;
>
> - pm_power_off = psci_sys_poweroff;
> + register_poweroff_handler_simple(psci_sys_poweroff, 128);
>
> out_put_node:
> of_node_put(np);
> diff --git a/arch/arm/mach-at91/board-gsia18s.c
> b/arch/arm/mach-at91/board-gsia18s.c
> index b729dd1..6722e66 100644
> --- a/arch/arm/mach-at91/board-gsia18s.c
> +++ b/arch/arm/mach-at91/board-gsia18s.c
> @@ -521,7 +521,7 @@ static void gsia18s_power_off(void)
>
> static int __init gsia18s_power_off_init(void)
> {
> - pm_power_off = gsia18s_power_off;
> + register_poweroff_handler_simple(gsia18s_power_off, 128);
> return 0;
> }
>
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> inde
Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
On Mon, 06 Oct 2014, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Register with a low priority value of 64 to reflect that
> the original code only sets pm_power_off if it was not already set.
>
> Cc: Linus Walleij
> Cc: Lee Jones
> Cc: Samuel Ortiz
> Signed-off-by: Guenter Roeck
> ---
> drivers/mfd/ab8500-sysctrl.c | 26 +++---
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
> index 8e0dae5..677438f 100644
> --- a/drivers/mfd/ab8500-sysctrl.c
> +++ b/drivers/mfd/ab8500-sysctrl.c
> @@ -6,6 +6,7 @@
[...]
> +static int ab8500_power_off(struct notifier_block *this, unsigned long
> unused1,
> + void *unused2)
> {
> sigset_t old;
> sigset_t all;
> @@ -34,11 +36,6 @@ static void ab8500_power_off(void)
> struct power_supply *psy;
> int ret;
>
> - if (sysctrl_dev == NULL) {
> - pr_err("%s: sysctrl not initialized\n", __func__);
> - return;
> - }
Can you explain the purpose of this change please?
> /*
>* If we have a charger connected and we're powering off,
>* reboot into charge-only mode.
> @@ -83,8 +80,15 @@ shutdown:
>AB8500_STW4500CTRL1_SWRESET4500N);
> (void)sigprocmask(SIG_SETMASK, &old, NULL);
> }
> +
> + return NOTIFY_DONE;
> }
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 18/44] mfd: twl4030-power: Register with kernel poweroff handler
On Mon, 06 Oct 2014, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Register with a low priority value of 64 to reflect that
> the original code only sets pm_power_off if it was not already set.
>
> Make twl4030_power_off static as it is only called from the twl4030-power
> driver.
>
> Cc: Samuel Ortiz
> Cc: Lee Jones
> Signed-off-by: Guenter Roeck
> ---
> drivers/mfd/twl4030-power.c | 25 +
> include/linux/i2c/twl.h | 1 -
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 4d3ff37..bd6b830 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -25,9 +25,10 @@
> */
>
> #include
> -#include
> +#include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -611,7 +612,8 @@ twl4030_power_configure_resources(const struct
> twl4030_power_data *pdata)
> * After a successful execution, TWL shuts down the power to the SoC
> * and all peripherals connected to it.
> */
> -void twl4030_power_off(void)
> +static int twl4030_power_off(struct notifier_block *this, unsigned long
> unused1,
> + void *unused2)
> {
> int err;
>
> @@ -619,8 +621,15 @@ void twl4030_power_off(void)
> TWL4030_PM_MASTER_P1_SW_EVENTS);
> if (err)
> pr_err("TWL4030 Unable to power off\n");
> +
> + return NOTIFY_DONE;
> }
>
> +static struct notifier_block twl4030_poweroff_nb = {
> + .notifier_call = twl4030_power_off,
> + .priority = 64,
64 out of what? How is this calculated? Wouldn't it be better to
define these?
> +};
> +
> static bool twl4030_power_use_poweroff(const struct twl4030_power_data
> *pdata,
> struct device_node *node)
> {
> @@ -836,7 +845,7 @@ static int twl4030_power_probe(struct platform_device
> *pdev)
> }
>
> /* Board has to be wired properly to use this feature */
> - if (twl4030_power_use_poweroff(pdata, node) && !pm_power_off) {
> + if (twl4030_power_use_poweroff(pdata, node)) {
> /* Default for SEQ_OFFSYNC is set, lets ensure this */
> err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, &val,
> TWL4030_PM_MASTER_CFG_P123_TRANSITION);
> @@ -853,7 +862,13 @@ static int twl4030_power_probe(struct platform_device
> *pdev)
> }
> }
>
> - pm_power_off = twl4030_power_off;
> + err = register_poweroff_handler(&twl4030_poweroff_nb);
> + if (err) {
> + dev_err(&pdev->dev,
> + "Failed to register poweroff handler\n");
If this is not fatal, you should issue a dev_warn() instead.
> + /* Not a fatal error */
> + err = 0;
How about using your own variable for this? Then you don't have to
worry about resetting it.
> + }
> }
>
> relock:
> @@ -869,6 +884,8 @@ relock:
>
> static int twl4030_power_remove(struct platform_device *pdev)
> {
> + unregister_poweroff_handler(&twl4030_poweroff_nb);
Perhaps a naive question, but is there any way you can do this using
devres (devm_* managed resources)?
> return 0;
> }
>
> diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
> index 8cfb50f..f8544f1 100644
> --- a/include/linux/i2c/twl.h
> +++ b/include/linux/i2c/twl.h
> @@ -680,7 +680,6 @@ struct twl4030_power_data {
> };
>
> extern int twl4030_remove_script(u8 flags);
> -extern void twl4030_power_off(void);
>
> struct twl4030_codec_data {
> unsigned int digimic_delay; /* in ms */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
Hello
This seems exactly what I would need on the mc13783 to handle cleanly
the poweroff,
but after reading this patchset I have the following question:
[...]
+/*
+ * Notifier list for kernel code which wants to be called
+ * to power off the system.
+ */
+static ATOMIC_NOTIFIER_HEAD(poweroff_handler_list);
[...]
+void do_kernel_poweroff(void)
+{
+ atomic_notifier_call_chain(&poweroff_handler_list, 0, NULL);
+}
+
It seems that the poweroff callback needs to be atomic as per
_atomic_notifier_call_chain documentation:
"Calls each function in a notifier chain in turn. The functions
run in an atomic context"
But this is a problem for many MFD (mc13783, twl4030 etc ...) which are
accessible on only a blocking bus (SPI, I2C).
What I am missing here ?
Thanks,
Philippe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
