* [PATCH v2 0/3] POWER8 PMU bugfixes
From: Joel Stanley @ 2014-07-08 6:38 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev
These three patches are required for correct operation of perf counters on
POWER8 boxes when running KVM guests. There were two bugs; not clearing MMCR2
and writing over the saved value when entering a guest. However the first
obscured the second.
Thanks to who mpe helped diagnose the issue and pointed out the fix.
V2:
Add comment from mpe
Joel Stanley (3):
powerpc/kvm: Remove redundant save of SIER AND MMCR2
powerpc/perf: Add PPMU_ARCH_207S define
powerpc/perf: Clear MMCR2 when enabling PMU
arch/powerpc/include/asm/perf_event_server.h | 3 +--
arch/powerpc/kvm/book3s_hv_interrupts.S | 5 -----
arch/powerpc/perf/core-book3s.c | 9 ++++++---
arch/powerpc/perf/power8-pmu.c | 2 +-
4 files changed, 8 insertions(+), 11 deletions(-)
--
2.0.0
^ permalink raw reply
* [PATCH v2 1/3] powerpc/kvm: Remove redundant save of SIER AND MMCR2
From: Joel Stanley @ 2014-07-08 6:38 UTC (permalink / raw)
To: benh, paulus, mpe, Alexander Graf; +Cc: stable, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <1404801502-4663-1-git-send-email-joel@jms.id.au>
These two registers are already saved in the block above. Aside from
being unnecessary, by the time we get down to the second save location
r8 no longer contains MMCR2, so we are clobbering the saved value with
PMC5.
MMCR2 primarily consists of counter freeze bits. So restoring the value
of PMC5 into MMCR2 will most likely have the effect of freezing
counters.
Fixes: 72cde5a88d37 ("KVM: PPC: Book3S HV: Save/restore host PMU registers that are new in POWER8")
Cc: stable@vger.kernel.org
Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Paul Mackerras <paulus@samba.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
V2:
- Add comments from mpe
arch/powerpc/kvm/book3s_hv_interrupts.S | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_interrupts.S b/arch/powerpc/kvm/book3s_hv_interrupts.S
index 8c86422..731be74 100644
--- a/arch/powerpc/kvm/book3s_hv_interrupts.S
+++ b/arch/powerpc/kvm/book3s_hv_interrupts.S
@@ -127,11 +127,6 @@ BEGIN_FTR_SECTION
stw r10, HSTATE_PMC + 24(r13)
stw r11, HSTATE_PMC + 28(r13)
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
-BEGIN_FTR_SECTION
- mfspr r9, SPRN_SIER
- std r8, HSTATE_MMCR + 40(r13)
- std r9, HSTATE_MMCR + 48(r13)
-END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
31:
/*
--
2.0.0
^ permalink raw reply related
* [PATCH v2 2/3] powerpc/perf: Add PPMU_ARCH_207S define
From: Joel Stanley @ 2014-07-08 6:38 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, stable
In-Reply-To: <1404801502-4663-1-git-send-email-joel@jms.id.au>
Instead of separate bits for every POWER8 PMU feature, have a single one
for v2.07 of the architecture.
This saves us adding a MMCR2 define for a future patch.
Cc: stable@vger.kernel.org
Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/perf_event_server.h | 3 +--
arch/powerpc/perf/core-book3s.c | 6 +++---
arch/powerpc/perf/power8-pmu.c | 2 +-
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index 9ed73714..b3e9360 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -61,8 +61,7 @@ struct power_pmu {
#define PPMU_SIAR_VALID 0x00000010 /* Processor has SIAR Valid bit */
#define PPMU_HAS_SSLOT 0x00000020 /* Has sampled slot in MMCRA */
#define PPMU_HAS_SIER 0x00000040 /* Has SIER */
-#define PPMU_BHRB 0x00000080 /* has BHRB feature enabled */
-#define PPMU_EBB 0x00000100 /* supports event based branch */
+#define PPMU_ARCH_207S 0x00000080 /* PMC is architecture v2.07S */
/*
* Values for flags to get_alternatives()
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 4520c93..a2ff1bd 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -485,7 +485,7 @@ static bool is_ebb_event(struct perf_event *event)
* check that the PMU supports EBB, meaning those that don't can still
* use bit 63 of the event code for something else if they wish.
*/
- return (ppmu->flags & PPMU_EBB) &&
+ return (ppmu->flags & PPMU_ARCH_207S) &&
((event->attr.config >> PERF_EVENT_CONFIG_EBB_SHIFT) & 1);
}
@@ -777,7 +777,7 @@ void perf_event_print_debug(void)
if (ppmu->flags & PPMU_HAS_SIER)
sier = mfspr(SPRN_SIER);
- if (ppmu->flags & PPMU_EBB) {
+ if (ppmu->flags & PPMU_ARCH_207S) {
pr_info("MMCR2: %016lx EBBHR: %016lx\n",
mfspr(SPRN_MMCR2), mfspr(SPRN_EBBHR));
pr_info("EBBRR: %016lx BESCR: %016lx\n",
@@ -1696,7 +1696,7 @@ static int power_pmu_event_init(struct perf_event *event)
if (has_branch_stack(event)) {
/* PMU has BHRB enabled */
- if (!(ppmu->flags & PPMU_BHRB))
+ if (!(ppmu->flags & PPMU_ARCH_207S))
return -EOPNOTSUPP;
}
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index fe2763b..639cd91 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -792,7 +792,7 @@ static struct power_pmu power8_pmu = {
.get_constraint = power8_get_constraint,
.get_alternatives = power8_get_alternatives,
.disable_pmc = power8_disable_pmc,
- .flags = PPMU_HAS_SSLOT | PPMU_HAS_SIER | PPMU_BHRB | PPMU_EBB,
+ .flags = PPMU_HAS_SSLOT | PPMU_HAS_SIER | PPMU_ARCH_207S,
.n_generic = ARRAY_SIZE(power8_generic_events),
.generic_events = power8_generic_events,
.cache_events = &power8_cache_events,
--
2.0.0
^ permalink raw reply related
* [PATCH v2 3/3] powerpc/perf: Clear MMCR2 when enabling PMU
From: Joel Stanley @ 2014-07-08 6:38 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, stable
In-Reply-To: <1404801502-4663-1-git-send-email-joel@jms.id.au>
On POWER8 when switching to a KVM guest we set bits in MMCR2 to freeze
the PMU counters. Aside from on boot they are then never reset,
resulting in stuck perf counters for any user in the guest or host.
We now set MMCR2 to 0 whenever enabling the PMU, which provides a sane
state for perf to use the PMU counters under either the guest or the
host.
This was manifesting as a bug with ppc64_cpu --frequency:
$ sudo ppc64_cpu --frequency
WARNING: couldn't run on cpu 0
WARNING: couldn't run on cpu 8
...
WARNING: couldn't run on cpu 144
WARNING: couldn't run on cpu 152
min: 18446744073.710 GHz (cpu -1)
max: 0.000 GHz (cpu -1)
avg: 0.000 GHz
The command uses a perf counter to measure CPU cycles over a fixed
amount of time, in order to approximate the frequency of the machine.
The counters were returning zero once a guest was started, regardless of
weather it was still running or had been shut down.
By dumping the value of MMCR2, it was observed that once a guest is
running MMCR2 is set to 1s - which stops counters from running:
$ sudo sh -c 'echo p > /proc/sysrq-trigger'
CPU: 0 PMU registers, ppmu = POWER8 n_counters = 6
PMC1: 5b635e38 PMC2: 00000000 PMC3: 00000000 PMC4: 00000000
PMC5: 1bf5a646 PMC6: 5793d378 PMC7: deadbeef PMC8: deadbeef
MMCR0: 0000000080000000 MMCR1: 000000001e000000 MMCRA: 0000040000000000
MMCR2: fffffffffffffc00 EBBHR: 0000000000000000
EBBRR: 0000000000000000 BESCR: 0000000000000000
SIAR: 00000000000a51cc SDAR: c00000000fc40000 SIER: 0000000001000000
This is done unconditionally in book3s_hv_interrupts.S upon entering the
guest, and the original value is only save/restored if the host has
indicated it was using the PMU. This is okay, however the user of the
PMU needs to ensure that it is in a defined state when it starts using
it.
Fixes: e05b9b9e5c10 ("powerpc/perf: Power8 PMU support")
Cc: stable@vger.kernel.org
Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/perf/core-book3s.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index a2ff1bd..bae697c 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1300,6 +1300,9 @@ static void power_pmu_enable(struct pmu *pmu)
write_mmcr0(cpuhw, mmcr0);
+ if (ppmu->flags & PPMU_ARCH_207S)
+ mtspr(SPRN_MMCR2, 0);
+
/*
* Enable instruction sampling if necessary
*/
--
2.0.0
^ permalink raw reply related
* RE: [PATCH] of: Add vendor prefix for EON Corporation
From: Shengzhou.Liu @ 2014-07-08 7:04 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1404759301.21434.145.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSnVseSAwOCwgMjAxNCAyOjU1IEFNDQo+IFRvOiBMaXUgU2hl
bmd6aG91LUIzNjY4NQ0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3Vi
amVjdDogUmU6IFtQQVRDSF0gb2Y6IEFkZCB2ZW5kb3IgcHJlZml4IGZvciBFT04gQ29ycG9yYXRp
b24NCj4gDQo+IE9uIE1vbiwgMjAxNC0wNy0wNyBhdCAxNzoyOSArMDgwMCwgU2hlbmd6aG91IExp
dSB3cm90ZToNCj4gPiBTaWduZWQtb2ZmLWJ5OiBTaGVuZ3pob3UgTGl1IDxTaGVuZ3pob3UuTGl1
QGZyZWVzY2FsZS5jb20+DQo+ID4gLS0tDQo+ID4gIERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9i
aW5kaW5ncy92ZW5kb3ItcHJlZml4ZXMudHh0IHwgMSArDQo+ID4gIDEgZmlsZSBjaGFuZ2VkLCAx
IGluc2VydGlvbigrKQ0KPiANCj4gQWdhaW4sIHBsZWFzZSBDQyBhbGwgcmVsZXZhbnQgbWFpbGlu
ZyBsaXN0cy4gIFdoZXJlIGlzIHRoZSBkZXZpY2V0cmVlDQo+IGxpc3Q/ICBBbmQgbWVudGlvbiB3
aHkgdGhpcyBwYXRjaCBpcyByZWxldmFudCB0byBQUEMuDQo+IA0KPiAtU2NvdHQNCltTaGVuZ3po
b3VdIEkgZGlkbid0IGZpbmQgYW55IHJlbGV2YW50IGxpc3QgZm9yIGRldmljZXRyZWUgaW4gdGhl
IE1BSU5UQUlORVJTLCBzbyBzZW50IGl0IGhlcmUgdG8gd2FpdCBmb3Igc29tZW9uZSBwb2ludCB0
byB0aGUgcHJvcGVyIGxpc3QuDQo+IA0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL0RvY3VtZW50YXRp
b24vZGV2aWNldHJlZS9iaW5kaW5ncy92ZW5kb3ItcHJlZml4ZXMudHh0DQo+ID4gYi9Eb2N1bWVu
dGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdmVuZG9yLXByZWZpeGVzLnR4dA0KPiA+IGluZGV4
IDFhNjc5M2IuLjNjMTBhMjEgMTAwNjQ0DQo+ID4gLS0tIGEvRG9jdW1lbnRhdGlvbi9kZXZpY2V0
cmVlL2JpbmRpbmdzL3ZlbmRvci1wcmVmaXhlcy50eHQNCj4gPiArKysgYi9Eb2N1bWVudGF0aW9u
L2RldmljZXRyZWUvYmluZGluZ3MvdmVuZG9yLXByZWZpeGVzLnR4dA0KPiA+IEBAIC00Miw2ICs0
Miw3IEBAIGVidglFQlYgRWxla3Ryb25paw0KPiA+ICBlZHQJRW1lcmdpbmcgRGlzcGxheSBUZWNo
bm9sb2dpZXMNCj4gPiAgZW1taWNybwlFTSBNaWNyb2VsZWN0cm9uaWMNCj4gPiAgZXBmbAlFY29s
ZSBQb2x5dGVjaG5pcXVlIEbDqWTDqXJhbGUgZGUgTGF1c2FubmUNCj4gPiArZW9uCUVvbiBTaWxp
Y29uIFNvbHV0aW9uLCBJbmMuDQo+ID4gIGVwc29uCVNlaWtvIEVwc29uIENvcnAuDQo+ID4gIGVz
dAlFU1RlZW0gV2lyZWxlc3MgTW9kZW1zDQo+ID4gIGV1a3JlYSAgRXVrcsOpYSBFbGVjdHJvbWF0
aXF1ZQ0KPiANCg0K
^ permalink raw reply
* RE: [PATCH] of: Add vendor prefix for EON Corporation
From: Shengzhou.Liu @ 2014-07-08 7:10 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1404759301.21434.145.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGl1IFNoZW5nemhvdS1C
MzY2ODUNCj4gU2VudDogVHVlc2RheSwgSnVseSAwOCwgMjAxNCAzOjA1IFBNDQo+IFRvOiBXb29k
IFNjb3R0LUIwNzQyMQ0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3Vi
amVjdDogUkU6IFtQQVRDSF0gb2Y6IEFkZCB2ZW5kb3IgcHJlZml4IGZvciBFT04gQ29ycG9yYXRp
b24NCj4gDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206
IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gU2VudDogVHVlc2RheSwgSnVseSAwOCwgMjAxNCAyOjU1
IEFNDQo+ID4gVG86IExpdSBTaGVuZ3pob3UtQjM2Njg1DQo+ID4gQ2M6IGxpbnV4cHBjLWRldkBs
aXN0cy5vemxhYnMub3JnDQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSF0gb2Y6IEFkZCB2ZW5kb3Ig
cHJlZml4IGZvciBFT04gQ29ycG9yYXRpb24NCj4gPg0KPiA+IE9uIE1vbiwgMjAxNC0wNy0wNyBh
dCAxNzoyOSArMDgwMCwgU2hlbmd6aG91IExpdSB3cm90ZToNCj4gPiA+IFNpZ25lZC1vZmYtYnk6
IFNoZW5nemhvdSBMaXUgPFNoZW5nemhvdS5MaXVAZnJlZXNjYWxlLmNvbT4NCj4gPiA+IC0tLQ0K
PiA+ID4gIERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy92ZW5kb3ItcHJlZml4ZXMu
dHh0IHwgMSArDQo+ID4gPiAgMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspDQo+ID4NCj4g
PiBBZ2FpbiwgcGxlYXNlIENDIGFsbCByZWxldmFudCBtYWlsaW5nIGxpc3RzLiAgV2hlcmUgaXMg
dGhlIGRldmljZXRyZWUNCj4gPiBsaXN0PyAgQW5kIG1lbnRpb24gd2h5IHRoaXMgcGF0Y2ggaXMg
cmVsZXZhbnQgdG8gUFBDLg0KPiA+DQo+ID4gLVNjb3R0DQo+IFtTaGVuZ3pob3VdIEkgZGlkbid0
IGZpbmQgYW55IHJlbGV2YW50IGxpc3QgZm9yIGRldmljZSB0cmVlIGluIHRoZQ0KPiBNQUlOVEFJ
TkVSUywgc28gc2VudCBpdCBoZXJlIHRvIHdhaXQgZm9yIHNvbWVvbmUgcG9pbnQgdG8gdGhlIHBy
b3BlciBsaXN0Lg0KDQpbU2hlbmd6aG91XSBmb3VuZCBpdCwgd2lsbCBzZW5kIHRvIGRldmljZXRy
ZWVAdmdlci5rZXJuZWwub3JnDQo=
^ permalink raw reply
* [PATCH] powerpc: Clean up MMU_FTRS_A2 and MMU_FTR_TYPE_3E
From: Michael Ellerman @ 2014-07-08 7:10 UTC (permalink / raw)
To: linuxppc-dev
In fb5a515704d7 "powerpc: Remove platforms/wsp and associated pieces",
we removed the last user of MMU_FTRS_A2. So remove it.
MMU_FTRS_A2 was the last user of MMU_FTR_TYPE_3E, so remove it also.
This leaves some unreachable code in mmu_context_nohash.c, so remove
that also.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/mmu.h | 10 +---------
arch/powerpc/mm/mmu_context_nohash.c | 12 +-----------
2 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index f8d1d6dcf7db..e61f24ed4e65 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -19,8 +19,7 @@
#define MMU_FTR_TYPE_40x ASM_CONST(0x00000004)
#define MMU_FTR_TYPE_44x ASM_CONST(0x00000008)
#define MMU_FTR_TYPE_FSL_E ASM_CONST(0x00000010)
-#define MMU_FTR_TYPE_3E ASM_CONST(0x00000020)
-#define MMU_FTR_TYPE_47x ASM_CONST(0x00000040)
+#define MMU_FTR_TYPE_47x ASM_CONST(0x00000020)
/*
* This is individual features
@@ -106,13 +105,6 @@
MMU_FTR_CI_LARGE_PAGE
#define MMU_FTRS_PA6T MMU_FTRS_DEFAULT_HPTE_ARCH_V2 | \
MMU_FTR_CI_LARGE_PAGE | MMU_FTR_NO_SLBIE_B
-#define MMU_FTRS_A2 MMU_FTR_TYPE_3E | MMU_FTR_USE_TLBILX | \
- MMU_FTR_USE_TLBIVAX_BCAST | \
- MMU_FTR_LOCK_BCAST_INVAL | \
- MMU_FTR_USE_TLBRSRV | \
- MMU_FTR_USE_PAIRED_MAS | \
- MMU_FTR_TLBIEL | \
- MMU_FTR_16M_PAGE
#ifndef __ASSEMBLY__
#include <asm/cputable.h>
diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_context_nohash.c
index af3d78e19302..928ebe79668b 100644
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -410,17 +410,7 @@ void __init mmu_context_init(void)
} else if (mmu_has_feature(MMU_FTR_TYPE_47x)) {
first_context = 1;
last_context = 65535;
- } else
-#ifdef CONFIG_PPC_BOOK3E_MMU
- if (mmu_has_feature(MMU_FTR_TYPE_3E)) {
- u32 mmucfg = mfspr(SPRN_MMUCFG);
- u32 pid_bits = (mmucfg & MMUCFG_PIDSIZE_MASK)
- >> MMUCFG_PIDSIZE_SHIFT;
- first_context = 1;
- last_context = (1UL << (pid_bits + 1)) - 1;
- } else
-#endif
- {
+ } else {
first_context = 1;
last_context = 255;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v5] powerpc/t2080rdb: Add T2080RDB board support
From: Shengzhou Liu @ 2014-07-08 6:52 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: Shengzhou Liu
T2080PCIe-RDB is a Freescale Reference Design Board that hosts 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 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
IFC/Local Bus
- NOR: 128MB 16-bit NOR flash
- NAND: 1GB 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 goldfinger(support SR-IOV)
- One PCIe x4 slot
- One PCIe x2 end-point device (C293 crypto co-processor)
SATA:
- Two SATA 2.0 ports on-board
SDHC:
- support a MicroSD/TF card on-board
I2C:
- Four I2C controllers.
UART:
- Dual 4-pins UART serial ports
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
v5: updated i2c nodes.
v4: no change.
v3: no change.
arch/powerpc/boot/dts/t2080rdb.dts | 57 ++++++++
arch/powerpc/boot/dts/t208xrdb.dtsi | 184 ++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +
4 files changed, 244 insertions(+), 1 deletion(-)
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 0000000..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@ffe0c0000 {
+ reg = <0xf 0xfe0c0000 0 0x11000>;
+
+ port1 {
+ ranges = <0 0 0xc 0x20000000 0 0x10000000>;
+ };
+ port2 {
+ ranges = <0 0 0xc 0x30000000 0 0x10000000>;
+ };
+ };
+};
+
+/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 0000000..1481e19
--- /dev/null
+++ b/arch/powerpc/boot/dts/t208xrdb.dtsi
@@ -0,0 +1,184 @@
+/*
+ * 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.
+ */
+
+/ {
+ model = "fsl,T2080RDB";
+ compatible = "fsl,T2080RDB";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ ifc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x2000>;
+ ranges = <0 0 0xf 0xe8000000 0x08000000
+ 2 0 0xf 0xff800000 0x00010000
+ 3 0 0xf 0xffdf0000 0x00008000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x10000>;
+ };
+
+ boardctrl: board-control@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,t2080-cpld";
+ reg = <3 0 0x300>;
+ ranges = <0 3 0 0x300>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ dcsr: dcsr@f00000000 {
+ ranges = <0x00000000 0xf 0x00000000 0x01072000>;
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+ spi@110000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "micron,n25q512a";
+ reg = <0>;
+ spi-max-frequency = <10000000>; /* input clock */
+ };
+ };
+
+ i2c@118000 {
+ adt7481@4c {
+ compatible = "adi,adt7481";
+ reg = <0x4c>;
+ };
+
+ rtc@68 {
+ compatible = "dallas,ds1339";
+ reg = <0x68>;
+ interrupts = <0x1 0x1 0 0>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c256";
+ reg = <0x50>;
+ };
+ };
+
+ i2c@118100 {
+ pca9546@77 {
+ compatible = "nxp,pca9546";
+ reg = <0x77>;
+ };
+ };
+
+ sdhc@114000 {
+ voltage-ranges = <1800 1800 3300 3300>;
+ };
+ };
+
+ pci0: pcie@ffe240000 {
+ reg = <0xf 0xfe240000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci1: pcie@ffe250000 {
+ reg = <0xf 0xfe250000 0 0x10000>;
+ ranges = <0x02000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci2: pcie@ffe260000 {
+ reg = <0xf 0xfe260000 0 0x1000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x30000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci3: pcie@ffe270000 {
+ reg = <0xf 0xfe270000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x40000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8030000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 436fdb6..5fa106a 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -274,7 +274,7 @@ config CORENET_GENERIC
For 32bit kernel, the following boards are supported:
P2041 RDB, P3041 DS, P4080 DS, kmcoge4, and OCA4080
For 64bit kernel, the following boards are supported:
- T208x QDS, T4240 QDS and B4 QDS
+ T208x QDS/RDB, T4240 QDS and B4 QDS
The following boards are supported for both 32bit and 64bit kernel:
P5020 DS, P5040 DS and T104xQDS
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index de66b7c..d464c99 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -120,6 +120,7 @@ static const char * const boards[] __initconst = {
"fsl,P5020DS",
"fsl,P5040DS",
"fsl,T2080QDS",
+ "fsl,T2080RDB",
"fsl,T2081QDS",
"fsl,T4240QDS",
"fsl,B4860QDS",
@@ -139,6 +140,7 @@ static const char * const hv_boards[] __initconst = {
"fsl,P5020DS-hv",
"fsl,P5040DS-hv",
"fsl,T2080QDS-hv",
+ "fsl,T2080RDB-hv",
"fsl,T2081QDS-hv",
"fsl,T4240QDS-hv",
"fsl,B4860QDS-hv",
--
1.8.0
^ permalink raw reply related
* Re: Build regressions/improvements in v3.16-rc4
From: Geert Uytterhoeven @ 2014-07-08 8:03 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: linuxppc-dev@lists.ozlabs.org, Linux-sh list
In-Reply-To: <1404806449-30974-1-git-send-email-geert@linux-m68k.org>
On Tue, Jul 8, 2014 at 10:00 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.16-rc4[1] to v3.16-rc3[3], the summaries are:
> - build errors: +7/-2
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_HIGH_MASK' undeclared (first use in this function): => 98:12
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_HIGH_SHIFT' undeclared (first use in this function): =>
145:10, 98:34
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_LOW_MASK' undeclared (first use in this function): => 97:21
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_LOW_SHIFT' undeclared (first use in this function): =>
97:42, 145:10
+ /scratch/kisskb/src/arch/sh/mm/cache-sh4.c: error:
'cached_to_uncached' undeclared (first use in this function): =>
99:17
+ /scratch/kisskb/src/arch/sh/mm/cache-sh4.c: error: implicit
declaration of function 'cpu_context'
[-Werror=implicit-function-declaration]: => 192:2
sh-randconfig
+ /scratch/kisskb/src/scripts/mod/devicetable-offsets.c: error:
-mcall-aixdesc must be big endian: => 1:0
powerpc-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/7639/ (all 119 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/7619/ (all 119 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()
From: David Laight @ 2014-07-08 8:33 UTC (permalink / raw)
To: 'Bjorn Helgaas', Alexander Gordeev
Cc: linux-mips@linux-mips.org, linux-s390@vger.kernel.org,
linux-doc@vger.kernel.org, linux-pci@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org, iommu@lists.linux-foundation.org,
xen-devel@lists.xenproject.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAErSpo7QWc35seoMhJA+H1_=MkKWYMdeYG=hT=i1v=iz8d5ezA@mail.gmail.com>
RnJvbTogQmpvcm4gSGVsZ2Fhcw0KLi4uDQo+ID4+IEV2ZW4gaWYgeW91IGRvIHRoYXQsIHlvdSBv
dWdodCB0byB3cml0ZSB2YWxpZCBpbnRlcnJ1cHQgaW5mb3JtYXRpb24NCj4gPj4gaW50byB0aGUg
NHRoIHNsb3QgKG1heWJlIHJlcGxpY2F0aW5nIG9uZSBvZiB0aGUgZWFybGllciBpbnRlcnJ1cHRz
KS4NCj4gPj4gVGhlbiwgaWYgdGhlIGRldmljZSBkb2VzIHJhaXNlIHRoZSAndW5leHBlY3RlZCcg
aW50ZXJydXB0IHlvdSBkb24ndA0KPiA+PiBnZXQgYSB3cml0ZSB0byBhIHJhbmRvbSBrZXJuZWwg
bG9jYXRpb24uDQo+ID4NCj4gPiBJIG1pZ2h0IGJlIG1pc3Npbmcgc29tZXRoaW5nLCBidXQgd2Ug
YXJlIHRhbGtpbmcgb2YgTVNJIGFkZHJlc3Mgc3BhY2UNCj4gPiBoZXJlLCBhcmVuJ3Qgd2U/IEkg
YW0gbm90IGdldHRpbmcgaG93IHdlIGNvdWxkIGVuZCB1cCB3aXRoIGEgJ3dyaXRlJw0KPiA+IHRv
IGEgcmFuZG9tIGtlcm5lbCBsb2NhdGlvbiB3aGVuIGEgdW5jbGFpbWVkIE1TSSB2ZWN0b3Igc2Vu
dC4gV2UgY291bGQNCj4gPiBvbmx5IGV4cGVjdCBhIHNwdXJpb3VzIGludGVycnVwdCBhdCB3b3Jz
dCwgd2hpY2ggaXMgaGFuZGxlZCBhbmQgcmVwb3J0ZWQuDQo+IA0KPiBZZXMsIHRoYXQncyBob3cg
SSB1bmRlcnN0YW5kIGl0LiAgV2l0aCBNU0ksIHRoZSBPUyBzcGVjaWZpZXMgdGhlIGENCj4gc2lu
Z2xlIE1lc3NhZ2UgQWRkcmVzcywgZS5nLiwgYSBMQVBJQyBhZGRyZXNzLCBhbmQgYSBzaW5nbGUg
TWVzc2FnZQ0KPiBEYXRhIHZhbHVlLCBlLmcuLCBhIHZlY3RvciBudW1iZXIgdGhhdCB3aWxsIGJl
IHdyaXR0ZW4gdG8gdGhlIExBUElDLg0KPiBUaGUgZGV2aWNlIGlzIHBlcm1pdHRlZCB0byBtb2Rp
Znkgc29tZSBsb3ctb3JkZXIgYml0cyBvZiB0aGUgTWVzc2FnZQ0KPiBEYXRhIHRvIHNlbmQgb25l
IG9mIHNldmVyYWwgdmVjdG9yIG51bWJlcnMgKHRoZSBNTUUgdmFsdWUgdGVsbHMgdGhlDQo+IGRl
dmljZSBob3cgbWFueSBiaXRzIGl0IGNhbiBtb2RpZnkpLg0KPiANCj4gQm90dG9tIGxpbmUsIEkg
dGhpbmsgYSBzcHVyaW91cyBpbnRlcnJ1cHQgaXMgdGhlIGZhaWx1cmUgd2UnZCBleHBlY3QNCj4g
aWYgYSBkZXZpY2UgdXNlZCBtb3JlIHZlY3RvcnMgdGhhbiB0aGUgT1MgZXhwZWN0cyBpdCB0by4N
Cg0KU28geW91IG5lZWQgdG8gdGVsbCB0aGUgZGV2aWNlIHdoZXJlIHRvIHdyaXRlIGluIG9yZGVy
IHRvIHJhaXNlIHRoZQ0KJ3NwdXJpb3VzIGludGVycnVwdCcuDQoNCglEYXZpZA0KDQo=
^ permalink raw reply
* [PATCH v5] powerpc/powernv: hwmon driver for power, fan rpm, voltage and temperature
From: Neelesh Gupta @ 2014-07-08 9:08 UTC (permalink / raw)
To: devicetree, linuxppc-dev, lm-sensors; +Cc: sbhat, linux, jdelvare
This patch adds basic kernel support for reading power values, fan
speed rpm, voltage and temperature data on powernv platforms which
will be exported to user space through sysfs interface.
Test results:
-------------
[root@tul163p1 ~]# sensors
ibmpowernv-isa-0000
Adapter: ISA adapter
fan1: 5465 RPM (min = 0 RPM)
fan2: 5152 RPM (min = 0 RPM)
fan3: 5521 RPM (min = 0 RPM)
fan4: 4891 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
fan6: 0 RPM (min = 0 RPM)
fan7: 7480 RPM (min = 0 RPM)
fan8: 7944 RPM (min = 0 RPM)
temp1: +39.0°C (high = +0.0°C)
power1: 190.00 W
[root@tul163p1 ~]# ls /sys/devices/platform/
alarmtimer ibmpowernv.0 power rtc-generic serial8250 uevent
[root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/hwmon/hwmon0/
device fan2_min fan4_min fan6_min fan8_min power
fan1_fault fan3_fault fan5_fault fan7_fault in1_fault power1_input
fan1_input fan3_input fan5_input fan7_input in2_fault subsystem
fan1_min fan3_min fan5_min fan7_min in3_fault temp1_input
fan2_fault fan4_fault fan6_fault fan8_fault in4_fault temp1_max
fan2_input fan4_input fan6_input fan8_input name uevent
[root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/
device fan2_min fan4_min fan6_min fan8_min power
fan1_fault fan3_fault fan5_fault fan7_fault in1_fault power1_input
fan1_input fan3_input fan5_input fan7_input in2_fault subsystem
fan1_min fan3_min fan5_min fan7_min in3_fault temp1_input
fan2_fault fan4_fault fan6_fault fan8_fault in4_fault temp1_max
fan2_input fan4_input fan6_input fan8_input name uevent
[root@tul163p1 ~]#
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
---
Changes in v5
=============
- Addressed couple minor comments in v4.
Changes in v4
=============
- Replaced pr_err() with dev_err() for logging print messages.
- Using kstrtou32() function for converting string to u32 instead of sscanf().
Changes in v3
=============
- Fixed an endianness bug leading the driver to break on LE.
- Fixed a bug that when one of the 'attribute_group' not populated, following
groups attributes were dropped.
- Rewrite the get_sensor_index_attr() function to handle all the error scenarios
like 'sscanf' etc.
- Fixed all the errors/warnings related to coding style/whitespace.
- Added 'Documentation' files.
- Addressed remaining review comments on V2.
Changes in v2
=============
- Generic use of devm_* functions in hwmon like using devm_kzalloc() for dynamic
memory request, avoiding the need to explicit free of memory.
Adding 'struct attribute_group' as member of platform data structure to be
populated and then passed to devm_hwmon_device_register_with_groups().
Note: Having an array of pointers of 'attribute_group' and each group
corresponds to 'enum sensors' type. Not completely sure, if it's ideal or
could have just one group populated with attributes of sensor types?
- 'ibmpowernv' is not hot-pluggable device so moving 'platform_driver' callback
function (probe) as part of __init code.
- Fixed issues related to coding style.
- Other general comments in v1.
.../devicetree/bindings/hwmon/ibmpowernv.txt | 23 +
Documentation/hwmon/ibmpowernv | 41 ++
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1
drivers/hwmon/ibmpowernv.c | 364 ++++++++++++++++++++
5 files changed, 440 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
create mode 100644 Documentation/hwmon/ibmpowernv
create mode 100644 drivers/hwmon/ibmpowernv.c
diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
new file mode 100644
index 0000000..f93242b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
@@ -0,0 +1,23 @@
+IBM POWERNV platform sensors
+----------------------------
+
+Required node properties:
+- compatible: must be one of
+ "ibm,opal-sensor-cooling-fan"
+ "ibm,opal-sensor-amb-temp"
+ "ibm,opal-sensor-power-supply"
+ "ibm,opal-sensor-power"
+- sensor-id: an opaque id provided by the firmware to the kernel, identifies a
+ given sensor and its attribute data
+
+Example sensors node:
+
+cooling-fan#8-data {
+ sensor-id = <0x7052107>;
+ compatible = "ibm,opal-sensor-cooling-fan";
+};
+
+amb-temp#1-thrs {
+ sensor-id = <0x5096000>;
+ compatible = "ibm,opal-sensor-amb-temp";
+};
diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv
new file mode 100644
index 0000000..644245a
--- /dev/null
+++ b/Documentation/hwmon/ibmpowernv
@@ -0,0 +1,41 @@
+Kernel Driver IBMPOWENV
+=======================
+
+Supported systems:
+ * Any recent IBM P servers based on POWERNV platform
+
+Author: Neelesh Gupta
+
+Description
+-----------
+
+This driver implements reading the platform sensors data like temperature/fan/
+voltage/power for 'POWERNV' platform.
+
+The driver uses the platform device infrastructure. It probes the device tree
+for sensor devices during the __init phase and registers them with the 'hwmon'.
+'hwmon' populates the 'sysfs' tree having attribute files, each for a given
+sensor type and its attribute data.
+
+All the nodes in the DT appear under "/ibm,opal/sensors" and each valid node in
+the DT maps to an attribute file in 'sysfs'. The node exports unique 'sensor-id'
+which the driver uses to make an OPAL call to the firmware.
+
+Usage notes
+-----------
+The driver is built statically with the kernel by enabling the config
+CONFIG_SENSORS_IBMPOWERNV. It can also be built as module 'ibmpowernv'.
+
+Sysfs attributes
+----------------
+
+fanX_input Measured RPM value.
+fanX_min Threshold RPM for alert generation.
+fanX_fault 0: No fail condition
+ 1: Failing fan
+tempX_input Measured ambient temperature.
+tempX_max Threshold ambient temperature for alert generation.
+inX_input Measured power supply voltage
+inX_fault 0: No fail condition.
+ 1: Failing power supply.
+power1_input System power consumption (microWatt)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 02d3d85..29c3fcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -554,6 +554,17 @@ config SENSORS_IBMPEX
This driver can also be built as a module. If so, the module
will be called ibmpex.
+config SENSORS_IBMPOWERNV
+ tristate "IBM POWERNV platform sensors"
+ depends on PPC_POWERNV
+ default y
+ help
+ If you say yes here you get support for the temperature/fan/power
+ sensors on your PowerNV platform.
+
+ This driver can also be built as a module. If so, the module
+ will be called ibmpowernv.
+
config SENSORS_IIO_HWMON
tristate "Hwmon driver that uses channels specified via iio maps"
depends on IIO
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 3dc0f02..fc4ed26 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_SENSORS_ULTRA45) += ultra45_env.o
obj-$(CONFIG_SENSORS_I5K_AMB) += i5k_amb.o
obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
+obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
obj-$(CONFIG_SENSORS_INA209) += ina209.o
obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o
diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
new file mode 100644
index 0000000..e6b652a
--- /dev/null
+++ b/drivers/hwmon/ibmpowernv.c
@@ -0,0 +1,364 @@
+/*
+ * IBM PowerNV platform sensors for temperature/fan/voltage/power
+ * Copyright (C) 2014 IBM
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ */
+
+#define DRVNAME "ibmpowernv"
+#define pr_fmt(fmt) DRVNAME ": " fmt
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+#include <linux/platform_device.h>
+#include <asm/opal.h>
+#include <linux/err.h>
+
+#define MAX_ATTR_LEN 32
+
+/* Sensor suffix name from DT */
+#define DT_FAULT_ATTR_SUFFIX "faulted"
+#define DT_DATA_ATTR_SUFFIX "data"
+#define DT_THRESHOLD_ATTR_SUFFIX "thrs"
+
+/*
+ * Enumerates all the types of sensors in the POWERNV platform and does index
+ * into 'struct sensor_group'
+ */
+enum sensors {
+ FAN,
+ AMBIENT_TEMP,
+ POWER_SUPPLY,
+ POWER_INPUT,
+ MAX_SENSOR_TYPE,
+};
+
+static struct sensor_group {
+ const char *name;
+ const char *compatible;
+ struct attribute_group group;
+ u32 attr_count;
+} sensor_groups[] = {
+ {"fan", "ibm,opal-sensor-cooling-fan"},
+ {"temp", "ibm,opal-sensor-amb-temp"},
+ {"in", "ibm,opal-sensor-power-supply"},
+ {"power", "ibm,opal-sensor-power"}
+};
+
+struct sensor_data {
+ u32 id; /* An opaque id of the firmware for each sensor */
+ enum sensors type;
+ char name[MAX_ATTR_LEN];
+ struct device_attribute dev_attr;
+};
+
+struct platform_data {
+ const struct attribute_group *attr_groups[MAX_SENSOR_TYPE + 1];
+ u32 sensors_count; /* Total count of sensors from each group */
+};
+
+/* Platform device representing all the ibmpowernv sensors */
+static struct platform_device *pdevice;
+
+static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ struct sensor_data *sdata = container_of(devattr, struct sensor_data,
+ dev_attr);
+ ssize_t ret;
+ u32 x;
+
+ ret = opal_get_sensor_data(sdata->id, &x);
+ if (ret)
+ return ret;
+
+ /* Convert temperature to milli-degrees */
+ if (sdata->type == AMBIENT_TEMP)
+ x *= 1000;
+ /* Convert power to micro-watts */
+ else if (sdata->type == POWER_INPUT)
+ x *= 1000000;
+
+ return sprintf(buf, "%u\n", x);
+}
+
+static int __init get_sensor_index_attr(const char *name, u32 *index,
+ char *attr)
+{
+ char *hash_pos = strchr(name, '#');
+ char buf[8] = { 0 };
+ char *dash_pos;
+ u32 copy_len;
+ int err;
+
+ if (!hash_pos)
+ return -EINVAL;
+
+ dash_pos = strchr(hash_pos, '-');
+ if (!dash_pos)
+ return -EINVAL;
+
+ copy_len = dash_pos - hash_pos - 1;
+ if (copy_len >= sizeof(buf))
+ return -EINVAL;
+
+ strncpy(buf, hash_pos + 1, copy_len);
+
+ err = kstrtou32(buf, 10, index);
+ if (err)
+ return err;
+
+ strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
+
+ return 0;
+}
+
+/*
+ * This function translates the DT node name into the 'hwmon' attribute name.
+ * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
+ * which need to be mapped as fan2_input, temp1_max respectively before
+ * populating them inside hwmon device class.
+ */
+static int __init create_hwmon_attr_name(struct device *dev, enum sensors type,
+ const char *node_name,
+ char *hwmon_attr_name)
+{
+ char attr_suffix[MAX_ATTR_LEN];
+ char *attr_name;
+ u32 index;
+ int err;
+
+ err = get_sensor_index_attr(node_name, &index, attr_suffix);
+ if (err) {
+ dev_err(dev, "Sensor device node name '%s' is invalid\n",
+ node_name);
+ return err;
+ }
+
+ if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX)) {
+ attr_name = "fault";
+ } else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
+ attr_name = "input";
+ } else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
+ if (type == AMBIENT_TEMP)
+ attr_name = "max";
+ else if (type == FAN)
+ attr_name = "min";
+ else
+ return -ENOENT;
+ } else {
+ return -ENOENT;
+ }
+
+ snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
+ sensor_groups[type].name, index, attr_name);
+ return 0;
+}
+
+static int __init populate_attr_groups(struct platform_device *pdev)
+{
+ struct platform_data *pdata = platform_get_drvdata(pdev);
+ const struct attribute_group **pgroups = pdata->attr_groups;
+ struct device_node *opal, *np;
+ enum sensors type;
+
+ opal = of_find_node_by_path("/ibm,opal/sensors");
+ if (!opal) {
+ dev_err(&pdev->dev, "Opal node 'sensors' not found\n");
+ return -ENODEV;
+ }
+
+ for_each_child_of_node(opal, np) {
+ if (np->name == NULL)
+ continue;
+
+ for (type = 0; type < MAX_SENSOR_TYPE; type++)
+ if (of_device_is_compatible(np,
+ sensor_groups[type].compatible)) {
+ sensor_groups[type].attr_count++;
+ break;
+ }
+ }
+
+ of_node_put(opal);
+
+ for (type = 0; type < MAX_SENSOR_TYPE; type++) {
+ sensor_groups[type].group.attrs = devm_kzalloc(&pdev->dev,
+ sizeof(struct attribute *) *
+ (sensor_groups[type].attr_count + 1),
+ GFP_KERNEL);
+ if (!sensor_groups[type].group.attrs)
+ return -ENOMEM;
+
+ pgroups[type] = &sensor_groups[type].group;
+ pdata->sensors_count += sensor_groups[type].attr_count;
+ sensor_groups[type].attr_count = 0;
+ }
+
+ return 0;
+}
+
+/*
+ * Iterate through the device tree for each child of 'sensors' node, create
+ * a sysfs attribute file, the file is named by translating the DT node name
+ * to the name required by the higher 'hwmon' driver like fan1_input, temp1_max
+ * etc..
+ */
+static int __init create_device_attrs(struct platform_device *pdev)
+{
+ struct platform_data *pdata = platform_get_drvdata(pdev);
+ const struct attribute_group **pgroups = pdata->attr_groups;
+ struct device_node *opal, *np;
+ struct sensor_data *sdata;
+ const __be32 *sensor_id;
+ enum sensors type;
+ u32 count = 0;
+ int err = 0;
+
+ opal = of_find_node_by_path("/ibm,opal/sensors");
+ sdata = devm_kzalloc(&pdev->dev, pdata->sensors_count * sizeof(*sdata),
+ GFP_KERNEL);
+ if (!sdata) {
+ err = -ENOMEM;
+ goto exit_put_node;
+ }
+
+ for_each_child_of_node(opal, np) {
+ if (np->name == NULL)
+ continue;
+
+ for (type = 0; type < MAX_SENSOR_TYPE; type++)
+ if (of_device_is_compatible(np,
+ sensor_groups[type].compatible))
+ break;
+
+ if (type == MAX_SENSOR_TYPE)
+ continue;
+
+ sensor_id = of_get_property(np, "sensor-id", NULL);
+ if (!sensor_id) {
+ dev_info(&pdev->dev,
+ "'sensor-id' missing in the node '%s'\n",
+ np->name);
+ continue;
+ }
+
+ sdata[count].id = be32_to_cpup(sensor_id);
+ sdata[count].type = type;
+ err = create_hwmon_attr_name(&pdev->dev, type, np->name,
+ sdata[count].name);
+ if (err)
+ goto exit_put_node;
+
+ sysfs_attr_init(&sdata[count].dev_attr.attr);
+ sdata[count].dev_attr.attr.name = sdata[count].name;
+ sdata[count].dev_attr.attr.mode = S_IRUGO;
+ sdata[count].dev_attr.show = show_sensor;
+
+ pgroups[type]->attrs[sensor_groups[type].attr_count++] =
+ &sdata[count++].dev_attr.attr;
+ }
+
+exit_put_node:
+ of_node_put(opal);
+ return err;
+}
+
+static int __init ibmpowernv_probe(struct platform_device *pdev)
+{
+ struct platform_data *pdata;
+ struct device *hwmon_dev;
+ int err;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, pdata);
+ pdata->sensors_count = 0;
+ err = populate_attr_groups(pdev);
+ if (err)
+ return err;
+
+ /* Create sysfs attribute data for each sensor found in the DT */
+ err = create_device_attrs(pdev);
+ if (err)
+ return err;
+
+ /* Finally, register with hwmon */
+ hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev, DRVNAME,
+ pdata,
+ pdata->attr_groups);
+
+ return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+static struct platform_driver ibmpowernv_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRVNAME,
+ },
+};
+
+static int __init ibmpowernv_init(void)
+{
+ int err;
+
+ pdevice = platform_device_alloc(DRVNAME, 0);
+ if (!pdevice) {
+ pr_err("Device allocation failed\n");
+ err = -ENOMEM;
+ goto exit;
+ }
+
+ err = platform_device_add(pdevice);
+ if (err) {
+ pr_err("Device addition failed (%d)\n", err);
+ goto exit_device_put;
+ }
+
+ err = platform_driver_probe(&ibmpowernv_driver, ibmpowernv_probe);
+ if (err) {
+ pr_err("Platfrom driver probe failed\n");
+ goto exit_device_del;
+ }
+
+ return 0;
+
+exit_device_del:
+ platform_device_del(pdevice);
+exit_device_put:
+ platform_device_put(pdevice);
+exit:
+ return err;
+}
+
+static void __exit ibmpowernv_exit(void)
+{
+ platform_driver_unregister(&ibmpowernv_driver);
+ platform_device_unregister(pdevice);
+}
+
+MODULE_AUTHOR("Neelesh Gupta <neelegup@linux.vnet.ibm.com>");
+MODULE_DESCRIPTION("IBM POWERNV platform sensors");
+MODULE_LICENSE("GPL");
+
+module_init(ibmpowernv_init);
+module_exit(ibmpowernv_exit);
^ permalink raw reply related
* Re: [PATCH v2] Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8
From: Alexander Graf @ 2014-07-08 10:41 UTC (permalink / raw)
To: Stewart Smith, linuxppc-dev, paulus, kvm-ppc
In-Reply-To: <1404795988-9892-1-git-send-email-stewart@linux.vnet.ibm.com>
On 08.07.14 07:06, Stewart Smith wrote:
> The POWER8 processor has a Micro Partition Prefetch Engine, which is
> a fancy way of saying "has way to store and load contents of L2 or
> L2+MRU way of L3 cache". We initiate the storing of the log (list of
> addresses) using the logmpp instruction and start restore by writing
> to a SPR.
>
> The logmpp instruction takes parameters in a single 64bit register:
> - starting address of the table to store log of L2/L2+L3 cache contents
> - 32kb for L2
> - 128kb for L2+L3
> - Aligned relative to maximum size of the table (32kb or 128kb)
> - Log control (no-op, L2 only, L2 and L3, abort logout)
>
> We should abort any ongoing logging before initiating one.
>
> To initiate restore, we write to the MPPR SPR. The format of what to write
> to the SPR is similar to the logmpp instruction parameter:
> - starting address of the table to read from (same alignment requirements)
> - table size (no data, until end of table)
> - prefetch rate (from fastest possible to slower. about every 8, 16, 24 or
> 32 cycles)
>
> The idea behind loading and storing the contents of L2/L3 cache is to
> reduce memory latency in a system that is frequently swapping vcores on
> a physical CPU.
>
> The best case scenario for doing this is when some vcores are doing very
> cache heavy workloads. The worst case is when they have about 0 cache hits,
> so we just generate needless memory operations.
>
> This implementation just does L2 store/load. In my benchmarks this proves
> to be useful.
>
> Benchmark 1:
> - 16 core POWER8
> - 3x Ubuntu 14.04LTS guests (LE) with 8 VCPUs each
> - No split core/SMT
> - two guests running sysbench memory test.
> sysbench --test=memory --num-threads=8 run
> - one guest running apache bench (of default HTML page)
> ab -n 490000 -c 400 http://localhost/
>
> This benchmark aims to measure performance of real world application (apache)
> where other guests are cache hot with their own workloads. The sysbench memory
> benchmark does pointer sized writes to a (small) memory buffer in a loop.
>
> In this benchmark with this patch I can see an improvement both in requests
> per second (~5%) and in mean and median response times (again, about 5%).
> The spread of minimum and maximum response times were largely unchanged.
>
> benchmark 2:
> - Same VM config as benchmark 1
> - all three guests running sysbench memory benchmark
>
> This benchmark aims to see if there is a positive or negative affect to this
> cache heavy benchmark. Although due to the nature of the benchmark (stores) we
> may not see a difference in performance, but rather hopefully an improvement
> in consistency of performance (when vcore switched in, don't have to wait
> many times for cachelines to be pulled in)
>
> The results of this benchmark are improvements in consistency of performance
> rather than performance itself. With this patch, the few outliers in duration
> go away and we get more consistent performance in each guest.
>
> benchmark 3:
> - same 3 guests and CPU configuration as benchmark 1 and 2.
> - two idle guests
> - 1 guest running STREAM benchmark
>
> This scenario also saw performance improvement with this patch. On Copy and
> Scale workloads from STREAM, I got 5-6% improvement with this patch. For
> Add and triad, it was around 10% (or more).
>
> benchmark 4:
> - same 3 guests as previous benchmarks
> - two guests running sysbench --memory, distinctly different cache heavy
> workload
> - one guest running STREAM benchmark.
>
> Similar improvements to benchmark 3.
>
> benchmark 5:
> - 1 guest, 8 VCPUs, Ubuntu 14.04
> - Host configured with split core (SMT8, subcores-per-core=4)
> - STREAM benchmark
>
> In this benchmark, we see a 10-20% performance improvement across the board
> of STREAM benchmark results with this patch.
>
> Based on preliminary investigation and microbenchmarks
> by Prerna Saxena <prerna@linux.vnet.ibm.com>
>
> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
>
> --
> changes since v1:
> - s/mppe/mpp_buffer/
> - add MPP_BUFFER_ORDER define.
> ---
> arch/powerpc/include/asm/kvm_host.h | 1 +
> arch/powerpc/include/asm/ppc-opcode.h | 10 ++++++
> arch/powerpc/include/asm/reg.h | 1 +
> arch/powerpc/kvm/book3s_hv.c | 54 ++++++++++++++++++++++++++++++++-
> 4 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 1eaea2d..83ed249 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -305,6 +305,7 @@ struct kvmppc_vcore {
> u32 arch_compat;
> ulong pcr;
> ulong dpdes; /* doorbell state (POWER8) */
> + unsigned long mpp_buffer; /* Micro Partition Prefetch buffer */
> };
>
> #define VCORE_ENTRY_COUNT(vc) ((vc)->entry_exit_count & 0xff)
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
> index 3132bb9..6201440 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -139,6 +139,7 @@
> #define PPC_INST_ISEL 0x7c00001e
> #define PPC_INST_ISEL_MASK 0xfc00003e
> #define PPC_INST_LDARX 0x7c0000a8
> +#define PPC_INST_LOGMPP 0x7c0007e4
> #define PPC_INST_LSWI 0x7c0004aa
> #define PPC_INST_LSWX 0x7c00042a
> #define PPC_INST_LWARX 0x7c000028
> @@ -275,6 +276,13 @@
> #define __PPC_EH(eh) 0
> #endif
>
> +/* POWER8 Micro Partition Prefetch parameters */
> +#define PPC_MPPE_ADDRESS_MASK 0xffffffffc000
> +#define PPC_MPPE_WHOLE_TABLE (0x2ULL << 60)
> +#define PPC_MPPE_LOG_L2 (0x02ULL << 54)
> +#define PPC_MPPE_LOG_L2L3 (0x01ULL << 54)
> +#define PPC_MPPE_LOG_ABORT (0x03ULL << 54)
> +
> /* Deal with instructions that older assemblers aren't aware of */
> #define PPC_DCBAL(a, b) stringify_in_c(.long PPC_INST_DCBAL | \
> __PPC_RA(a) | __PPC_RB(b))
> @@ -283,6 +291,8 @@
> #define PPC_LDARX(t, a, b, eh) stringify_in_c(.long PPC_INST_LDARX | \
> ___PPC_RT(t) | ___PPC_RA(a) | \
> ___PPC_RB(b) | __PPC_EH(eh))
> +#define PPC_LOGMPP(b) stringify_in_c(.long PPC_INST_LOGMPP | \
> + __PPC_RB(b))
> #define PPC_LWARX(t, a, b, eh) stringify_in_c(.long PPC_INST_LWARX | \
> ___PPC_RT(t) | ___PPC_RA(a) | \
> ___PPC_RB(b) | __PPC_EH(eh))
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index e5d2e0b..5164beb 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -224,6 +224,7 @@
> #define CTRL_TE 0x00c00000 /* thread enable */
> #define CTRL_RUNLATCH 0x1
> #define SPRN_DAWR 0xB4
> +#define SPRN_MPPR 0xB8 /* Micro Partition Prefetch Register */
> #define SPRN_CIABR 0xBB
> #define CIABR_PRIV 0x3
> #define CIABR_PRIV_USER 1
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 8227dba..41dab67 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -67,6 +67,13 @@
> /* Used as a "null" value for timebase values */
> #define TB_NIL (~(u64)0)
>
> +#if defined(CONFIG_PPC_64K_PAGES)
> +#define MPP_BUFFER_ORDER 0
> +#elif defined(CONFIG_PPC_4K_PAGES)
> +#define MPP_BUFFER_ORDER 4
> +#endif
> +
> +
> static void kvmppc_end_cede(struct kvm_vcpu *vcpu);
> static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu *vcpu);
>
> @@ -1528,6 +1535,7 @@ static void kvmppc_run_core(struct kvmppc_vcore *vc)
> int i, need_vpa_update;
> int srcu_idx;
> struct kvm_vcpu *vcpus_to_update[threads_per_core];
> + phys_addr_t phy_addr, tmp;
Please put the variable declarations into the if () branch so that the
compiler can catch potential leaks :)
>
> /* don't start if any threads have a signal pending */
> need_vpa_update = 0;
> @@ -1590,9 +1598,48 @@ static void kvmppc_run_core(struct kvmppc_vcore *vc)
>
> srcu_idx = srcu_read_lock(&vc->kvm->srcu);
>
> + /* If we have a saved list of L2/L3, restore it */
> + if (cpu_has_feature(CPU_FTR_ARCH_207S) && vc->mpp_buffer) {
> + phy_addr = virt_to_phys((void *)vc->mpp_buffer);
> +#if defined(CONFIG_PPC_4K_PAGES)
> + phy_addr = (phy_addr + 8*4096) & ~(8*4096);
get_free_pages() is automatically aligned to the order, no?
> +#endif
> + tmp = phy_addr & PPC_MPPE_ADDRESS_MASK;
> + tmp = tmp | PPC_MPPE_WHOLE_TABLE;
> +
> + /* For sanity, abort any 'save' requests in progress */
> + asm volatile(PPC_LOGMPP(R1) : : "r" (tmp));
> +
> + /* Inititate a cache-load request */
> + mtspr(SPRN_MPPR, tmp);
> + }
In fact, this whole block up here could be a function, no?
> +
> + /* Allocate memory before switching out of guest so we don't
> + trash L2/L3 with memory allocation stuff */
> + if (cpu_has_feature(CPU_FTR_ARCH_207S) && !vc->mpp_buffer) {
> + vc->mpp_buffer = __get_free_pages(GFP_KERNEL|__GFP_ZERO,
> + MPP_BUFFER_ORDER);
get_order(64 * 1024)?
Also, why allocate it here and not on vcore creation?
> + }
> +
> __kvmppc_vcore_entry();
>
> spin_lock(&vc->lock);
> +
> + if (cpu_has_feature(CPU_FTR_ARCH_207S) && vc->mpp_buffer) {
> + phy_addr = (phys_addr_t)virt_to_phys((void *)vc->mpp_buffer);
> +#if defined(CONFIG_PPC_4K_PAGES)
> + phy_addr = (phy_addr + 8*4096) & ~(8*4096);
> +#endif
> + tmp = PPC_MPPE_ADDRESS_MASK & phy_addr;
> + tmp = tmp | PPC_MPPE_LOG_L2;
> +
> + /* Abort any existing 'fetch' operations for this core */
> + mtspr(SPRN_MPPR, tmp&0x0fffffffffffffff);
pretty magical, no?
> +
> + /* Finally, issue logmpp to save cache contents for L2 */
> + asm volatile(PPC_LOGMPP(R1) : : "r" (tmp));
> + }
This too should be a separate function.
Alex
> +
> /* disable sending of IPIs on virtual external irqs */
> list_for_each_entry(vcpu, &vc->runnable_threads, arch.run_list)
> vcpu->cpu = -1;
> @@ -2329,8 +2376,13 @@ static void kvmppc_free_vcores(struct kvm *kvm)
> {
> long int i;
>
> - for (i = 0; i < KVM_MAX_VCORES; ++i)
> + for (i = 0; i < KVM_MAX_VCORES; ++i) {
> + if (kvm->arch.vcores[i] && kvm->arch.vcores[i]->mpp_buffer) {
> + free_pages(kvm->arch.vcores[i]->mpp_buffer,
> + MPP_BUFFER_ORDER);
> + }
> kfree(kvm->arch.vcores[i]);
> + }
> kvm->arch.online_vcores = 0;
> }
>
^ permalink raw reply
* Re: Regression in 3.15 on POWER8 with multipath SCSI
From: Junichi Nomura @ 2014-07-08 10:28 UTC (permalink / raw)
To: Mike Snitzer, Paul Mackerras
Cc: Vladimir Davydov, bvanassche@acm.org,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
dm-devel@redhat.com, Andrew Morton, Linus Torvalds
In-Reply-To: <20140701193907.GA15306@redhat.com>
On 07/02/14 04:39, Mike Snitzer wrote:
> On Mon, Jun 30 2014 at 6:30am -0400,
> Paul Mackerras <paulus@samba.org> wrote:
>=20
>> I have a machine on which 3.15 usually fails to boot, and 3.14 boots
>> every time. The machine is a POWER8 2-socket server with 20 cores
>> (thus 160 CPUs), 128GB of RAM, and 7 SCSI disks connected via a
>> hardware-RAID-capable adapter which appears as two IPR controllers
>> which are both connected to each disk. I am booting from a disk that
>> has Fedora 20 installed on it.
>>
>> After over two weeks of bisections, I can finally point to the commits
>> that cause the problems. The culprits are:
>>
>> 3e9f1be1 dm mpath: remove process_queued_ios()
>> e8099177 dm mpath: push back requests instead of queueing
>> bcccff93 kobject: don't block for each kobject_uevent
>>
>> The interesting thing is that neither e8099177 nor bcccff93 cause
>> failures on their own, but with both commits in there are failures
>> where the system will fail to find /home on some occasions.
>>
>> With 3e9f1be1 included, the system appears to be prone to a deadlock
>> condition which typically causes the boot process to hang with this
>> message showing:
>>
>> A start job is running for Monitoring of LVM2 mirror...rogress polling
>>
>> (with a [*** ] thing before it where the asterisks move back and
>> forth).
>>
>> If I revert 63d832c3 ("dm mpath: really fix lockdep warning") ,
>> 4cdd2ad7 ("dm mpath: fix lock order inconsistency in
>> multipath_ioctl"), 3e9f1be1 and bcccff93, in that order, I get a
>> kernel that will boot every time. The first two are later commits
>> that fix some problems with 3e9f1be1 (though not the problems I am
>> seeing).
>>
>> Can anyone see any reason why e8099177 and bcccff93 would interfere
>> with each other?
>=20
> No, not seeing any obvious relation.
>=20
> But even though you listed e8099177 as a culprit you didn't list it as a
> commit you reverted. Did you leave e8099177 simply because attempting
> to revert it fails (if you don't first revert other dm-mpath.c commits)?
>=20
> (btw, Bart Van Assche also has issues with commit e8099177 due to hangs
> during cable pull testing of mpath devices -- Bart: curious to know if
> your cable pull tests pass if you just revert bcccff93).
It seems Bart's issue has gone with the attached patch:
http://www.redhat.com/archives/dm-devel/2014-July/msg00035.html
Could you try if it makes any difference on your issue?
The problem is dm-mpath's state machine stall due to e8099177
but ioctl to the device can kick the state machine running again.
That might be related to why bcccff93 affects the reproducibility.
Also, 3e9f1be1 integrates some codes into the one which is affected
by this problem. So it makes sense why the problem becomes easier
to occur with that.
-
Jun'ichi Nomura, NEC Corporation
pg_ready() checks the current state of the multipath and may return
false even if a new IO is needed to change the state.
OTOH, if multipath_busy() returns busy, a new IO will not be sent
to multipath target and the state change won't happen. That results
in lock up.
The intent of multipath_busy() is to avoid unnecessary cycles of
dequeue + request_fn + requeue if it is known that multipath device
will requeue.
Such situation would be:
- path group is being activated
- there is no path and the multipath is setup to requeue if no path
This patch should fix the problem introduced as a part of this commit:
commit e809917735ebf1b9a56c24e877ce0d320baee2ec
dm mpath: push back requests instead of queueing
diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
index ebfa411..d58343e 100644
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1620,8 +1620,9 @@ static int multipath_busy(struct dm_target *ti)
=20
spin_lock_irqsave(&m->lock, flags);
=20
- /* pg_init in progress, requeue until done */
- if (!pg_ready(m)) {
+ /* pg_init in progress or no paths available */
+ if (m->pg_init_in_progress ||
+ (!m->nr_valid_paths && m->queue_if_no_path)) {
busy =3D 1;
goto out;
}=
^ permalink raw reply related
* Re: [PATCH v5 2/2] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Masami Hiramatsu @ 2014-07-08 12:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Tony Luck
Cc: Jeremy Fitzhardinge, linux-ia64, sparse, H. Peter Anvin, akataria,
linux-tip-commits, anil.s.keshavamurthy, Ingo Molnar,
Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, Thomas Gleixner, Tony Luck,
Kevin Hao, Linus Torvalds, rdunlap, Linux Kernel Mailing List,
dl9pf, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20140702070029.14689.18485.stgit@kbuild-fedora.novalocal>
Ping?
This patch can be applied without 1/2, and will fix ia64/ppc64 problem.
Thank you,
(2014/07/02 16:00), Masami Hiramatsu wrote:
> On ia64 and ppc64, the function pointer does not point the
> entry address of the function, but the address of function
> discriptor (which contains the entry address and misc
> data.) Since the kprobes passes the function pointer stored
> by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
> initalizing its blacklist, it fails and reports many errors
> as below.
>
> Failed to find blacklist 0001013168300000
> Failed to find blacklist 0001013000f0a000
> Failed to find blacklist 000101315f70a000
> Failed to find blacklist 000101324c80a000
> Failed to find blacklist 0001013063f0a000
> Failed to find blacklist 000101327800a000
> Failed to find blacklist 0001013277f0a000
> Failed to find blacklist 000101315a70a000
> Failed to find blacklist 0001013277e0a000
> Failed to find blacklist 000101305a20a000
> Failed to find blacklist 0001013277d0a000
> Failed to find blacklist 00010130bdc0a000
> Failed to find blacklist 00010130dc20a000
> Failed to find blacklist 000101309a00a000
> Failed to find blacklist 0001013277c0a000
> Failed to find blacklist 0001013277b0a000
> Failed to find blacklist 0001013277a0a000
> Failed to find blacklist 000101327790a000
> Failed to find blacklist 000101303140a000
> Failed to find blacklist 0001013a3280a000
>
> To fix this bug, this introduces function_entry() macro to
> retrieve the entry address from the given function pointer,
> and uses for kallsyms_lookup_size_offset() while initializing
> blacklist.
>
> Changes in v5:
> - Use arch_deref_entry_point() instead of function_entry().
>
> Changes in v4:
> - Add kernel_text_address() check for verifying the address.
> - Moved on the latest linus tree.
>
> Changes in v3:
> - Fix a bug to get blacklist address based on function entry
> instead of function descriptor. (Suzuki's work, Thanks!)
>
> Changes in V2:
> - Use function_entry() macro when lookin up symbols instead
> of storing it.
> - Update for the latest -next.
>
> Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Reported-by: Tony Luck <tony.luck@gmail.com>
> Tested-by: Tony Luck <tony.luck@intel.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Suzuki K. Poulose <suzuki@in.ibm.com>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> Cc: Kevin Hao <haokexin@gmail.com>
> Cc: linux-ia64@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> kernel/kprobes.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 3214289..ec370cc 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -32,6 +32,7 @@
> * <prasanna@in.ibm.com> added function-return probes.
> */
> #include <linux/kprobes.h>
> +#include <linux/types.h>
> #include <linux/hash.h>
> #include <linux/init.h>
> #include <linux/slab.h>
> @@ -2037,19 +2038,23 @@ static int __init populate_kprobe_blacklist(unsigned long *start,
> {
> unsigned long *iter;
> struct kprobe_blacklist_entry *ent;
> - unsigned long offset = 0, size = 0;
> + unsigned long entry, offset = 0, size = 0;
>
> for (iter = start; iter < end; iter++) {
> - if (!kallsyms_lookup_size_offset(*iter, &size, &offset)) {
> - pr_err("Failed to find blacklist %p\n", (void *)*iter);
> + entry = arch_deref_entry_point((void *)*iter);
> +
> + if (!kernel_text_address(entry) ||
> + !kallsyms_lookup_size_offset(entry, &size, &offset)) {
> + pr_err("Failed to find blacklist at %p\n",
> + (void *)entry);
> continue;
> }
>
> ent = kmalloc(sizeof(*ent), GFP_KERNEL);
> if (!ent)
> return -ENOMEM;
> - ent->start_addr = *iter;
> - ent->end_addr = *iter + size;
> + ent->start_addr = entry;
> + ent->end_addr = entry + size;
> INIT_LIST_HEAD(&ent->list);
> list_add_tail(&ent->list, &kprobe_blacklist);
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply
* Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()
From: Alexander Gordeev @ 2014-07-08 12:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips@linux-mips.org, linux-s390, linux-pci@vger.kernel.org,
x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
open list:INTEL IOMMU (VT-d), xen-devel, linuxppc-dev
In-Reply-To: <CAErSpo6f6RXWv0DEtLBZX0jXoSUYJeWrSm7mubSJ_F-O7tQp6w@mail.gmail.com>
On Mon, Jul 07, 2014 at 01:40:48PM -0600, Bjorn Helgaas wrote:
> >> Can you quantify the benefit of this? Can't a device already use
> >> MSI-X to request exactly the number of vectors it can use? (I know
> >
> > A Intel AHCI chipset requires 16 vectors written to MME while advertises
> > (via AHCI registers) and uses only 6. Even attempt to init 8 vectors results
> > in device's fallback to 1 (!).
>
> Is the fact that it uses only 6 vectors documented in the public spec?
Yes, it is documented in ICH specs.
> Is this a chipset erratum? Are there newer versions of the chipset
> that fix this, e.g., by requesting 8 vectors and using 6, or by also
> supporting MSI-X?
No, this is not an erratum. The value of 8 vectors is reserved and could
cause undefined results if used.
> I know this conserves vector numbers. What does that mean in real
> user-visible terms? Are there systems that won't boot because of this
> issue, and this patch fixes them? Does it enable bigger
> configurations, e.g., more I/O devices, than before?
Visibly, it ceases logging messages ('ahci 0000:00:1f.2: irq 107 for
MSI/MSI-X') for IRQs that are not shown in /proc/interrupts later.
No, it does not enable/fix any existing hardware issue I am aware of.
It just saves a couple of interrupt vectors, as Michael put it (10/16
to be precise). However, interrupt vectors space is pretty much scarce
resource on x86 and a risk of exhausting the vectors (and introducing
quota i.e) has already been raised AFAIR.
> Do you know how Windows handles this? Does it have a similar interface?
Have no clue, TBH. Can try to investigate if you see it helpful.
> As you can tell, I'm a little skeptical about this. It's a fairly big
> change, it affects the arch interface, it seems to be targeted for
> only a single chipset (though it's widely used), and we already
> support a standard solution (MSI-X, reducing the number of vectors
> requested, or even operating with 1 vector).
I also do not like the fact the arch interface is getting complicated,
so I happily leave it to your judgement ;) Well, it is low-level and
hidden from drivers at least.
Thanks!
> Bjorn
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH v5] powerpc/powernv: hwmon driver for power, fan rpm, voltage and temperature
From: Guenter Roeck @ 2014-07-08 13:34 UTC (permalink / raw)
To: Neelesh Gupta, devicetree, linuxppc-dev, lm-sensors; +Cc: sbhat, jdelvare
In-Reply-To: <20140708090315.3866.15604.stgit@localhost.localdomain>
On 07/08/2014 02:08 AM, Neelesh Gupta wrote:
> This patch adds basic kernel support for reading power values, fan
> speed rpm, voltage and temperature data on powernv platforms which
> will be exported to user space through sysfs interface.
>
> Test results:
> -------------
> [root@tul163p1 ~]# sensors
> ibmpowernv-isa-0000
> Adapter: ISA adapter
> fan1: 5465 RPM (min = 0 RPM)
> fan2: 5152 RPM (min = 0 RPM)
> fan3: 5521 RPM (min = 0 RPM)
> fan4: 4891 RPM (min = 0 RPM)
> fan5: 0 RPM (min = 0 RPM)
> fan6: 0 RPM (min = 0 RPM)
> fan7: 7480 RPM (min = 0 RPM)
> fan8: 7944 RPM (min = 0 RPM)
> temp1: +39.0°C (high = +0.0°C)
> power1: 190.00 W
>
> [root@tul163p1 ~]# ls /sys/devices/platform/
> alarmtimer ibmpowernv.0 power rtc-generic serial8250 uevent
> [root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/hwmon/hwmon0/
> device fan2_min fan4_min fan6_min fan8_min power
> fan1_fault fan3_fault fan5_fault fan7_fault in1_fault power1_input
> fan1_input fan3_input fan5_input fan7_input in2_fault subsystem
> fan1_min fan3_min fan5_min fan7_min in3_fault temp1_input
> fan2_fault fan4_fault fan6_fault fan8_fault in4_fault temp1_max
> fan2_input fan4_input fan6_input fan8_input name uevent
> [root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/
> device fan2_min fan4_min fan6_min fan8_min power
> fan1_fault fan3_fault fan5_fault fan7_fault in1_fault power1_input
> fan1_input fan3_input fan5_input fan7_input in2_fault subsystem
> fan1_min fan3_min fan5_min fan7_min in3_fault temp1_input
> fan2_fault fan4_fault fan6_fault fan8_fault in4_fault temp1_max
> fan2_input fan4_input fan6_input fan8_input name uevent
> [root@tul163p1 ~]#
>
> Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Applied to -next, with a minor cleanup.
Thanks for your patience,
Guenter
> diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv
> new file mode 100644
> index 0000000..644245a
> --- /dev/null
> +++ b/Documentation/hwmon/ibmpowernv
> @@ -0,0 +1,41 @@
> +Kernel Driver IBMPOWENV
s/IBMPOWENV/IBMPOWERNV/
^ permalink raw reply
* Re: [PATCH][v2]devicetree/binding/powerpc/fsl: Add binding for CPLD
From: Scott Wood @ 2014-07-08 14:06 UTC (permalink / raw)
To: Priyanka Jain; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1404796006-3254-1-git-send-email-Priyanka.Jain@freescale.com>
On Tue, 2014-07-08 at 10:36 +0530, Priyanka Jain wrote:
> Some Freescale boards like T1040RDB have on board CPLD connected on
> the IFC bus. Add binding for this in board.txt file
>
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> ---
> Changes for v2: Incorporated Scott's comments
Isn't this v3?
> .../devicetree/bindings/powerpc/fsl/board.txt | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> index 700dec4..67ef6a4 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> @@ -84,3 +84,19 @@ Example:
> compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
> reg = <0x66>;
> };
> +
> +* Freescale on-board CPLD
> +
> +Some Freescale boards like T1040RDB have on board CPLD connected.
s/have on board/have an on board/
> +
> +Required properties:
> +- compatible: Should be a board-specific string like "fsl,<board>-cpld"
> + Example:
> + "fsl,T1040RDB-cpld", "fsl,T1042RDB-cpld", "fsl,T1042RDB_PI-cpld"
> +- reg: should describe CPLD registers
> +
> +Example:
> + cpld@3,0 {
> + compatible = "fsl,T1040RDB-cpld";
> + reg = <3 0 0x300>;
> + };
Again, please keep the board name lowercase.
-Scott
^ permalink raw reply
* Fwd: powerpc allyesconfig fix
From: Nick Krause @ 2014-07-08 16:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Alexander Graf, linux-kernel@vger.kernel.org, Michael Ellerman,
paulus, Anton Blanchard, mahesh, linuxppc-dev, Guenter Roeck
In-Reply-To: <20140708160417.47fb4d7c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 815 bytes --]
From: Stephen Rothwell wrote on Tue, Jul 8, 2014 at 2:04 AM
Subject: Re: powerpc allyesconfig fix
Hi Nicholas,
On Tue, 8 Jul 2014 01:04:09 -0400 Nicholas Krause <xerofoify@gmail.com> wrote:
>
> powerpc:allmodconfig has been failing for some time with the following
> error.
This patch has already bee submitted directly by Guenter, however for
future reference: when you submit someone else's patch, you should
include a From line as the first line of the email body containing their
email address and you should include a Signed-off-by line from yourself.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
Hey Stephen,
Thanks for the heads up on submitting other people's patches. It would
be great if you can push this up into Linus's tree
for the next developer release.
--
Cheers Nick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Fwd: powerpc allyesconfig fix
From: Guenter Roeck @ 2014-07-08 16:43 UTC (permalink / raw)
To: Nick Krause
Cc: Stephen Rothwell, mahesh, Alexander Graf,
linux-kernel@vger.kernel.org, Michael Ellerman, paulus,
Anton Blanchard, linuxppc-dev
In-Reply-To: <CAPDOMVitjYMkoLAbwf6oBJg+fpFdKLi+S4hTm6opD27DMC1NDw@mail.gmail.com>
On Tue, Jul 08, 2014 at 12:35:27PM -0400, Nick Krause wrote:
> From: Stephen Rothwell wrote on Tue, Jul 8, 2014 at 2:04 AM
> Subject: Re: powerpc allyesconfig fix
>
> Hi Nicholas,
>
> On Tue, 8 Jul 2014 01:04:09 -0400 Nicholas Krause <xerofoify@gmail.com> wrote:
> >
> > powerpc:allmodconfig has been failing for some time with the following
> > error.
>
> This patch has already bee submitted directly by Guenter, however for
> future reference: when you submit someone else's patch, you should
> include a From line as the first line of the email body containing their
> email address and you should include a Signed-off-by line from yourself.
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
>
> Hey Stephen,
> Thanks for the heads up on submitting other people's patches. It would
> be great if you can push this up into Linus's tree
> for the next developer release.
Ben already mentioned that he would pick it up.
Guenter
^ permalink raw reply
* Re: [PATCH v2] Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8
From: Stewart Smith @ 2014-07-08 22:59 UTC (permalink / raw)
To: Alexander Graf, linuxppc-dev, paulus, kvm-ppc
In-Reply-To: <53BBCAC7.90904@suse.de>
Hi!
Thanks for review, much appreciated!
Alexander Graf <agraf@suse.de> writes:
> On 08.07.14 07:06, Stewart Smith wrote:
>> @@ -1528,6 +1535,7 @@ static void kvmppc_run_core(struct kvmppc_vcore *vc)
>> int i, need_vpa_update;
>> int srcu_idx;
>> struct kvm_vcpu *vcpus_to_update[threads_per_core];
>> + phys_addr_t phy_addr, tmp;
>
> Please put the variable declarations into the if () branch so that the
> compiler can catch potential leaks :)
ack. will fix.
>> @@ -1590,9 +1598,48 @@ static void kvmppc_run_core(struct kvmppc_vcore *vc)
>>
>> srcu_idx = srcu_read_lock(&vc->kvm->srcu);
>>
>> + /* If we have a saved list of L2/L3, restore it */
>> + if (cpu_has_feature(CPU_FTR_ARCH_207S) && vc->mpp_buffer) {
>> + phy_addr = virt_to_phys((void *)vc->mpp_buffer);
>> +#if defined(CONFIG_PPC_4K_PAGES)
>> + phy_addr = (phy_addr + 8*4096) & ~(8*4096);
>
> get_free_pages() is automatically aligned to the order, no?
That's what Paul reckoned too, and then we've attempted to find anywhere
that documents that behaviour. Happen to be able to point to docs/source
that say this is part of API?
>> +#endif
>> + tmp = phy_addr & PPC_MPPE_ADDRESS_MASK;
>> + tmp = tmp | PPC_MPPE_WHOLE_TABLE;
>> +
>> + /* For sanity, abort any 'save' requests in progress */
>> + asm volatile(PPC_LOGMPP(R1) : : "r" (tmp));
>> +
>> + /* Inititate a cache-load request */
>> + mtspr(SPRN_MPPR, tmp);
>> + }
>
> In fact, this whole block up here could be a function, no?
It could, perfectly happy for it to be one. Will fix.
>> +
>> + /* Allocate memory before switching out of guest so we don't
>> + trash L2/L3 with memory allocation stuff */
>> + if (cpu_has_feature(CPU_FTR_ARCH_207S) && !vc->mpp_buffer) {
>> + vc->mpp_buffer = __get_free_pages(GFP_KERNEL|__GFP_ZERO,
>> + MPP_BUFFER_ORDER);
>
> get_order(64 * 1024)?
>
> Also, why allocate it here and not on vcore creation?
There's also the possibility of saving/restorting part of the L3 cache
as well, and I was envisioning a future patch to this which checks a
flag in vcore (maybe exposed via sysfs or whatever mechanism is
applicable) if it should save/restore L2 or L2/L3, so thus it makes a
bit more sense allocating it there rather than elsewhere.
There's also no real reason to fail to create a vcore if we can't
allocate a buffer for L2/L3 cache contents - retrying later is perfectly
harmless.
>> +
>> + if (cpu_has_feature(CPU_FTR_ARCH_207S) && vc->mpp_buffer) {
>> + phy_addr = (phys_addr_t)virt_to_phys((void *)vc->mpp_buffer);
>> +#if defined(CONFIG_PPC_4K_PAGES)
>> + phy_addr = (phy_addr + 8*4096) & ~(8*4096);
>> +#endif
>> + tmp = PPC_MPPE_ADDRESS_MASK & phy_addr;
>> + tmp = tmp | PPC_MPPE_LOG_L2;
>> +
>> + /* Abort any existing 'fetch' operations for this core */
>> + mtspr(SPRN_MPPR, tmp&0x0fffffffffffffff);
>
> pretty magical, no?
Yeah, sorry about that.... I'll hide it in a function at least, and do
something a bit better there... IIRC this magic came from the initial
work that proved the hardware functionality, so I'll go back and re-read
some hardware documentation to see where exactly this came from...
>> +
>> + /* Finally, issue logmpp to save cache contents for L2 */
>> + asm volatile(PPC_LOGMPP(R1) : : "r" (tmp));
>> + }
>
> This too should be a separate function.
ack.
^ permalink raw reply
* Re: [PATCH] devicetree/bindings/powerpc/fsl: Add binding for board
From: Scott Wood @ 2014-07-09 1:46 UTC (permalink / raw)
To: Jain Priyanka-B32167
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5e950276b79a48e5bc3b65007f7fc208@BLUPR03MB135.namprd03.prod.outlook.com>
On Mon, 2014-07-07 at 22:56 -0500, Jain Priyanka-B32167 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, July 08, 2014 3:00 AM
> > To: Jain Priyanka-B32167
> > Cc: devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] devicetree/bindings/powerpc/fsl: Add binding for
> > board
> >
> > On Mon, 2014-07-07 at 14:06 +0530, Priyanka Jain wrote:
> > > Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> > > ---
> > > .../devicetree/bindings/powerpc/fsl/board.txt | 17
> > ++++++++++++++++-
> > > 1 files changed, 16 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > > b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > > index f35f295..7800729 100644
> > > --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > > +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > > @@ -1,8 +1,23 @@
> > > Freescale Reference Board Bindings
> > >
> > > -This document describes device tree bindings for various devices that
> > > +This document describes device tree bindings for board and various
> > > +devices that
> > > exist on some Freescale reference boards.
> > >
> > > +* Board node
> > > +Required properties:
> > > +
> > > + - model : Should be "fsl,<board>"
> > > + - compatible : Should be "fsl,<board>"
> > > + example: "fsl,T1040RDB", "fsl,T1042RDB", "fsl,T1042RDB_PI"
> > > + "fsl,T1040QDS", "fsl,T1042QDS"
> > > +
> > > +Example:
> > > +
> > > +/ {
> > > + model = "fsl,T1040RDB";
> > > + compatible = "fsl,T1040RDB";
> > > +};
> >
> > We really don't need to do this for every board just to satisfy
> > checkpatch.
> >
> > -Scott
> >
> [Jain Priyanka-B32167] Is it OK to submit a patch with board checkpatch warning for this case ?
If you mean "is it OK to submit a board patch that has checkpatch
warnings of this sort, where the compatible follows a well established
pattern", then yes.
-Scott
^ permalink raw reply
* Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a memory
From: Scott Wood @ 2014-07-09 1:53 UTC (permalink / raw)
To: Jain Priyanka-B32167
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org
In-Reply-To: <a9ac5cbcdb554bedbda35594740e320d@BLUPR03MB135.namprd03.prod.outlook.com>
On Mon, 2014-07-07 at 23:41 -0500, Jain Priyanka-B32167 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, July 08, 2014 2:56 AM
> > To: Jain Priyanka-B32167
> > Cc: devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> > spi@vger.kernel.org; linux-mtd@lists.infradead.org
> > Subject: Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a
> > memory
> >
> > On Thu, 2014-07-03 at 23:08 -0500, Jain Priyanka-B32167 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Friday, July 04, 2014 3:40 AM
> > > > To: Jain Priyanka-B32167
> > > > Cc: devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > linux- spi@vger.kernel.org; linux-mtd@lists.infradead.org
> > > > Subject: Re: [PATCH] devicetree/bindings: Add binding for micron
> > > > n25q512a memory
> > > >
> > > > On Thu, 2014-07-03 at 15:42 +0530, Priyanka Jain wrote:
> > > > > -Micron n25q512a memory is supported by m25p80 driver.
> > > > > Add compatible field required to support n25q512a in m25p80.txt
> > > > > -Add micron to the vendor-prefixes.txt file
> > > > >
> > > > > Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> > > > > ---
> > > > > Documentation/devicetree/bindings/mtd/m25p80.txt | 1 +
> > > > > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > > > > 2 files changed, 2 insertions(+), 0 deletions(-)
> > > >
> > > > Why did you send this to the ppc list but not the spi or mtd lists?
> > > >
> > > [Jain Priyanka-B32167] Sorry, I missed that
> > > > I'm having a hard time following the flow of how these SPI devices
> > > > get bound -- is the compatible involved at all? I don't see this
> > > > string (with vendor prefix included) in the driver. I do see a
> > > > table that contains what looks like device IDs. If the device can
> > > > report its id, shouldn't we rely on that rather than device tree
> > compatible?
> > > >
> > > > -Scott
> > > [Jain Priyanka-B32167]
> > > Spi driver has a check to device name corresponding to device-id and
> > compare to what is passed in dts string.
> >
> > Please go into more detail. I don't see where the string
> > "micron,n25q512a" appears in the current kernel. I do see "n25q512a",
> > but how does that compare successfully with the version of the string
> > that has a vendor compatible?
> >
> > Again, is there a device ID that can be read at runtime? Is there a
> > compatible string that represents a common programming interface?
> [Jain Priyanka-B32167]
>
> Spi driver (of_register_spi_devices()) search for compatible string in
> device-tree. It selects the flash device driver based on the compatible
> string (n25q512a). This compatible string is essential, else device
> probe wont continue. Then Device-id of flash is read at runtime in
> probe and compared with the corresponding device-id of flash
> (n25q512a). Device-id (maintained as first element in INFO string in
> spi_nor_ids[] in drivers/mtd/spi-nor/spi-nor.c file)
By "device id" I'm talking about 0x20bb20, not "n25q512a". Where does
that come from?
> Only if both device-ids match, the device is taken as successfully
> detected. Regarding vendor "micron", you are right currently the vendor
> information is not maintained as such in device-id, but the convention
> that is followed for compatible string is "vendor-id, device-id"
Is there going to be a patch to the driver to accept the string with
vendor id?
> > > New checkpatch script search for exact string match in binding folder.
> > So, I have added this in example.
> >
> > That check has a lot of false positives when it comes to compatible
> > strings for specific chips that don't need to be specifically mentioned
> > in a more generic binding.
> >
> > -Scott
> >
> [Jain Priyanka-B32167] Even though "micron,n25q512a" is in sync with
> binding mentioned in "
> Documentation/devicetree/bindings/mtd/m25p80.txt ", I have to add
> this as an a example, just to avoid checkpatch error. What should be
> the approach going forward: Should such checkpatch warnings be ignored?
They shouldn't be ignored nor blindly remedied. You should look at the
message and decide whether a binding is needed and whether it is
present. There probably should be a binding here, but I don't have
enough information to say whether it should be specific to n25q512a or
if spi nor can be described more generically.
-Scott
^ permalink raw reply
* [PATCH][v3]devicetree/binding/powerpc/fsl: Add binding for CPLD
From: Priyanka Jain @ 2014-07-09 3:47 UTC (permalink / raw)
To: scottwood, devicetree, linuxppc-dev; +Cc: Priyanka Jain
Some Freescale boards like T1040RDB have an on board CPLD connected on
the IFC bus. Add binding for cpld in board.txt file
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
Changes for v2: Incorporated Scott's comments
.../devicetree/bindings/powerpc/fsl/board.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 700dec4..67ef6a4 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -84,3 +84,19 @@ Example:
compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
reg = <0x66>;
};
+
+* Freescale on-board CPLD
+
+Some Freescale boards like T1040RDB have an on board CPLD connected.
+
+Required properties:
+- compatible: Should be a board-specific string like "fsl,<board>-cpld"
+ Example:
+ "fsl,t1040rdb-cpld", "fsl,t1042rdb-cpld", "fsl,t1042rdb_pi-cpld"
+- reg: should describe CPLD registers
+
+Example:
+ cpld@3,0 {
+ compatible = "fsl,t1040rdb-cpld";
+ reg = <3 0 0x300>;
+ };
--
1.7.4.1
^ permalink raw reply related
* Re: Regression in 3.15 on POWER8 with multipath SCSI
From: Alexey Kardashevskiy @ 2014-07-09 3:55 UTC (permalink / raw)
To: Junichi Nomura, Mike Snitzer, Paul Mackerras
Cc: Vladimir Davydov, bvanassche@acm.org,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
dm-devel@redhat.com, Andrew Morton, Linus Torvalds
In-Reply-To: <11AF7C027C4C02408624617A4986078401323542@BPXM12GP.gisp.nec.co.jp>
On 07/08/2014 08:28 PM, Junichi Nomura wrote:
> On 07/02/14 04:39, Mike Snitzer wrote:
>> On Mon, Jun 30 2014 at 6:30am -0400,
>> Paul Mackerras <paulus@samba.org> wrote:
>>
>>> I have a machine on which 3.15 usually fails to boot, and 3.14 boots
>>> every time. The machine is a POWER8 2-socket server with 20 cores
>>> (thus 160 CPUs), 128GB of RAM, and 7 SCSI disks connected via a
>>> hardware-RAID-capable adapter which appears as two IPR controllers
>>> which are both connected to each disk. I am booting from a disk that
>>> has Fedora 20 installed on it.
>>>
>>> After over two weeks of bisections, I can finally point to the commits
>>> that cause the problems. The culprits are:
>>>
>>> 3e9f1be1 dm mpath: remove process_queued_ios()
>>> e8099177 dm mpath: push back requests instead of queueing
>>> bcccff93 kobject: don't block for each kobject_uevent
>>>
>>> The interesting thing is that neither e8099177 nor bcccff93 cause
>>> failures on their own, but with both commits in there are failures
>>> where the system will fail to find /home on some occasions.
>>>
>>> With 3e9f1be1 included, the system appears to be prone to a deadlock
>>> condition which typically causes the boot process to hang with this
>>> message showing:
>>>
>>> A start job is running for Monitoring of LVM2 mirror...rogress polling
>>>
>>> (with a [*** ] thing before it where the asterisks move back and
>>> forth).
>>>
>>> If I revert 63d832c3 ("dm mpath: really fix lockdep warning") ,
>>> 4cdd2ad7 ("dm mpath: fix lock order inconsistency in
>>> multipath_ioctl"), 3e9f1be1 and bcccff93, in that order, I get a
>>> kernel that will boot every time. The first two are later commits
>>> that fix some problems with 3e9f1be1 (though not the problems I am
>>> seeing).
>>>
>>> Can anyone see any reason why e8099177 and bcccff93 would interfere
>>> with each other?
>>
>> No, not seeing any obvious relation.
>>
>> But even though you listed e8099177 as a culprit you didn't list it as a
>> commit you reverted. Did you leave e8099177 simply because attempting
>> to revert it fails (if you don't first revert other dm-mpath.c commits)?
>>
>> (btw, Bart Van Assche also has issues with commit e8099177 due to hangs
>> during cable pull testing of mpath devices -- Bart: curious to know if
>> your cable pull tests pass if you just revert bcccff93).
>
> It seems Bart's issue has gone with the attached patch:
> http://www.redhat.com/archives/dm-devel/2014-July/msg00035.html
> Could you try if it makes any difference on your issue?
>
> The problem is dm-mpath's state machine stall due to e8099177
> but ioctl to the device can kick the state machine running again.
> That might be related to why bcccff93 affects the reproducibility.
> Also, 3e9f1be1 integrates some codes into the one which is affected
> by this problem. So it makes sense why the problem becomes easier
> to occur with that.
>
> -
> Jun'ichi Nomura, NEC Corporation
>
>
> pg_ready() checks the current state of the multipath and may return
> false even if a new IO is needed to change the state.
>
> OTOH, if multipath_busy() returns busy, a new IO will not be sent
> to multipath target and the state change won't happen. That results
> in lock up.
>
> The intent of multipath_busy() is to avoid unnecessary cycles of
> dequeue + request_fn + requeue if it is known that multipath device
> will requeue.
>
> Such situation would be:
> - path group is being activated
> - there is no path and the multipath is setup to requeue if no path
>
> This patch should fix the problem introduced as a part of this commit:
> commit e809917735ebf1b9a56c24e877ce0d320baee2ec
> dm mpath: push back requests instead of queueing
>
> diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
> index ebfa411..d58343e 100644
> --- a/drivers/md/dm-mpath.c
> +++ b/drivers/md/dm-mpath.c
> @@ -1620,8 +1620,9 @@ static int multipath_busy(struct dm_target *ti)
>
> spin_lock_irqsave(&m->lock, flags);
>
> - /* pg_init in progress, requeue until done */
> - if (!pg_ready(m)) {
> + /* pg_init in progress or no paths available */
> + if (m->pg_init_in_progress ||
> + (!m->nr_valid_paths && m->queue_if_no_path)) {
> busy = 1;
> goto out;
> }
This patch fixes IPR SCSI for my POWER8 box, e8099177 was the problem.
--
Alexey
^ permalink raw reply
* [PATCH 1/2] powerpc/fsl-booke: Add initial T1040/T1042 RDB board support
From: Priyanka Jain @ 2014-07-09 4:23 UTC (permalink / raw)
To: scottwood, devicetree, linuxppc-dev
Cc: Priyanka Jain, Poonam Aggrwal, Prabhakar Kushwaha
T1040/T1042RDB is Freescale Reference Design Board.
The board can support both T1040/T1042 QorIQ Power Architecture™ processor.
T1040/T1042RDB board Overview
-----------------------
- SERDES Connections, 8 lanes supporting:
- PCI
- SGMII
- QSGMII
- SATA 2.0
- DDR Controller
- Supports rates of up to 1600 MHz data-rate
- Supports one DDR3LP UDIMM
-IFC/Local Bus
- NAND flash: 1GB 8-bit NAND flash
- NOR: 128MB 16-bit NOR Flash
- Ethernet
- Two on-board RGMII 10/100/1G ethernet ports.
- PHY #0 remains powered up during deep-sleep
- CPLD
- Clocks
- System and DDR clock (SYSCLK, “DDRCLK”)
- SERDES clocks
- Power Supplies
- USB
- Supports two USB 2.0 ports with integrated PHYs
- Two type A ports with 5V@1.5A per port.
- SDHC
- SDHC/SDXC connector
- SPI
- On-board 64MB SPI flash
- I2C
- Devices connected: EEPROM, thermal monitor, VID controller
- Other IO
- Two Serial ports
- ProfiBus port
Add support for T1040/T1042 RDB board:
-add device tree
-add entry in Kconfig to build
-Add entry in corenet_generic.c, as it is similar to other corenet platforms
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
arch/powerpc/boot/dts/t1040rdb.dts | 43 +++++++
arch/powerpc/boot/dts/t1042rdb.dts | 43 +++++++
arch/powerpc/boot/dts/t104xrdb.dtsi | 157 +++++++++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +
5 files changed, 246 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/t1040rdb.dts
create mode 100644 arch/powerpc/boot/dts/t1042rdb.dts
create mode 100644 arch/powerpc/boot/dts/t104xrdb.dtsi
diff --git a/arch/powerpc/boot/dts/t1040rdb.dts b/arch/powerpc/boot/dts/t1040rdb.dts
new file mode 100644
index 0000000..ff26043
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1040rdb.dts
@@ -0,0 +1,43 @@
+/*
+ * T1040RDB 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/t104xsi-pre.dtsi"
+/include/ "t104xrdb.dtsi"
+
+/ {
+ model = "fsl,T1040RDB";
+ compatible = "fsl,T1040RDB";
+};
+
+/include/ "fsl/t1040si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t1042rdb.dts b/arch/powerpc/boot/dts/t1042rdb.dts
new file mode 100644
index 0000000..a30058a
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1042rdb.dts
@@ -0,0 +1,43 @@
+/*
+ * T1042RDB 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/t104xsi-pre.dtsi"
+/include/ "t104xrdb.dtsi"
+
+/ {
+ model = "fsl,T1042RDB";
+ compatible = "fsl,T1042RDB";
+};
+
+/include/ "fsl/t1042si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t104xrdb.dtsi b/arch/powerpc/boot/dts/t104xrdb.dtsi
new file mode 100644
index 0000000..9aaefa5
--- /dev/null
+++ b/arch/powerpc/boot/dts/t104xrdb.dtsi
@@ -0,0 +1,157 @@
+/*
+ * T1040RDB/T1042RDB 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.
+ */
+
+/ {
+
+ ifc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x2000>;
+ ranges = <0 0 0xf 0xe8000000 0x08000000
+ 2 0 0xf 0xff800000 0x00010000
+ 3 0 0xf 0xffdf0000 0x00008000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x10000>;
+ };
+
+ cpld@3,0 {
+ compatible = "fsl,t1040rdb-cpld","fsl,t1042rdb-cpld";
+ reg = <3 0 0x300>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ dcsr: dcsr@f00000000 {
+ ranges = <0x00000000 0xf 0x00000000 0x01072000>;
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+
+ spi@110000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "micron,n25q512a";
+ reg = <0>;
+ spi-max-frequency = <10000000>; /* input clock */
+ };
+ };
+
+ i2c@118100 {
+ pca9546@77 {
+ compatible = "nxp,pca9546";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ };
+
+ pci0: pcie@ffe240000 {
+ reg = <0xf 0xfe240000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci1: pcie@ffe250000 {
+ reg = <0xf 0xfe250000 0 0x10000>;
+ ranges = <0x02000000 0x0 0xe0000000 0xc 0x10000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci2: pcie@ffe260000 {
+ reg = <0xf 0xfe260000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci3: pcie@ffe270000 {
+ reg = <0xf 0xfe270000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x30000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8030000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 5063696..157a1a4 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -276,7 +276,7 @@ config CORENET_GENERIC
For 64bit kernel, the following boards are supported:
T208x QDS, T4240 QDS/RDB and B4 QDS
The following boards are supported for both 32bit and 64bit kernel:
- P5020 DS, P5040 DS and T104xQDS
+ P5020 DS, P5040 DS and T104xQDS/RDB
endif # FSL_SOC_BOOKE
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index 4f22ad1..c268f89 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -128,6 +128,8 @@ static const char * const boards[] __initconst = {
"fsl,B4220QDS",
"fsl,T1040QDS",
"fsl,T1042QDS",
+ "fsl,T1040RDB",
+ "fsl,T1042RDB",
"keymile,kmcoge4",
NULL
};
--
1.7.4.1
^ 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