* Re: Failure to detect PCI card
From: David Hawkins @ 2013-08-05 21:08 UTC (permalink / raw)
To: Peter LaDow; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <CAN8Q1EcnT3We1X22pw4AQ28xmd2d-XB9nTzZ2KdVb=qOx4j7-Q@mail.gmail.com>
Hi Pete,
>> 1. Have you checked the power supplies on the PCI board?
>>
>> PCI boards can be powered from 3.3V or 5V, or both. I've had
>> old PCs that only supply one or the other rail, and various
>> evaluation boards that only supply 3.3V.
>>
>> If you can put together a "working" x86 setup that detects the
>> board, then you could poke around and see what voltages exist
>> on some of the decoupling components, then plug it into your
>> real system, and see what voltages you measure there.
>
> These are universal boards. Our board does only support only 3V3 (and
> is slotted as such).
Ok.
>> 2. Have you probed the PCI bus using a bus analyzer or scope?
>>
>> If you have a PCI bus analyzer (or can find someone with one),
>> plug it in and see what happens at power-on (there should be
>> configuration cycles).
>>
>> At a minimum, if you have a 'scope, see if the PCI configuration
>> space access handshakes are active during power-on.
>
> Hmm...I do have one. But I can't get both the analyzer and the card
> in the system in at the same time.
My analyzer has an extender card that you first plug in, and then
plug the board into that ... any chance someone in your organization
has one of those cards? Alternatively, confirm the board works in
a machine that has more than one slot, and if it does not, use the
analyzer to see what is happening.
>> 3. Is debugging this PCI card worth your time?
>>
>> Sometimes the "solution" involves tossing old hardware in
>> the trash.
>
> Well, this is part of the ongoing work regarding the incoming PCI
> memory corruption.
Ok, I recall seeing that thread.
> We are going down the path of abandoning the 82540
> for our platform because we can't seem to track down the corruption.
> So we are looking at other chipsets which we can purchase, which
> include this National (now TI) chipset on the Netgear FA331. If we
> could find a PCI (_not_ PCIe) card to test with that seems to work...
>
> Interestingly, I have an older 3com 3C905TXM exhibiting the same
> behavior. Both of these are older cards (they even came with drivers
> on--gasp--floppies!). Maybe the lack of a 5V supply is an issue...
If you're looking for a PCI target that you can completely control,
then if you have an "FPGA guy" in your company, perhaps he can
dig up a low-cost PCI card that you can configure as a PCI master
to emulate the functions of a network card.
Actually, before going down that route, I would get a PCI extender
that you can use to trace the traffic with your board. Does the
network card use 33MHz or 66MHz?
Cheers,
Dave
^ permalink raw reply
* Re: Failure to detect PCI card
From: Peter LaDow @ 2013-08-05 20:49 UTC (permalink / raw)
To: David Hawkins; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <52000ACA.1010606@ovro.caltech.edu>
On Mon, Aug 5, 2013 at 1:27 PM, David Hawkins <dwh@ovro.caltech.edu> wrote:
> 1. Have you checked the power supplies on the PCI board?
>
> PCI boards can be powered from 3.3V or 5V, or both. I've had
> old PCs that only supply one or the other rail, and various
> evaluation boards that only supply 3.3V.
>
> If you can put together a "working" x86 setup that detects the
> board, then you could poke around and see what voltages exist
> on some of the decoupling components, then plug it into your
> real system, and see what voltages you measure there.
These are universal boards. Our board does only support only 3V3 (and
is slotted as such).
> 2. Have you probed the PCI bus using a bus analyzer or scope?
>
> If you have a PCI bus analyzer (or can find someone with one),
> plug it in and see what happens at power-on (there should be
> configuration cycles).
>
> At a minimum, if you have a 'scope, see if the PCI configuration
> space access handshakes are active during power-on.
Hmm...I do have one. But I can't get both the analyzer and the card
in the system in at the same time.
> 3. Is debugging this PCI card worth your time?
>
> Sometimes the "solution" involves tossing old hardware in
> the trash.
Well, this is part of the ongoing work regarding the incoming PCI
memory corruption. We are going down the path of abandoning the 82540
for our platform because we can't seem to track down the corruption.
So we are looking at other chipsets which we can purchase, which
include this National (now TI) chipset on the Netgear FA331. If we
could find a PCI (_not_ PCIe) card to test with that seems to work...
Interestingly, I have an older 3com 3C905TXM exhibiting the same
behavior. Both of these are older cards (they even came with drivers
on--gasp--floppies!). Maybe the lack of a 5V supply is an issue...
Thanks,
Pete
^ permalink raw reply
* Re: Failure to detect PCI card
From: David Hawkins @ 2013-08-05 20:27 UTC (permalink / raw)
To: Peter LaDow; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <CAN8Q1EfoLTDr-x0r82Ezpqak+R=QuL1o37_OVU3Q0=8zFfDMqA@mail.gmail.com>
Hi Pete,
> On Mon, Aug 5, 2013 at 11:25 AM, Anatolij Gustschin <agust@denx.de> wrote:
>> Maybe this card needs bigger delay to respond after PCI reset. You can
>> try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000
>> for CONFIG_PCI_BOOTDELAY in the first step and if detection works,
>> try to decrease this value.
>
> That didn't work. But perhaps the problem is because these are older
> PCI parts, and don't implement ECAM (only the older CAM)? I don't
> think u-boot limits itself...
Since you're looking for suggestions (apologies if these are
"too obvious");
1. Have you checked the power supplies on the PCI board?
PCI boards can be powered from 3.3V or 5V, or both. I've had
old PCs that only supply one or the other rail, and various
evaluation boards that only supply 3.3V.
If you can put together a "working" x86 setup that detects the
board, then you could poke around and see what voltages exist
on some of the decoupling components, then plug it into your
real system, and see what voltages you measure there.
2. Have you probed the PCI bus using a bus analyzer or scope?
If you have a PCI bus analyzer (or can find someone with one),
plug it in and see what happens at power-on (there should be
configuration cycles).
At a minimum, if you have a 'scope, see if the PCI configuration
space access handshakes are active during power-on.
3. Is debugging this PCI card worth your time?
Sometimes the "solution" involves tossing old hardware in
the trash.
Cheers,
Dave
^ permalink raw reply
* Re: Failure to detect PCI card
From: Peter LaDow @ 2013-08-05 20:12 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20130805202559.0086e806@crub>
On Mon, Aug 5, 2013 at 11:25 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Maybe this card needs bigger delay to respond after PCI reset. You can
> try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000
> for CONFIG_PCI_BOOTDELAY in the first step and if detection works,
> try to decrease this value.
That didn't work. But perhaps the problem is because these are older
PCI parts, and don't implement ECAM (only the older CAM)? I don't
think u-boot limits itself...
Thanks,
Pete
^ permalink raw reply
* [PATCH v3 2/2] powerpc: Convert platforms to smp_generic_cpu_bootable
From: Andy Fleming @ 2013-08-05 19:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1375732715-22830-1-git-send-email-afleming@freescale.com>
T4, Cell, powernv, and pseries had the same implementation, so switch
them to use a generic version. A2 apparently had a version, but
removed it at some point, so we remove the declaration, too.
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
v3: No change
v2: Removed Change-Id
arch/powerpc/platforms/85xx/smp.c | 1 +
arch/powerpc/platforms/cell/smp.c | 15 +--------------
arch/powerpc/platforms/powernv/smp.c | 18 +-----------------
arch/powerpc/platforms/pseries/smp.c | 18 +-----------------
arch/powerpc/platforms/wsp/wsp.h | 1 -
5 files changed, 4 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 5ced4f5..ea9c626 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -255,6 +255,7 @@ out:
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
+ .cpu_bootable = smp_generic_cpu_bootable,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_disable = generic_cpu_disable,
.cpu_die = generic_cpu_die,
diff --git a/arch/powerpc/platforms/cell/smp.c b/arch/powerpc/platforms/cell/smp.c
index f75f6fc..90745ea 100644
--- a/arch/powerpc/platforms/cell/smp.c
+++ b/arch/powerpc/platforms/cell/smp.c
@@ -136,25 +136,12 @@ static int smp_cell_kick_cpu(int nr)
return 0;
}
-static int smp_cell_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
- * during boot if the user requests it. Odd-numbered
- * cpus are assumed to be secondary threads.
- */
- if (system_state == SYSTEM_BOOTING &&
- cpu_has_feature(CPU_FTR_SMT) &&
- !smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
- return 0;
-
- return 1;
-}
static struct smp_ops_t bpa_iic_smp_ops = {
.message_pass = iic_message_pass,
.probe = smp_iic_probe,
.kick_cpu = smp_cell_kick_cpu,
.setup_cpu = smp_cell_setup_cpu,
- .cpu_bootable = smp_cell_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
};
/* This is called very early */
diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
index 89e3857..908672b 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -46,22 +46,6 @@ static void pnv_smp_setup_cpu(int cpu)
xics_setup_cpu();
}
-static int pnv_smp_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
- * during boot if the user requests it.
- */
- if (system_state == SYSTEM_BOOTING && cpu_has_feature(CPU_FTR_SMT)) {
- if (!smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
- return 0;
- if (smt_enabled_at_boot
- && cpu_thread_in_core(nr) >= smt_enabled_at_boot)
- return 0;
- }
-
- return 1;
-}
-
int pnv_smp_kick_cpu(int nr)
{
unsigned int pcpu = get_hard_smp_processor_id(nr);
@@ -195,7 +179,7 @@ static struct smp_ops_t pnv_smp_ops = {
.probe = xics_smp_probe,
.kick_cpu = pnv_smp_kick_cpu,
.setup_cpu = pnv_smp_setup_cpu,
- .cpu_bootable = pnv_smp_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_disable = pnv_smp_cpu_disable,
.cpu_die = generic_cpu_die,
diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
index 306643c..ca2d1f6 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -187,22 +187,6 @@ static int smp_pSeries_kick_cpu(int nr)
return 0;
}
-static int smp_pSeries_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
- * during boot if the user requests it.
- */
- if (system_state == SYSTEM_BOOTING && cpu_has_feature(CPU_FTR_SMT)) {
- if (!smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
- return 0;
- if (smt_enabled_at_boot
- && cpu_thread_in_core(nr) >= smt_enabled_at_boot)
- return 0;
- }
-
- return 1;
-}
-
/* Only used on systems that support multiple IPI mechanisms */
static void pSeries_cause_ipi_mux(int cpu, unsigned long data)
{
@@ -237,7 +221,7 @@ static struct smp_ops_t pSeries_xics_smp_ops = {
.probe = pSeries_smp_probe,
.kick_cpu = smp_pSeries_kick_cpu,
.setup_cpu = smp_xics_setup_cpu,
- .cpu_bootable = smp_pSeries_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
};
/* This is called very early */
diff --git a/arch/powerpc/platforms/wsp/wsp.h b/arch/powerpc/platforms/wsp/wsp.h
index 62ef21a..a563a8a 100644
--- a/arch/powerpc/platforms/wsp/wsp.h
+++ b/arch/powerpc/platforms/wsp/wsp.h
@@ -17,7 +17,6 @@ extern void scom_init_wsp(void);
extern void a2_setup_smp(void);
extern int a2_scom_startup_cpu(unsigned int lcpu, int thr_idx,
struct device_node *np);
-extern int smp_a2_cpu_bootable(unsigned int nr);
extern int smp_a2_kick_cpu(int nr);
extern void opb_pic_init(void);
--
1.7.9.7
^ permalink raw reply related
* [PATCH v3 1/2] powerpc: Add smp_generic_cpu_bootable
From: Andy Fleming @ 2013-08-05 19:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Cell and PSeries both implemented their own versions of a
cpu_bootable smp_op which do the same thing (well, the PSeries
one has support for more than 2 threads). Copy the PSeries one
to generic code, and rename it smp_generic_cpu_bootable.
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
v3: Removed EXPORT_SYMBOL()
v2: Removed Change-Id
arch/powerpc/include/asm/smp.h | 2 ++
arch/powerpc/kernel/smp.c | 22 ++++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 48cfc85..9a5e71b 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -186,6 +186,8 @@ extern int smt_enabled_at_boot;
extern int smp_mpic_probe(void);
extern void smp_mpic_setup_cpu(int cpu);
extern int smp_generic_kick_cpu(int nr);
+extern int smp_generic_cpu_bootable(unsigned int nr);
+
extern void smp_generic_give_timebase(void);
extern void smp_generic_take_timebase(void);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..d947735 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -81,6 +81,28 @@ int smt_enabled_at_boot = 1;
static void (*crash_ipi_function_ptr)(struct pt_regs *) = NULL;
+/*
+ * Returns 1 if the specified cpu should be brought up during boot.
+ * Used to inhibit booting threads if they've been disabled or
+ * limited on the command line
+ */
+int smp_generic_cpu_bootable(unsigned int nr)
+{
+ /* Special case - we inhibit secondary thread startup
+ * during boot if the user requests it.
+ */
+ if (system_state == SYSTEM_BOOTING && cpu_has_feature(CPU_FTR_SMT)) {
+ if (!smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
+ return 0;
+ if (smt_enabled_at_boot
+ && cpu_thread_in_core(nr) >= smt_enabled_at_boot)
+ return 0;
+ }
+
+ return 1;
+}
+
+
#ifdef CONFIG_PPC64
int smp_generic_kick_cpu(int nr)
{
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH 00/11] Add compression support to pstore
From: Aruna Balakrishnaiah @ 2013-08-05 19:41 UTC (permalink / raw)
To: Tony Luck
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
linux-kernel@vger.kernel.org, keescook@chromium.org
In-Reply-To: <CA+8MBb+1LpR+Cx=84WZT98U5eqZcm1KriUP75aCg+uSrXrb3Yw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6794 bytes --]
Hi Tony,
On Monday 05 August 2013 11:52 PM, Tony Luck wrote:
> See attachment for what I actually applied - I think I got what you
> suggested (I added a declaration for "total_len").
>
> Forcing a panic worked some things were logged to pstore.
>
> But on reboot with your patches applied I'm still seeing a GP fault
> when pstore is mounted and we find compressed records and inflate them
> and install them into the pstore filesystem. Here's the oops:
>
> general protection fault: 0000 [#1] SMP
> Modules linked in:
> CPU: 29 PID: 10252 Comm: mount Not tainted 3.11.0-rc3-12-g73bec18 #2
> Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS
> SE5C600.86B.99.99.x059.091020121352 09/10/2012
> task: ffff88082e934040 ti: ffff88082e2ec000 task.ti: ffff88082e2ec000
> RIP: 0010:[<ffffffff8126d314>] [<ffffffff8126d314>] pstore_mkfile+0x84/0x410
> RSP: 0018:ffff88082e2edc70 EFLAGS: 00010007
> RAX: 0000000000000246 RBX: ffffffff81ca7b20 RCX: 625f6963703e373c
> RDX: 0000000000040004 RSI: 0000000000000004 RDI: ffffffff820aa7e8
> RBP: ffff88082e2edd10 R08: ffff881026a48000 R09: 0000000000000000
> R10: ffff88102d21efb8 R11: 0000000000000000 R12: ffff881026a48000
> R13: 51ffe35600000003 R14: 0000000000000000 R15: 0000000000004450
> FS: 00007fbd37a2d7e0(0000) GS:ffff88103fca0000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fbd37a47000 CR3: 000000103dc78000 CR4: 00000000000407e0
> Stack:
> ffff881026a4c450 0000000000005227 ffffffff81a3703d ffff881026a48000
> 2e2edd7000000000 ffff88103db34140 000000000001abaf 3638303900000000
> 0000003a00000fb8 ffff881026a48000 ffff88102d21e000 000000000000448a
> Call Trace:
> [<ffffffff8126dd7d>] pstore_get_records+0xed/0x2c0
> [<ffffffff8126cfa0>] ? pstore_get_inode+0x50/0x50
> [<ffffffff8126d042>] pstore_fill_super+0xa2/0xc0
> [<ffffffff811691f2>] mount_single+0xa2/0xd0
> [<ffffffff8126ce28>] pstore_mount+0x18/0x20
> [<ffffffff811693e3>] mount_fs+0x43/0x1b0
> [<ffffffff8112dc40>] ? __alloc_percpu+0x10/0x20
> [<ffffffff8118256f>] vfs_kern_mount+0x6f/0x100
> [<ffffffff81184a79>] do_mount+0x259/0xa10
> [<ffffffff81128bcb>] ? strndup_user+0x5b/0x80
> [<ffffffff811852be>] SyS_mount+0x8e/0xe0
> [<ffffffff81606802>] system_call_fastpath+0x16/0x1b
> Code: 88 e8 f1 0f 39 00 48 8b 0d 0a 3a a2 00 48 81 f9 00 0d c9 81 75
> 15 eb 67 0f 1f 80 00 00 00 00 48 8b 09 48 81 f9 00 0d c9 81 74 54 <44>
> 39 71 18 75 ee 4c 39 69 20 75 e8 48 39 59 10 75 e2 48 89 c6
> RIP [<ffffffff8126d314>] pstore_mkfile+0x84/0x410
> RSP <ffff88082e2edc70>
> ---[ end trace 0e1dd8e3ccfa3dcc ]---
> /etc/init.d/functions: line 530: 10252 Segmentation fault "$@"
>
> Here's the start of my pstore_mkfile() code where the GP fault occurred:
>
> ffffffff8126d290 <pstore_mkfile>:
> ffffffff8126d290: e8 2b 91 39 00 callq
> ffffffff816063c0 <__fentry__>
> ffffffff8126d295: 55 push %rbp
> ffffffff8126d296: 48 89 e5 mov %rsp,%rbp
> ffffffff8126d299: 41 57 push %r15
> ffffffff8126d29b: 41 56 push %r14
> ffffffff8126d29d: 41 89 fe mov %edi,%r14d
> ffffffff8126d2a0: 48 c7 c7 e8 a7 0a 82 mov $0xffffffff820aa7e8,%rdi
> ffffffff8126d2a7: 41 55 push %r13
> ffffffff8126d2a9: 49 89 d5 mov %rdx,%r13
> ffffffff8126d2ac: 41 54 push %r12
> ffffffff8126d2ae: 53 push %rbx
> ffffffff8126d2af: 48 83 ec 78 sub $0x78,%rsp
> ffffffff8126d2b3: 89 4d 84 mov %ecx,-0x7c(%rbp)
> ffffffff8126d2b6: 48 89 b5 70 ff ff ff mov %rsi,-0x90(%rbp)
> ffffffff8126d2bd: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
> ffffffff8126d2c4: 00 00
> ffffffff8126d2c6: 48 89 45 d0 mov %rax,-0x30(%rbp)
> ffffffff8126d2ca: 31 c0 xor %eax,%eax
> ffffffff8126d2cc: 48 8b 05 0d d5 e3 00 mov
> 0xe3d50d(%rip),%rax # ffffffff820aa7e0 <pstore_sb>
> ffffffff8126d2d3: 4c 89 85 78 ff ff ff mov %r8,-0x88(%rbp)
> ffffffff8126d2da: 44 89 4d 80 mov %r9d,-0x80(%rbp)
> ffffffff8126d2de: 48 8b 5d 28 mov 0x28(%rbp),%rbx
> ffffffff8126d2e2: 48 8b 40 60 mov 0x60(%rax),%rax
> ffffffff8126d2e6: 48 89 45 88 mov %rax,-0x78(%rbp)
> ffffffff8126d2ea: e8 f1 0f 39 00 callq
> ffffffff815fe2e0 <_raw_spin_lock_irqsave>
> ffffffff8126d2ef: 48 8b 0d 0a 3a a2 00 mov
> 0xa23a0a(%rip),%rcx # ffffffff81c90d00 <allpstore>
> ffffffff8126d2f6: 48 81 f9 00 0d c9 81 cmp $0xffffffff81c90d00,%rcx
> ffffffff8126d2fd: 75 15 jne
> ffffffff8126d314 <pstore_mkfile+0x84>
> ffffffff8126d2ff: eb 67 jmp
> ffffffff8126d368 <pstore_mkfile+0xd8>
> ffffffff8126d301: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> ffffffff8126d308: 48 8b 09 mov (%rcx),%rcx
> ffffffff8126d30b: 48 81 f9 00 0d c9 81 cmp $0xffffffff81c90d00,%rcx
> ffffffff8126d312: 74 54 je
> ffffffff8126d368 <pstore_mkfile+0xd8>
> ffffffff8126d314: 44 39 71 18 cmp
> %r14d,0x18(%rcx) <<<<<<<<<< GP fault here
> ffffffff8126d318: 75 ee jne
> ffffffff8126d308 <pstore_mkfile+0x78>
> ffffffff8126d31a: 4c 39 69 20 cmp %r13,0x20(%rcx)
> ffffffff8126d31e: 75 e8 jne
> ffffffff8126d308 <pstore_mkfile+0x78>
> ffffffff8126d320: 48 39 59 10 cmp %rbx,0x10(%rcx)
> ffffffff8126d324: 75 e2 jne
> ffffffff8126d308 <pstore_mkfile+0x78>
> ffffffff8126d326: 48 89 c6 mov %rax,%rsi
> ffffffff8126d329: 48 c7 c7 e8 a7 0a 82 mov $0xffffffff820aa7e8,%rdi
> ffffffff8126d330: e8 1b 0d 39 00 callq
> ffffffff815fe050 <_raw_spin_unlock_irqrestore>
>
> Booting a vanilla v3.11-rc4 kernel I can see the files pstore - but
> they still seem to have
> corruption/missing data at the end when I decode with openssl zlib -d :-(
>
> So start by peering at the path that I applied to make sure I didn't mess up.
Strangely I am not ablereproduce this on power or on system-x. With system-x I was
able to loga single record and decompression did not give me any junk characters
at the
end. Not sure if its the header which is missing.If it was I should have encountered
same issue on Power too. Please give a final try with the patch I have attached
and I
will dig into this more tomorrow. Patch to be applied on top of my patch series
(without your fix patch).
- Aruna
>
> -Tony
[-- Attachment #2: pstore_fix.patch --]
[-- Type: text/x-patch, Size: 1651 bytes --]
commit 35b489152ae8f673fa79e7eeffc0bc8503c608b6
Author: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Date: Tue Aug 6 00:08:35 2013 +0530
pstore: fix for the junk characters at the end
Signed-off-by: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 8f3e5f0..3446c99 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -283,7 +283,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
unsigned long size, big_buf_sz;
int hsize = 0;
int zipped_len = -1;
- size_t len;
+ size_t len, total_len;
bool compressed;
big_buf_sz = (psinfo->bufsize * 100) / 45;
@@ -293,9 +293,8 @@ static void pstore_dump(struct kmsg_dumper *dumper,
hsize = sprintf(dst, "%s#%d Part%d\n", why,
oopscount, part);
size = big_buf_sz - hsize;
- dst += hsize;
- if (!kmsg_dump_get_buffer(dumper, true, dst,
+ if (!kmsg_dump_get_buffer(dumper, true, dst + hsize,
size, &len))
break;
@@ -313,17 +312,18 @@ static void pstore_dump(struct kmsg_dumper *dumper,
if (!kmsg_dump_get_buffer(dumper, true, dst,
size, &len))
break;
+ total_len = hsize + len;
} else {
compressed = true;
- len = zipped_len;
+ total_len = zipped_len;
}
ret = psinfo->write(PSTORE_TYPE_DMESG, reason, &id, part,
- oopscount, compressed, hsize + len, psinfo);
+ oopscount, compressed, total_len, psinfo);
if (ret == 0 && reason == KMSG_DUMP_OOPS && pstore_is_mounted())
pstore_new_entry = 1;
- total += hsize + len;
+ total += total_len;
part++;
}
if (pstore_cannot_block_path(reason)) {
^ permalink raw reply related
* Re: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like booke3s
From: Scott Wood @ 2013-08-05 19:19 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, kvm@vger.kernel.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D070FAD49@039-SN2MPN1-012.039d.mgd.msft.net>
On Mon, 2013-08-05 at 09:27 -0500, Bhushan Bharat-R65777 wrote:
>
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Sent: Saturday, August 03, 2013 9:54 AM
> > To: Bhushan Bharat-R65777
> > Cc: Wood Scott-B07421; agraf@suse.de; kvm-ppc@vger.kernel.org;
> > kvm@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like
> > booke3s
> >
> > On Sat, 2013-08-03 at 02:58 +0000, Bhushan Bharat-R65777 wrote:
> > > One of the problem I saw was that if I put this code in
> > > asm/pgtable-32.h and asm/pgtable-64.h then pte_persent() and other
> > > friend function (on which this code depends) are defined in pgtable.h.
> > > And pgtable.h includes asm/pgtable-32.h and asm/pgtable-64.h before it
> > > defines pte_present() and friends functions.
> > >
> > > Ok I move wove this in asm/pgtable*.h, initially I fought with myself
> > > to take this code in pgtable* but finally end up doing here (got
> > > biased by book3s :)).
> >
> > Is there a reason why these routines can not be completely generic in pgtable.h
> > ?
>
> How about the generic function:
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
> index d257d98..21daf28 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -221,6 +221,27 @@ static inline unsigned long pte_update(struct mm_struct *mm,
> return old;
> }
>
> +static inline unsigned long pte_read(pte_t *p)
> +{
> +#ifdef PTE_ATOMIC_UPDATES
> + pte_t pte;
> + pte_t tmp;
> + __asm__ __volatile__ (
> + "1: ldarx %0,0,%3\n"
> + " andi. %1,%0,%4\n"
> + " bne- 1b\n"
> + " ori %1,%0,%4\n"
> + " stdcx. %1,0,%3\n"
> + " bne- 1b"
> + : "=&r" (pte), "=&r" (tmp), "=m" (*p)
> + : "r" (p), "i" (_PAGE_BUSY)
> + : "cc");
> +
> + return pte;
> +#else
> + return pte_val(*p);
> +#endif
> +#endif
> +}
> static inline int __ptep_test_and_clear_young(struct mm_struct *mm,
> unsigned long addr, pte_t *ptep)
Please leave a blank line between functions.
> {
> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
> index 690c8c2..dad712c 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -254,6 +254,45 @@ static inline pte_t *find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned long ea,
> }
> #endif /* !CONFIG_HUGETLB_PAGE */
>
> +static inline pte_t lookup_linux_pte(pgd_t *pgdir, unsigned long hva,
> + int writing, unsigned long *pte_sizep)
The name implies that it just reads the PTE. Setting accessed/dirty
shouldn't be an undocumented side-effect. Why can't the caller do that
(or a different function that the caller calls afterward if desired)?
Though even then you have the undocumented side effect of locking the
PTE on certain targets.
> +{
> + pte_t *ptep;
> + pte_t pte;
> + unsigned long ps = *pte_sizep;
> + unsigned int shift;
> +
> + ptep = find_linux_pte_or_hugepte(pgdir, hva, &shift);
> + if (!ptep)
> + return __pte(0);
> + if (shift)
> + *pte_sizep = 1ul << shift;
> + else
> + *pte_sizep = PAGE_SIZE;
> +
> + if (ps > *pte_sizep)
> + return __pte(0);
> +
> + if (!pte_present(*ptep))
> + return __pte(0);
> +
> +#ifdef CONFIG_PPC64
> + /* Lock PTE (set _PAGE_BUSY) and read */
> + pte = pte_read(ptep);
> +#else
> + pte = pte_val(*ptep);
> +#endif
What about 32-bit platforms that need atomic PTEs?
-Scott
^ permalink raw reply
* Re: Failure to detect PCI card
From: Peter LaDow @ 2013-08-05 18:36 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20130805183209.06686380495@gemini.denx.de>
On Mon, Aug 5, 2013 at 11:25 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Maybe this card needs bigger delay to respond after PCI reset. You can
> try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000
> for CONFIG_PCI_BOOTDELAY in the first step and if detection works,
> try to decrease this value.
I'll give this a try. But a generic question. Does the kernel depend
upon u-boot to initialize the PCI configuration?
And, I know this is a u-boot specific question, but will u-boot ignore
any PCI device it doesn't know about? Thus I have to enable a
specific device in the u-boot configuration for u-boot to recognize it
(and from there, have the kernel recognize it)?
On Mon, Aug 5, 2013 at 11:32 AM, Wolfgang Denk <wd@denx.de> wrote:
> Is there any chance that this card has some BIOS (like most graphic
> adapters do) which needs to run to put the card into an operative
> state (like by initializing any DRAM memory on the card)? OK, I would
> normally not expect such on a 10/100 PCI Ethernet network adapter, but
> I don't know this card at all...
Not that I'm aware of. I suppose the EEPROM to read in the
configuration/MAC address? But I wouldn't think an option ROM would
be present.
> Do you know if this card works in any other non-x86 system at all?
Don't have any other non-x86 systems to try out. We have an
MPC8349E-mITX board, but the PCI slot doesn't detect anything at all
(not even our 82540EM based board). And this card doesn't work there
either.
Thanks,
Pete
^ permalink raw reply
* Re: Failure to detect PCI card
From: Wolfgang Denk @ 2013-08-05 18:32 UTC (permalink / raw)
To: Peter LaDow; +Cc: linuxppc-dev
In-Reply-To: <CAN8Q1Ed-YtD1L7e9TaJyELdcz5Rcfdi0mdwU_H6HAx0-3FJ4Lg@mail.gmail.com>
Dear Peter LaDow,
In message <CAN8Q1Ed-YtD1L7e9TaJyELdcz5Rcfdi0mdwU_H6HAx0-3FJ4Lg@mail.gmail.com> you wrote:
> I have a PCI card (a Netgear FA331, vendor:device 100b:0020) that is
> failing to be detected by our PPC platform. This device works just
> fine in a PC, and other cards work just fine in the same PCI slot (we
> have an Intel 82540EM based card that works).
>
> But for some reason, neither u-boot nor the kernel detect this card.
> Any ideas why this might be?
Is there any chance that this card has some BIOS (like most graphic
adapters do) which needs to run to put the card into an operative
state (like by initializing any DRAM memory on the card)? OK, I would
normally not expect such on a 10/100 PCI Ethernet network adapter, but
I don't know this card at all...
Do you know if this card works in any other non-x86 system at all?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Quote from a recent meeting: "We are going to continue having these
meetings everyday until I find out why no work is getting done."
^ permalink raw reply
* Re: Failure to detect PCI card
From: Anatolij Gustschin @ 2013-08-05 18:25 UTC (permalink / raw)
To: Peter LaDow; +Cc: linuxppc-dev
In-Reply-To: <CAN8Q1Ed-YtD1L7e9TaJyELdcz5Rcfdi0mdwU_H6HAx0-3FJ4Lg@mail.gmail.com>
On Mon, 5 Aug 2013 10:58:01 -0700
Peter LaDow <petela@gocougs.wsu.edu> wrote:
> I have a PCI card (a Netgear FA331, vendor:device 100b:0020) that is
> failing to be detected by our PPC platform. This device works just
> fine in a PC, and other cards work just fine in the same PCI slot (we
> have an Intel 82540EM based card that works).
>
> But for some reason, neither u-boot nor the kernel detect this card.
> Any ideas why this might be?
Maybe this card needs bigger delay to respond after PCI reset. You can
try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000
for CONFIG_PCI_BOOTDELAY in the first step and if detection works,
try to decrease this value.
HTH,
Anatolij
^ permalink raw reply
* Re: [PATCH 00/11] Add compression support to pstore
From: Tony Luck @ 2013-08-05 18:22 UTC (permalink / raw)
To: Aruna Balakrishnaiah
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
linux-kernel@vger.kernel.org, keescook@chromium.org
In-Reply-To: <51FFDC8B.7010909@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 6032 bytes --]
See attachment for what I actually applied - I think I got what you
suggested (I added a declaration for "total_len").
Forcing a panic worked some things were logged to pstore.
But on reboot with your patches applied I'm still seeing a GP fault
when pstore is mounted and we find compressed records and inflate them
and install them into the pstore filesystem. Here's the oops:
general protection fault: 0000 [#1] SMP
Modules linked in:
CPU: 29 PID: 10252 Comm: mount Not tainted 3.11.0-rc3-12-g73bec18 #2
Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS
SE5C600.86B.99.99.x059.091020121352 09/10/2012
task: ffff88082e934040 ti: ffff88082e2ec000 task.ti: ffff88082e2ec000
RIP: 0010:[<ffffffff8126d314>] [<ffffffff8126d314>] pstore_mkfile+0x84/0x410
RSP: 0018:ffff88082e2edc70 EFLAGS: 00010007
RAX: 0000000000000246 RBX: ffffffff81ca7b20 RCX: 625f6963703e373c
RDX: 0000000000040004 RSI: 0000000000000004 RDI: ffffffff820aa7e8
RBP: ffff88082e2edd10 R08: ffff881026a48000 R09: 0000000000000000
R10: ffff88102d21efb8 R11: 0000000000000000 R12: ffff881026a48000
R13: 51ffe35600000003 R14: 0000000000000000 R15: 0000000000004450
FS: 00007fbd37a2d7e0(0000) GS:ffff88103fca0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fbd37a47000 CR3: 000000103dc78000 CR4: 00000000000407e0
Stack:
ffff881026a4c450 0000000000005227 ffffffff81a3703d ffff881026a48000
2e2edd7000000000 ffff88103db34140 000000000001abaf 3638303900000000
0000003a00000fb8 ffff881026a48000 ffff88102d21e000 000000000000448a
Call Trace:
[<ffffffff8126dd7d>] pstore_get_records+0xed/0x2c0
[<ffffffff8126cfa0>] ? pstore_get_inode+0x50/0x50
[<ffffffff8126d042>] pstore_fill_super+0xa2/0xc0
[<ffffffff811691f2>] mount_single+0xa2/0xd0
[<ffffffff8126ce28>] pstore_mount+0x18/0x20
[<ffffffff811693e3>] mount_fs+0x43/0x1b0
[<ffffffff8112dc40>] ? __alloc_percpu+0x10/0x20
[<ffffffff8118256f>] vfs_kern_mount+0x6f/0x100
[<ffffffff81184a79>] do_mount+0x259/0xa10
[<ffffffff81128bcb>] ? strndup_user+0x5b/0x80
[<ffffffff811852be>] SyS_mount+0x8e/0xe0
[<ffffffff81606802>] system_call_fastpath+0x16/0x1b
Code: 88 e8 f1 0f 39 00 48 8b 0d 0a 3a a2 00 48 81 f9 00 0d c9 81 75
15 eb 67 0f 1f 80 00 00 00 00 48 8b 09 48 81 f9 00 0d c9 81 74 54 <44>
39 71 18 75 ee 4c 39 69 20 75 e8 48 39 59 10 75 e2 48 89 c6
RIP [<ffffffff8126d314>] pstore_mkfile+0x84/0x410
RSP <ffff88082e2edc70>
---[ end trace 0e1dd8e3ccfa3dcc ]---
/etc/init.d/functions: line 530: 10252 Segmentation fault "$@"
Here's the start of my pstore_mkfile() code where the GP fault occurred:
ffffffff8126d290 <pstore_mkfile>:
ffffffff8126d290: e8 2b 91 39 00 callq
ffffffff816063c0 <__fentry__>
ffffffff8126d295: 55 push %rbp
ffffffff8126d296: 48 89 e5 mov %rsp,%rbp
ffffffff8126d299: 41 57 push %r15
ffffffff8126d29b: 41 56 push %r14
ffffffff8126d29d: 41 89 fe mov %edi,%r14d
ffffffff8126d2a0: 48 c7 c7 e8 a7 0a 82 mov $0xffffffff820aa7e8,%rdi
ffffffff8126d2a7: 41 55 push %r13
ffffffff8126d2a9: 49 89 d5 mov %rdx,%r13
ffffffff8126d2ac: 41 54 push %r12
ffffffff8126d2ae: 53 push %rbx
ffffffff8126d2af: 48 83 ec 78 sub $0x78,%rsp
ffffffff8126d2b3: 89 4d 84 mov %ecx,-0x7c(%rbp)
ffffffff8126d2b6: 48 89 b5 70 ff ff ff mov %rsi,-0x90(%rbp)
ffffffff8126d2bd: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
ffffffff8126d2c4: 00 00
ffffffff8126d2c6: 48 89 45 d0 mov %rax,-0x30(%rbp)
ffffffff8126d2ca: 31 c0 xor %eax,%eax
ffffffff8126d2cc: 48 8b 05 0d d5 e3 00 mov
0xe3d50d(%rip),%rax # ffffffff820aa7e0 <pstore_sb>
ffffffff8126d2d3: 4c 89 85 78 ff ff ff mov %r8,-0x88(%rbp)
ffffffff8126d2da: 44 89 4d 80 mov %r9d,-0x80(%rbp)
ffffffff8126d2de: 48 8b 5d 28 mov 0x28(%rbp),%rbx
ffffffff8126d2e2: 48 8b 40 60 mov 0x60(%rax),%rax
ffffffff8126d2e6: 48 89 45 88 mov %rax,-0x78(%rbp)
ffffffff8126d2ea: e8 f1 0f 39 00 callq
ffffffff815fe2e0 <_raw_spin_lock_irqsave>
ffffffff8126d2ef: 48 8b 0d 0a 3a a2 00 mov
0xa23a0a(%rip),%rcx # ffffffff81c90d00 <allpstore>
ffffffff8126d2f6: 48 81 f9 00 0d c9 81 cmp $0xffffffff81c90d00,%rcx
ffffffff8126d2fd: 75 15 jne
ffffffff8126d314 <pstore_mkfile+0x84>
ffffffff8126d2ff: eb 67 jmp
ffffffff8126d368 <pstore_mkfile+0xd8>
ffffffff8126d301: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
ffffffff8126d308: 48 8b 09 mov (%rcx),%rcx
ffffffff8126d30b: 48 81 f9 00 0d c9 81 cmp $0xffffffff81c90d00,%rcx
ffffffff8126d312: 74 54 je
ffffffff8126d368 <pstore_mkfile+0xd8>
ffffffff8126d314: 44 39 71 18 cmp
%r14d,0x18(%rcx) <<<<<<<<<< GP fault here
ffffffff8126d318: 75 ee jne
ffffffff8126d308 <pstore_mkfile+0x78>
ffffffff8126d31a: 4c 39 69 20 cmp %r13,0x20(%rcx)
ffffffff8126d31e: 75 e8 jne
ffffffff8126d308 <pstore_mkfile+0x78>
ffffffff8126d320: 48 39 59 10 cmp %rbx,0x10(%rcx)
ffffffff8126d324: 75 e2 jne
ffffffff8126d308 <pstore_mkfile+0x78>
ffffffff8126d326: 48 89 c6 mov %rax,%rsi
ffffffff8126d329: 48 c7 c7 e8 a7 0a 82 mov $0xffffffff820aa7e8,%rdi
ffffffff8126d330: e8 1b 0d 39 00 callq
ffffffff815fe050 <_raw_spin_unlock_irqrestore>
Booting a vanilla v3.11-rc4 kernel I can see the files pstore - but
they still seem to have
corruption/missing data at the end when I decode with openssl zlib -d :-(
So start by peering at the path that I applied to make sure I didn't mess up.
-Tony
[-- Attachment #2: pstorefix.patch --]
[-- Type: application/octet-stream, Size: 1652 bytes --]
commit 73bec18293b7236409e9020eaa5b922bcacabd2f
Author: Tony Luck <tony.luck@intel.com>
Date: Mon Aug 5 10:32:34 2013 -0700
pstore: experimental fix for problems with junk at end of zipped files
In Message-ID: <51FFDC8B.7010909@linux.vnet.ibm.com> Aruna suggested
these modifications to avoid problems with garbage at the end of
compressed files.
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 8f3e5f0..876cc95 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -283,7 +283,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
unsigned long size, big_buf_sz;
int hsize = 0;
int zipped_len = -1;
- size_t len;
+ size_t len, total_len;
bool compressed;
big_buf_sz = (psinfo->bufsize * 100) / 45;
@@ -303,6 +303,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
}
if (zipped_len < 0) {
+ pr_err("Compression failed\n");
dst = psinfo->buf;
hsize = sprintf(dst, "%s#%d Part%d\n",
why, oopscount, part);
@@ -313,17 +314,18 @@ static void pstore_dump(struct kmsg_dumper *dumper,
if (!kmsg_dump_get_buffer(dumper, true, dst,
size, &len))
break;
+ total_len = hsize + len;
} else {
compressed = true;
- len = zipped_len;
+ total_len = zipped_len;
}
ret = psinfo->write(PSTORE_TYPE_DMESG, reason, &id, part,
- oopscount, compressed, hsize + len, psinfo);
+ oopscount, compressed, total_len, psinfo);
if (ret == 0 && reason == KMSG_DUMP_OOPS && pstore_is_mounted())
pstore_new_entry = 1;
- total += hsize + len;
+ total += total_len;
part++;
}
if (pstore_cannot_block_path(reason)) {
^ permalink raw reply related
* Failure to detect PCI card
From: Peter LaDow @ 2013-08-05 17:58 UTC (permalink / raw)
To: linuxppc-dev
I have a PCI card (a Netgear FA331, vendor:device 100b:0020) that is
failing to be detected by our PPC platform. This device works just
fine in a PC, and other cards work just fine in the same PCI slot (we
have an Intel 82540EM based card that works).
But for some reason, neither u-boot nor the kernel detect this card.
Any ideas why this might be?
Thanks,
Pete
^ permalink raw reply
* Re: [PATCH 03/10] vfio: add external user support
From: Alex Williamson @ 2013-08-05 17:18 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Alexander Graf, kvm-ppc, linux-kernel, Paul Mackerras,
linuxppc-dev, David Gibson
In-Reply-To: <51EE47DE.5020002@ozlabs.ru>
On Tue, 2013-07-23 at 19:07 +1000, Alexey Kardashevskiy wrote:
> On 07/23/2013 12:23 PM, Alex Williamson wrote:
> > On Tue, 2013-07-16 at 10:53 +1000, Alexey Kardashevskiy wrote:
> >> VFIO is designed to be used via ioctls on file descriptors
> >> returned by VFIO.
> >>
> >> However in some situations support for an external user is required.
> >> The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to
> >> use the existing VFIO groups for exclusive access in real/virtual mode
> >> on a host to avoid passing map/unmap requests to the user space which
> >> would made things pretty slow.
> >>
> >> The protocol includes:
> >>
> >> 1. do normal VFIO init operation:
> >> - opening a new container;
> >> - attaching group(s) to it;
> >> - setting an IOMMU driver for a container.
> >> When IOMMU is set for a container, all groups in it are
> >> considered ready to use by an external user.
> >>
> >> 2. User space passes a group fd to an external user.
> >> The external user calls vfio_group_get_external_user()
> >> to verify that:
> >> - the group is initialized;
> >> - IOMMU is set for it.
> >> If both checks passed, vfio_group_get_external_user()
> >> increments the container user counter to prevent
> >> the VFIO group from disposal before KVM exits.
> >>
> >> 3. The external user calls vfio_external_user_iommu_id()
> >> to know an IOMMU ID. PPC64 KVM uses it to link logical bus
> >> number (LIOBN) with IOMMU ID.
> >>
> >> 4. When the external KVM finishes, it calls
> >> vfio_group_put_external_user() to release the VFIO group.
> >> This call decrements the container user counter.
> >> Everything gets released.
> >>
> >> The "vfio: Limit group opens" patch is also required for the consistency.
> >>
> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >
> > This looks fine to me. Is the plan to add this through the ppc tree
> > again? Thanks,
>
>
> Nope, better to add this through your tree. And faster for sure :) Thanks!
Applied to my next branch for v3.12. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
From: Mike Turquette @ 2013-08-05 17:11 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: Anatolij Gustschin, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20130803143956.GH2580@book.gsilab.sittig.org>
Quoting Gerhard Sittig (2013-08-03 07:39:56)
> [ we are strictly talking about clocks and source code again,
> I have trimmed the CC: list to not spam the device tree ML or
> subsystem maintainers ]
> =
> On Fri, Aug 02, 2013 at 16:30 -0700, Mike Turquette wrote:
> > =
> > Quoting Gerhard Sittig (2013-07-23 06:14:06)
> > > [ summary: "shared gate" support desirable? approach acceptable? ]
> > > =
> > > On Mon, Jul 22, 2013 at 14:14 +0200, Gerhard Sittig wrote:
> > > > =
> > > > this change implements a clock driver for the MPC512x PowerPC platf=
orm
> > > > which follows the COMMON_CLK approach and uses common clock drivers
> > > > shared with other platforms
> > > > =
> > > > [ ... ]
> > > > =
> > > > some of the clock items get pre-enabled in the clock driver to not =
have
> > > > them automatically disabled by the underlying clock subsystem becau=
se of
> > > > their being unused -- this approach is desirable because
> > > > [ ... ]
> > > > - some help introduce support for and migrate to the common
> > > > infrastructure, while more appropriate support for specific hardw=
are
> > > > constraints isn't available yet (remaining changes are strictly
> > > > internal to the clock driver and won't affect peripheral drivers)
> > > =
> > > This remark was related to the CAN clocks of the MPC512x SoC.
> > =
> > Gerhard,
> > =
> > Thanks for the patch (way far down below here). I'll check into it to
> > see if that implementation looks OK. It would be helpful if another
> > platform with shared gates could weigh in on whether the implementation
> > works for them.
> > =
> > Still, a shared gate solution is not a prerequisite for this series,
> > correct?
> =
> Well, the recent CAN driver related discussion suggested that I
> had a mental misconception there. The need for "shared gates"
> was felt because of mixing up unrelated paths in the clock tree.
> But the MCLK subtree is for bitrate generation, while the BDLC
> gate is for register access into the peripheral controller.
> =
> Currently I'm investigating how I can cleanly tell those
> individual aspects apart. Telling the gate for register access
> (in ARM speak often referred to as 'ipg') from the bitrate
> generation (the 'per' clock, or 'mclk' here) seems so much more
> appropriate.
> =
> After clean separation, and more testing to make sure nothing
> gets broken throughout the series, there will be v4.
> =
> =
> So "shared gate" support might have become obsolete for the
> MPC512x platform. But if others need it, the outlined approach
> (patch below) may be viable. The change to the common code is
> minimal. The use in the platform's clock driver was kind of
> overengineered for the case of exactly one such gate, but this
> immediately makes it a working approach for several gates, if
> others need it.
> =
> I'll trim the motivation and just leave the suggested approach
> for "shared gates" here. Feel free to drop it or to only
> resurrect it as the need may re-arise later. So far nobody
> appears to have felt the need up to now ...
You can drop it. If your platform does not need it and nobody else has
said that they require shared gates then there is no reason to spend
more time on it.
Regards,
Mike
> =
> > > [ ... ]
> > > =
> > > The question now is how to correctly support the situation where
> > > a gate is shared between subtrees yet isn't really part of any
> > > path within the subtrees. I really cannot find a single spot
> > > where to introduce the gate such that it's not duplicated.
> > > =
> > > The appropriate solution would not be to pre-enable those clocks,
> > > but to either introduce another gate clock type which supports a
> > > shared reference, or to add support for the shared reference to
> > > the existing gate code.
> > > =
> > > =
> > > I'd rather not duplicate most or all of the code of clk-gate.c,
> > > instead I looked into how to add "shared gate" support to the
> > > existing driver.
> > > =
> > > My question is whether the approach is acceptable. It adds
> > > minimal overhead and shall be OK for the enable/disable path from
> > > a technical POV. And it doesn't feel like too much of a stretch.
> > > But there may be non-technical reasons to reject the approach.
> > > I'd like to learn whether to follow that path before preparing
> > > another version of the patch series.
> > > =
> > > The diffs were taken with the '-w -b' options to demonstrate
> > > their essence and not drown it in whitespace changes. The
> > > implementation assumes that the caller which registers the gate
> > > (the platform's clock driver) provides both the counter cell and
> > > the lock. And that all gates with a "shared use counter" use the
> > > same lock (which is satisfied as they all get registered from the
> > > same spot in the platform's clock driver).
> > > =
> > > The CLK_IGNORE_UNUSED flag addresses a different problem. The
> > > SoC has four MSCAN components, while two of them are enabled in
> > > the device tree (the other two are present but disabled). So
> > > during probe two of the clocks get enabled. After probe all
> > > unused clocks automatically get disabled (that's another two).
> > > So the "shared use counter" drops to zero although components are
> > > in use, because "disable, it's unused" isn't told from "disable
> > > after enable, regular use". The flag would become obsolete if
> > > the common gate logic would implement a separate disable_unused()
> > > routine, but I guess this isn't necessary and the use of the flag
> > > is appropriate.
> > > =
> > > That the example use creates a field for just one counter is to
> > > better demonstrate the use and potential extension as need
> > > arises. Reducing this to a mere integer variable would be a
> > > micro optimization.
> > > =
> > > =
> > > The extension of the existing clk_gate implementation:
> > > =
> > > --- a/drivers/clk/clk-gate.c
> > > +++ b/drivers/clk/clk-gate.c
> > > @@ -46,6 +46,7 @@ static void clk_gate_endisable(struct clk_hw *hw, i=
nt enable)
> > > struct clk_gate *gate =3D to_clk_gate(hw);
> > > int set =3D gate->flags & CLK_GATE_SET_TO_DISABLE ? 1 : 0;
> > > unsigned long flags =3D 0;
> > > + int need_reg_access;
> > > u32 reg;
> > > =
> > > set ^=3D enable;
> > > @@ -53,6 +54,20 @@ static void clk_gate_endisable(struct clk_hw *hw, =
int enable)
> > > if (gate->lock)
> > > spin_lock_irqsave(gate->lock, flags);
> > > =
> > > + /*
> > > + * if a "shared use counter" was specified, keep track of ena=
ble
> > > + * and disable calls and only access hardware registers upon =
the
> > > + * very first enable or very last disable call
> > > + */
> > > + if (!gate->share_count) {
> > > + need_reg_access =3D 1;
> > > + } else if (enable) {
> > > + need_reg_access =3D (*gate->share_count)++ =3D=3D 0;
> > > + } else {
> > > + need_reg_access =3D --(*gate->share_count) =3D=3D 0;
> > > + }
> > > +
> > > + if (need_reg_access) {
> > > if (gate->flags & CLK_GATE_HIWORD_MASK) {
> > > reg =3D BIT(gate->bit_idx + 16);
> > > if (set)
> > > @@ -67,6 +82,7 @@ static void clk_gate_endisable(struct clk_hw *hw, i=
nt enable)
> > > }
> > > =
> > > clk_writel(reg, gate->reg);
> > > + }
> > > =
> > > if (gate->lock)
> > > spin_unlock_irqrestore(gate->lock, flags);
> > > @@ -118,10 +134,11 @@ EXPORT_SYMBOL_GPL(clk_gate_ops);
> > > * @clk_gate_flags: gate-specific flags for this clock
> > > * @lock: shared register lock for this clock
> > > */
> > > -struct clk *clk_register_gate(struct device *dev, const char *name,
> > > +struct clk *clk_register_gate_shared(struct device *dev, const char =
*name,
> > > const char *parent_name, unsigned long flags,
> > > void __iomem *reg, u8 bit_idx,
> > > - u8 clk_gate_flags, spinlock_t *lock)
> > > + u8 clk_gate_flags, spinlock_t *lock,
> > > + int *share_count)
> > > {
> > > struct clk_gate *gate;
> > > struct clk *clk;
> > > @@ -152,6 +169,7 @@ struct clk *clk_register_gate(struct device *dev,=
const char *name,
> > > gate->bit_idx =3D bit_idx;
> > > gate->flags =3D clk_gate_flags;
> > > gate->lock =3D lock;
> > > + gate->share_count =3D share_count;
> > > gate->hw.init =3D &init;
> > > =
> > > clk =3D clk_register(dev, &gate->hw);
> > > @@ -161,3 +179,14 @@ struct clk *clk_register_gate(struct device *dev=
, const char *name,
> > > =
> > > return clk;
> > > }
> > > +
> > > +struct clk *clk_register_gate(struct device *dev, const char *name,
> > > + const char *parent_name, unsigned long flags,
> > > + void __iomem *reg, u8 bit_idx,
> > > + u8 clk_gate_flags, spinlock_t *lock)
> > > +{
> > > +
> > > + return clk_register_gate_shared(dev, name, parent_name, flags,
> > > + reg, bit_idx, clk_gate_flags,
> > > + lock, NULL);
> > > +}
> > > --- a/include/linux/clk-provider.h
> > > +++ b/include/linux/clk-provider.h
> > > @@ -222,6 +222,7 @@ struct clk_gate {
> > > u8 bit_idx;
> > > u8 flags;
> > > spinlock_t *lock;
> > > + int *share_count;
> > > };
> > > =
> > > #define CLK_GATE_SET_TO_DISABLE BIT(0)
> > > @@ -232,6 +233,11 @@ struct clk *clk_register_gate(struct device *dev=
, const char *name,
> > > const char *parent_name, unsigned long flags,
> > > void __iomem *reg, u8 bit_idx,
> > > u8 clk_gate_flags, spinlock_t *lock);
> > > +struct clk *clk_register_gate_shared(struct device *dev, const char =
*name,
> > > + const char *parent_name, unsigned long flags,
> > > + void __iomem *reg, u8 bit_idx,
> > > + u8 clk_gate_flags, spinlock_t *lock,
> > > + int *share_count);
> > > =
> > > struct clk_div_table {
> > > unsigned int val;
> > > =
> > > =
> > > How to use these shared gates:
> > > =
> > > --- a/arch/powerpc/platforms/512x/clock-commonclk.c
> > > +++ b/arch/powerpc/platforms/512x/clock-commonclk.c
> > > @@ -123,6 +123,39 @@ static inline struct clk *mpc512x_clk_gated(
> > > reg, pos, 0, &clklock);
> > > }
> > > =
> > > +enum mpc512x_clk_shared_gate_id_t {
> > > + MPC512x_CLK_SHARED_GATE_MSCAN,
> > > + MPC512x_CLK_SHARED_GATE_MAX,
> > > +};
> > > +
> > > +static int mpc512x_clk_gate_counters[MPC512x_CLK_SHARED_GATE_MAX];
> > > +
> > > +/*
> > > + * implementor's note: since clk_gate items don't implement a separ=
ate
> > > + * .disable_unused() callback, their .disable() routine gets called =
and
> > > + * "disable the clock as we can't see it's in use" cannot be told fr=
om
> > > + * "regular disable, count these events please"
> > > + *
> > > + * passing the CLK_IGNORE_UNUSED flag upon clock creation will suppr=
ess
> > > + * the "disable, unused" call, so use counts won't get unbalanced, t=
he
> > > + * clock either never got enabled and thus need not get disabled, or
> > > + * part of the hardware got enabled while disabling the other part i=
sn't
> > > + * wanted
> > > + */
> > > +static inline struct clk *mpc512x_clk_gated_shared(
> > > + const char *name, const char *parent_name,
> > > + u32 __iomem *reg, u8 pos,
> > > + enum mpc512x_clk_shared_gate_id_t share_id)
> > > +{
> > > + int clkflags;
> > > +
> > > + clkflags =3D CLK_SET_RATE_PARENT;
> > > + clkflags |=3D CLK_IGNORE_UNUSED;
> > > + return clk_register_gate_shared(NULL, name, parent_name, clkf=
lags,
> > > + reg, pos, 0, &clklock,
> > > + &mpc512x_clk_gate_counters[sh=
are_id]);
> > > +}
> > > +
> > > static inline struct clk *mpc512x_clk_muxed(const char *name,
> > > const char **parent_names, int parent_count,
> > > u32 __iomem *reg, u8 pos, u8 len)
> > > @@ -520,9 +553,16 @@ static void mpc512x_clk_setup_mclk(struct mclk_s=
etup_data *entry)
> > > 1, 1);
> > > }
> > > if (sccr_reg) {
> > > + if (entry->type =3D=3D MCLK_TYPE_MSCAN) {
> > > + clks[clks_idx_pub] =3D mpc512x_clk_gated_shar=
ed(
> > > + entry->name_mclk,
> > > + entry->name_mux1, sccr_reg, s=
ccr_bit,
> > > + MPC512x_CLK_SHARED_GATE_MSCAN=
);
> > > + } else {
> > > clks[clks_idx_pub] =3D mpc512x_clk_gated(
> > > entry->name_mclk,
> > > entry->name_mux1, sccr_reg, s=
ccr_bit);
> > > + }
> > > } else {
> > > clks[clks_idx_pub] =3D mpc512x_clk_factor(
> > > entry->name_mclk,
> > > =
> > > Local tests have shown that the extension solves the problem of
> > > how to satisfy the SoC's constraints on the MPC512x platform.
> > > The MSCAN clocks no longer need to get pre-enabled, instead they
> > > get setup and enabled only as the mscan(4) driver probes devices
> > > according to how it was instructed (device tree nodes).
> > > =
> > > What do you think? Is the "shared gate" support in the common
> > > logic appropriate? I'd rather not duplicate all of this code
> > > just to introduce the specific gate I need, while most of the
> > > logic is identical to the existing gate implementation. The
> > > desire isn't to override the gate's operations, but to wrap them
> > > and to consult a counter in addition, while the register access
> > > still applies.
> =
> =
> virtually yours
> Gerhard Sittig
> -- =
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH 00/11] Add compression support to pstore
From: Aruna Balakrishnaiah @ 2013-08-05 17:10 UTC (permalink / raw)
To: Tony Luck
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
linux-kernel@vger.kernel.org, keescook@chromium.org
In-Reply-To: <CA+8MBbJ7x46FGC7dPSdNzf8z=fZz20w1kiNgnZr4QQB6SUELhg@mail.gmail.com>
Hi Tony,
Thank you very much for testing my patches.
On Saturday 03 August 2013 03:42 AM, Tony Luck wrote:
> A quick experiment to use your patchset - but with compression
> disabled by tweaking this line in pstore_dump():
>
> zipped_len = -1; //zip_data(dst, hsize + len);
>
> turned out well. This kernel dumps uncompressed dmesg blobs into pstore
> and gets them back out again. So it seems likely that the problems are
> someplace in the compression/decompression code.
A quick look on my code suggests that problem could be in this part
of code.
In pstore_dump:
if (zipped_len < 0) {
dst = psinfo->buf;
hsize = sprintf(dst, "%s#%d Part%d\n",
why, oopscount, part);
size = psinfo->bufsize - hsize;
dst += hsize;
compressed = false;
if (!kmsg_dump_get_buffer(dumper, true, dst,
size, &len))
break;
} else {
compressed = true;
---> len = zipped_len;
}
I am returning zipped_len as the length of the compressed data (which also
has hsize compressed). So returning hsize + len in pstore_write callback
will be wrong. It should just have been zipped_len. This might be adding
junk characters.
Can you please replace this hunk with:
if (zipped_len < 0) {
pr_err("Compression failed\n");
dst = psinfo->buf;
hsize = sprintf(dst, "%s#%d Part%d\n",
why, oopscount, part);
size = psinfo->bufsize - hsize;
dst += hsize;
compressed = false;
if (!kmsg_dump_get_buffer(dumper, true, dst,
size, &len))
break;
total_len = hsize + len;
} else {
compressed = true;
total_len = zipped_len;
}
ret = psinfo->write(PSTORE_TYPE_DMESG, reason, &id, part,
oopscount, compressed, total_len, psinfo);
if (ret == 0 && reason == KMSG_DUMP_OOPS && pstore_is_mounted())
pstore_new_entry = 1;
total += total_len;
part++;
With the above hunk, atleast I dont see junk characters at the end in power.
I apologise, since I do not have the suitable machine to test this I am
not able to reproduce the scenarios you are stating. I need your help
in testing this.
- Aruna
> -Tony
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
From: Gerhard Sittig @ 2013-08-05 17:01 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree@vger.kernel.org, Mike Turquette, Detlev Zundel,
Wolfram Sang, Greg Kroah-Hartman, rob.herring@calxeda.com,
Mark Brown, Marc Kleine-Budde,
linux-arm-kernel@lists.infradead.org, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org, David Woodhouse,
Wolfgang Grandegger, Mauro Carvalho Chehab
In-Reply-To: <20130805113720.GE9910@e106331-lin.cambridge.arm.com>
On Mon, Aug 05, 2013 at 12:37 +0100, Mark Rutland wrote:
>
> On Mon, Jul 22, 2013 at 01:14:44PM +0100, Gerhard Sittig wrote:
> > this change implements a clock driver for the MPC512x PowerPC platform
> > which follows the COMMON_CLK approach and uses common clock drivers
> > shared with other platforms
> >
> > this driver implements the publicly announced set of clocks (which can
> > get referenced by means of symbolic identifiers from the dt-bindings
> > header file), as well as generates additional 'struct clk' items where
> > the SoC hardware cannot easily get mapped to the common primitives of
> > the clock API, or requires "intermediate" clock nodes to represent
> > clocks that have both gates and dividers
> >
> > the previous PPC_CLOCK implementation is kept in place and remains in
> > parallel to the common clock implementation for test and comparison
> > during migration, a compile time option picks one of the two
> > alternatives (Kconfig switch, common clock used by default)
> >
> > some of the clock items get pre-enabled in the clock driver to not have
> > them automatically disabled by the underlying clock subsystem because of
> > their being unused -- this approach is desirable because
> > - some of the clocks are useful to have for diagnostics and information
> > despite their not getting claimed by any drivers (CPU, internal and
> > external RAM, internal busses, boot media)
> > - some of the clocks aren't claimed by their peripheral drivers yet,
> > either because of missing driver support or because device tree specs
> > aren't available yet (but the workarounds will get removed as the
> > drivers get adjusted and the device tree provides the clock specs)
> > - some help introduce support for and migrate to the common
> > infrastructure, while more appropriate support for specific hardware
> > constraints isn't available yet (remaining changes are strictly
> > internal to the clock driver and won't affect peripheral drivers)
> >
> > clkdev registration provides "alias names" for few clock items
> > - to not break those peripheral drivers which encode their component
> > index into the name that is used for clock lookup (UART, SPI, USB)
> > - to not break those drivers which use names for the clock lookup which
> > were encoded in the previous PPC_CLOCK implementation (NFC, VIU, CAN)
> > this workaround will get removed as these drivers get adjusted after
> > device tree based clock lookup has become available
> >
> > Signed-off-by: Gerhard Sittig <gsi@denx.de>
> > ---
> > arch/powerpc/platforms/512x/Kconfig | 14 +-
> > arch/powerpc/platforms/512x/Makefile | 4 +-
> > arch/powerpc/platforms/512x/clock-commonclk.c | 786 +++++++++++++++++++++++++
> > include/linux/clk-provider.h | 16 +
> > 4 files changed, 818 insertions(+), 2 deletions(-)
> > create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c
> >
>
> [...]
>
> > +static int get_freq_from_dt(char *propname)
> > +{
> > + struct device_node *np;
> > + const unsigned int *prop;
> > + int val;
> > +
> > + val = 0;
> > + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-immr");
> > + if (np) {
> > + prop = of_get_property(np, propname, NULL);
> > + if (prop)
> > + val = *prop;
> > + of_node_put(np);
> > + }
> > + return val;
> > +}
>
> Can you not use of_property_read_u32 here rather than of_get_property?
>
> Also, this seems rather unlike the common clock bindings method for
> describing frequencies in the dt. Given there's nothing in mainline
> using this yet, we can do it 'right' from the start.
This specific routine was taken in verbatim form from the former
PPC_CLOCK implementation. Although I could re-implement it in
other ways if that was considered necessary.
>
> [...]
>
> > + /*
> > + * externally provided clocks (when implemented in hardware,
> > + * device tree may specify values which otherwise were unknown)
> > + */
> > + freq = get_freq_from_dt("psc_mclk_in");
> > + if (!freq)
> > + freq = 25000000;
> > + clks[MPC512x_CLK_PSC_MCLK_IN] = mpc512x_clk_fixed("psc_mclk_in", freq);
> > + freq = get_freq_from_dt("spdif_tx_in");
> > + clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_tx_in", freq);
> > + freq = get_freq_from_dt("spdif_rx_in");
> > + clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_rx_in", freq);
>
> Can we not just use fixed-clocks for these in the dt? It feels odd to
> describe them in a compeltely differnet way in the dt, especially as
> we'll have to maintain some backwards compatibility for a while...
>
> I see for psc_mclk_in we assume a default value if not present. I'm not
> sure how to handle that, but I assume there's some way of finding out if
> we've already registered a clock output with the same name?
I guess using fixed-clocks (i.e. clock items that completely get
described in the device tree, and are taken care of by a common
driver which attaches to anything that is said to be compatible)
would change behaviour, which I did not intend to introduce.
The above code does what the PPC_CLOCK implementation did: Always
create the clock items, while their _rate_ may or may not be
specified or overridden from device tree specs, and defaults
(non-zero or zero) always apply.
Thank you for the feedback and suggestions. I've yet to find out
how much compatibility I'm allowed to break. :) ATM I assume
that my changes do keep compatibility where appropriate, and only
change the device tree or its interpretation where the device
tree may be considered wrong (not that it would provide false
information, but it certainly lacked essential information about
the hardware, like clock related information, and thus it shall
be acceptable to require an update of the dtb to fix that gap).
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH 00/11] Add compression support to pstore
From: Tony Luck @ 2013-08-05 16:41 UTC (permalink / raw)
To: Aruna Balakrishnaiah, linuxppc-dev@ozlabs.org, paulus@samba.org,
linux-kernel@vger.kernel.org, benh@kernel.crashing.org,
keescook@chromium.org
In-Reply-To: <CA+8MBbJ7x46FGC7dPSdNzf8z=fZz20w1kiNgnZr4QQB6SUELhg@mail.gmail.com>
One more experiment - removed previous hack that disabled compression.
Added a new hack to skip decompression.
System died cleanly when I forced a panic.
On reboot I found 3 files in pstore:
-r--r--r-- 1 root root 3972 Aug 5 09:24 dmesg-erst-5908671953186586625
-r--r--r-- 1 root root 2565 Aug 5 09:24 dmesg-erst-5908671953186586626
-r--r--r-- 1 root root 4067 Aug 5 09:24 dmesg-erst-5908671953186586627
Using "openssl zlib -d" to decompress then ends up with some garbage
at the end of the decompressed file - some text that should be there is
missing. E.g. the tail of decompressed version of *625 ends with:
<4>Call Trace:
<4> [<ffffffff815f85f4>] dump_stack+0x45/0x56
<4> [<ffffffff815f41ca>] panic+0xc2/0x1cb
<4> [<ffffffff815f4327>] ? printk+0x54/0x56
<4> [<ffffffff811cfe45>] aegl+0x25/0x30
<4> [<ffffffff811c719d>] proc_reg_write+0x3d/0x80
<4> [<ffffffff81165945>] vfs_write+0xc5/0x1e0
<4> [<ffffffff81165e32>] SyS_write+0x52/0xa0
<4> [<ffffffff81606882>] system_call_fastpath+0x16/0x1b
)c10^@^@^@^@^@^@^@^@^@
But my serial console logged this:
Call Trace:
[<ffffffff815f85f4>] dump_stack+0x45/0x56
[<ffffffff815f41ca>] panic+0xc2/0x1cb
[<ffffffff815f4327>] ? printk+0x54/0x56
[<ffffffff811cfe45>] aegl+0x25/0x30
[<ffffffff811c719d>] proc_reg_write+0x3d/0x80
[<ffffffff81165945>] vfs_write+0xc5/0x1e0
[<ffffffff81165e32>] SyS_write+0x52/0xa0
[<ffffffff81606882>] system_call_fastpath+0x16/0x1b
------------[ cut here ]------------
WARNING: CPU: 18 PID: 381 at arch/x86/kernel/smp.c:124
native_smp_send_reschedule+0x5b/0x60()
Modules linked in:
CPU: 18 PID: 381 Comm: kworker/18:1 Not tainted 3.11.0-rc3-11-ge41db9e #6
-Tony
^ permalink raw reply
* Re: [PATCH 6/6 v2] kvm: powerpc: use caching attributes as per linux pte
From: Scott Wood @ 2013-08-05 16:30 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, kvm@vger.kernel.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D070F8FE9@039-SN2MPN1-012.039d.mgd.msft.net>
On Fri, 2013-08-02 at 22:11 -0500, Bhushan Bharat-R65777 wrote:
> > How does wimg get set in the pfnmap case?
>
> Pfnmap is not kernel managed pages, right? So should we set I+G there ?
It could depend on ppc_md.phys_mem_access_prot(). Can't you pull it
from the PTE regardless of pfnmap?
-Scott
^ permalink raw reply
* Re: [PATCH 6/6 v2] kvm: powerpc: use caching attributes as per linux pte
From: Scott Wood @ 2013-08-05 16:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, kvm@vger.kernel.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1375503938.15999.82.camel@pasglop>
On Sat, 2013-08-03 at 14:25 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2013-08-03 at 03:11 +0000, Bhushan Bharat-R65777 wrote:
> >
> > >
> > > Could you explain why we need to set dirty/referenced on the PTE, when we didn't
> > > need to do that before? All we're getting from the PTE is wimg.
> > > We have MMU notifiers to take care of the page being unmapped, and we've already
> > > marked the page itself as dirty if the TLB entry is writeable.
> >
> > I pulled this code from book3s.
> >
> > Ben, can you describe why we need this on book3s ?
>
> If you let the guest write to the page you must set the dirty bit on the PTE
> (or the struct page, at least one of them), similar with accessed on any access.
>
> If you don't, the VM might swap the page out without writing it back to disk
> for example, assuming it contains no modified data.
We've already marked the page itself as dirty using kvm_set_pfn_dirty(),
and if the VM swaps it out we'll get an MMU notifier callback. If we
marked the PTE dirty/accessed instead, is there any guarantee it will
stay marked dirty/accessed until the next MMU notifier?
-Scott
^ permalink raw reply
* Re: PCIE device errors after linux kernel upgrade
From: Bjorn Helgaas @ 2013-08-05 15:38 UTC (permalink / raw)
To: Leon Ravich; +Cc: linux-pci@vger.kernel.org, linuxppc-dev
In-Reply-To: <CAPWoNkLQUbFG2vZ7wqoqqVNj4uxKz3Fa_vsSH=1_TDD=XC1f2A@mail.gmail.com>
[+cc linuxppc-dev]
On Mon, Aug 5, 2013 at 5:17 AM, Leon Ravich <lravich@gmail.com> wrote:
> Hi all ,
> I am trying to upgrade ours embedded device (freescale powerPC P2020 cpu)
> linux kernel , till now we used 2.6.32 I am trying to upgrade to 3.8.13 .
> I took the source from freescale git:
> git://git.freescale.com/ppc/sdk/linux.git
>
> on our embedded device we have an FPGA connected through PCIE .
>
> on each boot we loading the rbf design to the FPGA and the rescan pci bus to let
> kernel detect it .
>
> during the rescan I getting error messages:
> genirq: Setting trigger mode 0 for irq 27 failed
> (mpc8xxx_irq_set_type+0x0/0xec)
> [ 22.060898] genirq: Setting trigger mode 0 for irq 28 failed
> (mpc8xxx_irq_set_type+0x0/0xec)
> [ 22.069461] genirq: Setting trigger mode 0 for irq 31 failed
> (mpc8xxx_irq_set_type+0x0/0xec)
> [ 22.078010] genirq: Setting trigger mode 0 for irq 32 failed
> (mpc8xxx_irq_set_type+0x0/0xec)
> [ 22.086576] genirq: Setting trigger mode 0 for irq 33 failed
> (mpc8xxx_irq_set_type+0x0/0xec)
> [ 22.095143] genirq: Setting trigger mode 0 for irq 37 failed
> (mpc8xxx_irq_set_type+0x0/0xec)
> [ 22.103715] genirq: Setting trigger mode 0 for irq 38 failed
> (mpc8xxx_irq_set_type+0x0/0xec)
> [ 22.112282] genirq: Setting trigger mode 0 for irq 39 failed
> (mpc8xxx_irq_set_type+0x0/0xec)
Hmm, I don't know much about IRQ issues.
> [ 37.945785] pci 0000:00:00.0: ignoring class 0x0b2000 (doesn't
> match header type 01)
There's a recent patch related to this:
http://lkml.kernel.org/r/1374823418-1550-1-git-send-email-Chunhe.Lan@freescale.com
> [ 37.953640] PCIE error(s) detected
> [ 37.953858] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> [ 37.953988] pci 0000:00:00.0: BAR 8: assigned [mem 0xc0000000-0xdfffffff]
> [ 37.953994] pci 0000:00:00.0: BAR 7: can't assign io (size 0x10000)
> [ 37.954000] pci 0000:01:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff]
> [ 37.954013] pci 0000:01:00.0: BAR 1: assigned [mem 0xc0100000-0xc017ffff]
> [ 37.954025] pci 0000:01:00.0: BAR 2: assigned [mem 0xc0180000-0xc01fffff]
> [ 37.954036] pci 0000:00:00.0: PCI bridge to [bus 01]
> [ 37.954041] pci 0000:00:00.0: bridge window [mem 0xc0000000-0xdfffffff]
> [ 38.007354] PCIE ERR_DR register: 0x80020000
> [ 38.011613] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.016392] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.020997] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.025602] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.030207] PCIE ERR_CAP_R3 register: 0x00000000
>
>
> and after a few minutes I linux reboot it self,
>
>
> where can I start debugging it??
I'd start by applying the header quirk patch above, then comparing the
complete console log (boot with "ignore_loglevel") from 2.6.32 and
3.8.13.
Bjorn
^ permalink raw reply
* RE: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like booke3s
From: Bhushan Bharat-R65777 @ 2013-08-05 14:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <1375503847.15999.80.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogU2F0dXJk
YXksIEF1Z3VzdCAwMywgMjAxMyA5OjU0IEFNDQo+IFRvOiBCaHVzaGFuIEJoYXJhdC1SNjU3NzcN
Cj4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBhZ3JhZkBzdXNlLmRlOyBrdm0tcHBjQHZnZXIua2Vy
bmVsLm9yZzsNCj4ga3ZtQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFi
cy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCA1LzYgdjJdIGt2bTogcG93ZXJwYzogYm9va2U6
IEFkZCBsaW51eCBwdGUgbG9va3VwIGxpa2UNCj4gYm9va2Uzcw0KPiANCj4gT24gU2F0LCAyMDEz
LTA4LTAzIGF0IDAyOjU4ICswMDAwLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcgd3JvdGU6DQo+ID4g
T25lIG9mIHRoZSBwcm9ibGVtIEkgc2F3IHdhcyB0aGF0IGlmIEkgcHV0IHRoaXMgY29kZSBpbg0K
PiA+IGFzbS9wZ3RhYmxlLTMyLmggYW5kIGFzbS9wZ3RhYmxlLTY0LmggdGhlbiBwdGVfcGVyc2Vu
dCgpIGFuZCBvdGhlcg0KPiA+IGZyaWVuZCBmdW5jdGlvbiAob24gd2hpY2ggdGhpcyBjb2RlIGRl
cGVuZHMpIGFyZSBkZWZpbmVkIGluIHBndGFibGUuaC4NCj4gPiBBbmQgcGd0YWJsZS5oIGluY2x1
ZGVzIGFzbS9wZ3RhYmxlLTMyLmggYW5kIGFzbS9wZ3RhYmxlLTY0LmggYmVmb3JlIGl0DQo+ID4g
ZGVmaW5lcyBwdGVfcHJlc2VudCgpIGFuZCBmcmllbmRzIGZ1bmN0aW9ucy4NCj4gPg0KPiA+IE9r
IEkgbW92ZSB3b3ZlIHRoaXMgaW4gYXNtL3BndGFibGUqLmgsIGluaXRpYWxseSBJIGZvdWdodCB3
aXRoIG15c2VsZg0KPiA+IHRvIHRha2UgdGhpcyBjb2RlIGluIHBndGFibGUqIGJ1dCBmaW5hbGx5
IGVuZCB1cCBkb2luZyBoZXJlIChnb3QNCj4gPiBiaWFzZWQgYnkgYm9vazNzIDopKS4NCj4gDQo+
IElzIHRoZXJlIGEgcmVhc29uIHdoeSB0aGVzZSByb3V0aW5lcyBjYW4gbm90IGJlIGNvbXBsZXRl
bHkgZ2VuZXJpYyBpbiBwZ3RhYmxlLmgNCj4gPw0KDQpIb3cgYWJvdXQgdGhlIGdlbmVyaWMgZnVu
Y3Rpb246DQoNCmRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vcGd0YWJsZS1w
cGM2NC5oIGIvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL3BndGFibGUtcHBjNjQuaA0KaW5kZXgg
ZDI1N2Q5OC4uMjFkYWYyOCAxMDA2NDQNCi0tLSBhL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9w
Z3RhYmxlLXBwYzY0LmgNCisrKyBiL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3RhYmxlLXBw
YzY0LmgNCkBAIC0yMjEsNiArMjIxLDI3IEBAIHN0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBw
dGVfdXBkYXRlKHN0cnVjdCBtbV9zdHJ1Y3QgKm1tLA0KICAgICAgICByZXR1cm4gb2xkOw0KIH0N
Cg0KK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBwdGVfcmVhZChwdGVfdCAqcCkNCit7DQor
I2lmZGVmIFBURV9BVE9NSUNfVVBEQVRFUw0KKyAgICAgICBwdGVfdCBwdGU7DQorICAgICAgIHB0
ZV90IHRtcDsNCisgICAgICAgX19hc21fXyBfX3ZvbGF0aWxlX18gKA0KKyAgICAgICAiMTogICAg
IGxkYXJ4ICAgJTAsMCwlM1xuIg0KKyAgICAgICAiICAgICAgIGFuZGkuICAgJTEsJTAsJTRcbiIN
CisgICAgICAgIiAgICAgICBibmUtICAgIDFiXG4iDQorICAgICAgICIgICAgICAgb3JpICAgICAl
MSwlMCwlNFxuIg0KKyAgICAgICAiICAgICAgIHN0ZGN4LiAgJTEsMCwlM1xuIg0KKyAgICAgICAi
ICAgICAgIGJuZS0gICAgMWIiDQorICAgICAgIDogIj0mciIgKHB0ZSksICI9JnIiICh0bXApLCAi
PW0iICgqcCkNCisgICAgICAgOiAiciIgKHApLCAiaSIgKF9QQUdFX0JVU1kpDQorICAgICAgIDog
ImNjIik7DQorDQorICAgICAgIHJldHVybiBwdGU7DQorI2Vsc2UgIA0KKyAgICAgICByZXR1cm4g
cHRlX3ZhbCgqcCk7DQorI2VuZGlmDQorI2VuZGlmDQorfQ0KIHN0YXRpYyBpbmxpbmUgaW50IF9f
cHRlcF90ZXN0X2FuZF9jbGVhcl95b3VuZyhzdHJ1Y3QgbW1fc3RydWN0ICptbSwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIGFkZHIs
IHB0ZV90ICpwdGVwKQ0KIHsNCmRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20v
cGd0YWJsZS5oIGIvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL3BndGFibGUuaA0KaW5kZXggNjkw
YzhjMi4uZGFkNzEyYyAxMDA2NDQNCi0tLSBhL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3Rh
YmxlLmgNCisrKyBiL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3RhYmxlLmgNCkBAIC0yNTQs
NiArMjU0LDQ1IEBAIHN0YXRpYyBpbmxpbmUgcHRlX3QgKmZpbmRfbGludXhfcHRlX29yX2h1Z2Vw
dGUocGdkX3QgKnBnZGlyLCB1bnNpZ25lZCBsb25nIGVhLA0KIH0NCiAjZW5kaWYgLyogIUNPTkZJ
R19IVUdFVExCX1BBR0UgKi8NCg0KK3N0YXRpYyBpbmxpbmUgcHRlX3QgbG9va3VwX2xpbnV4X3B0
ZShwZ2RfdCAqcGdkaXIsIHVuc2lnbmVkIGxvbmcgaHZhLA0KKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGludCB3cml0aW5nLCB1bnNpZ25lZCBsb25nICpwdGVfc2l6ZXApDQor
ew0KKyAgICAgICBwdGVfdCAqcHRlcDsNCisgICAgICAgcHRlX3QgcHRlOw0KKyAgICAgICB1bnNp
Z25lZCBsb25nIHBzID0gKnB0ZV9zaXplcDsNCisgICAgICAgdW5zaWduZWQgaW50IHNoaWZ0Ow0K
Kw0KKyAgICAgICBwdGVwID0gZmluZF9saW51eF9wdGVfb3JfaHVnZXB0ZShwZ2RpciwgaHZhLCAm
c2hpZnQpOw0KKyAgICAgICBpZiAoIXB0ZXApDQorICAgICAgICAgICAgICAgcmV0dXJuIF9fcHRl
KDApOw0KKyAgICAgICBpZiAoc2hpZnQpDQorICAgICAgICAgICAgICAgKnB0ZV9zaXplcCA9IDF1
bCA8PCBzaGlmdDsNCisgICAgICAgZWxzZQ0KKyAgICAgICAgICAgICAgICpwdGVfc2l6ZXAgPSBQ
QUdFX1NJWkU7DQorDQorICAgICAgIGlmIChwcyA+ICpwdGVfc2l6ZXApDQorICAgICAgICAgICAg
ICAgcmV0dXJuIF9fcHRlKDApOw0KKw0KKyAgICAgICBpZiAoIXB0ZV9wcmVzZW50KCpwdGVwKSkN
CisgICAgICAgICAgICAgICByZXR1cm4gX19wdGUoMCk7DQorDQorI2lmZGVmIENPTkZJR19QUEM2
NA0KKyAgICAgICAvKiBMb2NrIFBURSAoc2V0IF9QQUdFX0JVU1kpIGFuZCByZWFkICovDQorICAg
ICAgIHB0ZSA9IHB0ZV9yZWFkKHB0ZXApOw0KKyNlbHNlDQorICAgICAgIHB0ZSA9IHB0ZV92YWwo
KnB0ZXApOw0KKyNlbmRpZg0KKyAgICAgICBpZiAocHRlX3ByZXNlbnQocHRlKSkgew0KKyAgICAg
ICAgICAgICAgIHB0ZSA9IHB0ZV9ta3lvdW5nKHB0ZSk7DQorICAgICAgICAgICAgICAgaWYgKHdy
aXRpbmcgJiYgcHRlX3dyaXRlKHB0ZSkpDQorICAgICAgICAgICAgICAgICAgICAgICBwdGUgPSBw
dGVfbWtkaXJ0eShwdGUpOw0KKyAgICAgICB9DQorDQorICAgICAgICpwdGVwID0gX19wdGUocHRl
KTsgLyogNjRiaXQ6IEFsc28gdW5sb2NrIHB0ZSAoY2xlYXIgX1BBR0VfQlVTWSkgKi8NCisNCisg
ICAgICAgcmV0dXJuIHB0ZTsNCit9DQorDQogI2VuZGlmIC8qIF9fQVNTRU1CTFlfXyAqLw0KDQog
I2VuZGlmIC8qIF9fS0VSTkVMX18gKi8NCg==
^ permalink raw reply
* Re: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
From: Mark Rutland @ 2013-08-05 11:37 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Mike Turquette, Detlev Zundel, Wolfram Sang, Greg Kroah-Hartman,
devicetree-discuss@lists.ozlabs.org, rob.herring@calxeda.com,
Mark Brown, Marc Kleine-Budde, Wolfgang Grandegger,
Anatolij Gustschin, linuxppc-dev@lists.ozlabs.org,
David Woodhouse, linux-arm-kernel@lists.infradead.org,
Mauro Carvalho Chehab
In-Reply-To: <1374495298-22019-18-git-send-email-gsi@denx.de>
On Mon, Jul 22, 2013 at 01:14:44PM +0100, Gerhard Sittig wrote:
> this change implements a clock driver for the MPC512x PowerPC platform
> which follows the COMMON_CLK approach and uses common clock drivers
> shared with other platforms
>
> this driver implements the publicly announced set of clocks (which can
> get referenced by means of symbolic identifiers from the dt-bindings
> header file), as well as generates additional 'struct clk' items where
> the SoC hardware cannot easily get mapped to the common primitives of
> the clock API, or requires "intermediate" clock nodes to represent
> clocks that have both gates and dividers
>
> the previous PPC_CLOCK implementation is kept in place and remains in
> parallel to the common clock implementation for test and comparison
> during migration, a compile time option picks one of the two
> alternatives (Kconfig switch, common clock used by default)
>
> some of the clock items get pre-enabled in the clock driver to not have
> them automatically disabled by the underlying clock subsystem because of
> their being unused -- this approach is desirable because
> - some of the clocks are useful to have for diagnostics and information
> despite their not getting claimed by any drivers (CPU, internal and
> external RAM, internal busses, boot media)
> - some of the clocks aren't claimed by their peripheral drivers yet,
> either because of missing driver support or because device tree specs
> aren't available yet (but the workarounds will get removed as the
> drivers get adjusted and the device tree provides the clock specs)
> - some help introduce support for and migrate to the common
> infrastructure, while more appropriate support for specific hardware
> constraints isn't available yet (remaining changes are strictly
> internal to the clock driver and won't affect peripheral drivers)
>
> clkdev registration provides "alias names" for few clock items
> - to not break those peripheral drivers which encode their component
> index into the name that is used for clock lookup (UART, SPI, USB)
> - to not break those drivers which use names for the clock lookup which
> were encoded in the previous PPC_CLOCK implementation (NFC, VIU, CAN)
> this workaround will get removed as these drivers get adjusted after
> device tree based clock lookup has become available
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> arch/powerpc/platforms/512x/Kconfig | 14 +-
> arch/powerpc/platforms/512x/Makefile | 4 +-
> arch/powerpc/platforms/512x/clock-commonclk.c | 786 +++++++++++++++++++++++++
> include/linux/clk-provider.h | 16 +
> 4 files changed, 818 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c
>
[...]
> +static int get_freq_from_dt(char *propname)
> +{
> + struct device_node *np;
> + const unsigned int *prop;
> + int val;
> +
> + val = 0;
> + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-immr");
> + if (np) {
> + prop = of_get_property(np, propname, NULL);
> + if (prop)
> + val = *prop;
> + of_node_put(np);
> + }
> + return val;
> +}
Can you not use of_property_read_u32 here rather than of_get_property?
Also, this seems rather unlike the common clock bindings method for
describing frequencies in the dt. Given there's nothing in mainline
using this yet, we can do it 'right' from the start.
[...]
> + /*
> + * externally provided clocks (when implemented in hardware,
> + * device tree may specify values which otherwise were unknown)
> + */
> + freq = get_freq_from_dt("psc_mclk_in");
> + if (!freq)
> + freq = 25000000;
> + clks[MPC512x_CLK_PSC_MCLK_IN] = mpc512x_clk_fixed("psc_mclk_in", freq);
> + freq = get_freq_from_dt("spdif_tx_in");
> + clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_tx_in", freq);
> + freq = get_freq_from_dt("spdif_rx_in");
> + clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_rx_in", freq);
Can we not just use fixed-clocks for these in the dt? It feels odd to
describe them in a compeltely differnet way in the dt, especially as
we'll have to maintain some backwards compatibility for a while...
I see for psc_mclk_in we assume a default value if not present. I'm not
sure how to handle that, but I assume there's some way of finding out if
we've already registered a clock output with the same name?
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v3 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
From: Nicolin Chen @ 2013-08-05 11:28 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, alsa-devel, lars, timur, rob.herring, broonie,
linuxppc-dev
In-Reply-To: <1375697222.4000.59.camel@pizza.hi.pengutronix.de>
Hi Philipp,
Thanks for the comments! I'll revise it and send a v4.
Here is my reply to some parts of your question.
On Mon, Aug 05, 2013 at 12:07:02PM +0200, Philipp Zabel wrote:
> This looks to me like a case of configuration data in the device tree.
> Couldn't the tx/rx clock source be determined automatically or at least
> the SoC specific clock sources to the mux be known to the driver, so
> that we can use clock phandles here?
>
> What happens if a different tx-clk-source is needed for 48 kHz than for
> 44.1 kHz?
You are right about the case. I'll try to figure out a nicer way, including
for the different sample-rate.
> Do we already have anything for this in the kernel?
> It could also be done using:
>
> u8 tmp = input;
>
> tmp = ((tmp & 0b10101010) >> 1) | ((tmp << 1) & 0b10101010);
> tmp = ((tmp & 0b11001100) >> 2) | ((tmp << 2) & 0b11001100);
> tmp = ((tmp & 0b11110000) >> 4) | ((tmp << 4) & 0b11110000);
>
> return tmp;
I was also wondering this question but I couldn't find it.
And obviously your algorithm is better :)
> In principle, it should also be possible to let the SDMA engine only
> take the FIFOs' MSBs for S16_LE. Is this a limitation of the SDMA ROM
> script?
You are right about the idea and the inference.
^ permalink raw reply
* [PATCH v2 3/3] powerpc: Correctly context switch DSCR on POWER8
From: Michael Neuling @ 2013-08-05 11:00 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <21599.1375697783@ale.ozlabs.ibm.com>
POWER8 allows the DSCR to be accessed directly from userspace via a new SPR
number 0x3 (Rather than 0x11. DSCR SPR number 0x11 is still used on POWER8 but
like POWER7, is only accessible in HV and OS modes). Currently, we allow this
by setting H/FSCR DSCR bit on boot.
Unfortunately this doesn't work, as the kernel needs to see the DSCR change so
that it knows to no longer restore the system wide version of DSCR on context
switch (ie. to set thread.dscr_inherit).
This clears the H/FSCR DSCR bit initially. If a process then accesses the DSCR
(via SPR 0x3), it'll trap into the kernel where we set thread.dscr_inherit in
facility_unavailable_exception().
We also change _switch() so that we set or clear the H/FSCR DSCR bit based on
the thread.dscr_inherit.
Signed-off-by: Michael Neuling <mikey@neuling.org>
diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cpu_setup_power.S
index 18b5b9c..c7a3b81 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -123,14 +123,18 @@ __init_LPCR:
__init_FSCR:
mfspr r3,SPRN_FSCR
- ori r3,r3,FSCR_TAR|FSCR_DSCR|FSCR_EBB
+ ori r3,r3,FSCR_TAR|FSCR_EBB
+ li r5,HFSCR_DSCR
+ andc r3,r3,r5
mtspr SPRN_FSCR,r3
blr
__init_HFSCR:
mfspr r3,SPRN_HFSCR
ori r3,r3,HFSCR_TAR|HFSCR_TM|HFSCR_BHRB|HFSCR_PM|\
- HFSCR_DSCR|HFSCR_VECVSX|HFSCR_FP|HFSCR_EBB
+ HFSCR_VECVSX|HFSCR_FP|HFSCR_EBB
+ li r5,HFSCR_DSCR
+ andc r3,r3,r5
mtspr SPRN_HFSCR,r3
blr
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index ab15b8d..4674fe6 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -584,9 +584,34 @@ BEGIN_FTR_SECTION
ld r7,DSCR_DEFAULT@toc(2)
ld r0,THREAD_DSCR(r4)
cmpwi r6,0
+ li r8, FSCR_DSCR
bne 1f
ld r0,0(r7)
-1: cmpd r0,r25
+ b 3f
+1:
+ BEGIN_FTR_SECTION_NESTED(70)
+ mfspr r6, SPRN_FSCR
+ or r6, r6, r8
+ mtspr SPRN_FSCR, r6
+ BEGIN_FTR_SECTION_NESTED(69)
+ mfspr r6, SPRN_HFSCR
+ or r6, r6, r8
+ mtspr SPRN_HFSCR, r6
+ END_FTR_SECTION_NESTED(CPU_FTR_HVMODE, CPU_FTR_HVMODE, 69)
+ b 4f
+ END_FTR_SECTION_NESTED(CPU_FTR_ARCH_207S, CPU_FTR_ARCH_207S, 70)
+3:
+ BEGIN_FTR_SECTION_NESTED(70)
+ mfspr r6, SPRN_FSCR
+ andc r6, r6, r8
+ mtspr SPRN_FSCR, r6
+ BEGIN_FTR_SECTION_NESTED(69)
+ mfspr r6, SPRN_HFSCR
+ andc r6, r6, r8
+ mtspr SPRN_HFSCR, r6
+ END_FTR_SECTION_NESTED(CPU_FTR_HVMODE, CPU_FTR_HVMODE, 69)
+ END_FTR_SECTION_NESTED(CPU_FTR_ARCH_207S, CPU_FTR_ARCH_207S, 70)
+4: cmpd r0,r25
beq 2f
mtspr SPRN_DSCR,r0
2:
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index bf33c22..e435bc0 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -44,9 +44,7 @@
#include <asm/machdep.h>
#include <asm/rtas.h>
#include <asm/pmc.h>
-#ifdef CONFIG_PPC32
#include <asm/reg.h>
-#endif
#ifdef CONFIG_PMAC_BACKLIGHT
#include <asm/backlight.h>
#endif
@@ -1296,43 +1294,54 @@ void vsx_unavailable_exception(struct pt_regs *regs)
die("Unrecoverable VSX Unavailable Exception", regs, SIGABRT);
}
+#ifdef CONFIG_PPC64
void facility_unavailable_exception(struct pt_regs *regs)
{
static char *facility_strings[] = {
- "FPU",
- "VMX/VSX",
- "DSCR",
- "PMU SPRs",
- "BHRB",
- "TM",
- "AT",
- "EBB",
- "TAR",
+ [FSCR_FP_LG] = "FPU",
+ [FSCR_VECVSX_LG] = "VMX/VSX",
+ [FSCR_DSCR_LG] = "DSCR",
+ [FSCR_PM_LG] = "PMU SPRs",
+ [FSCR_BHRB_LG] = "BHRB",
+ [FSCR_TM_LG] = "TM",
+ [FSCR_EBB_LG] = "EBB",
+ [FSCR_TAR_LG] = "TAR",
};
- char *facility, *prefix;
+ char *facility = "unknown";
u64 value;
+ u8 status;
+ bool hv;
- if (regs->trap == 0xf60) {
- value = mfspr(SPRN_FSCR);
- prefix = "";
- } else {
+ hv = (regs->trap == 0xf80);
+ if (hv)
value = mfspr(SPRN_HFSCR);
- prefix = "Hypervisor ";
+ else
+ value = mfspr(SPRN_FSCR);
+
+ status = value >> 56;
+ if (status == FSCR_DSCR_LG) {
+ /* User is acessing the DSCR. Set the inherit bit and allow
+ * the user to set it directly in future by setting via the
+ * H/FSCR DSCR bit.
+ */
+ current->thread.dscr_inherit = 1;
+ if (hv)
+ mtspr(SPRN_HFSCR, value | HFSCR_DSCR);
+ else
+ mtspr(SPRN_FSCR, value | FSCR_DSCR);
+ return;
}
- value = value >> 56;
+ if ((status < ARRAY_SIZE(facility_strings)) &&
+ facility_strings[status])
+ facility = facility_strings[status];
/* We restore the interrupt state now */
if (!arch_irq_disabled_regs(regs))
local_irq_enable();
- if (value < ARRAY_SIZE(facility_strings))
- facility = facility_strings[value];
- else
- facility = "unknown";
-
pr_err("%sFacility '%s' unavailable, exception at 0x%lx, MSR=%lx\n",
- prefix, facility, regs->nip, regs->msr);
+ hv ? "Hypervisor " : "", facility, regs->nip, regs->msr);
if (user_mode(regs)) {
_exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
@@ -1341,6 +1350,7 @@ void facility_unavailable_exception(struct pt_regs *regs)
die("Unexpected facility unavailable exception", regs, SIGABRT);
}
+#endif
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
^ permalink raw reply related
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