On Thu, Mar 26, 2015 at 04:42:07PM +1100, Gavin Shan wrote:
> There are two equivalent sets of PE state constants, defined in
> arch/powerpc/include/asm/eeh.h and include/uapi/linux/vfio.h.
> Though the names are different, their corresponding values are
> exactly same. The former is used by EEH co
Cedric Le Goater writes:
> The sensor service in OPAL only handles one FSP request at a time and
> returns OPAL_BUSY if one is already in progress. The lock covers this case
> but we could also remove it return EBUSY to the driver or even retry the
> call. That might be dangerous though.
Retr
If M64 has been supported, the prefetchable 64-bits memory resources
shouldn't be mapped to the corresponding PE# via M32DT. Unfortunately,
we're doing that in pnv_ioda_setup_pe_seg() wrongly. The issue was
introduced by commit 262af55 ("powerpc/powernv: Enable M64 aperatus
for PHB3"). The patch fi
The function eeh_add_parent_pe() is used to create a PE or add one
edev to its parent PE. Current code checks if PE#0 is valid for the
later case. Actually, we should validate PE#0 for both cases when
EEH core regards PE#0 as invalid one (without flag EEH_VALID_PE_ZERO).
Otherwise, not all EEH devi
On Thu, 2015-03-26 at 16:00 -0700, David Miller wrote:
> From: casca...@linux.vnet.ibm.com
> Date: Wed, 25 Mar 2015 21:43:42 -0300
>
> > On Mon, Mar 23, 2015 at 10:15:08PM -0400, David Miller wrote:
> >> From: Benjamin Herrenschmidt
> >> Date: Tue, 24 Mar 2015 13:08:10 +1100
> >>
> >> > For the
On Thu, 2015-03-26 at 10:31 -0500, Emil Medve wrote:
> Hello Kumar,
>
>
> On 03/26/2015 10:18 AM, Kumar Gala wrote:
> > Why no commit message with what issue this change was trying to fix?
>
> A while back, when I attempted to remove bootmem (in favor of just plain
> memblock as in powerpc land
On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt wrote:
>
> > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > > * Ingo Molnar wrote:
> > >
> > > > > +#define __HAVE_ARCH_REMAP
> > > > > +static inline void arch_remap(struct mm_struct *mm,
> > > > > +
On Thu, 2015-03-26 at 12:49 -0700, Dave Olson wrote:
> Michael Ellerman wrote:
>
> > On Thu, 2015-26-02 at 00:04:47 UTC, Dave Olson wrote:
> > > @@ -324,14 +335,33 @@ static bool cache_node_is_unified(const struct
> > > device_node *np)
> > > return of_get_property(np, "cache-unified", NULL);
From: casca...@linux.vnet.ibm.com
Date: Wed, 25 Mar 2015 21:43:42 -0300
> On Mon, Mar 23, 2015 at 10:15:08PM -0400, David Miller wrote:
>> From: Benjamin Herrenschmidt
>> Date: Tue, 24 Mar 2015 13:08:10 +1100
>>
>> > For the large pool, we don't keep a hint so we don't know it's
>> > wrapped, in
On Thu, 2015-03-26 at 17:15 +0800, ying.zh...@freescale.com wrote:
> From: Ying Zhang
>
> Create the dts files for each core and splits the devices between
> the two cores for P1021RDB-PC.
>
> Core0 has l2, serial0, i2c, spi, gpio, tdm,dma, usb, eth0, eth1,
> sdhc, crypto, global-util, message,
On Thu, 2015-03-26 at 17:14 +0800, ying.zh...@freescale.com wrote:
> From: Ying Zhang
>
> The dts file support QE-TDM function and PQ-MDS-T1 card for P1021RDB.
> PQ-MDS-T1 is connected to the board by PMC, there is a zarlink le88266
> on the card, we configure it by QE-SPI. Because PMC has a shar
On Tue, Feb 03, 2015 at 12:38:16PM +0100, LEROY Christophe wrote:
> Since commit 33fb845a6f01 ("powerpc/8xx: Don't use MD_TWC for walk"), MD_EPN
> and
> MD_TWC are not writen anymore in FixupDAR so saving r3 has become useless.
>
> Signed-off-by: Christophe Leroy
> ---
> v2: no change
> v3: no c
On Thu, 2015-03-26 at 17:23 +0100, Thomas Haschka wrote:
> Hello,
>
> Here's an updated version taking your suggested changements into account
> (merged the two loops into one, changed a hardcoded value into a constant).
Can you still move the core of the loop into a helper function ? There
is st
Commit bb344ca5b90df6 ("powerpc/mpc85xx: Add ranges to etsec2 nodes")
fixes a bug that was exposed by commit 746c9e9f92dd ("of/base: Fix
PowerPC address parsing hack"). The latter commit was applied to stable
trees, so the former should be as well.
-Scott
Michael Ellerman wrote:
> On Thu, 2015-26-02 at 00:04:47 UTC, Dave Olson wrote:
> > @@ -324,14 +335,33 @@ static bool cache_node_is_unified(const struct
> > device_node *np)
> > return of_get_property(np, "cache-unified", NULL);
> > }
> >
> > +/*
> > + * Handle unified caches that have tw
* Laurent Dufour wrote:
> +{
> + unsigned long vdso_end, vdso_start;
> +
> + if (!mm->context.vdso_base)
> + return;
> + vdso_start = mm->context.vdso_base;
> +
> +#ifdef CONFIG_PPC64
> + /* Calling is_32bit_task() implies that we are dealing with the
> + * curre
CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.
However some architectures like powerpc are keeping a reference to the vDSO
base address to build th
Some architecture would like to be triggered when a memory area is moved
through the mremap system call.
This patch is introducing a new arch_remap mm hook which is placed in the
path of mremap, and is called before the old area is unmapped (and the
arch_unmap hook is called).
The architectures w
Some processes (CRIU) are moving the vDSO area using the mremap system
call. As a consequence the kernel reference to the vDSO base address is
no more valid and the signal return frame built once the vDSO has been
moved is not pointing to the new sigreturn address.
This patch handles vDSO remappin
Hello,
Here's an updated version taking your suggested changements into account
(merged the two loops into one, changed a hardcoded value into a constant).
Just to keep everything together, here are the changements:
1. changes in sensors limits, we are down from 70, 50, 70
to 45, 50, 70, whe
OPAL has its own list of return codes. The patch provides a translation
of such codes in errnos for the opal_sensor_read call.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/opal-sensor.c | 37 ++-
1 file changed, 36 insertions(+), 1 deletion(-)
Ind
Currently, when a sensor value is read, the kernel calls OPAL, which in
turn builds a message for the FSP, and waits for a message back.
The new device tree for OPAL sensors [1] adds new sensors that can be
read synchronously (core temperatures for instance) and that don't need
to wait for a re
The opal sensor mutex protects the opal_sensor_read call which
can return a OPAL_BUSY code on IBM Power systems if a previous
request is in progress.
This can be handled at user level with a retry.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/opal-sensor.c |5 -
1
Hello Kumar,
On 03/26/2015 10:18 AM, Kumar Gala wrote:
> Why no commit message with what issue this change was trying to fix?
A while back, when I attempted to remove bootmem (in favor of just plain
memblock as in powerpc land bootmem was just a wrapper to memblock
anyway) I run at some point in
Why no commit message with what issue this change was trying to fix?
- k
On Mar 25, 2015, at 8:49 AM, Emil Medve wrote:
> Signed-off-by: Emil Medve
> ---
>
> v3: Rebased and updated due to upstream changes since v2
>
> v2: Rebased and updated due to upstream changes since v1
>
> arch/powerp
On 26/03/2015 15:17, Ingo Molnar wrote:
>
> * Laurent Dufour wrote:
>
>>> I argue we should use the right condition to clear vdso_base: if
>>> the vDSO gets at least partially unmapped. Otherwise there's
>>> little point in the whole patch: either correctly track whether
>>> the vDSO is OK, o
* Laurent Dufour wrote:
> > I argue we should use the right condition to clear vdso_base: if
> > the vDSO gets at least partially unmapped. Otherwise there's
> > little point in the whole patch: either correctly track whether
> > the vDSO is OK, or don't ...
>
> That's a good option, but it
We can disable a THP split or a hugepage collapse by disabling irq.
We do send IPI to all the cpus in the early part of split/collapse,
and disabling local irq ensure we don't make progress with
split/collapse. If the THP is getting split we return NULL from
find_linux_pte_or_hugepte(). For all the
For THP that is marked trans splitting, we return the pte.
This require the callers to handle the pmd_trans_splitting scenario,
if they care. All the current callers are either looking at pfn or
write_ok, hence we don't need to update them.
Signed-off-by: Aneesh Kumar K.V
---
Changes from V3:
* A
This patch remove helpers which we had used only once in the code.
Limiting page table walk variants help in ensuring that we won't
end up with code walking page table with wrong assumptions.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/pgtable.h | 21 -
arch/powerpc
pte can get updated from other CPUs as part of multiple activities
like THP split, huge page collapse, unmap. We need to make sure we
don't reload the pte value again and again for different checks.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s_64.h | 5 -
arch/pow
On 03/26/2015 10:44 AM, Cedric Le Goater wrote:
> On 03/26/2015 12:07 AM, Stewart Smith wrote:
>> Cédric Le Goater writes:
>>> Currently, when a sensor value is read, the kernel calls OPAL, which in
>>> turn builds a message for the FSP, and waits for a message back.
>>>
>>> The new device tree f
From: Ying Zhang
The dts file support QE-TDM function and PQ-MDS-T1 card for P1021RDB.
PQ-MDS-T1 is connected to the board by PMC, there is a zarlink le88266
on the card, we configure it by QE-SPI. Because PMC has a shared CS pin
with L2switch, so we do the device tree fixup in uboot.
Change-Id:
From: Ying Zhang
Create the dts files for each core and splits the devices between
the two cores for P1021RDB-PC.
Core0 has l2, serial0, i2c, spi, gpio, tdm,dma, usb, eth0, eth1,
sdhc, crypto, global-util, message, pci0, pci1, msi, crypto.
Core1 has l2, serial1, eth2.
Signed-off-by: Ying Zhang
From: Ying Zhang
The P1021RDB-PC have PMC sockets that support QE-TDM function.
The patch enable Quicc Engine and the related signals of QE-TDM.
Signed-off-by: Ying Zhang
Signed-off-by: Xie Xiaobo
Signed-off-by: Li Yang
---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 76
On (03/25/15 21:43), casca...@linux.vnet.ibm.com wrote:
> However, when using large TCP send/recv (I used uperf with 64KB
> writes/reads), I noticed that on the transmit side, largealloc is not
> used, but on the receive side, cxgb4 almost only uses largealloc, while
> qlge seems to have a 1/1 usag
Implemented CPU hotplug on e500mc, e5500 and e6500, and support
multiple threads mode and 64-bits mode.
For e6500 with two threads, if one thread is online, it can
enable/disable the other thread in the same core. If two threads of
one core are offline, the core will enter the PH20 state (a low po
There is a RCPM (Run Control/Power Management) in Freescale QorIQ
series processors. The device performs tasks associated with device
run control and power management.
The driver implements some features: mask/unmask irq, enter/exit low
power states, freeze time base, etc.
Signed-off-by: Chenhui
In sleep mode, the clocks of e500 cores and unused IP blocks is
turned off. The IP blocks which are allowed to wake up the processor
are still running.
The sleep mode is equal to the Standby state in Linux. Use the
command to enter sleep mode:
echo standby > /sys/power/state
Signed-off-by: Chen
Fix the attribute name of the configuration record class ID.
Signed-off-by: Philippe Bergheaud
---
Documentation/ABI/testing/sysfs-class-cxl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-class-cxl
b/Documentation/ABI/testing/sysfs-class-cxl
On 26/03/2015 10:43, Ingo Molnar wrote:
>
> * Benjamin Herrenschmidt wrote:
>
>> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
>>> * Ingo Molnar wrote:
>>>
> +#define __HAVE_ARCH_REMAP
> +static inline void arch_remap(struct mm_struct *mm,
> + unsigned
Various e500 core have different cache architecture, so they
need different cache flush operations. Therefore, add a callback
function cpu_flush_caches to the struct cpu_spec. The cache flush
operation for the specific kind of e500 is selected at init time.
The callback function will flush all cach
On 26/03/2015 10:48, Ingo Molnar wrote:
>
> * Benjamin Herrenschmidt wrote:
>
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+unsigned long old_start, unsigned long old_end,
+unsigned long new_st
* Benjamin Herrenschmidt wrote:
> > > +#define __HAVE_ARCH_REMAP
> > > +static inline void arch_remap(struct mm_struct *mm,
> > > + unsigned long old_start, unsigned long old_end,
> > > + unsigned long new_start, unsigned long new_end)
> > > +{
> > > +
On 03/26/2015 12:07 AM, Stewart Smith wrote:
> Cédric Le Goater writes:
>> Currently, when a sensor value is read, the kernel calls OPAL, which in
>> turn builds a message for the FSP, and waits for a message back.
>>
>> The new device tree for OPAL sensors [1] adds new sensors that can be
>> re
* Benjamin Herrenschmidt wrote:
> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > * Ingo Molnar wrote:
> >
> > > > +#define __HAVE_ARCH_REMAP
> > > > +static inline void arch_remap(struct mm_struct *mm,
> > > > + unsigned long old_start, unsigned long
> >
46 matches
Mail list logo