From: Peter Zijlstra
Enable perf_event_read() to update entire groups at once, this will be
useful for read transactions.
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Michael Ellerman
Cc: Sukadev Bhattiprolu
Signed-off-by: Peter Zijlstra (Intel)
Link:
http://lkml.kernel.org/r/201507230
The 24x7 counters in Powerpc allow monitoring a large number of counters
simultaneously. They also allow reading several counters in a single
HCALL so we can get a more consistent snapshot of the system.
Use the PMU's transaction interface to monitor and read several event
counters at once. The id
This patch plugs the leak of irq_bitmap, allocated as part of
initialization of cxl_context struct; during the call to
afu_allocate_irqs. The bitmap is now release during the call to function
afu_release_irqs.
Reported-by: Matthew R. Ochs
Signed-off-by: Vaibhav Jain
---
drivers/misc/cxl/irq.c |
On Thu, Aug 13, 2015 at 01:44:43PM -0500, Scott Wood wrote:
> On Thu, 2015-08-13 at 19:51 +0800, Kevin Hao wrote:
> > It makes no sense to put the instructions for calculating the lock
> > value (cpu number + 1) and the clearing of eq bit of cr1 in lbarx/stbcx
> > loop. And when the lock is acquire
On Thu, Aug 13, 2015 at 10:39:19PM -0500, Scott Wood wrote:
> On Thu, 2015-08-13 at 19:51 +0800, Kevin Hao wrote:
> > I didn't find anything unusual. But I think we do need to order the
> > load/store of esel_next when acquire/release tcd lock. For acquire,
> > add a data dependency to order the lo
> -Original Message-
> From: Eduardo Valentin [mailto:edubez...@gmail.com]
> Sent: Friday, August 14, 2015 12:29 PM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
> p...@vger.kernel.org
> Subject: Re: [PATCH V2] QorIQ/TMU: add thermal management sup
On Fri, Aug 14, 2015 at 04:03:19PM +1000, Daniel Axtens wrote:
>In the complete hotplug case, EEH PEs are supposed to be released
>and set to NULL. Normally, this is done by eeh_remove_device(),
>which is called from pcibios_release_device().
>
>However, if something is holding a kref to the device
CXL accelerators are unfortunately not immune from failure. This patch
set enables them to particpate in the Extended Error Handling process.
This series starts with a number of preparatory patches:
- Patch 1 is cleanup: converting macros to static inlines.
- Patch 2 makes sure we don't touch
We're about to make these more complex, so make them functions
first.
Signed-off-by: Daniel Axtens
---
drivers/misc/cxl/cxl.h | 51 ++
1 file changed, 35 insertions(+), 16 deletions(-)
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
i
If the PCI channel has gone down, don't attempt to poke the hardware.
We need to guard every time cxl_whatever_(read|write) is called. This
is because a call to those functions will dereference an offset into an
mmio register, and the mmio mappings get invalidated in the EEH
teardown.
Check in th
Previously the SPA was allocated and freed upon entering and leaving
AFU-directed mode. This causes some issues for error recovery - contexts
hold a pointer inside the SPA, and they may persist after the AFU has
been detached.
We would ideally like to allocate the SPA when the AFU is allocated, an
Check if an IRQ is mapped before releasing it.
This will simplify future EEH code by allowing unconditional unmapping
of IRQs.
Acked-by: Cyril Bur
Signed-off-by: Daniel Axtens
---
drivers/misc/cxl/irq.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/misc/cxl/irq.c b/drive
- MMIO pointer unmapping is guarded by a null pointer check.
However, iounmap doesn't null the pointer, just invalidate it.
Therefore, explicitly null the pointer after unmapping.
- afu_desc_mmio also needs to be unmapped.
- PCI regions are allocated in cxl_map_adapter_regs.
Therefore
Some aspects of initialisation are done only once in the lifetime of
an adapter: for example, allocating memory for the adapter,
allocating the adapter number, or setting up sysfs/debugfs files.
However, we may want to be able to do some parts of the
initialisation multiple times: for example, in
As with an adapter, some aspects of initialisation are done only once
in the lifetime of an AFU: for example, allocating memory, or setting
up sysfs/debugfs files.
However, we may want to be able to do some parts of the initialisation
multiple times: for example, in error recovery we want to be ab
If the driver doesn't participate in EEH, the AFUs will be removed
by cxl_remove, which will be invoked by EEH.
If the driver does particpate in EEH, the vPHB needs to stick around
so that the it can particpate.
In both cases, we shouldn't remove the AFU/vPHB.
Reviewed-by: Cyril Bur
Signed-off-
Provide a kernel API and a sysfs entry which allow a user to specify
that when a card is PERSTed, it's image will stay the same, allowing
it to participate in EEH.
cxl_reset is used to reflash the card. In that case, we cannot safely
assert that the image will not change. Therefore, disallow cxl_r
EEH (Enhanced Error Handling) allows a driver to recover from the
temporary failure of an attached PCI card. Enable basic CXL support
for EEH.
Signed-off-by: Daniel Axtens
---
drivers/misc/cxl/cxl.h | 1 +
drivers/misc/cxl/pci.c | 253
drivers
CONFIG_CXL_EEH is for CXL's EEH related code.
Other drivers can depend on or #ifdef on this symbol to configure
PERST behaviour, allowing CXL to participate in the EEH process.
Reviewed-by: Cyril Bur
Signed-off-by: Daniel Axtens
---
drivers/misc/cxl/Kconfig | 6 ++
1 file changed, 6 insert
> These seem a bit odd here (though perfectly harmless) - not sure these
> need to be done again on recovery (but maybe I'm wrong?) - seems more
> like something that should be done early in cxl_init_adapter?
>
I was really trying to get init to do _only_ things that are once-off
operations. As s
On 08/05/2015 12:38 PM, Gautham R. Shenoy wrote:
> Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
> prescribes that updates to HID0 be preceded by a SYNC instruction and
> followed by an ISYNC instruction (Page 91).
>
> Create an inline function name update_power8_hid0() which
On Tue, 2015-11-08 at 11:23:09 UTC, Andy Shevchenko wrote:
> The derive_parent() has similar semantics to what we have in newly introduced
> of_helpers module. The replacement reduces code base and propagates the actual
> error code to the caller.
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/
I upgraded our kernel for our custom p2010rdb based board from 3.4 to 4.1 and I
cannot get the
PCI controller to work, it is not initialized as can be seem by the below dmesg
fro 3.4 and 4.1.
Sorry to say, PCI is not my cup of tea so I don't not know how to find the
culprit.
I have checked what
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Currently, the PEs and their associated resources are assigned
in ppc_md.pcibios_fixup() except those consumed by SRIOV VFs.
The function is called for once after PCI probing and resources
assignment is finished which isn't hotplug friendly.
The patch cr
Hi Marc,
On Fri, Aug 14, 2015 at 03:41:07PM +0100, Marc Zyngier wrote:
> When find_and_init_phbs() looks for the probe-only property, it seems
> to trust the firmware to be correctly written, and assumes that there
> is a parameter to the property.
>
> It is conceivable that the firmware could no
When pci-host-generic looks for the probe-only property, it seems
to trust the DT to be correctly written, and assumes that there
is a parameter to the property.
Unfortunately, this is not always the case, and some firmware expose
this property naked. The driver ends up making a decision based on
The pci-host-generic driver parses the linux,pci-probe-only property,
and assumes that it will have a boolean parameter.
Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
property, which leads to the driver dereferencing some unsuspecting
memory location. Nothing really bad ha
When find_and_init_phbs() looks for the probe-only property, it seems
to trust the firmware to be correctly written, and assumes that there
is a parameter to the property.
It is conceivable that the firmware could not be that perfect, and it
could expose this property naked (at least one arm64 pla
The linux,pci-probe-only property mandates an argument to indicate
whether or not to engage the "probe-only" mode, but the Seattle
DTS just provides a naked property, which is illegal.
Also, it turns out that the board is perfectly happy without
probe-only, so let's drop this altogether.
Signed-o
Hi Bjorn,
On 14/08/15 15:57, Bjorn Helgaas wrote:
> Hi Marc,
>
> On Fri, Aug 14, 2015 at 03:41:07PM +0100, Marc Zyngier wrote:
>> When find_and_init_phbs() looks for the probe-only property, it seems
>> to trust the firmware to be correctly written, and assumes that there
>> is a parameter to the
On Thu, Aug 13, 2015 at 9:11 PM, David Miller wrote:
> From: James Bottomley
>> At least on some PA architectures, you have to be very careful.
>> Improperly managed, multiple aliases will cause the system to crash
>> (actually a machine check in the cache chequerboard). For the most
>> temperame
Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
to engage the PCI_PROBE_ONLY mode, and both have a subtle bug that
can be triggered if the property has no parameter.
Provide a generic implementation that can be used by both.
Signed-off-by: Marc Zyngier
---
drivers/of/of_pci.c
The pci-host-generic driver parses the linux,pci-probe-only property,
and assumes that it will have a boolean parameter.
Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
property, which leads to the driver dereferencing some unsuspecting
memory location. Nothing really bad ha
When pci-host-generic looks for the probe-only property, it seems
to trust the DT to be correctly written, and assumes that there
is a parameter to the property.
Unfortunately, this is not always the case, and some firmware expose
this property naked. The driver ends up making a decision based on
When find_and_init_phbs() looks for the probe-only property, it seems
to trust the firmware to be correctly written, and assumes that there
is a parameter to the property.
It is conceivable that the firmware could not be that perfect, and it
could expose this property naked (at least one arm64 pla
The linux,pci-probe-only property mandates an argument to indicate
whether or not to engage the "probe-only" mode, but the Seattle
DTS just provides a naked property, which is illegal.
Also, it turns out that the board is perfectly happy without
probe-only, so let's drop this altogether.
Signed-o
On Fri, 2015-08-14 at 13:15 +, Joakim Tjernlund wrote:
> I upgraded our kernel for our custom p2010rdb based board from 3.4 to 4.1 and
> I cannot get the
> PCI controller to work, it is not initialized as can be seem by the below
> dmesg fro 3.4 and 4.1.
> Sorry to say, PCI is not my cup of t
On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
> When pci-host-generic looks for the probe-only property, it seems
> to trust the DT to be correctly written, and assumes that there
> is a parameter to the property.
>
> Unfortunately, this is not always the case, and some firmware ex
On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote:
> On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
> > When pci-host-generic looks for the probe-only property, it seems
> > to trust the DT to be correctly written, and assumes that there
> > is a parameter to the property
On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
> When pci-host-generic looks for the probe-only property, it seems
> to trust the DT to be correctly written, and assumes that there
> is a parameter to the property.
>
> Unfortunately, this is not always the case, and some firmware ex
> On 14.08.2015, at 09:43, Will Deacon wrote:
>
> On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote:
>> On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
>>> When pci-host-generic looks for the probe-only property, it seems
>>> to trust the DT to be correctly written, and
On Thu, 2015-08-13 at 14:20 -0700, Dan Williams wrote:
> On Thu, Aug 13, 2015 at 9:51 AM, Ross Zwisler
> wrote:
> > Update the annotation for the kaddr pointer returned by direct_access()
> > so that it is a __pmem pointer. This is consistent with the PMEM driver
> > and with how this direct_acce
On Fri, Aug 14, 2015 at 9:55 AM, Ross Zwisler
wrote:
> On Thu, 2015-08-13 at 14:20 -0700, Dan Williams wrote:
>> On Thu, Aug 13, 2015 at 9:51 AM, Ross Zwisler
>> wrote:
>> > Update the annotation for the kaddr pointer returned by direct_access()
>> > so that it is a __pmem pointer. This is consi
On Fri, Aug 14, 2015 at 11:43 AM, Will Deacon wrote:
> On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote:
>> On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
>> > When pci-host-generic looks for the probe-only property, it seems
>> > to trust the DT to be correctly written
On Fri, Aug 14, 2015 at 11:19 AM, Marc Zyngier wrote:
> Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
> to engage the PCI_PROBE_ONLY mode, and both have a subtle bug that
> can be triggered if the property has no parameter.
Humm, I bet we could break a lot of machines if we f
Hi Philippe,
I was trying to test Timebase Sync today and realised that it hasn't
been applied to mpe's next tree, and that it no longer applies cleanly.
Would you be able to respin it please?
I also have some minor comments inline.
On Wed, 2015-06-10 at 16:01 +0200, Philippe Bergheaud wrote:
>
On Fri, 2015-08-14 at 15:13 +0800, Kevin Hao wrote:
> On Thu, Aug 13, 2015 at 10:39:19PM -0500, Scott Wood wrote:
> > On Thu, 2015-08-13 at 19:51 +0800, Kevin Hao wrote:
> > > I didn't find anything unusual. But I think we do need to order the
> > > load/store of esel_next when acquire/release tcd
On Fri, 2015-08-14 at 15:13 +0800, Kevin Hao wrote:
> On Thu, Aug 13, 2015 at 01:44:43PM -0500, Scott Wood wrote:
> > On Thu, 2015-08-13 at 19:51 +0800, Kevin Hao wrote:
> > > It makes no sense to put the instructions for calculating the lock
> > > value (cpu number + 1) and the clearing of eq bit
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch intends to add standalone driver to support PCI hotplug
for PowerPC PowerNV platform, which runs on top of skiboot firmware.
The firmware identified hotpluggable slots and marked their device
tree node with proper "ibm,slot-pluggable" and "ibm,r
Dongsheng Wang wrote:
For deep sleep, the diu module will power off, when wake up
from the deep sleep, the registers need to be reinitialized.
Signed-off-by: Jason Jin
Signed-off-by: Wang Dongsheng
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
On Sat, Aug 15, 2015 at 01:13:21PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>The patch intends to add standalone driver to support PCI hotplug
>>for PowerPC PowerNV platform, which runs on top of skiboot firmware.
>>The firmware identified hotpluggable slots an
On Fri, Aug 14, 2015 at 11:52:44PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>Currently, the PEs and their associated resources are assigned
>>in ppc_md.pcibios_fixup() except those consumed by SRIOV VFs.
>>The function is called for once after PCI probing and r
The existing device tree bindings are error-prone and inflexible.
Correct the mistake by moving the knowledge into the driver, which
has more flexibility in describing the quirks of each chip. This leaves
the device tree to its proper role of identifying a programming interface
rather than descri
Get the CPU clock's potential parent clocks from the clock interface
itself, rather than manually parsing the clocks property to find a
phandle, looking at the clock-names property of that, and assuming that
those are valid parent clocks for the cpu clock.
This is necessary for cpufreq to continue
Freescale's Layerscape ARM chips use the same structure.
Signed-off-by: Scott Wood
---
v2: non-RFC
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
arch/powerpc/platforms/85xx/p1022_ds.c
The device tree should describe the chips (or chip-like subblocks) in
the system, but it generally does not describe individual registers --
it should identify, rather than describe, a programming interface.
This has not been the case with the QorIQ clockgen nodes. The
knowledge of what each bit
The clock driver now takes care of ensuring that the mux only
exposes options that are valid. The driver was currently being overly
conservative in some cases -- for example, the "min_cpufreq =
get_bus_freq()" restriction only applies to chips with erratum
A-004510, and whether the freq_mask used
The driver retains compatibility with old device trees, but we don't
want the old nodes lying around to be copied, or used as a reference
(some of the mux options are incorrect), or even just being clutter.
We will also need the #clock-cells in the clockgen node in order to
add fman nodes.
Signed
On Tue, 2015-08-11 at 11:25 -0700, Michael Turquette wrote:
> Hi Scott,
>
> Quoting Scott Wood (2015-06-18 19:49:10)
> > The existing device tree bindings are error-prone and inflexible.
> > Correct the mistake by moving the knowledge into the driver, which
> > has more flexibility in describing
59 matches
Mail list logo
