* Re: [PATCH v2 1/2] printk: Add function to return log buffer address and size
From: Andrew Morton @ 2014-08-01 20:54 UTC (permalink / raw)
To: Vasant Hegde; +Cc: Linus Torvalds, linuxppc-dev, linux-kernel
In-Reply-To: <20140731102920.27954.25076.stgit@hegdevasant.in.ibm.com>
On Thu, 31 Jul 2014 16:00:06 +0530 Vasant Hegde <hegdevasant@linux.vnet.ibm.com> wrote:
> Platforms like IBM Power Systems supports service processor
> assisted dump. It provides interface to add memory region to
> be captured when system is crashed.
>
> During initialization/running we can add kernel memory region
> to be collected.
>
> Presently we don't have a way to get the log buffer base address
> and size. This patch adds support to return log buffer address
> and size.
>
> ...
>
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -10,6 +10,9 @@
> extern const char linux_banner[];
> extern const char linux_proc_banner[];
>
> +extern void *get_log_buf_addr(void);
> +extern u32 get_log_buf_len(void);
> +
> static inline int printk_get_level(const char *buffer)
> {
> if (buffer[0] == KERN_SOH_ASCII && buffer[1]) {
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 13e839d..4049f7b 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -270,6 +270,18 @@ static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
> static char *log_buf = __log_buf;
> static u32 log_buf_len = __LOG_BUF_LEN;
>
> +/* Return log buffer address */
> +void *get_log_buf_addr(void)
> +{
> + return log_buf;
> +}
> +
> +/* Return log buffer size */
> +u32 get_log_buf_len(void)
> +{
> + return log_buf_len;
> +}
> +
This is the v1 patch. The names are the same and get_log_buf_addr() still
returns void*.
^ permalink raw reply
* Pull request: scottwood/linux.git next
From: Scott Wood @ 2014-08-01 19:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Highlights include e6500 hardware threading support, an e6500 TLB erratum
workaround, corenet error reporting, support for a new board, and some
minor fixes.
The following changes since commit cd1154770ba984f4c766cac5ea42c38880080b1d:
powerpc/85xx: drop hypervisor specific board compatibles (2014-07-02 17:33:10 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to 78eb9094ca08a40b8f9d3e113a2b88e0b7dbad1d:
powerpc/t2080rdb: Add T2080RDB board support (2014-07-31 00:11:10 -0500)
----------------------------------------------------------------
Andy Fleming (1):
powerpc/e6500: Add support for hardware threads
Himangi Saraogi (2):
powerpc/mpic_msgr: Use kcalloc and correct the argument to sizeof
powerpc/fsl-pci: Correct use of ! and &
Priyanka Jain (1):
powerpc/85xx: Add binding for CPLD
Scott Wood (3):
powerpc/booke: Define MSR bits the same way as reg.h
powerpc/e6500: Work around erratum A-008139
memory: Freescale CoreNet Coherency Fabric error reporting driver
Shengzhou Liu (1):
powerpc/t2080rdb: Add T2080RDB board support
.../devicetree/bindings/powerpc/fsl/board.txt | 16 ++
arch/powerpc/boot/dts/t2080rdb.dts | 57 +++++
arch/powerpc/boot/dts/t208xrdb.dtsi | 184 +++++++++++++++
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
arch/powerpc/include/asm/cputable.h | 2 +-
arch/powerpc/include/asm/ppc-opcode.h | 9 +
arch/powerpc/include/asm/reg_booke.h | 55 ++++-
arch/powerpc/kernel/head_64.S | 22 ++
arch/powerpc/kernel/prom.c | 10 +-
arch/powerpc/kernel/setup-common.c | 6 +-
arch/powerpc/kernel/setup_64.c | 6 +-
arch/powerpc/mm/tlb_low_64e.S | 68 +++++-
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 1 +
arch/powerpc/platforms/85xx/smp.c | 44 ++++
arch/powerpc/sysdev/fsl_pci.c | 4 +-
arch/powerpc/sysdev/mpic_msgr.c | 2 +-
drivers/memory/Kconfig | 10 +
drivers/memory/Makefile | 1 +
drivers/memory/fsl-corenet-cf.c | 251 +++++++++++++++++++++
21 files changed, 717 insertions(+), 35 deletions(-)
create mode 100644 arch/powerpc/boot/dts/t2080rdb.dts
create mode 100644 arch/powerpc/boot/dts/t208xrdb.dtsi
create mode 100644 drivers/memory/fsl-corenet-cf.c
^ permalink raw reply
* Re: [PATCH] powerpc: fixing endianness of flash_block_list in rtas_flash
From: Thomas Falcon @ 2014-08-01 17:07 UTC (permalink / raw)
To: Vasant Hegde, linuxppc-dev
In-Reply-To: <53DB5EC5.5000703@linux.vnet.ibm.com>
On 08/01/2014 04:32 AM, Vasant Hegde wrote:
> On 07/25/2014 11:17 PM, Thomas Falcon wrote:
>> The function rtas_flash_firmware passes the address of a data structure,
>> flash_block_list, when making the update-flash-64-and-reboot rtas call.
>> While the endianness of the address is handled correctly, the endianness
>> of the data is not. This patch ensures that the data in
>> flash_block_list
>> is big endian when passed to rtas on little endian hosts.
>>
>> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/kernel/rtas_flash.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>
> Tom,
>
> In validate_flash rtas call returns update_results in BE.. I think we
> need below changes as well.
>
> Rest looks good.
>
> diff --git a/arch/powerpc/kernel/rtas_flash.c
> b/arch/powerpc/kernel/rtas_flash.c
> index db2b482..1eae0d8 100644
> --- a/arch/powerpc/kernel/rtas_flash.c
> +++ b/arch/powerpc/kernel/rtas_flash.c
> @@ -449,7 +449,7 @@ error:
> static void validate_flash(struct rtas_validate_flash_t *args_buf)
> {
> int token = rtas_token("ibm,validate-flash-image");
> - int update_results;
> + __be32 update_results;
> s32 rc;
>
> rc = 0;
> @@ -463,7 +463,7 @@ static void validate_flash(struct
> rtas_validate_flash_t *args_buf)
> } while (rtas_busy_delay(rc));
>
> args_buf->status = rc;
> - args_buf->update_results = update_results;
> + args_buf->update_results = be32_to_cpu(update_results);
> }
>
I do not think this conversion is needed. Any integers returned are
converted to cpu endian in the rtas_call function.
tom
>
> -Vasant
>
--
^ permalink raw reply
* Re: [PATCH] powerpc: fixing endianness of flash_block_list in rtas_flash
From: Vasant Hegde @ 2014-08-01 9:32 UTC (permalink / raw)
To: Thomas Falcon, linuxppc-dev
In-Reply-To: <1406310462-23005-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
On 07/25/2014 11:17 PM, Thomas Falcon wrote:
> The function rtas_flash_firmware passes the address of a data structure,
> flash_block_list, when making the update-flash-64-and-reboot rtas call.
> While the endianness of the address is handled correctly, the endianness
> of the data is not. This patch ensures that the data in flash_block_list
> is big endian when passed to rtas on little endian hosts.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/rtas_flash.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
Tom,
In validate_flash rtas call returns update_results in BE.. I think we need
below changes as well.
Rest looks good.
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index db2b482..1eae0d8 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -449,7 +449,7 @@ error:
static void validate_flash(struct rtas_validate_flash_t *args_buf)
{
int token = rtas_token("ibm,validate-flash-image");
- int update_results;
+ __be32 update_results;
s32 rc;
rc = 0;
@@ -463,7 +463,7 @@ static void validate_flash(struct rtas_validate_flash_t
*args_buf)
} while (rtas_busy_delay(rc));
args_buf->status = rc;
- args_buf->update_results = update_results;
+ args_buf->update_results = be32_to_cpu(update_results);
}
-Vasant
^ permalink raw reply related
* Re: [PATCH v2 1/2] printk: Add function to return log buffer address and size
From: Vasant Hegde @ 2014-08-01 8:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, linuxppc-dev, linux-kernel
In-Reply-To: <20140731152255.37e675870dfdf77d9dbaff70@linux-foundation.org>
On 08/01/2014 03:52 AM, Andrew Morton wrote:
> On Thu, 31 Jul 2014 21:05:48 +0530 Vasant Hegde <hegdevasant@linux.vnet.ibm.com> wrote:
>
>> Platforms like IBM Power Systems supports service processor
>> assisted dump. It provides interface to add memory region to
>> be captured when system is crashed.
>>
>> During initialization/running we can add kernel memory region
>> to be collected.
>>
>> Presently we don't have a way to get the log buffer base address
>> and size. This patch adds support to return log buffer address
>> and size.
>>
>> ...
>>
>> --- a/include/linux/printk.h
>> +++ b/include/linux/printk.h
>> @@ -10,6 +10,9 @@
>> extern const char linux_banner[];
>> extern const char linux_proc_banner[];
>>
>> +extern void *get_log_buf_addr(void);
>> +extern u32 get_log_buf_len(void);
>> +
>> static inline int printk_get_level(const char *buffer)
>> {
>> if (buffer[0] == KERN_SOH_ASCII && buffer[1]) {
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index 13e839d..4049f7b 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -270,6 +270,18 @@ static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
>> static char *log_buf = __log_buf;
>> static u32 log_buf_len = __LOG_BUF_LEN;
>>
>> +/* Return log buffer address */
>> +void *get_log_buf_addr(void)
>> +{
>> + return log_buf;
>> +}
>> +
>> +/* Return log buffer size */
>> +u32 get_log_buf_len(void)
>> +{
>> + return log_buf_len;
>> +}
>> +
>> /* human readable text of the record */
>> static char *log_text(const struct printk_log *msg)
>> {
>
Andrew,
Thanks for the review.. Shall I add your Ack?
> Looks OK to me, although I think log_buf_addr_get() and
> log_buf_len_get() would be better names. The kernel uses some
> big-endian names and some little-endian-names and some middle-endian
> names. It's all rather a mess. These symbols are already big-endian
> (ie: decreasing significance):
>
> log_buf -> addr -> get
> log_buf -> len -> get
Sure . Will rename function as above.
>
>
> The world wouldn't end if we simply made log_buf and log_buf_len global
> symbols. The pros and cons are all minor.
>
> It's probably better to make get_log_buf_addr() tell the truth and
> return a char *.
>
>
> Please include this in whatever tree carries "powerpc/powernv:
> Interface to register/unregister opal dump region".
Sure.. Will work with BenH.
-Vasant
^ permalink raw reply
* [PATCH v3] powerpc/kvm: support to handle sw breakpoint
From: Madhavan Srinivasan @ 2014-08-01 4:50 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: Madhavan Srinivasan, linuxppc-dev, kvm-ppc, kvm
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation Assistance interrupt, where we check for the illegal instruction
and accordingly we return to Host or Guest. Patch also adds support for
software breakpoint in PR KVM.
Changes v2->v3:
Changed the debug instructions. Using the all zero opcode in the instruction word
as illegal instruction as mentioned in Power ISA instead of ABS
Removed reg updated in emulation assist and added a call to
kvmppc_emulate_instruction for reg update.
Changes v1->v2:
Moved the debug instruction #def to kvm_book3s.h. This way PR_KVM can also share it.
Added code to use KVM get one reg infrastructure to get debug opcode.
Updated emulate.c to include emulation of debug instruction incase of PR_KVM.
Made changes to commit message.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/kvm_book3s.h | 7 +++++++
arch/powerpc/include/asm/ppc-opcode.h | 5 +++++
arch/powerpc/kvm/book3s.c | 3 ++-
arch/powerpc/kvm/book3s_hv.c | 12 ++++++++++--
arch/powerpc/kvm/book3s_pr.c | 3 +++
arch/powerpc/kvm/emulate.c | 9 +++++++++
6 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index f52f656..f17e3fd 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -24,6 +24,13 @@
#include <linux/kvm_host.h>
#include <asm/kvm_book3s_asm.h>
+/*
+ * KVMPPC_INST_BOOK3S_DEBUG is debug Instruction for supporting Software Breakpoint.
+ * Based on PowerISA v2.07, Instruction with opcode 0s will be treated as illegal
+ * instruction.
+ */
+#define KVMPPC_INST_BOOK3S_DEBUG 0x00dddd00
+
struct kvmppc_bat {
u64 raw;
u32 bepi;
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 3132bb9..56739b3 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -111,6 +111,11 @@
#define OP_31_XOP_LHBRX 790
#define OP_31_XOP_STHBRX 918
+/* KVMPPC_INST_BOOK3S_DEBUG -- Software breakpoint Instruction
+ * 0x00dddd00 -- Primary opcode is 0s
+ */
+#define OP_ZERO 0x0
+
#define OP_LWZ 32
#define OP_LD 58
#define OP_LWZU 33
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index c254c27..b40fe5d 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -789,7 +789,8 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
struct kvm_guest_debug *dbg)
{
- return -EINVAL;
+ vcpu->guest_debug = dbg->control;
+ return 0;
}
void kvmppc_decrementer_func(unsigned long data)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 7a12edb..7c16f4f 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -725,8 +725,13 @@ static int kvmppc_handle_exit_hv(struct kvm_run *run, struct kvm_vcpu *vcpu,
* we don't emulate any guest instructions at this stage.
*/
case BOOK3S_INTERRUPT_H_EMUL_ASSIST:
- kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
- r = RESUME_GUEST;
+ if (kvmppc_get_last_inst(vcpu) == KVMPPC_INST_BOOK3S_DEBUG) {
+ kvmppc_emulate_instruction(run, vcpu);
+ r = RESUME_HOST;
+ } else {
+ kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
+ r = RESUME_GUEST;
+ }
break;
/*
* This occurs if the guest (kernel or userspace), does something that
@@ -831,6 +836,9 @@ static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
long int i;
switch (id) {
+ case KVM_REG_PPC_DEBUG_INST:
+ *val = get_reg_val(id, KVMPPC_INST_BOOK3S_DEBUG);
+ break;
case KVM_REG_PPC_HIOR:
*val = get_reg_val(id, 0);
break;
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 8eef1e5..27f5234 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1229,6 +1229,9 @@ static int kvmppc_get_one_reg_pr(struct kvm_vcpu *vcpu, u64 id,
int r = 0;
switch (id) {
+ case KVM_REG_PPC_DEBUG_INST:
+ *val = get_reg_val(id, KVMPPC_INST_BOOK3S_DEBUG);
+ break;
case KVM_REG_PPC_HIOR:
*val = get_reg_val(id, to_book3s(vcpu)->hior);
break;
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index da86d9b..d95014e 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -458,6 +458,15 @@ int kvmppc_emulate_instruction(struct kvm_run *run, struct kvm_vcpu *vcpu)
kvmppc_set_gpr(vcpu, ra, vcpu->arch.vaddr_accessed);
break;
+ case OP_ZERO:
+ if((inst & 0x00FFFF00) == KVMPPC_INST_BOOK3S_DEBUG) {
+ run->exit_reason = KVM_EXIT_DEBUG;
+ run->debug.arch.address = kvmppc_get_pc(vcpu);
+ emulated = EMULATE_EXIT_USER;
+ advance = 0;
+ }
+ break;
+
default:
emulated = EMULATE_FAIL;
}
--
1.7.11.4
^ permalink raw reply related
* Re: scheduler crash on Power
From: Michael Ellerman @ 2014-08-01 1:53 UTC (permalink / raw)
To: Sukadev Bhattiprolu; +Cc: bruno, peterz, linuxppc-dev, linux-kernel, jwboyer
In-Reply-To: <20140730072242.GA21516@us.ibm.com>
On Wed, 2014-07-30 at 00:22 -0700, Sukadev Bhattiprolu wrote:
> I am getting this crash on a Powerpc system using 3.16.0-rc7 kernel plus
> some patches related to perf (24x7 counters) that Cody Schafer posted here:
>
> https://lkml.org/lkml/2014/5/27/768
>
> I don't get the crash on an unpatched kernel though.
You mean you don't get the crash on 3.16-rc7 ?
I find it hard to believe those 24x7 patches are causing this.
> I am also attaching the debug messages that Peterz added
> here: https://lkml.org/lkml/2014/7/17/288
I don't see any FAIL messages in your log, so it looks like you're not hitting
the case that patch was looking for?
> Appreciate any debug suggestions.
Reproduce on an unpatched kernel.
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] printk: Add function to return log buffer address and size
From: Joe Perches @ 2014-08-01 0:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: Vasant Hegde, Linus Torvalds, linuxppc-dev, linux-kernel
In-Reply-To: <20140731152255.37e675870dfdf77d9dbaff70@linux-foundation.org>
On Thu, 2014-07-31 at 15:22 -0700, Andrew Morton wrote:
> Please include this in whatever tree carries "powerpc/powernv:
> Interface to register/unregister opal dump region".
At some point, I'd like to redo the patch series
that breaks up printk.c into more manageable blocks.
https://lkml.org/lkml/2012/10/17/41
Any suggestion for timing?
^ permalink raw reply
* Re: [PATCH v2 1/2] printk: Add function to return log buffer address and size
From: Andrew Morton @ 2014-07-31 22:22 UTC (permalink / raw)
To: Vasant Hegde; +Cc: Linus Torvalds, linuxppc-dev, linux-kernel
In-Reply-To: <20140731153447.27134.44225.stgit@hegdevasant.in.ibm.com>
On Thu, 31 Jul 2014 21:05:48 +0530 Vasant Hegde <hegdevasant@linux.vnet.ibm.com> wrote:
> Platforms like IBM Power Systems supports service processor
> assisted dump. It provides interface to add memory region to
> be captured when system is crashed.
>
> During initialization/running we can add kernel memory region
> to be collected.
>
> Presently we don't have a way to get the log buffer base address
> and size. This patch adds support to return log buffer address
> and size.
>
> ...
>
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -10,6 +10,9 @@
> extern const char linux_banner[];
> extern const char linux_proc_banner[];
>
> +extern void *get_log_buf_addr(void);
> +extern u32 get_log_buf_len(void);
> +
> static inline int printk_get_level(const char *buffer)
> {
> if (buffer[0] == KERN_SOH_ASCII && buffer[1]) {
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 13e839d..4049f7b 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -270,6 +270,18 @@ static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
> static char *log_buf = __log_buf;
> static u32 log_buf_len = __LOG_BUF_LEN;
>
> +/* Return log buffer address */
> +void *get_log_buf_addr(void)
> +{
> + return log_buf;
> +}
> +
> +/* Return log buffer size */
> +u32 get_log_buf_len(void)
> +{
> + return log_buf_len;
> +}
> +
> /* human readable text of the record */
> static char *log_text(const struct printk_log *msg)
> {
Looks OK to me, although I think log_buf_addr_get() and
log_buf_len_get() would be better names. The kernel uses some
big-endian names and some little-endian-names and some middle-endian
names. It's all rather a mess. These symbols are already big-endian
(ie: decreasing significance):
log_buf -> addr -> get
log_buf -> len -> get
The world wouldn't end if we simply made log_buf and log_buf_len global
symbols. The pros and cons are all minor.
It's probably better to make get_log_buf_addr() tell the truth and
return a char *.
Please include this in whatever tree carries "powerpc/powernv:
Interface to register/unregister opal dump region".
^ permalink raw reply
* Re: [PATCH v2 7/7] memory-hotplug: tile: suitable memory should go to ZONE_MOVABLE
From: Chris Metcalf @ 2014-07-31 20:43 UTC (permalink / raw)
To: Wang Nan, Andrew Morton
Cc: linux-ia64, peifeiyue, linux-mm, linux-sh, linuxppc-dev, x86,
linux-kernel, Dave Hansen, Ingo Molnar, Zhang Yanfei, Mel Gorman,
Yinghai Lu
In-Reply-To: <53CDD5EE.1030805@huawei.com>
On 7/21/2014 11:09 PM, Wang Nan wrote:
> Hi Andrew,
>
> Please drop patch 7/7 from -mm tree and keep other 6 patches.
>
> arch_add_memory() in tile is different from others: no nid parameter.
> Patch 7/7 will block compiling.
>
> I cc this mail to Chris Metcalf and hope he can look at this issue.
>
> Other 6 patches looks good.
>
> On 2014/7/21 11:46, Wang Nan wrote:
>> This patch introduces zone_for_memory() to arch_add_memory() on tile to
>> ensure new, higher memory added into ZONE_MOVABLE if movable zone has
>> already setup.
>>
>> This patch also fix a problem: on tile, new memory should be added into
>> ZONE_HIGHMEM by default, not MAX_NR_ZONES-1, which is ZONE_MOVABLE.
>>
>> Signed-off-by: Wang Nan <wangnan0@huawei.com>
>> Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
>> Cc: Dave Hansen <dave.hansen@intel.com>
>> ---
>> arch/tile/mm/init.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/tile/mm/init.c b/arch/tile/mm/init.c
>> index bfb3127..22ac6c1 100644
>> --- a/arch/tile/mm/init.c
>> +++ b/arch/tile/mm/init.c
>> @@ -872,7 +872,8 @@ void __init mem_init(void)
>> int arch_add_memory(u64 start, u64 size)
>> {
>> struct pglist_data *pgdata = &contig_page_data;
>> - struct zone *zone = pgdata->node_zones + MAX_NR_ZONES-1;
>> + struct zone *zone = pgdata->node_zones +
>> + zone_for_memory(nid, start, size, ZONE_HIGHMEM);
>> unsigned long start_pfn = start >> PAGE_SHIFT;
>> unsigned long nr_pages = size >> PAGE_SHIFT;
>>
This code is entirely stale; it came from the initial port of Linux
2.6.15 to Tilera. Since we have always used DISCONTIGMEM unconditionally,
which forces NEED_MULTIPLE_NODES to be true, this code never compiles.
Note the completely irrelevant comment about x86 in this ifdef block, too :-)
The cleanest thing to do is just remove those three functions in the
ifdef block. I'll do that to our internal tree and plan to push the
change upstream later.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Does 3.0.4 kernel support PCIe AER driver on powerpc?
From: Robert Johnson @ 2014-07-31 20:28 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
I tried asking the linux-pci mail list but got no response, so I thought I =
should really ask a more powerpc centric audience.
I am working with a Freescale P2020 based embedded system that includes an =
IDT PCIe switch with x1 PCIe lanes to custom PCIe devices on a backplane. =
I was hoping to use the AER driver to get more info about any PCIe errors t=
hat may occur between the IDT switch and the PCIe devices. The embedded sy=
stem uses a board support package currently based on Gentoo Linux with kern=
el 3.0.4.
I guess the first question is does the 3.0.4 kernel support PCIe AER driver=
on powerpc?
I found one related old post from 2010 but the behavior I observe is differ=
ent than what is described in this post:
http://thread.gmane.org/gmane.linux.kernel.pci/9685/focus=3D9709
My assumption is that if the AER driver is working properly, I should see s=
ome kernel log entries that include "... service driver aer loaded" which c=
ome from pcie_port_probe_service() in drivers/pci/pcie/portdrv_core.c. Is =
that a correct assumption?
Here is a summary of what I see:
In drivers/pci/pcie/aer/aerdrv.c:
- aer_service_init() gets call at boot and appears to be su=
ccessful returning 0
- aer_probe() never gets called
=20
In drivers/pci/pcie/portdrv_core.c:
- pcie_port_service_register() gets called from aer_service=
_init() at boot, as expected it shows service name "aer" and returns 0
- pcie_port_probe_service() never gets called, I assume thi=
s would likely cause aer_probe() to get called
- pcie_port_device_register() gets called for many of the P=
CIe devices in the system and completes successfully for many cases where s=
ervice=3D0x02 (AER) is included
I end up with many devices in "/sys/bus/pci_express/devices" with names tha=
t end in "2" indicating that they are successfully associated with the AER =
service. There is also a directory /sys/bus/pci_express/drivers which cont=
ains an "aer" entry.
# ls /sys/bus/pci_express/devices
0000:01:00.0:pcie18 0000:02:11.0:pcie22 0000:02:14.0:pcie28 0000:05:00.0=
:pcie12 0000:06:05.0:pcie28 0000:06:0d.0:pcie22
0000:02:08.0:pcie22 0000:02:11.0:pcie28 0000:02:15.0:pcie22 0000:05:00.0=
:pcie18 0000:06:07.0:pcie22 0000:06:0d.0:pcie28
0000:02:08.0:pcie28 0000:02:12.0:pcie22 0000:02:15.0:pcie28 0000:06:01.0=
:pcie22 0000:06:07.0:pcie28 0000:06:0f.0:pcie22
0000:02:0c.0:pcie22 0000:02:12.0:pcie28 0000:02:16.0:pcie22 0000:06:01.0=
:pcie28 0000:06:09.0:pcie22 0000:06:0f.0:pcie28
0000:02:0c.0:pcie28 0000:02:13.0:pcie22 0000:02:16.0:pcie28 0000:06:03.0=
:pcie22 0000:06:09.0:pcie28 0000:07:00.0:pcie18
0000:02:10.0:pcie22 0000:02:13.0:pcie28 0000:02:17.0:pcie22 0000:06:03.0=
:pcie28 0000:06:0b.0:pcie22 0000:08:01.0:pcie22
0000:02:10.0:pcie28 0000:02:14.0:pcie22 0000:02:17.0:pcie28 0000:06:05.0=
:pcie22 0000:06:0b.0:pcie28 0000:08:02.0:pcie22
# ls /sys/bus/pci_express/drivers/aer
bind uevent unbind
Any idea why pcie_port_probe_service() is never called? Where should this =
be called from?
Here is a partial output of the lspci command (full listing too many chars)=
:
xpedite5570 / # lspci -vvv
00:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 21) (prog-if 00=
[Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Region 0: Memory at <ignored> (32-bit, non-prefetchable)
Bus: primary=3D00, secondary=3D01, subordinate=3D1a, sec-latency=3D=
0
I/O behind bridge: 00000000-00000fff
Memory behind bridge: 80000000-dfffffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000ffff=
f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=3D0mA PME(D0+,D1+,D2=
+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-
Capabilities: [4c] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64n=
s, L1 <1us
ExtTag- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsup=
ported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- Tr=
ansPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L0s, Latency=
L0 <2us, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- Com=
mClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk- DLA=
ctive- BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-=
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err-
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ Ch=
kEn-
01:00.0 PCI bridge: Integrated Device Technology, Inc. Device 808e (prog-if=
00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=3D01, secondary=3D02, subordinate=3D1a, sec-latency=3D=
0
I/O behind bridge: 00000000-00000fff
Memory behind bridge: 80000000-805fffff
Prefetchable memory behind bridge: 0000000080600000-00000000806ffff=
f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Upstream Port, MSI 00
DevCap: MaxPayload 2048 bytes, PhantFunc 0, Latency L0s <64=
ns, L1 <1us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-Slot=
PowerLimit 15.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsup=
ported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- Tr=
ansPend-
LnkCap: Port #8, Speed 5GT/s, Width x4, ASPM L0s L1, Latenc=
y L0 <4us, L1 <4us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk- DLA=
ctive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- Speed=
Dis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModi=
fiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationCompl=
ete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqua=
lizationRequest-
Capabilities: [c0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA PME(D0+,D1-,D2=
-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ Ch=
kEn-
Capabilities: [200 v1] Virtual Channel
Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=3DFixed
Status: InProgress-
VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTra=
ns-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR25=
6-
Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
Status: NegoPending- InProgress-
Capabilities: [330 v1] #12
Kernel driver in use: pcieport
02:08.0 PCI bridge: Integrated Device Technology, Inc. Device 808e (prog-if=
00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=3D02, secondary=3D03, subordinate=3D04, sec-latency=3D=
0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: 80000000-800fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000ffff=
f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Downstream Port (Slot-), MSI 00
DevCap: MaxPayload 2048 bytes, PhantFunc 0, Latency L0s <64=
ns, L1 <1us
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsup=
ported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- Tr=
ansPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Latenc=
y L0 <4us, L1 <4us
ClockPM- Surprise+ LLActRep+ BwNot+
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLA=
ctive+ BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARI=
Fwd+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIF=
wd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- Speed=
Dis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModi=
fiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationCompl=
ete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqua=
lizationRequest-
Capabilities: [c0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA PME(D0+,D1-,D2=
-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
Capabilities: [d0] MSI: Enable+ Count=3D1/1 Maskable- 64bit+
Address: 00000000fff41740 Data: 0000
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ Ch=
kEn-
Capabilities: [200 v1] Virtual Channel
Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=3DFixed
Status: InProgress-
VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTra=
ns-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR25=
6-
Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
Status: NegoPending- InProgress-
Capabilities: [320 v1] Access Control Services
ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamF=
wd+ EgressCtrl+ DirectTrans+
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamF=
wd- EgressCtrl- DirectTrans-
Capabilities: [330 v1] #12
Kernel driver in use: pcieport
02:0c.0 PCI bridge: Integrated Device Technology, Inc. Device 808e (prog-if=
00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=3D02, secondary=3D05, subordinate=3D12, sec-latency=3D=
0
I/O behind bridge: 00000000-00000fff
Memory behind bridge: 80100000-804fffff
Prefetchable memory behind bridge: 0000000080600000-00000000806ffff=
f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Downstream Port (Slot-), MSI 00
DevCap: MaxPayload 2048 bytes, PhantFunc 0, Latency L0s <64=
ns, L1 <1us
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsup=
ported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- Tr=
ansPend-
LnkCap: Port #12, Speed 5GT/s, Width x4, ASPM L0s L1, Laten=
cy L0 <4us, L1 <4us
ClockPM- Surprise+ LLActRep+ BwNot+
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk- DLA=
ctive+ BWMgmt+ ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARI=
Fwd+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIF=
wd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- Speed=
Dis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModi=
fiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationCompl=
ete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqua=
lizationRequest-
Capabilities: [c0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA PME(D0+,D1-,D2=
-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
Capabilities: [d0] MSI: Enable+ Count=3D1/1 Maskable- 64bit+
Address: 00000000fff41740 Data: 0001
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ Ch=
kEn-
Capabilities: [200 v1] Virtual Channel
Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=3DFixed
Status: InProgress-
VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTra=
ns-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR25=
6-
Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
Status: NegoPending- InProgress-
Capabilities: [320 v1] Access Control Services
ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamF=
wd+ EgressCtrl+ DirectTrans+
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamF=
wd- EgressCtrl- DirectTrans-
Capabilities: [330 v1] #12
Kernel driver in use: pcieport
02:11.0 PCI bridge: Integrated Device Technology, Inc. Device 808e (prog-if=
00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=3D02, secondary=3D14, subordinate=3D14, sec-latency=3D=
0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: 80500000-805fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000ffff=
f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Downstream Port (Slot-), MSI 00
DevCap: MaxPayload 1024 bytes, PhantFunc 0, Latency L0s <64=
ns, L1 <1us
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsup=
ported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- Tr=
ansPend-
LnkCap: Port #17, Speed 5GT/s, Width x1, ASPM L0s L1, Laten=
cy L0 <4us, L1 <4us
ClockPM- Surprise+ LLActRep+ BwNot+
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLA=
ctive+ BWMgmt+ ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARI=
Fwd+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIF=
wd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- Speed=
Dis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModi=
fiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationCompl=
ete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqua=
lizationRequest-
Capabilities: [c0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA PME(D0+,D1-,D2=
-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
Capabilities: [d0] MSI: Enable+ Count=3D1/1 Maskable- 64bit+
Address: 00000000fff41740 Data: 0003
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- =
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatal=
Err+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ Ch=
kEn-
Capabilities: [200 v1] Virtual Channel
Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=3DFixed
Status: InProgress-
VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTra=
ns-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR25=
6-
Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
Status: NegoPending- InProgress-
Capabilities: [320 v1] Access Control Services
ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamF=
wd+ EgressCtrl+ DirectTrans+
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamF=
wd- EgressCtrl- DirectTrans-
Capabilities: [330 v1] #12
Kernel driver in use: pcieport
14:00.0 Memory controller: Xilinx Corporation Device 6024
Subsystem: Xilinx Corporation Device 0007
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <T=
Abort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 64
Region 0: Memory at f80500000 (64-bit, non-prefetchable) [size=3D1M=
]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA PME(D0+,D1+,D2=
+,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
Capabilities: [48] MSI: Enable+ Count=3D1/16 Maskable- 64bit+
Address: 00000000fff41740 Data: 0016
Capabilities: [60] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64n=
s, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsup=
ported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- Tr=
ansPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency=
L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- Comm=
Clk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLA=
ctive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range B, TimeoutDis-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- Speed=
Dis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModi=
fiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationCom=
plete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqua=
lizationRequest-
Capabilities: [9c] MSI-X: Enable- Count=3D4 Masked-
Vector table: BAR=3D0 offset=3D000f0000
PBA: BAR=3D0 offset=3D000f8000
Capabilities: [fc] #00 [0000]
Capabilities: [100 v1] Device Serial Number 00-00-00-01-01-00-0a-35
Kernel driver in use: spi_dev
^ permalink raw reply
* Re: [PATCH 0/4] ASoC: fsl: Add stream names to CPU DAI drivers for DPCM
From: Mark Brown @ 2014-07-31 19:55 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel, lgirdwood, tiwai, b42378, b02247, linux-kernel, timur,
Li.Xiubo, perex, linuxppc-dev
In-Reply-To: <cover.1406688048.git.nicoleotsuka@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
On Wed, Jul 30, 2014 at 11:10:25AM +0800, Nicolin Chen wrote:
> DPCM needs extra dapm routes in the machine driver to route audio
> between Front-End and Back-End. In order to differ the stream names
> in the route map from CODECs, we here add specific stream names to
> all Freescale ASoC CPU DAI drivers so that we can implement ASRC via
> DPCM to each of them.
Applied all, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] powerpc/powernv: update dev->dma_mask in pci_set_dma_mask() path
From: Brian W Hart @ 2014-07-31 19:24 UTC (permalink / raw)
To: benh, linuxppc-dev, linux-kernel
powerpc defines various machine-specific routines for handling
pci_set_dma_mask(). The routines for machine "PowerNV" may neglect
to set dev->dma_mask. This could confuse anyone (e.g. drivers) that
consult dev->dma_mask to find the current mask. Set the dma_mask in
the PowerNV leaf routine.
Signed-off-by: Brian W. Hart <hartb@linux.vnet.ibm.com>
---
I assume the failure to set dma_mask in this path was just an oversight.
With this change everything still seems to work fine on my powernv setup,
and dev->dma_mask now carries the appropriate value after
pci_set_dma_mask(dev, DMA_BIT_MASK(64).
arch/powerpc/platforms/powernv/pci-ioda.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index de19ede..3136ae2 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -491,6 +491,7 @@ static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
set_dma_ops(&pdev->dev, &dma_iommu_ops);
set_iommu_table_base(&pdev->dev, &pe->tce32_table);
}
+ *pdev->dev.dma_mask = dma_mask;
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [patch -next] ASoC: fsl_asrc: fix an error code in fsl_asrc_probe()
From: Mark Brown @ 2014-07-31 19:24 UTC (permalink / raw)
To: Dan Carpenter
Cc: alsa-devel, Liam Girdwood, Takashi Iwai, kernel-janitors,
Timur Tabi, Jaroslav Kysela, Rob Herring, Grant Likely,
linuxppc-dev
In-Reply-To: <20140731093209.GF30276@mwanda>
[-- Attachment #1: Type: text/plain, Size: 255 bytes --]
On Thu, Jul 31, 2014 at 12:32:09PM +0300, Dan Carpenter wrote:
> There is a cut and paste bug so it returns success instead of the error
> code.
Applied, thanks. Might be worth looking at how you're generating your
CC lists here, it seems a bit random.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_asrc: Fix sparse warnings in FSL_ASRC_FORMATS due to typo
From: Mark Brown @ 2014-07-31 19:22 UTC (permalink / raw)
To: Nicolin Chen; +Cc: alsa-devel, b42378, linuxppc-dev, linux-kernel, timur
In-Reply-To: <1406779660-17177-1-git-send-email-nicoleotsuka@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
On Thu, Jul 31, 2014 at 12:07:40PM +0800, Nicolin Chen wrote:
> reproduce: make C=1 CF=-D__CHECK_ENDIAN__
>
> sparse warnings: (new ones prefixed by >>)
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
From: Emil Medve @ 2014-07-31 18:49 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <1406831433.29414.339.camel@snotra.buserror.net>
Hello Scott,
On 07/31/2014 01:30 PM, Scott Wood wrote:
> On Thu, 2014-07-31 at 00:48 -0500, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 07/31/2014 12:28 AM, Scott Wood wrote:
>>> On Wed, 2014-07-30 at 23:35 -0500, Emil Medve wrote:
>>>> Hello Scott,
>>>>
>>>>
>>>> On 07/30/2014 09:30 PM, Scott Wood wrote:
>>>>> On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
>>>>>>>>>> + mdio0: mdio <at> fc000 {
>>>>>>>>>> + };
>>>>>>>>>
>>>>>>>>> Why is the empty node needed?
>>>>>>>>
>>>>>>>> For the label
>>>>>>>
>>>>>>> For mdio-parent-bus, or is there some other dts layer that makes this
>>>>>>> node non-empty?
>>>>>>
>>>>>> 'powerpc/corenet: Create the dts components for the DPAA FMan' -
>>>>>> http://patchwork.ozlabs.org/patch/370872
>>>>>
>>>>> Why does this patch define the mdio0 label for mdio@e1120, but not
>>>>> define a label for any other node?
>>>>
>>>> Only MDIO controllers that are pinned out have these labels. Only pinned
>>>> out MDIO(s) are capable of controlling external PHY(s) via these board
>>>> level MDIO buses
>>>
>>> Is there any reason to describe non-pinned-out MDIO controllers at all?
>>
>> Yes. For the internal TBI PHY(s). Each MAC supporting SGMII has a TBI
>> PHY that is attached to the MDIO controller of the respective MAC
>
> OK, so similar to eTSEC. I didn't know if you were counting aTBI
> connection as being (partially) pinned out.
>
>>> Is the lack of pinning out inherent to the silicon, or is it board
>>> design/config?
>>
>> It's a silicon level decision
>
> So why is it the board file that adds the label, if it's always going to
> be the same node?
I guess we can move it
>>> I'm just curious why mdio@e1120 is labelled in a non-board dtsi while
>>> others are labelled elsewhere.
>>
>> Labels are relevant only in the context of 'powerpc/corenet: Add MDIO
>> bus muxing support to the board device tree(s)' -
>> http://patchwork.ozlabs.org/patch/370866. Most labels are created and
>> used in the board .dts file except b4qds.dtsi which is shared between
>> b4420qds.dts and b4860qds.dts
>
> I'm talking about qoriq-fman-0-1g-0.dtsi, not b4qds.dtsi. It labels
> mdio@e1120 as mdio0.
We missed that. Given the above, we'll leave it and remove it from the
board files
Cheers,
> In other words, why is the decision on where to label made differently
> for fman v3 than for previous fman versions?
>
> -Scott
^ permalink raw reply
* Re: [PATCH v4 6/6] clk: Add floor and ceiling constraints to clock rates
From: Mike Turquette @ 2014-07-31 18:54 UTC (permalink / raw)
To: Stephen Warren, Tomeu Vizoso
Cc: Ulf Hansson, Prashant Gaikwad,
Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>, Russell King <linux@arm.linux.org.uk>, Shawn Guo <shawn.guo@freescale.com>, Sascha Hauer <kernel@pengutronix.de>, David Brown <davidb@codeaurora.org>, Daniel Walker <dwalker@fifo99.com>, Bryan Huntsman <bryanh@codeaurora.org>, Paul Walmsley <paul@pwsan.com>, Tony Lindgren <tony@atomide.com>, " Benoît Cousson <bcousson@baylibre.com>, Kevin Hilman,
Tomasz Figa, alsa-devel, Jaroslav Kysela, Thierry Reding,
Paul Mackerras, Sylwester Nawrocki, linux-arch, Boris Brezillon,
linux-samsung-soc, Kukjin Kim, " Emilio López, patches,
Michal Simek, Takashi Iwai, Santosh Shilimkar, Anatolij Gustschin,
Dinh Nguyen, linux-media, Arnd Bergmann, linux-arm-msm,
spear-devel, Mark Brown, linux-rpi-kernel, Ben Dooks, linux-tegra,
linux-omap, linux-arm-kernel, Barry Song, Peter De Schrijver,
Liam Girdwood, linux-kernel, rabin, Kyungmin Park, Viresh Kumar,
Maxime Ripard, linuxppc-dev, Javier Martinez Canillas,
Mauro Carvalho Chehab
In-Reply-To: <53DA8218.7070300@wwwdotorg.org>
Quoting Stephen Warren (2014-07-31 10:51:20)
> On 07/31/2014 05:47 AM, Tomeu Vizoso wrote:
> > On 07/22/2014 07:50 PM, Stephen Warren wrote:
> >> On 07/17/2014 08:13 AM, Tomeu Vizoso wrote:
> >>> Adds a way for clock consumers to set maximum and minimum rates. This
> >>> can be
> >>> used for thermal drivers to set ceiling rates, or by misc. drivers to
> >>> set
> >>> floor rates to assure a minimum performance level.
> >>
> >>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> >>
> >>> +struct rate_constraint {
> >>> + struct hlist_node node;
> >>> + const char *dev_id;
> >>> + const char *con_id;
> >>> + enum constraint_type type;
> >>> + unsigned long rate;
> >>> +};
> >>
> >> I would personally still prefer either:
> >>
> >> a) The struct rate_constraints be stored in struct clk rather than
> >> struct clk_core, so they're stored in the container that "set" the
> >> constraints. This would mean iterating over a struct clk_core's
> >> associated struct clks, then iterating over the struct rate_constraints
> >> within each struct clk.
> >>
> >> or:
> >>
> >> b) struct rate_constraint to contain a pointer to the struct clk that
> >> created the constraint, rather than copying the dev_id/con_id from that
> >> struct clk into the struct rate_constraint.
> >>
> >> With either of those changes, the constraints are directly associated
> >> with the clock client object that created the constraint much better
> >> than right now, where the matching is only because the struct clk and
> >> struct rate_constraint "happen to" have the same dev_id/con_id values.
> >>
> >> Still, this is a pretty minor issue, and overall this series looks
> >> reasonable to me at a quick look.
> >
> > Yeah, I agree and personally prefer a), but given the little feedback
> > that I have gotten so far on the refactoring, I'm starting to consider
> > forgetting about the per-user clk struct and go instead with a
> > request-based API similar to that of pm_qos, for setting floor and
> > ceiling frequencies.
> =
> I would obviously encourage you to continue pushing for this feature, =
> although I understand it can be difficult to be motivated when the =
> patches don't get much feedback.
Sorry for not giving this more of a look. My secret plan was to review
this in more detail once we're closer to the merge window and, if
appropriate, apply it as one of the first things since this is bound to
cause some breakage early on which needs to be caught and fixed up
quickly.
We are very close to the merge window so I will try to get to this later
this week. I like the per-user struct clk myself and I hope we can get
this in for 3.18.
Regards,
Mike
^ permalink raw reply
* Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
From: Scott Wood @ 2014-07-31 18:30 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev
In-Reply-To: <53D9D893.8090105@Freescale.com>
On Thu, 2014-07-31 at 00:48 -0500, Emil Medve wrote:
> Hello Scott,
>
>
> On 07/31/2014 12:28 AM, Scott Wood wrote:
> > On Wed, 2014-07-30 at 23:35 -0500, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 07/30/2014 09:30 PM, Scott Wood wrote:
> >>> On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
> >>>>>>>> + mdio0: mdio <at> fc000 {
> >>>>>>>> + };
> >>>>>>>
> >>>>>>> Why is the empty node needed?
> >>>>>>
> >>>>>> For the label
> >>>>>
> >>>>> For mdio-parent-bus, or is there some other dts layer that makes this
> >>>>> node non-empty?
> >>>>
> >>>> 'powerpc/corenet: Create the dts components for the DPAA FMan' -
> >>>> http://patchwork.ozlabs.org/patch/370872
> >>>
> >>> Why does this patch define the mdio0 label for mdio@e1120, but not
> >>> define a label for any other node?
> >>
> >> Only MDIO controllers that are pinned out have these labels. Only pinned
> >> out MDIO(s) are capable of controlling external PHY(s) via these board
> >> level MDIO buses
> >
> > Is there any reason to describe non-pinned-out MDIO controllers at all?
>
> Yes. For the internal TBI PHY(s). Each MAC supporting SGMII has a TBI
> PHY that is attached to the MDIO controller of the respective MAC
OK, so similar to eTSEC. I didn't know if you were counting aTBI
connection as being (partially) pinned out.
> > Is the lack of pinning out inherent to the silicon, or is it board
> > design/config?
>
> It's a silicon level decision
So why is it the board file that adds the label, if it's always going to
be the same node?
> > I'm just curious why mdio@e1120 is labelled in a non-board dtsi while
> > others are labelled elsewhere.
>
> Labels are relevant only in the context of 'powerpc/corenet: Add MDIO
> bus muxing support to the board device tree(s)' -
> http://patchwork.ozlabs.org/patch/370866. Most labels are created and
> used in the board .dts file except b4qds.dtsi which is shared between
> b4420qds.dts and b4860qds.dts
I'm talking about qoriq-fman-0-1g-0.dtsi, not b4qds.dtsi. It labels
mdio@e1120 as mdio0.
In other words, why is the decision on where to label made differently
for fman v3 than for previous fman versions?
-Scott
^ permalink raw reply
* Re: [PATCH v4 6/6] clk: Add floor and ceiling constraints to clock rates
From: Stephen Warren @ 2014-07-31 17:51 UTC (permalink / raw)
To: Tomeu Vizoso, Mike Turquette
Cc: Andrew Lunn, Ulf Hansson, Prashant Gaikwad, Tony Lindgren,
Tomasz Figa, alsa-devel, Jaroslav Kysela, Thierry Reding,
Paul Mackerras, Sylwester Nawrocki, Daniel Walker, linux-arch,
Boris Brezillon, linux-samsung-soc, Kukjin Kim, Russell King,
Emilio López, Takashi Iwai, Michal Simek, Kyungmin Park,
Kevin Hilman, linux-arm-kernel, patches, Viresh Kumar,
David Brown, Anatolij Gustschin, Dinh Nguyen,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, linux-arm-msm,
spear-devel, Barry Song, Mark Brown, linux-rpi-kernel, Ben Dooks,
linux-tegra, linux-omap, Sascha Hauer, Shawn Guo, Paul Walmsley,
Peter De Schrijver, Liam Girdwood, linux-kernel, rabin,
Bryan Huntsman, Santosh Shilimkar, Benoît Cousson,
Maxime Ripard, linux-media, linuxppc-dev,
Javier Martinez Canillas, Mauro Carvalho Chehab
In-Reply-To: <53DA2CCB.2080300@collabora.com>
On 07/31/2014 05:47 AM, Tomeu Vizoso wrote:
> On 07/22/2014 07:50 PM, Stephen Warren wrote:
>> On 07/17/2014 08:13 AM, Tomeu Vizoso wrote:
>>> Adds a way for clock consumers to set maximum and minimum rates. This
>>> can be
>>> used for thermal drivers to set ceiling rates, or by misc. drivers to
>>> set
>>> floor rates to assure a minimum performance level.
>>
>>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>>
>>> +struct rate_constraint {
>>> + struct hlist_node node;
>>> + const char *dev_id;
>>> + const char *con_id;
>>> + enum constraint_type type;
>>> + unsigned long rate;
>>> +};
>>
>> I would personally still prefer either:
>>
>> a) The struct rate_constraints be stored in struct clk rather than
>> struct clk_core, so they're stored in the container that "set" the
>> constraints. This would mean iterating over a struct clk_core's
>> associated struct clks, then iterating over the struct rate_constraints
>> within each struct clk.
>>
>> or:
>>
>> b) struct rate_constraint to contain a pointer to the struct clk that
>> created the constraint, rather than copying the dev_id/con_id from that
>> struct clk into the struct rate_constraint.
>>
>> With either of those changes, the constraints are directly associated
>> with the clock client object that created the constraint much better
>> than right now, where the matching is only because the struct clk and
>> struct rate_constraint "happen to" have the same dev_id/con_id values.
>>
>> Still, this is a pretty minor issue, and overall this series looks
>> reasonable to me at a quick look.
>
> Yeah, I agree and personally prefer a), but given the little feedback
> that I have gotten so far on the refactoring, I'm starting to consider
> forgetting about the per-user clk struct and go instead with a
> request-based API similar to that of pm_qos, for setting floor and
> ceiling frequencies.
I would obviously encourage you to continue pushing for this feature,
although I understand it can be difficult to be motivated when the
patches don't get much feedback.
^ permalink raw reply
* [PATCH v2 2/2] powerpc/powernv: Interface to register/unregister opal dump region
From: Vasant Hegde @ 2014-07-31 10:30 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds, Andrew Morton, linuxppc-dev
In-Reply-To: <20140731102920.27954.25076.stgit@hegdevasant.in.ibm.com>
PowerNV platform is capable of capturing host memory region when system
crashes (because of host/firmware). We have new OPAL API to register/
unregister memory region to be captured when system crashes.
This patch adds support for new API. Also during boot time we register
kernel log buffer and unregister before doing kexec.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 15 +++++
arch/powerpc/platforms/powernv/Makefile | 2 -
arch/powerpc/platforms/powernv/opal-dump-region.c | 64 +++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-wrappers.S | 2 +
arch/powerpc/platforms/powernv/opal.c | 2 +
arch/powerpc/platforms/powernv/setup.c | 3 +
6 files changed, 87 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/powernv/opal-dump-region.c
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 0da1dbd..f9261d7 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -147,6 +147,8 @@ struct opal_sg_list {
#define OPAL_SET_PARAM 90
#define OPAL_DUMP_RESEND 91
#define OPAL_DUMP_INFO2 94
+#define OPAL_REGISTER_DUMP_REGION 101
+#define OPAL_UNREGISTER_DUMP_REGION 102
#ifndef __ASSEMBLY__
@@ -860,6 +862,8 @@ int64_t opal_get_param(uint64_t token, uint32_t param_id, uint64_t buffer,
int64_t opal_set_param(uint64_t token, uint32_t param_id, uint64_t buffer,
uint64_t length);
int64_t opal_sensor_read(uint32_t sensor_hndl, int token, __be32 *sensor_data);
+int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
+int64_t opal_unregister_dump_region(uint32_t id);
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -899,6 +903,8 @@ extern int opal_elog_init(void);
extern void opal_platform_dump_init(void);
extern void opal_sys_param_init(void);
extern void opal_msglog_init(void);
+extern void opal_dump_region_init(void);
+extern void opal_dump_kexec_callback(void);
extern int opal_machine_check(struct pt_regs *regs);
extern bool opal_mce_check_early_recovery(struct pt_regs *regs);
@@ -912,6 +918,15 @@ struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
unsigned long vmalloc_size);
void opal_free_sg_list(struct opal_sg_list *sg);
+/*
+ * Dump regions ids
+ * 0x01 - 0x7F : OPAL
+ * 0x80 - 0xFF : Kernel
+ */
+#define DUMP_REGION_HOST_START 0x80
+#define DUMP_REGION_LOG_BUF 0x80
+#define DUMP_REGION_HOST_END 0xFF
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index 4ad227d..e2819aa 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,7 +1,7 @@
obj-y += setup.o opal-wrappers.o opal.o opal-async.o
obj-y += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o
-obj-y += opal-msglog.o
+obj-y += opal-msglog.o opal-dump-region.o
obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
diff --git a/arch/powerpc/platforms/powernv/opal-dump-region.c b/arch/powerpc/platforms/powernv/opal-dump-region.c
new file mode 100644
index 0000000..c3f1536
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-dump-region.c
@@ -0,0 +1,64 @@
+/*
+ * PowerNV OPAL dump memory region interface
+ *
+ * Copyright 2014 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/pagemap.h>
+#include <linux/printk.h>
+#include <asm/opal.h>
+
+/*
+ * Pass kernel address range (start, size) that will be included in
+ * system dump (collected by service processor whenever system crashes).
+ *
+ * @id : Memory region ID (see opal.h)
+ * @addr : Start address
+ * @size : size in bytes
+ */
+static int add_dump_region_entry(uint32_t id, void *addr, uint64_t size)
+{
+ __be32 be_id = cpu_to_be32(id);
+ __be64 be_addr = cpu_to_be64(__pa(addr));
+ __be64 be_size = cpu_to_be64(size);
+
+ return opal_register_dump_region(be_id, be_addr, be_size);
+}
+
+static int remove_dump_region_entry(uint32_t id)
+{
+ __be32 be_id = cpu_to_be32(id);
+
+ return opal_unregister_dump_region(be_id);
+}
+
+/* This gets called just before kexec */
+void opal_dump_kexec_callback(void)
+{
+ int rc;
+
+ rc = remove_dump_region_entry(DUMP_REGION_LOG_BUF);
+ if (rc)
+ pr_warn("DUMP: Failed to unregister kernel log buffer. "
+ "rc = %d\n", rc);
+}
+
+void __init opal_dump_region_init(void)
+{
+ void *addr;
+ uint64_t size;
+ int rc;
+
+ /* Register kernel log buffer */
+ addr = get_log_buf_addr();
+ size = get_log_buf_len();
+ rc = add_dump_region_entry(DUMP_REGION_LOG_BUF, addr, size);
+ if (rc)
+ pr_warn("DUMP: Failed to register kernel log buffer. "
+ "rc = %d\n", rc);
+}
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 4abbff2..0f016cb 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -146,3 +146,5 @@ OPAL_CALL(opal_sync_host_reboot, OPAL_SYNC_HOST_REBOOT);
OPAL_CALL(opal_sensor_read, OPAL_SENSOR_READ);
OPAL_CALL(opal_get_param, OPAL_GET_PARAM);
OPAL_CALL(opal_set_param, OPAL_SET_PARAM);
+OPAL_CALL(opal_register_dump_region, OPAL_REGISTER_DUMP_REGION);
+OPAL_CALL(opal_unregister_dump_region, OPAL_UNREGISTER_DUMP_REGION);
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 1999756..2834303 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -616,6 +616,8 @@ static int __init opal_init(void)
/* Create "opal" kobject under /sys/firmware */
rc = opal_sysfs_init();
if (rc == 0) {
+ /* Setup dump region interface */
+ opal_dump_region_init();
/* Setup error log interface */
rc = opal_elog_init();
/* Setup code update interface */
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index d9b88fa..644c9ba 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -184,6 +184,9 @@ static void pnv_shutdown(void)
* DMA'ing ops are complete (such as dump retrieval).
*/
opal_shutdown();
+
+ /* Unregister memory dump region */
+ opal_dump_kexec_callback();
}
#ifdef CONFIG_KEXEC
^ permalink raw reply related
* [PATCH v2 2/2] powerpc/powernv: Interface to register/unregister opal dump region
From: Vasant Hegde @ 2014-07-31 15:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds, Andrew Morton, linuxppc-dev
In-Reply-To: <20140731153447.27134.44225.stgit@hegdevasant.in.ibm.com>
PowerNV platform is capable of capturing host memory region when system
crashes (because of host/firmware). We have new OPAL API to register/
unregister memory region to be captured when system crashes.
This patch adds support for new API. Also during boot time we register
kernel log buffer and unregister before doing kexec.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 15 +++++
arch/powerpc/platforms/powernv/Makefile | 2 -
arch/powerpc/platforms/powernv/opal-dump-region.c | 64 +++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-wrappers.S | 2 +
arch/powerpc/platforms/powernv/opal.c | 2 +
arch/powerpc/platforms/powernv/setup.c | 3 +
6 files changed, 87 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/powernv/opal-dump-region.c
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 0da1dbd..f9261d7 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -147,6 +147,8 @@ struct opal_sg_list {
#define OPAL_SET_PARAM 90
#define OPAL_DUMP_RESEND 91
#define OPAL_DUMP_INFO2 94
+#define OPAL_REGISTER_DUMP_REGION 101
+#define OPAL_UNREGISTER_DUMP_REGION 102
#ifndef __ASSEMBLY__
@@ -860,6 +862,8 @@ int64_t opal_get_param(uint64_t token, uint32_t param_id, uint64_t buffer,
int64_t opal_set_param(uint64_t token, uint32_t param_id, uint64_t buffer,
uint64_t length);
int64_t opal_sensor_read(uint32_t sensor_hndl, int token, __be32 *sensor_data);
+int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
+int64_t opal_unregister_dump_region(uint32_t id);
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -899,6 +903,8 @@ extern int opal_elog_init(void);
extern void opal_platform_dump_init(void);
extern void opal_sys_param_init(void);
extern void opal_msglog_init(void);
+extern void opal_dump_region_init(void);
+extern void opal_dump_kexec_callback(void);
extern int opal_machine_check(struct pt_regs *regs);
extern bool opal_mce_check_early_recovery(struct pt_regs *regs);
@@ -912,6 +918,15 @@ struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
unsigned long vmalloc_size);
void opal_free_sg_list(struct opal_sg_list *sg);
+/*
+ * Dump regions ids
+ * 0x01 - 0x7F : OPAL
+ * 0x80 - 0xFF : Kernel
+ */
+#define DUMP_REGION_HOST_START 0x80
+#define DUMP_REGION_LOG_BUF 0x80
+#define DUMP_REGION_HOST_END 0xFF
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index 4ad227d..e2819aa 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,7 +1,7 @@
obj-y += setup.o opal-wrappers.o opal.o opal-async.o
obj-y += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o
-obj-y += opal-msglog.o
+obj-y += opal-msglog.o opal-dump-region.o
obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
diff --git a/arch/powerpc/platforms/powernv/opal-dump-region.c b/arch/powerpc/platforms/powernv/opal-dump-region.c
new file mode 100644
index 0000000..c3f1536
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-dump-region.c
@@ -0,0 +1,64 @@
+/*
+ * PowerNV OPAL dump memory region interface
+ *
+ * Copyright 2014 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/pagemap.h>
+#include <linux/printk.h>
+#include <asm/opal.h>
+
+/*
+ * Pass kernel address range (start, size) that will be included in
+ * system dump (collected by service processor whenever system crashes).
+ *
+ * @id : Memory region ID (see opal.h)
+ * @addr : Start address
+ * @size : size in bytes
+ */
+static int add_dump_region_entry(uint32_t id, void *addr, uint64_t size)
+{
+ __be32 be_id = cpu_to_be32(id);
+ __be64 be_addr = cpu_to_be64(__pa(addr));
+ __be64 be_size = cpu_to_be64(size);
+
+ return opal_register_dump_region(be_id, be_addr, be_size);
+}
+
+static int remove_dump_region_entry(uint32_t id)
+{
+ __be32 be_id = cpu_to_be32(id);
+
+ return opal_unregister_dump_region(be_id);
+}
+
+/* This gets called just before kexec */
+void opal_dump_kexec_callback(void)
+{
+ int rc;
+
+ rc = remove_dump_region_entry(DUMP_REGION_LOG_BUF);
+ if (rc)
+ pr_warn("DUMP: Failed to unregister kernel log buffer. "
+ "rc = %d\n", rc);
+}
+
+void __init opal_dump_region_init(void)
+{
+ void *addr;
+ uint64_t size;
+ int rc;
+
+ /* Register kernel log buffer */
+ addr = get_log_buf_addr();
+ size = get_log_buf_len();
+ rc = add_dump_region_entry(DUMP_REGION_LOG_BUF, addr, size);
+ if (rc)
+ pr_warn("DUMP: Failed to register kernel log buffer. "
+ "rc = %d\n", rc);
+}
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 4abbff2..0f016cb 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -146,3 +146,5 @@ OPAL_CALL(opal_sync_host_reboot, OPAL_SYNC_HOST_REBOOT);
OPAL_CALL(opal_sensor_read, OPAL_SENSOR_READ);
OPAL_CALL(opal_get_param, OPAL_GET_PARAM);
OPAL_CALL(opal_set_param, OPAL_SET_PARAM);
+OPAL_CALL(opal_register_dump_region, OPAL_REGISTER_DUMP_REGION);
+OPAL_CALL(opal_unregister_dump_region, OPAL_UNREGISTER_DUMP_REGION);
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 1999756..2834303 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -616,6 +616,8 @@ static int __init opal_init(void)
/* Create "opal" kobject under /sys/firmware */
rc = opal_sysfs_init();
if (rc == 0) {
+ /* Setup dump region interface */
+ opal_dump_region_init();
/* Setup error log interface */
rc = opal_elog_init();
/* Setup code update interface */
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index d9b88fa..644c9ba 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -184,6 +184,9 @@ static void pnv_shutdown(void)
* DMA'ing ops are complete (such as dump retrieval).
*/
opal_shutdown();
+
+ /* Unregister memory dump region */
+ opal_dump_kexec_callback();
}
#ifdef CONFIG_KEXEC
^ permalink raw reply related
* [PATCH v2 1/2] printk: Add function to return log buffer address and size
From: Vasant Hegde @ 2014-07-31 15:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds, Andrew Morton, linuxppc-dev
Platforms like IBM Power Systems supports service processor
assisted dump. It provides interface to add memory region to
be captured when system is crashed.
During initialization/running we can add kernel memory region
to be collected.
Presently we don't have a way to get the log buffer base address
and size. This patch adds support to return log buffer address
and size.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
Next patch extends arch specific code to add log buffer to platform
dump.
-Vasant
include/linux/printk.h | 3 +++
kernel/printk/printk.c | 12 ++++++++++++
2 files changed, 15 insertions(+)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 319ff7e..aae82c4 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -10,6 +10,9 @@
extern const char linux_banner[];
extern const char linux_proc_banner[];
+extern void *get_log_buf_addr(void);
+extern u32 get_log_buf_len(void);
+
static inline int printk_get_level(const char *buffer)
{
if (buffer[0] == KERN_SOH_ASCII && buffer[1]) {
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 13e839d..4049f7b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -270,6 +270,18 @@ static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
static char *log_buf = __log_buf;
static u32 log_buf_len = __LOG_BUF_LEN;
+/* Return log buffer address */
+void *get_log_buf_addr(void)
+{
+ return log_buf;
+}
+
+/* Return log buffer size */
+u32 get_log_buf_len(void)
+{
+ return log_buf_len;
+}
+
/* human readable text of the record */
static char *log_text(const struct printk_log *msg)
{
^ permalink raw reply related
* Re: [PATCH 1/2] PCI/MSI/PPC: Remove arch_msi_check_device()
From: Alexander Gordeev @ 2014-07-31 13:53 UTC (permalink / raw)
To: linux-kernel, Michael Ellerman, Benjamin Herrenschmidt
Cc: linux-pci, linuxppc-dev
In-Reply-To: <18276ae8c0b212b8d40dfd186e1c84b8ae949525.1405160163.git.agordeev@redhat.com>
On Sat, Jul 12, 2014 at 01:21:07PM +0200, Alexander Gordeev wrote:
> PowerPC is the only architecture that makes use of hook
> arch_msi_check_device() and does perform some checks to
> figure out if MSI/MSI-X could be enabled for a device.
> However, there are no reasons why those checks could not
> be done within arch_setup_msi_irqs() hook.
>
> Moving MSI checks into arch_setup_msi_irqs() makes code
> more readable and allows getting rid of unnecessary hook
> arch_msi_check_device().
Michael, Ben,
Any feedback?
Thanks!
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* [PATCH] powerpc/book3s: Fix endianess issue for HMI handling on napping cpus.
From: Mahesh J Salgaonkar @ 2014-07-31 12:47 UTC (permalink / raw)
To: linuxppc-dev, Anton Blanchard, Benjamin Herrenschmidt; +Cc: preeti, shreyas
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
(NOTE: This patch depends on upstream HMI handling patchset at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-July/119731.html)
The current HMI handling on napping cpus does not take care of endianess
issue. On LE host kernel when we wake up from nap due to HMI interrupt we
would checkstop while jumping into opal call. There is a similar issue in
case of fast sleep wakeup where the code invokes opal_resync_tb opal call
without handling LE issue. This patch fixes that as well.
With this patch applied, HMIs handling on LE host kernel works fine.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/idle_power7.S | 49 ++++++++++++++++++++++++++++---------
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S
index 06305f6..be05841 100644
--- a/arch/powerpc/kernel/idle_power7.S
+++ b/arch/powerpc/kernel/idle_power7.S
@@ -135,6 +135,39 @@ _GLOBAL(power7_sleep)
b power7_powersave_common
/* No return */
+/*
+ * Make opal call in realmode. This is a generic function to be called
+ * from realmode from reset vector. It handles endianess.
+ *
+ * r13 - paca pointer
+ * r1 - stack pointer
+ * r3 - opal token
+ */
+opal_call_realmode:
+ mflr r12
+ std r12,_LINK(r1)
+ ld r2,PACATOC(r13)
+ /* Set opal return address */
+ LOAD_REG_ADDR(r0,return_from_opal_call)
+ mtlr r0
+ /* Handle endian-ness */
+ li r0,MSR_LE
+ mfmsr r12
+ andc r12,r12,r0
+ mtspr SPRN_HSRR1,r12
+ mr r0,r3 /* Move opal token to r0 */
+ LOAD_REG_ADDR(r11,opal)
+ ld r12,8(r11)
+ ld r2,0(r11)
+ mtspr SPRN_HSRR0,r12
+ hrfid
+
+return_from_opal_call:
+ FIXUP_ENDIAN
+ ld r0,_LINK(r1)
+ mtlr r0
+ blr
+
#define CHECK_HMI_INTERRUPT \
mfspr r0,SPRN_SRR1; \
BEGIN_FTR_SECTION_NESTED(66); \
@@ -148,12 +181,8 @@ ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S, 66); \
ld r2,PACATOC(r13); \
ld r1,PACAR1(r13); \
std r3,ORIG_GPR3(r1); /* Save original r3 */ \
- li r0,OPAL_HANDLE_HMI; \
- LOAD_REG_ADDR(r11,opal); \
- ld r12,8(r11); \
- ld r2,0(r11); \
- mtctr r12; \
- bctrl; \
+ li r3,OPAL_HANDLE_HMI; /* Pass opal token argument*/ \
+ bl opal_call_realmode; \
ld r3,ORIG_GPR3(r1); /* Restore original r3 */ \
20: nop;
@@ -166,12 +195,8 @@ BEGIN_FTR_SECTION
CHECK_HMI_INTERRUPT
END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
/* Time base re-sync */
- li r0,OPAL_RESYNC_TIMEBASE
- LOAD_REG_ADDR(r11,opal);
- ld r12,8(r11);
- ld r2,0(r11);
- mtctr r12
- bctrl
+ li r3,OPAL_RESYNC_TIMEBASE
+ bl opal_call_realmode;
/* TODO: Check r3 for failure */
^ permalink raw reply related
* Re: scheduler crash on Power
From: Dietmar Eggemann @ 2014-07-31 11:57 UTC (permalink / raw)
To: Sukadev Bhattiprolu, peterz@infrdead.org, bruno@wolff.to,
jwboyer@redhat.com
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140730072242.GA21516@us.ibm.com>
Hi Sukadev,
On 30/07/14 08:22, Sukadev Bhattiprolu wrote:
>=20
> I am getting this crash on a Powerpc system using 3.16.0-rc7 kernel plus
> some patches related to perf (24x7 counters) that Cody Schafer posted her=
e:
>=20
> =09https://lkml.org/lkml/2014/5/27/768
>=20
> I don't get the crash on an unpatched kernel though.
>=20
> I have been staring at the perf event patches, but can't find anything
> impacting the scheduler. Besides the patches had worked on 3.16.0-rc2
> kernel on a different Power system.
>=20
> The crash occurs on an idle system, a minute or two after booting to
> runlevel 3.
>=20
> kernel/sched/core.c:
>=20
> ---
> 5877 static void init_sched_groups_capacity(int cpu, struct sched_domain =
*sd)
> 5878 {
> 5879 struct sched_group *sg =3D sd->groups;
> 5880=20
> 5881 WARN_ON(!sg);
> 5882=20
> 5883 do {
> 5884 sg->group_weight =3D cpumask_weight(sched_group_cpus=
(sg));
>=20
> ---
>=20
>=20
> I tried applying the patch discussed in https://lkml.org/lkml/2014/7/16/3=
86
> but doesn't seem to help.
>=20
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index bc1638b..50702a8 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5842,6 +5842,8 @@ build_sched_groups(struct sched_domain *sd, int cpu=
)
> continue;
> =20
> group =3D get_group(i, sdd, &sg);
> + cpumask_clear(sched_group_cpus(sg));
> + sg->sgc->capacity =3D 0;
> cpumask_setall(sched_group_mask(sg));
> =20
> for_each_cpu(j, span) {
I don't think your problem is related to this one. None of the
'build_sched_groups: got group x with cpus:' show that a sched_group got
reused.
>=20
>=20
> I am also attaching the debug messages that Peterz added
> here: https://lkml.org/lkml/2014/7/17/288
>=20
> Appreciate any debug suggestions.
>=20
> Sukadev
>=20
>=20
> ----
> Red Hat Enterprise Linux Server 7.0 (Maipo)
> Kernel 3.16.0-rc7-24x7+ on an ppc64
>=20
> ltcbrazos2-lp07 login:=20
>=20
> Red Hat Enterprise Linux Server 7.0 (Maipo)
> Kernel 3.16.0-rc7-24x7+ on an ppc64
>=20
> ltcbrazos2-lp07 login: [ 181.915974] ------------[ cut here ]-----------=
-
> [ 181.915991] WARNING: at ../kernel/sched/core.c:5881
This warning indicates the problem. One of the struct sched_domains does
not have it's groups member set.
And its happening during a rebuild of the sched domain hierarchy, not
during the initial build.
You could run your system with the following patch-let (on top of
https://lkml.org/lkml/2014/7/17/288) w/ and w/o the perf related
patches (w/ CONFIG_SCHED_DEBUG enabled).
@@ -5882,6 +5882,9 @@ static void init_sched_groups_capacity(int cpu,
struct sched_domain *sd)
{
struct sched_group *sg =3D sd->groups;
+#ifdef CONFIG_SCHED_DEBUG
+ printk("sd name: %s span: %pc\n", sd->name, sd->span);
+#endif
WARN_ON(!sg);
do {
This will show if the rebuild of the sched domain hierarchy happens on
both systems and hopefully indicate for which sched_domain the
sd->groups is not set.
> [ 181.915994] Modules linked in: sg cfg80211 rfkill nx_crypto ibmveth ps=
eries_rng xfs libcrc32c sd_mod crc_t10dif crct10dif_common ibmvscsi scsi_tr=
ansport_srp scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
> [ 181.916024] CPU: 4 PID: 1087 Comm: kworker/4:2 Not tainted 3.16.0-rc7-=
24x7+ #15
> [ 181.916034] Workqueue: events .topology_work_fn
> [ 181.916038] task: c0000000dbd40000 ti: c0000000da400000 task.ti: c0000=
000da400000
> [ 181.916043] NIP: c0000000000d7528 LR: c0000000000d7578 CTR: 0000000000=
000000
> [ 181.916047] REGS: c0000000da403580 TRAP: 0700 Not tainted (3.16.0-r=
c7-24x7+)
> [ 181.916051] MSR: 8000000100029032 <SF,EE,ME,IR,DR,RI> CR: 28484c24 X=
ER: 00000000
> [ 181.916063] CFAR: c0000000000d74f4 SOFTE: 1=20
> GPR00: c0000000000d7578 c0000000da403800 c000000000eaa7f0 000000000000080=
0=20
> GPR04: 0000000000000800 0000000000000800 0000000000000000 c0000000009cf87=
8=20
> GPR08: c0000000009cf880 0000000000000001 0000000000000010 000000000000000=
0=20
> GPR12: 0000000000000000 c00000000ebe1200 0000000000000800 c0000000cc2f000=
0=20
> GPR16: c000000000ef0a68 0000000000000078 c0000000e5000000 000000000000007=
8=20
> GPR20: 0000000000000000 0000000000000001 c0000000cc2f0000 000000000000000=
1=20
> GPR24: c000000000db4402 000000000000000f 0000000000000000 c0000000dea3930=
0=20
> GPR28: c000000000ef0ae0 c0000000e5440000 0000000000000000 c000000000ef4f7=
c=20
> [ 181.916146] NIP [c0000000000d7528] .build_sched_domains+0xc28/0xd90
> [ 181.916151] LR [c0000000000d7578] .build_sched_domains+0xc78/0xd90
> [ 181.916155] Call Trace:
> [ 181.916159] [c0000000da403800] [c0000000000d7578] .build_sched_domains=
+0xc78/0xd90 (unreliable)
> [ 181.916166] [c0000000da403950] [c0000000000d7950] .partition_sched_dom=
ains+0x260/0x3f0
> [ 181.916175] [c0000000da403a30] [c000000000141704] .rebuild_sched_domai=
ns_locked+0x54/0x70
> [ 181.916182] [c0000000da403ab0] [c000000000143a98] .rebuild_sched_domai=
ns+0x28/0x50
> [ 181.916188] [c0000000da403b30] [c00000000004f250] .topology_work_fn+0x=
10/0x30
> [ 181.916194] [c0000000da403ba0] [c0000000000b7100] .process_one_work+0x=
1a0/0x4c0
> [ 181.916199] [c0000000da403c40] [c0000000000b7970] .worker_thread+0x180=
/0x630
> [ 181.916205] [c0000000da403d30] [c0000000000bfc88] .kthread+0x108/0x130
> [ 181.916214] [c0000000da403e30] [c00000000000a3e4] .ret_from_kernel_thr=
ead+0x58/0x74
> [ 181.916220] Instruction dump:
> [ 181.916223] 7f47492a e93c0000 e90a0010 7d0a4378 7d4a482a 814a0000 2f8a=
0000 419e0008=20
> [ 181.916235] 7f48492a ebdd0010 7fc90074 7929d182 <0b090000> 48000014 60=
000000 60000000=20
> [ 181.916245] ---[ end trace 6e9d20016598c36c ]---
> [ 181.916253] Unable to handle kernel paging request for data at address=
0x00000018
> [ 181.916257] Faulting instruction address: 0xc00000000039d1c0
> [ 181.916263] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 181.916267] SMP NR_CPUS=3D2048 NUMA pSeries
> [ 181.916271] Modules linked in: sg cfg80211 rfkill nx_crypto ibmveth ps=
eries_rng xfs libcrc32c sd_mod crc_t10dif crct10dif_common ibmvscsi scsi_tr=
ansport_srp scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
> [ 181.916293] CPU: 4 PID: 1087 Comm: kworker/4:2 Tainted: G W =
3.16.0-rc7-24x7+ #15
> [ 181.916299] Workqueue: events .topology_work_fn
> [ 181.916303] task: c0000000dbd40000 ti: c0000000da400000 task.ti: c0000=
000da400000
> [ 181.916309] NIP: c00000000039d1c0 LR: c0000000000d754c CTR: 0000000000=
000000
> [ 181.916313] REGS: c0000000da4034d0 TRAP: 0300 Tainted: G W =
(3.16.0-rc7-24x7+)
> [ 181.916317] MSR: 8000000100009032 <SF,EE,ME,IR,DR,RI> CR: 28484c24 X=
ER: 00000000
> [ 181.916327] CFAR: c000000000009358 DAR: 0000000000000018 DSISR: 400000=
00 SOFTE: 1=20
> GPR00: c0000000000d754c c0000000da403750 c000000000eaa7f0 000000000000001=
8=20
> GPR04: 0000000000000800 0000000000000800 0000000000000000 c0000000009cf87=
8=20
> GPR08: c0000000009cf880 0000000000000001 0000000000000010 000000000000000=
0=20
> GPR12: 0000000000000000 c00000000ebe1200 0000000000000800 c0000000cc2f000=
0=20
> GPR16: c000000000ef0a68 0000000000000078 c0000000e5000000 000000000000007=
8=20
> GPR20: 0000000000000000 0000000000000001 c0000000cc2f0000 000000000000000=
1=20
> GPR24: c000000000db4402 0000000000000020 0000000000000018 000000000000080=
0=20
> GPR28: 0000000000000020 0000000000000110 0000000000000000 000000000000001=
0=20
> [ 181.916406] NIP [c00000000039d1c0] .__bitmap_weight+0x70/0x100
> [ 181.916411] LR [c0000000000d754c] .build_sched_domains+0xc4c/0xd90
> [ 181.916415] Call Trace:
> [ 181.916418] [c0000000da403750] [c0000000da403800] 0xc0000000da403800 (=
unreliable)
> [ 181.916424] [c0000000da403800] [c0000000000d754c] .build_sched_domains=
+0xc4c/0xd90
> [ 181.916430] [c0000000da403950] [c0000000000d7950] .partition_sched_dom=
ains+0x260/0x3f0
> [ 181.916436] [c0000000da403a30] [c000000000141704] .rebuild_sched_domai=
ns_locked+0x54/0x70
> [ 181.916442] [c0000000da403ab0] [c000000000143a98] .rebuild_sched_domai=
ns+0x28/0x50
> [ 181.916448] [c0000000da403b30] [c00000000004f250] .topology_work_fn+0x=
10/0x30
> [ 181.916453] [c0000000da403ba0] [c0000000000b7100] .process_one_work+0x=
1a0/0x4c0
> [ 181.916458] [c0000000da403c40] [c0000000000b7970] .worker_thread+0x180=
/0x630
> [ 181.916463] [c0000000da403d30] [c0000000000bfc88] .kthread+0x108/0x130
> [ 181.916468] [c0000000da403e30] [c00000000000a3e4] .ret_from_kernel_thr=
ead+0x58/0x74
> [ 181.916472] Instruction dump:
> [ 181.916475] 409d00b4 3bbcffff 3be3fff8 7bbd1f48 3bc00000 7fa3ea14 4800=
0018 60000000=20
> [ 181.916484] 60000000 60000000 60000000 60420000 <e87f0009> 4bcb74e9 60=
000000 7fbfe840=20
> [ 181.916493] ---[ end trace 6e9d20016598c36d ]---
> [ 181.924408]=20
> [ 183.931081] Kernel panic - not syncing: Fatal exception
> [ 183.954314] Rebooting in 10 seconds..
>=20
^ 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