[PATCH] net/mlx4: Support shutdown() interface
In kexec scenario, we failed to load the mlx4 driver in the
second kernel because the ownership bit was hold by the first
kernel without release correctly.
The patch adds shutdown() interface so that the ownership can
be released correctly in the first kernel. It also helps avoiding
EEH error happened during boot stage of the second kernel because
of undesired traffic, which can't be handled by hardware during
that stage on Power platform.
Signed-off-by: Gavin Shan
Tested-by: Wei Yang
---
drivers/net/ethernet/mellanox/mlx4/main.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c
b/drivers/net/ethernet/mellanox/mlx4/main.c
index d711158..5a6105f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -2684,6 +2684,7 @@ static struct pci_driver mlx4_driver = {
.name = DRV_NAME,
.id_table = mlx4_pci_table,
.probe = mlx4_init_one,
+ .shutdown = mlx4_remove_one,
.remove = mlx4_remove_one,
.err_handler= &mlx4_err_handler,
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 03/11] perf: provide a common perf_event_nop_0() for use with .event_idx
On 03/03/2014 09:19 PM, Michael Ellerman wrote: On Thu, 2014-27-02 at 21:04:56 UTC, Cody P Schafer wrote: Rather an having every pmu that needs a function that just returns 0 for .event_idx define their own copy, reuse the one in kernel/events/core.c. Rename from perf_swevent_event_idx() because we're no longer using it for just software events. Naming is based on the perf_pmu_nop_*() functions. You could just use perf_pmu_nop_int() directly. No, .event_idx needs something that takes a (struct perf_event *), perf_pmu_nop_int() takes a (struct pmu *). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/2] powerpc/perf: Add lost exception workaround
Some power8 revisions have a hardware bug where we can lose a PMU
exception, this commit adds a workaround to detect the bad condition and
rectify the situation.
See the comment in the commit for a full description.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/reg.h | 2 +
arch/powerpc/perf/core-book3s.c | 100 +++-
arch/powerpc/perf/power8-pmu.c | 5 ++
3 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 90c06ec..3003472 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -670,6 +670,7 @@
#define MMCR0_PMC1CE 0x8000UL /* PMC1 count enable*/
#define MMCR0_PMCjCE 0x4000UL /* PMCj count enable*/
#define MMCR0_TRIGGER0x2000UL /* TRIGGER enable */
+#define MMCR0_PMAO_SYNC 0x0800UL /* PMU interrupt is synchronous */
#define MMCR0_PMAO 0x0080UL /* performance monitor alert has occurred,
set to 0 after handling exception */
#define MMCR0_SHRFC 0x0040UL /* SHRre freeze conditions between threads
*/
#define MMCR0_FC56 0x0010UL /* freeze counters 5 and 6 */
@@ -703,6 +704,7 @@
#define SPRN_EBBHR 804 /* Event based branch handler register */
#define SPRN_EBBRR 805 /* Event based branch return register */
#define SPRN_BESCR 806 /* Branch event status and control register */
+#define BESCR_GE 0x8000ULL /* Global Enable */
#define SPRN_WORT 895 /* Workload optimization register - thread */
#define SPRN_PMC1 787
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 67cf220..9b3065d 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -120,6 +120,7 @@ static inline void power_pmu_bhrb_enable(struct perf_event
*event) {}
static inline void power_pmu_bhrb_disable(struct perf_event *event) {}
void power_pmu_flush_branch_stack(void) {}
static inline void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw) {}
+static void pmao_restore_workaround(bool ebb) { }
#endif /* CONFIG_PPC32 */
static bool regs_use_siar(struct pt_regs *regs)
@@ -545,10 +546,18 @@ static unsigned long ebb_switch_in(bool ebb, unsigned
long mmcr0)
/* Enable EBB and read/write to all 6 PMCs for userspace */
mmcr0 |= MMCR0_EBE | MMCR0_PMCC_U6;
- /* Add any bits from the user reg, FC or PMAO */
+ /*
+* Add any bits from the user MMCR0, FC or PMAO. This is compatible
+* with pmao_restore_workaround() because we may add PMAO but we never
+* clear it here.
+*/
mmcr0 |= current->thread.mmcr0;
- /* Be careful not to set PMXE if userspace had it cleared */
+ /*
+* Be careful not to set PMXE if userspace had it cleared. This is also
+* compatible with pmao_restore_workaround() because it has already
+* cleared PMXE and we leave PMAO alone.
+*/
if (!(current->thread.mmcr0 & MMCR0_PMXE))
mmcr0 &= ~MMCR0_PMXE;
@@ -559,6 +568,91 @@ static unsigned long ebb_switch_in(bool ebb, unsigned long
mmcr0)
out:
return mmcr0;
}
+
+static void pmao_restore_workaround(bool ebb)
+{
+ unsigned pmcs[6];
+
+ if (!cpu_has_feature(CPU_FTR_PMAO_BUG))
+ return;
+
+ /*
+* On POWER8E there is a hardware defect which affects the PMU context
+* switch logic, ie. power_pmu_disable/enable().
+*
+* When a counter overflows PMXE is cleared and FC/PMAO is set in MMCR0
+* by the hardware. Sometime later the actual PMU exception is
+* delivered.
+*
+* If we context switch, or simply disable/enable, the PMU prior to the
+* exception arriving, the exception will be lost when we clear PMAO.
+*
+* When we reenable the PMU, we will write the saved MMCR0 with PMAO
+* set, and this _should_ generate an exception. However because of the
+* defect no exception is generated when we write PMAO, and we get
+* stuck with no counters counting but no exception delivered.
+*
+* The workaround is to detect this case and tweak the hardware to
+* create another pending PMU exception.
+*
+* We do that by setting up PMC6 (cycles) for an imminent overflow and
+* enabling the PMU. That causes a new exception to be generated in the
+* chip, but we don't take it yet because we have interrupts hard
+* disabled. We then write back the PMU state as we want it to be seen
+* by the exception handler. When we reenable interrupts the exception
+* handler will be called and see the correct state.
+*
+* The logic is the same for EBB, except that the exception is gated by
+* us having interrupts hard disabled as well as the fact that we are
+* not in userspace. The exc
[PATCH v3 1/2] powerpc: Add a cpu feature CPU_FTR_PMAO_BUG
Some power8 revisions have a hardware bug where we can lose a
Performance Monitor (PMU) exception under certain circumstances.
We will be adding a workaround for this case, see the next commit for
details. The observed behaviour is that writing PMAO doesn't cause an
exception as we would expect, hence the name of the feature.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/cputable.h | 6 --
arch/powerpc/kernel/cputable.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
v3: Add CPU_FTRS_POWER8E to the possible map!
v2: Set the bit directly via the cputable entry for POWER8E.
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 617cc76..bc23477 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -189,6 +189,7 @@ extern const char *powerpc_base_platform;
#defineCPU_FTR_HAS_PPR
LONG_ASM_CONST(0x0200)
#define CPU_FTR_DAWR LONG_ASM_CONST(0x0400)
#define CPU_FTR_DABRX LONG_ASM_CONST(0x0800)
+#define CPU_FTR_PMAO_BUG LONG_ASM_CONST(0x1000)
#ifndef __ASSEMBLY__
@@ -445,6 +446,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_DAWR | \
CPU_FTR_ARCH_207S | CPU_FTR_TM_COMP)
+#define CPU_FTRS_POWER8E (CPU_FTRS_POWER8 | CPU_FTR_PMAO_BUG)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
@@ -466,8 +468,8 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 |\
CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 | \
- CPU_FTRS_POWER7 | CPU_FTRS_POWER8 | CPU_FTRS_CELL | \
- CPU_FTRS_PA6T | CPU_FTR_VSX)
+ CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | CPU_FTRS_POWER8 | \
+ CPU_FTRS_CELL | CPU_FTRS_PA6T | CPU_FTR_VSX)
#endif
#else
enum {
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 6c8dd5d..c1faade 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -510,7 +510,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_mask = 0x,
.pvr_value = 0x004b,
.cpu_name = "POWER8E (raw)",
- .cpu_features = CPU_FTRS_POWER8,
+ .cpu_features = CPU_FTRS_POWER8E,
.cpu_user_features = COMMON_USER_POWER8,
.cpu_user_features2 = COMMON_USER2_POWER8,
.mmu_features = MMU_FTRS_POWER8,
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 03/11] perf: provide a common perf_event_nop_0() for use with .event_idx
On Thu, 2014-27-02 at 21:04:56 UTC, Cody P Schafer wrote:
> Rather an having every pmu that needs a function that just returns 0 for
> .event_idx define their own copy, reuse the one in kernel/events/core.c.
>
> Rename from perf_swevent_event_idx() because we're no longer using it
> for just software events. Naming is based on the perf_pmu_nop_*()
> functions.
You could just use perf_pmu_nop_int() directly.
Peterz, OK by you?
cheers
> Signed-off-by: Cody P Schafer
> ---
> include/linux/perf_event.h | 1 +
> kernel/events/core.c | 10 +-
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 3da5081..24a7b45 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -560,6 +560,7 @@ extern void perf_pmu_migrate_context(struct pmu *pmu,
> extern u64 perf_event_read_value(struct perf_event *event,
>u64 *enabled, u64 *running);
>
> +extern int perf_event_nop_0(struct perf_event *event);
>
> struct perf_sample_data {
> u64 type;
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 56003c6..2938a77 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5816,7 +5816,7 @@ static int perf_swevent_init(struct perf_event *event)
> return 0;
> }
>
> -static int perf_swevent_event_idx(struct perf_event *event)
> +int perf_event_nop_0(struct perf_event *event)
> {
> return 0;
> }
> @@ -5831,7 +5831,7 @@ static struct pmu perf_swevent = {
> .stop = perf_swevent_stop,
> .read = perf_swevent_read,
>
> - .event_idx = perf_swevent_event_idx,
> + .event_idx = perf_event_nop_0,
> };
>
> #ifdef CONFIG_EVENT_TRACING
> @@ -5950,7 +5950,7 @@ static struct pmu perf_tracepoint = {
> .stop = perf_swevent_stop,
> .read = perf_swevent_read,
>
> - .event_idx = perf_swevent_event_idx,
> + .event_idx = perf_event_nop_0,
> };
>
> static inline void perf_tp_register(void)
> @@ -6177,7 +6177,7 @@ static struct pmu perf_cpu_clock = {
> .stop = cpu_clock_event_stop,
> .read = cpu_clock_event_read,
>
> - .event_idx = perf_swevent_event_idx,
> + .event_idx = perf_event_nop_0,
> };
>
> /*
> @@ -6257,7 +6257,7 @@ static struct pmu perf_task_clock = {
> .stop = task_clock_event_stop,
> .read = task_clock_event_read,
>
> - .event_idx = perf_swevent_event_idx,
> + .event_idx = perf_event_nop_0,
> };
>
> static void perf_pmu_nop_void(struct pmu *pmu)
> --
> 1.9.0
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 02/11] perf: add PMU_FORMAT_RANGE() helper for use by sw-like pmus
On Thu, 2014-27-02 at 21:04:55 UTC, Cody P Schafer wrote:
> Add PMU_FORMAT_RANGE() and PMU_FORMAT_RANGE_RESERVED() (for reserved
> areas) which generate functions to extract the relevent bits from
> event->attr.config{,1,2} for use by sw-like pmus where the
> 'config{,1,2}' values don't map directly to hardware registers.
>
> Signed-off-by: Cody P Schafer
> ---
> include/linux/perf_event.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index e56b07f..3da5081 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -871,4 +871,21 @@ _name##_show(struct device *dev,
> \
> \
> static struct device_attribute format_attr_##_name = __ATTR_RO(_name)
>
> +#define PMU_FORMAT_RANGE(name, attr_var, bit_start, bit_end) \
> +PMU_FORMAT_ATTR(name, #attr_var ":" #bit_start "-" #bit_end);
> \
> +PMU_FORMAT_RANGE_RESERVED(name, attr_var, bit_start, bit_end)
I really think these should have event in the name.
Someone looking at the code is going to see event_get_foo() and wonder where
that is defined. Grep won't find a definition, tags won't find a definition,
the least you can do is have the macro name give some hint.
> +#define PMU_FORMAT_RANGE_RESERVED(name, attr_var, bit_start, bit_end)
> \
It doesn't generate a format attribute.
> +static u64 event_get_##name##_max(void)
> \
> +{\
> + int bits = (bit_end) - (bit_start) + 1; \
> + return ((0x1ULL << (bits - 1ULL)) - 1ULL) | \
> + (0xFULL << (bits - 4ULL)); \
What's wrong with:
(0x1ULL << ((bit_end) - (bit_start) + 1)) - 1ULL;
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Check that all cpu features are in the possible map
On Tue, 2014-03-04 at 13:44 +1100, Michael Ellerman wrote:
> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> index 6c8dd5d..eb31713 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -2255,6 +2255,15 @@ static struct cpu_spec * __init
> setup_cpu_spec(unsigned long offset,
> }
> #endif /* CONFIG_PPC64 || CONFIG_BOOKE */
>
> + /*
> + * Check that all CPU features are in the possible mask. We don't want
> + * to WARN() because we're called very early, and doing so will kill
> + * the machine, so just printk() instead.
> + */
> + if (t->cpu_features != (t->cpu_features & CPU_FTRS_POSSIBLE))
> + printk("WARNING: cpu spec contains impossible features!
> 0x%lx\n",
> + (t->cpu_features & ~CPU_FTRS_POSSIBLE));
Actually even this is not safe.
printk() takes the logbuf_lock, but we don't have a paca yet, so our LOCK_TOKEN
will be some random guff in low memory. And although that's OK, we're single
threaded, it's a bit fishy.
What's worse is printk() does local_irq_save(), which will _store_ to our paca
(soft_enabled), and so we risk flipping a value somewhere.
Interestingly lockdep appears to be OK, even though we haven't initialised it
yet. printk() helpfully turns lockdep off before doing any locking.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Check that all cpu features are in the possible map
cpu_has_feature() has an optimisation where it maintains a map of
possible cpu features. This allows the compiler to determine at compile
time that some cpu_has_feature() checks will always return 0, and
therefore the code guarded by the check can be elided.
However we have no logic to check whether the set of cpu features in the
current cpu spec are in the possible map. Although that should never
happen, if it does things are likely to go badly. So add a check and
print a warning.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/cputable.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 6c8dd5d..eb31713 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -2255,6 +2255,15 @@ static struct cpu_spec * __init setup_cpu_spec(unsigned
long offset,
}
#endif /* CONFIG_PPC64 || CONFIG_BOOKE */
+ /*
+* Check that all CPU features are in the possible mask. We don't want
+* to WARN() because we're called very early, and doing so will kill
+* the machine, so just printk() instead.
+*/
+ if (t->cpu_features != (t->cpu_features & CPU_FTRS_POSSIBLE))
+ printk("WARNING: cpu spec contains impossible features!
0x%lx\n",
+ (t->cpu_features & ~CPU_FTRS_POSSIBLE));
+
return t;
}
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Align p_dyn, p_rela and p_st symbols
The 64bit relocation code places a few symbols in the text segment. These symbols are only 4 byte aligned where they need to be 8 byte aligned. Add an explicit alignment. Signed-off-by: Anton Blanchard Cc: sta...@vger.kernel.org --- diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S index 1482327..d88736f 100644 --- a/arch/powerpc/kernel/reloc_64.S +++ b/arch/powerpc/kernel/reloc_64.S @@ -81,6 +81,7 @@ _GLOBAL(relocate) 6: blr +.balign 8 p_dyn: .llong __dynamic_start - 0b p_rela:.llong __rela_dyn_start - 0b p_st: .llong _stext - 0b ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Panic on ppc64 with numa_balancing and !sparsemem_vmemmap
On Tue, Mar 04, 2014 at 12:45:19AM +0530, Aneesh Kumar K.V wrote: > Mel Gorman writes: > > > On Wed, Feb 19, 2014 at 11:32:00PM +0530, Srikar Dronamraju wrote: > >> > >> On a powerpc machine with CONFIG_NUMA_BALANCING=y and > >> CONFIG_SPARSEMEM_VMEMMAP > >> not enabled, kernel panics. > >> > > > > This? > > This one fixed that crash on ppc64 > > http://mid.gmane.org/1393578122-6500-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com > Thanks. -- Mel Gorman SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Panic on ppc64 with numa_balancing and !sparsemem_vmemmap
Mel Gorman writes: > On Wed, Feb 19, 2014 at 11:32:00PM +0530, Srikar Dronamraju wrote: >> >> On a powerpc machine with CONFIG_NUMA_BALANCING=y and >> CONFIG_SPARSEMEM_VMEMMAP >> not enabled, kernel panics. >> > > This? This one fixed that crash on ppc64 http://mid.gmane.org/1393578122-6500-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Panic on ppc64 with numa_balancing and !sparsemem_vmemmap
On Wed, Feb 19, 2014 at 11:32:00PM +0530, Srikar Dronamraju wrote:
>
> On a powerpc machine with CONFIG_NUMA_BALANCING=y and CONFIG_SPARSEMEM_VMEMMAP
> not enabled, kernel panics.
>
This?
---8<---
sched: numa: Do not group tasks if last cpu is not set
On configurations with vmemmap disabled, the following partial is observed
[ 299.268623] CPU: 47 PID: 4366 Comm: numa01 Tainted: G D
3.14.0-rc5-vanilla #4
[ 299.278295] Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4
04/26/2012
[ 299.287452] task: 880c670bc110 ti: 880c66db6000 task.ti:
880c66db6000
[ 299.296642] RIP: 0010:[] []
task_numa_fault+0x50f/0x8b0
[ 299.306778] RSP: :880c66db7670 EFLAGS: 00010282
[ 299.313769] RAX: 33ee RBX: 880c670bc110 RCX: 0001
[ 299.322590] RDX: 0001 RSI: 0003 RDI:
[ 299.331394] RBP: 880c66db76c8 R08: R09: 000166b0
[ 299.340203] R10: 880c7ffecd80 R11: R12: 01ff
[ 299.348989] R13: 00ff R14: R15: 0003
[ 299.357763] FS: 7f5a60a3f700() GS:88106f2c()
knlGS:
[ 299.367510] CS: 0010 DS: ES: CR0: 80050033
[ 299.374913] CR2: 37da CR3: 000868ed4000 CR4: 07e0
[ 299.383726] Stack:
[ 299.387414] 0003 00010003
00010003
[ 299.396564] 811888f4 880c66db7698 0003
880c7f9b3ac0
[ 299.405730] 880c66ccebd8 0003
880c66db7718
[ 299.414907] Call Trace:
[ 299.419095] [] ? migrate_misplaced_page+0xb4/0x140
[ 299.427301] [] do_numa_page+0x18c/0x1f0
[ 299.434554] [] handle_mm_fault+0x617/0xf70
[ ..] SNIPPED
The oops occurs in task_numa_group looking up cpu_rq(LAST__CPU_MASK). The
bug exists for all configurations but will manifest differently. On vmemmap
configurations, it looks up garbage and on !vmemmap configuraitons it
will oops. This patch adds the necessary check and also fixes the type
for LAST__PID_MASK and LAST__CPU_MASK which are currently signed instead
of unsigned integers.
Signed-off-by: Mel Gorman
Cc: sta...@vger.kernel.org
diff --git a/include/linux/page-flags-layout.h
b/include/linux/page-flags-layout.h
index da52366..6f661d9 100644
--- a/include/linux/page-flags-layout.h
+++ b/include/linux/page-flags-layout.h
@@ -63,10 +63,10 @@
#ifdef CONFIG_NUMA_BALANCING
#define LAST__PID_SHIFT 8
-#define LAST__PID_MASK ((1 << LAST__PID_SHIFT)-1)
+#define LAST__PID_MASK ((1UL << LAST__PID_SHIFT)-1)
#define LAST__CPU_SHIFT NR_CPUS_BITS
-#define LAST__CPU_MASK ((1 << LAST__CPU_SHIFT)-1)
+#define LAST__CPU_MASK ((1UL << LAST__CPU_SHIFT)-1)
#define LAST_CPUPID_SHIFT (LAST__PID_SHIFT+LAST__CPU_SHIFT)
#else
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7815709..b44a8b1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1463,6 +1463,9 @@ static void task_numa_group(struct task_struct *p, int
cpupid, int flags,
int cpu = cpupid_to_cpu(cpupid);
int i;
+ if (unlikely(cpu == LAST__CPU_MASK && !cpu_online(cpu)))
+ return;
+
if (unlikely(!p->numa_group)) {
unsigned int size = sizeof(struct numa_group) +
2*nr_node_ids*sizeof(unsigned long);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Corenet: Add QE platform support for Corenet
On Feb 28, 2014, at 2:48 AM, Zhao Qiang wrote:
> There is QE on platform T104x, add support.
> Call funcs qe_ic_init and qe_init if CONFIG_QUICC_ENGINE is defined.
>
> Signed-off-by: Zhao Qiang
> ---
> arch/powerpc/platforms/85xx/corenet_generic.c | 32 +++
> 1 file changed, 32 insertions(+)
Can you use mpc85xx_qe_init() instead?
>
> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
> b/arch/powerpc/platforms/85xx/corenet_generic.c
> index fbd871e..f8c8e0c 100644
> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> @@ -26,6 +26,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -38,6 +40,10 @@ void __init corenet_gen_pic_init(void)
> unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
> MPIC_NO_RESET;
>
> +#ifdef CONFIG_QUICC_ENGINE
> + struct device_node *np;
> +#endif
> +
> if (ppc_md.get_irq == mpic_get_coreint_irq)
> flags |= MPIC_ENABLE_COREINT;
>
> @@ -45,6 +51,16 @@ void __init corenet_gen_pic_init(void)
> BUG_ON(mpic == NULL);
>
> mpic_init(mpic);
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> + if (np) {
> + qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> + qe_ic_cascade_high_mpic);
> + of_node_put(np);
> + }
> +#endif
> +
> }
>
> /*
> @@ -52,11 +68,24 @@ void __init corenet_gen_pic_init(void)
> */
> void __init corenet_gen_setup_arch(void)
> {
> +#ifdef CONFIG_QUICC_ENGINE
> + struct device_node *np;
> +#endif
> mpc85xx_smp_init();
>
> swiotlb_detect_4g();
>
> pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!np) {
> + pr_err("%s: Could not find Quicc Engine node\n", __func__);
> + return;
This doesn’t seem like an reasonable error message for common corenet platform.
It seems reasonable to build QE support but boot on a chip w/o QE.
> + }
> + qe_reset();
> + of_node_put(np);
> +#endif
> }
>
> static const struct of_device_id of_device_ids[] = {
> @@ -81,6 +110,9 @@ static const struct of_device_id of_device_ids[] = {
> {
> .compatible = "fsl,qoriq-pcie-v3.0",
> },
> + {
> + .compatible = "fsl,qe",
> + },
> /* The following two are for the Freescale hypervisor */
> {
> .name = "hypervisor",
> --
> 1.8.5
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] vfio-pci: avoid deadlock between unbind and VFIO_DEVICE_RESET
On Mon, 2014-03-03 at 12:28 -0300, Thadeu Lima de Souza Cascardo wrote:
> On Mon, Mar 03, 2014 at 08:09:22AM -0700, Alex Williamson wrote:
> > On Mon, 2014-03-03 at 11:33 -0300, Thadeu Lima de Souza Cascardo wrote:
> > > When we unbind vfio-pci from a device, while running a guest, we might
> > > have a deadlock when such a guest reboots.
> > >
> > > Unbind takes device_lock at device_release_driver, and waits for
> > > release_q at vfio_del_group_dev.
> > >
> > > release_q will only be woken up when all references to vfio_device are
> > > gone, and that includes open file descriptors, like the ones a guest
> > > on qemu will hold.
> > >
> > > If you try to reboot the guest, it will call VFIO_DEVICE_RESET, which
> > > calls pci_reset_function, which now grabs the device_lock, and we are
> > > deadlocked.
> > >
> > > Using device_trylock allow us to handle the case when the lock is
> > > already taken, and avoid this situation.
> > >
> > > Signed-off-by: Thadeu Lima de Souza Cascardo
> > > ---
> > >
> > > Not tested yet, but I would like some comments now, like would it be
> > > better to have a pci_try_reset_function, or do trylock on
> > > pci_reset_function itself?
> >
> >
> > We already have it:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61cf16d8bd38c3dc52033ea75d5b1f8368514a17
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=890ed578df82f5b7b5a874f9f2fa4f117305df5f
> >
> > Is there something insufficient about these or are you testing on and
> > older kernel? Thanks,
> >
> > Alex
>
> Sorry I missed it. On the rush to report and fix it, I looked only on my
> local branch. Should we backport those two patches to long term stable
> 3.10? I can reproduce the issue there.
Sure, if you're trying to exercise this path, it's easy to reproduce.
It's also relatively easy to avoid once you know it's there. It's not
obvious to me that this fix meets the stable patch rules though, it's
bigger than suggested, I'm not sure it really bothers people outside of
QA testing, it does cause a hang, but not a system hang. I'd certainly
suggest any downstream based on 3.10 that cares about vfio to pick it
up, does that make it sufficient for upstream stable? Thanks,
Alex
> > > ---
> > > drivers/vfio/pci/vfio_pci.c | 14 --
> > > 1 files changed, 12 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> > > index 3b76dc8..d1d2242 100644
> > > --- a/drivers/vfio/pci/vfio_pci.c
> > > +++ b/drivers/vfio/pci/vfio_pci.c
> > > @@ -513,8 +513,18 @@ static long vfio_pci_ioctl(void *device_data,
> > > return ret;
> > >
> > > } else if (cmd == VFIO_DEVICE_RESET) {
> > > - return vdev->reset_works ?
> > > - pci_reset_function(vdev->pdev) : -EINVAL;
> > > + struct pci_dev *pdev = vdev->pdev;
> > > + int ret = -EBUSY;
> > > + if (!vdev->reset_works)
> > > + return -EINVAL;
> > > + if (pci_cfg_access_trylock(pdev)) {
> > > + if (device_trylock(&pdev->dev)) {
> > > + ret = __pci_reset_function_locked(pdev);
> > > + device_unlock(&pdev->dev);
> > > + }
> > > + pci_cfg_access_unlock(pdev);
> > > + }
> > > + return ret;
> > >
> > > } else if (cmd == VFIO_DEVICE_GET_PCI_HOT_RESET_INFO) {
> > > struct vfio_pci_hot_reset_info hdr;
> >
> >
> >
> > ___
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] vfio-pci: avoid deadlock between unbind and VFIO_DEVICE_RESET
On Mon, Mar 03, 2014 at 08:09:22AM -0700, Alex Williamson wrote:
> On Mon, 2014-03-03 at 11:33 -0300, Thadeu Lima de Souza Cascardo wrote:
> > When we unbind vfio-pci from a device, while running a guest, we might
> > have a deadlock when such a guest reboots.
> >
> > Unbind takes device_lock at device_release_driver, and waits for
> > release_q at vfio_del_group_dev.
> >
> > release_q will only be woken up when all references to vfio_device are
> > gone, and that includes open file descriptors, like the ones a guest
> > on qemu will hold.
> >
> > If you try to reboot the guest, it will call VFIO_DEVICE_RESET, which
> > calls pci_reset_function, which now grabs the device_lock, and we are
> > deadlocked.
> >
> > Using device_trylock allow us to handle the case when the lock is
> > already taken, and avoid this situation.
> >
> > Signed-off-by: Thadeu Lima de Souza Cascardo
> > ---
> >
> > Not tested yet, but I would like some comments now, like would it be
> > better to have a pci_try_reset_function, or do trylock on
> > pci_reset_function itself?
>
>
> We already have it:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61cf16d8bd38c3dc52033ea75d5b1f8368514a17
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=890ed578df82f5b7b5a874f9f2fa4f117305df5f
>
> Is there something insufficient about these or are you testing on and
> older kernel? Thanks,
>
> Alex
Sorry I missed it. On the rush to report and fix it, I looked only on my
local branch. Should we backport those two patches to long term stable
3.10? I can reproduce the issue there.
Thanks.
Cascardo.
>
>
> > ---
> > drivers/vfio/pci/vfio_pci.c | 14 --
> > 1 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> > index 3b76dc8..d1d2242 100644
> > --- a/drivers/vfio/pci/vfio_pci.c
> > +++ b/drivers/vfio/pci/vfio_pci.c
> > @@ -513,8 +513,18 @@ static long vfio_pci_ioctl(void *device_data,
> > return ret;
> >
> > } else if (cmd == VFIO_DEVICE_RESET) {
> > - return vdev->reset_works ?
> > - pci_reset_function(vdev->pdev) : -EINVAL;
> > + struct pci_dev *pdev = vdev->pdev;
> > + int ret = -EBUSY;
> > + if (!vdev->reset_works)
> > + return -EINVAL;
> > + if (pci_cfg_access_trylock(pdev)) {
> > + if (device_trylock(&pdev->dev)) {
> > + ret = __pci_reset_function_locked(pdev);
> > + device_unlock(&pdev->dev);
> > + }
> > + pci_cfg_access_unlock(pdev);
> > + }
> > + return ret;
> >
> > } else if (cmd == VFIO_DEVICE_GET_PCI_HOT_RESET_INFO) {
> > struct vfio_pci_hot_reset_info hdr;
>
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] vfio-pci: avoid deadlock between unbind and VFIO_DEVICE_RESET
On Mon, 2014-03-03 at 11:33 -0300, Thadeu Lima de Souza Cascardo wrote:
> When we unbind vfio-pci from a device, while running a guest, we might
> have a deadlock when such a guest reboots.
>
> Unbind takes device_lock at device_release_driver, and waits for
> release_q at vfio_del_group_dev.
>
> release_q will only be woken up when all references to vfio_device are
> gone, and that includes open file descriptors, like the ones a guest
> on qemu will hold.
>
> If you try to reboot the guest, it will call VFIO_DEVICE_RESET, which
> calls pci_reset_function, which now grabs the device_lock, and we are
> deadlocked.
>
> Using device_trylock allow us to handle the case when the lock is
> already taken, and avoid this situation.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo
> ---
>
> Not tested yet, but I would like some comments now, like would it be
> better to have a pci_try_reset_function, or do trylock on
> pci_reset_function itself?
We already have it:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61cf16d8bd38c3dc52033ea75d5b1f8368514a17
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=890ed578df82f5b7b5a874f9f2fa4f117305df5f
Is there something insufficient about these or are you testing on and
older kernel? Thanks,
Alex
> ---
> drivers/vfio/pci/vfio_pci.c | 14 --
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 3b76dc8..d1d2242 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -513,8 +513,18 @@ static long vfio_pci_ioctl(void *device_data,
> return ret;
>
> } else if (cmd == VFIO_DEVICE_RESET) {
> - return vdev->reset_works ?
> - pci_reset_function(vdev->pdev) : -EINVAL;
> + struct pci_dev *pdev = vdev->pdev;
> + int ret = -EBUSY;
> + if (!vdev->reset_works)
> + return -EINVAL;
> + if (pci_cfg_access_trylock(pdev)) {
> + if (device_trylock(&pdev->dev)) {
> + ret = __pci_reset_function_locked(pdev);
> + device_unlock(&pdev->dev);
> + }
> + pci_cfg_access_unlock(pdev);
> + }
> + return ret;
>
> } else if (cmd == VFIO_DEVICE_GET_PCI_HOT_RESET_INFO) {
> struct vfio_pci_hot_reset_info hdr;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH] vfio-pci: avoid deadlock between unbind and VFIO_DEVICE_RESET
When we unbind vfio-pci from a device, while running a guest, we might
have a deadlock when such a guest reboots.
Unbind takes device_lock at device_release_driver, and waits for
release_q at vfio_del_group_dev.
release_q will only be woken up when all references to vfio_device are
gone, and that includes open file descriptors, like the ones a guest
on qemu will hold.
If you try to reboot the guest, it will call VFIO_DEVICE_RESET, which
calls pci_reset_function, which now grabs the device_lock, and we are
deadlocked.
Using device_trylock allow us to handle the case when the lock is
already taken, and avoid this situation.
Signed-off-by: Thadeu Lima de Souza Cascardo
---
Not tested yet, but I would like some comments now, like would it be
better to have a pci_try_reset_function, or do trylock on
pci_reset_function itself?
---
drivers/vfio/pci/vfio_pci.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 3b76dc8..d1d2242 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -513,8 +513,18 @@ static long vfio_pci_ioctl(void *device_data,
return ret;
} else if (cmd == VFIO_DEVICE_RESET) {
- return vdev->reset_works ?
- pci_reset_function(vdev->pdev) : -EINVAL;
+ struct pci_dev *pdev = vdev->pdev;
+ int ret = -EBUSY;
+ if (!vdev->reset_works)
+ return -EINVAL;
+ if (pci_cfg_access_trylock(pdev)) {
+ if (device_trylock(&pdev->dev)) {
+ ret = __pci_reset_function_locked(pdev);
+ device_unlock(&pdev->dev);
+ }
+ pci_cfg_access_unlock(pdev);
+ }
+ return ret;
} else if (cmd == VFIO_DEVICE_GET_PCI_HOT_RESET_INFO) {
struct vfio_pci_hot_reset_info hdr;
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc/fsl-booke: Add initial T208x QDS board support
Add support for Freescale T2080/T2081 QDS Development System Board.
T2081QDS board shares the same PCB with T1040QDS with some differences.
The T2080QDS Development System is a high-performance computing,
evaluation, and development platform that supports T2080 QorIQ
Power Architecture processor, with following major features:
T2080QDS feature overview:
Processor:
- T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
Memory:
- Single memory controller capable of supporting DDR3 and DDR3-LV devices
- Two DDR3 memory, 4GB, Dual rank @ 1866 Mbps data rate, and ECC support
Ethernet interfaces:
- Two 1Gbps RGMII on-board ports
- Four 10Gbps XFI on-board cages
- 1Gbps/2.5Gbps SGMII Riser card
- 10Gbps XAUI Riser card
Accelerator:
- DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
SerDes:
- 16 lanes up to 10.3125GHz
- Supports Aurora debug, PEX, SATA, SGMII, sRIO, HiGig, XFI and XAUI
IFC:
- 128MB NOR Flash, 512MB NAND Flash, PromJet debug port and FPGA
eSPI:
- Three SPI flash (16MB N25Q128A + 16MB EN25S64 + 512KB SST25WF040)
USB:
- Two USB2.0 ports with internal PHY (one Type-A + one micro Type-AB)
PCIE:
- Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0 with SR-IOV)
SATA:
- Two SATA 2.0 ports on-board
SRIO:
- Two Serial RapidIO 2.0 ports up to 5 GHz
eSDHC:
- Supports SD/MMC/eMMC Card
DMA:
- Three 8-channels DMA controllers
I2C:
- Four I2C controllers.
UART:
- Dual 4-pins UART serial ports
System Logic:
- QIXIS-II FPGA system controll
Differences between T2080 and T2081:
Feature T2080 T2081
1G Ethernet numbers: 8 6
10G Ethernet numbers: 4 2
SerDes lanes: 168
Serial RapidIO,RMan: 2 no
SATA Controller: 2 no
Aurora: yes no
SoC Package: 896-pins 780-pins
Signed-off-by: Shengzhou Liu
---
arch/powerpc/boot/dts/t2080qds.dts| 57 +++
arch/powerpc/boot/dts/t2081qds.dts| 48 ++
arch/powerpc/boot/dts/t208xqds.dtsi | 213 ++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 4 +
5 files changed, 323 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/boot/dts/t2080qds.dts
create mode 100644 arch/powerpc/boot/dts/t2081qds.dts
create mode 100644 arch/powerpc/boot/dts/t208xqds.dtsi
diff --git a/arch/powerpc/boot/dts/t2080qds.dts
b/arch/powerpc/boot/dts/t2080qds.dts
new file mode 100644
index 000..aa1d6d8
--- /dev/null
+++ b/arch/powerpc/boot/dts/t2080qds.dts
@@ -0,0 +1,57 @@
+/*
+ * T2080QDS Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t208xsi-pre.dtsi"
+/include/ "t208xqds.dtsi"
+
+/ {
+ model = "fsl,T2080QDS";
+ compatible = "fsl,T2080QDS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ rio: rapidio@ffe0c {
+ reg = <0xf 0xfe0c 0 0x11000>;
+
+ port1 {
+ ranges = <0 0 0xc 0x2000 0 0x1000>;
+ };
+ port2 {
+ ranges = <0 0 0xc 0x3000 0 0x1000>;
+ }
[PATCH 3/3] powerpc/t2080rdb: Add T2080RDB board support
T2080PCIe-RDB is a Freescale Reference Design Board that hosts the T2080 SoC.
The board feature overview:
Processor:
- T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
DDR Memory:
- Single memory controller capable of supporting DDR3 and DDR3-LP devices
- 72bit 4GB DDR3-LP SODIMM in slot
Ethernet interfaces:
- Two 10M/100M/1Gbps RGMII ports on-board
- Two 10Gbps SFP+ ports on-board
- Two 10Gbps Base-T ports on-board
Accelerator:
- DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
SerDes 16 lanes configuration:
- SerDes-1 Lane A-B: to two 10G SFP+ (MAC9 & MAC10)
- SerDes-1 Lane C-D: to two 10G Base-T (MAC1 & MAC2)
- SerDes-1 Lane E-H: to PCIe goldfinger (PCIe4 x4, Gen3)
- SerDes-2 Lane A-D: to PCIe slot (PCIe1 x4, Gen2)
- SerDes-2 Lane E-F: to C293 secure co-processor (PCIe2 x2)
- SerDes-2 Lane G-H: to SATA1 & SATA2
IFC/Local Bus
- NOR: 128MB 16-bit NOR flash
- NAND: 512MB 8-bit NAND flash
- CPLD: for system controlling with programable header on-board
eSPI:
- 64MB N25Q512 SPI flash
USB:
- Two USB2.0 ports with internal PHY (both Type-A)
PCIe:
- One PCIe x4 gold-finger
- One PCIe x4 connector
- One PCIe x2 end-point device (C293 crypto co-processor)
SATA:
- Two SATA 2.0 ports on-board
SDHC:
- support a TF-card on-board
I2C:
- Four I2C controllers.
UART:
- Dual 4-pins UART serial ports
This board can work in two mode: standalone mode and PCIe endpoint mode.
Signed-off-by: Shengzhou Liu
---
arch/powerpc/boot/dts/t2080rdb.dts| 57 +++
arch/powerpc/boot/dts/t208xrdb.dtsi | 210 ++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 4 +-
4 files changed, 271 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/t2080rdb.dts
create mode 100644 arch/powerpc/boot/dts/t208xrdb.dtsi
diff --git a/arch/powerpc/boot/dts/t2080rdb.dts
b/arch/powerpc/boot/dts/t2080rdb.dts
new file mode 100644
index 000..e889104
--- /dev/null
+++ b/arch/powerpc/boot/dts/t2080rdb.dts
@@ -0,0 +1,57 @@
+/*
+ * T2080PCIe-RDB Board Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t208xsi-pre.dtsi"
+/include/ "t208xrdb.dtsi"
+
+/ {
+ model = "fsl,T2080RDB";
+ compatible = "fsl,T2080RDB";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ rio: rapidio@ffe0c {
+ reg = <0xf 0xfe0c 0 0x11000>;
+
+ port1 {
+ ranges = <0 0 0xc 0x2000 0 0x1000>;
+ };
+ port2 {
+ ranges = <0 0 0xc 0x3000 0 0x1000>;
+ };
+ };
+};
+
+/include/ "fsl/t2080si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t208xrdb.dtsi
b/arch/powerpc/boot/dts/t208xrdb.dtsi
new file mode 100644
index 000..439a5c1
--- /dev/null
+++ b/arch/powerpc/boot/dts/t208xrdb.dtsi
@@ -0,0 +1,210 @@
+/*
+ * T2080/T2081PCIe-RDB Board Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the fo
[PATCH 1/3] powerpc/fsl-booke: Add support for T2080/T2081 SoC
Add support for T2080/T2081 SoC without DPAA components.
The T2080 SoC includes the following function and features:
- Four dual-threaded 64-bit Power architecture e6500 cores, up to 1.8GHz
- 2MB L2 cache and 512KB CoreNet platform cache (CPC)
- Hierarchical interconnect fabric
- One 32-/64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
- 16 SerDes lanes up to 10.3125 GHz
- 8 Ethernet interfaces (multiple 1G/2.5G/10G MACs)
- High-speed peripheral interfaces
- Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0)
- Two Serial RapidIO 2.0 controllers/ports running at up to 5 GHz
- Additional peripheral interfaces
- Two serial ATA (SATA 2.0) controllers
- Two high-speed USB 2.0 controllers with integrated PHY
- Enhanced secure digital host controller (SD/SDXC/eMMC)
- Enhanced serial peripheral interface (eSPI)
- Four I2C controllers
- Four 2-pin UARTs or two 4-pin UARTs
- Integrated Flash Controller supporting NAND and NOR flash
- Three eight-channel DMA engines
- Support for hardware virtualization and partitioning enforcement
- QorIQ Platform's Trust Architecture 2.0
T2081 is a reduced personality of T2080 without SATA, sRIO, RMan,
Aurora, and with less SerDes lanes and ethernet interfaces.
Signed-off-by: Shengzhou Liu
---
arch/powerpc/boot/dts/fsl/t2080si-post.dtsi | 60 +
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 344
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 96
arch/powerpc/include/asm/mpc85xx.h | 2 +
4 files changed, 502 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
new file mode 100644
index 000..1a902fe
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
@@ -0,0 +1,60 @@
+/*
+ * T2080 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "t2081si-post.dtsi"
+
+&soc {
+/include/ "qoriq-sata2-0.dtsi"
+/include/ "qoriq-sata2-1.dtsi"
+};
+
+&rio {
+ compatible = "fsl,srio";
+ interrupts = <16 2 1 11>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ port1 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ cell-index = <1>;
+ };
+
+ port2 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ cell-index = <2>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
new file mode 100644
index 000..0f05be2
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
@@ -0,0 +1,344 @@
+/*
+ * T2081 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
Re: [PATCH 2/3] dts: mpc512x: adjust clock specs for FEC nodes
On Mon, Feb 24, 2014 at 11:25 +0100, Gerhard Sittig wrote:
>
> a recent FEC binding document update that was motivated by i.MX
> development revealed that ARM and PowerPC implementations in Linux
> did not agree on the clock names to use for the FEC nodes
>
> change clock names from "per" to "ipg" in the FEC nodes of the
> mpc5121.dtsi include file such that the .dts specs comply with
> the common FEC binding
>
> this "incompatible" change does not break operation, because
> - COMMON_CLK support for MPC5121/23/25 and adjusted .dts files
> were only introduced in Linux v3.14-rc1, no mainline release
> provided these specs before
> - if this change won't make it for v3.14, the MPC512x CCF support
> provides full backwards compability, and keeps operating with
> device trees which lack clock specs or don't match in the names
>
> Signed-off-by: Gerhard Sittig
ping
Are there opinions about making PowerPC users of FEC use the same
clock names as ARM users do, to re-use (actually: keep sharing)
the FEC binding? The alternative would be to fragment the FEC
binding into several bindings for ARM and PowerPC, which I feel
would be undesirable, and is not necessary.
It would be nice to ship v3.14 (the first release with proper CCF
support for MPC512x) in a shape that is consistent with other FEC
users (ARM i.MX). We are lucky to have noticed the difference
before the release, and need not introduce the incompatibility,
and need not document and support obsolete conditions but can fix
them instead.
> ---
> arch/powerpc/boot/dts/mpc5121.dtsi |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi
> b/arch/powerpc/boot/dts/mpc5121.dtsi
> index 2c0e1552d20b..a5a375598ed8 100644
> --- a/arch/powerpc/boot/dts/mpc5121.dtsi
> +++ b/arch/powerpc/boot/dts/mpc5121.dtsi
> @@ -281,7 +281,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
> clocks = <&clks MPC512x_CLK_FEC>;
> - clock-names = "per";
> + clock-names = "ipg";
> };
>
> eth0: ethernet@2800 {
> @@ -291,7 +291,7 @@
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <4 0x8>;
> clocks = <&clks MPC512x_CLK_FEC>;
> - clock-names = "per";
> + clock-names = "ipg";
> };
>
> /* USB1 using external ULPI PHY */
> --
> 1.7.10.4
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: off...@denx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] powernv:cpufreq: Implement the driver->get() method
From: "Gautham R. Shenoy"
The current frequency of a cpu is reported through the sysfs file
cpuinfo_cur_freq. This requires the driver to implement a
"->get(unsigned int cpu)" method which will return the current
operating frequency.
Implement a function named powernv_cpufreq_get() which corresponds to
the required ->get() method.
Signed-off-by: Gautham R. Shenoy
---
drivers/cpufreq/powernv-cpufreq.c | 41 +++
1 file changed, 41 insertions(+)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index f0dae6f..5f43e4f 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -218,6 +218,46 @@ static inline void set_pmspr(unsigned long sprn, unsigned
long val)
BUG();
}
+/**
+ * Computes the current frequency on this cpu
+ * and stores the result in *ret_freq.
+ */
+static void powernv_get_cpu_freq(void *ret_freq)
+{
+ unsigned long pmspr_val;
+ long pstate_id;
+ int *cur_freq, freq;
+
+ cur_freq = (int *)ret_freq;
+ pmspr_val = get_pmspr(SPRN_PMSR);
+ pstate_id = pmspr_val;
+ pstate_id = pstate_id >> 56;
+ WARN_ON(pstate_id > 0);
+ freq = pstate_id_to_freq(pstate_id);
+ pr_debug("cpu %d pmsr %lx pstate_id %ld frequency %d \n",
+ smp_processor_id(), pmspr_val, pstate_id, freq);
+ *cur_freq = freq;
+}
+
+/**
+ * Returns the cpu frequency as reported by the firmware for 'cpu'.
+ * This value is reported through the sysfs file cpuinfo_cur_freq.
+ */
+unsigned int powernv_cpufreq_get(unsigned int cpu)
+{
+ int ret_freq;
+ cpumask_var_t sibling_mask;
+
+ if (!zalloc_cpumask_var(&sibling_mask, GFP_KERNEL))
+ return -ENOMEM;
+
+ powernv_cpu_to_core_mask(cpu, sibling_mask);
+ smp_call_function_any(sibling_mask, powernv_get_cpu_freq, &ret_freq, 1);
+
+ free_cpumask_var(sibling_mask);
+ return ret_freq;
+}
+
static void set_pstate(void *pstate)
{
unsigned long val;
@@ -310,6 +350,7 @@ static int powernv_cpufreq_target(struct cpufreq_policy
*policy,
static struct cpufreq_driver powernv_cpufreq_driver = {
.verify = powernv_cpufreq_verify,
.target = powernv_cpufreq_target,
+ .get= powernv_cpufreq_get,
.init = powernv_cpufreq_cpu_init,
.exit = powernv_cpufreq_cpu_exit,
.name = "powernv-cpufreq",
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/4] powernv:cpufreq: Export nominal and current frequency via sysfs
From: "Gautham R. Shenoy" Hi, On IBM POWERNV platforms[1], presently we do not report the current operating frequency of the processor through the sysfs interface "cpuinfo_cur_freq" since the cpu frequency driver[1] has not implemented the ->get(unsigned int cpu) method. Fix this by implementing the ->get(unsigned int cpu) method which will report the frequency corresponding to the pstate_id on PMSR on "cpu". Also, export the nominal frequency of the processor through the sysfs interface "cpuinfo_nominal_freq" by defining it as a driver attribute. The patch series depends on the cpu-frequency driver patch-series[1]. [1] http://comments.gmane.org/gmane.linux.ports.ppc.embedded/67905 Thanks and Regards gautham. Summary: == Gautham R. Shenoy (4): powernv:cpufreq: Create pstate_id_to_freq() helper powernv:cpufreq: Export nominal frequency via sysfs. powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper. powernv:cpufreq: Implement the driver->get() method drivers/cpufreq/powernv-cpufreq.c | 115 -- 1 file changed, 110 insertions(+), 5 deletions(-) -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] powernv:cpufreq: Export nominal frequency via sysfs.
From: "Gautham R. Shenoy"
Create a driver attribute named cpuinfo_nominal_frequency which
creates a sysfs read-only file named cpuinfo_nominal_frequency. Export
the frequency corresponding to the nominal_pstate through this
interface.
Signed-off-by: Gautham R. Shenoy
---
drivers/cpufreq/powernv-cpufreq.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index d0a8dee..c59eb26 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -137,8 +137,30 @@ static unsigned int pstate_id_to_freq(int pstate_id)
return powernv_freqs[i].frequency;
}
+/**
+ * show_cpuinfo_nominal_freq - Show the nominal CPU frequency as indicated by
+ * the firmware
+ */
+static ssize_t show_cpuinfo_nominal_freq(struct cpufreq_policy *policy,
+ char *buf)
+{
+ int nominal_freq;
+ nominal_freq = pstate_id_to_freq(powernv_pstate_info.pstate_nominal_id);
+ return sprintf(buf, "%u\n", nominal_freq);
+}
+
+
+struct freq_attr cpufreq_freq_attr_cpuinfo_nominal_freq = {
+ .attr = { .name = "cpuinfo_nominal_freq",
+ .mode = 0444,
+ },
+ .show = show_cpuinfo_nominal_freq,
+};
+
+
static struct freq_attr *powernv_cpu_freq_attr[] = {
&cpufreq_freq_attr_scaling_available_freqs,
+ &cpufreq_freq_attr_cpuinfo_nominal_freq,
NULL,
};
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] powernv:cpufreq: Create pstate_id_to_freq() helper
From: "Gautham R. Shenoy"
Create a helper routine that can return the cpu-frequency for the
corresponding pstate_id.
Also, cache the values of the pstate_max, pstate_min and
pstate_nominal and nr_pstates in a static structure so that they can
be reused in the future to perform any validations.
Signed-off-by: Gautham R. Shenoy
---
drivers/cpufreq/powernv-cpufreq.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index 345501e..d0a8dee 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -37,6 +37,15 @@ static DEFINE_PER_CPU(struct mutex, freq_switch_lock);
#define POWERNV_MAX_PSTATES256
static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
+struct powernv_pstate_info {
+ int pstate_min_id;
+ int pstate_max_id;
+ int pstate_nominal_id;
+ int nr_pstates;
+};
+
+static struct powernv_pstate_info powernv_pstate_info;
+
/*
* Initialize the freq table based on data obtained
@@ -106,9 +115,28 @@ static int init_powernv_pstates(void)
powernv_freqs[i].driver_data = 0;
powernv_freqs[i].frequency = CPUFREQ_TABLE_END;
+ powernv_pstate_info.pstate_min_id = pstate_min;
+ powernv_pstate_info.pstate_max_id = pstate_max;
+ powernv_pstate_info.pstate_nominal_id = pstate_nominal;
+ powernv_pstate_info.nr_pstates = nr_pstates;
+
return 0;
}
+/**
+ * Returns the cpu frequency corresponding to the pstate_id.
+ */
+static unsigned int pstate_id_to_freq(int pstate_id)
+{
+ int i;
+
+ i = powernv_pstate_info.pstate_max_id - pstate_id;
+
+ BUG_ON(i >= powernv_pstate_info.nr_pstates || i < 0);
+ WARN_ON(powernv_freqs[i].driver_data != pstate_id);
+ return powernv_freqs[i].frequency;
+}
+
static struct freq_attr *powernv_cpu_freq_attr[] = {
&cpufreq_freq_attr_scaling_available_freqs,
NULL,
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4] powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper.
From: "Gautham R. Shenoy"
Move the code that computes the cpumask corresponding to the
thread-siblings of a cpu to a new method named
powernv_cpu_to_core_mask() so that it can be used by other places in
the code.
Signed-off-by: Gautham R. Shenoy
---
drivers/cpufreq/powernv-cpufreq.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index c59eb26..f0dae6f 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -166,6 +166,23 @@ static struct freq_attr *powernv_cpu_freq_attr[] = {
/* Helper routines */
+/**
+ * Sets the bits corresponding to the thread-siblings of cpu in its core
+ * in 'cpus'.
+ */
+static void powernv_cpu_to_core_mask(unsigned int cpu, cpumask_var_t cpus)
+{
+ int base, i;
+
+ base = cpu_first_thread_sibling(cpu);
+
+ for (i = 0; i < threads_per_core; i++) {
+ cpumask_set_cpu(base + i, cpus);
+ }
+
+ return;
+}
+
/* Access helpers to power mgt SPR */
static inline unsigned long get_pmspr(unsigned long sprn)
@@ -231,13 +248,10 @@ static int powernv_set_freq(cpumask_var_t cpus, unsigned
int new_index)
static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
- int base, i;
+ int i;
#ifdef CONFIG_SMP
- base = cpu_first_thread_sibling(policy->cpu);
-
- for (i = 0; i < threads_per_core; i++)
- cpumask_set_cpu(base + i, policy->cpus);
+ powernv_cpu_to_core_mask(policy->cpu, policy->cpus);
#endif
policy->cpuinfo.transition_latency = 25000;
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Sound on PowerBook and iBook (snd_powermac/snd_aoa)
Hi list,
I was hoping to pick your brains regarding the sound on Apple PowerPC machines.
For a long time now, sound has been broken on a number of these machines. This,
I think, is due to i2c changes that started in April 2012. A number of bug
reports have been raised by users at a distribution level (e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714345 ) but as of yet no
progress has been made on these.
Ubuntu has been hit by a "Fixing recursive fault, but reboot is needed!" bug
that is caused by snd_powermac (
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1066435 ). I tried the
latest daily build of Lubuntu yesterday and the problem appears to be gone, but
since the bug is a bit temperamental, I'm wondering if it was a fluke? Has any
work been done on this, and can we genuinely mark it as solved? However, I
could not get sound working on my G4 iBook.
Ubuntu (and I think Debian) add snd_powermac to /etc/modules. Is this still
necessary or does the module now auto-load? The installer has a complicated
routine (/bin/discover-mac-io) to load certain sound modules and blacklist
others. Can we remove this now?
I seem to remember reading somewhere that certain machines will be migrating
from snd_powermac to snd_aoa, although I can't seem to find the reference to
that now. If this is the case, I think a certain number of machines have
slipped through the net. As users, what information do we need to provide to
get this fixed? Attached is a patch that was sent by Stefan Gartner to the
Debian mailing list (
https://lists.debian.org/debian-powerpc/2013/09/msg00031.html ). Is this patch
okay? I'm afraid I don't know how to check the device id/codec used by my own
machine, as at a kernel level I'm a bit clueless. Would it be possible to
provide instructions on how to do this? I could then circulate the instructions
to other users who also have no sound. That way we could hopefully fix all
broken machines.
If you need any more info then I will be happy to provide it, although you may
have to give me a few days to do it (no internet connection!...)
Many thanks
Adam
--- a/sound/aoa/fabrics/layout.c2013-09-18 21:09:41.910672970 +0200
+++ b/sound/aoa/fabrics/layout.c2013-09-18 23:23:58.230511273 +0200
@@ -113,6 +113,8 @@
MODULE_ALIAS("aoa-device-id-14");
MODULE_ALIAS("aoa-device-id-22");
MODULE_ALIAS("aoa-device-id-35");
+MODULE_ALIAS("aoa-device-id-38");
+MODULE_ALIAS("aoa-device-id-40");
MODULE_ALIAS("aoa-device-id-44");
/* onyx with all but microphone connected */
@@ -362,7 +364,20 @@
.connections = tas_connections_nolineout,
},
},
+ /* PowerBook6,4 */
+ { .device_id = 40,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_all,
+ },
+ },
/* PowerBook6,5 */
+ { .device_id = 38,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_all,
+ },
+ },
{ .device_id = 44,
.codecs[0] = {
.name = "tas",
--- a/sound/aoa/soundbus/i2sbus/core.c 2013-09-18 20:24:03.962348741 +0200
+++ b/sound/aoa/soundbus/i2sbus/core.c 2013-09-18 23:34:41.934550116 +0200
@@ -201,7 +201,7 @@
* so restrict to those we do handle for now.
*/
if (id && (*id == 22 || *id == 14 || *id == 35 ||
- *id == 44)) {
+ *id == 44 || *id == 40 || *id == 38)) {
snprintf(dev->sound.modalias, 32,
"aoa-device-id-%d", *id);
ok = 1;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
