* Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Scott Wood @ 2010-10-04 15:38 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A256099@zch01exm23.fsl.freescale.net>
On Sat, 2 Oct 2010 05:36:27 -0700
"Zang Roy-R61911" <r61911@freescale.com> wrote:
>
>
> > -----Original Message-----
> > From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> > Sent: Monday, September 20, 2010 21:19 PM
> > To: Zang Roy-R61911
> > Cc: linux-mtd@lists.infradead.org; dwmw2@infradead.org; dedekind1@gmail.com;
> > akpm@linux-foundation.org; Lan Chunhe-B25806; Wood Scott-B07421; Gala Kumar-
> > B11780; linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand
> > flash partitions
> >
> > On Fri, Sep 17, 2010 at 03:01:08PM +0800, Roy Zang wrote:
> > [...]
> > > +static struct mutex fsl_elbc_nand_mutex;
> > > +
> > > +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> > > {
> > > - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> > > + struct fsl_lbc_regs __iomem *lbc;
> > > struct fsl_elbc_mtd *priv;
> > > struct resource res;
> > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
> >
> > No need for = NULL.
> Any harm? Or just personal habit or style? Can you explain about why?
Besides not wanting superfluous code on general principle, it could
hide a bug if in the future the real initialization is missing on some
code path. It would become a runtime NULL dereference rather than a
compiler warning.
-Scott
^ permalink raw reply
* Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
From: Nathan Fontenot @ 2010-10-04 14:45 UTC (permalink / raw)
To: balbir
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <20101003182701.GI7896@balbir.in.ibm.com>
On 10/03/2010 01:27 PM, Balbir Singh wrote:
> * Dave Hansen <dave@linux.vnet.ibm.com> [2010-10-03 11:11:01]:
>
>> On Sun, 2010-10-03 at 13:07 -0500, Robin Holt wrote:
>>> On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote:
>>>> * Nathan Fontenot <nfont@austin.ibm.com> [2010-10-01 13:35:54]:
>>>>
>>>>> Define a version of memory_block_size_bytes() for powerpc/pseries such that
>>>>> a memory block spans an entire lmb.
>>>>
>>>> I hope I am not missing anything obvious, but why not just call it
>>>> lmb_size, why do we need memblock_size?
>>>>
>>>> Is lmb_size == memblock_size after your changes true for all
>>>> platforms?
>>>
>>> What is an lmb? I don't recall anything like lmb being referred to in
>>> the rest of the kernel.
>>
>> Heh. It's the OpenFirmware name for a Logical Memory Block. Basically
>> what we use to determine the SECTION_SIZE on powerpc. Probably not the
>> best terminology to use elsewhere in the kernel.
>
> Agreed for the kernel, this patch was for powerpc/pseries, hence was
> checking in this context.
>
I don't really see a reason to name it lmb_size, it seems easier
to stick with the naming used by the rest of the kernel.
-Nathan
^ permalink raw reply
* advice on reading a call trace
From: Jean-Mickael Guerin @ 2010-10-04 11:24 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm stepping into ppc world and I'd like to know how to read this call trace,
I enabled debug options but I'm not able to track the origin of this bug, I mean
what happens before handle_page_fault():
Unable to handle kernel paging request for data at address 0x00000008
Faulting instruction address: 0xc00abcd8
[c1d0dd40] [c00ab2e4] swapin_readahead+0x34/0xbc
[c1d0dd80] [c009e91c] handle_mm_fault+0x724/0x9b0
[c1d0dde0] [c0014e10] do_page_fault+0x2e8/0x55c
[c1d0df40] [c000fc8c] handle_page_fault+0xc/0x80
Instruction dump:
80010034 7d435378 bb210014 38210030 7c0803a6 4e800020 7d695b78 4bffff00
387a007c 4847616d 38000001 7c00f830 <817b0008> 7d3c0214 7f895840 7f9ee378
Kernel panic - not syncing: Fatal exception
Another one:
NIP: c00b6980 LR: c00b6978 CTR: 0f9ffb20
REGS: d6a9dc60 TRAP: 0300 Not tainted (2.6.34.6-00392-g31e1857)
MSR: 10029002 CR: 24004442 XER: 00000000
DEAR: 00000008, ESR: 00000000
TASK = da6a7440[4915] 'smrd' THREAD: d6a9c000 CPU: 0
GPR00: 00000008 d6a9dd10 da6a7440 c0738340 00000000 00000000 00000000 00000001
GPR08: 00000000 00000000 c00b6978 00000000 44004442 10027f04 c077790c d79f94a8
GPR16: d6a9dd88 c07a0000 d72301f0 d6a9c000 000001ff 00000000 0f9ffb20 da5c6f78
GPR24: d79f9440 c0738340 d6a9dd48 00000000 07832400 00000001 00000003 07832400
NIP [c00b6980] valid_swaphandles+0x19c/0x1d0
LR [c00b6978] valid_swaphandles+0x194/0x1d0
Call Trace:
[d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0 (unreliable)
[d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
[d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
[d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
[d6a9df40] [c001061c] handle_page_fault+0xc/0x80
Instruction dump:
38210030 7c0803a6 4e800020 7d695b78 4bffff04 3d20c074 39298300 3b290040
7f23cb78 484843a9 38000001 7c00f030 <817b0008> 7d3f0214 7f895840 7ffdfb78
Kernel panic - not syncing: Fatal exception
Call Trace:
[d6a9dba0] [c000765c] show_stack+0x40/0x15c (unreliable)
[d6a9dbd0] [c053b780] panic+0x94/0x118
[d6a9dc20] [c000d630] die+0x15c/0x1bc
[d6a9dc40] [c00155a4] bad_page_fault+0x90/0xc8
[d6a9dc50] [c001068c] handle_page_fault+0x7c/0x80
[d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0
[d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
[d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
[d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
[d6a9df40] [c001061c] handle_page_fault+0xc/0x80
Rebooting in 5 seconds..
Thanks,
Jean-Mickael
^ permalink raw reply
* Re: Introduce support for little endian PowerPC
From: Michel Dänzer @ 2010-10-04 10:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie
In-Reply-To: <1285966204.2463.137.camel@pasglop>
On Sam, 2010-10-02 at 06:50 +1000, Benjamin Herrenschmidt wrote:=20
> On Fri, 2010-10-01 at 18:20 +0200, Michel D=C3=A4nzer wrote:
> > On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote:=20
> > >=20
> > > Now, the main reasons in practice are anything touching graphics.
> > >=20
> > > There's quite a few IP cores out there for SoCs that don't have HW
> > > swappers, and -tons- of more or less ugly code that can't deal with n=
on
> > > native pixel ordering (hell, even Xorg isn't good at it, we really on=
ly
> > > support cards that have HW swappers today).
> >=20
> > That's not true. Even the radeon driver doesn't really need the HW
> > swappers anymore with KMS.
>=20
> And last I looked X still pukes if you give it a pixmap in non native
> byte order but that might have been fixed.
I'm not sure what exactly you mean by that, but I'm not aware of any
such issues offhand.
> > > There's an even bigger pile of application code that deals with graph=
ics
> > > without any regard for endianness and is essentially unfixable.
> >=20
> > Out of curiosity, what kind of APIs are those apps using? X11 and OpenG=
L
> > have well-defined semantics wrt endianness, allowing the drivers to
> > handle any necessary byte swapping internally, and IME the vast majorit=
y
> > of apps handle this correctly.
>=20
> So why is it so hard to get any video card working on ppc ? :-)
I didn't say anything about that, just that IME it should be mostly
possible to deal with endianness within the driver stack.
Note that I'm not arguing against these changes, just pointing out some
apparent inaccuracies in the reasoning for them.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Ppc to PowerPC changes relating to XGPIO
From: Guillaume Dargaud @ 2010-10-04 9:33 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
when I was using the PPC kernel a couple versions back, I had modified the
xgpio_ioctl.h file (and its related adapter.c) in order to extend the
xgpio_ioctl() function with new commands for my needs.
But now I don't see where the equivalent code is located with the new
architecture. How do I interact win GPIOs from usermode if not for ioctl calls
? (I need to manipulate the direction bits, not just read/write values).
Note: I'm using the kernel provided by the Xilinx git, so maybe my question
isn't relevant here.
Thanks
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* powerpc, fs_enet: scanning PHY after Linux is up
From: Heiko Schocher @ 2010-10-04 7:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, devicetree-discuss, Holger Brunck, Detlev Zundel
Hello all,
we have on the mgcoge arch/powerpc/boot/dts/mgcoge.dts 3 fs_enet
devices. The first is accessible on boot, and so get correct
probed and works fine. For the other two fs_enet devices the PHYs
are on startup in reset, and gets later, through userapplikations,
out of reset ... so, on bootup, this 2 fs_enet devices could
not detect the PHY in drivers/of/of_mdio.c of_mdiobus_register(),
and if we want to use them later, we get for example:
-bash-3.2# ifconfig eth2 172.31.31.33
net eth2: Could not attach to PHY
SIOCSIFFLAGS: No such device
So the problem is, that we cannot rescan the PHYs, if they are
accessible. Also we could not load the fs_enet driver as a module,
because the first port is used fix.
So, first question which comes in my mind, is:
Is detecting the phy in drivers/of/of_mdio.c of_mdiobus_register()
the right place, or should it not better be done, when really
using the port?
But we found another way to solve this issue:
After the PHYs are out of reset, we just have to rescan the PHYs
with (for example PHY with addr 1)
err = mdiobus_scan(bus, 1);
and
of_find_node_by_path("/soc@f0000000/cpm@119c0/mdio@10d40/ethernet-phy@1");
of_node_get(np);
dev_archdata_set_node(&err->dev.archdata, np);
but thats just a hack ...
So, the question is, is there a possibility to solve this problem?
If there is no standard option, what would be with adding a
"scan_phy" file in
/proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40
(or better destination?)
which with we could rescan a PHY with
"echo addr > /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40/scan_phy"
(so there is no need for using of_find_node_by_path(), as we should
have the associated device node here, and can step through the child
nodes with "for_each_child_of_node(np, child)" and check if reg == addr)
or shouldn;t be at least, if the phy couldn;t be found when opening
the port, retrigger a scanning, if the phy now is accessible?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: use of BAT before taking over the MMU
From: Segher Boessenkool @ 2010-10-04 4:25 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikPhpvJetY+NDFggYE6Wp6ppyt2BLmzEbsiwHuZ@mail.gmail.com>
> On the prom boot path, with the firmware supposed to
> be managing the MMU, there is a case where:
>
> 1. Linux changes some BAT registers.
> 2. Bits 0x00000070 are/become set in the MSR.
> 3. Linux takes an MMU fault.
> 4. The firmware handles it.
>
> AFAIK, you can't expect the firmware to leave the BAT alone.
> If the firmware provides mapping services by using the BAT
> as a software-filled TLB, Linux's BAT changes may be lost.
>
> You also can't expect that your BAT changes will not conflict
> with mappings that the firmware uses for itself. The firmware
> might write to your new BAT mapping, relying on those virtual
> addresses to be something else entirely.
The PowerPC OF binding requires the firmware to save and restore
the BATs on entry to / exit from the firmware.
Segher
^ permalink raw reply
* Re: ppc44x - how do i optimize driver for tlb hits
From: Benjamin Herrenschmidt @ 2010-10-03 22:38 UTC (permalink / raw)
To: Ayman El-Khashab; +Cc: linuxppc-dev
In-Reply-To: <20101003191305.GA7345@crust.elkhashab.com>
On Sun, 2010-10-03 at 14:13 -0500, Ayman El-Khashab wrote:
> On Sat, Sep 25, 2010 at 08:11:04AM +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2010-09-24 at 08:08 -0500, Ayman El-Khashab wrote:
> > >
> > > I suppose another option is to to use the kernel profiling option I
> > > always see but have never used. Is that a viable option to figure out
> > > what is happening here?
> >
> > With perf and stochastic sampling ? If you sample fast enough... but
> > you'll mostly point to your routine I suppose... though it might tell
> > you statistically where in your code, which -might- help.
> >
>
> Thanks I didn't end up profiling it b/c we found the biggest culprit.
> Basically we were mapping this memory in kernel space and as long as we
> did that ONLY everything was ok. But then we would mmap the physical
> addresses into user space. Using MAP_SHARED made it extremely slow.
> Using MAP_PRIVATE made it very fast. So it works, but why is MAP_SHARED
> that much slower?
I don't see any reason off hand why this would be the case. Can you
inspect the content of the TLB with either xmon or whatever HW debugger
you may have at hand and show me what difference you have between an
entry for your workload coming from MAP_SHARED vs. one coming from
MAP_PRIVATE ?
> The other optimization was a change in the algorithm to take advantage
> of the L2 prefetching. Since we were operating on many simultaneous
> streams it seems that the cache performance was not good.
Cheers,
Ben.
> thanks
> ame
^ permalink raw reply
* Re: ppc44x - how do i optimize driver for tlb hits
From: Ayman El-Khashab @ 2010-10-03 19:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1285366264.14081.33.camel@pasglop>
On Sat, Sep 25, 2010 at 08:11:04AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-09-24 at 08:08 -0500, Ayman El-Khashab wrote:
> >
> > I suppose another option is to to use the kernel profiling option I
> > always see but have never used. Is that a viable option to figure out
> > what is happening here?
>
> With perf and stochastic sampling ? If you sample fast enough... but
> you'll mostly point to your routine I suppose... though it might tell
> you statistically where in your code, which -might- help.
>
Thanks I didn't end up profiling it b/c we found the biggest culprit.
Basically we were mapping this memory in kernel space and as long as we
did that ONLY everything was ok. But then we would mmap the physical
addresses into user space. Using MAP_SHARED made it extremely slow.
Using MAP_PRIVATE made it very fast. So it works, but why is MAP_SHARED
that much slower?
The other optimization was a change in the algorithm to take advantage
of the L2 prefetching. Since we were operating on many simultaneous
streams it seems that the cache performance was not good.
thanks
ame
^ permalink raw reply
* Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
From: Balbir Singh @ 2010-10-03 18:27 UTC (permalink / raw)
To: Dave Hansen
Cc: Greg KH, steiner, linux-kernel, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <1286129461.9970.1.camel@nimitz>
* Dave Hansen <dave@linux.vnet.ibm.com> [2010-10-03 11:11:01]:
> On Sun, 2010-10-03 at 13:07 -0500, Robin Holt wrote:
> > On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote:
> > > * Nathan Fontenot <nfont@austin.ibm.com> [2010-10-01 13:35:54]:
> > >
> > > > Define a version of memory_block_size_bytes() for powerpc/pseries such that
> > > > a memory block spans an entire lmb.
> > >
> > > I hope I am not missing anything obvious, but why not just call it
> > > lmb_size, why do we need memblock_size?
> > >
> > > Is lmb_size == memblock_size after your changes true for all
> > > platforms?
> >
> > What is an lmb? I don't recall anything like lmb being referred to in
> > the rest of the kernel.
>
> Heh. It's the OpenFirmware name for a Logical Memory Block. Basically
> what we use to determine the SECTION_SIZE on powerpc. Probably not the
> best terminology to use elsewhere in the kernel.
Agreed for the kernel, this patch was for powerpc/pseries, hence was
checking in this context.
--
Three Cheers,
Balbir
^ permalink raw reply
* Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
From: Dave Hansen @ 2010-10-03 18:11 UTC (permalink / raw)
To: Robin Holt
Cc: Greg KH, steiner, linux-kernel, linux-mm, linuxppc-dev,
KAMEZAWA Hiroyuki, Balbir Singh
In-Reply-To: <20101003180731.GT14064@sgi.com>
On Sun, 2010-10-03 at 13:07 -0500, Robin Holt wrote:
> On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote:
> > * Nathan Fontenot <nfont@austin.ibm.com> [2010-10-01 13:35:54]:
> >
> > > Define a version of memory_block_size_bytes() for powerpc/pseries such that
> > > a memory block spans an entire lmb.
> >
> > I hope I am not missing anything obvious, but why not just call it
> > lmb_size, why do we need memblock_size?
> >
> > Is lmb_size == memblock_size after your changes true for all
> > platforms?
>
> What is an lmb? I don't recall anything like lmb being referred to in
> the rest of the kernel.
Heh. It's the OpenFirmware name for a Logical Memory Block. Basically
what we use to determine the SECTION_SIZE on powerpc. Probably not the
best terminology to use elsewhere in the kernel.
-- Dave
^ permalink raw reply
* Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
From: Robin Holt @ 2010-10-03 18:07 UTC (permalink / raw)
To: Balbir Singh
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <20101003175500.GE7896@balbir.in.ibm.com>
On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote:
> * Nathan Fontenot <nfont@austin.ibm.com> [2010-10-01 13:35:54]:
>
> > Define a version of memory_block_size_bytes() for powerpc/pseries such that
> > a memory block spans an entire lmb.
>
> I hope I am not missing anything obvious, but why not just call it
> lmb_size, why do we need memblock_size?
>
> Is lmb_size == memblock_size after your changes true for all
> platforms?
What is an lmb? I don't recall anything like lmb being referred to in
the rest of the kernel.
Robin
^ permalink raw reply
* Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
From: Balbir Singh @ 2010-10-03 17:55 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA62A0A.4050406@austin.ibm.com>
* Nathan Fontenot <nfont@austin.ibm.com> [2010-10-01 13:35:54]:
> Define a version of memory_block_size_bytes() for powerpc/pseries such that
> a memory block spans an entire lmb.
I hope I am not missing anything obvious, but why not just call it
lmb_size, why do we need memblock_size?
Is lmb_size == memblock_size after your changes true for all
platforms?
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
> ---
> arch/powerpc/platforms/pseries/hotplug-memory.c | 66 +++++++++++++++++++-----
> 1 file changed, 53 insertions(+), 13 deletions(-)
>
> Index: linux-next/arch/powerpc/platforms/pseries/hotplug-memory.c
> ===================================================================
> --- linux-next.orig/arch/powerpc/platforms/pseries/hotplug-memory.c 2010-09-30 14:44:37.000000000 -0500
> +++ linux-next/arch/powerpc/platforms/pseries/hotplug-memory.c 2010-09-30 14:47:04.000000000 -0500
> @@ -17,6 +17,54 @@
> #include <asm/pSeries_reconfig.h>
> #include <asm/sparsemem.h>
>
> +static unsigned long get_memblock_size(void)
> +{
> + struct device_node *np;
> + unsigned int memblock_size = 0;
> +
> + np = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
> + if (np) {
> + const unsigned long *size;
> +
> + size = of_get_property(np, "ibm,lmb-size", NULL);
> + memblock_size = size ? *size : 0;
> +
> + of_node_put(np);
> + } else {
> + unsigned int memzero_size = 0;
> + const unsigned int *regs;
> +
> + np = of_find_node_by_path("/memory@0");
> + if (np) {
> + regs = of_get_property(np, "reg", NULL);
> + memzero_size = regs ? regs[3] : 0;
> + of_node_put(np);
> + }
> +
> + if (memzero_size) {
> + /* We now know the size of memory@0, use this to find
> + * the first memoryblock and get its size.
> + */
Nit: comment style is not correct
> + char buf[64];
> +
> + sprintf(buf, "/memory@%x", memzero_size);
> + np = of_find_node_by_path(buf);
> + if (np) {
> + regs = of_get_property(np, "reg", NULL);
> + memblock_size = regs ? regs[3] : 0;
> + of_node_put(np);
> + }
> + }
> + }
> +
> + return memblock_size;
> +}
> +
> +unsigned long memory_block_size_bytes(void)
> +{
> + return get_memblock_size();
> +}
> +
> static int pseries_remove_memblock(unsigned long base, unsigned int memblock_size)
> {
> unsigned long start, start_pfn;
> @@ -127,30 +175,22 @@
>
> static int pseries_drconf_memory(unsigned long *base, unsigned int action)
> {
> - struct device_node *np;
> - const unsigned long *lmb_size;
> + unsigned long memblock_size;
> int rc;
>
> - np = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
> - if (!np)
> + memblock_size = get_memblock_size();
> + if (!memblock_size)
> return -EINVAL;
>
> - lmb_size = of_get_property(np, "ibm,lmb-size", NULL);
> - if (!lmb_size) {
> - of_node_put(np);
> - return -EINVAL;
> - }
> -
> if (action == PSERIES_DRCONF_MEM_ADD) {
> - rc = memblock_add(*base, *lmb_size);
> + rc = memblock_add(*base, memblock_size);
> rc = (rc < 0) ? -EINVAL : 0;
> } else if (action == PSERIES_DRCONF_MEM_REMOVE) {
> - rc = pseries_remove_memblock(*base, *lmb_size);
> + rc = pseries_remove_memblock(*base, memblock_size);
> } else {
> rc = -EINVAL;
> }
>
> - of_node_put(np);
> return rc;
> }
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
--
Three Cheers,
Balbir
^ permalink raw reply
* Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
From: Avi Kivity @ 2010-10-03 7:52 UTC (permalink / raw)
To: Greg KH
Cc: linuxppc-dev, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
KAMEZAWA Hiroyuki
In-Reply-To: <20100929123752.GA18865@kroah.com>
On 09/29/2010 02:37 PM, Greg KH wrote:
> >> > Thankfully things like rpm, hald, and other miscellaneous commands scan
> >> > that information.
> >>
> >> Really? Why? Why would rpm care about this? hald is dead now so we
> >> don't need to worry about that anymore,
> >
> > That's not what compatiblity means. We can't just support
> > latest-and-greatest userspace on latest-and-greatest kernels.
>
> Oh, I know that, that's not what I was getting at at all here, sorry if
> it came across that way.
>
> I wanted to know so we could go fix programs that are mucking around in
> these files, as odds are, the shouldn't be doing that in the first
> place.
>
> Like rpm, why would it matter what the memory in the system looks like?
>
I see, thanks.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness
From: Benjamin Herrenschmidt @ 2010-10-03 6:22 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, devicetree-discuss, linux-kernel, paulus,
Ian Munsie, Jeremy Kerr, linuxppc-dev
In-Reply-To: <20101003031555.GB28565@angua.secretlab.ca>
On Sat, 2010-10-02 at 21:15 -0600, Grant Likely wrote:
>
> But I won't merge this through my tree unless Ben asks me to.
Being careful heh ? :-)
I'll take care of these.
Cheers,
Ben.
^ permalink raw reply
* Re: [patch 1/1] powerpc: enable ARCH_DMA_ADDR_T_64BIT with ARCH_PHYS_ADDR_T_64BIT
From: Benjamin Herrenschmidt @ 2010-10-03 6:20 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: linuxppc-dev, akpm
In-Reply-To: <20101002190634E.fujita.tomonori@lab.ntt.co.jp>
> Really?
>
> The current dma_addr_t is:
>
> #if defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT)
> typedef u64 dma_addr_t;
> #else
> typedef u32 dma_addr_t;
> #endif
> typedef u64 dma64_addr_t;
-EBRAINFAI ... either I wasn't looking when we changed it or I just
forgot :-) We -used-, I'm pretty sure, to have it always 32-bit :-)
Anyways, doesn't matter. Patch looks good. We can always tweak the
config option if we want to later.
Cheers,
Ben.
>
> I think that this patch doesn't change anything. Or I miss something?
>
> @@ -22,6 +22,9 @@ config WORD_SIZE
> config ARCH_PHYS_ADDR_T_64BIT
> def_bool PPC64 || PHYS_64BIT
>
> +config ARCH_DMA_ADDR_T_64BIT
> + def_bool ARCH_PHYS_ADDR_T_64BIT
> +
> config MMU
> bool
> default y
^ permalink raw reply
* [PROBLEM] linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic
From: emin ak @ 2010-10-03 6:19 UTC (permalink / raw)
To: linuxppc-dev, linux-netdev; +Cc: Linux kernel, David Miller
Hi all,
My problem is kernel crash under full line rate random packet length
ip network traffic.
I'am using default unmodified kernel and default SMP kernel
configuration, MPC8572DS development board and also using a hardware
packet generator.
My test is ip forwarding between eth0 and eth1, and Hardware packet
generator produces full duplex, full line rate traffic with random
packet length and random payload . After a few millions of packets
passed, kernel produces this bellow two different crash messages . I
have retry this scenario many times, crash occurs sometimes on
skb_put, but mostly occurs on ip_rcv function. I have aplied same
test to latest stable linux 2.6.35.6 kernel. Same errors produced.
Any comment and help are appreciated.
Here is crash logs:
Thanks.
Emin
First type of crash:
root@mpc8572ds:~# skb_over_panic: text:c0226280 len:1171 put:1171
head:eed6d000 data:eed63040 tail:0xeed6d4d3 end:0xeed63660 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:127!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=2 MPC8572 DS
last sysfs file: /sys/devices/pci0002:03/0002:03:00.0/subsystem_device
Modules linked in:
NIP: c023bdcc LR: c023bdcc CTR: c01f3ff8
REGS: effe7d70 TRAP: 0700 Not tainted (2.6.36-rc5)
MSR: 00029000 <EE,ME,CE> CR: 22028024 XER: 20000000
TASK = ef83e9a0[9] 'ksoftirqd/1' THREAD: ef856000 CPU: 1
GPR00: c023bdcc effe7e20 ef83e9a0 0000007c 00021000 ffffffff c01f7b98 c03ccf1c
GPR08: c03c69d4 c03f94b4 00c4e000 00000004 20028048 1001a108 ef211000 efb52d90
GPR16: efb52e38 efb52870 00000000 ef211800 00000008 00000009 efb52800 00000037
GPR24: ef24e180 ef2be040 00000000 ef211948 efb52b80 00000493 ef015940 ef386600
NIP [c023bdcc] skb_put+0x8c/0x94
LR [c023bdcc] skb_put+0x8c/0x94
Call Trace:
[effe7e20] [c023bdcc] skb_put+0x8c/0x94 (unreliable)
[effe7e30] [c0226280] gfar_clean_rx_ring+0x104/0x4b8
[effe7e90] [c02269dc] gfar_poll+0x3a8/0x60c
[effe7f60] [c024928c] net_rx_action+0xf8/0x1a4
[effe7fa0] [c0042524] __do_softirq+0xe0/0x178
[effe7ff0] [c000e59c] call_do_softirq+0x14/0x24
[ef857f50] [c0004840] do_softirq+0x90/0xa0
[ef857f70] [c00430e4] run_ksoftirqd+0xb4/0x164
[ef857fb0] [c00586b4] kthread+0x7c/0x80
[ef857ff0] [c000e9a8] kernel_thread+0x4c/0x68
Instruction dump:
81030098 2f800000 409e000c 3d20c037 3809a19c 3c60c037 7c8802a6 7d695b78
3863b010 90010008 4cc63182 4be016c5 <0fe00000> 48000000 9421fff0 7c0802a6
Kernel panic - not syncing: Fatal exception in interrupt
---------------
second type of crash:
Faulting instruction address: 0xc026c1dc
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2 MPC8572 DS
last sysfs file: /sys/devices/pci0002:03/0002:03:00.0/subsystem_device
Modules linked in:
NIP: c026c1dc LR: c026bfac CTR: 00000000
REGS: effebd00 TRAP: 0300 Not tainted (2.6.36-rc5)
MSR: 00029000 <EE,ME,CE> CR: 42028042 XER: 00000000
DEAR: 0000cad8, ESR: 00000000
TASK = ef83cde0[3] 'ksoftirqd/0' THREAD: ef84a000 CPU: 0
GPR00: 00000005 effebdb0 ef83cde0 00000000 000001b9 00000000 c1008060 00000000
GPR08: 02c3f605 0000ca00 000005b9 0000ca00 b653a6c7 7af823f0 ef217000 efbab590
GPR16: efbab638 efbab070 00000000 ef217800 00000008 00000018 efbab000 00000028
GPR24: c03f971c c0410000 c0400000 c03f94b4 effea000 ef316e40 00000000 eecb685e
NIP [c026c1dc] ip_rcv+0x3f8/0x808
LR [c026bfac] ip_rcv+0x1c8/0x808
Call Trace:
[effebdb0] [c026c204] ip_rcv+0x420/0x808 (unreliable)
[effebde0] [c02482dc] __netif_receive_skb+0x2f8/0x324
[effebe10] [c02483a4] netif_receive_skb+0x9c/0xb0
[effebe30] [c0226308] gfar_clean_rx_ring+0x18c/0x4b8
[effebe90] [c02269dc] gfar_poll+0x3a8/0x60c
[effebf60] [c024928c] net_rx_action+0xf8/0x1a4
[effebfa0] [c0042524] __do_softirq+0xe0/0x178
[effebff0] [c000e59c] call_do_softirq+0x14/0x24
[ef84bf50] [c0004840] do_softirq+0x90/0xa0
[ef84bf70] [c00430e4] run_ksoftirqd+0xb4/0x164
[ef84bfb0] [c00586b4] kthread+0x7c/0x80
[ef84bff0] [c000e9a8] kernel_thread+0x4c/0x68
Instruction dump:
8148003c 318a0001 7d690194 91680038 9188003c 4bfffd78 7fa3eb78 48002a29
2f830000 40beff50 817d0048 5569003c <a00900d8> 2f800005 419e0034 2f800003
Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* [git pull] MPC5xxx powerpc fixes
From: Grant Likely @ 2010-10-03 4:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Linus Torvalds, linuxppc-dev,
Akinobu Mita, Eric Millbrandt, Julia Lawall
Hi Ben and Linus
Here are some powerpc fixes that I had sitting in my tree and forgot
about. They are ready to be merged, and are for the mpc5xxx platform
that I maintain, but Ben hasn't acked them yet. Ben, do you want
Linus to pull this directly, or do you have other powerpc commits that
you want to merge it with before Linus picks it up?
Thanks,
g.
The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00:
Linus Torvalds (1):
Linux 2.6.36-rc6
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 merge-powerpc
Akinobu Mita (1):
powerpc/512x: fix clk_get() return value
Eric Millbrandt (1):
powerpc/5200: tighten up ac97 reset timing
Julia Lawall (1):
powerpc/5200: efika.c: Add of_node_put to avoid memory leak
arch/powerpc/platforms/512x/clock.c | 2 +-
arch/powerpc/platforms/52xx/efika.c | 9 ++++++---
arch/powerpc/platforms/52xx/mpc52xx_common.c | 8 ++++++--
3 files changed, 13 insertions(+), 6 deletions(-)
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness
From: Grant Likely @ 2010-10-03 3:15 UTC (permalink / raw)
To: Ian Munsie
Cc: Michal Simek, devicetree-discuss, linux-kernel, paulus,
Jeremy Kerr, linuxppc-dev
In-Reply-To: <1285916771-18033-10-git-send-email-imunsie@au1.ibm.com>
On Fri, Oct 01, 2010 at 05:06:02PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> On PowerPC the device tree is always big endian, but the CPU could be
> either, so add be32_to_cpu where appropriate and change the types of
> device tree data to __be32 etc to allow sparse to locate endian issues.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
But I won't merge this through my tree unless Ben asks me to.
g.
> ---
> arch/powerpc/kernel/prom.c | 60 ++++++++++++++++++++++----------------------
> 1 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index fed9bf6..9b9ebb2 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -188,16 +188,16 @@ static void __init check_cpu_pa_features(unsigned long node)
> #ifdef CONFIG_PPC_STD_MMU_64
> static void __init check_cpu_slb_size(unsigned long node)
> {
> - u32 *slb_size_ptr;
> + __be32 *slb_size_ptr;
>
> slb_size_ptr = of_get_flat_dt_prop(node, "slb-size", NULL);
> if (slb_size_ptr != NULL) {
> - mmu_slb_size = *slb_size_ptr;
> + mmu_slb_size = be32_to_cpup(slb_size_ptr);
> return;
> }
> slb_size_ptr = of_get_flat_dt_prop(node, "ibm,slb-size", NULL);
> if (slb_size_ptr != NULL) {
> - mmu_slb_size = *slb_size_ptr;
> + mmu_slb_size = be32_to_cpup(slb_size_ptr);
> }
> }
> #else
> @@ -252,11 +252,11 @@ static void __init check_cpu_feature_properties(unsigned long node)
> {
> unsigned long i;
> struct feature_property *fp = feature_properties;
> - const u32 *prop;
> + const __be32 *prop;
>
> for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
> prop = of_get_flat_dt_prop(node, fp->name, NULL);
> - if (prop && *prop >= fp->min_value) {
> + if (prop && be32_to_cpup(prop) >= fp->min_value) {
> cur_cpu_spec->cpu_features |= fp->cpu_feature;
> cur_cpu_spec->cpu_user_features |= fp->cpu_user_ftr;
> }
> @@ -269,8 +269,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
> {
> static int logical_cpuid = 0;
> char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> - const u32 *prop;
> - const u32 *intserv;
> + const __be32 *prop;
> + const __be32 *intserv;
> int i, nthreads;
> unsigned long len;
> int found = 0;
> @@ -297,9 +297,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
> * version 2 of the kexec param format adds the phys cpuid of
> * booted proc.
> */
> - if (initial_boot_params && initial_boot_params->version >= 2) {
> - if (intserv[i] ==
> - initial_boot_params->boot_cpuid_phys) {
> + if (initial_boot_params && be32_to_cpu(initial_boot_params->version) >= 2) {
> + if (be32_to_cpu(intserv[i]) ==
> + be32_to_cpu(initial_boot_params->boot_cpuid_phys)) {
> found = 1;
> break;
> }
> @@ -324,9 +324,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>
> if (found) {
> DBG("boot cpu: logical %d physical %d\n", logical_cpuid,
> - intserv[i]);
> + be32_to_cpu(intserv[i]));
> boot_cpuid = logical_cpuid;
> - set_hard_smp_processor_id(boot_cpuid, intserv[i]);
> + set_hard_smp_processor_id(boot_cpuid, be32_to_cpu(intserv[i]));
>
> /*
> * PAPR defines "logical" PVR values for cpus that
> @@ -343,8 +343,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
> * it uses 0x0f000001.
> */
> prop = of_get_flat_dt_prop(node, "cpu-version", NULL);
> - if (prop && (*prop & 0xff000000) == 0x0f000000)
> - identify_cpu(0, *prop);
> + if (prop && (be32_to_cpup(prop) & 0xff000000) == 0x0f000000)
> + identify_cpu(0, be32_to_cpup(prop));
>
> identical_pvr_fixup(node);
> }
> @@ -365,7 +365,7 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>
> void __init early_init_dt_scan_chosen_arch(unsigned long node)
> {
> - unsigned long *lprop;
> + unsigned long *lprop; /* All these set by kernel, so no need to convert endian */
>
> #ifdef CONFIG_PPC64
> /* check if iommu is forced on or off */
> @@ -524,16 +524,16 @@ void __init early_init_dt_setup_initrd_arch(unsigned long start,
> static void __init early_reserve_mem(void)
> {
> u64 base, size;
> - u64 *reserve_map;
> + __be64 *reserve_map;
> unsigned long self_base;
> unsigned long self_size;
>
> - reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
> - initial_boot_params->off_mem_rsvmap);
> + reserve_map = (__be64 *)(((unsigned long)initial_boot_params) +
> + be32_to_cpu(initial_boot_params->off_mem_rsvmap));
>
> /* before we do anything, lets reserve the dt blob */
> self_base = __pa((unsigned long)initial_boot_params);
> - self_size = initial_boot_params->totalsize;
> + self_size = be32_to_cpu(initial_boot_params->totalsize);
> memblock_reserve(self_base, self_size);
>
> #ifdef CONFIG_BLK_DEV_INITRD
> @@ -547,13 +547,13 @@ static void __init early_reserve_mem(void)
> * Handle the case where we might be booting from an old kexec
> * image that setup the mem_rsvmap as pairs of 32-bit values
> */
> - if (*reserve_map > 0xffffffffull) {
> + if (be64_to_cpup(reserve_map) > 0xffffffffull) {
> u32 base_32, size_32;
> - u32 *reserve_map_32 = (u32 *)reserve_map;
> + __be32 *reserve_map_32 = (__be32 *)reserve_map;
>
> while (1) {
> - base_32 = *(reserve_map_32++);
> - size_32 = *(reserve_map_32++);
> + base_32 = be32_to_cpup(reserve_map_32++);
> + size_32 = be32_to_cpup(reserve_map_32++);
> if (size_32 == 0)
> break;
> /* skip if the reservation is for the blob */
> @@ -566,8 +566,8 @@ static void __init early_reserve_mem(void)
> }
> #endif
> while (1) {
> - base = *(reserve_map++);
> - size = *(reserve_map++);
> + base = be64_to_cpup(reserve_map++);
> + size = be64_to_cpup(reserve_map++);
> if (size == 0)
> break;
> DBG("reserving: %llx -> %llx\n", base, size);
> @@ -860,7 +860,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
> hardid = get_hard_smp_processor_id(cpu);
>
> for_each_node_by_type(np, "cpu") {
> - const u32 *intserv;
> + const __be32 *intserv;
> unsigned int plen, t;
>
> /* Check for ibm,ppc-interrupt-server#s. If it doesn't exist
> @@ -869,10 +869,10 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
> intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
> &plen);
> if (intserv == NULL) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> + const __be32 *reg = of_get_property(np, "reg", NULL);
> if (reg == NULL)
> continue;
> - if (*reg == hardid) {
> + if (be32_to_cpup(reg) == hardid) {
> if (thread)
> *thread = 0;
> return np;
> @@ -880,7 +880,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
> } else {
> plen /= sizeof(u32);
> for (t = 0; t < plen; t++) {
> - if (hardid == intserv[t]) {
> + if (hardid == be32_to_cpu(intserv[t])) {
> if (thread)
> *thread = t;
> return np;
> @@ -900,7 +900,7 @@ static int __init export_flat_device_tree(void)
> struct dentry *d;
>
> flat_dt_blob.data = initial_boot_params;
> - flat_dt_blob.size = initial_boot_params->totalsize;
> + flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
>
> d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
> powerpc_debugfs_root, &flat_dt_blob);
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH] PPC4xx: ADMA separating SoC specific functions
From: Greg KH @ 2010-10-02 18:49 UTC (permalink / raw)
To: Dan Williams
Cc: Wolfgang Denk, Tirumala Marri, yur, linux-raid, linux-crypto,
linuxppc-dev
In-Reply-To: <AANLkTi=JqTU898DfW1=4qcb2WbwHvroY6LqiAX_oBb5L@mail.gmail.com>
On Thu, Sep 30, 2010 at 05:57:10PM -0700, Dan Williams wrote:
> [ adding Greg ]
>
> On Thu, Sep 30, 2010 at 5:16 PM, Tirumala Marri <tmarri@apm.com> wrote:
> >> Where ?iop_adma_alloc_slots() is implemented differently between
> >> iop13xx and iop3xx. ?In this case why does ppc440spe-adma.h exist? ?If
> >> it has code specific to ppe440spe it should just live in the ppe440spe
> >> C file. ?If it is truly generic it should move to the base adma.c
> >> implementation. ?If you want to reuse a ppe440spe routine just link to
> >> it.
> > [Marri]That is how I started changing the code. And I see tons of warnings
> > Saying "Used but not defined" or "Defined but not used". How should I
> > suppress
> > Some functions from adma.c are used in ppc440spe-adma.c and some from
> > ppc440spe-adma.c
> > Are used in adma.c.
>
> This is part of defining a common interface. Maybe look at the
> linkages of how the common ioat_probe() routine is used to support all
> three versions of its dma hardware.
>
> > So I created intermediate file ppc440spe-adma.h with
> > inlined
> > Functions. In future this will be converted into ppc4xx_adma.h and move
> > existing
> > SoC specific stuff to ppc440spe-adma.c file.
>
> You definitely need to be able to resolve "used but not defined" and
> "defined but not used" warnings before tackling a driver conversion
> like this. In light of this comment I wonder if it would be
> appropriate to submit your original driver, that just duplicated
> routines from the ppc440spe driver, to the -staging tree. Then it
> would be available for someone familiar with driver conversions to
> take a shot at unifying.
>
> Greg, is this an appropriate use of -staging?
Possibly, but I really don't like duplication if possible. What's
keeping this code from being fixed up now properly?
thanks,
greg k-h
^ permalink raw reply
* use of BAT before taking over the MMU
From: Albert Cahalan @ 2010-10-02 18:32 UTC (permalink / raw)
To: linuxppc-dev
On the prom boot path, with the firmware supposed to
be managing the MMU, there is a case where:
1. Linux changes some BAT registers.
2. Bits 0x00000070 are/become set in the MSR.
3. Linux takes an MMU fault.
4. The firmware handles it.
AFAIK, you can't expect the firmware to leave the BAT alone.
If the firmware provides mapping services by using the BAT
as a software-filled TLB, Linux's BAT changes may be lost.
You also can't expect that your BAT changes will not conflict
with mappings that the firmware uses for itself. The firmware
might write to your new BAT mapping, relying on those virtual
addresses to be something else entirely.
^ permalink raw reply
* arch/powerpc/*/div64.S
From: Albert Cahalan @ 2010-10-02 18:16 UTC (permalink / raw)
To: linuxppc-dev
This looks like duplicated code getting out of sync.
$ diff -Naurd arch/powerpc/lib/div64.S arch/powerpc/boot/div64.S
--- arch/powerpc/lib/div64.S 2009-09-09 18:13:59.000000000 -0400
+++ arch/powerpc/boot/div64.S 2009-09-09 18:13:59.000000000 -0400
@@ -13,10 +13,10 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
-#include <asm/ppc_asm.h>
-#include <asm/processor.h>
+#include "ppc_asm.h"
-_GLOBAL(__div64_32)
+ .globl __div64_32
+__div64_32:
lwz r5,0(r3) # get the dividend into r5/r6
lwz r6,4(r3)
cmplw r5,r4
@@ -33,10 +33,9 @@
cntlzw r0,r5 # we are shifting the dividend right
li r10,-1 # to make it < 2^32, and shifting
srw r10,r10,r0 # the divisor right the same amount,
- addc r9,r4,r10 # rounding up (so the estimate cannot
+ add r9,r4,r10 # rounding up (so the estimate cannot
andc r11,r6,r10 # ever be too large, only too small)
andc r9,r9,r10
- addze r9,r9
or r11,r5,r11
rotlw r9,r9,r0
rotlw r11,r11,r0
^ permalink raw reply
* RE: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-10-02 12:36 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100920131907.GA2184@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1i
ZXIgMjAsIDIwMTAgMjE6MTkgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgt
bXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IGR3bXcyQGluZnJhZGVhZC5vcmc7IGRlZGVraW5kMUBn
bWFpbC5jb207DQo+IGFrcG1AbGludXgtZm91bmRhdGlvbi5vcmc7IExhbiBDaHVuaGUtQjI1ODA2
OyBXb29kIFNjb3R0LUIwNzQyMTsgR2FsYSBLdW1hci0NCj4gQjExNzgwOyBsaW51eHBwYy1kZXZA
b3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDIvMyB2NF0gUDQwODAvbXRkOiBPbmx5
IG1ha2UgZWxiYyBuYW5kIGRyaXZlciBkZXRlY3QgbmFuZA0KPiBmbGFzaCBwYXJ0aXRpb25zDQo+
IA0KPiBPbiBGcmksIFNlcCAxNywgMjAxMCBhdCAwMzowMTowOFBNICswODAwLCBSb3kgWmFuZyB3
cm90ZToNCj4gWy4uLl0NCj4gPiArc3RhdGljIHN0cnVjdCBtdXRleCBmc2xfZWxiY19uYW5kX211
dGV4Ow0KPiA+ICsNCj4gPiArc3RhdGljIGludCBfX2RldmluaXQgZnNsX2VsYmNfbmFuZF9wcm9i
ZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpkZXYpDQo+ID4gIHsNCj4gPiAtCXN0cnVjdCBmc2xf
bGJjX3JlZ3MgX19pb21lbSAqbGJjID0gY3RybC0+cmVnczsNCj4gPiArCXN0cnVjdCBmc2xfbGJj
X3JlZ3MgX19pb21lbSAqbGJjOw0KPiA+ICAJc3RydWN0IGZzbF9lbGJjX210ZCAqcHJpdjsNCj4g
PiAgCXN0cnVjdCByZXNvdXJjZSByZXM7DQo+ID4gKwlzdHJ1Y3QgZnNsX2VsYmNfZmNtX2N0cmwg
KmVsYmNfZmNtX2N0cmwgPSBOVUxMOw0KPiANCj4gTm8gbmVlZCBmb3IgPSBOVUxMLg0KQW55IGhh
cm0/IE9yIGp1c3QgcGVyc29uYWwgaGFiaXQgb3Igc3R5bGU/IENhbiB5b3UgZXhwbGFpbiBhYm91
dCB3aHk/DQpUaGFua3MuDQpSb3kNCg==
^ permalink raw reply
* Re: [patch 1/1] powerpc: enable ARCH_DMA_ADDR_T_64BIT with ARCH_PHYS_ADDR_T_64BIT
From: FUJITA Tomonori @ 2010-10-02 10:11 UTC (permalink / raw)
To: benh; +Cc: fujita.tomonori, linuxppc-dev, akpm
In-Reply-To: <1285989654.2463.286.camel@pasglop>
On Sat, 02 Oct 2010 13:20:54 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2010-10-01 at 21:31 -0400, Josh Boyer wrote:
> > > +config ARCH_DMA_ADDR_T_64BIT
> > > + def_bool ARCH_PHYS_ADDR_T_64BIT
> > > +
> >
> > I seemed to have missed what this is about entirely. Is there some
> > place I can look that describes what that is supposed to do? The PPC
This patchset unifies dma_addr_t typedef.
> > 4xx boards set PHYS_ADDR_T_64BIT because the MMU uses 36 bit
> > addressing, but the CPU is only 32 bits. I want to make sure this DMA
> > thing isn't going to cause problems.
this patchset changes nothing. Please see below.
> Yes, we need to test a bit. Our dma_addr_t has remained 32-bit so far
> because despite the fact that we've had routinely to deal with >32-bit
> physical addresses for MMIO, physical memory support has been
> constrained afaik to 32-bit.
Really?
The current dma_addr_t is:
#if defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT)
typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
#endif
typedef u64 dma64_addr_t;
I think that this patch doesn't change anything. Or I miss something?
@@ -22,6 +22,9 @@ config WORD_SIZE
config ARCH_PHYS_ADDR_T_64BIT
def_bool PPC64 || PHYS_64BIT
+config ARCH_DMA_ADDR_T_64BIT
+ def_bool ARCH_PHYS_ADDR_T_64BIT
+
config MMU
bool
default y
^ permalink raw reply
* Re: Serial RapidIO Maintaintance read causes lock up
From: Bastiaan Nijkamp @ 2010-10-02 7:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTikSaBR4vEikhGp0fsY3FnZCJQT2D-vw9=Kh4UHn@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6487 bytes --]
Hi,
It seems i forgot to include the relevant TLB entries in U-Boot and the
Device Tree in the e-mail, so here they are:
The TLB entries in U-Boot:
/*
* TLB 3: 256M Non-cacheable, guarded
* 0xc0000000 256M Rapid IO MEM First half
*/
SET_TLB_ENTRY(1, CONFIG_SYS_RIO_MEM_VIRT, CONFIG_SYS_RIO_MEM_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 3, BOOKE_PAGESZ_256M, 1),
/*
* TLB 4: 256M Non-cacheable, guarded
* 0xd0000000 256M Rapid IO MEM Second half
*/
SET_TLB_ENTRY(1, CONFIG_SYS_RIO_MEM_VIRT + 0x10000000,
CONFIG_SYS_RIO_MEM_PHYS + 0x10000000,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 4, BOOKE_PAGESZ_256M, 1),
And the device tree entry:
rapidio0:rapidio@c0000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,rapidio-delta";
reg = <0xc0000 0x20000>;
ranges = <0x0 0xc0000000 0x20000000>;
interrupt-parent = <&mpic>;
/* err_irq bell_outb_irq bell_inb_irq
msg1_tx_irq msg1_rx_irq msg2_tx_irq msg2_rx_irq */
interrupts = <0x30 0x2 0x31 0x2 0x32 0x2 0x35 0x2 0x36 0x2 0x37
0x2 0x38 0x2>;
};
Regards,
Bastiaan Nijkamp
2010/10/2 Bastiaan Nijkamp <bastiaan.nijkamp@gmail.com>
> Hi,
>
> We are currently evaluating Serial RapidIO on two WindRiver SBC8548 boards
> that use a Freescale Powerquicc III processor (MPC8548E rev. 2). We are
> running U-Boot version 2010.09 as bootloader and are using kernel version
> 2.6.35.6 stable.
>
> We have consulted multiple resources to collect al the requirements for
> a successful RapidIO connection (LAW, TLB, Registers) and we seem to have
> configured everything correctly. However, as soon as the board that is
> configured as the host starts the enumeration process, the system locks up.
> It locks in such a manner that we cannot use a JTAG interface to read any of
> the registers. We have also added a breakpoint just before the command that
> causes the lock up, to make sure the registers are correctly set at that
> point, and it seems they are.
>
> We have tripple checked everything that we could possibly think of and
> everything seems to be configured as required but the system keeps
> locking-up so there must be something that we are missing. I really hope
> that someone could point us in the right direction. The lock-up occurs when
> __fsl_read_rio_config is called by fsl_rio_config_read in fsl-rio.c.
>
> The LAW and TLB entries we have added to U-Boot are as follows:
>
> #define CONFIG_RIO 1
> #define CONFIG_SYS_RIO_MEM_VIRT 0xc0000000 /* base address */
> #define CONFIG_SYS_RIO_MEM_BUS 0xc0000000 /* base address */
> #define CONFIG_SYS_RIO_MEM_PHYS 0xc0000000
> #define CONFIG_SYS_RIO_MEM_SIZE 0x20000000 /* 512M */
>
> SET_LAW(CONFIG_SYS_RIO_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_RIO),
>
> -------------
>
> Here is the kernel log:
>
> Using SBC8548 machine description
> Memory CAM mapping: 256 Mb, residual: 0Mb
> Linux version 2.6.35.6 (dl704@lxws006) (gcc version 4.1.2 (Wind River
> Linux Sourcery G++ 4.1-91)) #7 We
> d Sep 29 13:27:18 CEST 2010
> bootconsole [udbg0] enabled
> setup_arch: bootmem
> sbc8548_setup_arch()
> arch: exit
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00010000
> Normal empty
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00010000
> MMU: Allocated 1088 bytes of context maps for 255 contexts
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
> Kernel command line: root=/dev/nfs rw nfsroot=192.168.100.21:/thales/target/rfs/sbc8548_wrlinux4
> ip=192
> .168.100.151:192.168.100.21:192.168.100.21:255.255.255.0:sbc8548_1:eth0:off
> console=ttyS0,115200 riohdid=1
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 256884k/262144k available (2712k kernel code, 5260k reserved, 112k
> data, 77k bss, 144k init)
> Kernel virtual memory layout:
> * 0xfffdf000..0xfffff000 : fixmap
> * 0xfc7f9000..0xfe000000 : early ioremap
> * 0xd1000000..0xfc7f9000 : vmalloc & ioremap
> Hierarchical RCU implementation.
> RCU-based detection of stalled CPUs is disabled.
> Verbose stalled-CPUs detection is disabled.
> NR_IRQS:512 nr_irqs:512
> mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs
> mpic: ISU size: 80, shift: 7, mask: 7f
> mpic: Initializing for 80 sources
> clocksource: timebase mult[50cede6] shift[22] registered
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> bio: create slab <bio-0> at 0
> vgaarb: loaded
> Switching to clocksource timebase
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> Setting up RapidIO peer-to-peer network /soc8548@e0000000/rapidio@c0000
> fsl-of-rio e00c0000.rapidio: Of-device full name /soc8548@e0000000
> /rapidio@c0000
> fsl-of-rio e00c0000.rapidio: Regs: [mem 0xe00c0000-0xe00dffff]
> fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size
> 0x0000000020000000.
> fsl-of-rio e00c0000.rapidio: pwirq: 48, bellirq: 50, txirq: 53, rxirq 54
> fsl-of-rio e00c0000.rapidio: DeviceID is 0x1
> fsl-of-rio e00c0000.rapidio: Configured as HOST
> fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial
> fsl-of-rio e00c0000.rapidio: Hardware port width: 4
> fsl-of-rio e00c0000.rapidio: Training connection status: Four-lane
> fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256
> RIO: enumerate master port 0, RIO0 mport
> fsl_rio_config_read: index 0 destid 255 hopcount 0 offset 00000068 len 4
> fsl_rio_config_read: Passed IS_ALIGNED.
> fsl_rio_config_read: Passed 'out_be32_1'
> fsl_rio_config_read: Passed 'out_be32_2'
> fsl_rio_config_read: len is 4
> fsl_rio_config_read: about to trigger '__fsl_read_rio_config'
>
> Regards,
> Bastiaan Nijkamp
>
[-- Attachment #2: Type: text/html, Size: 8642 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox