* [RFC] [PATCH] usb: gadget: fix dtd dma confusion
From: Christoph Fritz @ 2012-05-09 0:02 UTC (permalink / raw)
To: Fabio Estevam, Neil Zhang, Li Yang, Felipe Balbi,
Greg Kroah-Hartman, linux-usb, linuxppc-dev, Hans J. Koch,
Daniel Mack
Cc: Oliver Neukum, Kukjin Kim, Eric Miao, Chen Peter-B29397,
Sascha Hauer, Nicolas Ferre, Haojian Zhuang, Estevam Fabio-R49496,
Ido Shayevitz, Ben Dooks, Thomas Dahlmann, Russell King
In-Reply-To: <CAOMZO5C729Ki0Bequ+s1nnrgt4NZWvwg3Wnjk4kHp=d9BtkeXw@mail.gmail.com>
On Wed, Apr 11, 2012 at 10:15:49AM -0300, Fabio Estevam wrote:
> On Wed, Apr 11, 2012 at 4:39 AM, Christoph Fritz
> <chf.fritz@googlemail.com> wrote:
>
> > Can you approve this behaviour of g_ether/usbnet when using iperf?
>
> I am not very familiar with iperf, so I will let others comment.
Hi to All,
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.
See here:
daec765da767e4a6a30e1298862b28f2cae9a73f
usb: gadget: mv_udc: fix dtd dma confusion
So hereby I'm CC-ing all *udc.c maintainers to point out that this
issue maybe affects you too.
And maybe someone can explain if this:
+ if (curr_td->next_td_ptr == EP_QUEUE_HEAD_NEXT_TERMINATE) {
is necessary and why (please see below).
Thanks,
-- Christoph
---
Subject: [PATCH] usb: gadget: fsl_udc: fix dtd dma confusion
The controller will hang when doing testings with g_ether and iperf
(tool for measuring maximum TCP and UDP bandwidth). This patch adds a
delay to wait for controller to release dtd dma before freeing it.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
drivers/usb/gadget/fsl_udc_core.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index 55abfb6..fc86108 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -1638,6 +1638,15 @@ static int process_ep_req(struct fsl_udc *udc, int pipe,
status = REQ_UNCOMPLETE;
return status;
} else if (remaining_length) {
+ /* wait controller release dtd dma */
+ while ((curr_qh->curr_dtd_ptr == curr_td->td_dma)) {
+ if (curr_td->next_td_ptr ==
+ EP_QUEUE_HEAD_NEXT_TERMINATE) {
+ udelay(100);
+ break;
+ }
+ udelay(1);
+ }
if (direction) {
VDBG("Transmit dTD remaining length not zero");
status = -EPROTO;
--
1.7.2.5
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-05-09 1:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a couple of last minute fixes for 3.4 for regressions
introduced by my rewrite of the lazy irq masking code.
Cheers,
Ben.
The following changes since commit 810b4de25e53459323ff48957b0162b48d6cbd57:
tty/serial/pmac_zilog: Fix "nobody cared" IRQ message (2012-04-30 10:59:58 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to a3512b2dd57cb653bb33645ca9c934436e547e3c:
powerpc/irq: Make alignment & program interrupt behave the same (2012-05-09 09:42:33 +1000)
----------------------------------------------------------------
Benjamin Herrenschmidt (2):
powerpc/irq: Fix bug with new lazy IRQ handling code
powerpc/irq: Make alignment & program interrupt behave the same
arch/powerpc/include/asm/exception-64s.h | 7 -------
arch/powerpc/kernel/entry_64.S | 18 ------------------
arch/powerpc/kernel/exceptions-64s.S | 2 +-
arch/powerpc/kernel/irq.c | 8 +++++++-
arch/powerpc/kernel/traps.c | 10 ++++++++--
5 files changed, 16 insertions(+), 29 deletions(-)
^ permalink raw reply
* RE: [RFC] [PATCH] usb: gadget: fix dtd dma confusion
From: Neil Zhang @ 2012-05-09 1:50 UTC (permalink / raw)
To: Christoph Fritz, Fabio Estevam, Li Yang, Felipe Balbi,
Greg Kroah-Hartman, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Hans J. Koch, Daniel Mack
Cc: Oliver Neukum, Kukjin Kim, Eric Miao, Chen Peter-B29397,
Sascha Hauer, Nicolas Ferre, Haojian Zhuang, Estevam Fabio-R49496,
Ido Shayevitz, Ben Dooks, Thomas Dahlmann, Russell King, Chao Xie
In-Reply-To: <20120509000221.GA19525@lovely.krouter>
SGkgQ2hyaXN0b3BoLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENo
cmlzdG9waCBGcml0eiBbbWFpbHRvOmNoZi5mcml0ekBnb29nbGVtYWlsLmNvbV0NCj4gU2VudDog
MjAxMsTqNdTCOcjVIDg6MDINCj4gVG86IEZhYmlvIEVzdGV2YW07IE5laWwgWmhhbmc7IExpIFlh
bmc7IEZlbGlwZSBCYWxiaTsgR3JlZyBLcm9haC0NCj4gSGFydG1hbjsgbGludXgtdXNiQHZnZXIu
a2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IEhhbnMNCj4gSi4gS29j
aDsgRGFuaWVsIE1hY2sNCj4gQ2M6IFRob21hcyBEYWhsbWFubjsgTmljb2xhcyBGZXJyZTsgRXJp
YyBNaWFvOyBSdXNzZWxsIEtpbmc7IEhhb2ppYW4NCj4gWmh1YW5nOyBCZW4gRG9va3M7IEt1a2pp
biBLaW07IFNhc2NoYSBIYXVlcjsgT2xpdmVyIE5ldWt1bTsgQ2hlbiBQZXRlci0NCj4gQjI5Mzk3
OyBJZG8gU2hheWV2aXR6OyBFc3RldmFtIEZhYmlvLVI0OTQ5Ng0KPiBTdWJqZWN0OiBbUkZDXSBb
UEFUQ0hdIHVzYjogZ2FkZ2V0OiBmaXggZHRkIGRtYSBjb25mdXNpb24NCj4gDQo+IE9uIFdlZCwg
QXByIDExLCAyMDEyIGF0IDEwOjE1OjQ5QU0gLTAzMDAsIEZhYmlvIEVzdGV2YW0gd3JvdGU6DQo+
ID4gT24gV2VkLCBBcHIgMTEsIDIwMTIgYXQgNDozOSBBTSwgQ2hyaXN0b3BoIEZyaXR6DQo+ID4g
PGNoZi5mcml0ekBnb29nbGVtYWlsLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiA+IENhbiB5b3UgYXBw
cm92ZSB0aGlzIGJlaGF2aW91ciBvZiBnX2V0aGVyL3VzYm5ldCB3aGVuIHVzaW5nIGlwZXJmPw0K
PiA+DQo+ID4gSSBhbSBub3QgdmVyeSBmYW1pbGlhciB3aXRoIGlwZXJmLCBzbyBJIHdpbGwgbGV0
IG90aGVycyBjb21tZW50Lg0KPiANCj4gSGkgdG8gQWxsLA0KPiANCj4gYWZ0ZXIgYSB3aGlsZSBv
ZiB0ZXN0aW5nIGFuZCBzZWFyY2hpbmcgSSBjYW4gY29tZSB1cCB3aXRoIGEgcGF0Y2gNCj4gdGhh
dCBmaXhlcyBnX2V0aGVyIDwtPiBpcGVyZiBmb3IgZnNsX3VkYyBvbiBBUk0gaS5NWDM1Lg0KPiAN
Cj4gVGhlIHNhZCBwYXJ0IGlzIHRoYXQgdGhpcyBraW5kIG9mIGZpeCBpcyBhbHJlYWR5IGltcGxl
bWVudGVkIGZvcg0KPiBtYXJ2ZWxsIG12X3VkYyBkcml2ZXIgc2luY2UgbGFzdCB5ZWFyIGJ1dCBz
dGlsbCBfbm90XyBpbiB0aGUgfjE1DQo+IG90aGVyICp1ZGMuYyBkcml2ZXJzLg0KPiANCj4gU2Vl
IGhlcmU6DQo+IGRhZWM3NjVkYTc2N2U0YTZhMzBlMTI5ODg2MmIyOGYyY2FlOWE3M2YNCj4gdXNi
OiBnYWRnZXQ6IG12X3VkYzogZml4IGR0ZCBkbWEgY29uZnVzaW9uDQo+IA0KPiBTbyBoZXJlYnkg
SSdtIENDLWluZyBhbGwgKnVkYy5jIG1haW50YWluZXJzIHRvIHBvaW50IG91dCB0aGF0IHRoaXMN
Cj4gaXNzdWUgbWF5YmUgYWZmZWN0cyB5b3UgdG9vLg0KPiANCj4gQW5kIG1heWJlIHNvbWVvbmUg
Y2FuIGV4cGxhaW4gaWYgdGhpczoNCj4gKwkJCQlpZiAoY3Vycl90ZC0+bmV4dF90ZF9wdHIgPT0N
Cj4gRVBfUVVFVUVfSEVBRF9ORVhUX1RFUk1JTkFURSkgew0KPiBpcyBuZWNlc3NhcnkgYW5kIHdo
eSAocGxlYXNlIHNlZSBiZWxvdykuDQo+IA0KIA0KVGhlIG91dGVyIGxvb3AgaXMgdG8gY2hlY2sg
d2hldGhlciB0aGUgY29udHJvbGxlciBzdGlsbCBwb2ludCB0byB0aGUgY3VycmVudCBkdGQuDQpJ
ZiBzbywgd2Ugc2hvdWxkIHdhaXQgaXQgdG8gbW92ZSBvbnRvIHRoZSBuZXh0IGR0ZC4NCkJ1dCB0
aGVyZSBpcyBhbiBleGNlcHRpb24sIGlmIHRoZSBjdXJyZW50IGR0ZCBpcyB0aGUgbGFzdCBkdGQg
b24gdGhpcyBlcCBxdWV1ZSwgDQp0aGVuIHRoZSBjb250cm9sbGVyIGNhbiBuZXZlciBtb3ZlIG9u
Lg0KRm9ydHVuYXRlbHksIHdlIGNhbiBjaGVjayByZWdpc3RlciBlcHN0YXR1cyAob2Zmc2V0OiAw
eDFiOCkgdG8gc2VlIHdoZXRoZXIgdGhlIGJ1ZmZlciBpcyBmcmVlIGFnYWluLg0KDQo+IFRoYW5r
cywNCj4gIC0tIENocmlzdG9waA0KPiANCj4gLS0tDQo+IFN1YmplY3Q6IFtQQVRDSF0gdXNiOiBn
YWRnZXQ6IGZzbF91ZGM6IGZpeCBkdGQgZG1hIGNvbmZ1c2lvbg0KPiANCj4gVGhlIGNvbnRyb2xs
ZXIgd2lsbCBoYW5nIHdoZW4gZG9pbmcgdGVzdGluZ3Mgd2l0aCBnX2V0aGVyIGFuZCBpcGVyZg0K
PiAodG9vbCBmb3IgbWVhc3VyaW5nIG1heGltdW0gVENQIGFuZCBVRFAgYmFuZHdpZHRoKS4gIFRo
aXMgcGF0Y2ggYWRkcyBhDQo+IGRlbGF5IHRvIHdhaXQgZm9yIGNvbnRyb2xsZXIgdG8gcmVsZWFz
ZSBkdGQgZG1hIGJlZm9yZSBmcmVlaW5nIGl0Lg0KPiANCj4gU2lnbmVkLW9mZi1ieTogQ2hyaXN0
b3BoIEZyaXR6IDxjaGYuZnJpdHpAZ29vZ2xlbWFpbC5jb20+DQo+IC0tLQ0KPiAgZHJpdmVycy91
c2IvZ2FkZ2V0L2ZzbF91ZGNfY29yZS5jIHwgICAgOSArKysrKysrKysNCj4gIDEgZmlsZXMgY2hh
bmdlZCwgOSBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdpdCBh
L2RyaXZlcnMvdXNiL2dhZGdldC9mc2xfdWRjX2NvcmUuYw0KPiBiL2RyaXZlcnMvdXNiL2dhZGdl
dC9mc2xfdWRjX2NvcmUuYw0KPiBpbmRleCA1NWFiZmI2Li5mYzg2MTA4IDEwMDY0NA0KPiAtLS0g
YS9kcml2ZXJzL3VzYi9nYWRnZXQvZnNsX3VkY19jb3JlLmMNCj4gKysrIGIvZHJpdmVycy91c2Iv
Z2FkZ2V0L2ZzbF91ZGNfY29yZS5jDQo+IEBAIC0xNjM4LDYgKzE2MzgsMTUgQEAgc3RhdGljIGlu
dCBwcm9jZXNzX2VwX3JlcShzdHJ1Y3QgZnNsX3VkYyAqdWRjLA0KPiBpbnQgcGlwZSwNCj4gIAkJ
CXN0YXR1cyA9IFJFUV9VTkNPTVBMRVRFOw0KPiAgCQkJcmV0dXJuIHN0YXR1czsNCj4gIAkJfSBl
bHNlIGlmIChyZW1haW5pbmdfbGVuZ3RoKSB7DQo+ICsJCQkvKiB3YWl0IGNvbnRyb2xsZXIgcmVs
ZWFzZSBkdGQgZG1hICovDQo+ICsJCQl3aGlsZSAoKGN1cnJfcWgtPmN1cnJfZHRkX3B0ciA9PSBj
dXJyX3RkLT50ZF9kbWEpKSB7DQo+ICsJCQkJaWYgKGN1cnJfdGQtPm5leHRfdGRfcHRyID09DQo+
ICsJCQkJCQlFUF9RVUVVRV9IRUFEX05FWFRfVEVSTUlOQVRFKSB7DQo+ICsJCQkJCXVkZWxheSgx
MDApOw0KPiArCQkJCQlicmVhazsNCj4gKwkJCQl9DQo+ICsJCQkJdWRlbGF5KDEpOw0KPiArCQkJ
fQ0KPiAgCQkJaWYgKGRpcmVjdGlvbikgew0KPiAgCQkJCVZEQkcoIlRyYW5zbWl0IGRURCByZW1h
aW5pbmcgbGVuZ3RoIG5vdCB6ZXJvIik7DQo+ICAJCQkJc3RhdHVzID0gLUVQUk9UTzsNCj4gLS0N
Cj4gMS43LjIuNQ0KPiANCg0KQmVzdCBSZWdhcmRzLA0KTmVpbCBaaGFuZw0K
^ permalink raw reply
* RE: [RFC] [PATCH] usb: gadget: fix dtd dma confusion
From: Chen Peter-B29397 @ 2012-05-09 2:11 UTC (permalink / raw)
To: Neil Zhang, Christoph Fritz, Fabio Estevam, Li Yang-R58472,
Felipe Balbi, Greg Kroah-Hartman, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Hans J. Koch, Daniel Mack
Cc: Oliver Neukum, Kukjin Kim, Eric Miao, Estevam Fabio-R49496,
Sascha Hauer, Nicolas Ferre, Haojian Zhuang, Ido Shayevitz,
Ben Dooks, Thomas Dahlmann, Russell King, Chao Xie
In-Reply-To: <175CCF5F49938B4D99B2E3EF7F558EBE1A180E49BA@SC-VEXCH4.marvell.com>
=20
> >
> > 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.
> >
=20
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
BR,
Peter
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile fail in hugetlb cmdline parsing
From: Benjamin Herrenschmidt @ 2012-05-09 3:04 UTC (permalink / raw)
To: Rusty Russell
Cc: Jim Cromie, Greg Kroah-Hartman, Jason Baron, Paul Gortmaker,
linux-next, linuxppc-dev
In-Reply-To: <878vh3cncz.fsf@rustcorp.com.au>
On Tue, 2012-05-08 at 13:53 +0930, Rusty Russell wrote:
> On Mon, 7 May 2012 10:32:22 -0400, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> > Commit 9fb48c744ba6a4bf58b666f4e6fdac3008ea1bd4
> >
> > "params: add 3rd arg to option handler callback signature"
> >
> > added an extra arg to the function, but didn't catch all the use
> > cases needing it, causing this compile fail in mpc85xx_defconfig:
> >
> > arch/powerpc/mm/hugetlbpage.c:316:4: error: passing argument 7 of
> > 'parse_args' from incompatible pointer type [-Werror]
> >
> > include/linux/moduleparam.h:317:12: note: expected
> > 'int (*)(char *, char *, const char *)' but argument is of type
> > 'int (*)(char *, char *)'
> >
> > This function has no need to printk out the "doing" value, so
> > just add the arg as an "unused".
> >
> > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > Cc: Jim Cromie <jim.cromie@gmail.com>
> > Cc: Jason Baron <jbaron@redhat.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Becky Bruce <beckyb@kernel.crashing.org>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> Acked-by: Rusty Russell <rusty@rustcorp.com.au>
This is for -next right ? IE. I don't seem to have the faulty commit
in my tree so I can't carry the fix for now.... or am I missing
something ?
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/watchdog: move booke watchdog param related code to prom.c
From: Xie Shaohui-B21989 @ 2012-05-09 3:20 UTC (permalink / raw)
To: Bhushan Bharat-R65777, linux-watchdog@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D03CF692C@039-SN2MPN1-023.039d.mgd.msft.net>
>> -----Original Message-----
>> From:
>> linuxppc-dev-bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org
>> [mailto:linuxppc-dev-bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs
>> .org] On Behalf Of Shaohui Xie
>> Sent: Tuesday, May 08, 2012 11:37 AM
>> To: linux-watchdog@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
>> Cc: Xie Shaohui-B21989
>> Subject: [PATCH 1/2] powerpc/watchdog: move booke watchdog param
>> related code to prom.c
>>
>> Currently, BOOKE watchdog code for checking "wdt" and "wdt_period" is
>> in setup_32.c, it cannot be used in 64-bit, so move it to a common
>> place prom.c, which will be shared by 32-bit and 64-bit.
>>
>> Also, replace the simple_strtoul with kstrtol.
>>
>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>> ---
>> arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++
>> arch/powerpc/kernel/setup_32.c | 24 ------------------------
>> 2 files changed, 27 insertions(+), 24 deletions(-)
>
>Is not setup-common.c is better place to move this?
Move out from setup_32.c does not mean it have to go into setup-common.c, I=
need better reason to do this.
Best Regards,=20
Shaohui Xie
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/watchdog: move booke watchdog param related code to prom.c
From: Bhushan Bharat-R65777 @ 2012-05-09 3:27 UTC (permalink / raw)
To: Xie Shaohui-B21989, linux-watchdog@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <ED492CCEAF882048BC2237DE806547C90B2EB2@039-SN2MPN1-013.039d.mgd.msft.net>
> -----Original Message-----
> From: Xie Shaohui-B21989
> Sent: Wednesday, May 09, 2012 8:50 AM
> To: Bhushan Bharat-R65777; linux-watchdog@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Subject: RE: [PATCH 1/2] powerpc/watchdog: move booke watchdog param rela=
ted
> code to prom.c
>=20
> >> -----Original Message-----
> >> From:
> >> linuxppc-dev-bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org
> >> [mailto:linuxppc-dev-bounces+bharat.bhushan=3Dfreescale.com@lists.ozla=
b
> >> s
> >> .org] On Behalf Of Shaohui Xie
> >> Sent: Tuesday, May 08, 2012 11:37 AM
> >> To: linux-watchdog@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> >> Cc: Xie Shaohui-B21989
> >> Subject: [PATCH 1/2] powerpc/watchdog: move booke watchdog param
> >> related code to prom.c
> >>
> >> Currently, BOOKE watchdog code for checking "wdt" and "wdt_period" is
> >> in setup_32.c, it cannot be used in 64-bit, so move it to a common
> >> place prom.c, which will be shared by 32-bit and 64-bit.
> >>
> >> Also, replace the simple_strtoul with kstrtol.
> >>
> >> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> >> ---
> >> arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++
> >> arch/powerpc/kernel/setup_32.c | 24 ------------------------
> >> 2 files changed, 27 insertions(+), 24 deletions(-)
> >
> >Is not setup-common.c is better place to move this?
>=20
> Move out from setup_32.c does not mean it have to go into setup-common.c,=
I need
> better reason to do this.
>=20
What I think that setup_32.c is for 32 bit, setup_64.c is for 64 bit and se=
tup-common.c is for both.
I am not saying that you move this to setup-common.c. I am asking why you h=
ave not used setup-common.c ? I am ok even with prom.c.
Thanks
-Bharat
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/watchdog: move booke watchdog param related code to prom.c
From: Xie Shaohui-B21989 @ 2012-05-09 3:42 UTC (permalink / raw)
To: Bhushan Bharat-R65777, linux-watchdog@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D03CF86B7@039-SN2MPN1-023.039d.mgd.msft.net>
>> -----Original Message-----
>> From: Xie Shaohui-B21989
>> Sent: Wednesday, May 09, 2012 8:50 AM
>> To: Bhushan Bharat-R65777; linux-watchdog@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org
>> Subject: RE: [PATCH 1/2] powerpc/watchdog: move booke watchdog param
>> related code to prom.c
>>
>> >> -----Original Message-----
>> >> From:
>> >> linuxppc-dev-bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org
>> >> [mailto:linuxppc-dev-bounces+bharat.bhushan=3Dfreescale.com@lists.ozl
>> >> ab
>> >> s
>> >> .org] On Behalf Of Shaohui Xie
>> >> Sent: Tuesday, May 08, 2012 11:37 AM
>> >> To: linux-watchdog@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
>> >> Cc: Xie Shaohui-B21989
>> >> Subject: [PATCH 1/2] powerpc/watchdog: move booke watchdog param
>> >> related code to prom.c
>> >>
>> >> Currently, BOOKE watchdog code for checking "wdt" and "wdt_period"
>> >> is in setup_32.c, it cannot be used in 64-bit, so move it to a
>> >> common place prom.c, which will be shared by 32-bit and 64-bit.
>> >>
>> >> Also, replace the simple_strtoul with kstrtol.
>> >>
>> >> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>> >> ---
>> >> arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++
>> >> arch/powerpc/kernel/setup_32.c | 24 ------------------------
>> >> 2 files changed, 27 insertions(+), 24 deletions(-)
>> >
>> >Is not setup-common.c is better place to move this?
>>
>> Move out from setup_32.c does not mean it have to go into
>> setup-common.c, I need better reason to do this.
>>
>
>What I think that setup_32.c is for 32 bit, setup_64.c is for 64 bit and
>setup-common.c is for both.
>
>I am not saying that you move this to setup-common.c. I am asking why you
>have not used setup-common.c ? I am ok even with prom.c.
>
[Xie Shaohui] I'm not a fan of prom.c, I did this because I see same kind o=
f early parameters checking is did in this file only, so I thought maybe I =
should put them together. And seems setup-common.c is not the place to do c=
ommand line checking (I'm not sure about this).
Best Regards,=20
Shaohui Xie
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/watchdog: move booke watchdog param related code to prom.c
From: Bhushan Bharat-R65777 @ 2012-05-09 3:46 UTC (permalink / raw)
To: Xie Shaohui-B21989, linux-watchdog@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <ED492CCEAF882048BC2237DE806547C90B2EF0@039-SN2MPN1-013.039d.mgd.msft.net>
> >> >> .org] On Behalf Of Shaohui Xie
> >> >> Sent: Tuesday, May 08, 2012 11:37 AM
> >> >> To: linux-watchdog@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> >> >> Cc: Xie Shaohui-B21989
> >> >> Subject: [PATCH 1/2] powerpc/watchdog: move booke watchdog param
> >> >> related code to prom.c
> >> >>
> >> >> Currently, BOOKE watchdog code for checking "wdt" and "wdt_period"
> >> >> is in setup_32.c, it cannot be used in 64-bit, so move it to a
> >> >> common place prom.c, which will be shared by 32-bit and 64-bit.
> >> >>
> >> >> Also, replace the simple_strtoul with kstrtol.
> >> >>
> >> >> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> >> >> ---
> >> >> arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++
> >> >> arch/powerpc/kernel/setup_32.c | 24 ------------------------
> >> >> 2 files changed, 27 insertions(+), 24 deletions(-)
> >> >
> >> >Is not setup-common.c is better place to move this?
> >>
> >> Move out from setup_32.c does not mean it have to go into
> >> setup-common.c, I need better reason to do this.
> >>
> >
> >What I think that setup_32.c is for 32 bit, setup_64.c is for 64 bit
> >and setup-common.c is for both.
> >
> >I am not saying that you move this to setup-common.c. I am asking why
> >you have not used setup-common.c ? I am ok even with prom.c.
> >
> [Xie Shaohui] I'm not a fan of prom.c, I did this because I see same kind=
of
> early parameters checking is did in this file only, so I thought maybe I =
should
> put them together. And seems setup-common.c is not the place to do comman=
d line
> checking (I'm not sure about this).
>=20
Ok, so you are also not sure.
Let us see what other guys things of this.
Thanks
-Bharat
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile fail in hugetlb cmdline parsing
From: Stephen Rothwell @ 2012-05-09 4:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jim Cromie, Greg Kroah-Hartman, Jason Baron, Rusty Russell,
Paul Gortmaker, linux-next, linuxppc-dev
In-Reply-To: <1336532658.1714.15.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]
Hi Ben,
On Wed, 09 May 2012 13:04:18 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Tue, 2012-05-08 at 13:53 +0930, Rusty Russell wrote:
> > On Mon, 7 May 2012 10:32:22 -0400, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> > > Commit 9fb48c744ba6a4bf58b666f4e6fdac3008ea1bd4
> > >
> > > "params: add 3rd arg to option handler callback signature"
> > >
> > > added an extra arg to the function, but didn't catch all the use
> > > cases needing it, causing this compile fail in mpc85xx_defconfig:
> > >
> > > arch/powerpc/mm/hugetlbpage.c:316:4: error: passing argument 7 of
> > > 'parse_args' from incompatible pointer type [-Werror]
> > >
> > > include/linux/moduleparam.h:317:12: note: expected
> > > 'int (*)(char *, char *, const char *)' but argument is of type
> > > 'int (*)(char *, char *)'
> > >
> > > This function has no need to printk out the "doing" value, so
> > > just add the arg as an "unused".
> > >
> > > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > > Cc: Jim Cromie <jim.cromie@gmail.com>
> > > Cc: Jason Baron <jbaron@redhat.com>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Becky Bruce <beckyb@kernel.crashing.org>
> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> >
> > Acked-by: Rusty Russell <rusty@rustcorp.com.au>
>
> This is for -next right ? IE. I don't seem to have the faulty commit
> in my tree so I can't carry the fix for now.... or am I missing
> something ?
This patch has been added to the driver-core tree which contains the
faulty commit ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* 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
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