* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 1:36 UTC (permalink / raw)
To: Michael Neuling
Cc: sfr, matt, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Mike Qiu, linuxppc-dev
In-Reply-To: <5179D5D8.8080102@asianux.com>
On 2013年04月26日 09:18, Chen Gang wrote:
> On 2013年04月26日 09:06, Chen Gang wrote:
>>> CFAR is the Come From Register. It saves the location of the last
>>>> branch and is hence overwritten by any branch.
>>>>
>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>> . = 0x900
>> .globl decrementer_pSeries
>> decrementer_pSeries:
>> HMT_MEDIUM_PPR_DISCARD
>> SET_SCRATCH0(r13)
>> b decrementer_pSeries_0
>>
>> ...
>>
>>
Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
---------------------------------diff v2 begin-----------------------------
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index e789ee7..f0489c4 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -254,7 +254,15 @@ hardware_interrupt_hv:
STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
- MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
+ . = 0x900
+ .globl decrementer_pSeries
+decrementer_pSeries:
+ HMT_MEDIUM_PPR_DISCARD
+ SET_SCRATCH0(r13) /* save r13 */
+ EXCEPTION_PROLOG_0(PACA_EXGEN)
+ EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
+ b decrementer_pSeries_0
+
STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
@@ -536,6 +544,11 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
#endif
.align 7
+ /* moved from 0x900 */
+decrementer_pSeries_0:
+ EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
+
+ .align 7
/* moved from 0xe00 */
STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
---------------------------------diff v2 end-------------------------------
>
> Such as the fix below, is it OK (just like 0x300 or 0x200 has done) ?
>
> Please check, thanks.
>
> ---------------------------diff begin-------------------------------------
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index e789ee7..a0a5ff2 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -254,7 +254,14 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + HMT_MEDIUM_PPR_DISCARD
> + SET_SCRATCH0(r13) /* save r13 */
> + EXCEPTION_PROLOG_0(PACA_EXGEN)
> + b decrementer_pSeries_0
> +
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
> @@ -536,6 +543,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
> #endif
>
> .align 7
> + /* moved from 0x900 */
> +decrementer_pSeries_0:
> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
> + EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
> +
> + .align 7
> /* moved from 0xe00 */
> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
>
> ---------------------------diff end---------------------------------------
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply related
* Re: [PATCH 1/1] kvm:book3e: Fix a build error
From: tiejun.chen @ 2013-04-26 1:53 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
kvm@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3D9C33@039-SN2MPN1-013.039d.mgd.msft.net>
On 04/25/2013 08:11 PM, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-
>> owner@vger.kernel.org] On Behalf Of Tiejun Chen
>> Sent: Thursday, April 25, 2013 2:46 PM
>> To: galak@kernel.crashing.org
>> Cc: linuxppc-dev@lists.ozlabs.org; kvm-ppc@vger.kernel.org;
>> kvm@vger.kernel.org
>> Subject: [PATCH 1/1] kvm:book3e: Fix a build error
>>
>> Commit cd66cc2e, "powerpc/85xx: Add AltiVec support for e6500", adds
>> support for AltiVec on a Book-E class processor, but while compiling
>> in the CONFIG_PPC_BOOK3E_64 and CONFIG_VIRTUALIZATION case, this
>> introduce the following error:
>>
>> arch/powerpc/kernel/exceptions-64e.S:402: undefined reference to
>> `kvmppc_handler_42_0x01B'
>> arch/powerpc/kernel/built-in.o: In function `exc_altivec_assist_book3e':
>> arch/powerpc/kernel/exceptions-64e.S:424: undefined reference to
>> `kvmppc_handler_43_0x01B'
>> make: *** [vmlinux] Error 1
>>
>> Looks we should add these altivec kvm handlers.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>> ---
>> arch/powerpc/kvm/bookehv_interrupts.S | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/powerpc/kvm/bookehv_interrupts.S
>> b/arch/powerpc/kvm/bookehv_interrupts.S
>> index e8ed7d6..fa9c78a 100644
>> --- a/arch/powerpc/kvm/bookehv_interrupts.S
>> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
>> @@ -319,6 +319,11 @@ kvm_handler BOOKE_INTERRUPT_DEBUG, EX_PARAMS(DBG), \
>> SPRN_DSRR0, SPRN_DSRR1, 0
>> kvm_handler BOOKE_INTERRUPT_DEBUG, EX_PARAMS(CRIT), \
>> SPRN_CSRR0, SPRN_CSRR1, 0
>> +/* altivec */
>> +kvm_handler BOOKE_INTERRUPT_ALTIVEC_UNAVAIL, EX_PARAMS(GEN), \
>> + SPRN_SRR0, SPRN_SRR1, 0
>> +kvm_handler BOOKE_INTERRUPT_ALTIVEC_ASSIST, EX_PARAMS(GEN), \
>> + SPRN_SRR0, SPRN_SRR1, 0
>> #else
>> /*
>> * For input register values, see
>> arch/powerpc/include/asm/kvm_booke_hv_asm.h
>> --
>
> It seems that you are not using kvm-ppc-queue branch.
This is just used to fix a build error in powerpc.git when introduce commit
cd66cc2e, "powerpc/85xx: Add AltiVec support for e6500", in *powerpc.git* as I
mentioned in this patch head.
>
> I already have a patch ready for this (and AltiVec support is work
This change don't block your AltiVec support for kvm unless you think this
change is wrong. And especially, we always can reproduce this error with/without
enabling AltiVec, so I also don't think this should be suspended until support
e6500 in kvm since kvm based on e5500 should work.
Tiejun
> in progress) but we need first to pull e6500 kernel patches from
> Linux tree into agraf.git.
>
> -Mike
>
>
>
>
>
>
>
>
^ permalink raw reply
* Re: "attempt to move .org backwards" still show up
From: Mike Qiu @ 2013-04-26 1:58 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <51791076.9040405@asianux.com>
于 2013/4/25 19:16, Chen Gang 写道:
> On 2013年04月25日 14:25, Paul Mackerras wrote:
>> On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
>>>> This has block my work now
>>>> So I hope you can take a look ASAP
>>>> Thanks
>>>> :)
>>>>
>>>> Mike
>> As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
>> the immediate problem.
> Yes, just as my original reply to Mike to bypass it, but get no reply, I
> guess he has to face the CONFIG_KVM_BOOK3S_64_PR.
>
> Now, I am just fixing it, when I finish one patch, please help check.
Actually, I have compile pass by your patch, but I see Micheal Neuling's
reply,
I just stop to do that, and wait for you new patch :)
Now I will use your V2 patch to build
Thanks
Mike
> Thanks.
>
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Mike Qiu @ 2013-04-26 2:03 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179DA23.8000407@asianux.com>
于 2013/4/26 9:36, Chen Gang 写道:
> On 2013年04月26日 09:18, Chen Gang wrote:
>> On 2013年04月26日 09:06, Chen Gang wrote:
>>>> CFAR is the Come From Register. It saves the location of the last
>>>>> branch and is hence overwritten by any branch.
>>>>>
>>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>>> . = 0x900
>>> .globl decrementer_pSeries
>>> decrementer_pSeries:
>>> HMT_MEDIUM_PPR_DISCARD
>>> SET_SCRATCH0(r13)
>>> b decrementer_pSeries_0
>>>
>>> ...
>>>
>>>
> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
I will try your diff V2, to see if the machine can boot up
> ---------------------------------diff v2 begin-----------------------------
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index e789ee7..f0489c4 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -254,7 +254,15 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + HMT_MEDIUM_PPR_DISCARD
> + SET_SCRATCH0(r13) /* save r13 */
> + EXCEPTION_PROLOG_0(PACA_EXGEN)
> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
> + b decrementer_pSeries_0
> +
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
> @@ -536,6 +544,11 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
> #endif
>
> .align 7
> + /* moved from 0x900 */
> +decrementer_pSeries_0:
> + EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
> +
> + .align 7
> /* moved from 0xe00 */
> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
>
>
> ---------------------------------diff v2 end-------------------------------
>
>
>> Such as the fix below, is it OK (just like 0x300 or 0x200 has done) ?
>>
>> Please check, thanks.
>>
>> ---------------------------diff begin-------------------------------------
>>
>> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
>> index e789ee7..a0a5ff2 100644
>> --- a/arch/powerpc/kernel/exceptions-64s.S
>> +++ b/arch/powerpc/kernel/exceptions-64s.S
>> @@ -254,7 +254,14 @@ hardware_interrupt_hv:
>> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
>> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>>
>> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
>> + . = 0x900
>> + .globl decrementer_pSeries
>> +decrementer_pSeries:
>> + HMT_MEDIUM_PPR_DISCARD
>> + SET_SCRATCH0(r13) /* save r13 */
>> + EXCEPTION_PROLOG_0(PACA_EXGEN)
>> + b decrementer_pSeries_0
>> +
>> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>>
>> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
>> @@ -536,6 +543,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
>> #endif
>>
>> .align 7
>> + /* moved from 0x900 */
>> +decrementer_pSeries_0:
>> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
>> + EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
>> +
>> + .align 7
>> /* moved from 0xe00 */
>> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
>> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
>>
>> ---------------------------diff end---------------------------------------
>>
>
^ permalink raw reply
* Re: "attempt to move .org backwards" still show up
From: Chen Gang @ 2013-04-26 2:05 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179DF37.8020407@linux.vnet.ibm.com>
On 2013年04月26日 09:58, Mike Qiu wrote:
> 于 2013/4/25 19:16, Chen Gang 写道:
>> On 2013年04月25日 14:25, Paul Mackerras wrote:
>>> On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
>>>>> This has block my work now
>>>>> So I hope you can take a look ASAP
>>>>> Thanks
>>>>> :)
>>>>>
>>>>> Mike
>>> As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
>>> the immediate problem.
>> Yes, just as my original reply to Mike to bypass it, but get no reply, I
>> guess he has to face the CONFIG_KVM_BOOK3S_64_PR.
>>
>> Now, I am just fixing it, when I finish one patch, please help check.
> Actually, I have compile pass by your patch, but I see Micheal Neuling's
> reply,
> I just stop to do that, and wait for you new patch :)
>
I am just continuing (before get fixed, I should continue)
> Now I will use your V2 patch to build
Please see the discussion of patch v2, it still has another issues, but
I am still trying (I guess Michael is just checking).
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 2:06 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179E056.2000709@linux.vnet.ibm.com>
On 2013年04月26日 10:03, Mike Qiu wrote:
> �� 2013/4/26 9:36, Chen Gang �:
>> > On 2013��04��26�� 09:18, Chen Gang wrote:
>>> >> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>> >>>> CFAR is the Come From Register. It saves the location of the last
>>>>>> >>>>> branch and is hence overwritten by any branch.
>>>>>> >>>>>
>>>> >>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>>>> >>> . = 0x900
>>>> >>> .globl decrementer_pSeries
>>>> >>> decrementer_pSeries:
>>>> >>> HMT_MEDIUM_PPR_DISCARD
>>>> >>> SET_SCRATCH0(r13)
>>>> >>> b decrementer_pSeries_0
>>>> >>>
>>>> >>> ...
>>>> >>>
>>>> >>>
>> > Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>> > with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
> I will try your diff V2, to see if the machine can boot up
OK, thanks. (hope it can work)
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* RE: [PATCH 1/2] powerpc: Move opcode definitions from kvm/emulate.c to asm/ppc-opcode.h
From: Jia Hongtao-B38951 @ 2013-04-26 2:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1366777161.2869.0.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogV2VkbmVz
ZGF5LCBBcHJpbCAyNCwgMjAxMyAxMjoxOSBQTQ0KPiBUbzogSmlhIEhvbmd0YW8tQjM4OTUxDQo+
IENjOiBNaWNoYWVsIEVsbGVybWFuOyBXb29kIFNjb3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzJdIHBvd2VycGM6IE1vdmUg
b3Bjb2RlIGRlZmluaXRpb25zIGZyb20NCj4ga3ZtL2VtdWxhdGUuYyB0byBhc20vcHBjLW9wY29k
ZS5oDQo+IA0KPiBPbiBUdWUsIDIwMTMtMDQtMjMgYXQgMDY6MzYgKzAwMDAsIEppYSBIb25ndGFv
LUIzODk1MSB3cm90ZToNCj4gPiBUaGVzZSBkZWZpbml0aW9ucyBhcmUgZmlyc3RseSB1c2VkIGJ5
IEtWTSBkZWZpbmVkIGxpa2UgT1BfMzFfWE9QX1RSQVAuDQo+ID4gVHdvIHdheXMgdG8gZXh0cmFj
dCB0aGVzZSBkZWZpbml0aW9ucyBmb3IgcHVibGljIHVzZToNCj4gPg0KPiA+IDEuIExpa2UgdGhp
cyBwYXRjaCBkaWQuIEZvciBrZWVwaW5nIHRoZSBLVk0gY29kZSB0aGF0IHVzaW5nIHRoZXNlDQo+
ID4gICAgZGVmaW5pdGlvbnMgdW5jaGFuZ2VkIHdlIGRvIG5vdCB1cGRhdGUgdGhlbSB0byBtYXRj
aC4NCj4gPg0KPiA+IDIuIE1vdmUgdGhlc2UgZGVmaW5pdGlvbnMgdG8gYW5vdGhlciAuaCBmaWxl
IGxpa2UgbXkgbGFzdCBwYXRjaCBkaWQ6DQo+ID4gICAgaHR0cDovL3BhdGNod29yay5vemxhYnMu
b3JnL3BhdGNoLzIzNTY0Ni8NCj4gPiAgICBZb3UgY2FuIHNlZSB0aGUgY29tbWVudHMgdGhlcmUu
DQo+IA0KPiBUaGVyZSdzIGEgYmV0dGVyIHdheSAuLi4gYnV0IGl0J3MgbW9yZSB3b3JrLg0KPiAN
Cj4gQWxsIG9wY29kZXMgYXJlIGJhc2VkIG9uIGEgcHJpbWFyeSBvcGNvZGUgYW5kIGEgcG90ZW50
aWFsIHNlY29uZGFyeQ0KPiBvcGNvZGUuIFlvdSBjb3VsZC9zaG91bGQgcmV3b3JrIHBwYy1vcGNv
ZGVzLmggdG8gaW4gZmFjdCBkZWZpbmUgdGhlbQ0KPiBhbGwgdGhhdCB3YXkgYXMgd2VsbCwgd2hp
Y2ggd291bGQgInJlY29uY2lsZSIgdGhlIEtWTSB3YXkgYW5kIHRoZQ0KPiBleGlzdGluZyBzdHVm
Zi4NCj4gDQo+IENoZWVycywNCj4gQmVuLg0KPiANCg0KQWdyZWUuIEJ1dCBJJ20gYWZyYWlkIHRv
IHNheSB0aGF0IEknbSB0b28gYnVzeSB0byBkbyB0aGlzICJtb3JlIHdvcmsiDQpyaWdodCBub3cu
IENvdWxkIHdlIGRlZmVyIHRoaXMgd29yayBmb3Igc29tZSB0aW1lPw0KDQpUaGFua3MuDQotIEhv
bmd0YW8NCg==
^ permalink raw reply
* Re: [PATCH v4 2/13] Correct buffer parsing in update_dt_node()
From: Stephen Rothwell @ 2013-04-26 3:01 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <5177FF10.4000508@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
Hi Nathan,
On Wed, 24 Apr 2013 10:49:36 -0500 Nathan Fontenot <nfont@linux.vnet.ibm.com> wrote:
>
> @@ -134,6 +134,7 @@
> char *prop_data;
> char *rtas_buf;
> int update_properties_token;
> + u32 vd;
>
> update_properties_token = rtas_token("ibm,update-properties");
> if (update_properties_token == RTAS_UNKNOWN_SERVICE)
> @@ -160,13 +161,24 @@
>
> prop_data = rtas_buf + sizeof(*upwa);
>
> - for (i = 0; i < upwa->nprops; i++) {
> + /* The first element of the buffer is the path of the node
> + * being updated in the form of a 8 byte string length
^^^^
"bit" ?
> + * followed by the string. Skip past this to get to the
> + * properties being updated.
> + */
> + vd = *prop_data++;
> + prop_data += vd;
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/13] Use ARRAY_SIZE to iterate over firmware_features_table array
From: Stephen Rothwell @ 2013-04-26 3:08 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <5178005C.1070204@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
Hi Nathan,
On Wed, 24 Apr 2013 10:55:08 -0500 Nathan Fontenot <nfont@linux.vnet.ibm.com> wrote:
>
> When iterating over the entries in firmware_features_table we only need
> to go over the actual number of entries in the array instead of declaring
> it to be bigger and checking to make sure there is a valid entry in every
> slot.
>
> This patch removes the FIRMWARE_MAX_FEATURES #define and replaces the
> array looping with the use of ARRAY_SIZE().
>
Suggested-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> @@ -77,12 +77,10 @@
> pr_debug(" -> fw_feature_init()\n");
>
> for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) {
> - for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) {
> + for (i = 0; i < ARRAY_SIZE(firmware_features_table); i++) {
You should explicitly include linux/kernel.h to use ARRAY_SIZE().
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Mike Qiu @ 2013-04-26 3:08 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179E11F.8010007@asianux.com>
于 2013/4/26 10:06, Chen Gang 写道:
> On 2013年04月26日 10:03, Mike Qiu wrote:
>> �� 2013/4/26 9:36, Chen Gang �:
>>>> On 2013��04��26�� 09:18, Chen Gang wrote:
>>>>>> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>>>>>>> CFAR is the Come From Register. It saves the location of the last
>>>>>>>>>>>> branch and is hence overwritten by any branch.
>>>>>>>>>>>>
>>>>>>>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>>>>>>>> . = 0x900
>>>>>>>> .globl decrementer_pSeries
>>>>>>>> decrementer_pSeries:
>>>>>>>> HMT_MEDIUM_PPR_DISCARD
>>>>>>>> SET_SCRATCH0(r13)
>>>>>>>> b decrementer_pSeries_0
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>>>> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
>> I will try your diff V2, to see if the machine can boot up
> OK, thanks. (hope it can work)
It seems that the machine can be bootup in powernv mode, but I'm not
sure if my machine call that module.
At lease my machine can boot up
Thanks
Mike
>
> :-)
>
^ permalink raw reply
* Re: [PATCH V4 0/5] powerpc, perf: BHRB based branch stack enablement on POWER8
From: Michael Neuling @ 2013-04-26 3:11 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1366695764-3073-1-git-send-email-khandual@linux.vnet.ibm.com>
Anshuman,
IIRC there are new bits in the FSCR and HFSCR you need to enable for the
PMU and BRHB. Can you please check these are enabled?
Mikey
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote:
> Branch History Rolling Buffer (BHRB) is a new PMU feaure in IBM
> POWER8 processor which records the branch instructions inside the execution
> pipeline. This patchset enables the basic functionality of the feature through
> generic perf branch stack sampling framework.
>
> Sample output
> -------------
> $./perf record -b top
> $./perf report
>
> Overhead Command Source Shared Object Source Symbol Target Shared Object Target Symbol
> # ........ ....... .................... ...................................... .................... ...................................
> #
>
> 7.82% top libc-2.11.2.so [k] _IO_vfscanf libc-2.11.2.so [k] _IO_vfscanf
> 6.17% top libc-2.11.2.so [k] _IO_vfscanf [unknown] [k] 00000000
> 2.37% top [unknown] [k] 0xf7aafb30 [unknown] [k] 00000000
> 1.80% top [unknown] [k] 0x0fe07978 libc-2.11.2.so [k] _IO_vfscanf
> 1.60% top libc-2.11.2.so [k] _IO_vfscanf [kernel.kallsyms] [k] .do_task_stat
> 1.20% top [kernel.kallsyms] [k] .do_task_stat [kernel.kallsyms] [k] .do_task_stat
> 1.02% top libc-2.11.2.so [k] vfprintf libc-2.11.2.so [k] vfprintf
> 0.92% top top [k] _init [unknown] [k] 0x0fe037f4
>
> Changes in V2
> --------------
> - Added copyright messages to the newly created files
> - Modified couple of commit messages
>
> Changes in V3
> -------------
> - Incorporated review comments from Segher https://lkml.org/lkml/2013/4/16/350
> - Worked on a solution for review comment from Michael Ellerman https://lkml.org/lkml/2013/4/17/548
> - Could not move updated cpu_hw_events structure from core-book3s.c file into perf_event_server.h
> Because perf_event_server.h is pulled in first inside linux/perf_event.h before the definition of
> perf_branch_entry structure. Thats the reason why perf_branch_entry definition is not available
> inside perf_event_server.h where we define the array inside cpu_hw_events structure.
>
> - Finally have pulled in the code from perf_event_bhrb.c into core-book3s.c
>
> - Improved documentation for the patchset
>
> Changes in V4
> -------------
> - Incorporated review comments on V3 regarding new instruction encoding
>
> Anshuman Khandual (5):
> powerpc, perf: Add new BHRB related instructions for POWER8
> powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
> powerpc, perf: Add new BHRB related generic functions, data and flags
> powerpc, perf: Define BHRB generic functions, data and flags for POWER8
> powerpc, perf: Enable branch stack sampling framework
>
> arch/powerpc/include/asm/perf_event_server.h | 7 ++
> arch/powerpc/include/asm/ppc-opcode.h | 8 ++
> arch/powerpc/perf/Makefile | 2 +-
> arch/powerpc/perf/bhrb.S | 44 +++++++
> arch/powerpc/perf/core-book3s.c | 167 ++++++++++++++++++++++++++-
> arch/powerpc/perf/power8-pmu.c | 57 ++++++++-
> 6 files changed, 280 insertions(+), 5 deletions(-)
> create mode 100644 arch/powerpc/perf/bhrb.S
>
> --
> 1.7.11.7
>
^ permalink raw reply
* Re: "attempt to move .org backwards" still show up
From: Mike Qiu @ 2013-04-26 3:19 UTC (permalink / raw)
To: Paul Mackerras
Cc: sfr, Michael Neuling, matt, Chen Gang, linux-kernel,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20130425062539.GA421@iris.ozlabs.ibm.com>
于 2013/4/25 14:25, Paul Mackerras 写道:
> On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
>> This has block my work now
>> So I hope you can take a look ASAP
>> Thanks
>> :)
>>
>> Mike
> As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
> the immediate problem.
Thanks
got it, I will have a try.
> Paul.
>
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 3:25 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179EFB6.3090602@linux.vnet.ibm.com>
On 2013年04月26日 11:08, Mike Qiu wrote:
> 于 2013/4/26 10:06, Chen Gang 写道:
>> On 2013年04月26日 10:03, Mike Qiu wrote:
>>> �� 2013/4/26 9:36, Chen Gang �:
>>>>> On 2013��04��26�� 09:18, Chen Gang wrote:
>>>>>>> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>>>>>>>> CFAR is the Come From Register. It saves the location of the
>>>>>>>>>>> last
>>>>>>>>>>>>> branch and is hence overwritten by any branch.
>>>>>>>>>>>>>
>>>>>>>>> Do we process it just like others done (e.g. 0x300, 0xe00,
>>>>>>>>> 0xe20 ...) ?
>>>>>>>>> . = 0x900
>>>>>>>>> .globl decrementer_pSeries
>>>>>>>>> decrementer_pSeries:
>>>>>>>>> HMT_MEDIUM_PPR_DISCARD
>>>>>>>>> SET_SCRATCH0(r13)
>>>>>>>>> b decrementer_pSeries_0
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>
>>>>> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>>>>> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
>>> I will try your diff V2, to see if the machine can boot up
>> OK, thanks. (hope it can work)
> It seems that the machine can be bootup in powernv mode, but I'm not
> sure if my machine call that module.
>
> At lease my machine can boot up
Thank you for your information !
I have checked the disassemble by powerpc64-linux-gnu-objdump, it seems
all we have done for 0x900 is almost like the original done for 0x200.
I am just learning about the CFAR (google it), And I plan to wait for a
day, if all things go smoothly, I will send patch v3.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 3:42 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179F39C.5020408@asianux.com>
On 2013年04月26日 11:25, Chen Gang wrote:
> On 2013年04月26日 11:08, Mike Qiu wrote:
>> 于 2013/4/26 10:06, Chen Gang 写道:
>>> On 2013年04月26日 10:03, Mike Qiu wrote:
>>>> �� 2013/4/26 9:36, Chen Gang �:
>>>>>> On 2013��04��26�� 09:18, Chen Gang wrote:
>>>>>>>> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>>>>>>>>> CFAR is the Come From Register. It saves the location of the
>>>>>>>>>>>> last
>>>>>>>>>>>>>> branch and is hence overwritten by any branch.
>>>>>>>>>>>>>>
>>>>>>>>>> Do we process it just like others done (e.g. 0x300, 0xe00,
>>>>>>>>>> 0xe20 ...) ?
>>>>>>>>>> . = 0x900
>>>>>>>>>> .globl decrementer_pSeries
>>>>>>>>>> decrementer_pSeries:
>>>>>>>>>> HMT_MEDIUM_PPR_DISCARD
>>>>>>>>>> SET_SCRATCH0(r13)
>>>>>>>>>> b decrementer_pSeries_0
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>>
>>>>>> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>>>>>> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
>>>> I will try your diff V2, to see if the machine can boot up
>>> OK, thanks. (hope it can work)
>> It seems that the machine can be bootup in powernv mode, but I'm not
>> sure if my machine call that module.
>>
>> At lease my machine can boot up
>
Please reference commit number: 1707dd161349e6c54170c88d94fed012e3d224e3
(1707dd1 powerpc: Save CFAR before branching in interrupt entry paths)
What our diff v2 has done is just the fix for our patch v2 (just like
the commit 1707dd1 has done).
Please check, thanks.
:-)
> Thank you for your information !
>
> I have checked the disassemble by powerpc64-linux-gnu-objdump, it seems
> all we have done for 0x900 is almost like the original done for 0x200.
>
> I am just learning about the CFAR (google it), And I plan to wait for a
> day, if all things go smoothly, I will send patch v3.
>
>
> :-)
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH] powerpc: Fix "attempt to move .org backwards" error
From: Paul Mackerras @ 2013-04-26 3:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Chen Gang, Mike Qiu
Building a 64-bit powerpc kernel with PR KVM enabled currently gives
this error:
AS arch/powerpc/kernel/head_64.o
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:258: Error: attempt to move .org backwards
make[2]: *** [arch/powerpc/kernel/head_64.o] Error 1
This happens because the MASKABLE_EXCEPTION_PSERIES macro turns into
33 instructions, but we only have space for 32 at the decrementer
interrupt vector (from 0x900 to 0x980).
In the code generated by the MASKABLE_EXCEPTION_PSERIES macro, we
currently have two instances of the HMT_MEDIUM macro, which has the
effect of setting the SMT thread priority to medium. One is the
first instruction, and is overwritten by a no-op on processors where
we save the PPR (processor priority register), that is, POWER7 or
later. The other is after we have saved the PPR.
In order to reduce the code at 0x900 by one instruction, we omit the
first HMT_MEDIUM. On processors without SMT this will have no effect
since HMT_MEDIUM is a no-op there. On POWER5 and RS64 machines this
will mean that the first few instructions take a little longer in the
case where a decrementer interrupt occurs when the hardware thread is
running at low SMT priority. On POWER6 and later machines, the
hardware automatically boosts the thread priority when a decrementer
interrupt is taken if the thread priority was below medium, so this
change won't make any difference.
The alternative would be to branch out of line after saving the CFAR.
However, that would incur an extra overhead on all processors, whereas
the approach adopted here only adds overhead on older threaded processors.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/kernel/exceptions-64s.S | 7 ++++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 05e6d2e..8e5fae8 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -414,7 +414,6 @@ label##_relon_hv: \
#define SOFTEN_NOTEST_HV(vec) _SOFTEN_TEST(EXC_HV, vec)
#define __MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra) \
- HMT_MEDIUM_PPR_DISCARD; \
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(PACA_EXGEN); \
__EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec); \
@@ -427,6 +426,7 @@ label##_relon_hv: \
. = loc; \
.globl label##_pSeries; \
label##_pSeries: \
+ HMT_MEDIUM_PPR_DISCARD; \
_MASKABLE_EXCEPTION_PSERIES(vec, label, \
EXC_STD, SOFTEN_TEST_PR)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 56bd923..574db3f 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -235,6 +235,7 @@ instruction_access_slb_pSeries:
.globl hardware_interrupt_hv;
hardware_interrupt_pSeries:
hardware_interrupt_hv:
+ HMT_MEDIUM_PPR_DISCARD
BEGIN_FTR_SECTION
_MASKABLE_EXCEPTION_PSERIES(0x502, hardware_interrupt,
EXC_HV, SOFTEN_TEST_HV)
@@ -254,7 +255,11 @@ hardware_interrupt_hv:
STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
- MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
+ . = 0x900
+ .globl decrementer_pSeries
+decrementer_pSeries:
+ _MASKABLE_EXCEPTION_PSERIES(0x900, decrementer, EXC_STD, SOFTEN_TEST_PR)
+
STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Mike Qiu @ 2013-04-26 3:54 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179F7B8.5010701@asianux.com>
于 2013/4/26 11:42, Chen Gang 写道:
> On 2013年04月26日 11:25, Chen Gang wrote:
>> On 2013年04月26日 11:08, Mike Qiu wrote:
>>> 于 2013/4/26 10:06, Chen Gang 写道:
>>>> On 2013年04月26日 10:03, Mike Qiu wrote:
>>>>> �� 2013/4/26 9:36, Chen Gang �:
>>>>>>> On 2013��04��26�� 09:18, Chen Gang wrote:
>>>>>>>>> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>>>>>>>>>> CFAR is the Come From Register. It saves the location of the
>>>>>>>>>>>>> last
>>>>>>>>>>>>>>> branch and is hence overwritten by any branch.
>>>>>>>>>>>>>>>
>>>>>>>>>>> Do we process it just like others done (e.g. 0x300, 0xe00,
>>>>>>>>>>> 0xe20 ...) ?
>>>>>>>>>>> . = 0x900
>>>>>>>>>>> .globl decrementer_pSeries
>>>>>>>>>>> decrementer_pSeries:
>>>>>>>>>>> HMT_MEDIUM_PPR_DISCARD
>>>>>>>>>>> SET_SCRATCH0(r13)
>>>>>>>>>>> b decrementer_pSeries_0
>>>>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>>>>>>> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
>>>>> I will try your diff V2, to see if the machine can boot up
>>>> OK, thanks. (hope it can work)
>>> It seems that the machine can be bootup in powernv mode, but I'm not
>>> sure if my machine call that module.
>>>
>>> At lease my machine can boot up
> Please reference commit number: 1707dd161349e6c54170c88d94fed012e3d224e3
> (1707dd1 powerpc: Save CFAR before branching in interrupt entry paths)
>
> What our diff v2 has done is just the fix for our patch v2 (just like
> the commit 1707dd1 has done).
>
> Please check, thanks.
>
> :-)
I will check this evening or tomorrow, I have something else to do this
afteroon.
>> Thank you for your information !
>>
>> I have checked the disassemble by powerpc64-linux-gnu-objdump, it seems
>> all we have done for 0x900 is almost like the original done for 0x200.
>>
>> I am just learning about the CFAR (google it), And I plan to wait for a
>> day, if all things go smoothly, I will send patch v3.
>>
>>
>> :-)
>>
>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error
From: Chen Gang @ 2013-04-26 4:13 UTC (permalink / raw)
To: Paul Mackerras, Mike Qiu
Cc: linuxppc-dev, Michael Neuling, sfr@canb.auug.org.au
In-Reply-To: <20130426035140.GA5796@drongo>
On 2013年04月26日 11:51, Paul Mackerras wrote:
> Building a 64-bit powerpc kernel with PR KVM enabled currently gives
> this error:
>
> AS arch/powerpc/kernel/head_64.o
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:258: Error: attempt to move .org backwards
> make[2]: *** [arch/powerpc/kernel/head_64.o] Error 1
>
> This happens because the MASKABLE_EXCEPTION_PSERIES macro turns into
> 33 instructions, but we only have space for 32 at the decrementer
> interrupt vector (from 0x900 to 0x980).
>
> In the code generated by the MASKABLE_EXCEPTION_PSERIES macro, we
> currently have two instances of the HMT_MEDIUM macro, which has the
> effect of setting the SMT thread priority to medium. One is the
> first instruction, and is overwritten by a no-op on processors where
> we save the PPR (processor priority register), that is, POWER7 or
> later. The other is after we have saved the PPR.
>
> In order to reduce the code at 0x900 by one instruction, we omit the
> first HMT_MEDIUM. On processors without SMT this will have no effect
> since HMT_MEDIUM is a no-op there. On POWER5 and RS64 machines this
> will mean that the first few instructions take a little longer in the
> case where a decrementer interrupt occurs when the hardware thread is
> running at low SMT priority. On POWER6 and later machines, the
> hardware automatically boosts the thread priority when a decrementer
> interrupt is taken if the thread priority was below medium, so this
> change won't make any difference.
>
> The alternative would be to branch out of line after saving the CFAR.
> However, that would incur an extra overhead on all processors, whereas
> the approach adopted here only adds overhead on older threaded processors.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
Hello Mike:
Please try Paul's patch, firstly.
:-)
Thanks.
> arch/powerpc/include/asm/exception-64s.h | 2 +-
> arch/powerpc/kernel/exceptions-64s.S | 7 ++++++-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
> index 05e6d2e..8e5fae8 100644
> --- a/arch/powerpc/include/asm/exception-64s.h
> +++ b/arch/powerpc/include/asm/exception-64s.h
> @@ -414,7 +414,6 @@ label##_relon_hv: \
> #define SOFTEN_NOTEST_HV(vec) _SOFTEN_TEST(EXC_HV, vec)
>
> #define __MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra) \
> - HMT_MEDIUM_PPR_DISCARD; \
> SET_SCRATCH0(r13); /* save r13 */ \
> EXCEPTION_PROLOG_0(PACA_EXGEN); \
> __EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec); \
> @@ -427,6 +426,7 @@ label##_relon_hv: \
> . = loc; \
> .globl label##_pSeries; \
> label##_pSeries: \
> + HMT_MEDIUM_PPR_DISCARD; \
> _MASKABLE_EXCEPTION_PSERIES(vec, label, \
> EXC_STD, SOFTEN_TEST_PR)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 56bd923..574db3f 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -235,6 +235,7 @@ instruction_access_slb_pSeries:
> .globl hardware_interrupt_hv;
> hardware_interrupt_pSeries:
> hardware_interrupt_hv:
> + HMT_MEDIUM_PPR_DISCARD
> BEGIN_FTR_SECTION
> _MASKABLE_EXCEPTION_PSERIES(0x502, hardware_interrupt,
> EXC_HV, SOFTEN_TEST_HV)
> @@ -254,7 +255,11 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + _MASKABLE_EXCEPTION_PSERIES(0x900, decrementer, EXC_STD, SOFTEN_TEST_PR)
> +
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH v4 0/6] powerpc/powernv: PHB3 Support
From: Gavin Shan @ 2013-04-26 5:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
The patchset includes minimal support for PHB3. Initially, flag "PNV_PHB_IODA2"
is introduced to differentiate IODA2 compliant PHB3 from other types of PHBs and
do initialization accordingly for PHB3. Besides, variable IODA2 tables reside in
system memory and we allocate them in kernel, then pass them to f/w and enable
the corresponding BARs through OPAL API. The P/Q bits of IVE should be handled
on PHB3 by software and the patchset intends to cover that as well.
NOTE: The first patch comes from Ben.
v3 -> v4
* Remove the patch to retrieve IODA2 table address/length since
it's useless now
* Introduce IRQ chip for individual PHB and patch the handlers
during MSI interrupt setup time according to Ben's suggestion
* Pass HW IRQ to opal_pci_msi_eoi()
* Remove "sysdata" from IOMMU table
v2 -> v3
* Remove the unnecessary quirk. That's only useful with simics
* Do MSI EOI in single OPAL API opal_pci_msi_eoi()
* Use explicit branch to fully utilize CPU's prefetching engine
while doing TCE invalidation
* Add one patch to fix invalid IOMMU table for PCI devices
v1 -> v2
* Introduce CONFIG_POWERNV_MSI, which is similiar to CONFIG_PSERIES_MSI
* Enable CONFIG_PPC_MSI_BITMAP while selecting CONFIG_POWERNV_MSI
* Eleminate (struct pnv_phb::msi_count) since it has been removed in
linux-next
* Replace (CONFIG_PPC_POWERNV && CONFIG_PCI_MSI) with CONFIG_POWERNV_MSI
* Move declaration of pnv_pci_msi_eoi() to asm/xics.h
* Remove unnecessary "#ifdef ... #endif" in icp-native.c
* Add support to invalidate TCE
* Let the IODA2 table allocated by firmware and kernel to retrieve them
through device-tree
---
arch/powerpc/include/asm/opal.h | 7 +-
arch/powerpc/include/asm/xics.h | 1 +
arch/powerpc/platforms/powernv/Kconfig | 5 +
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
arch/powerpc/platforms/powernv/pci-ioda.c | 330 ++++++++++++++++++++----
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 4 +-
arch/powerpc/platforms/powernv/pci.c | 56 +----
arch/powerpc/platforms/powernv/pci.h | 35 ++-
arch/powerpc/sysdev/Kconfig | 1 +
arch/powerpc/sysdev/xics/icp-native.c | 2 +-
10 files changed, 332 insertions(+), 110 deletions(-)
Thanks,
Gavin
^ permalink raw reply
* [PATCH 2/6] powerpc/powernv: Add option CONFIG_POWERNV_MSI
From: Gavin Shan @ 2013-04-26 5:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1366953662-9473-1-git-send-email-shangw@linux.vnet.ibm.com>
As Michael Ellerman suggested, to add CONFIG_POWERNV_MSI for PowerNV
platform. That's similar to CONFIG_PSERIES_MSI for pSeries platform.
For now, we don't make it dependent on CONFIG_EEH since it's not ready
to enable that yet.
Apart from that, we also enable CONFIG_PPC_MSI_BITMAP on selecting
CONFIG_POWERNV_MSI.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/Kconfig | 5 +++++
arch/powerpc/sysdev/Kconfig | 1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
index 74fea5c..d3e840d 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -8,6 +8,11 @@ config PPC_POWERNV
select PPC_PCI_CHOICE if EMBEDDED
default y
+config POWERNV_MSI
+ bool "Support PCI MSI on PowerNV platform"
+ depends on PCI_MSI
+ default y
+
config PPC_POWERNV_RTAS
depends on PPC_POWERNV
bool "Support for RTAS based PowerNV platforms such as BML"
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index a84fecf..ab4cb54 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -19,6 +19,7 @@ config PPC_MSI_BITMAP
default y if MPIC
default y if FSL_PCI
default y if PPC4xx_MSI
+ default y if POWERNV_MSI
source "arch/powerpc/sysdev/xics/Kconfig"
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/6] powerpc/powernv: Supports PHB3
From: Gavin Shan @ 2013-04-26 5:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1366953662-9473-1-git-send-email-shangw@linux.vnet.ibm.com>
The patch intends to initialize PHB3 during system boot stage. The
flag "PNV_PHB_MODEL_PHB3" is introduced to differentiate IODA2
compatible PHB3 from other types of PHBs.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 62 +++++++++++++++--------------
arch/powerpc/platforms/powernv/pci.c | 6 ++-
arch/powerpc/platforms/powernv/pci.h | 8 ++-
3 files changed, 42 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index a5c5f15..3d4e958 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -852,18 +852,19 @@ static u32 pnv_ioda_bdfn_to_pe(struct pnv_phb *phb, struct pci_bus *bus,
return phb->ioda.pe_rmap[(bus->number << 8) | devfn];
}
-void __init pnv_pci_init_ioda1_phb(struct device_node *np)
+void __init pnv_pci_init_ioda_phb(struct device_node *np, int ioda_type)
{
struct pci_controller *hose;
static int primary = 1;
struct pnv_phb *phb;
unsigned long size, m32map_off, iomap_off, pemap_off;
const u64 *prop64;
+ const u32 *prop32;
u64 phb_id;
void *aux;
long rc;
- pr_info(" Initializing IODA OPAL PHB %s\n", np->full_name);
+ pr_info(" Initializing IODA%d OPAL PHB %s\n", ioda_type, np->full_name);
prop64 = of_get_property(np, "ibm,opal-phbid", NULL);
if (!prop64) {
@@ -890,37 +891,34 @@ void __init pnv_pci_init_ioda1_phb(struct device_node *np)
hose->last_busno = 0xff;
hose->private_data = phb;
phb->opal_id = phb_id;
- phb->type = PNV_PHB_IODA1;
+ phb->type = ioda_type;
/* Detect specific models for error handling */
if (of_device_is_compatible(np, "ibm,p7ioc-pciex"))
phb->model = PNV_PHB_MODEL_P7IOC;
+ else if (of_device_is_compatible(np, "ibm,p8-pciex"))
+ phb->model = PNV_PHB_MODEL_PHB3;
else
phb->model = PNV_PHB_MODEL_UNKNOWN;
- /* We parse "ranges" now since we need to deduce the register base
- * from the IO base
- */
+ /* Parse 32-bit and IO ranges (if any) */
pci_process_bridge_OF_ranges(phb->hose, np, primary);
primary = 0;
- /* Magic formula from Milton */
+ /* Get registers */
phb->regs = of_iomap(np, 0);
if (phb->regs == NULL)
pr_err(" Failed to map registers !\n");
-
- /* XXX This is hack-a-thon. This needs to be changed so that:
- * - we obtain stuff like PE# etc... from device-tree
- * - we properly re-allocate M32 ourselves
- * (the OFW one isn't very good)
- */
-
/* Initialize more IODA stuff */
- phb->ioda.total_pe = 128;
+ prop32 = of_get_property(np, "ibm,opal-num-pes", NULL);
+ if (!prop32)
+ phb->ioda.total_pe = 1;
+ else
+ phb->ioda.total_pe = *prop32;
phb->ioda.m32_size = resource_size(&hose->mem_resources[0]);
- /* OFW Has already off top 64k of M32 space (MSI space) */
+ /* FW Has already off top 64k of M32 space (MSI space) */
phb->ioda.m32_size += 0x10000;
phb->ioda.m32_segsize = phb->ioda.m32_size / phb->ioda.total_pe;
@@ -930,7 +928,10 @@ void __init pnv_pci_init_ioda1_phb(struct device_node *np)
phb->ioda.io_segsize = phb->ioda.io_size / phb->ioda.total_pe;
phb->ioda.io_pci_base = 0; /* XXX calculate this ? */
- /* Allocate aux data & arrays */
+ /* Allocate aux data & arrays
+ *
+ * XXX TODO: Don't allocate io segmap on PHB3
+ */
size = _ALIGN_UP(phb->ioda.total_pe / 8, sizeof(unsigned long));
m32map_off = size;
size += phb->ioda.total_pe * sizeof(phb->ioda.m32_segmap[0]);
@@ -960,7 +961,7 @@ void __init pnv_pci_init_ioda1_phb(struct device_node *np)
hose->mem_resources[2].start = 0;
hose->mem_resources[2].end = 0;
-#if 0
+#if 0 /* We should really do that ... */
rc = opal_pci_set_phb_mem_window(opal->phb_id,
window_type,
window_num,
@@ -974,16 +975,6 @@ void __init pnv_pci_init_ioda1_phb(struct device_node *np)
phb->ioda.m32_size, phb->ioda.m32_segsize,
phb->ioda.io_size, phb->ioda.io_segsize);
- if (phb->regs) {
- pr_devel(" BUID = 0x%016llx\n", in_be64(phb->regs + 0x100));
- pr_devel(" PHB2_CR = 0x%016llx\n", in_be64(phb->regs + 0x160));
- pr_devel(" IO_BAR = 0x%016llx\n", in_be64(phb->regs + 0x170));
- pr_devel(" IO_BAMR = 0x%016llx\n", in_be64(phb->regs + 0x178));
- pr_devel(" IO_SAR = 0x%016llx\n", in_be64(phb->regs + 0x180));
- pr_devel(" M32_BAR = 0x%016llx\n", in_be64(phb->regs + 0x190));
- pr_devel(" M32_BAMR = 0x%016llx\n", in_be64(phb->regs + 0x198));
- pr_devel(" M32_SAR = 0x%016llx\n", in_be64(phb->regs + 0x1a0));
- }
phb->hose->ops = &pnv_pci_ops;
/* Setup RID -> PE mapping function */
@@ -1011,7 +1002,18 @@ void __init pnv_pci_init_ioda1_phb(struct device_node *np)
rc = opal_pci_reset(phb_id, OPAL_PCI_IODA_TABLE_RESET, OPAL_ASSERT_RESET);
if (rc)
pr_warning(" OPAL Error %ld performing IODA table reset !\n", rc);
- opal_pci_set_pe(phb_id, 0, 0, 7, 1, 1 , OPAL_MAP_PE);
+
+ /*
+ * On IODA1 map everything to PE#0, on IODA2 we assume the IODA reset
+ * has cleared the RTT which has the same effect
+ */
+ if (ioda_type == PNV_PHB_IODA1)
+ opal_pci_set_pe(phb_id, 0, 0, 7, 1, 1 , OPAL_MAP_PE);
+}
+
+void pnv_pci_init_ioda2_phb(struct device_node *np)
+{
+ pnv_pci_init_ioda_phb(np, PNV_PHB_IODA2);
}
void __init pnv_pci_init_ioda_hub(struct device_node *np)
@@ -1034,6 +1036,6 @@ void __init pnv_pci_init_ioda_hub(struct device_node *np)
for_each_child_of_node(np, phbn) {
/* Look for IODA1 PHBs */
if (of_device_is_compatible(phbn, "ibm,ioda-phb"))
- pnv_pci_init_ioda1_phb(phbn);
+ pnv_pci_init_ioda_phb(phbn, PNV_PHB_IODA1);
}
}
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index 42eee93..a11b5a6 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -492,7 +492,7 @@ static void pnv_pci_dma_dev_setup(struct pci_dev *pdev)
pnv_pci_dma_fallback_setup(hose, pdev);
}
-/* Fixup wrong class code in p7ioc root complex */
+/* Fixup wrong class code in p7ioc and p8 root complex */
static void pnv_p7ioc_rc_quirk(struct pci_dev *dev)
{
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
@@ -558,6 +558,10 @@ void __init pnv_pci_init(void)
if (!found_ioda)
for_each_compatible_node(np, NULL, "ibm,p5ioc2")
pnv_pci_init_p5ioc2_hub(np);
+
+ /* Look for ioda2 built-in PHB3's */
+ for_each_compatible_node(np, NULL, "ibm,ioda2-phb")
+ pnv_pci_init_ioda2_phb(np);
}
/* Setup the linkage between OF nodes and PHBs */
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 42ddfba..f6314d6 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -4,9 +4,9 @@
struct pci_dn;
enum pnv_phb_type {
- PNV_PHB_P5IOC2,
- PNV_PHB_IODA1,
- PNV_PHB_IODA2,
+ PNV_PHB_P5IOC2 = 0,
+ PNV_PHB_IODA1 = 1,
+ PNV_PHB_IODA2 = 2,
};
/* Precise PHB model for error management */
@@ -14,6 +14,7 @@ enum pnv_phb_model {
PNV_PHB_MODEL_UNKNOWN,
PNV_PHB_MODEL_P5IOC2,
PNV_PHB_MODEL_P7IOC,
+ PNV_PHB_MODEL_PHB3,
};
#define PNV_PCI_DIAG_BUF_SIZE 4096
@@ -148,6 +149,7 @@ extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
u64 dma_offset);
extern void pnv_pci_init_p5ioc2_hub(struct device_node *np);
extern void pnv_pci_init_ioda_hub(struct device_node *np);
+extern void pnv_pci_init_ioda2_phb(struct device_node *np);
#endif /* __POWERNV_PCI_H */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/6] powerpc/powernv: Patch MSI EOI handler on P8
From: Gavin Shan @ 2013-04-26 5:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1366953662-9473-1-git-send-email-shangw@linux.vnet.ibm.com>
The EOI handler of MSI/MSI-X interrupts for P8 (PHB3) need additional
steps to handle the P/Q bits in IVE before EOIing the corresponding
interrupt. The patch changes the EOI handler to cover that. we have
individual IRQ chip in each PHB instance. During the MSI IRQ setup
time, the IRQ chip is copied over from the original one for that IRQ,
and the EOI handler is patched with the one that will handle the P/Q
bits (As Ben suggested).
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 2 +
arch/powerpc/include/asm/xics.h | 1 +
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
arch/powerpc/platforms/powernv/pci-ioda.c | 38 ++++++++++++++++++++++-
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 4 +-
arch/powerpc/platforms/powernv/pci.c | 2 +-
arch/powerpc/platforms/powernv/pci.h | 8 ++++-
arch/powerpc/sysdev/xics/icp-native.c | 2 +-
8 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index a4b28f1..b6c8b58 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -117,6 +117,7 @@ extern int opal_enter_rtas(struct rtas_args *args,
#define OPAL_SET_SLOT_LED_STATUS 55
#define OPAL_GET_EPOW_STATUS 56
#define OPAL_SET_SYSTEM_ATTENTION_LED 57
+#define OPAL_PCI_MSI_EOI 63
#ifndef __ASSEMBLY__
@@ -506,6 +507,7 @@ int64_t opal_pci_get_xive_reissue(uint64_t phb_id, uint32_t xive_number,
uint8_t *p_bit, uint8_t *q_bit);
int64_t opal_pci_set_xive_reissue(uint64_t phb_id, uint32_t xive_number,
uint8_t p_bit, uint8_t q_bit);
+int64_t opal_pci_msi_eoi(uint64_t phb_id, uint32_t hw_irq);
int64_t opal_pci_set_xive_pe(uint64_t phb_id, uint32_t pe_number,
uint32_t xive_num);
int64_t opal_get_xive_source(uint64_t phb_id, uint32_t xive_num,
diff --git a/arch/powerpc/include/asm/xics.h b/arch/powerpc/include/asm/xics.h
index 4ae9a09..282d43a 100644
--- a/arch/powerpc/include/asm/xics.h
+++ b/arch/powerpc/include/asm/xics.h
@@ -150,6 +150,7 @@ extern void xics_register_ics(struct ics *ics);
extern void xics_teardown_cpu(void);
extern void xics_kexec_teardown_cpu(int secondary);
extern void xics_migrate_irqs_away(void);
+extern void icp_native_eoi(struct irq_data *d);
#ifdef CONFIG_SMP
extern int xics_get_irq_server(unsigned int virq, const struct cpumask *cpumask,
unsigned int strict_check);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 3bb07e5..6fabe92 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -107,3 +107,4 @@ OPAL_CALL(opal_pci_mask_pe_error, OPAL_PCI_MASK_PE_ERROR);
OPAL_CALL(opal_set_slot_led_status, OPAL_SET_SLOT_LED_STATUS);
OPAL_CALL(opal_get_epow_status, OPAL_GET_EPOW_STATUS);
OPAL_CALL(opal_set_system_attention_led, OPAL_SET_SYSTEM_ATTENTION_LED);
+OPAL_CALL(opal_pci_msi_eoi, OPAL_PCI_MSI_EOI);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 3d4e958..3f88c51 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -31,6 +31,7 @@
#include <asm/opal.h>
#include <asm/iommu.h>
#include <asm/tce.h>
+#include <asm/xics.h>
#include "powernv.h"
#include "pci.h"
@@ -589,11 +590,27 @@ static void pnv_ioda_setup_dma(struct pnv_phb *phb)
}
#ifdef CONFIG_PCI_MSI
+static void pnv_ioda2_msi_eoi(struct irq_data *d)
+{
+ unsigned int hw_irq = (unsigned int)irqd_to_hwirq(d);
+ struct irq_chip *chip = irq_data_get_irq_chip(d);
+ struct pnv_phb *phb = container_of(chip, struct pnv_phb,
+ ioda.irq_chip);
+ int64_t rc;
+
+ rc = opal_pci_msi_eoi(phb->opal_id, hw_irq);
+ WARN_ON_ONCE(rc);
+
+ icp_native_eoi(d);
+}
+
static int pnv_pci_ioda_msi_setup(struct pnv_phb *phb, struct pci_dev *dev,
- unsigned int hwirq, unsigned int is_64,
- struct msi_msg *msg)
+ unsigned int hwirq, unsigned int virq,
+ unsigned int is_64, struct msi_msg *msg)
{
struct pnv_ioda_pe *pe = pnv_ioda_get_pe(dev);
+ struct irq_data *idata;
+ struct irq_chip *ichip;
unsigned int xive_num = hwirq - phb->msi_base;
uint64_t addr64;
uint32_t addr32, data;
@@ -638,6 +655,23 @@ static int pnv_pci_ioda_msi_setup(struct pnv_phb *phb, struct pci_dev *dev,
}
msg->data = data;
+ /*
+ * Change the IRQ chip for the MSI interrupts on PHB3.
+ * The corresponding IRQ chip should be populated for
+ * the first time.
+ */
+ if (phb->type == PNV_PHB_IODA2) {
+ if (!phb->ioda.irq_chip_init) {
+ idata = irq_get_irq_data(virq);
+ ichip = irq_data_get_irq_chip(idata);
+ phb->ioda.irq_chip_init = 1;
+ phb->ioda.irq_chip = *ichip;
+ phb->ioda.irq_chip.irq_eoi = pnv_ioda2_msi_eoi;
+ }
+
+ irq_set_chip(virq, &phb->ioda.irq_chip);
+ }
+
pr_devel("%s: %s-bit MSI on hwirq %x (xive #%d),"
" address=%x_%08x data=%x PE# %d\n",
pci_name(dev), is_64 ? "64" : "32", hwirq, xive_num,
diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
index d5c066e..92b37a0 100644
--- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
+++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
@@ -42,8 +42,8 @@
#ifdef CONFIG_PCI_MSI
static int pnv_pci_p5ioc2_msi_setup(struct pnv_phb *phb, struct pci_dev *dev,
- unsigned int hwirq, unsigned int is_64,
- struct msi_msg *msg)
+ unsigned int hwirq, unsigned int virq,
+ unsigned int is_64, struct msi_msg *msg)
{
if (WARN_ON(!is_64))
return -ENXIO;
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index a11b5a6..861e185 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -84,7 +84,7 @@ static int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
return -ENOMEM;
}
rc = phb->msi_setup(phb, pdev, phb->msi_base + hwirq,
- entry->msi_attrib.is_64, &msg);
+ virq, entry->msi_attrib.is_64, &msg);
if (rc) {
pr_warn("%s: Failed to setup MSI\n", pci_name(pdev));
irq_dispose_mapping(virq);
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index f6314d6..3c552b3 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -79,8 +79,8 @@ struct pnv_phb {
struct msi_bitmap msi_bmp;
#endif
int (*msi_setup)(struct pnv_phb *phb, struct pci_dev *dev,
- unsigned int hwirq, unsigned int is_64,
- struct msi_msg *msg);
+ unsigned int hwirq, unsigned int virq,
+ unsigned int is_64, struct msi_msg *msg);
void (*dma_dev_setup)(struct pnv_phb *phb, struct pci_dev *pdev);
void (*fixup_phb)(struct pci_controller *hose);
u32 (*bdfn_to_pe)(struct pnv_phb *phb, struct pci_bus *bus, u32 devfn);
@@ -108,6 +108,10 @@ struct pnv_phb {
unsigned int *io_segmap;
struct pnv_ioda_pe *pe_array;
+ /* IRQ chip */
+ int irq_chip_init;
+ struct irq_chip irq_chip;
+
/* Sorted list of used PE's based
* on the sequence of creation
*/
diff --git a/arch/powerpc/sysdev/xics/icp-native.c b/arch/powerpc/sysdev/xics/icp-native.c
index 48861d3..89db29d 100644
--- a/arch/powerpc/sysdev/xics/icp-native.c
+++ b/arch/powerpc/sysdev/xics/icp-native.c
@@ -81,7 +81,7 @@ static void icp_native_set_cpu_priority(unsigned char cppr)
iosync();
}
-static void icp_native_eoi(struct irq_data *d)
+void icp_native_eoi(struct irq_data *d)
{
unsigned int hw_irq = (unsigned int)irqd_to_hwirq(d);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 5/6] powerpc/powernv: Build DMA space for PE on PHB3
From: Gavin Shan @ 2013-04-26 5:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1366953662-9473-1-git-send-email-shangw@linux.vnet.ibm.com>
The patch intends to build 32-bits DMA space for individual PEs on
PHB3. The TVE# is recognized by the combo of PE# and fixed bits
from DMA address, which is zero for 32-bits DMA space.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 99 +++++++++++++++++++++++++++--
1 files changed, 93 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 1c7e808..04a37dc 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -600,9 +600,8 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
*/
tbl->it_busno = 0;
tbl->it_index = (unsigned long)ioremap(be64_to_cpup(swinvp), 8);
- tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE;
- if (phb->type == PNV_PHB_IODA1)
- tbl->it_type |= TCE_PCI_SWINV_PAIR;
+ tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE |
+ TCE_PCI_SWINV_PAIR;
}
iommu_init_table(tbl, phb->hose->node);
@@ -620,6 +619,81 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
__free_pages(tce_mem, get_order(TCE32_TABLE_SIZE * segs));
}
+static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
+ struct pnv_ioda_pe *pe)
+{
+ struct page *tce_mem = NULL;
+ void *addr;
+ const __be64 *swinvp;
+ struct iommu_table *tbl;
+ unsigned int tce_table_size, end;
+ int64_t rc;
+
+ /* We shouldn't already have a 32-bit DMA associated */
+ if (WARN_ON(pe->tce32_seg >= 0))
+ return;
+
+ /* The PE will reserve all possible 32-bits space */
+ pe->tce32_seg = 0;
+ end = (1 << ilog2(phb->ioda.m32_pci_base));
+ tce_table_size = (end / 0x1000) * 8;
+ pe_info(pe, "Setting up 32-bit TCE table at 0..%08x\n",
+ end);
+
+ /* Allocate TCE table */
+ tce_mem = alloc_pages_node(phb->hose->node, GFP_KERNEL,
+ get_order(tce_table_size));
+ if (!tce_mem) {
+ pe_err(pe, "Failed to allocate a 32-bit TCE memory\n");
+ goto fail;
+ }
+ addr = page_address(tce_mem);
+ memset(addr, 0, tce_table_size);
+
+ /*
+ * Map TCE table through TVT. The TVE index is the PE number
+ * shifted by 1 bit for 32-bits DMA space.
+ */
+ rc = opal_pci_map_pe_dma_window(phb->opal_id, pe->pe_number,
+ pe->pe_number << 1, 1, __pa(addr),
+ tce_table_size, 0x1000);
+ if (rc) {
+ pe_err(pe, "Failed to configure 32-bit TCE table,"
+ " err %ld\n", rc);
+ goto fail;
+ }
+
+ /* Setup linux iommu table */
+ tbl = &pe->tce32_table;
+ pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0);
+
+ /* OPAL variant of PHB3 invalidated TCEs */
+ swinvp = of_get_property(phb->hose->dn, "ibm,opal-tce-kill", NULL);
+ if (swinvp) {
+ /* We need a couple more fields -- an address and a data
+ * to or. Since the bus is only printed out on table free
+ * errors, and on the first pass the data will be a relative
+ * bus number, print that out instead.
+ */
+ tbl->it_busno = 0;
+ tbl->it_index = (unsigned long)ioremap(be64_to_cpup(swinvp), 8);
+ tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE;
+ }
+ iommu_init_table(tbl, phb->hose->node);
+
+ if (pe->pdev)
+ set_iommu_table_base(&pe->pdev->dev, tbl);
+ else
+ pnv_ioda_setup_bus_dma(pe, pe->pbus);
+
+ return;
+fail:
+ if (pe->tce32_seg >= 0)
+ pe->tce32_seg = -1;
+ if (tce_mem)
+ __free_pages(tce_mem, get_order(tce_table_size));
+}
+
static void pnv_ioda_setup_dma(struct pnv_phb *phb)
{
struct pci_controller *hose = phb->hose;
@@ -662,9 +736,22 @@ static void pnv_ioda_setup_dma(struct pnv_phb *phb)
if (segs > remaining)
segs = remaining;
}
- pe_info(pe, "DMA weight %d, assigned %d DMA32 segments\n",
- pe->dma_weight, segs);
- pnv_pci_ioda_setup_dma_pe(phb, pe, base, segs);
+
+ /*
+ * For IODA2 compliant PHB3, we needn't care about the weight.
+ * The all available 32-bits DMA space will be assigned to
+ * the specific PE.
+ */
+ if (phb->type == PNV_PHB_IODA1) {
+ pe_info(pe, "DMA weight %d, assigned %d DMA32 segments\n",
+ pe->dma_weight, segs);
+ pnv_pci_ioda_setup_dma_pe(phb, pe, base, segs);
+ } else {
+ pe_info(pe, "Assign DMA32 space\n");
+ segs = 0;
+ pnv_pci_ioda2_setup_dma_pe(phb, pe);
+ }
+
remaining -= segs;
base += segs;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 6/6] powerpc/powernv: Fix invalid IOMMU table
From: Gavin Shan @ 2013-04-26 5:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1366953662-9473-1-git-send-email-shangw@linux.vnet.ibm.com>
Ben found the root cause. Commit 37f02195bee9c25ce44e25204f40b7961a6d7c9d
("powerpc/pci: fix PCI-e devices rescan issue on powerpc platform")
overwrites the IOMMU table of PCI device while enabling PCI device.
The patch intends to fix the IOMMU table after that point.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 33 ++++++++++------------------
1 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 04a37dc..8c6c9cf 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -434,20 +434,21 @@ static void pnv_pci_ioda_setup_PEs(void)
}
}
-static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *dev)
+static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev)
{
- /* We delay DMA setup after we have assigned all PE# */
-}
+ struct pci_dn *pdn = pnv_ioda_get_pdn(pdev);
+ struct pnv_ioda_pe *pe;
-static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
-{
- struct pci_dev *dev;
+ /*
+ * The function can be called while the PE#
+ * hasn't been assigned. Do nothing for the
+ * case.
+ */
+ if (!pdn || pdn->pe_number == IODA_INVALID_PE)
+ return;
- list_for_each_entry(dev, &bus->devices, bus_list) {
- set_iommu_table_base(&dev->dev, &pe->tce32_table);
- if (dev->subordinate)
- pnv_ioda_setup_bus_dma(pe, dev->subordinate);
- }
+ pe = &phb->ioda.pe_array[pdn->pe_number];
+ set_iommu_table_base(&pdev->dev, &pe->tce32_table);
}
static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
@@ -605,11 +606,6 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
}
iommu_init_table(tbl, phb->hose->node);
- if (pe->pdev)
- set_iommu_table_base(&pe->pdev->dev, tbl);
- else
- pnv_ioda_setup_bus_dma(pe, pe->pbus);
-
return;
fail:
/* XXX Failure: Try to fallback to 64-bit only ? */
@@ -681,11 +677,6 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
}
iommu_init_table(tbl, phb->hose->node);
- if (pe->pdev)
- set_iommu_table_base(&pe->pdev->dev, tbl);
- else
- pnv_ioda_setup_bus_dma(pe, pe->pbus);
-
return;
fail:
if (pe->tce32_seg >= 0)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 4/6] powerpc/powernv: TCE invalidation for PHB3
From: Gavin Shan @ 2013-04-26 5:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1366953662-9473-1-git-send-email-shangw@linux.vnet.ibm.com>
The TCE should be invalidated while it's created or free'd. The
approach to do that for IODA1 and IODA2 compliant PHBs are different.
So the patch differentiate them with different functions called to
do that for IODA1 and IODA2 compliant PHBs. It's notable that the
PCI address is used to invalidate the corresponding TCE on IODA2
compliant PHB3.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 85 ++++++++++++++++++++++++++++-
arch/powerpc/platforms/powernv/pci.c | 48 +---------------
arch/powerpc/platforms/powernv/pci.h | 6 ++-
3 files changed, 90 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 3f88c51..1c7e808 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -89,6 +89,7 @@ static int pnv_ioda_alloc_pe(struct pnv_phb *phb)
return IODA_INVALID_PE;
} while(test_and_set_bit(pe, phb->ioda.pe_alloc));
+ phb->ioda.pe_array[pe].phb = phb;
phb->ioda.pe_array[pe].pe_number = pe;
return pe;
}
@@ -449,6 +450,85 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
}
}
+static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
+ u64 *startp, u64 *endp)
+{
+ u64 __iomem *invalidate = (u64 __iomem *)tbl->it_index;
+ unsigned long start, end, inc;
+
+ start = __pa(startp);
+ end = __pa(endp);
+
+ /* BML uses this case for p6/p7/galaxy2: Shift addr and put in node */
+ if (tbl->it_busno) {
+ start <<= 12;
+ end <<= 12;
+ inc = 128 << 12;
+ start |= tbl->it_busno;
+ end |= tbl->it_busno;
+ } else if (tbl->it_type & TCE_PCI_SWINV_PAIR) {
+ /* p7ioc-style invalidation, 2 TCEs per write */
+ start |= (1ull << 63);
+ end |= (1ull << 63);
+ inc = 16;
+ } else {
+ /* Default (older HW) */
+ inc = 128;
+ }
+
+ end |= inc - 1; /* round up end to be different than start */
+
+ mb(); /* Ensure above stores are visible */
+ while (start <= end) {
+ __raw_writeq(start, invalidate);
+ start += inc;
+ }
+
+ /*
+ * The iommu layer will do another mb() for us on build()
+ * and we don't care on free()
+ */
+}
+
+static void pnv_pci_ioda2_tce_invalidate(struct pnv_ioda_pe *pe,
+ struct iommu_table *tbl,
+ u64 *startp, u64 *endp)
+{
+ unsigned long start, end, inc;
+ u64 __iomem *invalidate = (u64 __iomem *)tbl->it_index;
+
+ /* We'll invalidate DMA address in PE scope */
+ start = 0x2ul << 60;
+ start |= (pe->pe_number & 0xFF);
+ end = start;
+
+ /* Figure out the start, end and step */
+ inc = tbl->it_offset + (((u64)startp - tbl->it_base) / sizeof(u64));
+ start |= (inc << 12);
+ inc = tbl->it_offset + (((u64)endp - tbl->it_base) / sizeof(u64));
+ end |= (inc << 12);
+ inc = (0x1ul << 12);
+ mb();
+
+ while (start <= end) {
+ __raw_writeq(start, invalidate);
+ start += inc;
+ }
+}
+
+void pnv_pci_ioda_tce_invalidate(struct iommu_table *tbl,
+ u64 *startp, u64 *endp)
+{
+ struct pnv_ioda_pe *pe = container_of(tbl, struct pnv_ioda_pe,
+ tce32_table);
+ struct pnv_phb *phb = pe->phb;
+
+ if (phb->type == PNV_PHB_IODA1)
+ pnv_pci_ioda1_tce_invalidate(tbl, startp, endp);
+ else
+ pnv_pci_ioda2_tce_invalidate(pe, tbl, startp, endp);
+}
+
static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe, unsigned int base,
unsigned int segs)
@@ -520,8 +600,9 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
*/
tbl->it_busno = 0;
tbl->it_index = (unsigned long)ioremap(be64_to_cpup(swinvp), 8);
- tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE
- | TCE_PCI_SWINV_PAIR;
+ tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE;
+ if (phb->type == PNV_PHB_IODA1)
+ tbl->it_type |= TCE_PCI_SWINV_PAIR;
}
iommu_init_table(tbl, phb->hose->node);
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index 861e185..55dfca844 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -329,48 +329,6 @@ struct pci_ops pnv_pci_ops = {
.write = pnv_pci_write_config,
};
-
-static void pnv_tce_invalidate(struct iommu_table *tbl,
- u64 *startp, u64 *endp)
-{
- u64 __iomem *invalidate = (u64 __iomem *)tbl->it_index;
- unsigned long start, end, inc;
-
- start = __pa(startp);
- end = __pa(endp);
-
-
- /* BML uses this case for p6/p7/galaxy2: Shift addr and put in node */
- if (tbl->it_busno) {
- start <<= 12;
- end <<= 12;
- inc = 128 << 12;
- start |= tbl->it_busno;
- end |= tbl->it_busno;
- }
- /* p7ioc-style invalidation, 2 TCEs per write */
- else if (tbl->it_type & TCE_PCI_SWINV_PAIR) {
- start |= (1ull << 63);
- end |= (1ull << 63);
- inc = 16;
- }
- /* Default (older HW) */
- else
- inc = 128;
-
- end |= inc - 1; /* round up end to be different than start */
-
- mb(); /* Ensure above stores are visible */
- while (start <= end) {
- __raw_writeq(start, invalidate);
- start += inc;
- }
- /* The iommu layer will do another mb() for us on build() and
- * we don't care on free()
- */
-}
-
-
static int pnv_tce_build(struct iommu_table *tbl, long index, long npages,
unsigned long uaddr, enum dma_data_direction direction,
struct dma_attrs *attrs)
@@ -395,7 +353,7 @@ static int pnv_tce_build(struct iommu_table *tbl, long index, long npages,
* of flags if that becomes the case
*/
if (tbl->it_type & TCE_PCI_SWINV_CREATE)
- pnv_tce_invalidate(tbl, tces, tcep - 1);
+ pnv_pci_ioda_tce_invalidate(tbl, tces, tcep - 1);
return 0;
}
@@ -409,8 +367,8 @@ static void pnv_tce_free(struct iommu_table *tbl, long index, long npages)
while (npages--)
*(tcep++) = 0;
- if (tbl->it_type & TCE_PCI_SWINV_FREE)
- pnv_tce_invalidate(tbl, tces, tcep - 1);
+ if (tbl->it_type & TCE_PCI_SWINV_CREATE)
+ pnv_pci_ioda_tce_invalidate(tbl, tces, tcep - 1);
}
static unsigned long pnv_tce_get(struct iommu_table *tbl, long index)
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 3c552b3..48dc4bb 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -23,8 +23,10 @@ enum pnv_phb_model {
#define PNV_IODA_PE_BUS_ALL (1 << 2) /* PE has subordinate buses */
/* Data associated with a PE, including IOMMU tracking etc.. */
+struct pnv_phb;
struct pnv_ioda_pe {
unsigned long flags;
+ struct pnv_phb *phb;
/* A PE can be associated with a single device or an
* entire bus (& children). In the former case, pdev
@@ -154,6 +156,6 @@ extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
extern void pnv_pci_init_p5ioc2_hub(struct device_node *np);
extern void pnv_pci_init_ioda_hub(struct device_node *np);
extern void pnv_pci_init_ioda2_phb(struct device_node *np);
-
-
+extern void pnv_pci_ioda_tce_invalidate(struct iommu_table *tbl,
+ u64 *startp, u64 *endp);
#endif /* __POWERNV_PCI_H */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/7] powerpc: Initialise PMU related regs on Power8
From: Michael Ellerman @ 2013-04-26 5:28 UTC (permalink / raw)
To: linuxppc-dev
For both HV and guest kernels, intialise PMU regs to something sane.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/reg.h | 6 ++++++
arch/powerpc/kernel/cpu_setup_power.S | 21 ++++++++++++++++++++-
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 4ae2d44..5735ebb 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -271,6 +271,7 @@
#define SPRN_HFSCR 0xbe /* HV=1 Facility Status & Control Register */
#define HFSCR_TAR (1 << (63-55)) /* Enable Target Address Register */
#define HFSCR_TM (1 << (63-58)) /* Enable Transactional Memory */
+#define HFSCR_PM (1 << (63-60)) /* Enable prob/priv access to PMU SPRs */
#define HFSCR_DSCR (1 << (63-61)) /* Enable Data Stream Control Register */
#define HFSCR_VECVSX (1 << (63-62)) /* Enable VMX/VSX */
#define HFSCR_FP (1 << (63-63)) /* Enable Floating Point */
@@ -637,6 +638,7 @@
#define MMCR0_FCWAIT 0x00000002UL /* freeze counter in WAIT state */
#define MMCR0_FCHV 0x00000001UL /* freeze conditions in hypervisor mode */
#define SPRN_MMCR1 798
+#define SPRN_MMCR2 769
#define SPRN_MMCRA 0x312
#define MMCRA_SDSYNC 0x80000000UL /* SDAR synced with SIAR */
#define MMCRA_SDAR_DCACHE_MISS 0x40000000UL
@@ -655,6 +657,10 @@
#define POWER7P_MMCRA_SIAR_VALID 0x10000000 /* P7+ SIAR contents valid */
#define POWER7P_MMCRA_SDAR_VALID 0x08000000 /* P7+ SDAR contents valid */
+#define SPRN_MMCRH 316 /* Hypervisor monitor mode control register */
+#define SPRN_MMCRS 894 /* Supervisor monitor mode control register */
+#define SPRN_MMCRC 851 /* Core monitor mode control register */
+
#define SPRN_PMC1 787
#define SPRN_PMC2 788
#define SPRN_PMC3 789
diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cpu_setup_power.S
index 2e6ad11..02a6945 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -49,6 +49,7 @@ _GLOBAL(__restore_cpu_power7)
_GLOBAL(__setup_cpu_power8)
mflr r11
bl __init_FSCR
+ bl __init_PMU
bl __init_hvmode_206
mtlr r11
beqlr
@@ -59,12 +60,14 @@ _GLOBAL(__setup_cpu_power8)
bl __init_LPCR
bl __init_HFSCR
bl __init_TLB
+ bl __init_PMU_HV
mtlr r11
blr
_GLOBAL(__restore_cpu_power8)
mflr r11
bl __init_FSCR
+ bl __init_PMU
mfmsr r3
rldicl. r0,r3,4,63
beqlr
@@ -75,6 +78,7 @@ _GLOBAL(__restore_cpu_power8)
bl __init_LPCR
bl __init_HFSCR
bl __init_TLB
+ bl __init_PMU_HV
mtlr r11
blr
@@ -124,7 +128,7 @@ __init_FSCR:
__init_HFSCR:
mfspr r3,SPRN_HFSCR
- ori r3,r3,HFSCR_TAR|HFSCR_TM|HFSCR_DSCR|HFSCR_VECVSX|HFSCR_FP
+ ori r3,r3,HFSCR_TAR|HFSCR_TM|HFSCR_DSCR|HFSCR_VECVSX|HFSCR_FP|HFSCR_PM
mtspr SPRN_HFSCR,r3
blr
@@ -139,3 +143,18 @@ __init_TLB:
bdnz 2b
ptesync
1: blr
+
+__init_PMU_HV:
+ li r5,0
+ mtspr SPRN_MMCRC,r5
+ mtspr SPRN_MMCRH,r5
+ blr
+
+__init_PMU:
+ li r5,0
+ mtspr SPRN_MMCRS,r5
+ mtspr SPRN_MMCRA,r5
+ mtspr SPRN_MMCR0,r5
+ mtspr SPRN_MMCR1,r5
+ mtspr SPRN_MMCR2,r5
+ blr
--
1.7.10.4
^ 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