* Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
From: Andrew Morton @ 2008-04-30 17:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: htejun, jeff, greg, linux-kernel, Emilian.Medve, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804301106010.22992@blarg.am.freescale.net>
On Wed, 30 Apr 2008 11:08:51 -0500 (CDT)
Kumar Gala <galak@kernel.crashing.org> wrote:
> From: Emil Medve <Emilian.Medve@Freescale.com>
>
> We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>
> Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c
>
> Which tree should this go through, powerpc.git?
I'd say so, yes.
> arch/powerpc/lib/Makefile | 1 +
> arch/powerpc/lib/devres.c | 33 +++++++++++++++++++++++++++++++++
> include/asm-powerpc/io.h | 8 +++++++-
> include/linux/io.h | 1 +
> lib/devres.c | 2 +-
>
^ permalink raw reply
* Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Wolfgang Grandegger @ 2008-04-30 17:26 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080430140742.GA789@polina.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Wed, Apr 30, 2008 at 03:19:37PM +0200, Wolfgang Grandegger wrote:
>> Anton Vorontsov wrote:
>>> On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
>>>> Hi Anton,
>>> [...]
>>>>> + upm@1,0 {
>>>>> + #address-cells = <0>;
>>>>> + #size-cells = <0>;
>>>>> + compatible = "fsl,upm-nand";
>>>>> + reg = <1 0 1>;
>>>>> + fsl,upm-addr-offset = <16>;
>>>>> + fsl,upm-cmd-offset = <8>;
>>>>> + gpios = <&qe_pio_e 18 0>;
>>>>> +
>>>>> + flash {
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <1>;
>>>>> + compatible = "stmicro,NAND512W3A2BN6E";
>>>>> +
>>>>> + partition@0 {
>>>>> + ...
>>>>> + };
>>>>> + };
>>>>> + };
>>>> Where can I find the code for that binding? fsl_upm_nand.c from
>>>> http://patchwork.ozlabs.org/linuxppc/patch?q=upm&id=17306 does not parse
>>>> OF partitions. Are there any plans to push the fsl_upm_nand driver
>>>> upstream?
>>> David already pushed UPM NAND driver upstream, but true, it was an "old"
>>> version, i.e. without approved bindings. I'll send the update (inlining
>>> here) if/when these bindings will be applied to the powerpc tree.
>> OK, thanks a lot.
>>
>>> - - - -
>>> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>>> Subject: [NAND] update FSL UPM NAND driver for the new OF bindings
>>>
>>> - get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
>>> chip-specific, and we should always do waits. I saw one board that
>>> didn't need fsl,wait-pattern, but I assume it was exception that
>>> proves general rule;
>>> - get rid of chip-delay. Today there are no users for this, and if
>>> anyone really need this they should push the OF bindings beforehand;
>>> - Now flash chips should be child nodes of the FSL UPM nand controller;
>>> - Implement OF partition parsing.
>> On what hardware did you test the NAND-UPM driver? Unfortunately, the
>> TQM8548 does not support the R/B pin and therefore GPIO support is not
>> needed but a chip delay. Furthermore some "asm sync" are required when
>> executing the run pattern:
>
> Too bad you need this. Oh well, you need to discuss property name with
> the OF guys, or think out some other way to deliver the chip delay
> value.
OK.
>> static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
>> void __iomem *io_base, u32 mar)
>> {
>> int ret = 0, i;
>> unsigned long flags;
>>
>> spin_lock_irqsave(&fsl_lbc_lock, flags);
>>
>> out_be32(&fsl_lbc_regs->mar, mar << (32 - upm->width));
>>
>> asm("sync; isync; msync");
>>
>> switch (upm->width) {
>> case 8:
>> out_8(io_base, 0x0);
>> break;
>> case 16:
>> out_be16(io_base, 0x0);
>> break;
>> case 32:
>> out_be32(io_base, 0x0);
>> break;
>> default:
>> ret = -EINVAL;
>> break;
>> }
>>
>> asm("sync; isync; msync");
>>
>> spin_unlock_irqrestore(&fsl_lbc_lock, flags);
>>
>> return ret;
>> }
>>
>>
>> Is this a known problem with the MPC85xx? How do we handle it?
>
> I did test this driver on MPC8555 and MPC8360 UPMs. They didn't need
> these syncs.. quite suspicious syncs, I must say. Maybe you should
> check TLB setup, for the UPM NAND it should be non-cacheable and
> guarded, IIRC.
I have that. Are you sure about the e500 CPUs. I have not seen any
MPC85xx board in U-Boot or Linux BSP using FSL UPM. Sometimes these
magic sync instructions seem to be needed, e.g., in the MPC8548 manual I
find:
"Also, an msync assembly instruction must be executed after each I2C
register read/write access to guarantee in-order execution."
Can somebody (from freescale?) sched some light on that issue?
TIA.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
From: Scott Wood @ 2008-04-30 17:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <18454.42926.213374.977098@cargo.ozlabs.ibm.com>
On Tue, Apr 29, 2008 at 02:44:30PM +1000, Paul Mackerras wrote:
> 3. The style in all the assembly code is not to have spaces after
> commas separating instruction operands.
I'll do that if that's what is prefered, but how did that come about as
the style used? It's different from what we do in C, and adding the
space helps readability in asm as well...
> The untested patch below is what I was thinking of. If you'd like to
> try it out, I'd be interested to hear how it goes.
It works for me.
-Scott
^ permalink raw reply
* Re: Predefined Compiler Flag for CROSS_COMPILE in ELDK
From: Detlev Zundel @ 2008-04-30 16:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <6e404418e8a1a19e1870eab8117c625e@lesc.ufc.br>
Hi Rodolfo,
> I using ppc_4xx- cross-compiler for build linux in xup virtex II pro.
> How can I change -mpcu compiler flag for a specific vallue for my
> board/processor?
Do the obvious thing - specify it on every command line.
Cheers
Detlev
--
"Oh, didn't you know, the Lord did the original programming of the universe in
COBOL." - "That's why the world is the evil work of Satan. A true divine being
would have used Scheme." - "And, if so, Jesus would have been crucified on a
big lambda symbol." -- K. Chafin, K. Schilling & D. Hanley, on comp.lang.lisp
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* [PATCH v4] sysdev,mv64x60: MV64x60 device bus
From: Remi Machet @ 2008-04-30 16:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Stephen Rothwell
For each mv64360 entry in the OpenFirmware database, add the
registration of an of_bus to take care of devices connected to
the MV64x60 asynchronous devices controller.
This change makes it possible for those devices to be detected by
drivers that support the of_platform without having a custom call
for each of them in the board file.
Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
---
Changes:
v2: Use the compatible field to detect devices to register (on Dale Farnsworth
suggestion).
v3: Added __initdata to variable of_mv64x60_devices (thanks to Stephen Rothwell
for pointing that out).
v4: Re-wrote the patch description.
arch/powerpc/sysdev/mv64x60_dev.c | 10 ++++++++++
1 files changed, 10 insertions(+)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c
index 41af122..c38695e 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -15,6 +15,7 @@
#include <linux/console.h>
#include <linux/mv643xx.h>
#include <linux/platform_device.h>
+#include <linux/of_platform.h>
#include <asm/prom.h>
@@ -25,6 +26,11 @@
* PowerPC of_platform_bus_type. They support platform_bus_type instead.
*/
+static struct of_device_id __initdata of_mv64x60_devices[] = {
+ { .compatible = "marvell,mv64306-devctrl", },
+ {}
+};
+
/*
* Create MPSC platform devices
*/
@@ -482,6 +488,10 @@ static int __init mv64x60_device_setup(void)
of_node_put(np);
}
+ /* Now add every node that is on the device bus (type is devicectrl */
+ for_each_compatible_node(np, NULL, "marvell,mv64360")
+ of_platform_bus_probe(np, of_mv64x60_devices, NULL);
+
return 0;
}
arch_initcall(mv64x60_device_setup);
^ permalink raw reply related
* RE: [PATCH] [POWERPC] Xilinx: Fix compile warnings
From: Stephen Neuendorffer @ 2008-04-30 16:39 UTC (permalink / raw)
To: Kumar Gala, Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804301025270.19599@blarg.am.freescale.net>
Rm9yIHdoYXQgaXQncyB3b3J0aDoNCkFja2VkLWJ5OiBTdGVwaGVuIE5ldWVuZG9yZmZlciA8c3Rl
cGhlbi5uZXVlbmRvcmZmZXJAeGlsaW54LmNvbT4NCg0KVGhlcmUncyBvbmUgb3IgdHdvIG90aGVy
IHRoaW5ncyBJJ3ZlIGJlZW4gbWVhbmluZyB0byBjbGVhbiB1cCwgc3VjaCBhcyB0aGUgc2VjdGlv
biBtaXNtYXRjaCBvbiBod2ljYXBfb2ZfbWF0Y2gsIHRvby4NCg0KU3RldmUNCg0KPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eHBwYy1kZXYtYm91bmNlcytzdGVwaGVu
Lm5ldWVuZG9yZmZlcj14aWxpbnguY29tQG96bGFicy5vcmcgW21haWx0bzpsaW51eHBwYy1kZXYt
DQo+IGJvdW5jZXMrc3RlcGhlbi5uZXVlbmRvcmZmZXI9eGlsaW54LmNvbUBvemxhYnMub3JnXSBP
biBCZWhhbGYgT2YgS3VtYXIgR2FsYQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDMwLCAyMDA4
IDg6MjYgQU0NCj4gVG86IEpvc2ggQm95ZXINCj4gQ2M6IGxpbnV4cHBjLWRldkBvemxhYnMub3Jn
DQo+IFN1YmplY3Q6IFtQQVRDSF0gW1BPV0VSUENdIFhpbGlueDogRml4IGNvbXBpbGUgd2Fybmlu
Z3MNCj4gDQo+IGFyY2gvcG93ZXJwYy9zeXNkZXYveGlsaW54X2ludGMuYzogSW4gZnVuY3Rpb24g
w6LigqzLnHhpbGlueF9pbnRjX2luaXTDouKCrOKEojoNCj4gYXJjaC9wb3dlcnBjL3N5c2Rldi94
aWxpbnhfaW50Yy5jOjExMTogd2FybmluZzogZm9ybWF0IMOi4oKsy5wlMDhYw6LigqzihKIgZXhw
ZWN0cyB0eXBlIMOi4oKsy5x1bnNpZ25lZCBpbnTDouKCrOKEoiwNCj4gYnV0IGFyZ3VtZW50IDIg
aGFzIHR5cGUgw6LigqzLnHJlc291cmNlX3NpemVfdMOi4oKs4oSiDQo+IGRyaXZlcnMvY2hhci94
aWxpbnhfaHdpY2FwL3hpbGlueF9od2ljYXAuYzogSW4gZnVuY3Rpb24gw6LigqzLnGh3aWNhcF9z
ZXR1cMOi4oKs4oSiOg0KPiBkcml2ZXJzL2NoYXIveGlsaW54X2h3aWNhcC94aWxpbnhfaHdpY2Fw
LmM6NjI2OiB3YXJuaW5nOiBjYXN0IHRvIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIG9mIGRpZmZlcmVu
dA0KPiBzaXplDQo+IGRyaXZlcnMvY2hhci94aWxpbnhfaHdpY2FwL3hpbGlueF9od2ljYXAuYzo2
NDY6IHdhcm5pbmc6IGZvcm1hdCDDouKCrMucJXjDouKCrOKEoiBleHBlY3RzIHR5cGUgw6LigqzL
nHVuc2lnbmVkDQo+IGludMOi4oKs4oSiLCBidXQgYXJndW1lbnQgNiBoYXMgdHlwZSDDouKCrMuc
cmVzb3VyY2Vfc2l6ZV90w6LigqzihKINCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEt1bWFyIEdhbGEg
PGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmc+DQo+IC0tLQ0KPiAgYXJjaC9wb3dlcnBjL3N5c2Rl
di94aWxpbnhfaW50Yy5jICAgICAgICAgIHwgICAgMiArLQ0KPiAgZHJpdmVycy9jaGFyL3hpbGlu
eF9od2ljYXAveGlsaW54X2h3aWNhcC5jIHwgICAgNiArKystLS0NCj4gIDIgZmlsZXMgY2hhbmdl
ZCwgNCBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL2Fy
Y2gvcG93ZXJwYy9zeXNkZXYveGlsaW54X2ludGMuYyBiL2FyY2gvcG93ZXJwYy9zeXNkZXYveGls
aW54X2ludGMuYw0KPiBpbmRleCBiYThlZWEyLi5iN2FlZmQwIDEwMDY0NA0KPiAtLS0gYS9hcmNo
L3Bvd2VycGMvc3lzZGV2L3hpbGlueF9pbnRjLmMNCj4gKysrIGIvYXJjaC9wb3dlcnBjL3N5c2Rl
di94aWxpbnhfaW50Yy5jDQo+IEBAIC0xMDcsNyArMTA3LDcgQEAgeGlsaW54X2ludGNfaW5pdChz
dHJ1Y3QgZGV2aWNlX25vZGUgKm5wKQ0KPiAgCX0NCj4gIAlyZWdzID0gaW9yZW1hcChyZXMuc3Rh
cnQsIDMyKTsNCj4gDQo+IC0JcHJpbnRrKEtFUk5fSU5GTyAiWGlsaW54IGludGMgYXQgMHglMDhY
IG1hcHBlZCB0byAweCVwXG4iLA0KPiArCXByaW50ayhLRVJOX0lORk8gIlhpbGlueCBpbnRjIGF0
IDB4JTA4TFggbWFwcGVkIHRvIDB4JXBcbiIsDQo+ICAJCXJlcy5zdGFydCwgcmVncyk7DQo+IA0K
PiAgCS8qIFNldHVwIGludGVycnVwdCBjb250cm9sbGVyICovDQo+IGRpZmYgLS1naXQgYS9kcml2
ZXJzL2NoYXIveGlsaW54X2h3aWNhcC94aWxpbnhfaHdpY2FwLmMgYi9kcml2ZXJzL2NoYXIveGls
aW54X2h3aWNhcC94aWxpbnhfaHdpY2FwLmMNCj4gaW5kZXggZGZlNjkwNy4uM2VkZjFmYyAxMDA2
NDQNCj4gLS0tIGEvZHJpdmVycy9jaGFyL3hpbGlueF9od2ljYXAveGlsaW54X2h3aWNhcC5jDQo+
ICsrKyBiL2RyaXZlcnMvY2hhci94aWxpbnhfaHdpY2FwL3hpbGlueF9od2ljYXAuYw0KPiBAQCAt
NjIzLDggKzYyMyw4IEBAIHN0YXRpYyBpbnQgX19kZXZpbml0IGh3aWNhcF9zZXR1cChzdHJ1Y3Qg
ZGV2aWNlICpkZXYsIGludCBpZCwNCj4gDQo+ICAJaWYgKCFyZXF1ZXN0X21lbV9yZWdpb24oZHJ2
ZGF0YS0+bWVtX3N0YXJ0LA0KPiAgCQkJCQlkcnZkYXRhLT5tZW1fc2l6ZSwgRFJJVkVSX05BTUUp
KSB7DQo+IC0JCWRldl9lcnIoZGV2LCAiQ291bGRuJ3QgbG9jayBtZW1vcnkgcmVnaW9uIGF0ICVw
XG4iLA0KPiAtCQkJKHZvaWQgKilyZWdzX3Jlcy0+c3RhcnQpOw0KPiArCQlkZXZfZXJyKGRldiwg
IkNvdWxkbid0IGxvY2sgbWVtb3J5IHJlZ2lvbiBhdCAlTHhcbiIsDQo+ICsJCQlyZWdzX3Jlcy0+
c3RhcnQpOw0KPiAgCQlyZXR2YWwgPSAtRUJVU1k7DQo+ICAJCWdvdG8gZmFpbGVkMTsNCj4gIAl9
DQo+IEBAIC02NDMsNyArNjQzLDcgQEAgc3RhdGljIGludCBfX2RldmluaXQgaHdpY2FwX3NldHVw
KHN0cnVjdCBkZXZpY2UgKmRldiwgaW50IGlkLA0KPiAgCW11dGV4X2luaXQoJmRydmRhdGEtPnNl
bSk7DQo+ICAJZHJ2ZGF0YS0+aXNfb3BlbiA9IDA7DQo+IA0KPiAtCWRldl9pbmZvKGRldiwgImlv
cmVtYXAgJWx4IHRvICVwIHdpdGggc2l6ZSAleFxuIiwNCj4gKwlkZXZfaW5mbyhkZXYsICJpb3Jl
bWFwICVseCB0byAlcCB3aXRoIHNpemUgJUx4XG4iLA0KPiAgCQkgKHVuc2lnbmVkIGxvbmcgaW50
KWRydmRhdGEtPm1lbV9zdGFydCwNCj4gIAkJCWRydmRhdGEtPmJhc2VfYWRkcmVzcywgZHJ2ZGF0
YS0+bWVtX3NpemUpOw0KPiANCj4gLS0NCj4gMS41LjQuMQ0K
^ permalink raw reply
* [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
From: Kumar Gala @ 2008-04-30 16:08 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, htejun, Jeff Garzik, linux-kernel, Emilian.Medve,
linuxppc-dev
From: Emil Medve <Emilian.Medve@Freescale.com>
We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c
Which tree should this go through, powerpc.git?
- k
arch/powerpc/lib/Makefile | 1 +
arch/powerpc/lib/devres.c | 33 +++++++++++++++++++++++++++++++++
include/asm-powerpc/io.h | 8 +++++++-
include/linux/io.h | 1 +
lib/devres.c | 2 +-
5 files changed, 43 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/lib/devres.c
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 4bb023f..f1d2cdc 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o
endif
obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
+obj-$(CONFIG_HAS_IOMEM) += devres.o
diff --git a/arch/powerpc/lib/devres.c b/arch/powerpc/lib/devres.c
new file mode 100644
index 0000000..b73c64b
--- /dev/null
+++ b/arch/powerpc/lib/devres.c
@@ -0,0 +1,33 @@
+#include <linux/device.h> /* devres_*(), devm_ioremap_release() */
+#include <linux/io.h> /* ioremap_flags() */
+#include <linux/module.h> /* EXPORT_SYMBOL() */
+
+/**
+ * devm_ioremap_flags - Managed ioremap_flags()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ * @flags: Page flags
+ *
+ * Managed ioremap_flags(). Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_flags(offset, size, flags);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_flags);
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index afae069..3b8c334 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -2,7 +2,7 @@
#define _ASM_POWERPC_IO_H
#ifdef __KERNEL__
-/*
+/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
@@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
#define _PNPWRP 0xa79
#define PNPBIOS_BASE 0xf000
+#include <linux/device.h>
+#include <linux/io.h>
+
#include <linux/compiler.h>
#include <asm/page.h>
#include <asm/byteorder.h>
@@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)
#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IO_H */
diff --git a/include/linux/io.h b/include/linux/io.h
index 831f57c..7a390cf 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr)
}
#endif
+void devm_ioremap_release(struct device *dev, void *res);
void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
diff --git a/lib/devres.c b/lib/devres.c
index 26c87c4..72c8909 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -2,7 +2,7 @@
#include <linux/io.h>
#include <linux/module.h>
-static void devm_ioremap_release(struct device *dev, void *res)
+void devm_ioremap_release(struct device *dev, void *res)
{
iounmap(*(void __iomem **)res);
}
--
1.5.4.1
^ permalink raw reply related
* [PATCH] [POWERPC] devres: Add devm_ioremap_flags()
From: Kumar Gala @ 2008-04-30 16:01 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, htejun, Jeff Garzik, linux-kernel, Emilian.Medve,
linuxppc-dev
From: Emil Medve <Emilian.Medve@Freescale.com>
We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Which tree should this go through, powerpc.git?
arch/powerpc/lib/Makefile | 1 +
include/asm-powerpc/io.h | 8 +++++++-
include/linux/io.h | 1 +
lib/devres.c | 2 +-
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 4bb023f..f1d2cdc 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o
endif
obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
+obj-$(CONFIG_HAS_IOMEM) += devres.o
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index afae069..3b8c334 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -2,7 +2,7 @@
#define _ASM_POWERPC_IO_H
#ifdef __KERNEL__
-/*
+/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
@@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
#define _PNPWRP 0xa79
#define PNPBIOS_BASE 0xf000
+#include <linux/device.h>
+#include <linux/io.h>
+
#include <linux/compiler.h>
#include <asm/page.h>
#include <asm/byteorder.h>
@@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)
#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IO_H */
diff --git a/include/linux/io.h b/include/linux/io.h
index 831f57c..7a390cf 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr)
}
#endif
+void devm_ioremap_release(struct device *dev, void *res);
void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
diff --git a/lib/devres.c b/lib/devres.c
index 26c87c4..72c8909 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -2,7 +2,7 @@
#include <linux/io.h>
#include <linux/module.h>
-static void devm_ioremap_release(struct device *dev, void *res)
+void devm_ioremap_release(struct device *dev, void *res)
{
iounmap(*(void __iomem **)res);
}
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Xilinx: Fix compile warnings
From: Stephen Rothwell @ 2008-04-30 15:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804301025270.19599@blarg.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 951 bytes --]
Hi Kumar,
On Wed, 30 Apr 2008 10:25:46 -0500 (CDT) Kumar Gala <galak@kernel.crashing.org> wrote:
>
> arch/powerpc/sysdev/xilinx_intc.c: In function ‘xilinx_intc_init’:
> arch/powerpc/sysdev/xilinx_intc.c:111: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’
> drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function ‘hwicap_setup’:
> drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from integer of different size
> drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format ‘%x’ expects type ‘unsigned int’, but argument 6 has type ‘resource_size_t’
If you compile with LANG=C, you don't get those strange annotations in
your error messages ...
The fix looks good though.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] Xilinx: Fix compile warnings
From: Kumar Gala @ 2008-04-30 15:25 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2189 bytes --]
arch/powerpc/sysdev/xilinx_intc.c: In function ‘xilinx_intc_init’:
arch/powerpc/sysdev/xilinx_intc.c:111: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’
drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function ‘hwicap_setup’:
drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from integer of different size
drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format ‘%x’ expects type ‘unsigned int’, but argument 6 has type ‘resource_size_t’
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/xilinx_intc.c | 2 +-
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
index ba8eea2..b7aefd0 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -107,7 +107,7 @@ xilinx_intc_init(struct device_node *np)
}
regs = ioremap(res.start, 32);
- printk(KERN_INFO "Xilinx intc at 0x%08X mapped to 0x%p\n",
+ printk(KERN_INFO "Xilinx intc at 0x%08LX mapped to 0x%p\n",
res.start, regs);
/* Setup interrupt controller */
diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index dfe6907..3edf1fc 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -623,8 +623,8 @@ static int __devinit hwicap_setup(struct device *dev, int id,
if (!request_mem_region(drvdata->mem_start,
drvdata->mem_size, DRIVER_NAME)) {
- dev_err(dev, "Couldn't lock memory region at %p\n",
- (void *)regs_res->start);
+ dev_err(dev, "Couldn't lock memory region at %Lx\n",
+ regs_res->start);
retval = -EBUSY;
goto failed1;
}
@@ -643,7 +643,7 @@ static int __devinit hwicap_setup(struct device *dev, int id,
mutex_init(&drvdata->sem);
drvdata->is_open = 0;
- dev_info(dev, "ioremap %lx to %p with size %x\n",
+ dev_info(dev, "ioremap %lx to %p with size %Lx\n",
(unsigned long int)drvdata->mem_start,
drvdata->base_address, drvdata->mem_size);
--
1.5.4.1
^ permalink raw reply related
* RE: SKB corruption on heavy traffic
From: Franca, Jose (NSN - PT/Portugal - MiniMD) @ 2008-04-30 15:07 UTC (permalink / raw)
To: ext Scott Wood; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <20080430150053.GB23545@ld0162-tx32.am.freescale.net>
Ok... We will try to enable debug on slab! :)
Ring buffer full occurs on tx in spite of having free bd's in the ring,
it doesn't use them... And it does not recover.
The problems that I refered are from previous kernel versions to ours
(our base of development was 2.4.31) and even on 2.6 kernels.
Filipe
-----Original Message-----
From: ext Scott Wood [mailto:scottwood@freescale.com]=20
Sent: quarta-feira, 30 de Abril de 2008 16:01
To: Franca, Jose (NSN - PT/Portugal - MiniMD)
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: SKB corruption on heavy traffic
On Wed, Apr 30, 2008 at 09:43:33AM +0100, Franca, Jose (NSN -
PT/Portugal - MiniMD) wrote:
> It't quite dificult to say if the problem exists without our
> changes, since the all software is dependent on this changes so
> to work with the hardware. I can't answer to that right now on
> that, but I forgot to add one thing: we have ring buffer full
> problems on our fcc_enet driver from time to time. So, I think
> the problem could be on linux configurations (related to hw)
> because there is a lot of posts on the web related to problems
> similar to this (none of them has really solved the bottom
> problem).
One thing you could try is to enable slab debugging, rather than your
custom debugging code; this will poison the memory upon free, making it
more likely that whatever is accessing it will crash immediately rather
than just cause corruption. Or, if you want to mantain the delay, do
the
poisoning yourself.
Of course, this won't help if the access is write-only, or if the
corruption is happening via DMA.
When you say you have a full ring buffer, do you mean tx or rx? Does it
recover gracefully? Do you think it's caused by something other than
sending data faster than the line can support (tx) or receiving packets
faster than the cpu can handle (rx)?
Are any of the other problem reports from recent, unmodified kernels
(2.4
is very old)?
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
From: Joakim Tjernlund @ 2008-04-30 15:04 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, netdev
In-Reply-To: <fa686aa40804300728y1a761bf9nd4568b682dc0bb52@mail.gmail.com>
On Wed, 2008-04-30 at 08:28 -0600, Grant Likely wrote:
> On Wed, Apr 30, 2008 at 8:16 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >
> >
> > On Wed, 2008-04-30 at 07:26 -0600, Grant Likely wrote:
> > > On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund
> > > <joakim.tjernlund@transmode.se> wrote:
> > > >
> > > >
> > > > On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
> > > > > On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
> > > > > <joakim.tjernlund@transmode.se> wrote:
> > > > > >
> > > > > > On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
> > > > > > > From: Grant Likely <grant.likely@secretlab.ca>
> > > > > > >
> > > > > > > Various improvements for configuring the MPC5200 MII link from the
> > > > > > > device tree:
> > > > > > > * Look for 'current-speed' property for fixed speed MII links
> > > > > >
> > > > > > Not that I have looked, but why can't you use the fixed-link property?
> > > > >
> > > > > fixed-link seems to be a recent invention, whereas current-speed is
> > > > > better know having already been in use with serial devices. It seemed
> > > > > to me to be a better choice, but my opinion can probably be swayed
> > > > > (arguments welcome).
> > > >
> > > > yes it is fairly new. You get alot more than just speed: Duplex/Pause
> > > > You need these too.
> > >
> > > duplex I've got. pause I don't need.
> >
> > dunno how you speify Half/Full Duplex, but isn't it possible that
> > someone else wants to use Pause in the future?
> > Isn't the point that everyone should use fixed-link when it is there
> > for this purpose?
>
> The format of the data is pretty much entirely device dependent (much
> like interrupt and gpio specifiers are controller dependent). I see
> any need in trying to define a common format for this data since it is
> entirely local to the device. ie. there is requirement for this data
> to be in the same format for every device. Also, by not trying to
> lock it down into a common format it gives future devices freedom to
> specify additional flags and parameters in the data.
>
> so,
> * gianfar: needs 5 bits of data.
> * 5200 FEC: only needs 2.
>
> As for 'current-speed' vs. 'fixed-link'. I just think 'current-speed'
> is the better name. :-)
Then some day someone else needs Pause or need to control Duplex. Then
you end up with several impl. Maybe fixed-link isn't the best
name, but it is designed for this purpose.
Anyhow, I not going to argue this more. Seems like I am the
only one thinking it would be better to use fixed-link instead so I
guess I am wrong here.
Jocke
^ permalink raw reply
* Re: SKB corruption on heavy traffic
From: Scott Wood @ 2008-04-30 15:00 UTC (permalink / raw)
To: Franca, Jose (NSN - PT/Portugal - MiniMD); +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <56DEE2D3217CD946B290399093C8FA7C212E1F@PTLIEXC001.nsn-intra.net>
On Wed, Apr 30, 2008 at 09:43:33AM +0100, Franca, Jose (NSN - PT/Portugal - MiniMD) wrote:
> It't quite dificult to say if the problem exists without our
> changes, since the all software is dependent on this changes so
> to work with the hardware. I can't answer to that right now on
> that, but I forgot to add one thing: we have ring buffer full
> problems on our fcc_enet driver from time to time. So, I think
> the problem could be on linux configurations (related to hw)
> because there is a lot of posts on the web related to problems
> similar to this (none of them has really solved the bottom
> problem).
One thing you could try is to enable slab debugging, rather than your
custom debugging code; this will poison the memory upon free, making it
more likely that whatever is accessing it will crash immediately rather
than just cause corruption. Or, if you want to mantain the delay, do the
poisoning yourself.
Of course, this won't help if the access is write-only, or if the
corruption is happening via DMA.
When you say you have a full ring buffer, do you mean tx or rx? Does it
recover gracefully? Do you think it's caused by something other than
sending data faster than the line can support (tx) or receiving packets
faster than the cpu can handle (rx)?
Are any of the other problem reports from recent, unmodified kernels (2.4
is very old)?
-Scott
^ permalink raw reply
* RE: DPMS for Radeon 9600 in G5
From: Sanders, Rob M. @ 2008-04-30 14:45 UTC (permalink / raw)
To: Kevin Diggs, linuxppc-dev
In-Reply-To: <48188C9F.3070805@hypersurf.com>
Kevin,
Have you tried posting to the xorg =
(http://lists.freedesktop.org/mailman/listinfo/xorg) mailing list? =20
They helped me fix an issue I was seeing with my Radeon 9600 and G5. =
I'm running YDL6 with two LCDs hanging
off the back of my Radeon. =20
Rob
-----Original Message-----
From: linuxppc-dev-bounces+sanders-rob=3Dzai.com@ozlabs.org on behalf of =
Kevin Diggs
Sent: Wed 4/30/2008 11:13 AM
To: linuxppc-dev@ozlabs.org
Subject: DPMS for Radeon 9600 in G5
=20
Anyone one have any suggestions on how to get DPMS working for a Radeon=20
9600? Using a DVI cable?
Thanks!
kevin
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
From: Grant Likely @ 2008-04-30 14:28 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev, paulus, netdev
In-Reply-To: <1209564975.16926.8.camel@gentoo-jocke.transmode.se>
On Wed, Apr 30, 2008 at 8:16 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
>
> On Wed, 2008-04-30 at 07:26 -0600, Grant Likely wrote:
> > On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund
> > <joakim.tjernlund@transmode.se> wrote:
> > >
> > >
> > > On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
> > > > On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
> > > > <joakim.tjernlund@transmode.se> wrote:
> > > > >
> > > > > On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
> > > > > > From: Grant Likely <grant.likely@secretlab.ca>
> > > > > >
> > > > > > Various improvements for configuring the MPC5200 MII link from the
> > > > > > device tree:
> > > > > > * Look for 'current-speed' property for fixed speed MII links
> > > > >
> > > > > Not that I have looked, but why can't you use the fixed-link property?
> > > >
> > > > fixed-link seems to be a recent invention, whereas current-speed is
> > > > better know having already been in use with serial devices. It seemed
> > > > to me to be a better choice, but my opinion can probably be swayed
> > > > (arguments welcome).
> > >
> > > yes it is fairly new. You get alot more than just speed: Duplex/Pause
> > > You need these too.
> >
> > duplex I've got. pause I don't need.
>
> dunno how you speify Half/Full Duplex, but isn't it possible that
> someone else wants to use Pause in the future?
> Isn't the point that everyone should use fixed-link when it is there
> for this purpose?
The format of the data is pretty much entirely device dependent (much
like interrupt and gpio specifiers are controller dependent). I see
any need in trying to define a common format for this data since it is
entirely local to the device. ie. there is requirement for this data
to be in the same format for every device. Also, by not trying to
lock it down into a common format it gives future devices freedom to
specify additional flags and parameters in the data.
so,
* gianfar: needs 5 bits of data.
* 5200 FEC: only needs 2.
As for 'current-speed' vs. 'fixed-link'. I just think 'current-speed'
is the better name. :-)
Cheers,
g.
>
> Jocke
>
> Jocke
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* DPMS for Radeon 9600 in G5
From: Kevin Diggs @ 2008-04-30 15:13 UTC (permalink / raw)
To: linuxppc-dev
Anyone one have any suggestions on how to get DPMS working for a Radeon
9600? Using a DVI cable?
Thanks!
kevin
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
From: Joakim Tjernlund @ 2008-04-30 14:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, netdev
In-Reply-To: <fa686aa40804300626v41828f64oc3d0d88ff5954825@mail.gmail.com>
On Wed, 2008-04-30 at 07:26 -0600, Grant Likely wrote:
> On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >
> >
> > On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
> > > On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
> > > <joakim.tjernlund@transmode.se> wrote:
> > > >
> > > > On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
> > > > > From: Grant Likely <grant.likely@secretlab.ca>
> > > > >
> > > > > Various improvements for configuring the MPC5200 MII link from the
> > > > > device tree:
> > > > > * Look for 'current-speed' property for fixed speed MII links
> > > >
> > > > Not that I have looked, but why can't you use the fixed-link property?
> > >
> > > fixed-link seems to be a recent invention, whereas current-speed is
> > > better know having already been in use with serial devices. It seemed
> > > to me to be a better choice, but my opinion can probably be swayed
> > > (arguments welcome).
> >
> > yes it is fairly new. You get alot more than just speed: Duplex/Pause
> > You need these too.
>
> duplex I've got. pause I don't need.
dunno how you speify Half/Full Duplex, but isn't it possible that
someone else wants to use Pause in the future?
Isn't the point that everyone should use fixed-link when it is there
for this purpose?
Jocke
Jocke
^ permalink raw reply
* Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Anton Vorontsov @ 2008-04-30 14:07 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev
In-Reply-To: <481871E9.5000101@grandegger.com>
On Wed, Apr 30, 2008 at 03:19:37PM +0200, Wolfgang Grandegger wrote:
> Anton Vorontsov wrote:
> > On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
> >> Hi Anton,
> > [...]
> >>> + upm@1,0 {
> >>> + #address-cells = <0>;
> >>> + #size-cells = <0>;
> >>> + compatible = "fsl,upm-nand";
> >>> + reg = <1 0 1>;
> >>> + fsl,upm-addr-offset = <16>;
> >>> + fsl,upm-cmd-offset = <8>;
> >>> + gpios = <&qe_pio_e 18 0>;
> >>> +
> >>> + flash {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <1>;
> >>> + compatible = "stmicro,NAND512W3A2BN6E";
> >>> +
> >>> + partition@0 {
> >>> + ...
> >>> + };
> >>> + };
> >>> + };
> >> Where can I find the code for that binding? fsl_upm_nand.c from
> >> http://patchwork.ozlabs.org/linuxppc/patch?q=upm&id=17306 does not parse
> >> OF partitions. Are there any plans to push the fsl_upm_nand driver
> >> upstream?
> >
> > David already pushed UPM NAND driver upstream, but true, it was an "old"
> > version, i.e. without approved bindings. I'll send the update (inlining
> > here) if/when these bindings will be applied to the powerpc tree.
>
> OK, thanks a lot.
>
> > - - - -
> > From: Anton Vorontsov <avorontsov@ru.mvista.com>
> > Subject: [NAND] update FSL UPM NAND driver for the new OF bindings
> >
> > - get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
> > chip-specific, and we should always do waits. I saw one board that
> > didn't need fsl,wait-pattern, but I assume it was exception that
> > proves general rule;
> > - get rid of chip-delay. Today there are no users for this, and if
> > anyone really need this they should push the OF bindings beforehand;
> > - Now flash chips should be child nodes of the FSL UPM nand controller;
> > - Implement OF partition parsing.
>
> On what hardware did you test the NAND-UPM driver? Unfortunately, the
> TQM8548 does not support the R/B pin and therefore GPIO support is not
> needed but a chip delay. Furthermore some "asm sync" are required when
> executing the run pattern:
Too bad you need this. Oh well, you need to discuss property name with
the OF guys, or think out some other way to deliver the chip delay
value.
> static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
> void __iomem *io_base, u32 mar)
> {
> int ret = 0, i;
> unsigned long flags;
>
> spin_lock_irqsave(&fsl_lbc_lock, flags);
>
> out_be32(&fsl_lbc_regs->mar, mar << (32 - upm->width));
>
> asm("sync; isync; msync");
>
> switch (upm->width) {
> case 8:
> out_8(io_base, 0x0);
> break;
> case 16:
> out_be16(io_base, 0x0);
> break;
> case 32:
> out_be32(io_base, 0x0);
> break;
> default:
> ret = -EINVAL;
> break;
> }
>
> asm("sync; isync; msync");
>
> spin_unlock_irqrestore(&fsl_lbc_lock, flags);
>
> return ret;
> }
>
>
> Is this a known problem with the MPC85xx? How do we handle it?
I did test this driver on MPC8555 and MPC8360 UPMs. They didn't need
these syncs.. quite suspicious syncs, I must say. Maybe you should
check TLB setup, for the UPM NAND it should be non-cacheable and
guarded, IIRC.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
From: Grant Likely @ 2008-04-30 13:26 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: netdev, linuxppc-dev, paulus, domen.puncer
In-Reply-To: <1209561053.16926.2.camel@gentoo-jocke.transmode.se>
On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
>
> On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
> > On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
> > <joakim.tjernlund@transmode.se> wrote:
> > >
> > > On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
> > > > From: Grant Likely <grant.likely@secretlab.ca>
> > > >
> > > > Various improvements for configuring the MPC5200 MII link from the
> > > > device tree:
> > > > * Look for 'current-speed' property for fixed speed MII links
> > >
> > > Not that I have looked, but why can't you use the fixed-link property?
> >
> > fixed-link seems to be a recent invention, whereas current-speed is
> > better know having already been in use with serial devices. It seemed
> > to me to be a better choice, but my opinion can probably be swayed
> > (arguments welcome).
>
> yes it is fairly new. You get alot more than just speed: Duplex/Pause
> You need these too.
duplex I've got. pause I don't need.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Wolfgang Grandegger @ 2008-04-30 13:19 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080430111656.GA14148@polina.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
>> Hi Anton,
> [...]
>>> + upm@1,0 {
>>> + #address-cells = <0>;
>>> + #size-cells = <0>;
>>> + compatible = "fsl,upm-nand";
>>> + reg = <1 0 1>;
>>> + fsl,upm-addr-offset = <16>;
>>> + fsl,upm-cmd-offset = <8>;
>>> + gpios = <&qe_pio_e 18 0>;
>>> +
>>> + flash {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "stmicro,NAND512W3A2BN6E";
>>> +
>>> + partition@0 {
>>> + ...
>>> + };
>>> + };
>>> + };
>> Where can I find the code for that binding? fsl_upm_nand.c from
>> http://patchwork.ozlabs.org/linuxppc/patch?q=upm&id=17306 does not parse
>> OF partitions. Are there any plans to push the fsl_upm_nand driver
>> upstream?
>
> David already pushed UPM NAND driver upstream, but true, it was an "old"
> version, i.e. without approved bindings. I'll send the update (inlining
> here) if/when these bindings will be applied to the powerpc tree.
OK, thanks a lot.
> - - - -
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [NAND] update FSL UPM NAND driver for the new OF bindings
>
> - get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
> chip-specific, and we should always do waits. I saw one board that
> didn't need fsl,wait-pattern, but I assume it was exception that
> proves general rule;
> - get rid of chip-delay. Today there are no users for this, and if
> anyone really need this they should push the OF bindings beforehand;
> - Now flash chips should be child nodes of the FSL UPM nand controller;
> - Implement OF partition parsing.
On what hardware did you test the NAND-UPM driver? Unfortunately, the
TQM8548 does not support the R/B pin and therefore GPIO support is not
needed but a chip delay. Furthermore some "asm sync" are required when
executing the run pattern:
static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
void __iomem *io_base, u32 mar)
{
int ret = 0, i;
unsigned long flags;
spin_lock_irqsave(&fsl_lbc_lock, flags);
out_be32(&fsl_lbc_regs->mar, mar << (32 - upm->width));
asm("sync; isync; msync");
switch (upm->width) {
case 8:
out_8(io_base, 0x0);
break;
case 16:
out_be16(io_base, 0x0);
break;
case 32:
out_be32(io_base, 0x0);
break;
default:
ret = -EINVAL;
break;
}
asm("sync; isync; msync");
spin_unlock_irqrestore(&fsl_lbc_lock, flags);
return ret;
}
Is this a known problem with the MPC85xx? How do we handle it?
Wolfgang.
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
From: Joakim Tjernlund @ 2008-04-30 13:10 UTC (permalink / raw)
To: Grant Likely; +Cc: netdev, linuxppc-dev, paulus, domen.puncer
In-Reply-To: <fa686aa40804300607k72ef9985m43b3c4111cad6085@mail.gmail.com>
On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
> On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >
> > On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > Various improvements for configuring the MPC5200 MII link from the
> > > device tree:
> > > * Look for 'current-speed' property for fixed speed MII links
> >
> > Not that I have looked, but why can't you use the fixed-link property?
>
> fixed-link seems to be a recent invention, whereas current-speed is
> better know having already been in use with serial devices. It seemed
> to me to be a better choice, but my opinion can probably be swayed
> (arguments welcome).
yes it is fairly new. You get alot more than just speed: Duplex/Pause
You need these too.
Jocke
^ permalink raw reply
* Re: EXT_IRQ0 @ MPC834x
From: André Schwarz @ 2008-04-30 13:09 UTC (permalink / raw)
To: linux-ppc list
In-Reply-To: <48175059.9080001@matrix-vision.de>
Issue solved !
IRQ has been requested with IRQF_SHARED.
Obviously this is not neccessary and caused this bogus behaviour.
Don't know if it's a bug or a feature.
Cheers,
Andr=E9
Andre Schwarz schrieb:
> All,
>=20
> actually I'm having trouble getting the IRQ0 work on a MPC8343 with
> 2.6.25-rc8.
> There's an external PCI device connected to it ....
>=20
>=20
> Regarding to the manual IRQ0 is somewhat special and has Vector 48 assi=
gned.
>=20
> Therefore my dts entry for this device looks like :
>=20
> interrupt-map =3D <0x5800 0 0 1 &ipic 0x30 0x8
> ... >;
>=20
> Having a look on virq mapping gives :
>=20
> mvBL-M7> cat /sys/kernel/debug/powerpc/virq_mapping
> virq hwirq chip name host name
> 16 0x0000e IPIC /soc@e0000000/pic@700
> 17 0x0000f IPIC /soc@e0000000/pic@700
> 18 0x00009 IPIC /soc@e0000000/pic@700
> 20 0x00010 IPIC /soc@e0000000/pic@700
> 32 0x00020 IPIC /soc@e0000000/pic@700
> 33 0x00021 IPIC /soc@e0000000/pic@700
> 34 0x00022 IPIC /soc@e0000000/pic@700
> 38 0x00026 IPIC /soc@e0000000/pic@700
> 48 0x00030 IPIC /soc@e0000000/pic@700
>=20
>=20
> After loading the device driver (=3Dmvbcdma) the irq shows up correctly=
.
>=20
> mvBL-M7> cat /proc/interrupts
> CPU0
> 16: 603 IPIC Level i2c-mpc
> 17: 8 IPIC Level i2c-mpc
> 18: 295 IPIC Level serial
> 20: 341 IPIC Level mpc83xx_spi
> 32: 2 IPIC Level enet_tx
> 33: 3 IPIC Level enet_rx
> 34: 0 IPIC Level enet_error
> 38: 0 IPIC Level ehci_hcd:usb1
> 48: 0 IPIC Level mvbcdma0
> BAD: 0
>=20
>=20
> As soon as the device generates an interrupt I get :
>=20
> irq 48: nobody cared (try booting with the "irqpoll" option)
> handlers:
> [<d18d66e8>] (mvbcdma_irq+0x0/0x180 [mvbcdma])
> Disabling IRQ #48
>=20
>=20
> The handler _would_ have returned IRQ_RETVAL(1).
> Obviously the handler isn't called at all - but why ?
>=20
>=20
> Using "nm" on the kernel module gives :
>=20
> 000006e8 t mvbcdma_irq
>=20
> ->offset 0x6e8 inside module matches with output regarding handler.
>=20
>=20
> Any help is welcome !
>=20
>=20
> regards,
> Andre Schwarz
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registerger=
icht: Amtsgericht Stuttgart, HRB 271090
> Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
From: Grant Likely @ 2008-04-30 13:07 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: netdev, linuxppc-dev, paulus, domen.puncer
In-Reply-To: <1209540962.18445.8.camel@gentoo-jocke.transmode.se>
On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
> On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Various improvements for configuring the MPC5200 MII link from the
> > device tree:
> > * Look for 'current-speed' property for fixed speed MII links
>
> Not that I have looked, but why can't you use the fixed-link property?
fixed-link seems to be a recent invention, whereas current-speed is
better know having already been in use with serial devices. It seemed
to me to be a better choice, but my opinion can probably be swayed
(arguments welcome).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: FW: SKB corruption on heavy traffic
From: Franca, Jose (NSN - PT/Portugal - MiniMD) @ 2008-04-30 13:03 UTC (permalink / raw)
To: ext Gerhard Pircher, Scott Wood; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <20080430122556.40830@gmx.net>
Hi!
There was a sugestion to change slab to slub alocation method... I =
don't know quite well yet what is necessary to do this, but it seems =
that the current implementation of slub is more commonly available on =
2.6 kernels, not in 2.4 that I use :(...
Any guesses or hints on this?
Regards!
Filipe.
-----Original Message-----
From: ext Gerhard Pircher [mailto:gerhard_pircher@gmx.net]=20
Sent: quarta-feira, 30 de Abril de 2008 13:26
To: Franca, Jose (NSN - PT/Portugal - MiniMD); Scott Wood
Cc: linuxppc-embedded@ozlabs.org; linuxppc-dev@ozlabs.org
Subject: Re: FW: SKB corruption on heavy traffic
Hi,
I think I have the same problem here with all versions of the 2.6.x =
kernel
series (tested with kernel v2.6.8/14/16/18/25 on a PPC7455 machine with
different PCI network cards by transferring a big file over NFS/SCP). =
Data
corruption occurs under high load, but I don't get any kernel oops.
regards,
Gerhard
-------- Original-Nachricht --------
> Datum: Wed, 30 Apr 2008 10:07:15 +0100
> Von: "Franca, Jose (NSN - PT/Portugal - MiniMD)" <jose.franca@nsn.com>
> An: linuxppc-dev@ozlabs.org, linuxppc-embedded@ozlabs.org
> Betreff: FW: SKB corruption on heavy traffic
> >From our latest debugs we found that the problem occurs mainly on =
skbuff
> code. After some variable time kfree or kalloc result in kernel oops.
>=20
> -----Original Message-----
> From: Franca, Jose (NSN - PT/Portugal - MiniMD)=20
> Sent: quarta-feira, 30 de Abril de 2008 9:44
> To: 'ext Scott Wood'
> Cc: =09
> Subject: RE: SKB corruption on heavy traffic
>=20
> Hello!
>=20
> Thank you for replying!
> It't quite dificult to say if the problem exists without our
> changes, since the all software is dependent on this changes so to =
work
> with the hardware. I can't answer to that right now on that, but I =
forgot=20
> to add one thing: we have ring buffer full problems on our fcc_enet
> driver from time to time. So, I think the problem could be on linux
> configurations (related to hw) because there is a lot of posts on the =
web=20
> related to problems similar to this (none of them has really solved =
the
> bottom problem).=20
>=20
> Regards,
> Filipe=20
>=20
> -----Original Message-----
> From: ext Scott Wood [mailto:scottwood@freescale.com]=20
> Sent: ter=E7a-feira, 29 de Abril de 2008 20:15
> To: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: SKB corruption on heavy traffic
>=20
> On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - =
PT/Portugal
> - MiniMD) wrote:
> > We are developing a MPC8247 based telecom board (512MB), using
> > linux 2.4 with some proprietary changes on IP stack and we are =
facing
> > some problems when we have heavy traffic on our Ethernet =
interfaces...
>=20
> Do you see these problems without the proprietary changes, and with a
> current kernel?
>=20
> -Scott
--=20
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! =
http://games.entertainment.gmx.net/de/entertainment/games/free
^ permalink raw reply
* Re: FW: SKB corruption on heavy traffic
From: Gerhard Pircher @ 2008-04-30 12:25 UTC (permalink / raw)
To: Franca, Jose (NSN - PT/Portugal - MiniMD), Scott Wood
Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <56DEE2D3217CD946B290399093C8FA7C212E48@PTLIEXC001.nsn-intra.net>
Hi,
I think I have the same problem here with all versions of the 2.6.x kernel
series (tested with kernel v2.6.8/14/16/18/25 on a PPC7455 machine with
different PCI network cards by transferring a big file over NFS/SCP). Data
corruption occurs under high load, but I don't get any kernel oops.
regards,
Gerhard
-------- Original-Nachricht --------
> Datum: Wed, 30 Apr 2008 10:07:15 +0100
> Von: "Franca, Jose (NSN - PT/Portugal - MiniMD)" <jose.franca@nsn.com>
> An: linuxppc-dev@ozlabs.org, linuxppc-embedded@ozlabs.org
> Betreff: FW: SKB corruption on heavy traffic
> >From our latest debugs we found that the problem occurs mainly on skbuff
> code. After some variable time kfree or kalloc result in kernel oops.
>
> -----Original Message-----
> From: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Sent: quarta-feira, 30 de Abril de 2008 9:44
> To: 'ext Scott Wood'
> Cc:
> Subject: RE: SKB corruption on heavy traffic
>
> Hello!
>
> Thank you for replying!
> It't quite dificult to say if the problem exists without our
> changes, since the all software is dependent on this changes so to work
> with the hardware. I can't answer to that right now on that, but I forgot
> to add one thing: we have ring buffer full problems on our fcc_enet
> driver from time to time. So, I think the problem could be on linux
> configurations (related to hw) because there is a lot of posts on the web
> related to problems similar to this (none of them has really solved the
> bottom problem).
>
> Regards,
> Filipe
>
> -----Original Message-----
> From: ext Scott Wood [mailto:scottwood@freescale.com]
> Sent: terça-feira, 29 de Abril de 2008 20:15
> To: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: SKB corruption on heavy traffic
>
> On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal
> - MiniMD) wrote:
> > We are developing a MPC8247 based telecom board (512MB), using
> > linux 2.4 with some proprietary changes on IP stack and we are facing
> > some problems when we have heavy traffic on our Ethernet interfaces...
>
> Do you see these problems without the proprietary changes, and with a
> current kernel?
>
> -Scott
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.gmx.net/de/entertainment/games/free
^ 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