* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-12-14 8:41 UTC (permalink / raw)
To: Scott Wood, dedekind1
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, shuo.liu, linux-mtd,
akpm, dwmw2
In-Reply-To: <4EE6BC9B.4000602@freescale.com>
=E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 10:46, LiuShuo =E5=86=99=E9=
=81=93:
> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:30, Scott Wood =E5=86=99=
=E9=81=93:
>> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
>>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
>>>> NAND chips come from the factory with bad blocks marked at a certain
>>>> offset into each page. This offset is normally in the OOB area, but
>>>> since we change the layout from "4k data, 128 byte oob" to "2k=20
>>>> data, 64
>>>> byte oob, 2k data, 64 byte oob" the marker is no longer in the=20
>>>> oob. On
>>>> first use we need to migrate the markers so that they are still in=20
>>>> the oob.
>>> Ah, I see, thanks. Are you planning to implement in-kernel migration =
or
>>> use a user-space tool?
>> That's the kind of answer I was hoping to get from Shuo. :-)
> OK, I try to do this. Wait for a couple of days.
>
> -LiuShuo
I found it's too complex to do the migration in Linux driver.
Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is=20
enough.
And let user ensure it been completed before linux use the Nand flash chi=
p.
Even if we don't do the migration, the bad block also can be marked as ba=
d
by wearing. So, do we really need to take much time to implement it ?
(code looks too complex.)
-LiuShuo
>> Most likely is a firmware-based tool, but I'd like there to be some wa=
y
>> for the tool to mark that this has happened, so that the Linux driver
>> can refuse to do non-raw accesses to a chip that isn't marked as havin=
g
>> been migrated (or at least yell loudly in the log).
>>
>> Speaking of raw accesses, these are currently broken in the eLBC
>> driver... we need some way for the generic layer to tell us what kind =
of
>> access it is before the transaction starts, not once it wants to read
>> out the buffer (unless we add more hacks to delay the start of a read
>> transaction until first buffer access...). We'd be better off with a
>> high-level "read page/write page" function that does the whole thing
>> (not just buffer access, but command issuance as well).
>>
>> -Scott
>
^ permalink raw reply
* linux-next: build warnings after merge of the final tree
From: Stephen Rothwell @ 2011-12-14 7:15 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, Paul Mackerras, linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc allyesconfig)
produced these warnings:
In file included from arch/powerpc/include/asm/asm-offsets.h:1:0,
from kernel/trace/trace_syscalls.c:9:
include/generated/asm-offsets.h:15:0: warning: "NMI_MASK" redefined [enabled by default]
include/linux/hardirq.h:56:0: note: this is the location of the previous definition
include/generated/asm-offsets.h:128:0: warning: "CLONE_VM" redefined [enabled by default]
include/linux/sched.h:8:0: note: this is the location of the previous definition
include/generated/asm-offsets.h:129:0: warning: "CLONE_UNTRACED" redefined [enabled by default]
include/linux/sched.h:22:0: note: this is the location of the previous definition
include/generated/asm-offsets.h:165:0: warning: "NSEC_PER_SEC" redefined [enabled by default]
include/linux/time.h:40:0: note: this is the location of the previous definition
include/generated/asm-offsets.h:173:0: warning: "PGD_TABLE_SIZE" redefined [enabled by default]
arch/powerpc/include/asm/pgtable-ppc64-4k.h:17:0: note: this is the location of the previous definition
Maybe caused by commit d5e553d6e0a4 ("trace: Include <asm/asm-offsets.h>
in trace_syscalls.c") from the tip tree. These warnings may have been
here for a while as it is hard to catch the new ones among the flood.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] Only use initrd_end as the limit for alloc_bottom if it's inside the RMO.
From: Tony Breeds @ 2011-12-14 3:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt, LinuxPPC-dev; +Cc: Paul Mackerras, Anton Blanchard
From: Paul Mackerras <paulus@samba.org>
As the kernels and initrd's get bigger boot-loaders and possibly
kexec-tools will need to place the initrd outside the RMO. When this
happens we end up with no lowmem and the boot doesn't get very far.
Only use initrd_end as the limit for alloc_bottom if it's inside the
RMO.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/prom_init.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index cc58486..940dc0c 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1224,14 +1224,6 @@ static void __init prom_init_mem(void)
RELOC(alloc_bottom) = PAGE_ALIGN((unsigned long)&RELOC(_end) + 0x4000);
- /* Check if we have an initrd after the kernel, if we do move our bottom
- * point to after it
- */
- if (RELOC(prom_initrd_start)) {
- if (RELOC(prom_initrd_end) > RELOC(alloc_bottom))
- RELOC(alloc_bottom) = PAGE_ALIGN(RELOC(prom_initrd_end));
- }
-
/*
* If prom_memory_limit is set we reduce the upper limits *except* for
* alloc_top_high. This must be the real top of RAM so we can put
@@ -1269,6 +1261,15 @@ static void __init prom_init_mem(void)
RELOC(alloc_top) = RELOC(rmo_top);
RELOC(alloc_top_high) = RELOC(ram_top);
+ /*
+ * Check if we have an initrd after the kernel but still inside
+ * the RMO. If we do move our bottom point to after it.
+ */
+ if (RELOC(prom_initrd_start) &&
+ RELOC(prom_initrd_start) < RELOC(rmo_top) &&
+ RELOC(prom_initrd_end) > RELOC(alloc_bottom))
+ RELOC(alloc_bottom) = PAGE_ALIGN(RELOC(prom_initrd_end));
+
prom_printf("memory layout at init:\n");
prom_printf(" memory_limit : %x (16 MB aligned)\n", RELOC(prom_memory_limit));
prom_printf(" alloc_bottom : %x\n", RELOC(alloc_bottom));
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-12-14 3:41 UTC (permalink / raw)
To: dedekind1, Scott Wood
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, shuo.liu, linux-mtd,
akpm, dwmw2
In-Reply-To: <1323724195.2297.11.camel@koala>
=E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:09, Artem Bityutskiy =E5=
=86=99=E9=81=93:
> On Tue, 2011-12-06 at 18:09 -0600, Scott Wood wrote:
>> On 12/03/2011 10:31 PM, shuo.liu@freescale.com wrote:
>>> From: Liu Shuo<shuo.liu@freescale.com>
>>>
>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In o=
rder
>>> to support the Nand flash chip whose page size is larger than 2K byte=
s,
>>> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and s=
ave
>>> them to a large buffer.
>>>
>>> Signed-off-by: Liu Shuo<shuo.liu@freescale.com>
>>> ---
>>> v3:
>>> -remove page_size of struct fsl_elbc_mtd.
>>> -do a oob write by NAND_CMD_RNDIN.
>>>
>>> drivers/mtd/nand/fsl_elbc_nand.c | 243 +++++++++++++++++++++++++++=
+++++++----
>>> 1 files changed, 218 insertions(+), 25 deletions(-)
>> What is the plan for bad block marker migration.
I think we can use a special bbt pattern to indicate whether migration=20
has been done.
(we needn't to define another marker)
Do the migration our chip->scan_bbt as follow :
/*
* this pattern indicate that the bad block information has been migrate=
d,
* if this isn't found, we do the migration.
*/
static u8 migrated_bbt_pattern[] =3D {'M', 'b', 'b', 't', '0' };
static int fsl_elbc_bbt(struct mtd_info *mtd)
{
if (!check_migrated_bbt_pattern())
bad_block_info_migtrate();
nand_default_bbt(mtd); /* default function in nand_bbt.c */
}
- LiuShuo
^ permalink raw reply
* RE: [PATCH] mmc: sdhci-pltfm: Added sdhci-adjust-timeout quirk
From: Xie Xiaobo-R63061 @ 2011-12-14 3:27 UTC (permalink / raw)
To: Huang Changming-R66093, linuxppc-dev@lists.ozlabs.org
Cc: avorontsov@ru.mvista.com, linux-mmc@vger.kernel.org
In-Reply-To: <8A2FC72B45BB5A4C9F801431E06AE48F11644C44@039-SN1MPN1-006.039d.mgd.msft.net>
SGkgQ2hhbmdtaW5nLA0KDQpPSywgeW91IGNhbiBtZXJnZSBteSBwYXRjaCBpbnRvIHlvdXIgcGF0
Y2hlcy4NCg0KSGkgYWxsLA0KUGxlYXNlIGlnbm9yZSB0aGlzIHBhdGNoLiBDaGFuZ21pbmcgd2ls
bCBzZW5kIHRoZSBzaW1pbGFyIHBhdGNoLg0KDQpCUnMNClhpZSBYaWFvYm8NCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEh1YW5nIENoYW5nbWluZy1SNjYwOTMgDQpTZW50OiAy
MDExxOoxMtTCMTPI1SAxNjowMA0KVG86IFhpZSBYaWFvYm8tUjYzMDYxOyBsaW51eHBwYy1kZXZA
bGlzdHMub3psYWJzLm9yZw0KQ2M6IGF2b3JvbnRzb3ZAcnUubXZpc3RhLmNvbTsgbGludXgtbW1j
QHZnZXIua2VybmVsLm9yZzsgWGllIFhpYW9iby1SNjMwNjENClN1YmplY3Q6IFJFOiBbUEFUQ0hd
IG1tYzogc2RoY2ktcGx0Zm06IEFkZGVkIHNkaGNpLWFkanVzdC10aW1lb3V0IHF1aXJrDQoNClhp
YW9ibywgSSBoYXZlIG9uZSBvdGhlciBzaW1pbGFyIHBhdGNoLCBidXQgdGhlIHByb3BlcnR5IGlz
ICdzZGhjaSxhZGp1c3QtdGltZW91dCcuDQpNYXliZSBJIGNhbiByZXBvc3QgaXQgd2l0aCBhZGQg
eW91ciBzaWduZWQtb2ZmLWJ5Pw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IGxpbnV4cHBjLWRldi1ib3VuY2VzK3I2NjA5Mz1mcmVlc2NhbGUuY29tQGxpc3RzLm96bGFi
cy5vcmcNCj4gW21haWx0bzpsaW51eHBwYy1kZXYtYm91bmNlcytyNjYwOTM9ZnJlZXNjYWxlLmNv
bUBsaXN0cy5vemxhYnMub3JnXSBPbiANCj4gQmVoYWxmIE9mIFhpZSBYaWFvYm8NCj4gU2VudDog
TW9uZGF5LCBEZWNlbWJlciAwNSwgMjAxMSA0OjU1IFBNDQo+IFRvOiBsaW51eHBwYy1kZXZAbGlz
dHMub3psYWJzLm9yZw0KPiBDYzogYXZvcm9udHNvdkBydS5tdmlzdGEuY29tOyBsaW51eC1tbWNA
dmdlci5rZXJuZWwub3JnOyBYaWUgWGlhb2JvLQ0KPiBSNjMwNjENCj4gU3ViamVjdDogW1BBVENI
XSBtbWM6IHNkaGNpLXBsdGZtOiBBZGRlZCBzZGhjaS1hZGp1c3QtdGltZW91dCBxdWlyaw0KPiAN
Cj4gU29tZSBjb250cm9sbGVyIHByb3ZpZGVzIGFuIGluY29ycmVjdCB0aW1lb3V0IHZhbHVlIGZv
ciB0cmFuc2ZlcnMsIFNvIA0KPiBpdCBuZWVkIHRoZSBxdWlyayB0byBhZGp1c3QgdGltZW91dCB2
YWx1ZSB0byAweEUuDQo+IEUuZy4gZVNESEMgb2YgTVBDODUzNiwgUDEwMTAsIGFuZCBQMjAyMC4N
Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IFhpZSBYaWFvYm8gPFguWGllQGZyZWVzY2FsZS5jb20+DQo+
IC0tLQ0KPiAgZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1wbHRmbS5jIHwgICAgNSArKysrLQ0KPiAg
MSBmaWxlcyBjaGFuZ2VkLCA0IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pDQo+IA0KPiBk
aWZmIC0tZ2l0IGEvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1wbHRmbS5jIGIvZHJpdmVycy9tbWMv
aG9zdC9zZGhjaS0gDQo+IHBsdGZtLmMgaW5kZXggYTllMTJlYS4uYjVkNmIzZiAxMDA2NDQNCj4g
LS0tIGEvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1wbHRmbS5jDQo+ICsrKyBiL2RyaXZlcnMvbW1j
L2hvc3Qvc2RoY2ktcGx0Zm0uYw0KPiBAQCAtMiw3ICsyLDcgQEANCj4gICAqIHNkaGNpLXBsdGZt
LmMgU3VwcG9ydCBmb3IgU0RIQ0kgcGxhdGZvcm0gZGV2aWNlcw0KPiAgICogQ29weXJpZ2h0IChj
KSAyMDA5IEludGVsIENvcnBvcmF0aW9uDQo+ICAgKg0KPiAtICogQ29weXJpZ2h0IChjKSAyMDA3
IEZyZWVzY2FsZSBTZW1pY29uZHVjdG9yLCBJbmMuDQo+ICsgKiBDb3B5cmlnaHQgKGMpIDIwMDcs
IDIwMTEgRnJlZXNjYWxlIFNlbWljb25kdWN0b3IsIEluYy4NCj4gICAqIENvcHlyaWdodCAoYykg
MjAwOSBNb250YVZpc3RhIFNvZnR3YXJlLCBJbmMuDQo+ICAgKg0KPiAgICogQXV0aG9yczogWGlh
b2JvIFhpZSA8WC5YaWVAZnJlZXNjYWxlLmNvbT4gQEAgLTY4LDYgKzY4LDkgQEAgdm9pZCANCj4g
c2RoY2lfZ2V0X29mX3Byb3BlcnR5KHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpDQo+ICAJ
CWlmIChvZl9nZXRfcHJvcGVydHkobnAsICJzZGhjaSwxLWJpdC1vbmx5IiwgTlVMTCkpDQo+ICAJ
CQlob3N0LT5xdWlya3MgfD0gU0RIQ0lfUVVJUktfRk9SQ0VfMV9CSVRfREFUQTsNCj4gDQo+ICsJ
CWlmIChvZl9nZXRfcHJvcGVydHkobnAsICJzZGhjaSxzZGhjaS1hZGp1c3QtdGltZW91dCIsIE5V
TEwpKQ0KPiArCQkJaG9zdC0+cXVpcmtzIHw9IFNESENJX1FVSVJLX0JST0tFTl9USU1FT1VUX1ZB
TDsNCj4gKw0KPiAgCQlpZiAoc2RoY2lfb2Zfd3BfaW52ZXJ0ZWQobnApKQ0KPiAgCQkJaG9zdC0+
cXVpcmtzIHw9IFNESENJX1FVSVJLX0lOVkVSVEVEX1dSSVRFX1BST1RFQ1Q7DQo+IA0KPiAtLQ0K
PiAxLjYuNA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+IExpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QNCj4gTGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmcNCj4gaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xpc3RpbmZvL2xpbnV4
cHBjLWRldg0KDQo=
^ permalink raw reply
* Re: CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Anton Blanchard @ 2011-12-14 3:17 UTC (permalink / raw)
To: Fushen Chen; +Cc: Peter Zijlstra, Thomas Gleixner, Linuxppc-dev Development
In-Reply-To: <CAEu=RPgnh-i-SFt4kiiAtDjLZ3A0cAHhk7ch56Uvv0uG_+HfCg@mail.gmail.com>
Hi,
> This is 2.6.32, but I think 2.6.36 is the same.
Sounds a bit like this, merged in 2.6.39.
Anton
--
commit ad5d1c888e556bc00c4e86f452cad4a3a87d22c1
Author: Anton Blanchard <anton@samba.org>
Date: Sun Mar 20 15:28:03 2011 +0000
powerpc: Fix accounting of softirq time when idle
commit cf9efce0ce31 (powerpc: Account time using timebase rather
than PURR) used in_irq() to detect if the time was spent in
interrupt processing. This only catches hardirq context so if we
are in softirq context and in the idle loop we end up accounting it
as idle time. If we instead use in_interrupt() we catch both softirq
and hardirq time.
The issue was found when running a network intensive workload. top
showed the following:
0.0%us, 1.1%sy, 0.0%ni, 85.7%id, 0.0%wa, 9.9%hi, 3.3%si, 0.0%st
85.7% idle. But this was wildly different to the perf events data.
To confirm the suspicion I ran something to keep the core busy:
# yes > /dev/null &
8.2%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 10.3%hi, 81.4%si, 0.0%st
We only got 8.2% of the CPU for the userspace task and softirq has
shot up to 81.4%.
With the patch below top shows the correct stats:
0.0%us, 0.0%sy, 0.0%ni, 5.3%id, 0.0%wa, 13.3%hi, 81.3%si, 0.0%st
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix swiotlb ops for ppc64
From: Benjamin Herrenschmidt @ 2011-12-14 3:00 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list
In-Reply-To: <C9D58E47-96F4-45ED-BE54-758D71B361FD@kernel.crashing.org>
On Tue, 2011-12-13 at 20:53 -0600, Becky Bruce wrote:
> The non-coherent "specialness" is in the dma sync stuff and no, I
> don't think the iotlb stuff deals with that properly.
>
> Do you not have a problem with 1)? If not then I think we can look at
> switching over; 2) was more of a secondary thing.
So let's switch over, avoid an #ifdef which is always a good thing...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix swiotlb ops for ppc64
From: Becky Bruce @ 2011-12-14 2:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1323750427.19891.59.camel@pasglop>
On Dec 12, 2011, at 10:27 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2011-12-12 at 21:55 -0600, Becky Bruce wrote:
>> 1) dma_direct_alloc_coherent strips GFP_HIGHMEM out of the flags =
field
>> when calling the actual allocator and the iotlb version does not. I
>> don't know how much this matters - I did a quick grep and I don't see
>> any users that specify that, but somebody went through the trouble of
>> putting it in there in the first place and without knowing why I
>> wasn't willing to get rid of it. Now, since my patch it looks like
>> someone added a VM_BUG_ON into __get_free_pages() if GFP_HIGHMEM so
>> this would get caught. However, I don't know if we really want to
>> throw a bug there.
>>=20
>> 2) The iotlb code doesn't deal with the !coherent parts like 8xx. =
We
>> can work around that by setting up the dma_ops differently for that
>> case instead.
>=20
> Does the rest of it handle them ? I mean swiotlb_map_sg_attrs etc...
The non-coherent "specialness" is in the dma sync stuff and no, I don't =
think the iotlb stuff deals with that properly.
Do you not have a problem with 1)? If not then I think we can look at =
switching over; 2) was more of a secondary thing.
-B
^ permalink raw reply
* Re: CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Fushen Chen @ 2011-12-14 1:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, Linuxppc-dev Development, Thomas Gleixner
In-Reply-To: <1323819246.7671.4.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]
This is 2.6.32, but I think 2.6.36 is the same.
Thanks,
Fushen
On Tue, Dec 13, 2011 at 3:34 PM, Benjamin Herrenschmidt <
benh@kernel.crashing.org> wrote:
> On Wed, 2011-12-14 at 00:28 +0100, Thomas Gleixner wrote:
> > On Wed, 14 Dec 2011, Benjamin Herrenschmidt wrote:
> >
> > > On Tue, 2011-12-13 at 12:42 -0800, Fushen Chen wrote:
> > > > On APM82181, "vmstat" (/proc/stat) doesn't show correct idle
> > > > percent, if kernel enables "CONFIG_NO_HZ" (Tickless System / Dynamic
> > > > Tick).
> > > >
> > > > When I run wireless throughput test with heavy traffic, "vmstat"
> shows
> > > > very high idle percent while "oprofile" shows very low idle percent.
> > > > During the test, the system is idle, but network traffic uses a lot
> of
> > > > hard IRQ and soft-irq time. "vmstat" would have the correct stats if
> > > > account_idle_ticks(ticks) in kernel/time/tick-sched.c doesn't add
> more
> > > > idle time in "vmstat". In the same test, if I disable "CONFIG_NO_HZ"
> > > > in kernel, idle percent in "vmstat" and "oprofile" would match.
> > > >
> > > > My APM82181 kernel configuration is "CONFIG_NO_HZ",
> "CONFIG_HZ_250=y",
> > > > "CONFIG_HZ=250", and "CONFIG_HIGH_RES_TIMERS".
> > > >
> > > > My question is that if kernel enables "CONFIG_NO_HZ", how would
> kernel
> > > > report correct stats.
> > >
> > > Hi Thomas ! Any idea what we're doing wrong ? :-)
> >
> > Not really, that had been an issue before and had been fixed. Peter ????
>
> Fusen, what kernel version is this ?
>
> Cheers,
> Ben.
>
>
>
[-- Attachment #2: Type: text/html, Size: 2237 bytes --]
^ permalink raw reply
* Re: CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Andreas Schwab @ 2011-12-13 23:57 UTC (permalink / raw)
To: Fushen Chen; +Cc: Linuxppc-dev Development
In-Reply-To: <CAEu=RPirE=H1N=KjHNjNRBM6H1fRvrugCw6ojqWaTNm2=WTfng__4707.66240400753$1323813396$gmane$org@mail.gmail.com>
Does this help?
<http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/47530>
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Thomas Gleixner @ 2011-12-13 23:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, Linuxppc-dev Development, Fushen Chen
In-Reply-To: <1323818650.7671.3.camel@pasglop>
On Wed, 14 Dec 2011, Benjamin Herrenschmidt wrote:
> On Tue, 2011-12-13 at 12:42 -0800, Fushen Chen wrote:
> > On APM82181, "vmstat" (/proc/stat) doesn't show correct idle
> > percent, if kernel enables "CONFIG_NO_HZ" (Tickless System / Dynamic
> > Tick).
> >
> > When I run wireless throughput test with heavy traffic, "vmstat" shows
> > very high idle percent while "oprofile" shows very low idle percent.
> > During the test, the system is idle, but network traffic uses a lot of
> > hard IRQ and soft-irq time. "vmstat" would have the correct stats if
> > account_idle_ticks(ticks) in kernel/time/tick-sched.c doesn't add more
> > idle time in "vmstat". In the same test, if I disable "CONFIG_NO_HZ"
> > in kernel, idle percent in "vmstat" and "oprofile" would match.
> >
> > My APM82181 kernel configuration is "CONFIG_NO_HZ", "CONFIG_HZ_250=y",
> > "CONFIG_HZ=250", and "CONFIG_HIGH_RES_TIMERS".
> >
> > My question is that if kernel enables "CONFIG_NO_HZ", how would kernel
> > report correct stats.
>
> Hi Thomas ! Any idea what we're doing wrong ? :-)
Not really, that had been an issue before and had been fixed. Peter ????
Thanks,
tglx
^ permalink raw reply
* Re: CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Benjamin Herrenschmidt @ 2011-12-13 23:34 UTC (permalink / raw)
To: Fushen Chen; +Cc: Peter Zijlstra, Linuxppc-dev Development, Thomas Gleixner
In-Reply-To: <alpine.LFD.2.02.1112140027230.3020@ionos>
On Wed, 2011-12-14 at 00:28 +0100, Thomas Gleixner wrote:
> On Wed, 14 Dec 2011, Benjamin Herrenschmidt wrote:
>
> > On Tue, 2011-12-13 at 12:42 -0800, Fushen Chen wrote:
> > > On APM82181, "vmstat" (/proc/stat) doesn't show correct idle
> > > percent, if kernel enables "CONFIG_NO_HZ" (Tickless System / Dynamic
> > > Tick).
> > >
> > > When I run wireless throughput test with heavy traffic, "vmstat" shows
> > > very high idle percent while "oprofile" shows very low idle percent.
> > > During the test, the system is idle, but network traffic uses a lot of
> > > hard IRQ and soft-irq time. "vmstat" would have the correct stats if
> > > account_idle_ticks(ticks) in kernel/time/tick-sched.c doesn't add more
> > > idle time in "vmstat". In the same test, if I disable "CONFIG_NO_HZ"
> > > in kernel, idle percent in "vmstat" and "oprofile" would match.
> > >
> > > My APM82181 kernel configuration is "CONFIG_NO_HZ", "CONFIG_HZ_250=y",
> > > "CONFIG_HZ=250", and "CONFIG_HIGH_RES_TIMERS".
> > >
> > > My question is that if kernel enables "CONFIG_NO_HZ", how would kernel
> > > report correct stats.
> >
> > Hi Thomas ! Any idea what we're doing wrong ? :-)
>
> Not really, that had been an issue before and had been fixed. Peter ????
Fusen, what kernel version is this ?
Cheers,
Ben.
^ permalink raw reply
* Re: CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Benjamin Herrenschmidt @ 2011-12-13 23:24 UTC (permalink / raw)
To: Fushen Chen; +Cc: Linuxppc-dev Development, Thomas Gleixner
In-Reply-To: <CAEu=RPirE=H1N=KjHNjNRBM6H1fRvrugCw6ojqWaTNm2=WTfng@mail.gmail.com>
On Tue, 2011-12-13 at 12:42 -0800, Fushen Chen wrote:
> On APM82181, "vmstat" (/proc/stat) doesn't show correct idle
> percent, if kernel enables "CONFIG_NO_HZ" (Tickless System / Dynamic
> Tick).
>
> When I run wireless throughput test with heavy traffic, "vmstat" shows
> very high idle percent while "oprofile" shows very low idle percent.
> During the test, the system is idle, but network traffic uses a lot of
> hard IRQ and soft-irq time. "vmstat" would have the correct stats if
> account_idle_ticks(ticks) in kernel/time/tick-sched.c doesn't add more
> idle time in "vmstat". In the same test, if I disable "CONFIG_NO_HZ"
> in kernel, idle percent in "vmstat" and "oprofile" would match.
>
> My APM82181 kernel configuration is "CONFIG_NO_HZ", "CONFIG_HZ_250=y",
> "CONFIG_HZ=250", and "CONFIG_HIGH_RES_TIMERS".
>
> My question is that if kernel enables "CONFIG_NO_HZ", how would kernel
> report correct stats.
Hi Thomas ! Any idea what we're doing wrong ? :-)
Cheers,
Ben.
> Thanks,
> Fushen
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile error with 85xx/p1022_ds.c
From: Tabi Timur-B04825 @ 2011-12-13 20:56 UTC (permalink / raw)
To: Michael Neuling, Gala Kumar-B11780
Cc: linux-next@vger.kernel.org, linuxppc-dev, Kyle Moffett,
sfr@canb.auug.org.au
In-Reply-To: <22284.1323643754@neuling.org>
On Sun, Dec 11, 2011 at 4:49 PM, Michael Neuling <mikey@neuling.org> wrote:
> Current linux-next compiled with mpc85xx_defconfig causes this:
> =A0arch/powerpc/platforms/85xx/p1022_ds.c:341:14: error: 'udbg_progress' =
undeclared here (not in a function)
>
> Add include to fix this.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH] [v4] powerpc/fsl: add MSI support for the Freescale hypervisor
From: Timur Tabi @ 2011-12-13 20:51 UTC (permalink / raw)
To: kumar.gala, scottwood, linuxppc-dev
Add support for vmpic-msi nodes to the fsl_msi driver. The MSI is
virtualized by the hypervisor, so the vmpic-msi does not contain a 'reg'
property. Instead, the driver uses hcalls.
Add support for the "msi-address-64" property to the fsl_pci driver.
The Freescale hypervisor typically puts the virtualized MSIIR register
in the page after the end of DDR, so we extend the DDR ATMU to cover it.
Any other location for MSIIR is not supported, for now.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
v4: fix checkpatch complaint. I know, I suck.
arch/powerpc/sysdev/fsl_msi.c | 68 +++++++++++++++++++++++++++++------------
arch/powerpc/sysdev/fsl_msi.h | 7 ++--
arch/powerpc/sysdev/fsl_pci.c | 29 +++++++++++++++++
3 files changed, 81 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 89548e0..ecb5c19 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -23,6 +23,8 @@
#include <asm/hw_irq.h>
#include <asm/ppc-pci.h>
#include <asm/mpic.h>
+#include <asm/fsl_hcalls.h>
+
#include "fsl_msi.h"
#include "fsl_pci.h"
@@ -163,11 +165,13 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
*/
np = of_parse_phandle(hose->dn, "fsl,msi", 0);
if (np) {
- if (of_device_is_compatible(np, "fsl,mpic-msi"))
+ if (of_device_is_compatible(np, "fsl,mpic-msi") ||
+ of_device_is_compatible(np, "fsl,vmpic-msi"))
phandle = np->phandle;
else {
- dev_err(&pdev->dev, "node %s has an invalid fsl,msi"
- " phandle\n", hose->dn->full_name);
+ dev_err(&pdev->dev,
+ "node %s has an invalid fsl,msi phandle %u\n",
+ hose->dn->full_name, np->phandle);
return -EINVAL;
}
}
@@ -196,16 +200,14 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
if (hwirq < 0) {
rc = hwirq;
- pr_debug("%s: fail allocating msi interrupt\n",
- __func__);
+ dev_err(&pdev->dev, "could not allocate MSI interrupt\n");
goto out_free;
}
virq = irq_create_mapping(msi_data->irqhost, hwirq);
if (virq == NO_IRQ) {
- pr_debug("%s: fail mapping hwirq 0x%x\n",
- __func__, hwirq);
+ dev_err(&pdev->dev, "fail mapping hwirq %i\n", hwirq);
msi_bitmap_free_hwirqs(&msi_data->bitmap, hwirq, 1);
rc = -ENOSPC;
goto out_free;
@@ -234,6 +236,7 @@ static void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
u32 intr_index;
u32 have_shift = 0;
struct fsl_msi_cascade_data *cascade_data;
+ unsigned int ret;
cascade_data = irq_get_handler_data(irq);
msi_data = cascade_data->msi_data;
@@ -265,6 +268,14 @@ static void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
case FSL_PIC_IP_IPIC:
msir_value = fsl_msi_read(msi_data->msi_regs, msir_index * 0x4);
break;
+ case FSL_PIC_IP_VMPIC:
+ ret = fh_vmpic_get_msir(virq_to_hw(irq), &msir_value);
+ if (ret) {
+ pr_err("fsl-msi: fh_vmpic_get_msir() failed for "
+ "irq %u (ret=%u)\n", irq, ret);
+ msir_value = 0;
+ }
+ break;
}
while (msir_value) {
@@ -282,6 +293,7 @@ static void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
switch (msi_data->feature & FSL_PIC_IP_MASK) {
case FSL_PIC_IP_MPIC:
+ case FSL_PIC_IP_VMPIC:
chip->irq_eoi(idata);
break;
case FSL_PIC_IP_IPIC:
@@ -311,7 +323,8 @@ static int fsl_of_msi_remove(struct platform_device *ofdev)
}
if (msi->bitmap.bitmap)
msi_bitmap_free(&msi->bitmap);
- iounmap(msi->msi_regs);
+ if ((msi->feature & FSL_PIC_IP_MASK) != FSL_PIC_IP_VMPIC)
+ iounmap(msi->msi_regs);
kfree(msi);
return 0;
@@ -383,26 +396,32 @@ static int __devinit fsl_of_msi_probe(struct platform_device *dev)
goto error_out;
}
- /* Get the MSI reg base */
- err = of_address_to_resource(dev->dev.of_node, 0, &res);
- if (err) {
- dev_err(&dev->dev, "%s resource error!\n",
+ /*
+ * Under the Freescale hypervisor, the msi nodes don't have a 'reg'
+ * property. Instead, we use hypercalls to access the MSI.
+ */
+ if ((features->fsl_pic_ip & FSL_PIC_IP_MASK) != FSL_PIC_IP_VMPIC) {
+ err = of_address_to_resource(dev->dev.of_node, 0, &res);
+ if (err) {
+ dev_err(&dev->dev, "invalid resource for node %s\n",
dev->dev.of_node->full_name);
- goto error_out;
- }
+ goto error_out;
+ }
- msi->msi_regs = ioremap(res.start, resource_size(&res));
- if (!msi->msi_regs) {
- dev_err(&dev->dev, "ioremap problem failed\n");
- goto error_out;
+ msi->msi_regs = ioremap(res.start, resource_size(&res));
+ if (!msi->msi_regs) {
+ dev_err(&dev->dev, "could not map node %s\n",
+ dev->dev.of_node->full_name);
+ goto error_out;
+ }
+ msi->msiir_offset =
+ features->msiir_offset + (res.start & 0xfffff);
}
msi->feature = features->fsl_pic_ip;
msi->irqhost->host_data = msi;
- msi->msiir_offset = features->msiir_offset + (res.start & 0xfffff);
-
/*
* Remember the phandle, so that we can match with any PCI nodes
* that have an "fsl,msi" property.
@@ -476,6 +495,11 @@ static const struct fsl_msi_feature ipic_msi_feature = {
.msiir_offset = 0x38,
};
+static const struct fsl_msi_feature vmpic_msi_feature = {
+ .fsl_pic_ip = FSL_PIC_IP_VMPIC,
+ .msiir_offset = 0,
+};
+
static const struct of_device_id fsl_of_msi_ids[] = {
{
.compatible = "fsl,mpic-msi",
@@ -485,6 +509,10 @@ static const struct of_device_id fsl_of_msi_ids[] = {
.compatible = "fsl,ipic-msi",
.data = (void *)&ipic_msi_feature,
},
+ {
+ .compatible = "fsl,vmpic-msi",
+ .data = (void *)&vmpic_msi_feature,
+ },
{}
};
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index b5d25ba..f6c646a 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -20,9 +20,10 @@
#define IRQS_PER_MSI_REG 32
#define NR_MSI_IRQS (NR_MSI_REG * IRQS_PER_MSI_REG)
-#define FSL_PIC_IP_MASK 0x0000000F
-#define FSL_PIC_IP_MPIC 0x00000001
-#define FSL_PIC_IP_IPIC 0x00000002
+#define FSL_PIC_IP_MASK 0x0000000F
+#define FSL_PIC_IP_MPIC 0x00000001
+#define FSL_PIC_IP_IPIC 0x00000002
+#define FSL_PIC_IP_VMPIC 0x00000003
struct fsl_msi {
struct irq_host *irqhost;
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4ce547e..5204a10 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -113,6 +113,8 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
u32 piwar = PIWAR_EN | PIWAR_PF | PIWAR_TGI_LOCAL |
PIWAR_READ_SNOOP | PIWAR_WRITE_SNOOP;
char *name = hose->dn->full_name;
+ const u64 *reg;
+ int len;
pr_debug("PCI memory map start 0x%016llx, size 0x%016llx\n",
(u64)rsrc->start, (u64)resource_size(rsrc));
@@ -205,6 +207,33 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
/* Setup inbound mem window */
mem = memblock_end_of_DRAM();
+
+ /*
+ * The msi-address-64 property, if it exists, indicates the physical
+ * address of the MSIIR register. Normally, this register is located
+ * inside CCSR, so the ATMU that covers all of CCSR is used. But if
+ * this property exists, then we normally need to create a new ATMU
+ * for it. For now, however, we cheat. The only entity that creates
+ * this property is the Freescale hypervisor, and the address is
+ * specified in the partition configuration. Typically, the address
+ * is located in the page immediately after the end of DDR. If so, we
+ * can avoid allocating a new ATMU by extending the DDR ATMU by one
+ * page.
+ */
+ reg = of_get_property(hose->dn, "msi-address-64", &len);
+ if (reg && (len == sizeof(u64))) {
+ u64 address = be64_to_cpup(reg);
+
+ if ((address >= mem) && (address < (mem + PAGE_SIZE))) {
+ pr_info("%s: extending DDR ATMU to cover MSIIR", name);
+ mem += PAGE_SIZE;
+ } else {
+ /* TODO: Create a new ATMU for MSIIR */
+ pr_warn("%s: msi-address-64 address of %llx is "
+ "unsupported\n", name, address);
+ }
+ }
+
sz = min(mem, paddr_lo);
mem_log = __ilog2_u64(sz);
--
1.7.3.4
^ permalink raw reply related
* CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Fushen Chen @ 2011-12-13 20:42 UTC (permalink / raw)
To: Linuxppc-dev Development
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On APM82181, "vmstat" (/proc/stat) doesn't show correct idle percent, if
kernel enables "CONFIG_NO_HZ" (Tickless System / Dynamic Tick).
When I run wireless throughput test with heavy traffic, "vmstat" shows very
high idle percent while "oprofile" shows very low idle percent. During the
test, the system is idle, but network traffic uses a lot of hard IRQ and
soft-irq time. "vmstat" would have the correct stats if
account_idle_ticks(ticks) in kernel/time/tick-sched.c doesn't add more idle
time in "vmstat". In the same test, if I disable "CONFIG_NO_HZ" in kernel,
idle percent in "vmstat" and "oprofile" would match.
My APM82181 kernel configuration is "CONFIG_NO_HZ", "CONFIG_HZ_250=y",
"CONFIG_HZ=250", and "CONFIG_HIGH_RES_TIMERS".
My question is that if kernel enables "CONFIG_NO_HZ", how would kernel
report correct stats.
Thanks,
Fushen
[-- Attachment #2: Type: text/html, Size: 1037 bytes --]
^ permalink raw reply
* [PATCH] [v3] powerpc/fsl: add MSI support for the Freescale hypervisor
From: Timur Tabi @ 2011-12-13 20:37 UTC (permalink / raw)
To: kumar.gala, scottwood, linuxppc-dev
Add support for vmpic-msi nodes to the fsl_msi driver. The MSI is
virtualized by the hypervisor, so the vmpic-msi does not contain a 'reg'
property. Instead, the driver uses hcalls.
Add support for the "msi-address-64" property to the fsl_pci driver.
The Freescale hypervisor typically puts the virtualized MSIIR register
in the page after the end of DDR, so we extend the DDR ATMU to cover it.
Any other location for MSIIR is not supported, for now.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
v3: fix a pr_warn message
v2: fix a comment and patch description
arch/powerpc/sysdev/fsl_msi.c | 68 +++++++++++++++++++++++++++++------------
arch/powerpc/sysdev/fsl_msi.h | 7 ++--
arch/powerpc/sysdev/fsl_pci.c | 29 +++++++++++++++++
3 files changed, 81 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 89548e0..7dc473f 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -23,6 +23,8 @@
#include <asm/hw_irq.h>
#include <asm/ppc-pci.h>
#include <asm/mpic.h>
+#include <asm/fsl_hcalls.h>
+
#include "fsl_msi.h"
#include "fsl_pci.h"
@@ -163,11 +165,13 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
*/
np = of_parse_phandle(hose->dn, "fsl,msi", 0);
if (np) {
- if (of_device_is_compatible(np, "fsl,mpic-msi"))
+ if (of_device_is_compatible(np, "fsl,mpic-msi") ||
+ of_device_is_compatible(np, "fsl,vmpic-msi"))
phandle = np->phandle;
else {
- dev_err(&pdev->dev, "node %s has an invalid fsl,msi"
- " phandle\n", hose->dn->full_name);
+ dev_err(&pdev->dev,
+ "node %s has an invalid fsl,msi phandle %u\n",
+ hose->dn->full_name, np->phandle);
return -EINVAL;
}
}
@@ -196,16 +200,14 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
if (hwirq < 0) {
rc = hwirq;
- pr_debug("%s: fail allocating msi interrupt\n",
- __func__);
+ dev_err(&pdev->dev, "could not allocate MSI interrupt\n");
goto out_free;
}
virq = irq_create_mapping(msi_data->irqhost, hwirq);
if (virq == NO_IRQ) {
- pr_debug("%s: fail mapping hwirq 0x%x\n",
- __func__, hwirq);
+ dev_err(&pdev->dev, "fail mapping hwirq %i\n", hwirq);
msi_bitmap_free_hwirqs(&msi_data->bitmap, hwirq, 1);
rc = -ENOSPC;
goto out_free;
@@ -234,6 +236,7 @@ static void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
u32 intr_index;
u32 have_shift = 0;
struct fsl_msi_cascade_data *cascade_data;
+ unsigned int ret;
cascade_data = irq_get_handler_data(irq);
msi_data = cascade_data->msi_data;
@@ -265,6 +268,14 @@ static void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
case FSL_PIC_IP_IPIC:
msir_value = fsl_msi_read(msi_data->msi_regs, msir_index * 0x4);
break;
+ case FSL_PIC_IP_VMPIC:
+ ret = fh_vmpic_get_msir(virq_to_hw(irq), &msir_value);
+ if (ret) {
+ pr_err("fsl-msi: fh_vmpic_get_msir() failed for "
+ "irq %u (ret=%u)\n", irq, ret);
+ msir_value = 0;
+ }
+ break;
}
while (msir_value) {
@@ -282,6 +293,7 @@ static void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
switch (msi_data->feature & FSL_PIC_IP_MASK) {
case FSL_PIC_IP_MPIC:
+ case FSL_PIC_IP_VMPIC:
chip->irq_eoi(idata);
break;
case FSL_PIC_IP_IPIC:
@@ -311,7 +323,8 @@ static int fsl_of_msi_remove(struct platform_device *ofdev)
}
if (msi->bitmap.bitmap)
msi_bitmap_free(&msi->bitmap);
- iounmap(msi->msi_regs);
+ if ((msi->feature & FSL_PIC_IP_MASK) != FSL_PIC_IP_VMPIC)
+ iounmap(msi->msi_regs);
kfree(msi);
return 0;
@@ -383,26 +396,32 @@ static int __devinit fsl_of_msi_probe(struct platform_device *dev)
goto error_out;
}
- /* Get the MSI reg base */
- err = of_address_to_resource(dev->dev.of_node, 0, &res);
- if (err) {
- dev_err(&dev->dev, "%s resource error!\n",
+ /*
+ * Under the Freescale hypervisor, the msi nodes don't have a 'reg'
+ * property. Instead, we use hypercalls to access the MSI.
+ */
+ if ((features->fsl_pic_ip & FSL_PIC_IP_MASK) != FSL_PIC_IP_VMPIC) {
+ err = of_address_to_resource(dev->dev.of_node, 0, &res);
+ if (err) {
+ dev_err(&dev->dev, "invalid resource for node %s\n",
dev->dev.of_node->full_name);
- goto error_out;
- }
+ goto error_out;
+ }
- msi->msi_regs = ioremap(res.start, resource_size(&res));
- if (!msi->msi_regs) {
- dev_err(&dev->dev, "ioremap problem failed\n");
- goto error_out;
+ msi->msi_regs = ioremap(res.start, resource_size(&res));
+ if (!msi->msi_regs) {
+ dev_err(&dev->dev, "could not map node %s\n",
+ dev->dev.of_node->full_name);
+ goto error_out;
+ }
+ msi->msiir_offset =
+ features->msiir_offset + (res.start & 0xfffff);
}
msi->feature = features->fsl_pic_ip;
msi->irqhost->host_data = msi;
- msi->msiir_offset = features->msiir_offset + (res.start & 0xfffff);
-
/*
* Remember the phandle, so that we can match with any PCI nodes
* that have an "fsl,msi" property.
@@ -476,6 +495,11 @@ static const struct fsl_msi_feature ipic_msi_feature = {
.msiir_offset = 0x38,
};
+static const struct fsl_msi_feature vmpic_msi_feature = {
+ .fsl_pic_ip = FSL_PIC_IP_VMPIC,
+ .msiir_offset = 0,
+};
+
static const struct of_device_id fsl_of_msi_ids[] = {
{
.compatible = "fsl,mpic-msi",
@@ -485,6 +509,10 @@ static const struct of_device_id fsl_of_msi_ids[] = {
.compatible = "fsl,ipic-msi",
.data = (void *)&ipic_msi_feature,
},
+ {
+ .compatible = "fsl,vmpic-msi",
+ .data = (void *)&vmpic_msi_feature,
+ },
{}
};
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index b5d25ba..f6c646a 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -20,9 +20,10 @@
#define IRQS_PER_MSI_REG 32
#define NR_MSI_IRQS (NR_MSI_REG * IRQS_PER_MSI_REG)
-#define FSL_PIC_IP_MASK 0x0000000F
-#define FSL_PIC_IP_MPIC 0x00000001
-#define FSL_PIC_IP_IPIC 0x00000002
+#define FSL_PIC_IP_MASK 0x0000000F
+#define FSL_PIC_IP_MPIC 0x00000001
+#define FSL_PIC_IP_IPIC 0x00000002
+#define FSL_PIC_IP_VMPIC 0x00000003
struct fsl_msi {
struct irq_host *irqhost;
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4ce547e..5204a10 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -113,6 +113,8 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
u32 piwar = PIWAR_EN | PIWAR_PF | PIWAR_TGI_LOCAL |
PIWAR_READ_SNOOP | PIWAR_WRITE_SNOOP;
char *name = hose->dn->full_name;
+ const u64 *reg;
+ int len;
pr_debug("PCI memory map start 0x%016llx, size 0x%016llx\n",
(u64)rsrc->start, (u64)resource_size(rsrc));
@@ -205,6 +207,33 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
/* Setup inbound mem window */
mem = memblock_end_of_DRAM();
+
+ /*
+ * The msi-address-64 property, if it exists, indicates the physical
+ * address of the MSIIR register. Normally, this register is located
+ * inside CCSR, so the ATMU that covers all of CCSR is used. But if
+ * this property exists, then we normally need to create a new ATMU
+ * for it. For now, however, we cheat. The only entity that creates
+ * this property is the Freescale hypervisor, and the address is
+ * specified in the partition configuration. Typically, the address
+ * is located in the page immediately after the end of DDR. If so, we
+ * can avoid allocating a new ATMU by extending the DDR ATMU by one
+ * page.
+ */
+ reg = of_get_property(hose->dn, "msi-address-64", &len);
+ if (reg && (len == sizeof(u64))) {
+ u64 address = be64_to_cpup(reg);
+
+ if ((address >= mem) && (address < (mem + PAGE_SIZE))) {
+ pr_info("%s: extending DDR ATMU to cover MSIIR", name);
+ mem += PAGE_SIZE;
+ } else {
+ /* TODO: Create a new ATMU for MSIIR */
+ pr_warn("%s: msi-address-64 address of %llx is "
+ "unsupported\n", name, address);
+ }
+ }
+
sz = min(mem, paddr_lo);
mem_log = __ilog2_u64(sz);
--
1.7.3.4
^ permalink raw reply related
* Re: sam460ex, rtc-m41t80 incorrect behaviour with kernel >=linux-2.6.38
From: acrux @ 2011-12-13 20:13 UTC (permalink / raw)
To: John Stultz; +Cc: linuxppc-dev, Alexander Bigga, rtc-linux
In-Reply-To: <1323730073.4078.97.camel@work-vm>
On Mon, 12 Dec 2011 14:47:53 -0800
John Stultz <john.stultz@linaro.org> wrote:
> On Sun, 2011-12-04 at 03:29 +0100, acrux_it@libero.it wrote:
> > Acube Sam460ex is a 460ex SoC (PowerPC) based board with m41t81
> > like RTC. The wrong beahviour it seems to be caused this commit:
> >
> > Thu, 3 Feb 2011 21:02:35 +0000 (13:02 -0800)
> > commit 16380c153a69c3784d2afaddfe0a22f353046cf6
> > RTC: Convert rtc drivers to use the alarm_irq_enable method
> > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;
> > h=16380c153a69c3784d2afaddfe0a22f353046cf6
>
> Yea. This was reported earlier, but it seems none of the proposed
> solutions have been implemented.
>
> The cause is that the m41t80 driver's alarm functionality is somehow
> broken. The alarm mode is actually now used for UIE, so where before
> 2.6.38, UIE mode returned -EINVAL, it will now succeed, setting the
> alarm to fire a second away.
>
> However, since the alarm code is broken, no alarm arrives and you get
> the timeout you see.
>
> Could you test the following patch to see if it resolves the issue for
> you? If it does, I'll queue it for inclusion.
>
> thanks
> -john
>
hallo John,
CC to linuxppc-dev@lists.ozlabs.org
thanks for your time, this escamotage works fine.
I tested your patch against linux-2.6.38.8 and linux-3.1.5.
Tested-by: Nico Macrionitis <acrux@cruxppc.org>
cheers,
Nico
>
> [PATCH] rtc: m41t80: Workaround broken alarm functionality
>
> The m41t80 driver doesn't seem to have a functional alarm.
>
> This causes failures when the generic core sees alarm functions,
> but then cannot use them properly for things like UIE mode.
>
> Disabling the alarm functions allows proper error reporting,
> and possible fallback to emulated modes. Once someone fixes
> the alarm functions, this can be restored.
>
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
> drivers/rtc/rtc-m41t80.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c
> index eda128f..64aedd8 100644
> --- a/drivers/rtc/rtc-m41t80.c
> +++ b/drivers/rtc/rtc-m41t80.c
> @@ -357,10 +357,19 @@ static int m41t80_rtc_read_alarm(struct device
> *dev, struct rtc_wkalrm *t) static struct rtc_class_ops
> m41t80_rtc_ops = { .read_time = m41t80_rtc_read_time,
> .set_time = m41t80_rtc_set_time,
> + /*
> + * XXX - m41t80 alarm functionality is reported broken.
> + * until it is fixed, don't register alarm functions.
> + *
> .read_alarm = m41t80_rtc_read_alarm,
> .set_alarm = m41t80_rtc_set_alarm,
> + */
> .proc = m41t80_rtc_proc,
> + /*
> + * See above comment on broken alarm
> + *
> .alarm_irq_enable = m41t80_rtc_alarm_irq_enable,
> + */
> };
>
> #if defined(CONFIG_RTC_INTF_SYSFS) || defined
> #(CONFIG_RTC_INTF_SYSFS_MODULE)
> --
> 1.7.3.2.146.gca209
>
>
>
--
GNU/Linux on Power Architecture
CRUX PPC - http://cruxppc.org/
^ permalink raw reply
* Re: Linux port availability for p5010 processor
From: Scott Wood @ 2011-12-13 19:28 UTC (permalink / raw)
To: Vineeth; +Cc: linuxppc-dev, Senthil CGC, rajarama.b
In-Reply-To: <CAFbQSaALfZ-6-_g5aC1GgbUaoHyuBwaT342OFMTSf0iqtakDGA@mail.gmail.com>
On 12/12/2011 11:33 PM, Vineeth wrote:
> Do we have a linux port available for freescale P5010 processor (with
> single E5500 core) ?
> /(found arch/powerpc/platforms/pseries ; and a some details on
> kernel/cputable.c /)
p5010 is basically a p5020 with one core and "memory complex" instead of
two. The same Linux code should work for both.
pseries is something completely different.
> Is there any reference board which uses this processor ?
p5020ds has a p5020.
Linux support is in arch/powerpc/platforms/85xx/p5020_ds.c (and
scattered in other places).
> any reference in DTS file also will be helpful.
arch/powerpc/boot/dts/p5020ds.dts
-Scott
^ permalink raw reply
* [PATCH] [v2] powerpc/fsl: add MSI support for the Freescale hypervisor
From: Timur Tabi @ 2011-12-13 18:52 UTC (permalink / raw)
To: kumar.gala, scottwood, linuxppc-dev
Add support for vmpic-msi nodes to the fsl_msi driver. The MSI is
virtualized by the hypervisor, so the vmpic-msi does not contain a 'reg'
property. Instead, the driver uses hcalls.
Add support for the "msi-address-64" property to the fsl_pci driver.
The Freescale hypervisor typically puts the virtualized MSIIR register
in the page after the end of DDR, so we extend the DDR ATMU to cover it.
Any other location for MSIIR is not supported, for now.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/sysdev/fsl_msi.c | 68 +++++++++++++++++++++++++++++------------
arch/powerpc/sysdev/fsl_msi.h | 7 ++--
arch/powerpc/sysdev/fsl_pci.c | 30 ++++++++++++++++++
3 files changed, 82 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 89548e0..7dc473f 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -23,6 +23,8 @@
#include <asm/hw_irq.h>
#include <asm/ppc-pci.h>
#include <asm/mpic.h>
+#include <asm/fsl_hcalls.h>
+
#include "fsl_msi.h"
#include "fsl_pci.h"
@@ -163,11 +165,13 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
*/
np = of_parse_phandle(hose->dn, "fsl,msi", 0);
if (np) {
- if (of_device_is_compatible(np, "fsl,mpic-msi"))
+ if (of_device_is_compatible(np, "fsl,mpic-msi") ||
+ of_device_is_compatible(np, "fsl,vmpic-msi"))
phandle = np->phandle;
else {
- dev_err(&pdev->dev, "node %s has an invalid fsl,msi"
- " phandle\n", hose->dn->full_name);
+ dev_err(&pdev->dev,
+ "node %s has an invalid fsl,msi phandle %u\n",
+ hose->dn->full_name, np->phandle);
return -EINVAL;
}
}
@@ -196,16 +200,14 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
if (hwirq < 0) {
rc = hwirq;
- pr_debug("%s: fail allocating msi interrupt\n",
- __func__);
+ dev_err(&pdev->dev, "could not allocate MSI interrupt\n");
goto out_free;
}
virq = irq_create_mapping(msi_data->irqhost, hwirq);
if (virq == NO_IRQ) {
- pr_debug("%s: fail mapping hwirq 0x%x\n",
- __func__, hwirq);
+ dev_err(&pdev->dev, "fail mapping hwirq %i\n", hwirq);
msi_bitmap_free_hwirqs(&msi_data->bitmap, hwirq, 1);
rc = -ENOSPC;
goto out_free;
@@ -234,6 +236,7 @@ static void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
u32 intr_index;
u32 have_shift = 0;
struct fsl_msi_cascade_data *cascade_data;
+ unsigned int ret;
cascade_data = irq_get_handler_data(irq);
msi_data = cascade_data->msi_data;
@@ -265,6 +268,14 @@ static void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
case FSL_PIC_IP_IPIC:
msir_value = fsl_msi_read(msi_data->msi_regs, msir_index * 0x4);
break;
+ case FSL_PIC_IP_VMPIC:
+ ret = fh_vmpic_get_msir(virq_to_hw(irq), &msir_value);
+ if (ret) {
+ pr_err("fsl-msi: fh_vmpic_get_msir() failed for "
+ "irq %u (ret=%u)\n", irq, ret);
+ msir_value = 0;
+ }
+ break;
}
while (msir_value) {
@@ -282,6 +293,7 @@ static void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
switch (msi_data->feature & FSL_PIC_IP_MASK) {
case FSL_PIC_IP_MPIC:
+ case FSL_PIC_IP_VMPIC:
chip->irq_eoi(idata);
break;
case FSL_PIC_IP_IPIC:
@@ -311,7 +323,8 @@ static int fsl_of_msi_remove(struct platform_device *ofdev)
}
if (msi->bitmap.bitmap)
msi_bitmap_free(&msi->bitmap);
- iounmap(msi->msi_regs);
+ if ((msi->feature & FSL_PIC_IP_MASK) != FSL_PIC_IP_VMPIC)
+ iounmap(msi->msi_regs);
kfree(msi);
return 0;
@@ -383,26 +396,32 @@ static int __devinit fsl_of_msi_probe(struct platform_device *dev)
goto error_out;
}
- /* Get the MSI reg base */
- err = of_address_to_resource(dev->dev.of_node, 0, &res);
- if (err) {
- dev_err(&dev->dev, "%s resource error!\n",
+ /*
+ * Under the Freescale hypervisor, the msi nodes don't have a 'reg'
+ * property. Instead, we use hypercalls to access the MSI.
+ */
+ if ((features->fsl_pic_ip & FSL_PIC_IP_MASK) != FSL_PIC_IP_VMPIC) {
+ err = of_address_to_resource(dev->dev.of_node, 0, &res);
+ if (err) {
+ dev_err(&dev->dev, "invalid resource for node %s\n",
dev->dev.of_node->full_name);
- goto error_out;
- }
+ goto error_out;
+ }
- msi->msi_regs = ioremap(res.start, resource_size(&res));
- if (!msi->msi_regs) {
- dev_err(&dev->dev, "ioremap problem failed\n");
- goto error_out;
+ msi->msi_regs = ioremap(res.start, resource_size(&res));
+ if (!msi->msi_regs) {
+ dev_err(&dev->dev, "could not map node %s\n",
+ dev->dev.of_node->full_name);
+ goto error_out;
+ }
+ msi->msiir_offset =
+ features->msiir_offset + (res.start & 0xfffff);
}
msi->feature = features->fsl_pic_ip;
msi->irqhost->host_data = msi;
- msi->msiir_offset = features->msiir_offset + (res.start & 0xfffff);
-
/*
* Remember the phandle, so that we can match with any PCI nodes
* that have an "fsl,msi" property.
@@ -476,6 +495,11 @@ static const struct fsl_msi_feature ipic_msi_feature = {
.msiir_offset = 0x38,
};
+static const struct fsl_msi_feature vmpic_msi_feature = {
+ .fsl_pic_ip = FSL_PIC_IP_VMPIC,
+ .msiir_offset = 0,
+};
+
static const struct of_device_id fsl_of_msi_ids[] = {
{
.compatible = "fsl,mpic-msi",
@@ -485,6 +509,10 @@ static const struct of_device_id fsl_of_msi_ids[] = {
.compatible = "fsl,ipic-msi",
.data = (void *)&ipic_msi_feature,
},
+ {
+ .compatible = "fsl,vmpic-msi",
+ .data = (void *)&vmpic_msi_feature,
+ },
{}
};
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index b5d25ba..f6c646a 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -20,9 +20,10 @@
#define IRQS_PER_MSI_REG 32
#define NR_MSI_IRQS (NR_MSI_REG * IRQS_PER_MSI_REG)
-#define FSL_PIC_IP_MASK 0x0000000F
-#define FSL_PIC_IP_MPIC 0x00000001
-#define FSL_PIC_IP_IPIC 0x00000002
+#define FSL_PIC_IP_MASK 0x0000000F
+#define FSL_PIC_IP_MPIC 0x00000001
+#define FSL_PIC_IP_IPIC 0x00000002
+#define FSL_PIC_IP_VMPIC 0x00000003
struct fsl_msi {
struct irq_host *irqhost;
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4ce547e..cd82613 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -113,6 +113,8 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
u32 piwar = PIWAR_EN | PIWAR_PF | PIWAR_TGI_LOCAL |
PIWAR_READ_SNOOP | PIWAR_WRITE_SNOOP;
char *name = hose->dn->full_name;
+ const u64 *reg;
+ int len;
pr_debug("PCI memory map start 0x%016llx, size 0x%016llx\n",
(u64)rsrc->start, (u64)resource_size(rsrc));
@@ -205,6 +207,34 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
/* Setup inbound mem window */
mem = memblock_end_of_DRAM();
+
+ /*
+ * The msi-address-64 property, if it exists, indicates the physical
+ * address of the MSIIR register. Normally, this register is located
+ * inside CCSR, so the ATMU that covers all of CCSR is used. But if
+ * this property exists, then we normally need to create a new ATMU
+ * for it. For now, however, we cheat. The only entity that creates
+ * this property is the Freescale hypervisor, and the address is
+ * specified in the partition configuration. Typically, the address
+ * is located in the page immediately after the end of DDR. If so, we
+ * can avoid allocating a new ATMU by extending the DDR ATMU by one
+ * page.
+ */
+ reg = of_get_property(hose->dn, "msi-address-64", &len);
+ if (reg && (len == sizeof(u64))) {
+ u64 address = be64_to_cpup(reg);
+
+ if ((address >= mem) && (address < (mem + PAGE_SIZE))) {
+ pr_info("%s: extending DDR ATMU to cover MSIIR", name);
+ mem += PAGE_SIZE;
+ } else {
+ /* TODO: Create a new ATMU for MSIIR */
+ pr_warn("%s: msi-address-64 address of %llx in node %s"
+ " is unsupported\n", name, address,
+ hose->dn->full_name);
+ }
+ }
+
sz = min(mem, paddr_lo);
mem_log = __ilog2_u64(sz);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH RESEND] gpio: mpc8xxx: don't allow input-only pins to be output for MPC5121
From: Wolfram Sang @ 2011-12-13 18:23 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, Anatolij Gustschin, linux-kernel, Linus Walleij
In-Reply-To: <20111213181659.GA29243@ponder.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
On Tue, Dec 13, 2011 at 11:16:59AM -0700, Grant Likely wrote:
> On Tue, Dec 13, 2011 at 10:12:48AM +0100, Wolfram Sang wrote:
> > Add a 5121-custom reject if an input-only pin is requested to be output
> > (see 18.3.1.1 in the refman). Also, rewrite mach-specific quirk setup to
> > consume less lines which scales better.
> >
> > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> > ---
> > drivers/gpio/gpio-mpc8xxx.c | 17 ++++++++++++-----
> > 1 files changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> > index ec3fcf0..25dc736 100644
> > --- a/drivers/gpio/gpio-mpc8xxx.c
> > +++ b/drivers/gpio/gpio-mpc8xxx.c
> > @@ -115,6 +115,14 @@ static int mpc8xxx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> > return 0;
> > }
> >
> > +static int mpc5121_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> > +{
> > + /* GPIO 28..31 are input only on MPC5121 */
> > + if (gpio >= 28)
> > + return -EINVAL;
> > +
> > + return mpc8xxx_gpio_dir_out(gc, gpio, val);
> > +}
> > static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
>
> This actually caused a build failure. mpc8xxx_gpio_dir_out() was used before
> it was declared. I moved the symbol to immediately below and applied anyway,
> but how did it compile for you? Should I drop this patch until you retest?
Huh, I am surprised as well. Will investigate tomorrow. Sorry for the
inconvenience.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND] gpio: mpc8xxx: don't allow input-only pins to be output for MPC5121
From: Grant Likely @ 2011-12-13 18:16 UTC (permalink / raw)
To: Wolfram Sang
Cc: linuxppc-dev, Anatolij Gustschin, linux-kernel, Linus Walleij
In-Reply-To: <1323767568-9565-1-git-send-email-w.sang@pengutronix.de>
On Tue, Dec 13, 2011 at 10:12:48AM +0100, Wolfram Sang wrote:
> Add a 5121-custom reject if an input-only pin is requested to be output
> (see 18.3.1.1 in the refman). Also, rewrite mach-specific quirk setup to
> consume less lines which scales better.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> drivers/gpio/gpio-mpc8xxx.c | 17 ++++++++++++-----
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> index ec3fcf0..25dc736 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -115,6 +115,14 @@ static int mpc8xxx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> return 0;
> }
>
> +static int mpc5121_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + /* GPIO 28..31 are input only on MPC5121 */
> + if (gpio >= 28)
> + return -EINVAL;
> +
> + return mpc8xxx_gpio_dir_out(gc, gpio, val);
> +}
> static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
This actually caused a build failure. mpc8xxx_gpio_dir_out() was used before
it was declared. I moved the symbol to immediately below and applied anyway,
but how did it compile for you? Should I drop this patch until you retest?
g.
^ permalink raw reply
* Re: [PATCH RESEND] gpio: mpc8xxx: don't allow input-only pins to be output for MPC5121
From: Grant Likely @ 2011-12-13 18:07 UTC (permalink / raw)
To: Wolfram Sang
Cc: linuxppc-dev, Anatolij Gustschin, linux-kernel, Linus Walleij
In-Reply-To: <1323767568-9565-1-git-send-email-w.sang@pengutronix.de>
On Tue, Dec 13, 2011 at 10:12:48AM +0100, Wolfram Sang wrote:
> Add a 5121-custom reject if an input-only pin is requested to be output
> (see 18.3.1.1 in the refman). Also, rewrite mach-specific quirk setup to
> consume less lines which scales better.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Applied, thanks.
g.
> ---
> drivers/gpio/gpio-mpc8xxx.c | 17 ++++++++++++-----
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> index ec3fcf0..25dc736 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -115,6 +115,14 @@ static int mpc8xxx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> return 0;
> }
>
> +static int mpc5121_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + /* GPIO 28..31 are input only on MPC5121 */
> + if (gpio >= 28)
> + return -EINVAL;
> +
> + return mpc8xxx_gpio_dir_out(gc, gpio, val);
> +}
> static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> {
> struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
> @@ -340,11 +348,10 @@ static void __init mpc8xxx_add_controller(struct device_node *np)
> mm_gc->save_regs = mpc8xxx_gpio_save_regs;
> gc->ngpio = MPC8XXX_GPIO_PINS;
> gc->direction_input = mpc8xxx_gpio_dir_in;
> - gc->direction_output = mpc8xxx_gpio_dir_out;
> - if (of_device_is_compatible(np, "fsl,mpc8572-gpio"))
> - gc->get = mpc8572_gpio_get;
> - else
> - gc->get = mpc8xxx_gpio_get;
> + gc->direction_output = of_device_is_compatible(np, "fsl,mpc5121-gpio") ?
> + mpc5121_gpio_dir_out : mpc8xxx_gpio_dir_out;
> + gc->get = of_device_is_compatible(np, "fsl,mpc8572-gpio") ?
> + mpc8572_gpio_get : mpc8xxx_gpio_get;
> gc->set = mpc8xxx_gpio_set;
> gc->to_irq = mpc8xxx_gpio_to_irq;
>
> --
> 1.7.7.1
>
^ permalink raw reply
* [PATCH V2] gpio: mpc8xxx: don't allow input-only pins to be output for MPC5121
From: Wolfram Sang @ 2011-12-13 17:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Anatolij Gustschin, linuxppc-dev, Linus Walleij
Add a 5121-custom reject if an input-only pin is requested to be output
(see 18.3.1.1 in the refman). Also, rewrite mach-specific quirk setup to
consume less lines which scales better.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
Since V1, added an empty line after the new function.
drivers/gpio/gpio-mpc8xxx.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index ec3fcf0..bb4975f 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -115,6 +115,15 @@ static int mpc8xxx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
return 0;
}
+static int mpc5121_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ /* GPIO 28..31 are input only on MPC5121 */
+ if (gpio >= 28)
+ return -EINVAL;
+
+ return mpc8xxx_gpio_dir_out(gc, gpio, val);
+}
+
static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
{
struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
@@ -340,11 +349,10 @@ static void __init mpc8xxx_add_controller(struct device_node *np)
mm_gc->save_regs = mpc8xxx_gpio_save_regs;
gc->ngpio = MPC8XXX_GPIO_PINS;
gc->direction_input = mpc8xxx_gpio_dir_in;
- gc->direction_output = mpc8xxx_gpio_dir_out;
- if (of_device_is_compatible(np, "fsl,mpc8572-gpio"))
- gc->get = mpc8572_gpio_get;
- else
- gc->get = mpc8xxx_gpio_get;
+ gc->direction_output = of_device_is_compatible(np, "fsl,mpc5121-gpio") ?
+ mpc5121_gpio_dir_out : mpc8xxx_gpio_dir_out;
+ gc->get = of_device_is_compatible(np, "fsl,mpc8572-gpio") ?
+ mpc8572_gpio_get : mpc8xxx_gpio_get;
gc->set = mpc8xxx_gpio_set;
gc->to_irq = mpc8xxx_gpio_to_irq;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH v2 01/19] mxc_udc: add workaround for ENGcm09152 for i.MX25
From: Felipe Balbi @ 2011-12-13 14:18 UTC (permalink / raw)
To: Eric Bénard
Cc: Greg Kroah-Hartman, open list:FREESCALE USB PER..., open list,
Felipe Balbi, Sascha Hauer, open list:FREESCALE USB PER...,
linux-arm-kernel
In-Reply-To: <1323785377-22463-1-git-send-email-eric@eukrea.com>
[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]
Hi,
On Tue, Dec 13, 2011 at 03:09:37PM +0100, Eric Bénard wrote:
> this patch gives the possibility to workaround bug ENGcm09152
> on i.MX25 when the hardware workaround is also implemented on
> the board.
> It covers the workaround described on page 42 of the following Errata,
> titled "USB: UTMI_USBPHY VBUS input impedance implementation error" :
> http://cache.freescale.com/files/dsp/doc/errata/IMX25CE.pdf
>
> Signed-off-by: Eric Bénard <eric@eukrea.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Cc: Li Yang <leoli@freescale.com>
Sascha, are you taking this one or should I take it ? One comment below
though.
> ---
> drivers/usb/gadget/fsl_mxc_udc.c | 22 +++++++++++++---------
> 1 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
> index dcbc0a2..4aff05d 100644
> --- a/drivers/usb/gadget/fsl_mxc_udc.c
> +++ b/drivers/usb/gadget/fsl_mxc_udc.c
> @@ -23,7 +23,7 @@
> static struct clk *mxc_ahb_clk;
> static struct clk *mxc_usb_clk;
>
> -/* workaround ENGcm09152 for i.MX35 */
> +/* workaround ENGcm09152 for i.MX25/35 */
> #define USBPHYCTRL_OTGBASE_OFFSET 0x608
> #define USBPHYCTRL_EVDO (1 << 23)
>
> @@ -89,16 +89,20 @@ eenahb:
> void fsl_udc_clk_finalize(struct platform_device *pdev)
> {
> struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
> - if (cpu_is_mx35()) {
> + if (cpu_is_mx25() || cpu_is_mx35()) {
> unsigned int v;
> -
> - /* workaround ENGcm09152 for i.MX35 */
> + void __iomem *otgbase;
> + if (cpu_is_mx25())
> + otgbase = MX25_IO_ADDRESS(MX25_USB_BASE_ADDR +
> + USBPHYCTRL_OTGBASE_OFFSET);
> + else if (cpu_is_mx35())
> + otgbase = MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
> + USBPHYCTRL_OTGBASE_OFFSET);
I don't want to see cpu_is_* or machine_is_* or <plat/*> or <mach/*>
anywhere on drivers, please make sure to remove them for 3.4 merge
window the latest. You should also make sure that this driver has no
static globals. IOW, I would like to be able to have multiple instances
of this driver working fine.
Granted, you have no boards with such setup, but we made that mistake on
musb driver and now we have a bunch of other stuff to rework in order to
get our dual-MUSB board to work ;-)
I also see that fsl_udc_core.c is still not using dev_pm_ops, please fix
that too.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
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