* Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
From: Rob Landley @ 2014-10-07 16:21 UTC (permalink / raw)
To: Guenter Roeck, linux-kernel
Cc: linux-m32r-ja, linux-mips, linux-efi, linux-ia64, linux-xtensa,
Mark Rutland, devel, linux-s390, lguest, linux-c6x-dev,
linux-hexagon, linux-sh, linux-acpi, Pawel Moll, xen-devel,
devicetree, user-mode-linux-devel, linux-pm, adi-buildroot-devel,
linux-m68k, linux-am33-list, linux-tegra, openipmi-developer,
linux-metag, linux-arm-kernel, linux-parisc, linux-cris-kernel,
Rob Herring, linux-alpha, linuxppc-dev
In-Reply-To: <1412659726-29957-6-git-send-email-linux@roeck-us.net>
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
^ permalink raw reply
* Re: [PATCH 29/44] staging: nvec: Register with kernel poweroff handler
From: Greg Kroah-Hartman @ 2014-10-07 16:23 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-m32r-ja, linux-mips, linux-efi, linux-ia64, linux-xtensa,
devel, linux-s390, lguest, linux-c6x-dev, linux-hexagon, linux-sh,
linux-acpi, xen-devel, devicetree, user-mode-linux-devel,
linux-pm, Julian Andres Klode, adi-buildroot-devel, linux-m68k,
linux-am33-list, linux-tegra, openipmi-developer, linux-metag,
linux-arm-kernel, linux-parisc, linux-cris-kernel, linux-kernel,
linux-alpha, linuxppc-dev
In-Reply-To: <1412659726-29957-30-git-send-email-linux@roeck-us.net>
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 <jak@jak-linux.org>
> Cc: Marc Dietrich <marvin24@gmx.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/staging/nvec/nvec.c | 24 +++++++++++++++---------
> drivers/staging/nvec/nvec.h | 2 ++
> 2 files changed, 17 insertions(+), 9 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
From: Guenter Roeck @ 2014-10-07 16:31 UTC (permalink / raw)
To: Rob Landley
Cc: linux-m32r-ja, linux-mips, linux-efi, linux-ia64, linux-xtensa,
Mark Rutland, devel, linux-s390, lguest, linux-c6x-dev,
linux-hexagon, linux-sh, linux-acpi, Pawel Moll, xen-devel,
devicetree, user-mode-linux-devel, linux-pm, adi-buildroot-devel,
linux-m68k, linux-am33-list, linux-tegra, openipmi-developer,
linux-metag, linux-arm-kernel, linux-parisc, linux-cris-kernel,
linux-kernel, Rob Herring, linux-alpha, linuxppc-dev
In-Reply-To: <543412F7.8040909@landley.net>
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
^ permalink raw reply
* Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
From: Mark Rutland @ 2014-10-07 16:58 UTC (permalink / raw)
To: Rob Landley
Cc: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org,
linux-m68k@vger.kernel.org, linux-efi@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-xtensa@linux-xtensa.org,
devel@driverdev.osuosl.org, linux-s390@vger.kernel.org,
lguest@lists.ozlabs.org, linux-c6x-dev@linux-c6x.org,
linux-hexagon@vger.kernel.org, linux-sh@vger.kernel.org,
linux-acpi@vger.kernel.org, Pawel Moll,
xen-devel@lists.xenproject.org, Guenter Roeck,
devicetree@vger.kernel.org,
user-mode-linux-devel@lists.sourceforge.net,
linux-pm@vger.kernel.org,
adi-buildroot-devel@lists.sourceforge.net,
linux-am33-list@redhat.com, linux-tegra@vger.kernel.org,
openipmi-developer@lists.sourceforge.net,
linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Rob Herring,
linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <543412F7.8040909@landley.net>
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.
^ permalink raw reply
* Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
From: David Daney @ 2014-10-07 16:59 UTC (permalink / raw)
To: Guenter Roeck, Rob Landley
Cc: linux-m32r-ja, linux-mips, linux-efi, linux-ia64, linux-xtensa,
Mark Rutland, devel, linux-s390, lguest, linux-c6x-dev,
linux-hexagon, linux-sh, linux-acpi, Pawel Moll, xen-devel,
devicetree, user-mode-linux-devel, linux-pm, adi-buildroot-devel,
linux-m68k, linux-am33-list, linux-tegra, openipmi-developer,
linux-metag, linux-arm-kernel, linux-parisc, linux-cris-kernel,
linux-kernel, Rob Herring, linux-alpha, linuxppc-dev
In-Reply-To: <20141007163131.GE28835@roeck-us.net>
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
^ permalink raw reply
* Re: [PATCH 00/20] powerpc: Convert power off logic to pm_power_off
From: Guenter Roeck @ 2014-10-07 17:00 UTC (permalink / raw)
To: Alexander Graf
Cc: Arnd Bergmann, Geoff Levand, Alistair Popple, Scott Wood,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <5433CFEB.9040104@suse.de>
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
^ permalink raw reply
* Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
From: Rob Landley @ 2014-10-07 17:10 UTC (permalink / raw)
To: David Daney, Guenter Roeck
Cc: linux-m32r-ja, linux-mips, linux-efi, linux-ia64, linux-xtensa,
Mark Rutland, devel, linux-s390, lguest, linux-c6x-dev,
linux-hexagon, linux-sh, linux-acpi, Pawel Moll, xen-devel,
devicetree, user-mode-linux-devel, linux-pm, adi-buildroot-devel,
linux-m68k, linux-am33-list, linux-tegra, openipmi-developer,
linux-metag, linux-arm-kernel, linux-parisc, linux-cris-kernel,
linux-kernel, Rob Herring, linux-alpha, linuxppc-dev
In-Reply-To: <54341BF1.9020001@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 00/20] powerpc: Convert power off logic to pm_power_off
From: Alexander Graf @ 2014-10-07 17:47 UTC (permalink / raw)
To: Guenter Roeck
Cc: Arnd Bergmann, Geoff Levand, Alistair Popple, Scott Wood,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20141007170052.GB16931@roeck-us.net>
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
^ permalink raw reply
* Re: [PATCH V25/5] powerpc/kexec: Use global IND_FLAGS macro
From: Vivek Goyal @ 2014-10-07 17:52 UTC (permalink / raw)
To: Geoff Levand
Cc: kexec, linux-kernel, Eric Biederman, Andrew Morton, linuxppc-dev
In-Reply-To: <adf97d602657c72f6ee59aefe5d51149159a3e99.1412640584.git.geoff@infradead.org>
On Tue, Oct 07, 2014 at 12:21:30AM +0000, 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 <geoff@infradead.org>
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
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH 00/20] powerpc: Convert power off logic to pm_power_off
From: Guenter Roeck @ 2014-10-07 19:03 UTC (permalink / raw)
To: Alexander Graf
Cc: Arnd Bergmann, Geoff Levand, Alistair Popple, Scott Wood,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <54342737.5010802@suse.de>
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
^ permalink raw reply
* [PATCH] powerpc: mitigate impact of decrementer reset
From: Paul Clarke @ 2014-10-07 19:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1412708517-84726-1-git-send-email-pc@us.ibm.com>
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 0x7fffffff.
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 <pc@us.ibm.com>
---
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
^ permalink raw reply related
* Re: [PATCH V3 4/5] kexec: Add IND_FLAGS macro
From: Geoff Levand @ 2014-10-07 20:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, kexec, Eric Biederman, linux-kernel
In-Reply-To: <de975a34c5beb9715359eaa4d74ba82a7798aae3.1412640584.git.geoff@infradead.org>
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 <geoff@infradead.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
---
>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
^ permalink raw reply related
* Re: [v3, 08/16] powerpc/powerpc: Add new PCIe functions for allocating cxl interrupts
From: Michael Ellerman @ 2014-10-07 22:59 UTC (permalink / raw)
To: Michael Neuling, greg, arnd, benh
Cc: cbe-oss-dev, mikey, linux-kernel, imunsie, linuxppc-dev,
Aneesh Kumar K.V, anton, jk
In-Reply-To: <1412678902-18672-9-git-send-email-mikey@neuling.org>
On Tue, 2014-07-10 at 10:48:14 UTC, Michael Neuling wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> 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 <asm/debug.h>
> #include <asm/firmware.h>
>
> +#include <misc/cxl.h>
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
^ permalink raw reply
* Re: [v3,12/16] cxl: Add base builtin support
From: Michael Ellerman @ 2014-10-07 23:04 UTC (permalink / raw)
To: Michael Neuling, greg, arnd, benh
Cc: cbe-oss-dev, mikey, linux-kernel, imunsie, linuxppc-dev,
Aneesh Kumar K.V, anton, jk
In-Reply-To: <1412678902-18672-13-git-send-email-mikey@neuling.org>
On Tue, 2014-07-10 at 10:48:18 UTC, Michael Neuling wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> 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
^ permalink raw reply
* Re: [PATCH 03/44] hibernate: Call have_kernel_poweroff instead of checking pm_power_off
From: Rafael J. Wysocki @ 2014-10-07 23:41 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-m32r-ja, linux-mips, linux-efi, linux-ia64, Len Brown,
linux-xtensa, Pavel Machek, devel, linux-s390, lguest,
linux-c6x-dev, linux-hexagon, linux-sh, linux-acpi, xen-devel,
devicetree, user-mode-linux-devel, linux-pm, adi-buildroot-devel,
linux-m68k, linux-am33-list, linux-tegra, openipmi-developer,
linux-metag, linux-arm-kernel, linux-parisc, linux-cris-kernel,
linux-kernel, linux-alpha, linuxppc-dev
In-Reply-To: <1412659726-29957-4-git-send-email-linux@roeck-us.net>
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 <rjw@rjwysocki.net>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Len Brown <len.brown@intel.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
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.
^ permalink raw reply
* Re: [PATCH 08/44] kernel: Move pm_power_off to common code
From: Rafael J. Wysocki @ 2014-10-07 23:42 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-m32r-ja, linux-mips, linux-efi, linux-ia64, Steven Miao,
linux-xtensa, Boris Ostrovsky, Catalin Marinas, Will Deacon,
David Howells, Max Filippov, Paul Mackerras, Ralf Baechle,
Pavel Machek, H. Peter Anvin, Guan Xuetao, Thomas Gleixner,
Lennox Wu, Hans-Christian Egtvedt, devel, linux-s390,
Jesper Nilsson, lguest, Russell King, linux-c6x-dev, Len Brown,
David S. Miller, linux-hexagon, Hirokazu Takata, linux-sh,
James E.J. Bottomley, linux-acpi, Ingo Molnar, Geert Uytterhoeven,
Mark Salter, xen-devel, Matt Turner, Chen Liqin, Jonas Bonn,
Haavard Skinnemoen, devicetree, James Hogan,
user-mode-linux-devel, linux-pm, Aurelien Jacquiot,
Heiko Carstens, Jeff Dike, adi-buildroot-devel, Chris Metcalf,
Konrad Rzeszutek Wilk, Mikael Starvik, Richard Weinberger,
linux-m68k, linux-am33-list, Ivan Kokshaysky, linux-tegra,
openipmi-developer, linux-metag, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
linux-parisc, linux-cris-kernel, Vineet Gupta, linux-kernel,
Fenghua Yu, Richard Kuo, David Vrabel, linux-alpha,
Martin Schwidefsky, Koichi Yasutake, linuxppc-dev, Helge Deller
In-Reply-To: <1412659726-29957-9-git-send-email-linux@roeck-us.net>
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.
^ permalink raw reply
* Re: [PATCH 44/44] kernel: Remove pm_power_off
From: Rafael J. Wysocki @ 2014-10-07 23:43 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-m32r-ja, linux-mips, linux-efi, linux-ia64, Len Brown,
linux-xtensa, Pavel Machek, devel, linux-s390, lguest,
linux-c6x-dev, linux-hexagon, linux-sh, linux-acpi, xen-devel,
devicetree, user-mode-linux-devel, linux-pm, adi-buildroot-devel,
linux-m68k, linux-am33-list, linux-tegra, openipmi-developer,
linux-metag, linux-arm-kernel, linux-parisc, linux-cris-kernel,
linux-kernel, linux-alpha, linuxppc-dev
In-Reply-To: <1412659726-29957-45-git-send-email-linux@roeck-us.net>
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 <rjw@rjwysocki.net>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Len Brown <len.brown@intel.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
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 <linux/types.h>
>
> /*
> - * 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.
^ permalink raw reply
* Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
From: Alex Deucher @ 2014-10-07 23:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Dave Airlie, Linux PCI, Anton Blanchard, Brian King,
Yijing Wang, Takashi Iwai, Bjorn Helgaas
In-Reply-To: <1412656696.30859.122.camel@pasglop>
On Tue, Oct 7, 2014 at 12:38 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> From: Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
>
> 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 <alexdeucher@gmail.com>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: <stable@vger.kernel.org>
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),
> - .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, 0xaa38),
> - .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, 0xaa40),
> - .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, 0xaa48),
> - .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, 0xaa50),
> - .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, 0xaa58),
> - .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, 0xaa60),
> - .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, 0xaa68),
> - .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, 0xaa80),
> - .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, 0xaa88),
> - .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, 0xaa90),
> - .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, 0xaa98),
> - .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, 0x9902),
> - .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaaa0),
> - .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaaa8),
> - .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> { PCI_DEVICE(0x1002, 0xaab0),
> - .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI },
> + .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI |
> + AZX_DCAPS_NO_MSI64 },
> /* VIA VT8251/VT8237A */
> { PCI_DEVICE(0x1106, 0x3288),
> .driver_data = AZX_DRIVER_VIA | AZX_DCAPS_POSFIX_VIA },
> diff --git a/sound/pci/hda/hda_priv.h b/sound/pci/hda/hda_priv.h
> index 949cd43..5016014 100644
> --- a/sound/pci/hda/hda_priv.h
> +++ b/sound/pci/hda/hda_priv.h
> @@ -171,6 +171,7 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO1, SDO2, SDO3 };
> #define AZX_DCAPS_PM_RUNTIME (1 << 26) /* runtime PM support */
> #define AZX_DCAPS_I915_POWERWELL (1 << 27) /* HSW i915 powerwell support */
> #define AZX_DCAPS_CORBRP_SELF_CLEAR (1 << 28) /* CORBRP clears itself after reset */
> +#define AZX_DCAPS_NO_MSI64 (1 << 29) /* Stick to 32-bit MSIs */
>
> /* HD Audio class code */
> #define PCI_CLASS_MULTIMEDIA_HD_AUDIO 0x0403
>
>
^ permalink raw reply
* Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
From: Benjamin Herrenschmidt @ 2014-10-07 23:49 UTC (permalink / raw)
To: Alex Deucher
Cc: linuxppc-dev, Dave Airlie, Linux PCI, Anton Blanchard, Brian King,
Yijing Wang, Takashi Iwai, Bjorn Helgaas
In-Reply-To: <CADnq5_NFt8neiOAg896d3-DbAn0rnrE7iXaTFmkNGSg-J9oSkA@mail.gmail.com>
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 <alexdeucher@gmail.com>
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > CC: <stable@vger.kernel.org>
>
> 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.
^ permalink raw reply
* Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
From: Alex Deucher @ 2014-10-08 0:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Dave Airlie, Linux PCI, Anton Blanchard, Brian King,
Yijing Wang, Takashi Iwai, Bjorn Helgaas
In-Reply-To: <1412725790.30859.214.camel@pasglop>
On Tue, Oct 7, 2014 at 7:49 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> 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 <alexdeucher@gmail.com>
>> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> > CC: <stable@vger.kernel.org>
>>
>> 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.
>
>
^ permalink raw reply
* Re: [v3,12/16] cxl: Add base builtin support
From: Michael Neuling @ 2014-10-08 0:45 UTC (permalink / raw)
To: Michael Ellerman
Cc: cbe-oss-dev, arnd, greg, imunsie, linux-kernel, linuxppc-dev,
Aneesh Kumar K.V, anton, jk
In-Reply-To: <20141007230416.2040C14011E@ozlabs.org>
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 <imunsie@au1.ibm.com>
> >=20
> > This adds the base cxl support that needs to be build into the kernel t=
o use
> > cxl as a module. This is needed so that the cxl call backs from the cor=
e
> > powerpc mm code always exist irrespective of if the cxl module is loade=
d or
> > not. This is similar to how cell works with CONFIG_SPU_BASE.
> >=20
> > This adds a cxl_slbia() call (similar to spu_flush_all_slbs()) which ch=
ecks for
> > the cxl module being loaded. If the modules is not loaded we return, ot=
herwise
> > we call into the cxl SLB invalidation code.
> >=20
> > 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 g=
et/put
> > calls for the cxl driver module to refcount the active cxl contexts.
>=20
> This last paragraph is no longer true.
Yep, thanks. I'll move it to patch 7 where it does apply.
Mikey
^ permalink raw reply
* Re: [v3, 08/16] powerpc/powerpc: Add new PCIe functions for allocating cxl interrupts
From: Michael Neuling @ 2014-10-08 0:46 UTC (permalink / raw)
To: Michael Ellerman
Cc: cbe-oss-dev, arnd, greg, imunsie, linux-kernel, linuxppc-dev,
Aneesh Kumar K.V, anton, jk
In-Reply-To: <20141007225905.0F85514011E@ozlabs.org>
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 <imunsie@au1.ibm.com>
> >=20
> > This adds a number of functions for allocating IRQs under powernv PCIe =
for cxl.
> >=20
> > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/p=
latforms/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 <asm/debug.h>
> > #include <asm/firmware.h>
> > =20
> > +#include <misc/cxl.h>
>=20
> You should be including pnv-pci.h here.
>=20
> Otherwise the header and the implementation could get out of sync, it wil=
l also
> fix these:
>=20
> 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
^ permalink raw reply
* Re: powerpc: mitigate impact of decrementer reset
From: Michael Ellerman @ 2014-10-08 2:52 UTC (permalink / raw)
To: Paul Clarke, linuxppc-dev
In-Reply-To: <54343B54.4060500@us.ibm.com>
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 0x7fffffff.
> 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
^ permalink raw reply
* RE: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
From: Hongtao Jia @ 2014-10-08 3:08 UTC (permalink / raw)
To: Scott Wood, Guenter Roeck
Cc: linux-kernel@vger.kernel.org, Guenter Roeck, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org, Jojy G Varghese
In-Reply-To: <1412015766.13320.253.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDMwLCAyMDE0IDI6MzYgQU0NCj4gVG86IEd1
ZW50ZXIgUm9lY2sNCj4gQ2M6IEJlbmphbWluIEhlcnJlbnNjaG1pZHQ7IFBhdWwgTWFja2VycmFz
OyBNaWNoYWVsIEVsbGVybWFuOyBsaW51eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmc7IGxp
bnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IEpvankgRyBWYXJnaGVzZTsNCj4gR3VlbnRlciBS
b2VjazsgSmlhIEhvbmd0YW8tQjM4OTUxDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBvd2VycGMv
ZnNsOiBBZGQgc3VwcG9ydCBmb3IgcGNpKGUpIG1hY2hpbmUgY2hlY2sNCj4gZXhjZXB0aW9uIG9u
IEU1MDBNQyAvIEU1NTAwDQo+IA0KPiBPbiBNb24sIDIwMTQtMDktMjkgYXQgMDk6NDggLTA3MDAs
IEd1ZW50ZXIgUm9lY2sgd3JvdGU6DQo+ID4gRnJvbTogSm9qeSBHIFZhcmdoZXNlIDxqb2p5dkBq
dW5pcGVyLm5ldD4NCj4gPg0KPiA+IEZvciBFNTAwTUMgYW5kIEU1NTAwLCBhIG1hY2hpbmUgY2hl
Y2sgZXhjZXB0aW9uIGluIHBjaShlKSBtZW1vcnkgc3BhY2UNCj4gPiBjcmFzaGVzIHRoZSBrZXJu
ZWwuDQo+ID4NCj4gPiBUZXN0aW5nIHNob3dzIHRoYXQgdGhlIE1DQVIoVSkgcmVnaXN0ZXIgaXMg
emVybyBvbiBhIE1DIGV4Y2VwdGlvbiBmb3INCj4gPiB0aGUNCj4gPiBFNTUwMCBjb3JlLiBBdCB0
aGUgc2FtZSB0aW1lLCBERUFSIHJlZ2lzdGVyIGhhcyBiZWVuIGZvdW5kIHRvIGhhdmUgdGhlDQo+
ID4gYWRkcmVzcyBvZiB0aGUgZmF1bHR5IGxvYWQgYWRkcmVzcyBkdXJpbmcgYW4gTUMgZXhjZXB0
aW9uIGZvciB0aGlzIGNvcmUuDQo+ID4NCj4gPiBUaGlzIGZpeCBjaGFuZ2VzIHRoZSBjdXJyZW50
IGJlaGF2aW9yIHRvIGZpeHVwIHRoZSByZXN1bHQgcmVnaXN0ZXIgYW5kDQo+ID4gaW5zdHJ1Y3Rp
b24gcG9pbnRlcnMgaW4gdGhlIGNhc2Ugb2YgYSBsb2FkIG9wZXJhdGlvbiBvbiBhIGZhdWx0eSBQ
Q0kNCj4gPiBhZGRyZXNzLg0KPiA+DQo+ID4gVGhlIGNoYW5nZXMgYXJlOg0KPiA+IC0gQWRkZWQg
dGhlIGhvb2sgdG8gcGNpIG1hY2hpbmUgY2hlY2sgaGFuZGluZyB0byB0aGUgZTUwMG1jIG1hY2hp
bmUNCj4gY2hlY2sNCj4gPiAgIGV4Y2VwdGlvbiBoYW5kbGVyLg0KPiA+IC0gRm9yIHRoZSBFNTUw
MCBjb3JlLCBsb2FkIGZhdWx0aW5nIGFkZHJlc3MgZnJvbSBTUFJOX0RFQVIgcmVnaXN0ZXIuDQo+
ID4gICBBcyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgaXMgbmVjZXNzYXJ5IGJlY2F1c2UgdGhlIEU1
NTAwIGNvcmUgZG9lcyBub3QNCj4gPiAgIHJlcG9ydCB0aGUgZmF1bHQgYWRkcmVzcyBpbiB0aGUg
TUNBUiByZWdpc3Rlci4NCj4gPg0KPiA+IENjOiBTY290dCBXb29kIDxzY290dHdvb2RAZnJlZXNj
YWxlLmNvbT4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBKb2p5IEcgVmFyZ2hlc2UgPGpvanl2QGp1bmlw
ZXIubmV0PiBbR3VlbnRlciBSb2VjazoNCj4gPiB1cGRhdGVkIGRlc2NyaXB0aW9uXQ0KPiA+IFNp
Z25lZC1vZmYtYnk6IEd1ZW50ZXIgUm9lY2sgPGdyb2Vja0BqdW5pcGVyLm5ldD4NCj4gPiBTaWdu
ZWQtb2ZmLWJ5OiBHdWVudGVyIFJvZWNrIDxsaW51eEByb2Vjay11cy5uZXQ+DQo+ID4gLS0tDQo+
ID4gIGFyY2gvcG93ZXJwYy9rZXJuZWwvdHJhcHMuYyAgIHwgMyArKy0NCj4gPiAgYXJjaC9wb3dl
cnBjL3N5c2Rldi9mc2xfcGNpLmMgfCA1ICsrKysrDQo+ID4gIDIgZmlsZXMgY2hhbmdlZCwgNyBp
bnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQo+ID4NCj4gPiBkaWZmIC0tZ2l0IGEvYXJjaC9w
b3dlcnBjL2tlcm5lbC90cmFwcy5jIGIvYXJjaC9wb3dlcnBjL2tlcm5lbC90cmFwcy5jDQo+ID4g
aW5kZXggMGRjNDNmOS4uZWNiNzA5YiAxMDA2NDQNCj4gPiAtLS0gYS9hcmNoL3Bvd2VycGMva2Vy
bmVsL3RyYXBzLmMNCj4gPiArKysgYi9hcmNoL3Bvd2VycGMva2VybmVsL3RyYXBzLmMNCj4gPiBA
QCAtNDk0LDcgKzQ5NCw4IEBAIGludCBtYWNoaW5lX2NoZWNrX2U1MDBtYyhzdHJ1Y3QgcHRfcmVn
cyAqcmVncykNCj4gPiAgCWludCByZWNvdmVyYWJsZSA9IDE7DQo+ID4NCj4gPiAgCWlmIChyZWFz
b24gJiBNQ1NSX0xEKSB7DQo+ID4gLQkJcmVjb3ZlcmFibGUgPSBmc2xfcmlvX21jaGVja19leGNl
cHRpb24ocmVncyk7DQo+ID4gKwkJcmVjb3ZlcmFibGUgPSBmc2xfcmlvX21jaGVja19leGNlcHRp
b24ocmVncykgfHwNCj4gPiArCQkJZnNsX3BjaV9tY2hlY2tfZXhjZXB0aW9uKHJlZ3MpOw0KPiA+
ICAJCWlmIChyZWNvdmVyYWJsZSA9PSAxKQ0KPiA+ICAJCQlnb3RvIHNpbGVudF9vdXQ7DQo+ID4g
IAl9DQo+ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9zeXNkZXYvZnNsX3BjaS5jDQo+ID4g
Yi9hcmNoL3Bvd2VycGMvc3lzZGV2L2ZzbF9wY2kuYyBpbmRleCBjNTA3NzY3Li5iZGI5NTZiIDEw
MDY0NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9zeXNkZXYvZnNsX3BjaS5jDQo+ID4gKysrIGIv
YXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfcGNpLmMNCj4gPiBAQCAtMTAyMSw2ICsxMDIxLDExIEBA
IGludCBmc2xfcGNpX21jaGVja19leGNlcHRpb24oc3RydWN0IHB0X3JlZ3MNCj4gPiAqcmVncykg
ICNlbmRpZg0KPiA+ICAJYWRkciArPSBtZnNwcihTUFJOX01DQVIpOw0KPiA+DQo+ID4gKyNpZmRl
ZiBDT05GSUdfRTU1MDBfQ1BVDQo+ID4gKwlpZiAobWZzcHIoU1BSTl9FUENSKSAmIFNQUk5fRVBD
Ul9JQ00pDQo+ID4gKwkJYWRkciA9IFBGTl9QSFlTKHZtYWxsb2NfdG9fcGZuKCh2b2lkICopbWZz
cHIoU1BSTl9ERUFSKSkpOw0KPiAjZW5kaWYNCj4gDQo+IEtjb25maWcgdGVsbHMgeW91IHdoYXQg
aGFyZHdhcmUgaXMgc3VwcG9ydGVkLCBub3Qgd2hhdCBoYXJkd2FyZSB5b3UncmUNCj4gYWN0dWFs
bHkgcnVubmluZyBvbi4NCj4gDQo+IEppYSBIb25ndGFvLCBkbyB5b3Uga25vdyBhbnl0aGluZyBh
Ym91dCB0aGlzIGlzc3VlPyAgSXMgdGhlcmUgYW4gZXJyYXR1bT8NCg0KU29ycnkgZm9yIHRoZSBs
YXRlIHJlc3BvbnNlLCBJIGp1c3QgcmV0dXJuIGZyb20gbXkgdmFjYXRpb24uDQpJIGRvbid0IGtu
b3cgdGhpcyBpc3N1ZS4NCg0KPiBXaGF0IGNoaXBzIGFyZSBhZmZlY3RlZCBieSB0aGUgdGhlIGVy
cmF0dW0gY292ZXJlZCBieQ0KPiA8aHR0cDovL3BhdGNod29yay5vemxhYnMub3JnL3BhdGNoLzI0
MDIzOS8+Pw0KDQpNUEM4NTQ0LCBNUEM4NTQ4LCBNUEM4NTcyIGFyZSBhZmZlY3RlZCBieSB0aGlz
IGVycmF0dW0uDQpJIGNoZWNrZWQgUDQwODAgd2hpY2ggdXNpbmcgZTUwMG1jIGFuZCBubyBzdWNo
IGVycmF0dW0gaXMgZm91bmQuDQoNCj4gDQo+IENhbiB3ZSByZWx5IG9uIERFQVIgb3IgaXMgdGhp
cyBqdXN0IGEgc2lkZSBlZmZlY3Qgb2YgbGlrZWx5IGhhdmluZyB0YWtlbg0KPiBhIFRMQiBtaXNz
IGZvciB0aGUgYWRkcmVzcyByZWNlbnRseT8gIFBlcmhhcHMgd2Ugc2hvdWxkIHVzZSB0aGUNCj4g
aW5zdHJ1Y3Rpb24gZW11bGF0aW9uIHRvIGRldGVybWluZSB0aGUgZWZmZWN0aXZlIGFkZHJlc3Mg
aW5zdGVhZC4NCj4gDQo+IEd1ZW50ZXIsIGlzIHRoaXMgcGF0Y2ggaW50ZW5kZWQgdG8gZGVhbCB3
aXRoIGFuIGVycmF0dW0gb3IgYXJlIHlvdQ0KPiBjb3ZlcmluZyB1cCBsZWdpdGltYXRlIGVycm9y
cz8NCj4gDQo+IC1TY290dA0KPiANCg0K
^ permalink raw reply
* RE: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
From: Hongtao Jia @ 2014-10-08 3:10 UTC (permalink / raw)
To: Scott Wood, Guenter Roeck
Cc: linux-kernel@vger.kernel.org, Guenter Roeck, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org, Jojy Varghese
In-Reply-To: <1412124210.13320.330.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDAxLCAyMDE0IDg6NDQgQU0NCj4gVG86IEd1
ZW50ZXIgUm9lY2sNCj4gQ2M6IEpvankgVmFyZ2hlc2U7IEJlbmphbWluIEhlcnJlbnNjaG1pZHQ7
IFBhdWwgTWFja2VycmFzOyBNaWNoYWVsDQo+IEVsbGVybWFuOyBsaW51eHBwYy1kZXZAbGlzdHMu
b3psYWJzLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsNCj4gR3VlbnRlciBSb2Vj
azsgSmlhIEhvbmd0YW8tQjM4OTUxDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBvd2VycGMvZnNs
OiBBZGQgc3VwcG9ydCBmb3IgcGNpKGUpIG1hY2hpbmUgY2hlY2sNCj4gZXhjZXB0aW9uIG9uIEU1
MDBNQyAvIEU1NTAwDQo+IA0KPiBPbiBUdWUsIDIwMTQtMDktMzAgYXQgMDg6NTAgLTA3MDAsIEd1
ZW50ZXIgUm9lY2sgd3JvdGU6DQo+ID4gT24gTW9uLCBTZXAgMjksIDIwMTQgYXQgMDY6MzE6MDZQ
TSAtMDUwMCwgU2NvdHQgV29vZCB3cm90ZToNCj4gPiA+IE9uIE1vbiwgMjAxNC0wOS0yOSBhdCAy
MzowMyArMDAwMCwgSm9qeSBWYXJnaGVzZSB3cm90ZToNCj4gPiA+ID4NCj4gPiA+ID4gT24gOS8y
OS8xNCAxMjowNiBQTSwgIkd1ZW50ZXIgUm9lY2siIDxsaW51eEByb2Vjay11cy5uZXQ+IHdyb3Rl
Og0KPiA+ID4gPg0KPiA+ID4gPiA+VGhvc2UgYXJlIGVycm9ycyByZWxhdGVkIHRvIFBDSWUgaG90
cGx1ZywgYW5kIGFyZSBzZWVuIHdpdGgNCj4gPiA+ID4gPnVuZXhwZWN0ZWQgUENJZSBkZXZpY2Ug
cmVtb3ZhbHMgKHRyaWdnZXJlZCwgZm9yIGV4YW1wbGUsIGJ5DQo+ID4gPiA+ID5yZW1vdmluZyBw
b3dlciBmcm9tIGEgUENJZSBhZGFwdGVyKS4NCj4gPiA+ID4gPlRoZSBiZWhhdmlvciB3ZSBzZWUg
b24gRTU1MDAgaXMgcXVpdGUgc2ltaWxhciB0byB0aGUgc2FtZQ0KPiA+ID4gPiA+YmVoYXZpb3Ig
b24NCj4gPiA+ID4gPkU1MDA6DQo+ID4gPiA+ID5JZiB1bmhhbmRsZWQsIHRoZSBDUFUga2VlcHMg
ZXhlY3V0aW5nIHRoZSBzYW1lIGluc3RydWN0aW9uIG92ZXINCj4gPiA+ID4gPmFuZCBvdmVyIGFn
YWluIGlmIHRoZXJlIGlzIGFuIGVycm9yIG9uIGEgUENJZSBhY2Nlc3MgYW5kIHRodXMNCj4gPiA+
ID4gPnN0YWxscy4gSSBkb24ndCBrbm93IGlmIHRoaXMgaXMgY29uc2lkZXJlZCBhbiBlcnJhdHVt
IG9yIGV4cGVjdGVkDQo+ID4gPiA+ID5iZWhhdmlvciwgYnV0IGl0IGlzIG9uZSB3ZSBoYXZlIHRv
IGFkZHJlc3Mgc2luY2Ugd2UgaGF2ZSB0byBiZQ0KPiA+ID4gPiA+YWJsZSB0byBoYW5kbGUgdGhh
dCBjb25kaXRpb24uDQo+ID4gPg0KPiA+ID4gVGhlIHJlYXNvbiBJIGFzayBpcyB0aGF0IHRoZSBo
YW5kbGluZyBmb3IgZTUwMCB3YXMgZGVzY3JpYmVkIGFzIGFuDQo+ID4gPiBlcnJhdHVtIHdvcmth
cm91bmQuICBJZiBpdCBpcyBhbiBlcnJhdHVtIGl0IHdvdWxkIGJlIG5pY2UgdG8ga25vdw0KPiA+
ID4gdGhlIGVycmF0dW0gbnVtYmVyIGFuZCB0aGUgZnVsbCBsaXN0IG9mIGFmZmVjdGVkIGNoaXBz
Lg0KPiA+ID4NCj4gPiBNeSB1bmRlcnN0YW5kaW5nLCB3aGljaCBtYXkgYmUgd3JvbmcsIHdhcyB0
aGF0IHRoaXMgaXMgZXhwZWN0ZWQNCj4gPiBiZWhhdmlvciwgYXQgbGVhc3QgZm9yIEU1NTAwLiBJ
IGFjdHVhbGx5IHRob3VnaHQgSSBoYWQgc2VlbiBpdA0KPiA+IHNvbWV3aGVyZSBpbiB0aGUgc3Bl
Y2lmaWNhdGlvbiAocmVzcG9uc2UgdG8gUENJZSBlcnJvcnMpLCBidXQgSSBkb24ndA0KPiByZWNh
bGwgd2hlcmUgZXhhY3RseS4NCj4gPg0KPiA+IEF0IGxlYXN0IGZvciBteSBwYXJ0IEkgYW0gbm90
IGF3YXJlIG9mIGFuIGVycmF0dW0uDQo+IA0KPiBKaWEgSG9uZ3RhbywgY2FuIHlvdSBjb21tZW50
IGhlcmU/DQoNCkkgZGlkIG5vdCBmaW5kIGFueSByZWxhdGVkIGVycmF0dW0gZWl0aGVyLg0KDQo+
IA0KPiA+ID4gPiA+VWx0aW1hdGVseSwgd2UnbGwgd2FudA0KPiA+ID4gPiA+dG8NCj4gPiA+ID4g
PmltcGxlbWVudCBQQ0llIGVycm9yIGhhbmRsZXJzIGZvciB0aGUgYWZmZWN0ZWQgZHJpdmVycywg
YnV0IHRoYXQNCj4gPiA+ID4gPndpbGwgYmUgYSBuZXh0IHN0ZXAuDQo+ID4gPg0KPiA+ID4gRm9y
IG5vdyBjYW4gd2UgYXQgbGVhc3QgcHJpbnQgYSByYXRlbGltaXRlZCBlcnJvciBtZXNzYWdlPyAg
SSBkb24ndA0KPiA+ID4gbGlrZSB0aGUgaWRlYSBvZiBzaWxlbnRseSBpZ25vcmluZyB0aGVzZSBl
cnJvcnMuICBJIHN1cHBvc2UgaXQncyBhDQo+ID4gPiBzZXBhcmF0ZSBpc3N1ZSBmcm9tIGV4dGVu
ZGluZyB0aGUgd29ya2Fyb3VuZCB0byBjb3ZlciBlNTAwbWMsIHRob3VnaC4NCj4gPiA+DQo+ID4g
SSBkb24ndCByZWFsbHkgbGlrZSB0aGUgaWRlYSBvZiBwcmludGluZyBhbiBlcnJvciBtZXNzYWdl
IHByZXR0eSBtdWNoDQo+ID4gZWFjaCB0aW1lIHdoZW4gYW4gdW5leHBlY3RlZCBob3RwbHVnIGV2
ZW50IG9jY3Vycy4NCj4gDQo+IFVuZXhwZWN0ZWQgZXZlbnRzIHNlZW0gbGlrZSB0aGUgc29ydCBv
ZiB0aGluZyB5b3UnZCB3YW50IHRvIGxvZywgYnV0IG15DQo+IGNvbmNlcm4gaXMgdGhhdCB0aGlz
IG1pZ2h0IG5vdCBiZSB0aGUgb25seSBjYXVzZSBvZiBQQ0kgZXJyb3JzLg0KPiANCj4gLVNjb3R0
DQo+IA0KDQo=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox