* drivers/net/fec_8xx config problem
From: Becky Bruce @ 2008-04-30 19:19 UTC (permalink / raw)
To: pantelis.antoniou, jengelh; +Cc: linuxppc-dev@ozlabs.org list
I just noticed that the fec_8xx driver is not currently reachable via
menuconfig because it depends on 8XX instead of 8xx. It looks like
this change occurred in commit
d1c0a65fb597697d1fbce4eadf42b84f70483edc, almost a year ago:
diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig
index a84c232..afb34de 100644
--- a/drivers/net/fec_8xx/Kconfig+++ b/drivers/net/fec_8xx/Kconfig
@@ -1,6 +1,6 @@
config FEC_8XX
tristate "Motorola 8xx FEC driver"
- depends on NET_ETHERNET && 8xx
+ depends on 8XX
select MII
Since nobody has noticed this problem, I'm wondering if this driver
is still in (infrequent) use, or if it's been superseded and should
be removed, or if I'm just completely missing something with respect
to the use of "8XX" instead of "8xx".
I'm happy to submit a patch to correct this, I'm just not sure what
the right answer is.
Thanks,
Becky
^ permalink raw reply
* Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
From: Andrew Morton @ 2008-04-30 19:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, linuxppc-dev, rdunlap, paulus, torvalds
In-Reply-To: <51A34080-7981-4958-B225-4921FC95B84A@kernel.crashing.org>
On Wed, 30 Apr 2008 14:01:12 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Apr 30, 2008, at 1:35 PM, Andrew Morton wrote:
> > On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
> > "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> >
> >> From: Randy Dunlap <randy.dunlap@oracle.com>
> >>
> >> Don't refer to file that no longer exists:
> >> docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file
> >> or directory
> >>
> >> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> >> ---
> >> Documentation/DocBook/rapidio.tmpl | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
> >> +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
> >> @@ -133,7 +133,6 @@
> >> !Idrivers/rapidio/rio-sysfs.c
> >> </sect1>
> >> <sect1 id="PPC32_support"><title>PPC32 support</title>
> >> -!Iarch/powerpc/kernel/rio.c
> >> !Earch/powerpc/sysdev/fsl_rio.c
> >> !Iarch/powerpc/sysdev/fsl_rio.c
> >> </sect1>
> >
> > grumble.
> >
> > This is a subset of rapidio-fix-docbook-references.patch, but I
> > appear to
> > be unable to interest anyone in merging/reviewing/accepting/anything-
> > else
> > that quite large set of patches.
> >
> > Guys, those patches were sent six weeks ago and it now looks like
> > they will
> > miss 2.6.26. This is pretty slack of us. Help?
>
> Odd. I thought Paul had picked up a docbook RapidIO patch from you in
> the latest merge round.
>
Well it's more than "a" patch. The six-week-old patch series is:
rapidio-add-memory-mapping-driver-to-rapidio.patch
rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch
rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch
rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to-space-resources.patch
rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch
rapidio-add-the-memory-mapping-support-in-rionet-driver.patch
rapidio-fix-docbook-references.patch
rapidio-fix-kernel-doc-problems.patch
totalling:
arch/powerpc/sysdev/fsl_rio.c | 13 +
include/linux/rio.h | 10
drivers/net/Kconfig | 10
drivers/net/rionet.c | 324 ++++++++++++++++++++++++++++++
drivers/rapidio/Makefile | 1
drivers/rapidio/rio.c | 10
drivers/rapidio/sallocator/Kconfig | 9
drivers/rapidio/sallocator/Makefile | 12 +
drivers/rapidio/sallocator/bitmap.c | 384 ++++++++++++++++++++++++++++++++++++
include/linux/rio.h | 10
include/linux/rio_drv.h | 41 +++
16 files changed, 1425 insertions(+), 14 deletions(-)
(seems that I forgot to cc Jeff on the rionet change too).
Oh well. If nobody puts their hand up in the next 24 hours or so I'll just
send it all in to Linus.
^ permalink raw reply
* Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
From: Geoff Levand @ 2008-04-30 19:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1209534108.18023.221.camel@pasglop>
Benjamin Herrenschmidt wrote:
> This patch changes vmemmap to use a different region (region 0xf) of the
> address space whose page size can be dynamically configured at boot.
>
> The problem with the current approach of always using 16M pages is that
> it's not well suited to machines that have small amounts of memory such
> as small partitions on pseries, or PS3's.
>
> In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
> tends to prevent hotplugging the HV's "additional" memory, thus limiting
> the available memory even more, from my experience down to something
> like 80M total, which makes it really not very useable.
>
> The logic used by my match to choose the vmemmap page size is:
>
> - If 16M pages are available and there's 1G or more RAM at boot, use that size.
> - Else if 64K pages are available, use that
> - Else use 4K pages
>
> I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
> and it seems to work fine.
>
> However, when attempting to test on a PS3, it didn't boot.
>
> In fact, it doesn't boot without my patch with current upstream.
Yes, this is a know problem I am working on, related to recent
changes in bootmem. Errors with: 'sparse_early_usemap_alloc: allocation failed'.
I tried
> booting 2.6.25 with a ps3_defconfig and that doesn't work neither
> (though at least when doing the later, I do get a black screen & no
> sync, like of ps3fb failed monitor detection, while with current
> upstream, I just get the last kexec messages and nothing happens).
This should work. You are the first to report a problem with
2.6.25. Could you double check your build, and if you still have
trouble, put your vmlinux somewhere I can get it?
> Since the PS3 boot failures are impossible to debug unless your email is
> @sony* and you have the special magic tools, I'll let Geoff try the
> patch out.
OK, I'll try it with the upstream kernel from last week and report
within the next day or so.
-Geoff
^ permalink raw reply
* Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
From: Kumar Gala @ 2008-04-30 19:01 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linuxppc-dev, Randy.Dunlap, Paul Mackerras,
torvalds
In-Reply-To: <20080430113500.dfe21880.akpm@linux-foundation.org>
On Apr 30, 2008, at 1:35 PM, Andrew Morton wrote:
> On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Don't refer to file that no longer exists:
>> docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file
>> or directory
>>
>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>> ---
>> Documentation/DocBook/rapidio.tmpl | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
>> +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
>> @@ -133,7 +133,6 @@
>> !Idrivers/rapidio/rio-sysfs.c
>> </sect1>
>> <sect1 id="PPC32_support"><title>PPC32 support</title>
>> -!Iarch/powerpc/kernel/rio.c
>> !Earch/powerpc/sysdev/fsl_rio.c
>> !Iarch/powerpc/sysdev/fsl_rio.c
>> </sect1>
>
> grumble.
>
> This is a subset of rapidio-fix-docbook-references.patch, but I
> appear to
> be unable to interest anyone in merging/reviewing/accepting/anything-
> else
> that quite large set of patches.
>
> Guys, those patches were sent six weeks ago and it now looks like
> they will
> miss 2.6.26. This is pretty slack of us. Help?
Odd. I thought Paul had picked up a docbook RapidIO patch from you in
the latest merge round.
- k
^ permalink raw reply
* Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
From: Randy Dunlap @ 2008-04-30 18:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Benjamin, linux-kernel, linuxppc-dev, Paul Mackerras, torvalds
In-Reply-To: <20080430113500.dfe21880.akpm@linux-foundation.org>
On Wed, 30 Apr 2008 11:35:00 -0700 Andrew Morton wrote:
> On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> >
> > Don't refer to file that no longer exists:
> > docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file or directory
> >
> > Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> > ---
> > Documentation/DocBook/rapidio.tmpl | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
> > +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
> > @@ -133,7 +133,6 @@
> > !Idrivers/rapidio/rio-sysfs.c
> > </sect1>
> > <sect1 id="PPC32_support"><title>PPC32 support</title>
> > -!Iarch/powerpc/kernel/rio.c
> > !Earch/powerpc/sysdev/fsl_rio.c
> > !Iarch/powerpc/sysdev/fsl_rio.c
> > </sect1>
>
> grumble.
>
> This is a subset of rapidio-fix-docbook-references.patch, but I appear to
> be unable to interest anyone in merging/reviewing/accepting/anything-else
> that quite large set of patches.
>
> Guys, those patches were sent six weeks ago and it now looks like they will
> miss 2.6.26. This is pretty slack of us. Help?
There's nothing there that can hurt. (famous last words)
Just merge it.
---
~Randy
^ permalink raw reply
* Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
From: Andrew Morton @ 2008-04-30 18:35 UTC (permalink / raw)
To: Randy.Dunlap
Cc: Benjamin, linux-kernel, linuxppc-dev, Paul Mackerras, torvalds
In-Reply-To: <Pine.LNX.4.64.0804292009000.18219@shark.he.net>
On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Don't refer to file that no longer exists:
> docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file or directory
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> Documentation/DocBook/rapidio.tmpl | 1 -
> 1 file changed, 1 deletion(-)
>
> --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
> +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
> @@ -133,7 +133,6 @@
> !Idrivers/rapidio/rio-sysfs.c
> </sect1>
> <sect1 id="PPC32_support"><title>PPC32 support</title>
> -!Iarch/powerpc/kernel/rio.c
> !Earch/powerpc/sysdev/fsl_rio.c
> !Iarch/powerpc/sysdev/fsl_rio.c
> </sect1>
grumble.
This is a subset of rapidio-fix-docbook-references.patch, but I appear to
be unable to interest anyone in merging/reviewing/accepting/anything-else
that quite large set of patches.
Guys, those patches were sent six weeks ago and it now looks like they will
miss 2.6.26. This is pretty slack of us. Help?
^ permalink raw reply
* Re: mpc8379e rdb nand flash support
From: Scott Wood @ 2008-04-30 18:28 UTC (permalink / raw)
To: ???; +Cc: linuxppc-embedded
In-Reply-To: <2F9EE17A2D4D48458F49220889E0FAAD@baby>
On Thu, Apr 24, 2008 at 09:52:25AM +0800, ??? wrote:
> Since our projects need more capability to store filesystems,I changed nand flash to 1G byte.
> I think it is the same to operate nand flash both in u-boot and linux kernel ,because the code about FCM nand flash control is almost the same.So I just test it in u-boot.
> From the mpc8379e reference manual page 484 :
> 21 PGS NAND Flash E2PROM page size, buffer size, and block size.
> 0 Page size of 512 main area bytes plus 16 spare area bytes (small page devices);
> FCM RAM buffers are 1 Kbyte each; Flash block size of 16 Kbytes.
> 1 Page size of 2048 main area bytes plus 64 spare area bytes (large page devices);
> FCM RAM buffers are 4 Kbytes each; Flash block size of 128 Kbytes.
>
> Because the 32M nand flash block size is just the 16Kbytes,and it
> works well.But the block size of the 1G bytes nand flash is
> 256Kbytes,when every time I tried to write to it ,It just can be writed
> the first 128kbytes of every 256kbytes.As I wrote in last email.
> Below is the linux kernel information when I operate nand flash.
Try changing set_addr() to hardcode the shift applied before writing to
FBAR to the width of FPAR[PI], rather than basing it on the actual erase
block size.
-Scott
^ permalink raw reply
* 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
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