* Re: [V2 5/5] powerpc: kernel: 16650 UART reg-shift support
From: Tanmay Inamdar @ 2012-05-09 5:27 UTC (permalink / raw)
To: Josh Boyer; +Cc: devicetree-discuss, linuxppc-dev, linux-kernel
In-Reply-To: <CA+5PVA4sjX_Dk6ecySG4ZZoM=xhaWu2jGrQ=LtFgxGL88G=-Nw@mail.gmail.com>
On Wed, May 2, 2012 at 7:08 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Mon, Apr 9, 2012 at 3:20 AM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>> In APM8018X SOC, UART register address space has been relocated to 32-bi=
t
>> data boundaries for APB bus implementation.
>> Current legacy_serial driver ignores the reg-shift property. This patch
>> modifies legacy_serial.c and udbg_16550.c to work with above mentioned U=
ARTs.
>>
>> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
>> ---
>> :100644 100644 8338aef... f5fc106... M =A0arch/powerpc/include/asm/udbg.=
h
>> :100644 100644 bedd12e... d523b7d... M =A0arch/powerpc/kernel/legacy_ser=
ial.c
>> :100644 100644 6837f83... e0cb7dc... M =A0arch/powerpc/kernel/udbg_16550=
.c
>> =A0arch/powerpc/include/asm/udbg.h =A0 =A0 | =A0 =A02 +-
>> =A0arch/powerpc/kernel/legacy_serial.c | =A0 16 +++++---
>> =A0arch/powerpc/kernel/udbg_16550.c =A0 =A0| =A0 64 ++++++++++++++++++++=
++------------
>> =A03 files changed, 52 insertions(+), 30 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/=
udbg.h
>> index 8338aef..f5fc106 100644
>> --- a/arch/powerpc/include/asm/udbg.h
>> +++ b/arch/powerpc/include/asm/udbg.h
>> @@ -29,7 +29,7 @@ extern void udbg_printf(const char *fmt, ...)
>> =A0extern void udbg_progress(char *s, unsigned short hex);
>>
>> =A0extern void udbg_init_uart(void __iomem *comport, unsigned int speed,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int clock)=
;
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int clock,=
=A0unsigned int regshift);
>> =A0extern unsigned int udbg_probe_uart_speed(void __iomem *comport,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0unsigned int clock);
>>
>> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/l=
egacy_serial.c
>> index bedd12e..d523b7d 100644
>> --- a/arch/powerpc/kernel/legacy_serial.c
>> +++ b/arch/powerpc/kernel/legacy_serial.c
>> @@ -33,6 +33,7 @@ static struct legacy_serial_info {
>> =A0 =A0 =A0 =A0unsigned int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clock=
;
>> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 irq_check_parent;
>> =A0 =A0 =A0 =A0phys_addr_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 taddr=
;
>> + =A0 =A0 =A0 unsigned int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regshi=
ft;
>> =A0} legacy_serial_infos[MAX_LEGACY_SERIAL_PORTS];
>>
>> =A0static struct __initdata of_device_id legacy_serial_parents[] =3D {
>> @@ -42,6 +43,7 @@ static struct __initdata of_device_id legacy_serial_pa=
rents[] =3D {
>> =A0 =A0 =A0 =A0{.compatible =3D "ibm,opb",},
>> =A0 =A0 =A0 =A0{.compatible =3D "simple-bus",},
>> =A0 =A0 =A0 =A0{.compatible =3D "wrs,epld-localbus",},
>> + =A0 =A0 =A0 {.compatible =3D "apm,apb",},
>> =A0 =A0 =A0 =A0{},
>> =A0};
>>
>> @@ -163,11 +165,6 @@ static int __init add_legacy_soc_port(struct device=
_node *np,
>> =A0 =A0 =A0 =A0if (of_get_property(np, "clock-frequency", NULL) =3D=3D N=
ULL)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;
>>
>> - =A0 =A0 =A0 /* if reg-shift or offset, don't try to use it */
>> - =A0 =A0 =A0 if ((of_get_property(np, "reg-shift", NULL) !=3D NULL) ||
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 (of_get_property(np, "reg-offset", NULL) !=
=3D NULL))
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1;
>> -
>
> So we explicitly didn't support reg-shift before. =A0I'm guessing there i=
s
> a reason for that, but I don't recall what. =A0Ben?
>
> Also, why do you need to use the legacy serial driver at all for this
> SOC? =A0As far as I remember, the OF serial driver should be sufficient.
>
You are right. There is no need to use legacy serial driver. However I
realized that when 40x is selected, 'PPC_UDBG_16550' is by default
selected. This enables legacy serial driver.
Is it now required to enable 'PPC_UDBG_16550' by default for every SOC
that uses 40x processor?
>> +static unsigned int reg_shift;
>> +#define ns16550_offset(addr) (addr - (unsigned char *)udbg_comport)
>> +
>> =A0static struct NS16550 __iomem *udbg_comport;
>>
>> +static inline u8 serial_read(unsigned char *addr)
>> +{
>> + =A0 =A0 =A0 u32 offset =3D ns16550_offset(addr) << reg_shift;
>> + =A0 =A0 =A0 return readb(udbg_comport + offset);
>> +}
>> +
>> +static inline void serial_write(unsigned char *addr, char val)
>> +{
>> + =A0 =A0 =A0 u32 offset =3D ns16550_offset(addr) << reg_shift;
>> + =A0 =A0 =A0 writeb(val, udbg_comport + offset);
>> +}
>> +
>
> I don't think readb/writeb are correct here. =A0Why did you switch to
> using those instead of sticking with in_8/out_8?
>
> josh
Thanks,
Tanmay
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, =
is for the sole use of the intended recipient(s) and contains information=
=A0
that is confidential and proprietary to AppliedMicro Corporation or its s=
ubsidiaries. =
It is to be used solely for the purpose of furthering the parties' busine=
ss relationship. =
All unauthorized review, use, disclosure or distribution is prohibited. =
If you are not the intended recipient, please contact the sender by reply=
e-mail =
and destroy all copies of the original message.
=0D
^ permalink raw reply
* Re: [V2 2/5] powerpc: 40x: Add AHB, APB of_device_ids
From: Tanmay Inamdar @ 2012-05-09 5:28 UTC (permalink / raw)
To: Josh Boyer; +Cc: devicetree-discuss, linuxppc-dev, linux-kernel
In-Reply-To: <CA+5PVA4HGVGRbnLCMOAbO1mYnFCgHhh1_ErLdKq5YhMdV0VhQw@mail.gmail.com>
On Wed, May 2, 2012 at 7:11 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Mon, Apr 9, 2012 at 3:20 AM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>> Adding of_device_id's for AHB and APB buses used in klondike (APM8018X) =
in
>> platforms/40x/ppc40x_simple.c file
>>
>> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
>
> You should probably combine the first 3 patches in this series into one
> patch. =A0Otherwise you run the risk of changing the DTS to something the
> kernel can't support. =A0At the least, this change should be patch 1 in
> the series, and you can probably combine the two DTS changes.
>
I will do it in next version of patches.
> josh
Thanks,
Tanmay
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, =
is for the sole use of the intended recipient(s) and contains information=
=A0
that is confidential and proprietary to AppliedMicro Corporation or its s=
ubsidiaries. =
It is to be used solely for the purpose of furthering the parties' busine=
ss relationship. =
All unauthorized review, use, disclosure or distribution is prohibited. =
If you are not the intended recipient, please contact the sender by reply=
e-mail =
and destroy all copies of the original message.
=0D
^ permalink raw reply
* Re: [RFC] [PATCH] usb: gadget: fix dtd dma confusion
From: Christoph Fritz @ 2012-05-09 5:38 UTC (permalink / raw)
To: Chen Peter-B29397, Chao Xie
Cc: Oliver Neukum, Kukjin Kim, Eric Miao, Li Yang-R58472,
Greg Kroah-Hartman, Sascha Hauer, linux-usb@vger.kernel.org,
Nicolas Ferre, linuxppc-dev@lists.ozlabs.org, Felipe Balbi,
Ido Shayevitz, Estevam Fabio-R49496, Hans J. Koch, Haojian Zhuang,
Daniel Mack, Thomas Dahlmann, Russell King, Neil Zhang,
Fabio Estevam, Ben Dooks
In-Reply-To: <F281D0F91ED19E4D8E63A7504E8A649803B91E69@039-SN2MPN1-022.039d.mgd.msft.net>
Hi Peter,
thanks you for your help.
On Wed, May 09, 2012 at 02:11:56AM +0000, Chen Peter-B29397 wrote:
>
>
> > >
> > > after a while of testing and searching I can come up with a patch
> > > that fixes g_ether <-> iperf for fsl_udc on ARM i.MX35.
> > >
> > > The sad part is that this kind of fix is already implemented for
> > > marvell mv_udc driver since last year but still _not_ in the ~15
> > > other *udc.c drivers.
> > >
>
> It is a controller limitation (bug?) for chipidea controller when using
> dtd list to handle multi-dtds situation. The controller will read dtd's
> next pointer after this dtd's active bit has already been cleared.
>
> Freescale has an errata for this problem's description and solution.
> http://cache.freescale.com/files/dsp/doc/errata/IMX23CE.pdf
> See 2858
I'm hacking here an i.MX35 not an i.MX23. So I already had a look at its
errata sheet http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf
but didn't find a similar "limitation" as you now pointed out by errata
number 2858 for i.MX23.
What about the fix for mv_udc, shouldn't they have a similar
"limitation"? How do you explain?
Or maybe someone from Marvell has an answer?
Thanks,
-- Christoph
^ permalink raw reply
* RE: [RFC] [PATCH] usb: gadget: fix dtd dma confusion
From: Chen Peter-B29397 @ 2012-05-09 5:43 UTC (permalink / raw)
To: Christoph Fritz, Chao Xie
Cc: Oliver Neukum, Kukjin Kim, Eric Miao, Li Yang-R58472,
Greg Kroah-Hartman, Sascha Hauer, linux-usb@vger.kernel.org,
Nicolas Ferre, linuxppc-dev@lists.ozlabs.org, Felipe Balbi,
Ido Shayevitz, Estevam Fabio-R49496, Hans J. Koch, Haojian Zhuang,
Daniel Mack, Thomas Dahlmann, Russell King, Neil Zhang,
Fabio Estevam, Ben Dooks
In-Reply-To: <20120509053826.GA3492@lovely.krouter>
=20
>=20
> I'm hacking here an i.MX35 not an i.MX23. So I already had a look at its
> errata sheet http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf
> but didn't find a similar "limitation" as you now pointed out by errata
> number 2858 for i.MX23.
>
i.mx35 and i.mx23 uses the same controller.
=20
> What about the fix for mv_udc, shouldn't they have a similar
> "limitation"? How do you explain?
> Or maybe someone from Marvell has an answer?
>
It is probably that others who use chipidea core have the same problem,
but it needs to get confirm from them. =20
>=20
> Thanks,
> -- Christoph
^ permalink raw reply
* RE: [RFC] [PATCH] usb: gadget: fix dtd dma confusion
From: Neil Zhang @ 2012-05-09 5:45 UTC (permalink / raw)
To: Christoph Fritz, Chen Peter-B29397, Chao Xie
Cc: Oliver Neukum, Kukjin Kim, Eric Miao, Li Yang-R58472,
Greg Kroah-Hartman, Sascha Hauer, linux-usb@vger.kernel.org,
Nicolas Ferre, linuxppc-dev@lists.ozlabs.org, Felipe Balbi,
Ido Shayevitz, Estevam Fabio-R49496, Hans J. Koch, Haojian Zhuang,
Daniel Mack, Thomas Dahlmann, Russell King, Fabio Estevam,
Ben Dooks
In-Reply-To: <20120509053826.GA3492@lovely.krouter>
DQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENocmlzdG9waCBG
cml0eiBbbWFpbHRvOmNoZi5mcml0ekBnb29nbGVtYWlsLmNvbV0NCj4gU2VudDogMjAxMsTqNdTC
OcjVIDEzOjM4DQo+IFRvOiBDaGVuIFBldGVyLUIyOTM5NzsgQ2hhbyBYaWUNCj4gQ2M6IE5laWwg
Wmhhbmc7IEZhYmlvIEVzdGV2YW07IExpIFlhbmctUjU4NDcyOyBGZWxpcGUgQmFsYmk7IEdyZWcN
Cj4gS3JvYWgtSGFydG1hbjsgbGludXgtdXNiQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2
QGxpc3RzLm96bGFicy5vcmc7DQo+IEhhbnMgSi4gS29jaDsgRGFuaWVsIE1hY2s7IFRob21hcyBE
YWhsbWFubjsgTmljb2xhcyBGZXJyZTsgRXJpYyBNaWFvOw0KPiBSdXNzZWxsIEtpbmc7IEhhb2pp
YW4gWmh1YW5nOyBCZW4gRG9va3M7IEt1a2ppbiBLaW07IFNhc2NoYSBIYXVlcjsNCj4gT2xpdmVy
IE5ldWt1bTsgSWRvIFNoYXlldml0ejsgRXN0ZXZhbSBGYWJpby1SNDk0OTYNCj4gU3ViamVjdDog
UmU6IFtSRkNdIFtQQVRDSF0gdXNiOiBnYWRnZXQ6IGZpeCBkdGQgZG1hIGNvbmZ1c2lvbg0KPiAN
Cj4gSGkgUGV0ZXIsDQo+IA0KPiAgdGhhbmtzIHlvdSBmb3IgeW91ciBoZWxwLg0KPiANCj4gT24g
V2VkLCBNYXkgMDksIDIwMTIgYXQgMDI6MTE6NTZBTSArMDAwMCwgQ2hlbiBQZXRlci1CMjkzOTcg
d3JvdGU6DQo+ID4NCj4gPg0KPiA+ID4gPg0KPiA+ID4gPiBhZnRlciBhIHdoaWxlIG9mIHRlc3Rp
bmcgYW5kIHNlYXJjaGluZyBJIGNhbiBjb21lIHVwIHdpdGggYSBwYXRjaA0KPiA+ID4gPiB0aGF0
IGZpeGVzIGdfZXRoZXIgPC0+IGlwZXJmIGZvciBmc2xfdWRjIG9uIEFSTSBpLk1YMzUuDQo+ID4g
PiA+DQo+ID4gPiA+IFRoZSBzYWQgcGFydCBpcyB0aGF0IHRoaXMga2luZCBvZiBmaXggaXMgYWxy
ZWFkeSBpbXBsZW1lbnRlZCBmb3INCj4gPiA+ID4gbWFydmVsbCBtdl91ZGMgZHJpdmVyIHNpbmNl
IGxhc3QgeWVhciBidXQgc3RpbGwgX25vdF8gaW4gdGhlIH4xNQ0KPiA+ID4gPiBvdGhlciAqdWRj
LmMgZHJpdmVycy4NCj4gPiA+ID4NCj4gPg0KPiA+IEl0IGlzIGEgY29udHJvbGxlciBsaW1pdGF0
aW9uIChidWc/KSBmb3IgY2hpcGlkZWEgY29udHJvbGxlciB3aGVuDQo+IHVzaW5nDQo+ID4gZHRk
IGxpc3QgdG8gaGFuZGxlIG11bHRpLWR0ZHMgc2l0dWF0aW9uLiBUaGUgY29udHJvbGxlciB3aWxs
IHJlYWQNCj4gZHRkJ3MNCj4gPiBuZXh0IHBvaW50ZXIgYWZ0ZXIgdGhpcyBkdGQncyBhY3RpdmUg
Yml0IGhhcyBhbHJlYWR5IGJlZW4gY2xlYXJlZC4NCj4gPg0KPiA+IEZyZWVzY2FsZSBoYXMgYW4g
ZXJyYXRhIGZvciB0aGlzIHByb2JsZW0ncyBkZXNjcmlwdGlvbiBhbmQgc29sdXRpb24uDQo+ID4g
aHR0cDovL2NhY2hlLmZyZWVzY2FsZS5jb20vZmlsZXMvZHNwL2RvYy9lcnJhdGEvSU1YMjNDRS5w
ZGYNCj4gPiBTZWUgMjg1OA0KPiANCj4gSSdtIGhhY2tpbmcgaGVyZSBhbiBpLk1YMzUgbm90IGFu
IGkuTVgyMy4gU28gSSBhbHJlYWR5IGhhZCBhIGxvb2sgYXQNCj4gaXRzDQo+IGVycmF0YSBzaGVl
dA0KPiBodHRwOi8vY2FjaGUuZnJlZXNjYWxlLmNvbS9maWxlcy9kc3AvZG9jL2VycmF0YS9JTVgz
NUNFLnBkZg0KPiBidXQgZGlkbid0IGZpbmQgYSBzaW1pbGFyICJsaW1pdGF0aW9uIiBhcyB5b3Ug
bm93IHBvaW50ZWQgb3V0IGJ5IGVycmF0YQ0KPiBudW1iZXIgMjg1OCBmb3IgaS5NWDIzLg0KPiAN
Cj4gV2hhdCBhYm91dCB0aGUgZml4IGZvciBtdl91ZGMsIHNob3VsZG4ndCB0aGV5IGhhdmUgYSBz
aW1pbGFyDQo+ICJsaW1pdGF0aW9uIj8gSG93IGRvIHlvdSBleHBsYWluPw0KPiBPciBtYXliZSBz
b21lb25lIGZyb20gTWFydmVsbCBoYXMgYW4gYW5zd2VyPw0KPiANCg0KWWVzLCB3ZSBlbmNvdW50
ZXJlZCB0aGUgc2FtZSBpc3N1ZSwgYW5kIEkgaGF2ZSBhbnN3ZXJlZCB5b3VyIHF1ZXN0aW9uIHNl
dmVyYWwgaG91cnMgYWdvLg0KUGxlYXNlIGhhdmUgYSBsb29rLg0KDQo+IA0KPiBUaGFua3MsDQo+
ICAtLSBDaHJpc3RvcGgNCg0KQmVzdCBSZWdhcmRzLA0KTmVpbCBaaGFuZw0K
^ permalink raw reply
* Re: [RFC] [PATCH] usb: gadget: fix dtd dma confusion
From: Christoph Fritz @ 2012-05-09 5:56 UTC (permalink / raw)
To: Chen Peter-B29397
Cc: Oliver Neukum, Kukjin Kim, Eric Miao, Li Yang-R58472,
Greg Kroah-Hartman, Sascha Hauer, linux-usb@vger.kernel.org,
Nicolas Ferre, linuxppc-dev@lists.ozlabs.org, Felipe Balbi,
Ido Shayevitz, Ben Dooks, Estevam Fabio-R49496, Hans J. Koch,
Haojian Zhuang, Daniel Mack, Thomas Dahlmann, Russell King,
Neil Zhang, Fabio Estevam, Chao Xie
In-Reply-To: <F281D0F91ED19E4D8E63A7504E8A649803B93001@039-SN2MPN1-022.039d.mgd.msft.net>
On Wed, May 09, 2012 at 05:43:11AM +0000, Chen Peter-B29397 wrote:
>
> >
> > I'm hacking here an i.MX35 not an i.MX23. So I already had a look at its
> > errata sheet http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf
> > but didn't find a similar "limitation" as you now pointed out by errata
> > number 2858 for i.MX23.
> >
>
> i.mx35 and i.mx23 uses the same controller.
A link or short note in i.MX35 its errata sheet to the i.MX23 one
would be nice.
^ permalink raw reply
* Re: [RFC] [PATCH] usb: gadget: fix dtd dma confusion
From: Christoph Fritz @ 2012-05-09 6:04 UTC (permalink / raw)
To: Neil Zhang
Cc: Oliver Neukum, Kukjin Kim, Eric Miao, Li Yang-R58472,
Chen Peter-B29397, Sascha Hauer, linux-usb@vger.kernel.org,
Nicolas Ferre, linuxppc-dev@lists.ozlabs.org, Felipe Balbi,
Ido Shayevitz, Thomas Dahlmann, Estevam Fabio-R49496,
Hans J. Koch, Haojian Zhuang, Daniel Mack, Greg Kroah-Hartman,
Russell King, Ben Dooks, Fabio Estevam, Chao Xie
In-Reply-To: <175CCF5F49938B4D99B2E3EF7F558EBE1A180E49D9@SC-VEXCH4.marvell.com>
Hi Neil,
thanks for you help.
> >
> > What about the fix for mv_udc, shouldn't they have a similar
> > "limitation"? How do you explain?
> > Or maybe someone from Marvell has an answer?
> >
>
> Yes, we encountered the same issue, and I have answered your question several hours ago.
> Please have a look.
Thanks for that.
Relating to the other *udc.c driver, do you think they should implement
a similar workaround there too or at least check their errataS?
Thanks,
-- Christoph
^ permalink raw reply
* Re: Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2012-05-09 11:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <CA+5PVA64YFcVrjwedn2V2pC8P87DXC1SEgbua+ZHF3VQr=FDmA@mail.gmail.com>
On Wed, May 2, 2012 at 9:51 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> Hi Ben,
>
> A few patches from Suzie for 47x kexec/kdump support, and some MSI patche=
s
> from Mai La.
>
> josh
>
> The following changes since commit ec34a6814988f17506733c1e8b058ce4660259=
1d:
>
> =A0powerpc: Remove old powerpc specific ptrace getregs/setregs calls
> (2012-04-30 15:37:28 +1000)
>
> are available in the git repository at:
>
> =A0git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git =
next
Bump? There's also one small addition on top to fix a build error with -We=
rror.
josh
^ permalink raw reply
* Re: powerpc/85xx: p2020rdb - move the NAND address.
From: Sebastian Andrzej Siewior @ 2012-05-09 19:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: Bryan Hundven, linuxppc-dev
In-Reply-To: <926BF56B-AA5C-443B-BD52-6844518810DB@kernel.crashing.org>
* Kumar Gala | 2012-03-31 09:48:18 [-0500]:
Sorry for the delay Kumar, I though I allready done it.
>Yes, please do.
Here it comes.
>From 5b3e09992615e5670fa8e432e50424466fa9ca1a Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Wed, 9 May 2012 21:48:42 +0200
Subject: [PATCH] Revert "powerpc/85xx: p2020rdb - move the NAND address."
This reverts commit 0c00f65653389a408dfbbee7578e671664eea26a.
The initial commit was my fault. There are two boards out there:
P2020RDB and P2020RDB-PC. I wasn't aware of that and assumed that I have
a RDB board in front of me while I the RDB-PC. This patch makes it work
for the RDB-PC variant and breaks it for the RDB. Now there is a device
tree file available for the RDB-PC which was not there earlier. So with
this revert, everything gets back to normal :)
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
arch/powerpc/boot/dts/p2020rdb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts b/arch/powerpc/boot/dts/p2020rdb.dts
index 153bc76..4d52bce 100644
--- a/arch/powerpc/boot/dts/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -34,7 +34,7 @@
/* NOR and NAND Flashes */
ranges = <0x0 0x0 0x0 0xef000000 0x01000000
- 0x1 0x0 0x0 0xff800000 0x00040000
+ 0x1 0x0 0x0 0xffa00000 0x00040000
0x2 0x0 0x0 0xffb00000 0x00020000>;
nor@0,0 {
--
1.7.10
>>>> Since both system have the same SoC and the NAND_SPL is always linked
>>>> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
>>>> later to 0xff800000 (or to 0xffa00000) and having it consistent among
>>>> both configs.
>>
>> what about this thing? Should leave it as it or move to the same
>> location? Since I have no HW *I* would prefer not to touch it :)
>
>Hmm, that implies a u-boot change, right?
Yup.
>- k
Sebastian
^ permalink raw reply related
* Re: [PATCH v2 2/3] ppc32/kprobe: complete kprobe and migrate exception frame
From: Benjamin Herrenschmidt @ 2012-05-10 3:50 UTC (permalink / raw)
To: Tiejun Chen; +Cc: linuxppc-dev
In-Reply-To: <1323946810-4868-3-git-send-email-tiejun.chen@windriver.com>
On Thu, 2011-12-15 at 19:00 +0800, Tiejun Chen wrote:
> We can't emulate stwu since that may corrupt current exception stack.
> So we will have to do real store operation in the exception return code.
>
> Firstly we'll allocate a trampoline exception frame below the kprobed
> function stack and copy the current exception frame to the trampoline.
> Then we can do this real store operation to implement 'stwu', and reroute
> the trampoline frame to r1 to complete this exception migration.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
> ---
> arch/powerpc/kernel/entry_32.S | 35 +++++++++++++++++++++++++++++++++++
> 1 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 56212bc..0cdd27d 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -850,6 +850,41 @@ resume_kernel:
>
> /* interrupts are hard-disabled at this point */
> restore:
> + lwz r3,_MSR(r1) /* Returning to user mode? */
> + andi. r0,r3,MSR_PR
> + bne 1f
.../...
Wouldn't it be better to use resume_kernel here ?
IE. We already have restore_user vs. resume_kernel labels, including
the PR test. In the !PREEMPT case, resume_kernel is empty but it's
there, so you can just "populate" it, ie, something like:
restore_user:
... existing dbcr0 stuff ...
b restore
resume_kernel: <-- removed the ifdef CONFIG_PREEMPT
... Do the stack store business here...
#ifdef CONFIG_PREEMPT
... move the preempt code here...
#endif
restore:
... existing stuff ...
Also, the added advantage is that the code to calc
the thread info pointer and load the TI_FLAG can be
shared now between your stuff and preempt, ie:
resume_kernel:
rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
lwz r0,TI_FLAGS(r9)
andis. r0,r0,_TIF_EMULATE_STACK_STORE@h
bne- emulate_stack_store
#ifdef CONFIG_PREEMPT
lwz r8,TI_PREEMPT(r9) <-- note use of r8 instead of r0,
I -think- r8 can be clobbered
here but pls dbl check
cmpwi 0,r8,0
bne restore
andi. r0,r0,_TIF_NEED_RESCHED
etc...
> + /* check current_thread_info, _TIF_EMULATE_STACK_STORE */
> + rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
> + lwz r0,TI_FLAGS(r9)
> + andis. r0,r0,_TIF_EMULATE_STACK_STORE@h
> + beq+ 1f
> +
> + addi r9,r1,INT_FRAME_SIZE /* Get the kprobed function entry */
> +
> + lwz r3,GPR1(r1)
> + subi r3,r3,INT_FRAME_SIZE /* dst: Allocate a trampoline exception frame */
> + mr r4,r1 /* src: current exception frame */
> + li r5,INT_FRAME_SIZE /* size: INT_FRAME_SIZE */
> + mr r1,r3 /* Reroute the trampoline frame to r1 */
> + bl memcpy /* Copy from the original to the trampoline */
> +
> + /* Do real store operation to complete stwu */
> + lwz r5,GPR1(r1)
> + stw r9,0(r5)
Ok, I think I -finally- understand your trick of using r1 +
INT_FRAME_SIZE as the value to store :-) It makes sense and it's
actually a nice hack :-)
I would recommend that in the C code part of the emulation, you
add some sanity checking to make sure we don't overflow the
kernel stack etc... it should come in generally handy especially
if what's your trying to debug with kprobes is a kernel stack
overflow :-)
> + /* Clear _TIF_EMULATE_STACK_STORE flag */
> + rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
> + lis r11,_TIF_EMULATE_STACK_STORE@h
> + addi r9,r9,TI_FLAGS
> +0: lwarx r8,0,r9
> + andc r8,r8,r11
> +#ifdef CONFIG_IBM405_ERR77
> + dcbt 0,r9
> +#endif
> + stwcx. r8,0,r9
> + bne- 0b
> +1:
> +
> #ifdef CONFIG_44x
> BEGIN_MMU_FTR_SECTION
> b 1f
BTW. Are you going to do a ppc64 variant of that patch ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/1] ppc64: fix missing to check all bits of _TIF_USER_WORK_MASK in preempt
From: Benjamin Herrenschmidt @ 2012-05-10 4:00 UTC (permalink / raw)
To: Tiejun Chen; +Cc: linuxppc-dev
In-Reply-To: <1323681035-19350-1-git-send-email-tiejun.chen@windriver.com>
On Mon, 2011-12-12 at 17:10 +0800, Tiejun Chen wrote:
>
> -#ifdef CONFIG_PREEMPT
> - clrrdi r9,r1,THREAD_SHIFT /* current_thread_info() */
> - li r0,_TIF_NEED_RESCHED /* bits to check */
> - ld r3,_MSR(r1)
> - ld r4,TI_FLAGS(r9)
> - /* Move MSR_PR bit in r3 to _TIF_SIGPENDING position in r0 */
> - rlwimi r0,r3,32+TIF_SIGPENDING-MSR_PR_LG,_TIF_SIGPENDING
> - and. r0,r4,r0 /* check NEED_RESCHED and maybe SIGPENDING */
> - bne do_work
> -
> -#else /* !CONFIG_PREEMPT */
> ld r3,_MSR(r1) /* Returning to user mode? */
> andi. r3,r3,MSR_PR
> - beq restore /* if not, just restore regs and return */
> + bne test_work_user
Any reason to not use restore_user / resume_kernel like ppc32 ? It might
help whoever wants to look at that code in the future if we make both
sides a bit closer :-) Not a big deal and if you prefer like this I
don't have a firm objection
> + clrrdi r9,r1,THREAD_SHIFT /* current_thread_info() */
> + li r0,_TIF_USER_WORK_MASK
> +#ifdef CONFIG_PREEMPT
> + ori r0,r0,_TIF_NEED_RESCHED
> +#endif
Why the above ? Doesn't _TIF_USER_WORK_MASK altready contain
TIF_NEED_RESCHED ? Also this is the kernel path, I'd rather just
define something along the lines of _TIF_KERNEL_WORK_MASK.
Then, you change the definition of it based on PREEMPT, ie:
#ifdef CONFIG_PREEMPT
#define _TIF_KERNEL_WORK_MASK _TIF_NEED_RESCHED
#else
#define _TIF_KERNEL_WORK_MASK 0
#endif
Now, that does mean that you'll have a useless test without PREEMPT
here but ... it will stop being useless as soon as you port over
the stux emulation so it's fine as a placeholder.
> + ld r4,TI_FLAGS(r9)
> + and. r0,r4,r0 /* check NEED_RESCHED and maybe _TIF_USER_WORK_MASK */
> + bne do_kernel_work
> + b restore /* if so, just restore regs and return */
> +
> +test_work_user:
> /* Check current_thread_info()->flags */
> clrrdi r9,r1,THREAD_SHIFT
> ld r4,TI_FLAGS(r9)
> andi. r0,r4,_TIF_USER_WORK_MASK
> - bne do_work
> -#endif
> + bne do_user_work
>
> restore:
> BEGIN_FW_FTR_SECTION
> @@ -693,10 +692,8 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
> b .ret_from_except_lite /* loop back and handle more */
> #endif
>
> -do_work:
> +do_kernel_work:
> #ifdef CONFIG_PREEMPT
> - andi. r0,r3,MSR_PR /* Returning to user mode? */
> - bne user_work
> /* Check that preempt_count() == 0 and interrupts are enabled */
> lwz r8,TI_PREEMPT(r9)
> cmpwi cr1,r8,0
> @@ -738,9 +735,9 @@ do_work:
> bne 1b
> b restore
>
> -user_work:
> #endif /* CONFIG_PREEMPT */
>
> +do_user_work:
> /* Enable interrupts */
> #ifdef CONFIG_PPC_BOOK3E
> wrteei 1
^ permalink raw reply
* Re: [PATCH] powerpc: use local var instead of local_paca->irq_happened directly in __check_irq_replay
From: Wang Sheng-Hui @ 2012-05-10 5:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, linux-kernel, Milton Miller, Anton Blanchard,
linuxppc-dev
In-Reply-To: <1336448796.2540.187.camel@pasglop>
On 2012年05月08日 11:46, Benjamin Herrenschmidt wrote:
> Hi Wang !
>
> Does this patch fixes it for you ?
>
Sorry, this patch doesn't work. And my system crashed again with the patch.
======================================================
# kernel BUG at /usr/src/kernels/linux/arch/powerpc/kernel/irq.c:188!
cpu 0x0: Vector: 700 (Program Check) at [c00000026ffebbb0]
pc: c00000000000ea9c: .__check_irq_replay+0x7c/0x90
lr: c000000000010578: .arch_local_irq_restore+0x38/0x90
sp: c00000026ffebe30
msr: 8000000000029032
current = 0xc000000000e27be0
paca = 0xc000000003580000 softe: 0 irq_happened: 0x01
pid = 0, comm = swapper/0
kernel BUG at /usr/src/kernels/linux/arch/powerpc/kernel/irq.c:188!
enter ? for help
[link register ] c000000000010578 .arch_local_irq_restore+0x38/0x90
[c00000026ffebe30] c000000000f42100 softirq_vec+0x0/0x80 (unreliable)
[c00000026ffebea0] c000000000085854 .__do_softirq+0xa4/0x2a0
[c00000026ffebf90] c0000000000229b8 .call_do_softirq+0x14/0x24
[c000000000edf870] c0000000000106c8 .do_softirq+0xf8/0x130
[c000000000edf910] c000000000085544 .irq_exit+0xc4/0xf0
[c000000000edf990] c0000000000100a4 .do_IRQ+0xe4/0x310
[c000000000edfa50] c0000000000038c0 hardware_interrupt_common+0x140/0x180
--- Exception: 501 (Hardware Interrupt) at c0000000000105b4 .arch_local_irq_restore+0x74/0x90
[c000000000edfd40] c000000000058480 .pSeries_idle+0x10/0x40 (unreliable)
[c000000000edfdb0] c000000000017d70 .cpu_idle+0x190/0x290
[c000000000edfe70] c00000000000b308 .rest_init+0x88/0xa0
[c000000000edfef0] c0000000008c0d1c .start_kernel+0x554/0x574
[c000000000edff90] c000000000009658 .start_here_common+0x20/0x48
0:mon> e
cpu 0x0: Vector: 700 (Program Check) at [c00000026ffebbb0]
pc: c00000000000ea9c: .__check_irq_replay+0x7c/0x90
lr: c000000000010578: .arch_local_irq_restore+0x38/0x90
sp: c00000026ffebe30
msr: 8000000000029032
current = 0xc000000000e27be0
paca = 0xc000000003580000 softe: 0 irq_happened: 0x01
pid = 0, comm = swapper/0
kernel BUG at /usr/src/kernels/linux/arch/powerpc/kernel/irq.c:188!
0:mon> r
R00 = 0000000000000001 R16 = 0000000003680000
R01 = c00000026ffebe30 R17 = 000000000021ed0f
R02 = c000000000edd228 R18 = 000000000021efbb
R03 = 0000000000000500 R19 = 000000000021ee84
R04 = 0000000000000000 R20 = c000000000f42100
R05 = 00000000000007ea R21 = 0000000000000000
R06 = 00000000273f6d30 R22 = c000000000955b80
R07 = 00363d0e68097e11 R23 = c000000000955b80
R08 = 00000000008c0000 R24 = 000000000000000a
R09 = c000000003580000 R25 = 0000000000000000
R10 = 0000000000000001 R26 = c000000000edc100
R11 = 0000000000000000 R27 = c00000026ffe8000
R12 = 0000000000000002 R28 = 0000000000000000
R13 = c000000003580000 R29 = c000000000f42100
R14 = 0000000002e1fa78 R30 = c000000000e60890
R15 = 0000000001173000 R31 = 0000000000000040
pc = c00000000000ea9c .__check_irq_replay+0x7c/0x90
cfar= c00000000000ea3c .__check_irq_replay+0x1c/0x90
lr = c000000000010578 .arch_local_irq_restore+0x38/0x90
msr = 8000000000029032 cr = 28000048
ctr = c000000000063f70 xer = 0000000000000001 trap = 700
0:mon> t
[link register ] c000000000010578 .arch_local_irq_restore+0x38/0x90
[c00000026ffebe30] c000000000f42100 softirq_vec+0x0/0x80 (unreliable)
[c00000026ffebea0] c000000000085854 .__do_softirq+0xa4/0x2a0
[c00000026ffebf90] c0000000000229b8 .call_do_softirq+0x14/0x24
[c000000000edf870] c0000000000106c8 .do_softirq+0xf8/0x130
[c000000000edf910] c000000000085544 .irq_exit+0xc4/0xf0
[c000000000edf990] c0000000000100a4 .do_IRQ+0xe4/0x310
[c000000000edfa50] c0000000000038c0 hardware_interrupt_common+0x140/0x180
--- Exception: 501 (Hardware Interrupt) at c0000000000105b4 .arch_local_irq_restore+0x74/0x90
[c000000000edfd40] c000000000058480 .pSeries_idle+0x10/0x40 (unreliable)
[c000000000edfdb0] c000000000017d70 .cpu_idle+0x190/0x290
[c000000000edfe70] c00000000000b308 .rest_init+0x88/0xa0
[c000000000edfef0] c0000000008c0d1c .start_kernel+0x554/0x574
[c000000000edff90] c000000000009658 .start_here_common+0x20/0x48
0:mon> di
> From 249f8649bf95a4c3e6637284754a165c1d83c394 Mon Sep 17 00:00:00 2001
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Tue, 8 May 2012 13:31:59 +1000
> Subject: [PATCH 2/3] powerpc/irq: Fix bug with new lazy IRQ handling code
>
> We had a case where we could turn on hard interrupts while
> leaving the PACA_IRQ_HARD_DIS bit set in the PACA. This can
> in turn cause a BUG_ON() to hit in __check_irq_replay() due
> to interrupt state getting out of sync.
>
> The assembly code was also way too convoluted. Instead, we
> now leave it to the C code to do the right thing which ends
> up being smaller and more readable.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/entry_64.S | 18 ------------------
> arch/powerpc/kernel/irq.c | 8 +++++++-
> 2 files changed, 7 insertions(+), 19 deletions(-)
>
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index fd46046..29f1357 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -763,16 +763,6 @@ do_work:
> SOFT_DISABLE_INTS(r3,r4)
> 1: bl .preempt_schedule_irq
>
> - /* Hard-disable interrupts again (and update PACA) */
> -#ifdef CONFIG_PPC_BOOK3E
> - wrteei 0
> -#else
> - ld r10,PACAKMSR(r13) /* Get kernel MSR without EE */
> - mtmsrd r10,1
> -#endif /* CONFIG_PPC_BOOK3E */
> - li r0,PACA_IRQ_HARD_DIS
> - stb r0,PACAIRQHAPPENED(r13)
> -
> /* Re-test flags and eventually loop */
> clrrdi r9,r1,THREAD_SHIFT
> ld r4,TI_FLAGS(r9)
> @@ -783,14 +773,6 @@ do_work:
> user_work:
> #endif /* CONFIG_PREEMPT */
>
> - /* Enable interrupts */
> -#ifdef CONFIG_PPC_BOOK3E
> - wrteei 1
> -#else
> - ori r10,r10,MSR_EE
> - mtmsrd r10,1
> -#endif /* CONFIG_PPC_BOOK3E */
> -
> andi. r0,r4,_TIF_NEED_RESCHED
> beq 1f
> bl .restore_interrupts
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 5ec1b23..3717fb5 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -260,11 +260,17 @@ EXPORT_SYMBOL(arch_local_irq_restore);
> * if they are currently disabled. This is typically called before
> * schedule() or do_signal() when returning to userspace. We do it
> * in C to avoid the burden of dealing with lockdep etc...
> + *
> + * NOTE: This is called with interrupts hard disabled but not marked
> + * as such in paca->irq_happened, so we need to resync this.
> */
> void restore_interrupts(void)
> {
> - if (irqs_disabled())
> + if (irqs_disabled()) {
> + local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
> local_irq_enable();
> + } else
> + __hard_irq_enable();
> }
>
> #endif /* CONFIG_PPC64 */
^ permalink raw reply
* Re: [PATCH 1/1] page_alloc.c: remove argument to pageblock_default_order
From: Mel Gorman @ 2012-05-10 13:34 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-ia64, rajman mekaco, linux-kernel, linux-mm, Minchan Kim,
Tejun Heo, linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <20120503163749.d24bf07f.akpm@linux-foundation.org>
On Thu, May 03, 2012 at 04:37:49PM -0700, Andrew Morton wrote:
> On Thu, 3 May 2012 22:45:12 +0530
> rajman mekaco <rajman.mekaco@gmail.com> wrote:
>
> > When CONFIG_HUGETLB_PAGE_SIZE_VARIABLE is not defined, then
> > pageblock_default_order has an argument to it.
> >
> > However, free_area_init_core will call it without any argument
> > anyway.
> >
> > Remove the argument to pageblock_default_order when
> > CONFIG_HUGETLB_PAGE_SIZE_VARIABLE is not defined.
> >
> > Signed-off-by: rajman mekaco <rajman.mekaco@gmail.com>
> > ---
> > mm/page_alloc.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index a712fb9..4b95412 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -4274,7 +4274,7 @@ static inline void __init set_pageblock_order(unsigned int order)
> > * at compile-time. See include/linux/pageblock-flags.h for the values of
> > * pageblock_order based on the kernel config
> > */
> > -static inline int pageblock_default_order(unsigned int order)
> > +static inline int pageblock_default_order(void)
> > {
> > return MAX_ORDER-1;
> > }
>
> Interesting. It has been that way since at least 3.1.
>
/me slaps self
> It didn't break the build because pageblock_default_order() is only
> ever invoked by set_pageblock_order(), with:
>
> set_pageblock_order(pageblock_default_order());
>
> and set_pageblock_order() is a macro:
>
> #define set_pageblock_order(x) do {} while (0)
>
> There's yet another reason not to use macros, dammit - they hide bugs.
>
>
> Mel, can you have a think about this please? Can we just kill off
> pageblock_default_order() and fold its guts into
> set_pageblock_order(void)? Only ia64 and powerpc can define
> CONFIG_HUGETLB_PAGE_SIZE_VARIABLE.
>
This looks reasonable to me.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [PATCH] powerpc: Support lower minimum entitlement for virtual processors
From: Robert Jennings @ 2012-05-09 15:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1335763810.20866.38.camel@pasglop>
* Benjamin Herrenschmidt (benh@kernel.crashing.org) wrote:
> On Fri, 2012-03-23 at 16:22 -0500, Robert Jennings wrote:
> > This patch changes the architecture vector to advertise support for a
> > lower minimum virtual processor entitled capacity. The default
> > minimum without this patch is 10%, this patch specifies 5%. This will
> > allow 20 LPARs per CPU rather than only 10.
>
> Any reason why we don't just put 1% in there and thus don't have to
> change again when pHyp decides to lower their minimum ? :-)
>
> (Can you test that it works, ie, that pHyp doesn't barf if we put 1% and
> properly uses 5% in that case ?)
Thanks Ben, makes good sense.
I'm in the process of validating this and I'll post reply or a new
version of the patch when I get it completed.
--Rob Jennings
> > Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/kernel/prom_init.c | 8 ++++++--
> > 1 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> > index eca626e..3d882ea 100644
> > --- a/arch/powerpc/kernel/prom_init.c
> > +++ b/arch/powerpc/kernel/prom_init.c
> > @@ -689,6 +689,9 @@ static void __init early_cmdline_parse(void)
> > #define OV3_VMX 0x40 /* VMX/Altivec */
> > #define OV3_DFP 0x20 /* decimal FP */
> >
> > +/* Option vector 4: IBM PAPR implementation */
> > +#define OV4_MIN_ENT_CAP 0x05 /* minimum VP entitled capacity */
> > +
> > /* Option vector 5: PAPR/OF options supported */
> > #define OV5_LPAR 0x80 /* logical partitioning supported */
> > #define OV5_SPLPAR 0x40 /* shared-processor LPAR supported */
> > @@ -753,8 +756,9 @@ static unsigned char ibm_architecture_vec[] = {
> > OV3_FP | OV3_VMX | OV3_DFP,
> >
> > /* option vector 4: IBM PAPR implementation */
> > - 2 - 2, /* length */
> > + 3 - 2, /* length */
> > 0, /* don't halt */
> > + OV4_MIN_ENT_CAP, /* minimum VP entitled capacity */
> >
> > /* option vector 5: PAPR/OF options */
> > 13 - 2, /* length */
> > @@ -771,7 +775,7 @@ static unsigned char ibm_architecture_vec[] = {
> > * must match by the macro below. Update the definition if
> > * the structure layout changes.
> > */
> > -#define IBM_ARCH_VEC_NRCORES_OFFSET 100
> > +#define IBM_ARCH_VEC_NRCORES_OFFSET 101
> > W(NR_CPUS), /* number of cores supported */
> >
> > /* option vector 6: IBM PAPR hints */
>
>
^ permalink raw reply
* [PATCH][v2] powerpc: Support lower minimum entitlement for virtual processors
From: Robert Jennings @ 2012-05-10 18:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, Robert Jennings
This patch changes the architecture vector to advertise support for a
lower minimum virtual processor entitled capacity. The default
minimum without this patch is 10%, this patch specifies 1%.
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
Dropped minimum to 1% and tested to ensure that pHYP handled this properly.
---
arch/powerpc/kernel/prom_init.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index eca626e..46a3c42 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -689,6 +689,9 @@ static void __init early_cmdline_parse(void)
#define OV3_VMX 0x40 /* VMX/Altivec */
#define OV3_DFP 0x20 /* decimal FP */
+/* Option vector 4: IBM PAPR implementation */
+#define OV4_MIN_ENT_CAP 0x01 /* minimum VP entitled capacity */
+
/* Option vector 5: PAPR/OF options supported */
#define OV5_LPAR 0x80 /* logical partitioning supported */
#define OV5_SPLPAR 0x40 /* shared-processor LPAR supported */
@@ -753,8 +756,9 @@ static unsigned char ibm_architecture_vec[] = {
OV3_FP | OV3_VMX | OV3_DFP,
/* option vector 4: IBM PAPR implementation */
- 2 - 2, /* length */
+ 3 - 2, /* length */
0, /* don't halt */
+ OV4_MIN_ENT_CAP, /* minimum VP entitled capacity */
/* option vector 5: PAPR/OF options */
13 - 2, /* length */
@@ -771,7 +775,7 @@ static unsigned char ibm_architecture_vec[] = {
* must match by the macro below. Update the definition if
* the structure layout changes.
*/
-#define IBM_ARCH_VEC_NRCORES_OFFSET 100
+#define IBM_ARCH_VEC_NRCORES_OFFSET 101
W(NR_CPUS), /* number of cores supported */
/* option vector 6: IBM PAPR hints */
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v3 03/17] powerpc: Add PFO support to the VIO bus
From: Robert Jennings @ 2012-05-10 19:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Kent Yoder, linuxppc-dev, linux-kernel, linux-crypto
In-Reply-To: <1335841603.3621.8.camel@pasglop>
* Benjamin Herrenschmidt (benh@kernel.crashing.org) wrote:
> Hrm... I don't like that much:
>
> > + if (op->timeout)
> > + deadline = jiffies + msecs_to_jiffies(op->timeout);
> > +
> > + while (true) {
> > + hret = plpar_hcall_norets(H_COP, op->flags,
> > + vdev->resource_id,
> > + op->in, op->inlen, op->out,
> > + op->outlen, op->csbcpb);
> > +
> > + if (hret == H_SUCCESS ||
> > + (hret != H_NOT_ENOUGH_RESOURCES &&
> > + hret != H_BUSY && hret != H_RESOURCE) ||
> > + (op->timeout && time_after(deadline, jiffies)))
> > + break;
> > +
> > + dev_dbg(dev, "%s: hcall ret(%ld), retrying.\n", __func__, hret);
> > + }
> > +
>
> Is this meant to be called in atomic context ? If not, maybe it should
> at the very least do a cond_resched() ?
>
> Else, what about ceding the processor ? Or at the very least reducing
> the thread priority for a bit ?
>
> Shouldn't we also enforce to always have a timeout ? IE. Something like
> 30s or so if nothing specified to avoid having the kernel just hard
> lock...
>
> In general I don't like that sort of synchronous code, I'd rather return
> the busy status up the chain which gives a chance to the caller to take
> more appropriate measures depending on what it's doing, but that really
> depends what you use that synchronous call for. I suppose if it's for
> configuration type operations, it's ok...
This function is called in atomic context, it is used by PFO-type device
drivers to perform operations with the nest accelerator unit (like
crypto acceleration).
Having the timeout and retries in this function is the wrong thing to do.
We'll resubmit this without the loop and the caller will be responsible for
retrying the operations.
I would rather have the caller cede the processor or alter thread
priority where appropriate than doing that in this function. I don't
think this should be done in this crypto driver.
--Rob Jennings
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/p1022ds/DTS: Add RTC support
From: Tabi Timur-B04825 @ 2012-05-10 21:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: Huang Changming-R66093, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1334626955-8069-2-git-send-email-Chang-Ming.Huang@freescale.com>
On Mon, Apr 16, 2012 at 8:42 PM, <Chang-Ming.Huang@freescale.com> wrote:
> From: Jerry Huang <Chang-Ming.Huang@freescale.com>
>
> Add the RTC support for p1022ds
>
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
Kumar, please apply for 3.5.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/mpc85xx: p1022ds support the MTD for NOR and NAND flash
From: Tabi Timur-B04825 @ 2012-05-10 21:04 UTC (permalink / raw)
To: Huang Changming-R66093, Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1334626955-8069-1-git-send-email-Chang-Ming.Huang@freescale.com>
On Mon, Apr 16, 2012 at 8:42 PM, <Chang-Ming.Huang@freescale.com> wrote:
> From: Jerry Huang <Chang-Ming.Huang@freescale.com>
>
> The compatilbe 'simple-bus' is removed from the latest DTS for NAND and
> NOR flash partition, so we must add the new compatilbe support for p1022d=
s,
> otherwise, the kernel can't parse the partition of NOR and NAND flash.
>
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> ---
This patch is no longer compatible with the upstream kernel since my
patch, "powerpc/85xx: don't call of_platform_bus_probe() twice" was
applied. This is because my patch removed p1022_ds_ids[].
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH v3 03/17] powerpc: Add PFO support to the VIO bus
From: Benjamin Herrenschmidt @ 2012-05-10 21:58 UTC (permalink / raw)
To: Robert Jennings; +Cc: Kent Yoder, linuxppc-dev, linux-kernel, linux-crypto
In-Reply-To: <20120510190835.GB12304@linux.vnet.ibm.com>
On Thu, 2012-05-10 at 14:08 -0500, Robert Jennings wrote:
> * Benjamin Herrenschmidt (benh@kernel.crashing.org) wrote:
> > Is this meant to be called in atomic context ? If not, maybe it should
> > at the very least do a cond_resched() ?
> >
> > Else, what about ceding the processor ? Or at the very least reducing
> > the thread priority for a bit ?
> >
> > Shouldn't we also enforce to always have a timeout ? IE. Something like
> > 30s or so if nothing specified to avoid having the kernel just hard
> > lock...
> >
> > In general I don't like that sort of synchronous code, I'd rather return
> > the busy status up the chain which gives a chance to the caller to take
> > more appropriate measures depending on what it's doing, but that really
> > depends what you use that synchronous call for. I suppose if it's for
> > configuration type operations, it's ok...
>
> This function is called in atomic context, it is used by PFO-type device
> drivers to perform operations with the nest accelerator unit (like
> crypto acceleration).
>
> Having the timeout and retries in this function is the wrong thing to do.
> We'll resubmit this without the loop and the caller will be responsible for
> retrying the operations.
>
> I would rather have the caller cede the processor or alter thread
> priority where appropriate than doing that in this function. I don't
> think this should be done in this crypto driver.
That sounds right indeed... as long as the upper crypto layer has a
concept of "try again later"... if it doesn't it will result in random
funny failures :-)
Cheers,
Ben.
^ permalink raw reply
* [BUG] powerpc: perf record crash
From: Sukadev Bhattiprolu @ 2012-05-11 0:23 UTC (permalink / raw)
To: linuxppc-dev
I get this crash when I run on 3.4.0-rc5 on a P6.
./perf record -a -d -- ./perf bench sched all
I rebuilt 'perf' locally after building the kernel 3.4.0-rc5.
Sometimes it occurs on the first attempt, sometimes on the second.
Pls let me know if I can provide any other debug info.
----
Red Hat Enterprise Linux Server release 6.2 (Santiago)
Kernel 3.4.0-rc5-mainline on an ppc64
stormy2 login: kernel BUG at arch/powerpc/kernel/irq.c:188!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: ipv6 bnx2 ses enclosure sg ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr radeon drm_kms_helper ttm drm i2c_algo_bit i2c_core power_supply dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
NIP: c00000000000ea9c LR: c000000000010548 CTR: 0000000000000000
REGS: c00000006de879f0 TRAP: 0700 Not tainted (3.4.0-rc5-mainline)
MSR: 8000000000021032 <SF,ME,IR,DR,RI> CR: 22000088 XER: 00000000
SOFTE: 0
CFAR: 0000000000003318
TASK = c00000006de62d50[0] 'swapper/7' THREAD: c00000006de84000 CPU: 7
GPR00: 0000000000000001 c00000006de87c70 c000000000c47d88 0000000000000500
GPR04: 000000000bf87ff4 0000000000000000 0000000000000007 000e1cfe2fc642ff
GPR08: 00000000007e0000 c000000006df1500 0000000000000001 0000000000000000
GPR12: 0000000042000088 c000000006df1500 c00000006de87f90 0000000006f042c0
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 8000000000009032
GPR24: c00000006de84000 0000000000000000 c000000000e356d0 c000000000cd0318
GPR28: c0000000006229b8 c000000000b55f58 c000000000bce190 c000000000ff8eb0
NIP [c00000000000ea9c] .__check_irq_replay+0x7c/0x90
LR [c000000000010548] .arch_local_irq_restore+0x38/0x90
Call Trace:
[c00000006de87c70] [00000000832e13f4] 0x832e13f4 (unreliable)
[c00000006de87ce0] [c0000000004ca118] .cpuidle_idle_call+0x1f8/0x380
[c00000006de87da0] [c000000000055450] .pSeries_idle+0x10/0x40
[c00000006de87e10] [c000000000017ce8] .cpu_idle+0x178/0x290
[c00000006de87ed0] [c0000000006081f0] .start_secondary+0x350/0x35c
[c00000006de87f90] [c00000000000936c] .start_secondary_prolog+0x10/0x14
Instruction dump:
4e800020 7da96b78 8809022b 794bf7e3 38600500 5400e87e 5400183e 9809022b
4082ffdc 880d022b 7c0000d0 78000fe0 <0b000000> 38600000 4bffffc4 60000000
---[ end trace 39f49db612f9ab0f ]---
Kernel panic - not syncing: Attempted to kill the idle task!
panic occurred, switching back to text console
Dumping ftrace buffer:
(ftrace buffer empty)
Current pid: 6199 comm: perf / Idle pid: 0 comm: swapper/7
------------[ cut here ]------------
WARNING: at kernel/rcutree.c:465
Modules linked in: ipv6 bnx2 ses enclosure sg ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr radeon drm_kms_helper ttm drm i2c_algo_bit i2c_core power_supply dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
NIP: c000000000110aa0 LR: c000000000110a9c CTR: c000000000060f40
REGS: c000000068b96e00 TRAP: 0700 Tainted: G D (3.4.0-rc5-mainline)
MSR: 8000000000021032 <SF,ME,IR,DR,RI> CR: 28022482 XER: 0000000a
SOFTE: 0
CFAR: c000000000602cc4
TASK = c000000059620090[6199] 'perf' THREAD: c000000068b94000 CPU: 7
GPR00: c000000000110a9c c000000068b97080 c000000000c47d88 000000000000003d
GPR04: 0000000000000000 0000000000000000 0000000000000000 800000000b2a3d80
GPR08: 0000000000000000 c000000000804208 000000000002ef30 00000000007e0000
GPR12: 0000000024022488 c000000006df1500 c000000069c8db00 c000000000815b80
GPR16: c000000000815b80 0000000000000000 c000000068b97750 c000000000caed60
GPR20: c000000068b94080 0000000000000001 0000000000000000 0000000000000004
GPR24: c000000000815b80 c000000000cacad8 c000000068b94000 0000000000000000
GPR28: c0000000008155f0 c00000006de62d50 c000000000bd5c40 c000000000b88053
NIP [c000000000110aa0] .rcu_idle_exit_common+0xc0/0x100
LR [c000000000110a9c] .rcu_idle_exit_common+0xbc/0x100
Call Trace:
[c000000068b97080] [c000000000110a9c] .rcu_idle_exit_common+0xbc/0x100 (unreliable)
[c000000068b97110] [c000000000110b98] .rcu_irq_enter+0xb8/0xe0
[c000000068b97190] [c00000000007b5ec] .irq_enter+0x1c/0xc0
[c000000068b97220] [c000000000010024] .do_IRQ+0x64/0x2e0
[c000000068b972e0] [c0000000000038c0] hardware_interrupt_common+0x140/0x180
--- Exception: 501 at .arch_local_irq_restore+0x74/0x90
LR = .arch_local_irq_restore+0x74/0x90
[c000000068b975d0] [c0000000000b35e8] .update_rq_clock+0x48/0x80 (unreliable)
[c000000068b97640] [c0000000000b319c] .finish_task_switch+0x7c/0x150
[c000000068b976e0] [c0000000005f62b0] .__schedule+0x2f0/0x6e0
[c000000068b97960] [c0000000001d0ac4] .pipe_wait+0x64/0xa0
[c000000068b97a20] [c0000000001d1578] .pipe_read+0x3d8/0x670
[c000000068b97b50] [c0000000001c35a4] .do_sync_read+0xb4/0x140
[c000000068b97ce0] [c0000000001c475c] .vfs_read+0xec/0x1e0
[c000000068b97d80] [c0000000001c4978] .SyS_read+0x58/0xd0
[c000000068b97e30] [c0000000000097dc] syscall_exit+0x0/0x38
Instruction dump:
881f000e 2f800001 41feffbc e92d0200 e8ad0200 e889022e e8dd022e e87e8120
38a503c8 38fd03c8 484f21fd 60000000 <0fe00000> 38000001 981f000e 4bffff88
---[ end trace 39f49db612f9ab10 ]---
Current pid: 6199 comm: perf / Idle pid: 0 comm: swapper/7
------------[ cut here ]------------
WARNING: at kernel/rcutree.c:355
Modules linked in: ipv6 bnx2 ses enclosure sg ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr radeon drm_kms_helper ttm drm i2c_algo_bit i2c_core power_supply dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
NIP: c000000000110d80 LR: c000000000110d7c CTR: c000000000060f40
REGS: c000000068b96e10 TRAP: 0700 Tainted: G D W (3.4.0-rc5-mainline)
MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28022482 XER: 0000000a
SOFTE: 0
CFAR: c000000000602cc4
TASK = c000000059620090[6199] 'perf' THREAD: c000000068b94000 CPU: 7
GPR00: c000000000110d7c c000000068b97090 c000000000c47d88 000000000000003d
GPR04: 0000000000000000 0000000000000000 0000000000000000 800000000b2a3d80
GPR08: 0000000000000000 c000000000804208 00000000000399f0 00000000007e0000
GPR12: 0000000028022488 c000000006df1500 c000000069c8db00 c000000000815b80
GPR16: c000000000815b80 0000000000000000 c000000068b97750 c000000000caed60
GPR20: c000000068b94080 0000000000000001 0000000000000010 c000000068b94100
GPR24: 0000000000000000 c000000068b94000 c0000000e7fac000 0000000000000000
GPR28: c00000006de62d50 c000000000b88053 c000000000bd5c40 c000000000fe4bf8
NIP [c000000000110d80] .rcu_idle_enter_common+0xd0/0x110
LR [c000000000110d7c] .rcu_idle_enter_common+0xcc/0x110
Call Trace:
[c000000068b97090] [c000000000110d7c] .rcu_idle_enter_common+0xcc/0x110 (unreliable)
[c000000068b97120] [c000000000110e74] .rcu_irq_exit+0xb4/0xe0
[c000000068b971a0] [c00000000007b3ec] .irq_exit+0x8c/0xf0
[c000000068b97220] [c000000000010094] .do_IRQ+0xd4/0x2e0
[c000000068b972e0] [c0000000000038c0] hardware_interrupt_common+0x140/0x180
--- Exception: 501 at .arch_local_irq_restore+0x74/0x90
LR = .arch_local_irq_restore+0x74/0x90
[c000000068b975d0] [c0000000000b35e8] .update_rq_clock+0x48/0x80 (unreliable)
[c000000068b97640] [c0000000000b319c] .finish_task_switch+0x7c/0x150
[c000000068b976e0] [c0000000005f62b0] .__schedule+0x2f0/0x6e0
[c000000068b97960] [c0000000001d0ac4] .pipe_wait+0x64/0xa0
[c000000068b97a20] [c0000000001d1578] .pipe_read+0x3d8/0x670
[c000000068b97b50] [c0000000001c35a4] .do_sync_read+0xb4/0x140
[c000000068b97ce0] [c0000000001c475c] .vfs_read+0xec/0x1e0
[c000000068b97d80] [c0000000001c4978] .SyS_read+0x58/0xd0
[c000000068b97e30] [c0000000000097dc] syscall_exit+0x0/0x38
Instruction dump:
881d0011 2f800001 41feff8c e92d0200 e8ad0200 e889022e e8dc022e e87e8120
38a503c8 38fc03c8 484f1f1d 60000000 <0fe00000> 38000001 981d0011 4bffff58
---[ end trace 39f49db612f9ab11 ]---
Rebooting in 10 seconds..
^ permalink raw reply
* Re: [BUG] powerpc: perf record crash
From: Benjamin Herrenschmidt @ 2012-05-11 0:37 UTC (permalink / raw)
To: Sukadev Bhattiprolu; +Cc: linuxppc-dev
In-Reply-To: <20120511002354.GA8895@us.ibm.com>
On Thu, 2012-05-10 at 17:23 -0700, Sukadev Bhattiprolu wrote:
> I get this crash when I run on 3.4.0-rc5 on a P6.
>
> ./perf record -a -d -- ./perf bench sched all
>
> I rebuilt 'perf' locally after building the kernel 3.4.0-rc5.
>
> Sometimes it occurs on the first attempt, sometimes on the second.
> Pls let me know if I can provide any other debug info.
It looks like the same bug that Wang Sheng-Hui <shhuiw@gmail.com>
reported, I'm still tracking it. I pushed a patch upstream that I
thought fixed it but according to Wang, it's still around.
Looking at it now.
Cheers,
Ben.
> ----
>
> Red Hat Enterprise Linux Server release 6.2 (Santiago)
> Kernel 3.4.0-rc5-mainline on an ppc64
>
> stormy2 login: kernel BUG at arch/powerpc/kernel/irq.c:188!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in: ipv6 bnx2 ses enclosure sg ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr radeon drm_kms_helper ttm drm i2c_algo_bit i2c_core power_supply dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
> NIP: c00000000000ea9c LR: c000000000010548 CTR: 0000000000000000
> REGS: c00000006de879f0 TRAP: 0700 Not tainted (3.4.0-rc5-mainline)
> MSR: 8000000000021032 <SF,ME,IR,DR,RI> CR: 22000088 XER: 00000000
> SOFTE: 0
> CFAR: 0000000000003318
> TASK = c00000006de62d50[0] 'swapper/7' THREAD: c00000006de84000 CPU: 7
> GPR00: 0000000000000001 c00000006de87c70 c000000000c47d88 0000000000000500
> GPR04: 000000000bf87ff4 0000000000000000 0000000000000007 000e1cfe2fc642ff
> GPR08: 00000000007e0000 c000000006df1500 0000000000000001 0000000000000000
> GPR12: 0000000042000088 c000000006df1500 c00000006de87f90 0000000006f042c0
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000 8000000000009032
> GPR24: c00000006de84000 0000000000000000 c000000000e356d0 c000000000cd0318
> GPR28: c0000000006229b8 c000000000b55f58 c000000000bce190 c000000000ff8eb0
> NIP [c00000000000ea9c] .__check_irq_replay+0x7c/0x90
> LR [c000000000010548] .arch_local_irq_restore+0x38/0x90
> Call Trace:
> [c00000006de87c70] [00000000832e13f4] 0x832e13f4 (unreliable)
> [c00000006de87ce0] [c0000000004ca118] .cpuidle_idle_call+0x1f8/0x380
> [c00000006de87da0] [c000000000055450] .pSeries_idle+0x10/0x40
> [c00000006de87e10] [c000000000017ce8] .cpu_idle+0x178/0x290
> [c00000006de87ed0] [c0000000006081f0] .start_secondary+0x350/0x35c
> [c00000006de87f90] [c00000000000936c] .start_secondary_prolog+0x10/0x14
> Instruction dump:
> 4e800020 7da96b78 8809022b 794bf7e3 38600500 5400e87e 5400183e 9809022b
> 4082ffdc 880d022b 7c0000d0 78000fe0 <0b000000> 38600000 4bffffc4 60000000
> ---[ end trace 39f49db612f9ab0f ]---
>
> Kernel panic - not syncing: Attempted to kill the idle task!
> panic occurred, switching back to text console
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Current pid: 6199 comm: perf / Idle pid: 0 comm: swapper/7
> ------------[ cut here ]------------
> WARNING: at kernel/rcutree.c:465
> Modules linked in: ipv6 bnx2 ses enclosure sg ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr radeon drm_kms_helper ttm drm i2c_algo_bit i2c_core power_supply dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
> NIP: c000000000110aa0 LR: c000000000110a9c CTR: c000000000060f40
> REGS: c000000068b96e00 TRAP: 0700 Tainted: G D (3.4.0-rc5-mainline)
> MSR: 8000000000021032 <SF,ME,IR,DR,RI> CR: 28022482 XER: 0000000a
> SOFTE: 0
> CFAR: c000000000602cc4
> TASK = c000000059620090[6199] 'perf' THREAD: c000000068b94000 CPU: 7
> GPR00: c000000000110a9c c000000068b97080 c000000000c47d88 000000000000003d
> GPR04: 0000000000000000 0000000000000000 0000000000000000 800000000b2a3d80
> GPR08: 0000000000000000 c000000000804208 000000000002ef30 00000000007e0000
> GPR12: 0000000024022488 c000000006df1500 c000000069c8db00 c000000000815b80
> GPR16: c000000000815b80 0000000000000000 c000000068b97750 c000000000caed60
> GPR20: c000000068b94080 0000000000000001 0000000000000000 0000000000000004
> GPR24: c000000000815b80 c000000000cacad8 c000000068b94000 0000000000000000
> GPR28: c0000000008155f0 c00000006de62d50 c000000000bd5c40 c000000000b88053
> NIP [c000000000110aa0] .rcu_idle_exit_common+0xc0/0x100
> LR [c000000000110a9c] .rcu_idle_exit_common+0xbc/0x100
> Call Trace:
> [c000000068b97080] [c000000000110a9c] .rcu_idle_exit_common+0xbc/0x100 (unreliable)
> [c000000068b97110] [c000000000110b98] .rcu_irq_enter+0xb8/0xe0
> [c000000068b97190] [c00000000007b5ec] .irq_enter+0x1c/0xc0
> [c000000068b97220] [c000000000010024] .do_IRQ+0x64/0x2e0
> [c000000068b972e0] [c0000000000038c0] hardware_interrupt_common+0x140/0x180
> --- Exception: 501 at .arch_local_irq_restore+0x74/0x90
> LR = .arch_local_irq_restore+0x74/0x90
> [c000000068b975d0] [c0000000000b35e8] .update_rq_clock+0x48/0x80 (unreliable)
> [c000000068b97640] [c0000000000b319c] .finish_task_switch+0x7c/0x150
> [c000000068b976e0] [c0000000005f62b0] .__schedule+0x2f0/0x6e0
> [c000000068b97960] [c0000000001d0ac4] .pipe_wait+0x64/0xa0
> [c000000068b97a20] [c0000000001d1578] .pipe_read+0x3d8/0x670
> [c000000068b97b50] [c0000000001c35a4] .do_sync_read+0xb4/0x140
> [c000000068b97ce0] [c0000000001c475c] .vfs_read+0xec/0x1e0
> [c000000068b97d80] [c0000000001c4978] .SyS_read+0x58/0xd0
> [c000000068b97e30] [c0000000000097dc] syscall_exit+0x0/0x38
> Instruction dump:
> 881f000e 2f800001 41feffbc e92d0200 e8ad0200 e889022e e8dd022e e87e8120
> 38a503c8 38fd03c8 484f21fd 60000000 <0fe00000> 38000001 981f000e 4bffff88
> ---[ end trace 39f49db612f9ab10 ]---
> Current pid: 6199 comm: perf / Idle pid: 0 comm: swapper/7
> ------------[ cut here ]------------
> WARNING: at kernel/rcutree.c:355
> Modules linked in: ipv6 bnx2 ses enclosure sg ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr radeon drm_kms_helper ttm drm i2c_algo_bit i2c_core power_supply dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
> NIP: c000000000110d80 LR: c000000000110d7c CTR: c000000000060f40
> REGS: c000000068b96e10 TRAP: 0700 Tainted: G D W (3.4.0-rc5-mainline)
> MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28022482 XER: 0000000a
> SOFTE: 0
> CFAR: c000000000602cc4
> TASK = c000000059620090[6199] 'perf' THREAD: c000000068b94000 CPU: 7
> GPR00: c000000000110d7c c000000068b97090 c000000000c47d88 000000000000003d
> GPR04: 0000000000000000 0000000000000000 0000000000000000 800000000b2a3d80
> GPR08: 0000000000000000 c000000000804208 00000000000399f0 00000000007e0000
> GPR12: 0000000028022488 c000000006df1500 c000000069c8db00 c000000000815b80
> GPR16: c000000000815b80 0000000000000000 c000000068b97750 c000000000caed60
> GPR20: c000000068b94080 0000000000000001 0000000000000010 c000000068b94100
> GPR24: 0000000000000000 c000000068b94000 c0000000e7fac000 0000000000000000
> GPR28: c00000006de62d50 c000000000b88053 c000000000bd5c40 c000000000fe4bf8
> NIP [c000000000110d80] .rcu_idle_enter_common+0xd0/0x110
> LR [c000000000110d7c] .rcu_idle_enter_common+0xcc/0x110
> Call Trace:
> [c000000068b97090] [c000000000110d7c] .rcu_idle_enter_common+0xcc/0x110 (unreliable)
> [c000000068b97120] [c000000000110e74] .rcu_irq_exit+0xb4/0xe0
> [c000000068b971a0] [c00000000007b3ec] .irq_exit+0x8c/0xf0
> [c000000068b97220] [c000000000010094] .do_IRQ+0xd4/0x2e0
> [c000000068b972e0] [c0000000000038c0] hardware_interrupt_common+0x140/0x180
> --- Exception: 501 at .arch_local_irq_restore+0x74/0x90
> LR = .arch_local_irq_restore+0x74/0x90
> [c000000068b975d0] [c0000000000b35e8] .update_rq_clock+0x48/0x80 (unreliable)
> [c000000068b97640] [c0000000000b319c] .finish_task_switch+0x7c/0x150
> [c000000068b976e0] [c0000000005f62b0] .__schedule+0x2f0/0x6e0
> [c000000068b97960] [c0000000001d0ac4] .pipe_wait+0x64/0xa0
> [c000000068b97a20] [c0000000001d1578] .pipe_read+0x3d8/0x670
> [c000000068b97b50] [c0000000001c35a4] .do_sync_read+0xb4/0x140
> [c000000068b97ce0] [c0000000001c475c] .vfs_read+0xec/0x1e0
> [c000000068b97d80] [c0000000001c4978] .SyS_read+0x58/0xd0
> [c000000068b97e30] [c0000000000097dc] syscall_exit+0x0/0x38
> Instruction dump:
> 881d0011 2f800001 41feff8c e92d0200 e8ad0200 e889022e e8dc022e e87e8120
> 38a503c8 38fc03c8 484f1f1d 60000000 <0fe00000> 38000001 981d0011 4bffff58
> ---[ end trace 39f49db612f9ab11 ]---
> Rebooting in 10 seconds..
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc/irq: Fix another case of lazy IRQ state getting out of sync
From: Benjamin Herrenschmidt @ 2012-05-11 2:12 UTC (permalink / raw)
To: Sukadev Bhattiprolu, Wang Sheng-Hui; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1336696621.3881.72.camel@pasglop>
So we have another case of paca->irq_happened getting out of
sync with the HW irq state. This can happen when a perfmon
interrupt occurs while soft disabled, as it will return to a
soft disabled but hard enabled context while leaving a stale
PACA_IRQ_HARD_DIS flag set.
This patch fixes it, and also adds a test for the condition
of those flags being out of sync in arch_local_irq_restore()
when CONFIG_TRACE_IRQFLAGS is enabled.
This helps catching those gremlins faster (and so far I
can't seem see any anymore, so that's good news).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Please test ASAP as I need to send that to Linus today
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index f8a7a1a..293e283 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -588,23 +588,19 @@ _GLOBAL(ret_from_except_lite)
fast_exc_return_irq:
restore:
/*
- * This is the main kernel exit path, we first check if we
- * have to change our interrupt state.
+ * This is the main kernel exit path. First we check if we
+ * are about to re-enable interrupts
*/
ld r5,SOFTE(r1)
lbz r6,PACASOFTIRQEN(r13)
- cmpwi cr1,r5,0
- cmpw cr0,r5,r6
- beq cr0,4f
+ cmpwi cr0,r5,0
+ beq restore_irq_off
- /* We do, handle disable first, which is easy */
- bne cr1,3f;
- li r0,0
- stb r0,PACASOFTIRQEN(r13);
- TRACE_DISABLE_INTS
- b 4f
+ /* We are enabling, were we already enabled ? Yes, just return */
+ cmpwi cr0,r6,1
+ beq cr0,do_restore
-3: /*
+ /*
* We are about to soft-enable interrupts (we are hard disabled
* at this point). We check if there's anything that needs to
* be replayed first.
@@ -626,7 +622,7 @@ restore_no_replay:
/*
* Final return path. BookE is handled in a different file
*/
-4:
+do_restore:
#ifdef CONFIG_PPC_BOOK3E
b .exception_return_book3e
#else
@@ -700,6 +696,25 @@ fast_exception_return:
#endif /* CONFIG_PPC_BOOK3E */
/*
+ * We are returning to a context with interrupts soft disabled.
+ *
+ * However, we may also about to hard enable, so we need to
+ * make sure that in this case, we also clear PACA_IRQ_HARD_DIS
+ * or that bit can get out of sync and bad things will happen
+ */
+restore_irq_off:
+ ld r3,_MSR(r1)
+ lbz r7,PACAIRQHAPPENED(r13)
+ andi. r0,r3,MSR_EE
+ beq 1f
+ rlwinm r7,r7,0,~PACA_IRQ_HARD_DIS
+ stb r7,PACAIRQHAPPENED(r13)
+1: li r0,0
+ stb r0,PACASOFTIRQEN(r13);
+ TRACE_DISABLE_INTS
+ b do_restore
+
+ /*
* Something did happen, check if a re-emit is needed
* (this also clears paca->irq_happened)
*/
@@ -748,6 +763,9 @@ restore_check_irq_replay:
#endif /* CONFIG_PPC_BOOK3E */
1: b .ret_from_except /* What else to do here ? */
+
+
+3:
do_work:
#ifdef CONFIG_PREEMPT
andi. r0,r3,MSR_PR /* Returning to user mode? */
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 5ec1b23..fe8cf8e 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -229,6 +229,19 @@ notrace void arch_local_irq_restore(unsigned long en)
*/
if (unlikely(irq_happened != PACA_IRQ_HARD_DIS))
__hard_irq_disable();
+#ifdef CONFIG_TRACE_IRQFLAG
+ else {
+ /*
+ * We should already be hard disabled here. We had bugs
+ * where that wasn't the case so let's dbl check it and
+ * warn if we are wrong. Only do that when IRQ tracing
+ * is enabled as mfmsr() can be costly.
+ */
+ if (WARN_ON(mfmsr() & MSR_EE))
+ __hard_irq_disable();
+ }
+#endif /* CONFIG_TRACE_IRQFLAG */
+
set_soft_enabled(0);
/*
^ permalink raw reply related
* Re: linux-next: Tree for May 10 (net/phy)
From: Paul Gortmaker @ 2012-05-11 2:36 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, linuxppc-dev, LKML, netdev
In-Reply-To: <4FAC35E2.4060900@xenotime.net>
On Thu, May 10, 2012 at 5:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On 05/10/2012 02:26 AM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20120508:
>
>
>
> ERROR: "of_mdio_find_bus" [drivers/net/phy/mdio-mux.ko] undefined!
Not just randconfig, but also powerpc allmodconfig:
http://kisskb.ellerman.id.au/kisskb/buildresult/6291463/
Adding ppc ML to cc.
P.
--
>
> Full randconfig file is attached.
>
> --
> ~Randy
^ permalink raw reply
* Re: linux-next: Tree for May 10 (net/phy)
From: David Miller @ 2012-05-11 2:43 UTC (permalink / raw)
To: paul.gortmaker
Cc: sfr, david.daney, netdev, linux-kernel, rdunlap, linux-next,
linuxppc-dev
In-Reply-To: <CAP=VYLon7XRoh9s==wGYjUPNAYaTk8QQx7FGRnaDR97v+O-zXA@mail.gmail.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 10 May 2012 22:36:55 -0400
> On Thu, May 10, 2012 at 5:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> On 05/10/2012 02:26 AM, Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20120508:
>>
>>
>>
>> ERROR: "of_mdio_find_bus" [drivers/net/phy/mdio-mux.ko] undefined!
>
> Not just randconfig, but also powerpc allmodconfig:
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/6291463/
>
> Adding ppc ML to cc.
Adding the guilty party to the CC:. This really stinks, especially
after I did give the patch submitter a hard time about getting the
dependencies right. :-/
^ permalink raw reply
* [PATCH 2/2][v2] powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_PPC_FSL_BOOK3E
From: Shaohui Xie @ 2012-05-11 5:33 UTC (permalink / raw)
To: linux-watchdog, linuxppc-dev; +Cc: Shaohui Xie
CONFIG_FSL_BOOKE is only defined in 32-bit, CONFIG_PPC_FSL_BOOK3E is
defined in both 32-bit and 64-bit, so use CONFIG_PPC_FSL_BOOK3E to make
driver work in 32-bit & 64-bit.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
---
changes for v2:
use PPC_FSL_BOOK3E instead of FSL_SOC_BOOKE.
drivers/watchdog/Kconfig | 8 ++++----
drivers/watchdog/booke_wdt.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 3709624..4373ca0 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1094,10 +1094,10 @@ config BOOKE_WDT
config BOOKE_WDT_DEFAULT_TIMEOUT
int "PowerPC Book-E Watchdog Timer Default Timeout"
depends on BOOKE_WDT
- default 38 if FSL_BOOKE
- range 0 63 if FSL_BOOKE
- default 3 if !FSL_BOOKE
- range 0 3 if !FSL_BOOKE
+ default 38 if PPC_FSL_BOOK3E
+ range 0 63 if PPC_FSL_BOOK3E
+ default 3 if !PPC_FSL_BOOK3E
+ range 0 3 if !PPC_FSL_BOOK3E
help
Select the default watchdog timer period to be used by the PowerPC
Book-E watchdog driver. A watchdog "event" occurs when the bit
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index ce0ab44..338a437 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -37,7 +37,7 @@
u32 booke_wdt_enabled;
u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
-#ifdef CONFIG_FSL_BOOKE
+#ifdef CONFIG_PPC_FSL_BOOK3E
#define WDTP(x) ((((x)&0x3)<<30)|(((x)&0x3c)<<15))
#define WDTP_MASK (WDTP(0x3f))
#else
@@ -190,7 +190,7 @@ static long booke_wdt_ioctl(struct file *file,
case WDIOC_SETTIMEOUT:
if (get_user(tmp, p))
return -EFAULT;
-#ifdef CONFIG_FSL_BOOKE
+#ifdef CONFIG_PPC_FSL_BOOK3E
/* period of 1 gives the largest possible timeout */
if (tmp > period_to_sec(1))
return -EINVAL;
--
1.6.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