When we enter into fadump crash path via system reset we fail to update
the pstore.
On the system reset path we first update the pstore then we go for fadump
crash. But the problem here is when all the CPUs try to get the pstore
lock to initiate the pstore write, only one CPUs will acquire the
Gautham R. Shenoy wrote:
From: "Gautham R. Shenoy"
Currently purr, spurr, idle_purr, idle_spurr are exposed for every CPU
via the sysfs interface
/sys/devices/system/cpu/cpuX/[idle_][s]purr. Each sysfs read currently
generates an IPI to obtain the desired value from the target CPU X.
Since
Gautham R. Shenoy wrote:
From: "Gautham R. Shenoy"
Add documentation for the following sysfs interfaces:
/sys/devices/system/cpu/cpuX/purr
/sys/devices/system/cpu/cpuX/spurr
/sys/devices/system/cpu/cpuX/idle_purr
/sys/devices/system/cpu/cpuX/idle_spurr
Signed-off-by: Gautham R. Shenoy
---
Le 01/04/2020 à 11:11, Christophe Leroy a écrit :
Le 01/04/2020 à 10:57, Ravi Bangoria a écrit :
On 4/1/20 12:33 PM, Christophe Leroy wrote:
Le 01/04/2020 à 08:12, Ravi Bangoria a écrit :
Introduce new parameter 'nr' to __set_breakpoint() which indicates
which DAWR should be
Hi Gautham,
Gautham R. Shenoy wrote:
From: "Gautham R. Shenoy"
Currently when CPU goes idle, we take a snapshot of PURR via
pseries_idle_prolog() which is used at the CPU idle exit to compute
the idle PURR cycles via the function pseries_idle_epilog(). Thus,
the value of idle PURR cycle thus
On Tue, Mar 31, 2020 at 09:00:21PM -0300, Leonardo Bras wrote:
> During a crash, there is chance that the cpus that handle the NMI IPI
> are holding a spin_lock. If this spin_lock is needed by crashing_cpu it
> will cause a deadlock. (rtas.lock and printk logbuf_lock as of today)
>
> This is a
On 4/1/20 2:50 PM, Christophe Leroy wrote:
Le 01/04/2020 à 11:13, Ravi Bangoria a écrit :
On 4/1/20 12:20 PM, Christophe Leroy wrote:
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
Currently we assume that we have only one watchpoint supported by hw.
Get rid of that assumption and
Le 01/04/2020 à 11:13, Ravi Bangoria a écrit :
On 4/1/20 12:20 PM, Christophe Leroy wrote:
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
Currently we assume that we have only one watchpoint supported by hw.
Get rid of that assumption and use dynamic loop instead. This should
make
On 4/1/20 12:02 PM, Christophe Leroy wrote:
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
Instead of disabling only one watchpoint, get num of available
watchpoints dynamically and disable all of them.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hw_breakpoint.h | 15
On 4/1/20 12:20 PM, Christophe Leroy wrote:
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
Currently we assume that we have only one watchpoint supported by hw.
Get rid of that assumption and use dynamic loop instead. This should
make supporting more watchpoints very easy.
With more than
Le 01/04/2020 à 10:57, Ravi Bangoria a écrit :
On 4/1/20 12:33 PM, Christophe Leroy wrote:
Le 01/04/2020 à 08:12, Ravi Bangoria a écrit :
Introduce new parameter 'nr' to __set_breakpoint() which indicates
which DAWR should be programed. Also convert current_brk variable
to an array.
> On 20-Mar-2020, at 1:27 AM, Jarkko Sakkinen
> wrote:
>
> On Wed, Mar 18, 2020 at 09:00:17PM -0400, Stefan Berger wrote:
>> From: Stefan Berger
>>
>> This patch fixes the following problem when the ibmvtpm driver
>> is built as a module:
>>
>> ERROR: modpost: "tpm2_get_cc_attrs_tbl"
static void set_debug_reg_defaults(struct thread_struct *thread)
{
- thread->hw_brk.address = 0;
- thread->hw_brk.type = 0;
- thread->hw_brk.len = 0;
- thread->hw_brk.hw_len = 0;
- if (ppc_breakpoint_available())
- set_breakpoint(>hw_brk);
+ int i;
+
+ for (i =
On Wed, Apr 01, 2020 at 04:45:34PM +0800, Shengjiu Wang wrote:
> In order to move common structure to fsl_asrc_common.h
> we change the name of asrc_priv to asrc, the asrc_priv
> will be used by new struct fsl_asrc_priv.
>
> Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
On 4/1/20 12:03 PM, Christophe Leroy wrote:
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
Instead of disabling only first watchpoint, disable all available
watchpoints while clearing dawr_force_enable.
Can you also explain why you change the function name ?
Right. I should have. Will
On 4/1/20 12:33 PM, Christophe Leroy wrote:
Le 01/04/2020 à 08:12, Ravi Bangoria a écrit :
Introduce new parameter 'nr' to __set_breakpoint() which indicates
which DAWR should be programed. Also convert current_brk variable
to an array.
Signed-off-by: Ravi Bangoria
---
EASRC (Enhanced Asynchronous Sample Rate Converter) is a new IP module
found on i.MX8MN. It is different with old ASRC module.
The primary features for the EASRC are as follows:
- 4 Contexts - groups of channels with an independent time base
- Fully independent and concurrent context control
-
EASRC (Enhanced Asynchronous Sample Rate Converter) is a new
IP module found on i.MX8MN.
Signed-off-by: Shengjiu Wang
---
.../devicetree/bindings/sound/fsl,easrc.yaml | 101 ++
1 file changed, 101 insertions(+)
create mode 100644
There is a new ASRC included in i.MX serial platform, there
are some common definition can be shared with each other.
So move the common definition to a separate header file.
And add fsl_asrc_pair_priv and fsl_asrc_priv for
the variable specific for the module, which can be used
internally.
In order to align with new ESARC, we add new property fsl,asrc-format.
The fsl,asrc-format can replace the fsl,asrc-width, driver
can accept format from devicetree, don't need to convert it to
format through width.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 40
In order to align with new ESARC, we add new property fsl,asrc-format.
The fsl,asrc-format can replace the fsl,asrc-width, driver
can accept format from devicetree, don't need to convert it to
format through width.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl-asoc-card.c | 21
In order to support new EASRC and simplify the code structure,
We decide to share the common structure between them. This bring
a problem that EASRC accept format directly from devicetree, but
ASRC accept width from devicetree.
In order to align with new ESARC, we add new property
In order to move common structure to fsl_asrc_common.h
we change the name of asrc_priv to asrc, the asrc_priv
will be used by new struct fsl_asrc_priv.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 298 +--
sound/soc/fsl/fsl_asrc.h | 4 +-
Add new module driver for new ASRC in i.MX8MN, several commits
are added for new property fsl,asrc-format
Shengjiu Wang (7):
ASoC: fsl_asrc: rename asrc_priv to asrc
ASoC: dt-bindings: fsl_asrc: Add new property fsl,asrc-format
ASoC: fsl-asoc-card: Support new property fsl,asrc-format
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> This driver exposes LPC memory on OpenCAPI pmem cards
> as an NVDIMM, allowing the existing nvram infrastructure
> to be used.
>
> Namespace metadata is stored on the media itself, so
> scm_reserve_metadata() maps 1 section's worth of
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> This patch emits a message showing how much LPC memory & special purpose
> memory was detected on an OCXL device.
>
> Signed-off-by: Alastair D'Silva
> Acked-by: Frederic Barrat
> Acked-by: Andrew Donnellan
> ---
>
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> Add functions to map/unmap LPC memory
>
"map memory" is an overloaded term. I'm guessing this patch has
nothing to do with mapping memory in the MMU. Is it updating hardware
resource decoders to start claiming address space that was
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> This patch addresses warnings and errors from the kernel doc scripts for
> the OpenCAPI driver.
>
> It also makes minor tweaks to make the docs more consistent.
>
> Signed-off-by: Alastair D'Silva
> Acked-by: Andrew Donnellan
> ---
>
On Sun, Mar 29, 2020 at 10:53 PM Alastair D'Silva wrote:
>
> OpenCAPI LPC memory is allocated per link, but each link supports
> multiple AFUs, and each AFU can have LPC memory assigned to it.
Is there an OpenCAPI primer to decode these objects and their
associations that I can reference?
>
>
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> Function declarations don't need externs, remove the existing ones
> so they are consistent with newer code
>
> Signed-off-by: Alastair D'Silva
> Acked-by: Andrew Donnellan
> Acked-by: Frederic Barrat
Looks good.
> ---
>
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> This patch adds OPAL calls to powernv so that the OpenCAPI
> driver can map & release LPC (Lowest Point of Coherency) memory.
>
> Signed-off-by: Alastair D'Silva
> Reviewed-by: Andrew Donnellan
> ---
>
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> When setting up OpenCAPI connected persistent memory, the range check may
> not be performed until quite late (or perhaps not at all, if the user does
> not establish a DAX device).
>
> This patch makes the range check callable so we
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> Add OPAL calls for LPC memory alloc/release
>
This seems to be referencing an existing api definition, can you
include a pointer to the spec in case someone wanted to understand
what these routines do? I suspect this is not allocating
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> This series adds support for OpenCAPI Persistent Memory devices on bare metal
> (arch/powernv), exposing them as nvdimms so that we can make use of the
> existing infrastructure. There already exists a driver for the same devices
>
Hi,
On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote:
> On 04/01/20 at 12:56am, Mike Rapoport wrote:
> > On Mon, Mar 30, 2020 at 11:58:43AM +0200, Michal Hocko wrote:
> > >
> > > What would it take to make ia64 use HAVE_MEMBLOCK_NODE_MAP? I would
> > > really love to see that thing go
Subscribe to the MCE notification and add the physical address which
generated a memory error to nvdimm bad range.
Signed-off-by: Santosh Sivaraj
---
This patch depends on "powerpc/mce: Add MCE notification chain" [1].
Unlike the previous series[2], the patch adds badblock registration only
Le 01/04/2020 à 08:50, Ravi Bangoria a écrit :
On 4/1/20 11:59 AM, Christophe Leroy wrote:
Le 01/04/2020 à 08:12, Ravi Bangoria a écrit :
So far we had only one watchpoint, so we have hardcoded HBP_NUM to 1.
But future Power architecture is introducing 2nd DAWR and thus kernel
should be
Le 01/04/2020 à 08:12, Ravi Bangoria a écrit :
Introduce new parameter 'nr' to __set_breakpoint() which indicates
which DAWR should be programed. Also convert current_brk variable
to an array.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/debug.h | 2 +-
Le 01/04/2020 à 08:12, Ravi Bangoria a écrit :
Introduce new parameter 'nr' to set_dawr() which indicates which DAWR
should be programed.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hw_breakpoint.h | 4 ++--
arch/powerpc/kernel/dawr.c | 15 ++-
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
With Book3s DAWR, ptrace and perf watchpoints on powerpc behaves
differently. Ptrace watchpoint works in one-shot mode and generates
signal before executing instruction. It's ptrace user's job to
single-step the instruction and re-enable the
On 4/1/20 11:59 AM, Christophe Leroy wrote:
Le 01/04/2020 à 08:12, Ravi Bangoria a écrit :
So far we had only one watchpoint, so we have hardcoded HBP_NUM to 1.
But future Power architecture is introducing 2nd DAWR and thus kernel
should be able to dynamically find actual number of
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
Currently we assume that we have only one watchpoint supported by hw.
Get rid of that assumption and use dynamic loop instead. This should
make supporting more watchpoints very easy.
With more than one watchpoint, exception handler need to know
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
So far powerpc hw supported only one watchpoint. But Future Power
architecture is introducing 2nd DAWR. Convert thread_struct->hw_brk
into an array.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/processor.h | 2 +-
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
Instead of disabling only first watchpoint, disable all available
watchpoints while clearing dawr_force_enable.
Can you also explain why you change the function name ?
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/dawr.c | 10
Le 01/04/2020 à 08:13, Ravi Bangoria a écrit :
Instead of disabling only one watchpoint, get num of available
watchpoints dynamically and disable all of them.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hw_breakpoint.h | 15 +++
1 file changed, 7 insertions(+),
Le 01/04/2020 à 08:12, Ravi Bangoria a écrit :
So far we had only one watchpoint, so we have hardcoded HBP_NUM to 1.
But future Power architecture is introducing 2nd DAWR and thus kernel
should be able to dynamically find actual number of watchpoints
supported by hw it's running on. Introduce
Add support for 2nd DAWR in xmon. With this, we can have two
simultaneous breakpoints from xmon.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/xmon/xmon.c | 101 ++-
1 file changed, 69 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c
Xmon allows overwriting breakpoints because it's supported by only
one dawr. But with multiple dawrs, overwriting becomes ambiguous
or unnecessary complicated. So let's not allow it.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/xmon/xmon.c | 4
1 file changed, 4 insertions(+)
diff --git
With Book3s DAWR, ptrace and perf watchpoints on powerpc behaves
differently. Ptrace watchpoint works in one-shot mode and generates
signal before executing instruction. It's ptrace user's job to
single-step the instruction and re-enable the watchpoint. OTOH, in
case of perf watchpoint, kernel
Currently we assume that we have only one watchpoint supported by hw.
Get rid of that assumption and use dynamic loop instead. This should
make supporting more watchpoints very easy.
With more than one watchpoint, exception handler need to know which
DAWR caused the exception, and hw currently
Currently we calculate hw aligned start and end addresses manually.
Replace them with builtin ALIGN_DOWN() and ALIGN() macros.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
arch/powerpc/kernel/hw_breakpoint.c | 6 +++---
Introduce is_ptrace_bp() function and move the check inside the
function. We will utilize it more in later set of patches.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/hw_breakpoint.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
ptrace_bps is already an array of size HBP_NUM_MAX. But we use
hardcoded index 0 while fetching/updating it. Convert such code
to loop over array.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/hw_breakpoint.c | 7 --
arch/powerpc/kernel/process.c | 6 -
So far powerpc hw supported only one watchpoint. But Future Power
architecture is introducing 2nd DAWR. Convert thread_struct->hw_brk
into an array.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/processor.h | 2 +-
arch/powerpc/kernel/process.c | 61
Instead of disabling only first watchpoint, disable all available
watchpoints while clearing dawr_force_enable.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/dawr.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dawr.c
Instead of disabling only one watchpoint, get num of available
watchpoints dynamically and disable all of them.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hw_breakpoint.h | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git
Introduce new parameter 'nr' to __set_breakpoint() which indicates
which DAWR should be programed. Also convert current_brk variable
to an array.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/debug.h | 2 +-
arch/powerpc/include/asm/hw_breakpoint.h | 2 +-
Introduce new parameter 'nr' to set_dawr() which indicates which DAWR
should be programed.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hw_breakpoint.h | 4 ++--
arch/powerpc/kernel/dawr.c | 15 ++-
arch/powerpc/kernel/process.c| 2 +-
3
User can ask for num of available watchpoints(dbginfo.num_data_bps)
using ptrace(PPC_PTRACE_GETHWDBGINFO). Return actual number of
available watchpoints on the machine rather than hardcoded 1.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 +-
1 file changed, 1
So far we had only one watchpoint, so we have hardcoded HBP_NUM to 1.
But future Power architecture is introducing 2nd DAWR and thus kernel
should be able to dynamically find actual number of watchpoints
supported by hw it's running on. Introduce function for the same.
Also convert HBP_NUM macro
Future Power architecture is introducing second DAWR. Add SPRN_ macros
for the same.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/reg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index
Future Power architecture is introducing second DAWR. Use real
register names from ISA for current macros:
s/SPRN_DAWR/SPRN_DAWR0/
s/SPRN_DAWRX/SPRN_DAWRX0/
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/reg.h | 4 ++--
arch/powerpc/kernel/dawr.c | 4 ++--
So far, powerpc Book3S code has been written with an assumption of only
one watchpoint. But future power architecture is introducing second
watchpoint register (DAWR). Even though this patchset does not enable
2nd DAWR, it make the infrastructure ready so that enabling 2nd DAWR
should just be a
On 01. 04. 20 4:07, Michael Ellerman wrote:
> Michal Simek writes:
>> Hi,
>>
>> recently we wanted to update xilinx intc driver and we found that function
>> which we wanted to remove is still wired by ancient Xilinx PowerPC
>> platforms. Here is the thread about it.
>>
101 - 164 of 164 matches
Mail list logo
