* Re: [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
From: Domen Puncer @ 2007-10-24 19:12 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20071024182308.21194.69416.stgit@trillian.cg.shawcable.net>
On 24/10/07 12:24 -0600, Grant Likely wrote:
> Domen,
>
> Here's a real solution to the problem. I've somewhat tested this on
> the lite5200b. Can you give it a spin on efika and see if SPI still
> works for you?
My test case was lite5200b too, I don't think I ever tried SPI on
efika.
(Are even the right pins on irda connector, or is a necessary line
missing?)
Domen
>
> Thanks,
> g.
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
--
Domen Puncer | Research & Development
.............................................................................................
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.............................................................................................
www.telargo.com
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Valentine Barshak @ 2007-10-24 19:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese, jeff, netdev
In-Reply-To: <1193196718.2085.35.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Tue, 2007-10-23 at 20:57 -0500, Valentine Barshak wrote:
>
>> +static int m88e1111_init(struct mii_phy *phy)
>> +{
>> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
>> + phy_write(phy, 0x14, 0x0ce3);
>> + phy_write(phy, 0x18, 0x4101);
>> + phy_write(phy, 0x09, 0x0e00);
>> + phy_write(phy, 0x04, 0x01e1);
>> + phy_write(phy, 0x00, 0x9140);
>> + phy_write(phy, 0x00, 0x1140);
>> +
>> + return 0;
>> +}
>
> Care to put a few comments on why the above is necessary and what it
> does ?
I think this set's up Marvell ext control (0x14) and led control (0x18)
registers with some default values, Also sets some bits in the
CTRL1000, ADVERTISE and basic mode control registers and resets the phy
for the changes to take effect. Unfortunately, I don't have a detailed
88E1111 description and can't tell anything about it. Looks like the
code was originally ported from u-boot and is needed to init the phy :)
Stefan, do you have any info on this?
Thanks,
Valentine.
>
> Thanks !
> Ben.
>
>> +static struct mii_phy_ops m88e1111_phy_ops = {
>> + .init = m88e1111_init,
>> + .setup_aneg = genmii_setup_aneg,
>> + .setup_forced = genmii_setup_forced,
>> + .poll_link = genmii_poll_link,
>> + .read_link = genmii_read_link
>> +};
>> +
>> +static struct mii_phy_def m88e1111_phy_def = {
>> +
>> + .phy_id = 0x01410CC0,
>> + .phy_id_mask = 0x0ffffff0,
>> + .name = "Marvell 88E1111 Ethernet",
>> + .ops = &m88e1111_phy_ops,
>> +};
>> +
>> static struct mii_phy_def *mii_phy_table[] = {
>> &cis8201_phy_def,
>> + &bcm5248_phy_def,
>> + &m88e1111_phy_def,
>> &genmii_phy_def,
>> NULL
>> };
>
^ permalink raw reply
* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 19:31 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F7D28.6050107@freescale.com>
On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > Calling it directly from the platform code is an option, but where
> > does the fabric driver code live? It doesn't make a lot of sense to
> > put ALSA code into arch/powerpc/platforms/52xx. I could make a
> > function call from arch/powerpc/platforms/52xx over to
> > sound/soc/powerpc but that's not very pretty.
>
> sound/soc/fsl is where the non-codec ASoC drivers for Freescale parts should go.
Why are you using a vendor named directory? I don't believe vendor
named directories are used anywhere in the kernel. The directories are
always named after the platform or architecture. Vendor directories
end up in a big mess if Freescale decides to sell a CPU to someone
else.
>
> > The codec drivers in asoc are completely agnostic. The same codec
> > driver works on x86, arm, powerpc, etc.
>
> Well, in theory at least. I never tried my cs4270 driver on anything but PowerPC.
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 19:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710241231h9427223kbfcc23be2e111194@mail.gmail.com>
Jon Smirl wrote:
> Why are you using a vendor named directory? I don't believe vendor
> named directories are used anywhere in the kernel. The directories are
> always named after the platform or architecture. Vendor directories
> end up in a big mess if Freescale decides to sell a CPU to someone
> else.
Two reasons:
1) The sound/soc directory already has names like "at91" and "pxa", so I thought
"fsl" is appropriate.
2) There may not be any directories named "fsl", but there are plenty of files
with that name:
./arch/powerpc/boot/fsl-soc.c
./arch/powerpc/boot/fsl-soc.h
./arch/powerpc/boot/fsl-soc.o
./arch/powerpc/mm/fsl_booke_mmu.c
./arch/powerpc/platforms/fsl_uli1575.c
./arch/powerpc/sysdev/fsl_pci.c
./arch/powerpc/sysdev/fsl_pci.h
./arch/powerpc/sysdev/fsl_soc.c
./arch/powerpc/sysdev/fsl_soc.h
./arch/powerpc/sysdev/fsl_soc.o
./arch/ppc/mm/fsl_booke_mmu.c
./drivers/usb/gadget/fsl_usb2_udc.c
./drivers/usb/gadget/fsl_usb2_udc.h
./include/linux/fsl_devices.h
./include/config/fsl
Having said all that, if you really think sound/soc/powerpc is better than
sound/soc/fsl, I won't complain.
^ permalink raw reply
* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 19:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F9FE5.7040808@freescale.com>
On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > Why are you using a vendor named directory? I don't believe vendor
> > named directories are used anywhere in the kernel. The directories are
> > always named after the platform or architecture. Vendor directories
> > end up in a big mess if Freescale decides to sell a CPU to someone
> > else.
>
> Two reasons:
>
> 1) The sound/soc directory already has names like "at91" and "pxa", so I thought
> "fsl" is appropriate.
pxa is the processor family. Intel sold the pxa cpus to Marvell six months ago.
>
> 2) There may not be any directories named "fsl", but there are plenty of files
> with that name:
>
> ./arch/powerpc/boot/fsl-soc.c
> ./arch/powerpc/boot/fsl-soc.h
> ./arch/powerpc/boot/fsl-soc.o
> ./arch/powerpc/mm/fsl_booke_mmu.c
> ./arch/powerpc/platforms/fsl_uli1575.c
> ./arch/powerpc/sysdev/fsl_pci.c
> ./arch/powerpc/sysdev/fsl_pci.h
> ./arch/powerpc/sysdev/fsl_soc.c
> ./arch/powerpc/sysdev/fsl_soc.h
> ./arch/powerpc/sysdev/fsl_soc.o
> ./arch/ppc/mm/fsl_booke_mmu.c
> ./drivers/usb/gadget/fsl_usb2_udc.c
> ./drivers/usb/gadget/fsl_usb2_udc.h
> ./include/linux/fsl_devices.h
> ./include/config/fsl
>
> Having said all that, if you really think sound/soc/powerpc is better than
> sound/soc/fsl, I won't complain.
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Apparent kernel bug with GDB on ppc405
From: Matt Mackall @ 2007-10-24 19:46 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: gdb
I'm trying to debug a trivial statically-linked hello world program on
a Xilinx PPC 405 and I'm seeing the following behavior:
With direct gdb on target, I can set a breakpoint at main, run, and
the breakpoint is triggered.
With gdbserver and gdb with "target remote localhost:1234", the above
still works.
With gdb on target redirected to a PC and tunneled back
to the target, everything still works.
With gdb on a PC, execution continues past the breakpoint. Comparing
the gdb protocol streams here and and on the previous (working) case
are identical up to the point of hitting the breakpoint (which never
happens in the latter case).
Raising the load on the PC to 4 and running gdb under nice -n 19 makes
things work again. So this begins to look like a kernel cache or
timing bug rather than a problem with the PC tool. It appears that the
breakpoint written to the executable at continue time is not visible
to the CPU at execute time.
My first suspicion was a dcache/icache coherency issue in
copy_to_user_page, so I added flush_dcache_icache_page(page) here to
no avail. On closer inspection, it looks like both icache and dcache
are already being flushed by flush_icache_user_range().
Adding printk(".") (or any printk) in this function here fixes things
(serial console at 115k), while printk("") and udelay(100) do not.
Which still suggests an icache bug..?
Any suggestions?
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
^ permalink raw reply
* problems to boot 2.6.23 kernel on XILINX ppc with 8Mbytes of RAM
From: manu @ 2007-10-24 20:01 UTC (permalink / raw)
To: Linuxppc-embedded
Hello,
I work on a custom board based on a virtex 2 pro FPGA and 8Mbytes of SDRAM.
Untill now I used a 2.4.31 linux ppc kernel with John Williams patches
and uclinux distribution and everything worked perfectly.
I've decided to move to the latest 2.6 version from kernel.org
(2.6.23.1) with an initramfs containing a busybox.
My complete zImage including the initramfs has a size of 900Kbytes.
I made some tests with a ML300 board and I managed to get a shell easily.
When I migrated to the custom board, I had the "Now booting the kernel"
message and then nothing.
When I trace the code running on the ppc with the debugger, execution
seems to be stuck in some early initialization code.
I managed to reproduce the problem on the ML300 using "mem=8m" parameter
on the bootline.
With "mem=16m" the kernel boots correctly.
I'm really surprised by the amount of RAM required to boot the kernel.
Is there a way to make it boot with only 8Mbytes of RAM ?
Thanks for your help.
Manu
^ permalink raw reply
* Re: New time code miscalculates cpu usage
From: Olof Johansson @ 2007-10-24 20:19 UTC (permalink / raw)
To: Tony Breeds; +Cc: paulus, linuxppc-dev
In-Reply-To: <20071017060747.GF9814@bakeyournoodle.com>
On Wed, Oct 17, 2007 at 04:07:48PM +1000, Tony Breeds wrote:
> On Tue, Oct 16, 2007 at 03:25:25PM -0500, Olof Johansson wrote:
> > Hi,
> >
> > Not sure when this started happening, but I wanted to report it. I'll
> > start bisecting in a day or two if noone else has gotten around to
> > looking at it:
> >
> > $ echo "int main(void) { while(1); }" > test.c ; gcc test.c
> > $ time ./a.out & sleep 2 ; killall a.out
> > real 0m2.008s
> > user 0m4.014s
> > sys 0m0.002s
> >
> > Seen on POWER5 and PA6T, haven't tried anything else yet.
>
> For what it's worth, this is my bug. I suspected it, and git bisect
> confirmed it.I have an ugly work around now, but hope to have something
> better out tomorrow.
Hi Tony,
Any news?
-Olof
^ permalink raw reply
* Re: [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
From: Grant Likely @ 2007-10-24 20:14 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-dev
In-Reply-To: <20071024191206.GD3369@nd47.coderock.org>
On 10/24/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 24/10/07 12:24 -0600, Grant Likely wrote:
> > Domen,
> >
> > Here's a real solution to the problem. I've somewhat tested this on
> > the lite5200b. Can you give it a spin on efika and see if SPI still
> > works for you?
>
> My test case was lite5200b too, I don't think I ever tried SPI on
> efika.
> (Are even the right pins on irda connector, or is a necessary line
> missing?)
Hmm, I guess that's right. Can you at least make sure it still boots
on Efika? Some of the clock detection stuff has changed so I want to
make sure it still boots.
Are you setup to do your SPI test easily on you lite5200b? When I say
"somewhat" tested; I mean I probed the driver and it didn't crash.
:-) I haven't tried to run traffic over it.
Can you check that on your system? If not, can you email me what
setup/programs you used for testing? I know very little about the SPI
infrastructure.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: New time code miscalculates cpu usage
From: Sergei Shtylyov @ 2007-10-24 20:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: paulus, linuxppc-dev
In-Reply-To: <20071016202525.GA11837@lixom.net>
Hello.
Olof Johansson wrote:
> Not sure when this started happening, but I wanted to report it. I'll
> start bisecting in a day or two if noone else has gotten around to
> looking at it:
> $ echo "int main(void) { while(1); }" > test.c ; gcc test.c
> $ time ./a.out & sleep 2 ; killall a.out
> real 0m2.008s
> user 0m4.014s
> sys 0m0.002s
>
> Seen on POWER5 and PA6T, haven't tried anything else yet.
I'm not surprised -- the kernel accounts twice for each tick.
WBR, Sergei
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 20:28 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024194640.GB19691@waste.org>
On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> I'm trying to debug a trivial statically-linked hello world program on
> a Xilinx PPC 405 and I'm seeing the following behavior:
>
<snip>
>
> Any suggestions?
http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
I was fighting with a similar problem almost 2 years ago. Looks like
it might be related. At some point the problem seemed to go away and
I determined what the root cause was. :-(
I haven't been using gdb lately, so I don't know if it's the same
problem. Nobody I had talked to had seen the issue on other 405
platforms. It could very well be something virtex-specific.
That's not much help, but maybe it will give you some clues.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Matt Mackall @ 2007-10-24 20:42 UTC (permalink / raw)
To: Grant Likely; +Cc: gdb, linuxppc-embedded
In-Reply-To: <fa686aa40710241328x77435cc1lf09cac730b0ce5ac@mail.gmail.com>
On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > I'm trying to debug a trivial statically-linked hello world program on
> > a Xilinx PPC 405 and I'm seeing the following behavior:
> >
> <snip>
> >
> > Any suggestions?
>
> http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
>
> I was fighting with a similar problem almost 2 years ago. Looks like
> it might be related. At some point the problem seemed to go away and
> I determined what the root cause was. :-(
>
> I haven't been using gdb lately, so I don't know if it's the same
> problem. Nobody I had talked to had seen the issue on other 405
> platforms. It could very well be something virtex-specific.
Could be the same problem, but I'm seeing only your symptom 3 so far.
I've tried throwing some larger hammers at the problem. Flushing all
of the dcache and icache (flush_dcache_all and
flush_instruction_cache) isn't helping. But printk(".") does!
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 20:46 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024204215.GC19691@waste.org>
On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > I'm trying to debug a trivial statically-linked hello world program on
> > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > >
> > <snip>
> > >
> > > Any suggestions?
> >
> > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> >
> > I was fighting with a similar problem almost 2 years ago. Looks like
> > it might be related. At some point the problem seemed to go away and
> > I determined what the root cause was. :-(
> >
> > I haven't been using gdb lately, so I don't know if it's the same
> > problem. Nobody I had talked to had seen the issue on other 405
> > platforms. It could very well be something virtex-specific.
>
> Could be the same problem, but I'm seeing only your symptom 3 so far.
>
> I've tried throwing some larger hammers at the problem. Flushing all
> of the dcache and icache (flush_dcache_all and
> flush_instruction_cache) isn't helping. But printk(".") does!
It's really true; printk *is* the most valuable tool kernel hackers
have for debugging.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
From: Domen Puncer @ 2007-10-24 20:54 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710241314w2dbe0863ja15746614cff0dd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
On 24/10/07 14:14 -0600, Grant Likely wrote:
> On 10/24/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > On 24/10/07 12:24 -0600, Grant Likely wrote:
> > > Domen,
> > >
> > > Here's a real solution to the problem. I've somewhat tested this on
> > > the lite5200b. Can you give it a spin on efika and see if SPI still
> > > works for you?
> >
> > My test case was lite5200b too, I don't think I ever tried SPI on
> > efika.
> > (Are even the right pins on irda connector, or is a necessary line
> > missing?)
>
> Hmm, I guess that's right. Can you at least make sure it still boots
> on Efika? Some of the clock detection stuff has changed so I want to
> make sure it still boots.
OK. I'll do that tomorrow.
>
> Are you setup to do your SPI test easily on you lite5200b? When I say
> "somewhat" tested; I mean I probed the driver and it didn't crash.
> :-) I haven't tried to run traffic over it.
Sorry, lite5200b is resting these days. :-(
>
> Can you check that on your system? If not, can you email me what
> setup/programs you used for testing? I know very little about the SPI
> infrastructure.
For userspace part I used something like: Documentation/spi/spidev
And for kernel the attached, to fill get binded to spidev driver.
Domen
>
> Thanks,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
--
Domen Puncer | Research & Development
.............................................................................................
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.............................................................................................
www.telargo.com
[-- Attachment #2: spidev_test_devices --]
[-- Type: text/plain, Size: 1502 bytes --]
---
drivers/spi/Makefile | 1 +
drivers/spi/spi_test_devices.c | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
Index: work-powerpc.git/drivers/spi/Makefile
===================================================================
--- work-powerpc.git.orig/drivers/spi/Makefile
+++ work-powerpc.git/drivers/spi/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_SPI_SPIDEV) += spidev.o
# SPI slave drivers (protocol for that link)
# ... add above this line ...
+obj-m += spi_test_devices.o
Index: work-powerpc.git/drivers/spi/spi_test_devices.c
===================================================================
--- /dev/null
+++ work-powerpc.git/drivers/spi/spi_test_devices.c
@@ -0,0 +1,38 @@
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/spi/spi.h>
+
+static struct spi_board_info spi_info[7];
+static struct spi_device *spidev[7];
+static int testdev_init(void)
+{
+ struct spi_board_info *info;
+ int i;
+
+ for (i=0; i<7; i++) {
+ struct spi_master *master;
+
+ info = &spi_info[i];
+ //info->max_speed_hz = 2*1000000;
+ info->max_speed_hz = 100000;
+ //info->max_speed_hz = 1*1000000;
+ strcpy(info->modalias, "spidev");
+
+ master = spi_busnum_to_master(i);
+ if (master)
+ spidev[i] = spi_new_device(master, info);
+ }
+ return 0;
+}
+
+static void testdev_exit(void)
+{
+ /* there is no _remove? */
+ /*for (i=0; i<7; i++) {
+ }*/
+}
+
+module_init(testdev_init);
+module_exit(testdev_exit);
+
+MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: David Daney @ 2007-10-24 20:34 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024194640.GB19691@waste.org>
Matt Mackall wrote:
> I'm trying to debug a trivial statically-linked hello world program on
> a Xilinx PPC 405 and I'm seeing the following behavior:
>
> With direct gdb on target, I can set a breakpoint at main, run, and
> the breakpoint is triggered.
>
> With gdbserver and gdb with "target remote localhost:1234", the above
> still works.
>
> With gdb on target redirected to a PC and tunneled back
> to the target, everything still works.
>
> With gdb on a PC, execution continues past the breakpoint. Comparing
> the gdb protocol streams here and and on the previous (working) case
> are identical up to the point of hitting the breakpoint (which never
> happens in the latter case).
>
> Raising the load on the PC to 4 and running gdb under nice -n 19 makes
> things work again. So this begins to look like a kernel cache or
> timing bug rather than a problem with the PC tool. It appears that the
> breakpoint written to the executable at continue time is not visible
> to the CPU at execute time.
>
> My first suspicion was a dcache/icache coherency issue in
> copy_to_user_page, so I added flush_dcache_icache_page(page) here to
> no avail. On closer inspection, it looks like both icache and dcache
> are already being flushed by flush_icache_user_range().
>
First of all I have never used a similar configuration so this may be
totally off base. But...
If the icache is virtually indexed, then I think there are only two ways
to invalidate it. The first is from the context of the debugged process
where the page is mapped at the location the target program will see it.
If you try to invalidate from the context of the debugger, the page
will most likely not be mapped at the virtual address of the target
program so you might have to invalidate the *entire* icache.
David Daney
^ permalink raw reply
* i2c-mpc.c driver issues
From: Tjernlund @ 2007-10-24 21:06 UTC (permalink / raw)
To: i2c; +Cc: linuxppc-dev
While browsing the i2c-mpc.c driver I noticed some things that look odd
to me so I figured I report them. Could not find a maintainer in the MAINTANERS file
so I sent here, cc:ed linuxppc-dev as well.
1) There are a lot of return -1 error code that is propagated back to
userspace. Should be changed to proper -Exxx codes.
2) mpc_read(), according to the comment below it sends a STOP condition here but
this function does not known if this is the last read or not. mpc_xfer is
the one that knows when the transaction is over and should send the stop, which it already
does.
/* Generate stop on last byte */
if (i == length - 1)
writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_TXAK);
Jocke
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Matt Mackall @ 2007-10-24 21:54 UTC (permalink / raw)
To: Grant Likely; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024204215.GC19691@waste.org>
On Wed, Oct 24, 2007 at 03:42:16PM -0500, Matt Mackall wrote:
> On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > I'm trying to debug a trivial statically-linked hello world program on
> > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > >
> > <snip>
> > >
> > > Any suggestions?
> >
> > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> >
> > I was fighting with a similar problem almost 2 years ago. Looks like
> > it might be related. At some point the problem seemed to go away and
> > I determined what the root cause was. :-(
> >
> > I haven't been using gdb lately, so I don't know if it's the same
> > problem. Nobody I had talked to had seen the issue on other 405
> > platforms. It could very well be something virtex-specific.
>
> Could be the same problem, but I'm seeing only your symptom 3 so far.
>
> I've tried throwing some larger hammers at the problem. Flushing all
> of the dcache and icache (flush_dcache_all and
> flush_instruction_cache) isn't helping. But printk(".") does!
Well there was one remaining cache - the TLB. This patch seems to make
things work, but don't ask me why:
--- include/asm-ppc/cacheflush.h (revision 10439)
+++ include/asm-ppc/cacheflush.h (working copy)
@@ -11,6 +11,7 @@
#define _PPC_CACHEFLUSH_H
#include <linux/mm.h>
+#include <asm/tlbflush.h>
/*
* No cache flushing is required when address mappings are
@@ -35,10 +36,23 @@
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr, int len);
#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
do { memcpy(dst, src, len); \
flush_icache_user_range(vma, page, vaddr, len); \
+ _tlbia(); \
} while (0)
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: New time code miscalculates cpu usage
From: Benjamin Herrenschmidt @ 2007-10-24 21:56 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <471FA875.6080602@ru.mvista.com>
On Thu, 2007-10-25 at 00:17 +0400, Sergei Shtylyov wrote:
> Hello.
>
> Olof Johansson wrote:
>
> > Not sure when this started happening, but I wanted to report it. I'll
> > start bisecting in a day or two if noone else has gotten around to
> > looking at it:
>
> > $ echo "int main(void) { while(1); }" > test.c ; gcc test.c
> > $ time ./a.out & sleep 2 ; killall a.out
> > real 0m2.008s
> > user 0m4.014s
> > sys 0m0.002s
> >
> > Seen on POWER5 and PA6T, haven't tried anything else yet.
>
> I'm not surprised -- the kernel accounts twice for each tick.
Your input would be much more valuable if you actually pointed out where
that happens and why since you seem to know it.
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Matt Sealey @ 2007-10-24 22:05 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, tnt, linux-usb-devel
In-Reply-To: <20071024163412.GA17785@ru.mvista.com>
Valentine Barshak wrote:
> Rework ohci-ppc-of driver to use big-endian property instead of
> ohci-be/ohci-le compatible strings. Also remove unnecessary
> user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
> USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
> and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
[snip]
>
> config USB_UHCI_HCD
> diff -pruN linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c linux-2.6/drivers/usb/host/ohci-ppc-of.c
> --- linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c 2007-10-24 18:44:25.000000000 +0400
> +++ linux-2.6/drivers/usb/host/ohci-ppc-of.c 2007-10-24 19:32:21.000000000 +0400
> @@ -15,8 +15,8 @@
>
> #include <linux/signal.h>
>
> -#include <asm/of_platform.h>
> -#include <asm/prom.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
>
>
> static int __devinit
> @@ -91,15 +91,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
> int irq;
>
> int rv;
> - int is_bigendian;
>
> if (usb_disabled())
> return -ENODEV;
>
> - is_bigendian =
> - of_device_is_compatible(dn, "ohci-bigendian") ||
> - of_device_is_compatible(dn, "ohci-be");
> -
> dev_dbg(&op->dev, "initializing PPC-OF USB Controller\n");
>
> rv = of_address_to_resource(dn, 0, &res);
> @@ -134,9 +129,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
> }
>
> ohci = hcd_to_ohci(hcd);
> - if (is_bigendian) {
> +
> + if (of_get_property(dn, "big-endian", NULL)) {
> ohci->flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
> - if (of_device_is_compatible(dn, "mpc5200-ohci"))
> + if (of_device_is_compatible(dn, "mpc5200-usb-ohci"))
> ohci->flags |= OHCI_QUIRK_FRAME_NO;
> }
Just a note, this is a fairly destructive change and will stop the Efika
from having it's USB ports detected.
I've updated the Efika Device Tree Supplement script internally, but I
would really rather not have users be forced to update their kernel and
firmware quite so often just for what is, here, a merely aesthetic
change.
Can we just make sure real quickly that the changing of compatibles
doesn't break existing, not-easily-flashable firmwares?
At least work in 'mpc5200-ohci' for the endian check (it's always big
endian, but our device tree has no big-endian property by default and
does not contain mpc5200-usb-ohci or usb-ohci properties) otherwise we are
going to have users complain. To you guys.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 22:27 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024215421.GF19691@waste.org>
On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> On Wed, Oct 24, 2007 at 03:42:16PM -0500, Matt Mackall wrote:
> > On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > > I'm trying to debug a trivial statically-linked hello world program on
> > > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > > >
> > > <snip>
> > > >
> > > > Any suggestions?
> > >
> > > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> > >
> > > I was fighting with a similar problem almost 2 years ago. Looks like
> > > it might be related. At some point the problem seemed to go away and
> > > I determined what the root cause was. :-(
> > >
> > > I haven't been using gdb lately, so I don't know if it's the same
> > > problem. Nobody I had talked to had seen the issue on other 405
> > > platforms. It could very well be something virtex-specific.
> >
> > Could be the same problem, but I'm seeing only your symptom 3 so far.
> >
> > I've tried throwing some larger hammers at the problem. Flushing all
> > of the dcache and icache (flush_dcache_all and
> > flush_instruction_cache) isn't helping. But printk(".") does!
>
> Well there was one remaining cache - the TLB. This patch seems to make
> things work, but don't ask me why:
>
> --- include/asm-ppc/cacheflush.h (revision 10439)
> +++ include/asm-ppc/cacheflush.h (working copy)
> @@ -11,6 +11,7 @@
> #define _PPC_CACHEFLUSH_H
>
> #include <linux/mm.h>
> +#include <asm/tlbflush.h>
>
> /*
> * No cache flushing is required when address mappings are
> @@ -35,10 +36,23 @@
> extern void flush_icache_user_range(struct vm_area_struct *vma,
> struct page *page, unsigned long addr, int len);
>
> #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> do { memcpy(dst, src, len); \
> flush_icache_user_range(vma, page, vaddr, len); \
> + _tlbia(); \
> } while (0)
Hmmm; thinking out loud here...
- so tlbia invalidates all TLB entries
- When gdb inserts a breakpoint the .text pages are marked as read
only, so the kernel does a copy on write so that gdb can modify the
instruction. The kernel also updates the page tables so that the test
process now uses the new page.
- This means that there are now 2 pages for that one section of
executable code; the original and the one with the breakpoint.
- However, the program is still in memory, and there is probably
already a TLB entry pointing to the original page for that range of
addresses.
Could it be that the kernel page tables are getting updated to the new
page; but active set of TLB entries is not getting updated?
If so, then printk(".") probably solves the problem simply because it
touches enough pages in its execution path that the old TLB entry gets
overwritten? There are only 64 TLB entries afterall.
Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Matt Mackall @ 2007-10-24 22:32 UTC (permalink / raw)
To: Grant Likely; +Cc: gdb, linuxppc-embedded
In-Reply-To: <fa686aa40710241527j1a316760lf36d512eb625810f@mail.gmail.com>
On Wed, Oct 24, 2007 at 04:27:52PM -0600, Grant Likely wrote:
> On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > On Wed, Oct 24, 2007 at 03:42:16PM -0500, Matt Mackall wrote:
> > > On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > > > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > > > I'm trying to debug a trivial statically-linked hello world program on
> > > > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > > > >
> > > > <snip>
> > > > >
> > > > > Any suggestions?
> > > >
> > > > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> > > >
> > > > I was fighting with a similar problem almost 2 years ago. Looks like
> > > > it might be related. At some point the problem seemed to go away and
> > > > I determined what the root cause was. :-(
> > > >
> > > > I haven't been using gdb lately, so I don't know if it's the same
> > > > problem. Nobody I had talked to had seen the issue on other 405
> > > > platforms. It could very well be something virtex-specific.
> > >
> > > Could be the same problem, but I'm seeing only your symptom 3 so far.
> > >
> > > I've tried throwing some larger hammers at the problem. Flushing all
> > > of the dcache and icache (flush_dcache_all and
> > > flush_instruction_cache) isn't helping. But printk(".") does!
> >
> > Well there was one remaining cache - the TLB. This patch seems to make
> > things work, but don't ask me why:
> >
> > --- include/asm-ppc/cacheflush.h (revision 10439)
> > +++ include/asm-ppc/cacheflush.h (working copy)
> > @@ -11,6 +11,7 @@
> > #define _PPC_CACHEFLUSH_H
> >
> > #include <linux/mm.h>
> > +#include <asm/tlbflush.h>
> >
> > /*
> > * No cache flushing is required when address mappings are
> > @@ -35,10 +36,23 @@
> > extern void flush_icache_user_range(struct vm_area_struct *vma,
> > struct page *page, unsigned long addr, int len);
> >
> > #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> > do { memcpy(dst, src, len); \
> > flush_icache_user_range(vma, page, vaddr, len); \
> > + _tlbia(); \
> > } while (0)
>
> Hmmm; thinking out loud here...
>
> - so tlbia invalidates all TLB entries
> - When gdb inserts a breakpoint the .text pages are marked as read
> only, so the kernel does a copy on write so that gdb can modify the
> instruction. The kernel also updates the page tables so that the test
> process now uses the new page.
> - This means that there are now 2 pages for that one section of
> executable code; the original and the one with the breakpoint.
> - However, the program is still in memory, and there is probably
> already a TLB entry pointing to the original page for that range of
> addresses.
>
> Could it be that the kernel page tables are getting updated to the new
> page; but active set of TLB entries is not getting updated?
>
> If so, then printk(".") probably solves the problem simply because it
> touches enough pages in its execution path that the old TLB entry gets
> overwritten? There are only 64 TLB entries afterall.
>
> Thoughts?
Not completely implausible, but a) why isn't this seen on basically
every machine with software TLB? b) why does -local- GDB, which is
presumably doing much less work than gdbserver + network stack, not fail?
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 22:39 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024223250.GI19691@waste.org>
On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> On Wed, Oct 24, 2007 at 04:27:52PM -0600, Grant Likely wrote:
> > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > On Wed, Oct 24, 2007 at 03:42:16PM -0500, Matt Mackall wrote:
> > > > On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > > > > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > > > > I'm trying to debug a trivial statically-linked hello world program on
> > > > > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > > > > >
> > > > > <snip>
> > > > > >
> > > > > > Any suggestions?
> > > > >
> > > > > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> > > > >
> > > > > I was fighting with a similar problem almost 2 years ago. Looks like
> > > > > it might be related. At some point the problem seemed to go away and
> > > > > I determined what the root cause was. :-(
> > > > >
> > > > > I haven't been using gdb lately, so I don't know if it's the same
> > > > > problem. Nobody I had talked to had seen the issue on other 405
> > > > > platforms. It could very well be something virtex-specific.
> > > >
> > > > Could be the same problem, but I'm seeing only your symptom 3 so far.
> > > >
> > > > I've tried throwing some larger hammers at the problem. Flushing all
> > > > of the dcache and icache (flush_dcache_all and
> > > > flush_instruction_cache) isn't helping. But printk(".") does!
> > >
> > > Well there was one remaining cache - the TLB. This patch seems to make
> > > things work, but don't ask me why:
> > >
> > > --- include/asm-ppc/cacheflush.h (revision 10439)
> > > +++ include/asm-ppc/cacheflush.h (working copy)
> > > @@ -11,6 +11,7 @@
> > > #define _PPC_CACHEFLUSH_H
> > >
> > > #include <linux/mm.h>
> > > +#include <asm/tlbflush.h>
> > >
> > > /*
> > > * No cache flushing is required when address mappings are
> > > @@ -35,10 +36,23 @@
> > > extern void flush_icache_user_range(struct vm_area_struct *vma,
> > > struct page *page, unsigned long addr, int len);
> > >
> > > #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> > > do { memcpy(dst, src, len); \
> > > flush_icache_user_range(vma, page, vaddr, len); \
> > > + _tlbia(); \
> > > } while (0)
> >
> > Hmmm; thinking out loud here...
> >
> > - so tlbia invalidates all TLB entries
> > - When gdb inserts a breakpoint the .text pages are marked as read
> > only, so the kernel does a copy on write so that gdb can modify the
> > instruction. The kernel also updates the page tables so that the test
> > process now uses the new page.
> > - This means that there are now 2 pages for that one section of
> > executable code; the original and the one with the breakpoint.
> > - However, the program is still in memory, and there is probably
> > already a TLB entry pointing to the original page for that range of
> > addresses.
> >
> > Could it be that the kernel page tables are getting updated to the new
> > page; but active set of TLB entries is not getting updated?
> >
> > If so, then printk(".") probably solves the problem simply because it
> > touches enough pages in its execution path that the old TLB entry gets
> > overwritten? There are only 64 TLB entries afterall.
> >
> > Thoughts?
>
> Not completely implausible, but a) why isn't this seen on basically
> every machine with software TLB? b) why does -local- GDB, which is
> presumably doing much less work than gdbserver + network stack, not fail?
a) I don't know.... very odd.
b) gdb is big. It probably touches far more pages (via library calls)
than gdbserver. The network stack is also big, but it's probably more
localized too.
Niceing down the host also makes sense because if the PC is being slow
then the target may go off and run other things while between setting
the breakpoint and getting the 'go' command.
Can you grab a snapshot of the TLB before and after setting the breakpoint?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 22:40 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <fa686aa40710241539r792380dam62ea820a48dab62e@mail.gmail.com>
On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > Not completely implausible, but a) why isn't this seen on basically
> > every machine with software TLB? b) why does -local- GDB, which is
> > presumably doing much less work than gdbserver + network stack, not fail?
>
> a) I don't know.... very odd.
>
> b) gdb is big. It probably touches far more pages (via library calls)
> than gdbserver. The network stack is also big, but it's probably more
> localized too.
>
> Niceing down the host also makes sense because if the PC is being slow
> then the target may go off and run other things while between setting
> the breakpoint and getting the 'go' command.
>
> Can you grab a snapshot of the TLB before and after setting the breakpoint?
Or; probably more relevant, before and after the page copy?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: i2c-mpc.c driver issues
From: Jon Smirl @ 2007-10-24 22:44 UTC (permalink / raw)
To: Tjernlund; +Cc: linuxppc-dev, i2c
In-Reply-To: <019001c81681$b5d449c0$5267a8c0@Jocke>
On 10/24/07, Tjernlund <tjernlund@tjernlund.se> wrote:
> While browsing the i2c-mpc.c driver I noticed some things that look odd
> to me so I figured I report them. Could not find a maintainer in the MAINTANERS file
> so I sent here, cc:ed linuxppc-dev as well.
There appear to be more issues with this driver. It is still
registering as platform driver instead of a of_platform driver.
On the mpc5200 the probe function for platform drivers is not getting
called, so fsl_i2c_probe never gets called. It's not clear to me that
this driver is functioning on the mpc5200.
> 1) There are a lot of return -1 error code that is propagated back to
> userspace. Should be changed to proper -Exxx codes.
>
> 2) mpc_read(), according to the comment below it sends a STOP condition here but
> this function does not known if this is the last read or not. mpc_xfer is
> the one that knows when the transaction is over and should send the stop, which it already
> does.
>
> /* Generate stop on last byte */
> if (i == length - 1)
> writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_TXAK);
>
> Jocke
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Daniel Jacobowitz @ 2007-10-24 22:41 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024223250.GI19691@waste.org>
On Wed, Oct 24, 2007 at 05:32:50PM -0500, Matt Mackall wrote:
> Not completely implausible, but a) why isn't this seen on basically
> every machine with software TLB? b) why does -local- GDB, which is
> presumably doing much less work than gdbserver + network stack, not fail?
You said it yourself. Local gdb does more work -> blows through more
TLB entries.
I can't answer you about the other half, but I'm pretty sure TLB
invalidation is already supposed to be happening... somewhere.
--
Daniel Jacobowitz
CodeSourcery
^ 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