Machine check in 4xx ethernet driver
Hi, I'm getting machine check exception when trying to dump emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7 The problem seems not new, I can reproduce it on 2.6.25 Denx kernel -bash-3.2# ethtool -d eth0 Data machine check in kernel mode. Oops: Machine check, sig: 7 [#1] Kilauea Modules linked in: NIP: c000e240 LR: c0158358 CTR: 0004 REGS: cfffdf50 TRAP: 0202 Not tainted (2.6.29-rc7) MSR: 00029030 CR: 22002044 XER: 205f TASK = cfa79740[1011] 'ethtool' THREAD: cfa82000 GPR00: 0001 cfa83d10 cfa79740 cf8d7a34 d105696c 0004 cfa83d40 GPR08: 001b 0004 0004 22002022 1005f4d0 1001 1000d9c4 GPR16: 1000d9bc 1000d9b4 1000fbec 10057650 100118a4 1001 1000da10 100570ec GPR24: bf90f790 cfa83d38 cf8d7800 10058008 cf8d7800 cf8d79c0 cf811360 NIP [c000e240] _memcpy_fromio+0x9c/0xc4 LR [c0158358] emac_ethtool_get_regs+0x68/0xc4 Call Trace: [cfa83d10] [c015831c] emac_ethtool_get_regs+0x2c/0xc4 (unreliable) [cfa83d30] [c017ed00] ethtool_get_regs+0xf8/0x1f8 [cfa83d60] [c018036c] dev_ethtool+0x10f4/0x13ac [cfa83df0] [c017d7dc] dev_ioctl+0x430/0x700 [cfa83e70] [c016ad80] sock_ioctl+0x80/0x2ec [cfa83e90] [c0088104] vfs_ioctl+0x34/0x98 [cfa83ea0] [c0088550] do_vfs_ioctl+0x3c0/0x734 [cfa83f10] [c0088904] sys_ioctl+0x40/0x74 [cfa83f40] [c000eb60] ret_from_syscall+0x0/0x3c Instruction dump: 419c004c 8004 9003 7c0006ac 38840004 38630004 38a5fffc 4200ffe8 2f05 41baffb4 7ca903a6 8804 <9803> 7c0006ac 38840001 38630001 ---[ end trace 075752cbf5bce2a1 ]--- Bus error Felix. -- View this message in context: http://www.nabble.com/Machine-check-in-4xx-ethernet-driver-tp22408005p22408005.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
Juergen, I don't understand how this would work, Now I do one byte-swap, which works. -I byteswap in software, for 16-bit cycles by byte swapping and for 8 bit cycles by adding an offset of 1. (The byte swapping on the chipselect is off) Your advice includes two byteswaps, one by re-routing the data bus and one by enabling the byte swap on the chip-select. Or does one of them not really swap bytes? Henk On Sat, Mar 7, 2009 at 11:09 AM, Juergen Beisert wrote: > Henk, > > On Freitag, 20. Februar 2009, Henk Stegeman wrote: >> - Any suggestions to what could be wrong here? Or does the MPC5200 in >> this case only byte swap u16 reads, but a u8 read is unchanged? > > You should not follow the Freescale bus signal names when you connect your > external little endian device. Otherwise the offsets are always wrong. > > Do it in this way instead: > > MPC LE Device > D[0..7] <-> D[24..31] > D[8..15] <-> D[16..23] > D[16..23] <-> D[8..15] > D[24..31] <-> D[0..7] > > If you connect your device in such a way, just enable CS's byte swap feature > depending on your bus size and you are done (no additional software > manipulation required). Now you can write bytes, words or longs and you will > always write the correct data into the corresponding device register. > > Hope it helps > Juergen > > -- > Pengutronix e.K. | Juergen Beisert | > Linux Solutions for Science and Industry | Phone: +49-8766-939 228 | > Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917- | > Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ | > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc/usb: Fix 440EPx USBH_3 & USBH_5 EHCI errata
> Please provide a valid email address here. New email client helpfully stripped out the address... >> called in a context where you can't iomap ? (ie with a spinlock held). That is indeed the case. Keeping ehci generic is a valid point, but because of the above I don't think adding a "hook" is going to work. I'll take a look at the *platform_private option and re-post - this would also allow for better runtime checking, as you suggested. Cheers Jan -- > On Fri, 2009-03-06 at 11:30 +, - Reyneke wrote: >> Patch applies to 440EPx devices in USB EHCI host mode (USB 2.0). >> >>>From the 440EPx errata: >> >> USBH_3: Host hangs after underrun or overrun occurs >> USBH_5: EHCI0_INSNREGxx registers are reset by a Soft or Light Host >> Controller Reset >> >> Workround for USBH_3 is to enable Break Memory Transfer (BMT) in INSNREG3. >> But the controller is reset after this fix is applied, and thus the current >> workround is lost. The following short patch ensures INSNREG3 is correctly >> set after reset. > >> Signed-off-by: Jan Reyneke > > Please provide a valid email address here. > >> --- > > A few issues here. First, it would be preferable to have this in the > ehci-ppc-of.c file. If you can't stick that in such a place that it will > be called after ehci_reset, then maybe you can add a reset "hook" so > that ehci-ppc-of.c gets to wrap the real ehci_reset(). > > Also, while the ifdef CONFIG_440EPX is good to prevent building the code > on machines that don't need it, it's also not enough. We allow building > kernels that support multiple boards and SoC's within the same major CPU > family and thus you -also- need runtime detection. Either using a quirk > (I think the USB drivers have quirk flags) or just always doing the > of_device_is_compatible() thingy which is yet another reason for finding > a way to move that up into ehci-ppc-of.c > > That would also avoid some duplication... > > > So if you manage to move the quirk here, you can thus re-use the > existing code, or is the reset always called in a context where you > can't iomap ? (ie with a spinlock held). > > In any case, I don't like adding a specific field to the generic ehci > structure like that. If that's what it takes, add a void > *platform_private to it, and use -that- to stick a host specific data > structure, but for something not performance sensitive such as a reset, > if you can get away with always mapping/unmapping, it's probably better. > > Cheers, > Ben. > > _ View your Twitter and Flickr updates from one place – Learn more! http://clk.atdmt.com/UKM/go/137984870/direct/01/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Machine check in 4xx ethernet driver
On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote: > >Hi, > >I'm getting machine check exception when trying to dump >emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7 >The problem seems not new, I can reproduce it on 2.6.25 Denx kernel I've not looked at what that code path does, but the EMAC regs are in DCR space, not MMIO. Using memcpy_fromio there seems odd. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Fri, 6 Mar 2009, Jens Axboe wrote:
> On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > But then I noticed ps3vram_make_request() may be called
> > > > > > concurrently,
> > > > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > > > driver down, and in the end, the version with a thread turns out to
> > > > > > be
> > > > > > ca. 1% faster. The version without a thread is about 50 lines less
> > > > > > code, though.
> > > > >
> > > > > That is correct, ->make_request_fn may get reentered. I'm not
> > > > > surprised
> > > > > that performance dropped if you just shoved everything under a mutex.
> > > > > You could be a little more smart and queue concurrent bio's for
> > > > > processing when the current one is complete though, there are several
> > > > > approaches there that be a lot faster than going all the way through
> > > > > the
> > > > > IO stack and scheduler just to avoid concurrency.
> > > >
> > > > Yes, using a spinlock and queueing requests on a list if the driver is
> > > > busy can be done after 2.6.29...
> > >
> > > Certainly. Even just replacing your current mutex with a spinlock during
> > > the memcpy() would surely be a lot faster. Or even just grabbing the
> > > mutex before calling into the write for the duration of the bio. The way
> > > you do it is certain context switch death :-)
> >
> > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> > I cannot use a spinlock.
>
> Ah right, I hadn't looked close enough. But putting the mutex_lock()
> outside of the bio_for_each_segment() is going to be much faster than
> getting/releasing it for each segment.
It doesn't seem to make any measurable difference, so I'm gonna leave it for
now.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> On Fri, 6 Mar 2009, Jens Axboe wrote:
> > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > > But then I noticed ps3vram_make_request() may be called
> > > > > > > concurrently,
> > > > > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > > > > driver down, and in the end, the version with a thread turns out
> > > > > > > to be
> > > > > > > ca. 1% faster. The version without a thread is about 50 lines less
> > > > > > > code, though.
> > > > > >
> > > > > > That is correct, ->make_request_fn may get reentered. I'm not
> > > > > > surprised
> > > > > > that performance dropped if you just shoved everything under a
> > > > > > mutex.
> > > > > > You could be a little more smart and queue concurrent bio's for
> > > > > > processing when the current one is complete though, there are
> > > > > > several
> > > > > > approaches there that be a lot faster than going all the way
> > > > > > through the
> > > > > > IO stack and scheduler just to avoid concurrency.
> > > > >
> > > > > Yes, using a spinlock and queueing requests on a list if the driver is
> > > > > busy can be done after 2.6.29...
> > > >
> > > > Certainly. Even just replacing your current mutex with a spinlock during
> > > > the memcpy() would surely be a lot faster. Or even just grabbing the
> > > > mutex before calling into the write for the duration of the bio. The way
> > > > you do it is certain context switch death :-)
> > >
> > > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> > > I cannot use a spinlock.
> >
> > Ah right, I hadn't looked close enough. But putting the mutex_lock()
> > outside of the bio_for_each_segment() is going to be much faster than
> > getting/releasing it for each segment.
>
> It doesn't seem to make any measurable difference, so I'm gonna leave it for
> now.
It will depend on where the bio's are coming from. If they are all
single segment, then there will be no difference. If they contain
multiple segments, you reduce the lock/release by that amount.
But yeah, just leave it as-is for now. You can send a final patch for
inclusion though. Unless I'm mistaken, I only saw the original and then
an incremental patch for changing it to ->make_request_fn?
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Mon, Mar 09 2009, Jens Axboe wrote:
> On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > > > But then I noticed ps3vram_make_request() may be called
> > > > > > > > concurrently,
> > > > > > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > > > > > driver down, and in the end, the version with a thread turns
> > > > > > > > out to be
> > > > > > > > ca. 1% faster. The version without a thread is about 50 lines
> > > > > > > > less
> > > > > > > > code, though.
> > > > > > >
> > > > > > > That is correct, ->make_request_fn may get reentered. I'm not
> > > > > > > surprised
> > > > > > > that performance dropped if you just shoved everything under a
> > > > > > > mutex.
> > > > > > > You could be a little more smart and queue concurrent bio's for
> > > > > > > processing when the current one is complete though, there are
> > > > > > > several
> > > > > > > approaches there that be a lot faster than going all the way
> > > > > > > through the
> > > > > > > IO stack and scheduler just to avoid concurrency.
> > > > > >
> > > > > > Yes, using a spinlock and queueing requests on a list if the driver
> > > > > > is
> > > > > > busy can be done after 2.6.29...
> > > > >
> > > > > Certainly. Even just replacing your current mutex with a spinlock
> > > > > during
> > > > > the memcpy() would surely be a lot faster. Or even just grabbing the
> > > > > mutex before calling into the write for the duration of the bio. The
> > > > > way
> > > > > you do it is certain context switch death :-)
> > > >
> > > > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> > > > I cannot use a spinlock.
> > >
> > > Ah right, I hadn't looked close enough. But putting the mutex_lock()
> > > outside of the bio_for_each_segment() is going to be much faster than
> > > getting/releasing it for each segment.
> >
> > It doesn't seem to make any measurable difference, so I'm gonna leave it for
> > now.
>
> It will depend on where the bio's are coming from. If they are all
> single segment, then there will be no difference. If they contain
> multiple segments, you reduce the lock/release by that amount.
>
> But yeah, just leave it as-is for now. You can send a final patch for
> inclusion though. Unless I'm mistaken, I only saw the original and then
> an incremental patch for changing it to ->make_request_fn?
There was a full version, my mistake. I got confused by the removal of
the old driver in another directory :-)
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Mon, 9 Mar 2009, Jens Axboe wrote:
> On Mon, Mar 09 2009, Jens Axboe wrote:
> > On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > > > > But then I noticed ps3vram_make_request() may be called
> > > > > > > > > concurrently,
> > > > > > > > > so I had to add a mutex to avoid data corruption. This slows
> > > > > > > > > the
> > > > > > > > > driver down, and in the end, the version with a thread turns
> > > > > > > > > out to be
> > > > > > > > > ca. 1% faster. The version without a thread is about 50 lines
> > > > > > > > > less
> > > > > > > > > code, though.
> > > > > > > >
> > > > > > > > That is correct, ->make_request_fn may get reentered. I'm not
> > > > > > > > surprised
> > > > > > > > that performance dropped if you just shoved everything under a
> > > > > > > > mutex.
> > > > > > > > You could be a little more smart and queue concurrent bio's for
> > > > > > > > processing when the current one is complete though, there are
> > > > > > > > several
> > > > > > > > approaches there that be a lot faster than going all the way
> > > > > > > > through the
> > > > > > > > IO stack and scheduler just to avoid concurrency.
> > > > > > >
> > > > > > > Yes, using a spinlock and queueing requests on a list if the
> > > > > > > driver is
> > > > > > > busy can be done after 2.6.29...
> > > > > >
> > > > > > Certainly. Even just replacing your current mutex with a spinlock
> > > > > > during
> > > > > > the memcpy() would surely be a lot faster. Or even just grabbing the
> > > > > > mutex before calling into the write for the duration of the bio.
> > > > > > The way
> > > > > > you do it is certain context switch death :-)
> > > > >
> > > > > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> > > > > I cannot use a spinlock.
> > > >
> > > > Ah right, I hadn't looked close enough. But putting the mutex_lock()
> > > > outside of the bio_for_each_segment() is going to be much faster than
> > > > getting/releasing it for each segment.
> > >
> > > It doesn't seem to make any measurable difference, so I'm gonna leave it
> > > for
> > > now.
> >
> > It will depend on where the bio's are coming from. If they are all
> > single segment, then there will be no difference. If they contain
> > multiple segments, you reduce the lock/release by that amount.
> >
> > But yeah, just leave it as-is for now. You can send a final patch for
> > inclusion though. Unless I'm mistaken, I only saw the original and then
> > an incremental patch for changing it to ->make_request_fn?
>
> There was a full version, my mistake. I got confused by the removal of
Indeed.
> the old driver in another directory :-)
Can you please ack it? Thx!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Machine check in 4xx ethernet driver
Josh Boyer-4 wrote: > > On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote: >> >>Hi, >> >>I'm getting machine check exception when trying to dump >>emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7 >>The problem seems not new, I can reproduce it on 2.6.25 Denx kernel > > I've not looked at what that code path does, but the EMAC regs are > in DCR space, not MMIO. Using memcpy_fromio there seems odd. > > At least on 405EX MAL registers are in DCR space, but EMAC and RGMII ones are in MMIO space. -- View this message in context: http://www.nabble.com/Machine-check-in-4xx-ethernet-driver-tp22408005p22410889.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> On Mon, 9 Mar 2009, Jens Axboe wrote:
> > On Mon, Mar 09 2009, Jens Axboe wrote:
> > > On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > > > > > But then I noticed ps3vram_make_request() may be called
> > > > > > > > > > concurrently,
> > > > > > > > > > so I had to add a mutex to avoid data corruption. This
> > > > > > > > > > slows the
> > > > > > > > > > driver down, and in the end, the version with a thread
> > > > > > > > > > turns out to be
> > > > > > > > > > ca. 1% faster. The version without a thread is about 50
> > > > > > > > > > lines less
> > > > > > > > > > code, though.
> > > > > > > > >
> > > > > > > > > That is correct, ->make_request_fn may get reentered. I'm not
> > > > > > > > > surprised
> > > > > > > > > that performance dropped if you just shoved everything under
> > > > > > > > > a mutex.
> > > > > > > > > You could be a little more smart and queue concurrent bio's
> > > > > > > > > for
> > > > > > > > > processing when the current one is complete though, there are
> > > > > > > > > several
> > > > > > > > > approaches there that be a lot faster than going all the way
> > > > > > > > > through the
> > > > > > > > > IO stack and scheduler just to avoid concurrency.
> > > > > > > >
> > > > > > > > Yes, using a spinlock and queueing requests on a list if the
> > > > > > > > driver is
> > > > > > > > busy can be done after 2.6.29...
> > > > > > >
> > > > > > > Certainly. Even just replacing your current mutex with a spinlock
> > > > > > > during
> > > > > > > the memcpy() would surely be a lot faster. Or even just grabbing
> > > > > > > the
> > > > > > > mutex before calling into the write for the duration of the bio.
> > > > > > > The way
> > > > > > > you do it is certain context switch death :-)
> > > > > >
> > > > > > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(),
> > > > > > so
> > > > > > I cannot use a spinlock.
> > > > >
> > > > > Ah right, I hadn't looked close enough. But putting the mutex_lock()
> > > > > outside of the bio_for_each_segment() is going to be much faster than
> > > > > getting/releasing it for each segment.
> > > >
> > > > It doesn't seem to make any measurable difference, so I'm gonna leave
> > > > it for
> > > > now.
> > >
> > > It will depend on where the bio's are coming from. If they are all
> > > single segment, then there will be no difference. If they contain
> > > multiple segments, you reduce the lock/release by that amount.
> > >
> > > But yeah, just leave it as-is for now. You can send a final patch for
> > > inclusion though. Unless I'm mistaken, I only saw the original and then
> > > an incremental patch for changing it to ->make_request_fn?
> >
> > There was a full version, my mistake. I got confused by the removal of
>
> Indeed.
>
> > the old driver in another directory :-)
>
> Can you please ack it? Thx!
Sure, I thought we had agreed to queue it up for 2.6.29?
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
Henk, On Montag, 9. März 2009, Henk Stegeman wrote: > I don't understand how this would work, > > Now I do one byte-swap, which works. > -I byteswap in software, for 16-bit cycles by byte swapping and for 8 > bit cycles by adding an offset of 1. > (The byte swapping on the chipselect is off) > > Your advice includes two byteswaps, one by re-routing the data bus and > one by enabling the byte swap on the chip-select. My experience is the chip select byte swap feature only works correctly if you connect a little endian device like I showed you. > Or does one of them not really swap bytes? Let me show you how it works. You must ensure you can write/read data in any data width, but at the side of the little endian device it always must be in the correct endianess. This example uses a 32 bit data width, but it works for 16 bit, too. - LE shows how a real litte endian CPU would write data - MPC1 shows how MPC5200 will do it, without any byte swap and DO at the MPC5200 side is also D0 at the little endian device - MPC2 shows how MPC5200 will do it, with D0 at the MPC5200 side is D24 at the little endian device - MPC3 shows how MPC5200 will do it, connected like MPC2 but also the chip select byte swap feature enabled - LE DEV shows how the little endian device expects the data You want to write this data at the given offset into the little endian device: Bytes: 0:0x34, 1:0x12, 2:0x78, 3:0x56 Worte: 0:0x1234 2:0x5678 LONG:0:0x56781234 Writing as bytes: Bytes: 0:0x34, 1:0x12, 2:0x78, 3:0x56 Offset LEMPC1 MPC2 MPC3 LE DEV 0 0x34 0x56 0x34 0x34 0x34 1 0x12 0x78 0x12 0x12 0x12 2 0x78 0x12 0x78 0x78 0x78 3 0x56 0x34 0x56 0x56 0x56 ------> these are correct > this is wrong Writing as words: Words: 0:0x1234 2:0x5678 Offset LE MPC1 MPC2 MPC3 LE DEV 0 0x34 0x78 0x12 0x34 0x34 (1) 0x12 0x56 0x34 0x12 0x12 2 0x78 0x34 0x56 0x78 0x78 (3) 0x56 0x12 0x78 0x56 0x56 -------> these are correct ----> these are wrong Writing as longs: LONG: 0:0x56781234 Offset LE MPC1 MPC2 MPC3 LE DEV 0 0x34 0x34 0x56 0x34 0x34 (1) 0x12 0x12 0x78 0x12 0x12 (2) 0x78 0x78 0x12 0x78 0x78 (3) 0x56 0x56 0x34 0x56 0x56 --- -------> these are correct --> this is wrong So, the MPC3 example always writes correct data. Hope it helps, Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | Phone: +49-8766-939 228 | Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ | ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Machine check in 4xx ethernet driver
On Mon, Mar 09, 2009 at 03:53:25AM -0700, Felix Radensky wrote: > > > >Josh Boyer-4 wrote: >> >> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote: >>> >>>Hi, >>> >>>I'm getting machine check exception when trying to dump >>>emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7 >>>The problem seems not new, I can reproduce it on 2.6.25 Denx kernel >> >> I've not looked at what that code path does, but the EMAC regs are >> in DCR space, not MMIO. Using memcpy_fromio there seems odd. >> >> > >At least on 405EX MAL registers are in DCR space, but EMAC and RGMII >ones are in MMIO space. Ah, quite right. No coffee yet this morning. You'll need to look at the code path ethtool is forcing. Perhaps it's doing something stupid. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
KGDB over serial on xilinx virtex-5 (ppc440)
Hi all, Has anybody tested KGDBOC in linux-2.6.28 for Xilinx Virtex-5 PowerPC target boards.. I just see that KGDB waits for remote connection from GDB host, but unfortunately Command line arguments were : console=ttyS0 ip=bootp root=/dev/nfs rw kgdboc=ttyS0 kgdbwait The test is been done on xilinx virtex-5 ppc440 target Target side: Serial: 8250/16550 driver4 ports, IRQ sharing disabled 83e0.serial: ttyS0 at MMIO 0x83e01003 (irq = 16) is a 16550A console [ttyS0] enabled kgdb: Registered I/O driver kgdboc. kgdb: Waiting for connection from remote gdb... -- Host side -- (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending packet: $qSupported#37...Timed out. Timed out. Timed out . . -- Is anything else need to be implemented for ppc44x for KGDB to work ? -- "The Good You Do, The Best You GET" Regards Srikanth Krishnakar ** ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Machine check in 4xx ethernet driver
Josh Boyer-4 wrote: > > On Mon, Mar 09, 2009 at 03:53:25AM -0700, Felix Radensky wrote: >> >> >> >>Josh Boyer-4 wrote: >>> >>> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote: Hi, I'm getting machine check exception when trying to dump emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7 The problem seems not new, I can reproduce it on 2.6.25 Denx kernel >>> >>> I've not looked at what that code path does, but the EMAC regs are >>> in DCR space, not MMIO. Using memcpy_fromio there seems odd. >>> >>> >> >>At least on 405EX MAL registers are in DCR space, but EMAC and RGMII >>ones are in MMIO space. > > Ah, quite right. No coffee yet this morning. > > You'll need to look at the code path ethtool is forcing. Perhaps it's > doing > something stupid. > > The problem goes away if I replace memcpy_fromio() by memcpy(). > Is memcpy_fromio() really necessary in this case ? > > -- View this message in context: http://www.nabble.com/Machine-check-in-4xx-ethernet-driver-tp22408005p22412825.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/7] Generic RTC class driver
Hi Alessandro et al, This patch series: 1. Adds the missing module alias to rtc-parisc (which is a bugfix), and performs a few cleanups, 2. Moves the platform device creation out of rtc-ppc and into arch-specific code (which is also a bugfix), 3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is a cleanup), 4. Hooks up rtc-generic on m68k (it's been using [sg]et_rtc_time() since ages), 5. Makes rtc-generic dependent on PARISC, PPC, and M68K (the existing [sg]et_rtc_time() users): a. without introducing ARCH_HAS_GENERIC_RTC, b. with a big fat warning in the Kconfig comment discouraging people from relaxing the dependencies. 6. Converts the PS3 RTC support into a separate driver, called rtc-ps3 (as a bonus ;-) To reduce code churn, the order and number of the actual patches slightly differs: [1] parisc: rtc: get_rtc_time() returns unsigned int [2] parisc: rtc: platform_driver_probe() fixups [3] parisc: rtc: Add missing module alias [4] parisc: rtc: Rename rtc-parisc to rtc-generic [5] m68k: Hook up rtc-generic [6] powerpc: Hook up rtc-generic, and kill rtc-ppc [7] powerpc/ps3: Add rtc-ps3 a/drivers/rtc/rtc-parisc.c | 85 - b/arch/m68k/include/asm/rtc.h |7 +- b/arch/m68k/kernel/time.c | 18 + b/arch/parisc/Kconfig |2 b/arch/parisc/kernel/time.c |6 - b/arch/powerpc/include/asm/ps3.h|3 b/arch/powerpc/kernel/time.c| 16 b/arch/powerpc/platforms/ps3/os-area.c |2 b/arch/powerpc/platforms/ps3/platform.h |2 b/arch/powerpc/platforms/ps3/setup.c|2 b/arch/powerpc/platforms/ps3/time.c | 26 +++ b/drivers/rtc/Kconfig | 10 +-- b/drivers/rtc/Makefile |2 b/drivers/rtc/rtc-generic.c | 84 + b/drivers/rtc/rtc-parisc.c |5 - b/drivers/rtc/rtc-ps3.c | 106 +++- drivers/rtc/Kconfig | 22 +++--- drivers/rtc/Makefile|2 drivers/rtc/rtc-parisc.c|6 - drivers/rtc/rtc-ppc.c | 70 - 20 files changed, 271 insertions(+), 205 deletions(-) These patches are relative to the "rtc-parisc" branch of Kyle's PA-RISC git repository, which already contains some cleanups for the rtc-parisc driver by Dann, which already have been ack'ed by Alessandro: http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=shortlog;h=rtc-parisc Paul: Feel free to add your SuperH support. I suppose the easiest way for this to go in is through Kyle's PA-RISC tree, as he already has the preceding patches? Can I have your acks, please? Thanks! With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/7] parisc: rtc: get_rtc_time() returns unsigned int
Signed-off-by: Geert Uytterhoeven
---
drivers/rtc/rtc-parisc.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index b966f56..620b949 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc/rtc-parisc.c
@@ -13,9 +13,7 @@
static int parisc_get_time(struct device *dev, struct rtc_time *tm)
{
- unsigned long ret;
-
- ret = get_rtc_time(tm);
+ unsigned int ret = get_rtc_time(tm);
if (ret & RTC_BATT_BAD)
return -EOPNOTSUPP;
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/7] parisc: rtc: platform_driver_probe() fixups
When using platform_driver_probe(), it's not needed to setup a .probe
function, and .remove should be marked __exit_p(), not __devexit_p().
Signed-off-by: Geert Uytterhoeven
Cc: dann frazier
---
drivers/rtc/rtc-parisc.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index 620b949..f4e871c 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc/rtc-parisc.c
@@ -62,8 +62,7 @@ static struct platform_driver parisc_rtc_driver = {
.name = "rtc-parisc",
.owner = THIS_MODULE,
},
- .probe = parisc_rtc_probe,
- .remove = __devexit_p(parisc_rtc_remove),
+ .remove = __exit_p(parisc_rtc_remove),
};
static int __init parisc_rtc_init(void)
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/7] parisc: rtc: Add missing module alias
Make udev autoload the driver
Signed-off-by: Geert Uytterhoeven
---
drivers/rtc/rtc-parisc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index f4e871c..48ef5b4 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc/rtc-parisc.c
@@ -81,3 +81,4 @@ module_exit(parisc_rtc_fini);
MODULE_AUTHOR("Kyle McMartin ");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("HP PA-RISC RTC driver");
+MODULE_ALIAS("platform:rtc-parisc");
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/7] m68k: Hook up rtc-generic
m68k has been a long time user of the generic RTC abstraction, so hook up
rtc-generic:
- Create the "rtc-generic" platform device if mach_hwclk is set,
- Add checks for mach_hwclk, in anticipation of RTC chip drivers being moved
to drivers/rtc/.
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/include/asm/rtc.h |7 +--
arch/m68k/kernel/time.c | 18 ++
drivers/rtc/Kconfig |2 +-
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/m68k/include/asm/rtc.h b/arch/m68k/include/asm/rtc.h
index 5d3e038..a4d08ea 100644
--- a/arch/m68k/include/asm/rtc.h
+++ b/arch/m68k/include/asm/rtc.h
@@ -36,13 +36,16 @@ static inline unsigned int get_rtc_time(struct rtc_time
*time)
* RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
* by the RTC when initially set to a non-zero value.
*/
- mach_hwclk(0, time);
+ if (mach_hwclk)
+ mach_hwclk(0, time);
return RTC_24H;
}
static inline int set_rtc_time(struct rtc_time *time)
{
- return mach_hwclk(1, time);
+ if (mach_hwclk)
+ return mach_hwclk(1, time);
+ return -EINVAL;
}
static inline unsigned int get_rtc_ss(void)
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index 7db4159..54d9807 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -159,3 +160,20 @@ int do_settimeofday(struct timespec *tv)
}
EXPORT_SYMBOL(do_settimeofday);
+
+
+static int __init rtc_init(void)
+{
+ struct platform_device *pdev;
+
+ if (!mach_hwclk)
+ return -ENODEV;
+
+ pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+module_init(rtc_init);
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index d0aeff2..c8ead87 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -681,7 +681,7 @@ config RTC_DRV_GENERIC
tristate "Generic RTC support"
# Please consider writing a new RTC driver instead of using the generic
# RTC abstraction
- depends on PARISC
+ depends on PARISC || M68K
help
Say Y or M here to enable RTC support on systems using the generic
RTC abstraction. If you do not know what you are doing, you should
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/7] parisc: rtc: Rename rtc-parisc to rtc-generic
The rtc-parisc driver is not PA-RISC specific at all, as it uses the existing
(but deprecated) generic RTC infrastructure ([gs]et_rtc_time()).
Rename the driver from rtc-parisc to rtc-generic.
Signed-off-by: Geert Uytterhoeven
---
arch/parisc/Kconfig |2 +-
arch/parisc/kernel/time.c |6 ++--
drivers/rtc/Kconfig | 10 +++--
drivers/rtc/Makefile |2 +-
drivers/rtc/rtc-generic.c | 84 +
drivers/rtc/rtc-parisc.c | 84 -
6 files changed, 95 insertions(+), 93 deletions(-)
create mode 100644 drivers/rtc/rtc-generic.c
delete mode 100644 drivers/rtc/rtc-parisc.c
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index aacf11d..378b649 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,7 @@ config PARISC
select HAVE_IDE
select HAVE_OPROFILE
select RTC_CLASS
- select RTC_DRV_PARISC
+ select RTC_DRV_GENERIC
select INIT_ALL_POSSIBLE
help
The PA-RISC microprocessor is designed by Hewlett-Packard and used
diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index e75cae6..86a99d0 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -216,14 +216,14 @@ void __init start_cpu_itimer(void)
per_cpu(cpu_data, cpu).it_value = next_tick;
}
-static struct platform_device rtc_parisc_dev = {
- .name = "rtc-parisc",
+static struct platform_device rtc_generic_dev = {
+ .name = "rtc-generic",
.id = -1,
};
static int __init rtc_init(void)
{
- if (platform_device_register(&rtc_parisc_dev) < 0)
+ if (platform_device_register(&rtc_generic_dev) < 0)
printk(KERN_ERR "unable to register rtc device...\n");
/* not necessarily an error */
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 81450fb..d0aeff2 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -677,12 +677,14 @@ config RTC_DRV_RS5C313
help
If you say yes here you get support for the Ricoh RS5C313 RTC chips.
-config RTC_DRV_PARISC
- tristate "PA-RISC firmware RTC support"
+config RTC_DRV_GENERIC
+ tristate "Generic RTC support"
+ # Please consider writing a new RTC driver instead of using the generic
+ # RTC abstraction
depends on PARISC
help
- Say Y or M here to enable RTC support on PA-RISC systems using
- firmware calls. If you do not know what you are doing, you should
+ Say Y or M here to enable RTC support on systems using the generic
+ RTC abstraction. If you do not know what you are doing, you should
just say Y.
config RTC_DRV_PPC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 0e697aa..9c18a01 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -55,7 +55,7 @@ obj-$(CONFIG_RTC_DRV_PCF8563) += rtc-pcf8563.o
obj-$(CONFIG_RTC_DRV_PCF8583) += rtc-pcf8583.o
obj-$(CONFIG_RTC_DRV_PL030)+= rtc-pl030.o
obj-$(CONFIG_RTC_DRV_PL031)+= rtc-pl031.o
-obj-$(CONFIG_RTC_DRV_PARISC) += rtc-parisc.o
+obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
obj-$(CONFIG_RTC_DRV_PPC) += rtc-ppc.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
diff --git a/drivers/rtc/rtc-generic.c b/drivers/rtc/rtc-generic.c
new file mode 100644
index 000..9832200
--- /dev/null
+++ b/drivers/rtc/rtc-generic.c
@@ -0,0 +1,84 @@
+/* rtc-generic: RTC driver using the generic RTC abstraction
+ *
+ * Copyright (C) 2008 Kyle McMartin
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static int generic_get_time(struct device *dev, struct rtc_time *tm)
+{
+ unsigned int ret = get_rtc_time(tm);
+
+ if (ret & RTC_BATT_BAD)
+ return -EOPNOTSUPP;
+
+ return rtc_valid_tm(tm);
+}
+
+static int generic_set_time(struct device *dev, struct rtc_time *tm)
+{
+ if (set_rtc_time(tm) < 0)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
+static const struct rtc_class_ops generic_rtc_ops = {
+ .read_time = generic_get_time,
+ .set_time = generic_set_time,
+};
+
+static int __init generic_rtc_probe(struct platform_device *dev)
+{
+ struct rtc_device *rtc;
+
+ rtc = rtc_device_register("rtc-generic", &dev->dev, &generic_rtc_ops,
+ THIS_MODULE);
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
+
+ platform_set_drvdata(dev, rtc);
+
+ return 0;
+}
+
+static int __exit generic_rtc_remove(struct platform_device *dev)
+{
+ struct rtc_device *rtc = platform_get_drvdata(dev);
+
+ rtc_device_unregister(rtc);
+
+ return 0;
+}
+
+static struct platform_driver generic_rtc_driver = {
+ .driver = {
+ .name = "rtc-generic",
+ .owner = THIS_MODULE,
+ },
+ .remove = __exit_p(generic_rtc_remove),
+};
+
+static
[PATCH 6/7] powerpc: Hook up rtc-generic, and kill rtc-ppc
PowerPC has been a long time user of the generic RTC abstraction, so hook up
rtc-generic:
- Create the "rtc-generic" platform device if ppc_md.get_rtc_time is set,
- Kill rtc-ppc, as rtc-generic offers the same functionality in a more
generic way, and supports autoloading through udev.
Signed-off-by: Geert Uytterhoeven
Cc: David Woodhouse
---
arch/powerpc/kernel/time.c | 16 ++
drivers/rtc/Kconfig| 10 +--
drivers/rtc/Makefile |1 -
drivers/rtc/rtc-ppc.c | 69
4 files changed, 17 insertions(+), 79 deletions(-)
delete mode 100644 drivers/rtc/rtc-ppc.c
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index c956403..926ea86 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1127,3 +1127,19 @@ void div128_by_32(u64 dividend_high, u64 dividend_low,
dr->result_low = ((u64)y << 32) + z;
}
+
+static int __init rtc_init(void)
+{
+ struct platform_device *pdev;
+
+ if (!ppc_md.get_rtc_time)
+ return -ENODEV;
+
+ pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+module_init(rtc_init);
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index c8ead87..6488c50 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -681,20 +681,12 @@ config RTC_DRV_GENERIC
tristate "Generic RTC support"
# Please consider writing a new RTC driver instead of using the generic
# RTC abstraction
- depends on PARISC || M68K
+ depends on PARISC || M68K || PPC
help
Say Y or M here to enable RTC support on systems using the generic
RTC abstraction. If you do not know what you are doing, you should
just say Y.
-config RTC_DRV_PPC
- tristate "PowerPC machine dependent RTC support"
- depends on PPC
- help
-The PowerPC kernel has machine-specific functions for accessing
-the RTC. This exposes that functionality through the generic RTC
-class.
-
config RTC_DRV_PXA
tristate "PXA27x/PXA3xx"
depends on ARCH_PXA
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 9c18a01..bd209a5 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -56,7 +56,6 @@ obj-$(CONFIG_RTC_DRV_PCF8583) += rtc-pcf8583.o
obj-$(CONFIG_RTC_DRV_PL030)+= rtc-pl030.o
obj-$(CONFIG_RTC_DRV_PL031)+= rtc-pl031.o
obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
-obj-$(CONFIG_RTC_DRV_PPC) += rtc-ppc.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
diff --git a/drivers/rtc/rtc-ppc.c b/drivers/rtc/rtc-ppc.c
deleted file mode 100644
index c8e97e2..000
--- a/drivers/rtc/rtc-ppc.c
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * RTC driver for ppc_md RTC functions
- *
- * © 2007 Red Hat, Inc.
- *
- * Author: David Woodhouse
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-
-#include
-#include
-#include
-#include
-#include
-
-static int ppc_rtc_read_time(struct device *dev, struct rtc_time *tm)
-{
- ppc_md.get_rtc_time(tm);
- return 0;
-}
-
-static int ppc_rtc_set_time(struct device *dev, struct rtc_time *tm)
-{
- return ppc_md.set_rtc_time(tm);
-}
-
-static const struct rtc_class_ops ppc_rtc_ops = {
- .set_time = ppc_rtc_set_time,
- .read_time = ppc_rtc_read_time,
-};
-
-static struct rtc_device *rtc;
-static struct platform_device *ppc_rtc_pdev;
-
-static int __init ppc_rtc_init(void)
-{
- if (!ppc_md.get_rtc_time || !ppc_md.set_rtc_time)
- return -ENODEV;
-
- ppc_rtc_pdev = platform_device_register_simple("ppc-rtc", 0, NULL, 0);
- if (IS_ERR(ppc_rtc_pdev))
- return PTR_ERR(ppc_rtc_pdev);
-
- rtc = rtc_device_register("ppc_md", &ppc_rtc_pdev->dev,
- &ppc_rtc_ops, THIS_MODULE);
- if (IS_ERR(rtc)) {
- platform_device_unregister(ppc_rtc_pdev);
- return PTR_ERR(rtc);
- }
-
- return 0;
-}
-
-static void __exit ppc_rtc_exit(void)
-{
- rtc_device_unregister(rtc);
- platform_device_unregister(ppc_rtc_pdev);
-}
-
-module_init(ppc_rtc_init);
-module_exit(ppc_rtc_exit);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("David Woodhouse ");
-MODULE_DESCRIPTION("Generic RTC class driver for PowerPC");
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/7] powerpc/ps3: Add rtc-ps3
Create a real RTC driver for PS3, and unhook the deprecated
ppc_md.[gs]et_rtc_time.
Signed-off-by: Geert Uytterhoeven
Cc: Geoff Levand
---
arch/powerpc/include/asm/ps3.h|3 +
arch/powerpc/platforms/ps3/os-area.c |2 +
arch/powerpc/platforms/ps3/platform.h |2 -
arch/powerpc/platforms/ps3/setup.c|2 -
arch/powerpc/platforms/ps3/time.c | 26 -
drivers/rtc/Kconfig |9 +++
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-ps3.c | 105 +
8 files changed, 132 insertions(+), 18 deletions(-)
create mode 100644 drivers/rtc/rtc-ps3.c
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index 67f1812..cdb6fd8 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -50,6 +50,9 @@ enum ps3_param_av_multi_out {
enum ps3_param_av_multi_out ps3_os_area_get_av_multi_out(void);
+extern u64 ps3_os_area_get_rtc_diff(void);
+extern void ps3_os_area_set_rtc_diff(u64 rtc_diff);
+
/* dma routines */
enum ps3_dma_page_size {
diff --git a/arch/powerpc/platforms/ps3/os-area.c
b/arch/powerpc/platforms/ps3/os-area.c
index e1c83c2..86e392b 100644
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -808,6 +808,7 @@ u64 ps3_os_area_get_rtc_diff(void)
{
return saved_params.rtc_diff;
}
+EXPORT_SYMBOL(ps3_os_area_get_rtc_diff);
/**
* ps3_os_area_set_rtc_diff - Set the rtc diff value.
@@ -823,6 +824,7 @@ void ps3_os_area_set_rtc_diff(u64 rtc_diff)
os_area_queue_work();
}
}
+EXPORT_SYMBOL(ps3_os_area_set_rtc_diff);
/**
* ps3_os_area_get_av_multi_out - Returns the default video mode.
diff --git a/arch/powerpc/platforms/ps3/platform.h
b/arch/powerpc/platforms/ps3/platform.h
index 235c13e..136aa06 100644
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -64,8 +64,6 @@ int ps3_set_rtc_time(struct rtc_time *time);
void __init ps3_os_area_save_params(void);
void __init ps3_os_area_init(void);
-u64 ps3_os_area_get_rtc_diff(void);
-void ps3_os_area_set_rtc_diff(u64 rtc_diff);
/* spu */
diff --git a/arch/powerpc/platforms/ps3/setup.c
b/arch/powerpc/platforms/ps3/setup.c
index 3331ccb..6618182 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -270,8 +270,6 @@ define_machine(ps3) {
.init_IRQ = ps3_init_IRQ,
.panic = ps3_panic,
.get_boot_time = ps3_get_boot_time,
- .set_rtc_time = ps3_set_rtc_time,
- .get_rtc_time = ps3_get_rtc_time,
.set_dabr = ps3_set_dabr,
.calibrate_decr = ps3_calibrate_decr,
.progress = ps3_progress,
diff --git a/arch/powerpc/platforms/ps3/time.c
b/arch/powerpc/platforms/ps3/time.c
index d0daf7d..b178a1e 100644
--- a/arch/powerpc/platforms/ps3/time.c
+++ b/arch/powerpc/platforms/ps3/time.c
@@ -19,6 +19,7 @@
*/
#include
+#include
#include
#include
@@ -74,23 +75,20 @@ static u64 read_rtc(void)
return rtc_val;
}
-int ps3_set_rtc_time(struct rtc_time *tm)
+unsigned long __init ps3_get_boot_time(void)
{
- u64 now = mktime(tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
- tm->tm_hour, tm->tm_min, tm->tm_sec);
-
- ps3_os_area_set_rtc_diff(now - read_rtc());
- return 0;
+ return read_rtc() + ps3_os_area_get_rtc_diff();
}
-void ps3_get_rtc_time(struct rtc_time *tm)
+static int __init ps3_rtc_init(void)
{
- to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
- tm->tm_year -= 1900;
- tm->tm_mon -= 1;
-}
+ struct platform_device *pdev;
-unsigned long __init ps3_get_boot_time(void)
-{
- return read_rtc() + ps3_os_area_get_rtc_diff();
+ pdev = platform_device_register_simple("rtc-ps3", -1, NULL, 0);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
}
+
+module_init(ps3_rtc_init);
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 6488c50..7b6b63a 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -730,4 +730,13 @@ config RTC_DRV_MV
This driver can also be built as a module. If so, the module
will be called rtc-mv.
+config RTC_DRV_PS3
+ tristate "PS3 RTC"
+ depends on PPC_PS3
+ help
+ If you say yes here you will get support for the RTC on PS3.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-ps3.
+
endif # RTC_CLASS
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index bd209a5..d161d1d 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -75,3 +75,4 @@ obj-$(CONFIG_RTC_DRV_VR41XX) += rtc-vr41xx.o
obj-$(CONFIG_RTC_DRV_WM8350) += rtc-wm8350.o
obj-$(CONFIG_RTC_DRV_X1205)+= rtc-x12
Re: [PATCH 6/7] powerpc: Hook up rtc-generic, and kill rtc-ppc
On Mon, 2009-03-09 at 14:26 +0100, Geert Uytterhoeven wrote: > PowerPC has been a long time user of the generic RTC abstraction, so hook up > rtc-generic: > - Create the "rtc-generic" platform device if ppc_md.get_rtc_time is set, > - Kill rtc-ppc, as rtc-generic offers the same functionality in a more > generic way, and supports autoloading through udev. > > Signed-off-by: Geert Uytterhoeven Acked-By: David Woodhouse -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH 7/7] powerpc/ps3: Add rtc-ps3
On Mon, 9 Mar 2009 14:26:23 +0100
Geert Uytterhoeven wrote:
Hi,
just a few notes:
> +
> +static int ps3_get_time(struct device *dev, struct rtc_time *tm)
> +{
> + to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
> + tm->tm_year -= 1900;
> + tm->tm_mon -= 1;
> + return 0;
> +}
this should be return rtc_valid_tm() .
can't you use functions from rtc-lib.c instead of
that to_tm ?
> +
> +MODULE_AUTHOR("Sony Corporation");
real name, if possible and a contact address
here . Just in case I need someone to bother :)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH 0/7] Generic RTC class driver
On Mon, 9 Mar 2009 14:26:16 +0100 Geert Uytterhoeven wrote: > Hi Alessandro et al, > > These patches are relative to the "rtc-parisc" branch of Kyle's PA-RISC git > repository, which already contains some cleanups for the rtc-parisc driver by > Dann, which already have been ack'ed by Alessandro: > > http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=shortlog;h=rtc-parisc > > Paul: Feel free to add your SuperH support. > > I suppose the easiest way for this to go in is through Kyle's PA-RISC tree, as > he already has the preceding patches? Can I have your acks, please? Here's mine. Thanks for your efforts . Acked-by: Alessandro Zummo btw I'll pretend I had never seen this patch if asked in court :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [U-Boot] ppc4xx: u-boot sees PCIe endpoint, linux does not.
Hello Stefan, On Mon, Dec 1, 2008 at 8:46 PM, Stefan Roese wrote: > On Monday 01 December 2008, Leon Woestenberg wrote: >> >> Now, if I re-program the end-point FPGA during the u-boot boot >> >> time-out, Linux will recognize the end-point. >> > >> > It's possible that either the reset in between goes bonkers or something >> > else causes your FPGA to stop responding. It looks like a programming >> > problem with the FPGA to me. >> >> I have verified that the end point does not receive any kind of reset. >> >> Also, this problem only happens on the Canyonlands board; on x86 and >> powerpc MPC8315E it remains properly working after soft/hard resets, >> u-boot init etc. > > This could be because only the 4xx Linux PCI(e) driver really resets the > endpoint (PHY reset). But you seem to have analyzed this already. > Some progress: Using au-boot GIT checkout of 9-2-2009 (one month old) I now have different behaviour: u-boot does report a link, but no longer the PCIe vendor id: CPU: AMCC PowerPC 460EX Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100 MHz) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter disabled 32 kB I-Cache 32 kB D-Cache Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 I2C: ready DTT: 1 is 44 C DRAM: 512 MB (ECC not enabled, 400 MHz, CL3) FLASH: 64 MB NAND: 128 MiB PCI: Bus Dev VenId DevId Class Int PCIE0: link is not up. PCIE0: initialization as root-complex failed PCIE1: successfully set as root-complex Linux now correctly recognizes the device. The FPGA with PCIe end point now also survives both a hard reset (reset button) and soft reset (shutdown -r now in Linux). Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Machine check in 4xx ethernet driver
Josh Boyer-4 wrote: > > On Mon, Mar 09, 2009 at 03:53:25AM -0700, Felix Radensky wrote: >> >> >> >>Josh Boyer-4 wrote: >>> >>> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote: Hi, I'm getting machine check exception when trying to dump emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7 The problem seems not new, I can reproduce it on 2.6.25 Denx kernel >>> >>> I've not looked at what that code path does, but the EMAC regs are >>> in DCR space, not MMIO. Using memcpy_fromio there seems odd. >>> >>> >> >>At least on 405EX MAL registers are in DCR space, but EMAC and RGMII >>ones are in MMIO space. > > Ah, quite right. No coffee yet this morning. > > You'll need to look at the code path ethtool is forcing. Perhaps it's > doing > something stupid. > > Bad quoting in previous message, sorry. The problem goes away if I replace memcpy_fromio() by memcpy()., but register values seem wrong. Why would memcpy() work when memcpy_fromio() doesn't ? -- View this message in context: http://www.nabble.com/Machine-check-in-4xx-ethernet-driver-tp22408005p22413434.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/bootwrapper: add fixed-head.o to simpleimage wrappers
From: Grant Likely fixed-head.o must be linked into the bootwrapper for raw-binary images to work. This patch adds it into the bootwrapper. Signed-off-by: Grant Likely Reported-by: Eddie Dawydiuk --- I pulled this chunk out of Eddie's bigger patch and also modified the other case where it applies. This is a definite bug on the simpleimage generation. Once I get an ack, I'll add it to my -next tree and ask Ben to pull. Cheers, g. arch/powerpc/boot/wrapper |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index 965c237..c5bd9cf 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -211,11 +211,11 @@ simpleboot-virtex405-*) binary=y ;; simpleboot-virtex440-*) -platformo="$object/simpleboot.o $object/virtex.o" +platformo="$object/fixed-head.o $object/simpleboot.o $object/virtex.o" binary=y ;; simpleboot-*) -platformo="$object/simpleboot.o" +platformo="$object/fixed-head.o $object/simpleboot.o" binary=y ;; asp834x-redboot) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH 7/7] powerpc/ps3: Add rtc-ps3
On Mon, 9 Mar 2009, Alessandro Zummo wrote:
> On Mon, 9 Mar 2009 14:26:23 +0100
> Geert Uytterhoeven wrote:
> > +
> > +static int ps3_get_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
> > + tm->tm_year -= 1900;
> > + tm->tm_mon -= 1;
> > + return 0;
> > +}
>
> this should be return rtc_valid_tm() .
Fixed.
> can't you use functions from rtc-lib.c instead of
> that to_tm ?
Ah, those pesky PPC-specific functions... switched to rtc_time_to_tm() and
rtc_tm_to_time().
> > +
> > +MODULE_AUTHOR("Sony Corporation");
>
> real name, if possible and a contact address
> here . Just in case I need someone to bother :)
All PS3-specific drivers have this. But there's an official PS3 platform
maintainer in MAINTAINERS.
>From 41020647c3e2b07e0302a905a926d6221061a128 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven
Date: Tue, 24 Feb 2009 14:04:20 +0100
Subject: powerpc/ps3: Add rtc-ps3
Create a real RTC driver for PS3, and unhook the deprecated
ppc_md.[gs]et_rtc_time.
Signed-off-by: Geert Uytterhoeven
Acked-by: Alessandro Zummo
---
arch/powerpc/include/asm/ps3.h|3 +
arch/powerpc/platforms/ps3/os-area.c |2 +
arch/powerpc/platforms/ps3/platform.h |2 -
arch/powerpc/platforms/ps3/setup.c|2 -
arch/powerpc/platforms/ps3/time.c | 26 -
drivers/rtc/Kconfig |9 +++
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-ps3.c | 104 +
8 files changed, 131 insertions(+), 18 deletions(-)
create mode 100644 drivers/rtc/rtc-ps3.c
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index 67f1812..cdb6fd8 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -50,6 +50,9 @@ enum ps3_param_av_multi_out {
enum ps3_param_av_multi_out ps3_os_area_get_av_multi_out(void);
+extern u64 ps3_os_area_get_rtc_diff(void);
+extern void ps3_os_area_set_rtc_diff(u64 rtc_diff);
+
/* dma routines */
enum ps3_dma_page_size {
diff --git a/arch/powerpc/platforms/ps3/os-area.c
b/arch/powerpc/platforms/ps3/os-area.c
index e1c83c2..86e392b 100644
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -808,6 +808,7 @@ u64 ps3_os_area_get_rtc_diff(void)
{
return saved_params.rtc_diff;
}
+EXPORT_SYMBOL(ps3_os_area_get_rtc_diff);
/**
* ps3_os_area_set_rtc_diff - Set the rtc diff value.
@@ -823,6 +824,7 @@ void ps3_os_area_set_rtc_diff(u64 rtc_diff)
os_area_queue_work();
}
}
+EXPORT_SYMBOL(ps3_os_area_set_rtc_diff);
/**
* ps3_os_area_get_av_multi_out - Returns the default video mode.
diff --git a/arch/powerpc/platforms/ps3/platform.h
b/arch/powerpc/platforms/ps3/platform.h
index 235c13e..136aa06 100644
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -64,8 +64,6 @@ int ps3_set_rtc_time(struct rtc_time *time);
void __init ps3_os_area_save_params(void);
void __init ps3_os_area_init(void);
-u64 ps3_os_area_get_rtc_diff(void);
-void ps3_os_area_set_rtc_diff(u64 rtc_diff);
/* spu */
diff --git a/arch/powerpc/platforms/ps3/setup.c
b/arch/powerpc/platforms/ps3/setup.c
index 3331ccb..6618182 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -270,8 +270,6 @@ define_machine(ps3) {
.init_IRQ = ps3_init_IRQ,
.panic = ps3_panic,
.get_boot_time = ps3_get_boot_time,
- .set_rtc_time = ps3_set_rtc_time,
- .get_rtc_time = ps3_get_rtc_time,
.set_dabr = ps3_set_dabr,
.calibrate_decr = ps3_calibrate_decr,
.progress = ps3_progress,
diff --git a/arch/powerpc/platforms/ps3/time.c
b/arch/powerpc/platforms/ps3/time.c
index d0daf7d..b178a1e 100644
--- a/arch/powerpc/platforms/ps3/time.c
+++ b/arch/powerpc/platforms/ps3/time.c
@@ -19,6 +19,7 @@
*/
#include
+#include
#include
#include
@@ -74,23 +75,20 @@ static u64 read_rtc(void)
return rtc_val;
}
-int ps3_set_rtc_time(struct rtc_time *tm)
+unsigned long __init ps3_get_boot_time(void)
{
- u64 now = mktime(tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
- tm->tm_hour, tm->tm_min, tm->tm_sec);
-
- ps3_os_area_set_rtc_diff(now - read_rtc());
- return 0;
+ return read_rtc() + ps3_os_area_get_rtc_diff();
}
-void ps3_get_rtc_time(struct rtc_time *tm)
+static int __init ps3_rtc_init(void)
{
- to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
- tm->tm_year -= 1900;
- tm->tm_mon -= 1;
-}
+ struct platform_device *pdev;
-unsigned long __init ps3_get_boot_time(void)
-{
- return read_rtc() + ps3_os_area_get_rtc_diff();
+ pdev = platform_device_register_simple("rtc-ps3", -1, NULL, 0)
Re: next branch status
On Mar 2, 2009, at 10:55 PM, Benjamin Herrenschmidt wrote: Note: Kumar and Grant, pls be a bit more careful with files outside of arch/powerpc ... like the 5200 fec driver change, even if it's really powerpc only stuff and quite clearly so, it's in drivers/net, it wouldn't have hurt to seek davem ack for it... No big deal, it's only 2 or 3 files that I might need to give Linus an explanation about tho :-) Which files are you taking about? The i2c driver changes got ack'd by Ben Dooks. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Generic RTC class driver
On Mon, Mar 09, 2009 at 02:26:16PM +0100, Geert Uytterhoeven wrote: > Paul: Feel free to add your SuperH support. > > I suppose the easiest way for this to go in is through Kyle's PA-RISC tree, as > he already has the preceding patches? Can I have your acks, please? > I'll add the SH support once the patch set is merged, it's not a very pressing matter, so no need to make the patch juggling any more complicated :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: clean up ssi.txt, add definition for fsl, ssi-asynchronous
On Mar 6, 2009, at 1:43 PM, Timur Tabi wrote: Add the definition of the fsl,ssi-asynchronous property to ssi.txt (documentation of the device tree bindings for the Freescale SSI device). Also tidy up the layout of ssi.txt. Signed-off-by: Timur Tabi --- v2: fixed typo, improved wording. Documentation/powerpc/dts-bindings/fsl/ssi.txt | 68 + +-- 1 files changed, 40 insertions(+), 28 deletions(-) does not apply cleanly if/after I apply: powerpc: add fsl, fifo-depth property to Freescale SSI device nodes - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add fsl, fifo-depth property to Freescale SSI device nodes
On Mar 4, 2009, at 2:55 PM, Timur Tabi wrote: The Freescale Serial Synchronous Interface (SSI) is an audio device present on some Freescale SOCs. Various implementations of the SSI have a different transmit and receive FIFO depth, but are otherwise identical. To support these variations, add a new property fsl,fifo-depth to the SSI node that specifies the depth of the FIFOs. Also update the MPC8610 HPCD device tree with this property. Signed-off-by: Timur Tabi --- Updates to the SSI audio driver will come later. Currently, this driver supports only one Freescale SOC, and so it's hard-coded to use the value 8. If/when this driver is updated to support other SOCs (e.g. the i.MX parts that have a FIFO depth of 15), the driver will check for this property. I just want to get this DTS change in now. Documentation/powerpc/dts-bindings/fsl/ssi.txt |2 ++ arch/powerpc/boot/dts/mpc8610_hpcd.dts |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: clean up ssi.txt, add definition for fsl, ssi-asynchronous
Kumar Gala wrote: > does not apply cleanly if/after I apply: > > powerpc: add fsl, fifo-depth property to Freescale SSI device nodes That's weird -- I designed the patch so that it would. Oh well, I'll rebase and repost. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'merge'
Please pull from 'merge' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge to receive the following updates: arch/powerpc/configs/linkstation_defconfig | 36 + arch/powerpc/configs/storcenter_defconfig| 35 + arch/powerpc/platforms/embedded6xx/linkstation.c | 38 --- arch/powerpc/platforms/embedded6xx/storcenter.c | 32 --- 4 files changed, 44 insertions(+), 97 deletions(-) Guennadi Liakhovetski (1): powerpc: fix linkstation and storcenter compilation breakage ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] eHEA: Don't do memory allocation under lock if not necessary
In ehea_probe_adapter() the initial memory allocation and initialisation does
not need to be done with the ehea_fw_handles.lock semaphore held. Doing so
extends the amount of time the lock is held unnecessarily.
Signed-off-by: David Howells
---
drivers/net/ehea/ehea_main.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index dfe9226..34480ae 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -3370,18 +3370,19 @@ static int __devinit ehea_probe_adapter(struct
of_device *dev,
ehea_error("Invalid ibmebus device probed");
return -EINVAL;
}
- mutex_lock(&ehea_fw_handles.lock);
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
- ret = -ENOMEM;
dev_err(&dev->dev, "no mem for ehea_adapter\n");
- goto out;
+ return -ENOMEM;
}
- list_add(&adapter->list, &adapter_list);
-
adapter->ofdev = dev;
+ adapter->pd = EHEA_PD_ID;
+
+ mutex_lock(&ehea_fw_handles.lock);
+
+ list_add(&adapter->list, &adapter_list);
adapter_handle = of_get_property(dev->node, "ibm,hea-handle",
NULL);
@@ -3395,8 +3396,6 @@ static int __devinit ehea_probe_adapter(struct of_device
*dev,
goto out_free_ad;
}
- adapter->pd = EHEA_PD_ID;
-
dev->dev.driver_data = adapter;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add unwind information for SPE registers of E500 core
On Mar 3, 2009, at 10:51 PM, Liming Wang wrote: SPE registers use the high part bit0~bit31 of E500 GPR0~GPR31. The unwind information in "eh_frame" section is used during exception handling and describes register information in the signal frame. But current unwind information doesn't cover SPE registers, which have been saved in the signal frame. This patch adds this unwind information to "eh_frame" section. SPE registers use register number 1200+N to identify register 'N', but they start from 113 in unwind column, which is computed from gcc source code, macro DWARF_REG_TO_UNWIND_COLUMN: #define FIRST_PSEUDO_REGISTER 114 #define DWARF_REG_TO_UNWIND_COLUMN(r) \ ((r) > 1200 ? ((r) - 1200 + FIRST_PSEUDO_REGISTER - 1) : (r)) Signed-off-by: Liming Wang --- arch/powerpc/kernel/vdso32/sigtramp.S | 34 + 1 files changed, 34 insertions(+), 0 deletions(-) What about SPEFSCR & the accumulator? Are they not part of the frame? They probably should be. diff --git a/arch/powerpc/kernel/vdso32/sigtramp.S b/arch/powerpc/ kernel/vdso32/sigtramp.S index 68d49dd..789a343 100644 --- a/arch/powerpc/kernel/vdso32/sigtramp.S +++ b/arch/powerpc/kernel/vdso32/sigtramp.S @@ -251,6 +251,40 @@ V_FUNCTION_END(__kernel_sigtramp_rt32) vsave_msr1 (31); \ vsave_msr2 (33, 32*16+12);\ vsave (32, 32*16) +#elif defined(CONFIG_SPE) +#define EH_FRAME_VMX \ introduce EH_FRAME_SPE. + rsave (113, VREGS); \ we should probably be doing the same thing as vsave_msr1() - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/kernel: typo: s/resouces/resources/
Signed-off-by: Wolfram Sang
---
arch/powerpc/kernel/pci-common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 0f41812..f57b7bf 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1453,7 +1453,7 @@ void __init pcibios_resource_survey(void)
* we proceed to assigning things that were left unassigned
*/
if (!(ppc_pci_flags & PPC_PCI_PROBE_ONLY)) {
- pr_debug("PCI: Assigning unassigned resouces...\n");
+ pr_debug("PCI: Assigning unassigned resources...\n");
pci_assign_unassigned_resources();
}
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cpm_uart: fix non-console port startup bug
On Mar 5, 2009, at 9:01 PM, Xiaotian Feng wrote: After UART interrupt handler is installed and rx is enabled, if an rx interrupt comes before hardware init, rx->cur will be updated. Then the hardware init will reset BD and make rx->cur out of sync, move the hardware init code before request_irq. Signed-off-by: Xiaotian Feng --- drivers/serial/cpm_uart/cpm_uart_core.c | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc 4xx: DDR0_14[REDUC] decoded incorrectly
Hi, according to the PPC440EPx Embedded Processor User Manual (rev 1.14) DDR0_14[REDUC] bit has the following meaning: REDUC - Enable the half data path feature of the controller 0 = Standard operation using full 64/72-bit memory bus 1 = Memory data path width is 32/40 bits However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus by the kernel code. My understanding is this is not correct - patch attached. --- linux.orig/arch/powerpc/boot/4xx.c 2009-03-09 17:55:01.0 +0200 +++ linux/arch/powerpc/boot/4xx.c 2009-03-09 17:58:07.0 +0200 @@ -193,9 +193,9 @@ val = SDRAM0_READ(DDR0_14); if (DDR_GET_VAL(val, DDR_REDUC, DDR_REDUC_SHIFT)) - dpath = 8; /* 64 bits */ - else dpath = 4; /* 32 bits */ + else + dpath = 8; /* 64 bits */ /* get address pins (rows) */ val = SDRAM0_READ(DDR0_42); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH resend 0/6] OpenFirmware support for the spi_mpc83xx driver
On Jan 23, 2009, at 1:49 PM, Anton Vorontsov wrote: On Tue, Jan 06, 2009 at 10:28:10PM -0600, Kumar Gala wrote: On Dec 5, 2008, at 2:09 PM, Anton Vorontsov wrote: Hi all, The patch series are used to support SPI via the OF SPI subsystem (driver/of/of_spi.c). Now the driver is able to manage its own chip selects, and doesn't need any auxiliary support from the board files or fsl_soc constructors. The series also contains PowerPC portions of the MMC SPI support. Since the series touches spi and powerpc trees, I think it would be most convenient to pass it via one of these trees. The patches doesn't touch any SPI functionality, only some probe routines, so I believe powerpc.git is the best candidate... The other reason for powerpc tree is that the patches depends on other patches as found in paulus/powerpc.git + of_gpio_count() as found here: http://ozlabs.org/pipermail/linuxppc-dev/2008-December/065917.html David, if you're OK with the patches, may I ask you to sign off on the ones that touch drivers/spi so that we could pass it via Kumar's powerpc.git? The queue: [1/7] powerpc: Implement get_brgfreq() and get_baudrate() stubs [2/7] spi_mpc83xx: Fix sparse warnings [3/7] spi_mpc83xx: Rework chip selects handling [4/7] spi_mpc83xx: Add OF platform driver bindings [5/7] powerpc/fsl_soc: Isolate legacy fsl_spi support to mpc832x_rdb boards [6/7] powerpc: Add mmc-spi-slot bindings [7/7] powerpc/83xx: Add mmc-spi support via the device tree for MPC8323E-RDB David, Any status on these patches? Ping? No single comment on this patch set for ~2 months... Resending... Thanks, David, Anything going on here? Should we send this via some other channel? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/86xx: Correct local bus registers in GE Fanuc SBC610 dts file
On Feb 27, 2009, at 9:53 AM, Martyn Welch wrote: The registers for the local bus are incorrectly set to 0xf8005000 rather than there actual location of 0xfef05000. Signed-off-by: Martyn Welch --- arch/powerpc/boot/dts/gef_sbc610.dts |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc 4xx: DDR0_14[REDUC] decoded incorrectly
On Mon, Mar 09, 2009 at 06:21:36PM +0200, Mikhail Zolotaryov wrote: > Hi, > > according to the PPC440EPx Embedded Processor User Manual (rev 1.14) > DDR0_14[REDUC] bit has the following meaning: > > REDUC - Enable the half data path feature of the controller > 0 = Standard operation using full 64/72-bit memory bus > 1 = Memory data path width is 32/40 bits > > However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus > by the kernel code. My understanding is this is not correct - patch > attached. You are missing the Signed-off-by tag that is needed. Aside from that, I'm curious if you found this just through inspection, or if you actually had a problem because of it. Your fix seems correct, yet I've had no problems with my boards at all. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ps3/block: Replace mtd/ps3vram by block/ps3vram
On 03/06/2009 04:54 AM, Geert Uytterhoeven wrote: > Convert the PS3 Video RAM Storage Driver from an MTD driver to a plain block > device driver. > > The ps3vram driver exposes unused video RAM on the PS3 as a block device > suitable for storage or swap. Fast data transfer is achieved using a local > cache in system RAM and DMA transfers via the GPU. > > The new driver is ca. 50% faster for reading, and ca. 10% for writing. > > arch/powerpc/platforms/ps3/Kconfig |7 + > drivers/block/Makefile |1 + > drivers/block/ps3vram.c| 865 > > drivers/mtd/devices/Kconfig|7 - > drivers/mtd/devices/Makefile |1 - > drivers/mtd/devices/ps3vram.c | 768 > 6 files changed, 873 insertions(+), 776 deletions(-) > create mode 100644 drivers/block/ps3vram.c > delete mode 100644 drivers/mtd/devices/ps3vram.c Looks good, certainly an improvement. Acked-by: Geoff Levand ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.29-rc7-git2 : crash in kmem_list3_init()
On Mon, Mar 09, 2009 at 10:02:11PM +0530, Sachin P. Sant wrote: > While trying to boot 2.6.29-rc7-git2 on a power5 box ran into > following crash. > > Unable to handle kernel paging request for data at address 0xc00070001008 > Faulting instruction address: 0xc0119070 > cpu 0x0: Vector: 300 (Data Access) at [c0ac3980] >pc: c0119070: .kmem_list3_init+0x68/0x8c >lr: c011906c: .kmem_list3_init+0x64/0x8c >sp: c0ac3c00 > msr: 80009032 > dar: c00070001008 > dsisr: 4200 > current = 0xc09ea610 > paca= 0xc0b43480 >pid = 0, comm = swapper > enter ? for help > [c0ac3c90] c068b788 .setup_cpu_cache+0xf8/0x1e8 > [c0ac3d20] c011c8a0 .kmem_cache_create+0x43c/0x500 > [c0ac3e20] c0948c54 .kmem_cache_init+0x284/0x640 > [c0ac3ee0] c0920a5c .start_kernel+0x360/0x480 > [c0ac3f90] c00083d8 .start_here_common+0x1c/0x44 > > Attached here is the dmesg log with loglevel=8 mminit_loglevel=4 > as well as .config used. > > Tried to boot a kernel.org kernel on this box for first time so not > sure if this is a new problem or a recurring one. Will try booting > some older kernels on this box and will report the results. > > Node 0 Memory: 0x800-0x3a00 > Node 1 Memory: 0x0-0x800 0x3a00-0x7200 > PCI host bridge /p...@8002003 ranges: > IO 0x03fe0070..0x03fe007f -> 0x > MEM 0x0401c000..0x0401 -> 0xc000 > EEH: PCI Enhanced I/O Error Handling Enabled > PPC64 nvram contains 7168 bytes > Using shared processor idle loop > Zone PFN ranges: > DMA 0x -> 0x7200 > Normal 0x7200 -> 0x7200 > Movable zone start PFN for each node > early_node_map[3] active PFN ranges > 1: 0x -> 0x0800 > 0: 0x0800 -> 0x3a00 > 1: 0x3a00 -> 0x7200 What's interesting about this machine is that the nodes are interleaving. It's possible someone is double initialising incorrectly. > mminit::pageflags_layout_widths Section 0 Node 4 Zone 2 Flags 22 > mminit::pageflags_layout_shifts Section 20 Node 4 Zone 2 > mminit::pageflags_layout_offsets Section 0 Node 60 Zone 58 > mminit::pageflags_layout_zoneid Zone ID: 58 -> 64 > mminit::pageflags_layout_usage location: 64 -> 58 unused 58 -> 22 flags 22 -> > 0 > On node 0 totalpages: 12800 > DMA zone: 18 pages used for memmap > DMA zone: 0 pages reserved > DMA zone: 12782 pages, LIFO batch:1 > mminit::memmap_init Initialising map node 0 zone 0 pfns 2048 -> 14848 > On node 1 totalpages: 16384 > DMA zone: 40 pages used for memmap > DMA zone: 0 pages reserved > DMA zone: 16344 pages, LIFO batch:1 > mminit::memmap_init Initialising map node 1 zone 0 pfns 0 -> 29184 See, the core initialising at least goes over both nodes when initialising node 1. The page mappings should be ok because this situation is checked for but it's possible the SLAB allocator is missing something. > [boot]0015 Setup Done > mminit::zonelist general 0:DMA = 0:DMA 1:DMA > mminit::zonelist thisnode 0:DMA = 0:DMA > mminit::zonelist general 1:DMA = 1:DMA 0:DMA > mminit::zonelist thisnode 1:DMA = 1:DMA > Built 2 zonelists in Node order, mobility grouping on. Total pages: 29126 > Policy zone: DMA > Kernel command line: root=/dev/sda5 quiet sysrq=1 loglevel=8 > mminit_loglevel=4 > [boot]0020 XICS Init > [boot]0021 XICS Done > pic: no ISA interrupt controller > PID hash table entries: 4096 (order: 12, 32768 bytes) > time_init: decrementer frequency = 207.05 MHz > time_init: processor frequency = 1656.40 MHz > clocksource: timebase mult[1351aa5] shift[22] registered > clockevent: decrementer mult[3501] shift[16] cpu[0] > Console: colour dummy device 80x25 > console handover: boot [udbg0] -> real [hvc0] > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar > ... MAX_LOCKDEP_SUBCLASSES: 8 > ... MAX_LOCK_DEPTH: 48 > ... MAX_LOCKDEP_KEYS:8191 > ... CLASSHASH_SIZE: 4096 > ... MAX_LOCKDEP_ENTRIES: 8192 > ... MAX_LOCKDEP_CHAINS: 16384 > ... CHAINHASH_SIZE: 8192 > memory used by lock dependency info: 3839 kB > per task-struct memory footprint: 1920 bytes > Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes) > Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes) > freeing bootmem node 0 > freeing bootmem node 1 > Memory: 1812096k/1867776k available (9792k kernel code, 57856k reserved, > 1216k data, 8025k bss, 448k init) > Unable to handle kernel paging request for data at address 0xc00070001008 What is meant to be stored at this address 0xc00070001008? Because the error occurs aftre freeing bootmem memory, I wonder with the interleaving node if memory is getting inappropriately freed. > Faulting instruction address: 0xc0119070 > cpu 0x0: Vector: 300 (Data Access) at [c0ac3980] > pc: c00
[PATCH] powerpc udbg: fix lost byte during console handover; change LFCR to CRLF
When the console is on a serial port to be driven by serial8250, a
character can be lost from the end of the first line in the two-line
sequence
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
This happens because udbg_puts or udbg_write stuff the last byte of
the line into the Tx FIFO and return, whereupon the serial8250
initialization code immediately empties that FIFO. The fix: udbg_puts
and udbg_write now wait for the Tx FIFO to clear before returning.
This delays the system by one additional serial frame time for each
line written by udbg, but the effect is not noticeable, a cumulative
17 milliseconds for 200 lines of early printk output at 115200 baud.
Also, the routines in udbg_16550.c now emit CRLF instead of LFCR.
Linux makes a point of emitting CRLF because, when serial output is
captured to a file, LFCR sequences can confuse text editors. See
http://lkml.org/lkml/2006/2/4/50 for some history.
Signed-off-by: Andrew Klossner
---
arch/powerpc/include/asm/udbg.h |1 +
arch/powerpc/kernel/udbg.c |7
arch/powerpc/kernel/udbg_16550.c | 60 +++--
3 files changed, 58 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
index 6418cee..cd21e5e 100644
--- a/arch/powerpc/include/asm/udbg.h
+++ b/arch/powerpc/include/asm/udbg.h
@@ -15,6 +15,7 @@
#include
extern void (*udbg_putc)(char c);
+extern void (*udbg_flush)(void);
extern int (*udbg_getc)(void);
extern int (*udbg_getc_poll)(void);
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index 7d6c9bb..fc9af47 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -18,6 +18,7 @@
#include
void (*udbg_putc)(char c);
+void (*udbg_flush)(void);
int (*udbg_getc)(void);
int (*udbg_getc_poll)(void);
@@ -76,6 +77,9 @@ void udbg_puts(const char *s)
while ((c = *s++) != '\0')
udbg_putc(c);
}
+
+ if (udbg_flush)
+ udbg_flush();
}
#if 0
else {
@@ -98,6 +102,9 @@ int udbg_write(const char *s, int n)
}
}
+ if (udbg_flush)
+ udbg_flush();
+
return n - remain;
}
diff --git a/arch/powerpc/kernel/udbg_16550.c b/arch/powerpc/kernel/udbg_16550.c
index 7b7da8c..0362a89 100644
--- a/arch/powerpc/kernel/udbg_16550.c
+++ b/arch/powerpc/kernel/udbg_16550.c
@@ -48,14 +48,21 @@ struct NS16550 {
static struct NS16550 __iomem *udbg_comport;
-static void udbg_550_putc(char c)
+static void udbg_550_flush(void)
{
if (udbg_comport) {
while ((in_8(&udbg_comport->lsr) & LSR_THRE) == 0)
/* wait for idle */;
- out_8(&udbg_comport->thr, c);
+ }
+}
+
+static void udbg_550_putc(char c)
+{
+ if (udbg_comport) {
if (c == '\n')
udbg_550_putc('\r');
+ udbg_550_flush();
+ out_8(&udbg_comport->thr, c);
}
}
@@ -108,6 +115,7 @@ void udbg_init_uart(void __iomem *comport, unsigned int
speed,
/* Clear & enable FIFOs */
out_8(&udbg_comport->fcr ,0x07);
udbg_putc = udbg_550_putc;
+ udbg_flush = udbg_550_flush;
udbg_getc = udbg_550_getc;
udbg_getc_poll = udbg_550_getc_poll;
}
@@ -149,14 +157,21 @@ unsigned int udbg_probe_uart_speed(void __iomem *comport,
unsigned int clock)
}
#ifdef CONFIG_PPC_MAPLE
-void udbg_maple_real_putc(char c)
+void udbg_maple_real_flush(void)
{
if (udbg_comport) {
while ((real_readb(&udbg_comport->lsr) & LSR_THRE) == 0)
/* wait for idle */;
- real_writeb(c, &udbg_comport->thr); eieio();
+ }
+}
+
+void udbg_maple_real_putc(char c)
+{
+ if (udbg_comport) {
if (c == '\n')
udbg_maple_real_putc('\r');
+ udbg_maple_real_flush();
+ real_writeb(c, &udbg_comport->thr); eieio();
}
}
@@ -165,20 +180,28 @@ void __init udbg_init_maple_realmode(void)
udbg_comport = (struct NS16550 __iomem *)0xf40003f8;
udbg_putc = udbg_maple_real_putc;
+ udbg_flush = udbg_maple_real_flush;
udbg_getc = NULL;
udbg_getc_poll = NULL;
}
#endif /* CONFIG_PPC_MAPLE */
#ifdef CONFIG_PPC_PASEMI
-void udbg_pas_real_putc(char c)
+void udbg_pas_real_flush(void)
{
if (udbg_comport) {
while ((real_205_readb(&udbg_comport->lsr) & LSR_THRE) == 0)
/* wait for idle */;
- real_205_writeb(c, &udbg_comport->thr); eieio();
+ }
+}
+
+void udbg_pas_real_putc(char c)
+{
+ if (udbg_comport) {
if (c == '\n')
udbg_pas_real_putc('\r');
+
Re: [rtc-linux] [PATCH 7/7] powerpc/ps3: Add rtc-ps3
Hi,
On 03/09/2009 07:12 AM, Alessandro Zummo wrote:
> On Mon, 9 Mar 2009 14:26:23 +0100
> Geert Uytterhoeven wrote:
>> +
>> +MODULE_AUTHOR("Sony Corporation");
>
> real name, if possible and a contact address
> here . Just in case I need someone to bother :)
Please look at the MAINTAINERS file, that will give
the contact for PS3. It is much easier to maintain
a single place for the contact than many spread
throughout the kernel sources.
-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
On Mon, 9 Mar 2009 11:04:17 -0700
Geoff Levand wrote:
>
> Hi,
>
> On 03/09/2009 07:12 AM, Alessandro Zummo wrote:
> > On Mon, 9 Mar 2009 14:26:23 +0100
> > Geert Uytterhoeven wrote:
> >> +
> >> +MODULE_AUTHOR("Sony Corporation");
> >
> > real name, if possible and a contact address
> > here . Just in case I need someone to bother :)
>
> Please look at the MAINTAINERS file, that will give
> the contact for PS3. It is much easier to maintain
> a single place for the contact than many spread
> throughout the kernel sources.
Having it in MODULE_AUTHOR allow my scripts to automatically
send an email when appropriate.
MAINTAINERS lists the files with an arbitrary
driver title so that the search must be made by an human and there's
no field that links a person to a specific .c .
so every time I want to address someone I need to check MODULE_AUTHOR,
the git log and the MAINTAINERS file.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
On 03/09/2009 06:26 AM, Geert Uytterhoeven wrote: > Create a real RTC driver for PS3, and unhook the deprecated > ppc_md.[gs]et_rtc_time. > 8 files changed, 132 insertions(+), 18 deletions(-) Sorry, I hadn't been following the discussion closely, but could you explain why we are going from a generic framework where we hook in our platform specific part to a totally independent driver that has such an increase in code size. Why couldn't you fix the generic part so that udev could load it automatically? I much prefer to have this code in the platform support code as it was. It is much more effort (a pain) to maintain a separate driver were I have to cater to a subsystem's maintainer, and with this rtc it seems everyone who was using the generic PPC driver will need to do the same. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
Hi,
On 03/09/2009 11:43 AM, Alessandro Zummo wrote:
> Geoff Levand wrote:
>> On 03/09/2009 07:12 AM, Alessandro Zummo wrote:
>> > On Mon, 9 Mar 2009 14:26:23 +0100
>> > Geert Uytterhoeven wrote:
>> >> +
>> >> +MODULE_AUTHOR("Sony Corporation");
>> >
>> > real name, if possible and a contact address
>> > here . Just in case I need someone to bother :)
>>
>> Please look at the MAINTAINERS file, that will give
>> the contact for PS3. It is much easier to maintain
>> a single place for the contact than many spread
>> throughout the kernel sources.
>
> Having it in MODULE_AUTHOR allow my scripts to automatically
> send an email when appropriate.
>
> MAINTAINERS lists the files with an arbitrary
> driver title so that the search must be made by an human and there's
> no field that links a person to a specific .c .
>
> so every time I want to address someone I need to check MODULE_AUTHOR,
> the git log and the MAINTAINERS file.
I see. It seems what you want is MODULE_MAINTAINER, as author is
the author, who after some time, may not be the maintainer any more.
There was some work by Joe Perches to list the files a maintainer is
responsible for into the MAINTAINERS file. I think that would give
you what you want, a way to automatically get the maintainer of a
file.
Joe, could you let us know the status of that work?
-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
On Mon, 2009-03-09 at 12:06 -0700, Geoff Levand wrote: > There was some work by Joe Perches to list the files a maintainer is > responsible for into the MAINTAINERS file. I think that would give > you what you want, a way to automatically get the maintainer of a > file. > > Joe, could you let us know the status of that work? I think it works fine, and is an acceptable approach to finding a maintainer for either a patch or a specific file. The changes I've posted are probably not suitable for merging by anyone other than Linus as MAINTAINERS is the most heavily modified file in the kernel tree. I've submitted it several times after merging it with the latest kernel without response from Linus. I'd merge and submit it again if it could be accepted. If someone would propose a mechanism that would improve the possibility to get it merged, I'd also appreciate that. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc 4xx: DDR0_14[REDUC] decoded incorrectly
However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus by the kernel code. My understanding is this is not correct - patch attached. You are missing the Signed-off-by tag that is needed. I'm sorry. Signed-off-by: Mikhail Zolotaryov Aside from that, I'm curious if you found this just through inspection, or if you actually had a problem because of it. Your fix seems correct, yet I've had no problems with my boards at all. I'm actually working on custom PowerPC 440EPX board development here and have found the problem: without applying changes described, Linux detects memory size incorrectly and is unable to start. The rest of memory size computation process seems to be correct. I have checked Sequoia evaluation board with U-Boot 2009.1 and confirm that original kernel code reported memory size correctly. So, for my understanding, if computation algorithm was wrong but result was correct - the problem is source data i.e. initial DDR configuration parameters loaded by U-Boot (please don't give a damn that memory size is always reported correctly by U-Boot - it's hard-coded constant there). I have checked Sequoia board schematics (DES0211_11_SCH_11.pdf, page 5, unit U1D) and noted that BankSel#1 is not connected, while bootloader memory configuration is (board/amcc/sequoia/sdram.c): mtsdram(DDR0_10, 0x0300); i.e. both Chip Selects used. If I change this line to: mtsdram(DDR0_10, 0x0100); memory is accessible, patched kernel detects memory size correctly and kernel seems to be working well. Please check my considerations, possibly it may be necessary to request additional information from board manufacturer. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Does DRI/DRM still work on non-coherent DMA platforms?
Hi, I heard rumors that DRI doesn't work on SAM440EP (onboard Radeon GPU) boards. I had DRI halfway working on my AmigaOne (Radeon 9250) with an early release candidate of the 2.6.25 kernel and IIRC this patch here (manually applied): http://kerneltrap.org/index.php?q=mailarchive/git-commits-head/2008/3/30/1301044 I just tested DRI again on my A1 (I don't have a SAM board) with v2.6.29-rc6 and the machine looks up while starting the X server. Curiously DRI seems to work, if I specify "udbg-immortal" on the kernel command line and enable DRM debugging. Did anyone try out DRI on a non-coherent DMA PPC platform and can confirm that it still works? best regards, Gerhard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull mpc52xx-next
> Hey Ben, > > Here are some more for -next. > > The following changes since commit 652e8f8d579d61745094e36b4ff085026a332e73: > Benjamin Herrenschmidt (1): > Merge commit 'jwb/next' into next > > are available in the git repository at: > > git://git.secretlab.ca/git/linux-2.6-mpc52xx next Grant, Can you grab this guy too? http://patchwork.ozlabs.org/patch/24082/ Mikey > > Grant Likely (2): > powerpc/5200: Add 'simple-bus' to the of_platform probe list. > powerpc/4xx: update ml507 .dts file to release reference design > > Grzegorz Bernacki (2): > powerpc/5200: Add digsy-mtc support to mpc5200_defconfig > powerpc/5200: On the digsy-mtc, configure PSC4 and PSC5 as UARTs > > arch/powerpc/boot/dts/digsy_mtc.dts | 12 ++-- > arch/powerpc/boot/dts/virtex440-ml507.dts| 124 +++- -- > arch/powerpc/configs/mpc5200_defconfig | 71 +-- > arch/powerpc/platforms/52xx/mpc52xx_common.c |3 +- > 4 files changed, 184 insertions(+), 26 deletions(-) > > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Does DRI/DRM still work on non-coherent DMA platforms?
On Mon, 2009-03-09 at 22:30 +0100, Gerhard Pircher wrote: > Hi, > > I heard rumors that DRI doesn't work on SAM440EP (onboard Radeon GPU) > boards. I had DRI halfway working on my AmigaOne (Radeon 9250) with an > early release candidate of the 2.6.25 kernel and IIRC this patch here > (manually applied): > http://kerneltrap.org/index.php?q=mailarchive/git-commits-head/2008/3/30/1301044 > > I just tested DRI again on my A1 (I don't have a SAM board) with > v2.6.29-rc6 and the machine looks up while starting the X server. > Curiously DRI seems to work, if I specify "udbg-immortal" on the > kernel command line and enable DRM debugging. > Did anyone try out DRI on a non-coherent DMA PPC platform and can > confirm that it still works? It should work... try using dri-next branch from airlied tree, I had that working on a Canyonlands after DaveM and I fixed a whole bunch of issues. Also make sure you use the latest X side driver too. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Oops with 2.6.29-rc7 on POWER5
I get the following oops on a ppc64 machine using a Fedora rawhide kernel, which is very close to 2.6.29-rc7. It's a POWER5, pSeries CHRP IBM,9123-710. Haven't looked into it just quite yet, but I found it interesting and was wondering if anyone had seen anything like this or could recreate. josh BUG: sleeping function called from invalid context at kernel/mutex.c:207 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper [ cut here ] Badness at kernel/mutex.c:135 NIP: c05fe54c LR: c05fe530 CTR: 0001 REGS: cfffb5b0 TRAP: 0700 Not tainted (2.6.29-0.215.rc7.fc11.ppc64) MSR: 80021032 CR: 2882 XER: 000f TASK = c0f69e90[0] 'swapper' THREAD: c101 CPU: 0 GPR00: cfffb830 c10106b8 0001 GPR04: c0f69e90 0070 0002 GPR08: c179a3b8 c104cb58 c1086a10 GPR12: 003c c1058400 c0006f09b4d0 c0006f09b270 GPR16: c0006f09b408 cfffba60 0001 c0006f09b3c8 GPR20: 0001 c0006e570129 c0006f09b8c0 GPR24: c039d520 c0006f09b248 c0f69e90 GPR28: c0006f09b8c0 c0006f09b8c0 c0fa15c0 cfffb830 NIP [c05fe54c] .mutex_lock_nested+0xc0/0x4b0 LR [c05fe530] .mutex_lock_nested+0xa4/0x4b0 Call Trace: [cfffb830] [c05fe504] .mutex_lock_nested+0x78/0x4b0 (unreliable) [cfffb950] [c039d520] .echo_char_raw+0x40/0x98 [cfffb9f0] [c039fd68] .n_tty_receive_buf+0xb48/0x1104 [cfffbbb0] [c03a3a08] .flush_to_ldisc+0x160/0x244 [cfffbc80] [c03a3b5c] .tty_flip_buffer_push+0x70/0x9c [cfffbd10] [c03b9e94] .hvsi_interrupt+0x464/0x590 [cfffbe50] [c0119168] .handle_IRQ_event+0x60/0xdc [cfffbef0] [c011baf0] .handle_fasteoi_irq+0x108/0x1a8 [cfffbf90] [c002f1c4] .call_handle_irq+0x1c/0x2c [c1013970] [c000e0ac] .do_IRQ+0x144/0x258 [c1013a30] [c0004d28] hardware_interrupt_entry+0x28/0x2c --- Exception: 501 at .raw_local_irq_restore+0xa4/0xc0 LR = .cpu_idle+0x13c/0x1e0 [c1013d20] [c0f9af28] mv88e6131_switch_driver+0x8d08/0x275f8 (unreliable) [c1013dc0] [c0014d34] .cpu_idle+0x13c/0x1e0 [c1013e60] [c06062b8] .rest_init+0x94/0xb0 [c1013ee0] [c088bd08] .start_kernel+0x4a4/0x4c8 [c1013f90] [c0008408] .start_here_common+0x2c/0xa4 Instruction dump: 78290464 80090014 5409012f 41a20028 4bcb199d 6000 2fa3 419e0018 e93e8008 8009 2f80 409e0008 <0fe0> 3800 8b8d01da 980d01da ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull mpc52xx-next
Hey Mikey, On Mon, Mar 9, 2009 at 5:46 PM, Michael Neuling wrote: > Grant, > > Can you grab this guy too? > > http://patchwork.ozlabs.org/patch/24082/ Oops, forgot to email you about this one. I actually wrote another patch the eliminates the sysfs attributes entirely which also eliminates the problem. It will be in my next pull request to Ben (any day now; just waiting for an ack on another patch). g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull mpc52xx-next
> > Grant, > > > > Can you grab this guy too? > > > > http://patchwork.ozlabs.org/patch/24082/ > > Oops, forgot to email you about this one. I actually wrote another > patch the eliminates the sysfs attributes entirely which also > eliminates the problem. It will be in my next pull request to Ben > (any day now; just waiting for an ack on another patch). OK, sounds good. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Oops with 2.6.29-rc7 on POWER5
On Mon, 2009-03-09 at 20:05 -0400, Josh Boyer wrote: > [cfffb830] [c05fe504] .mutex_lock_nested+0x78/0x4b0 > (unreliable) > [cfffb950] [c039d520] .echo_char_raw+0x40/0x98 > [cfffb9f0] [c039fd68] .n_tty_receive_buf+0xb48/0x1104 > [cfffbbb0] [c03a3a08] .flush_to_ldisc+0x160/0x244 > [cfffbc80] [c03a3b5c] .tty_flip_buffer_push+0x70/0x9c > [cfffbd10] [c03b9e94] .hvsi_interrupt+0x464/0x590 > [cfffbe50] [c0119168] .handle_IRQ_event+0x60/0xdc > [cfffbef0] [c011baf0] .handle_fasteoi_irq+0x108/0x1a8 > Do that patch help ? Alan, any comment about the races talked about in those comments ? Are they still something I should worry about ? hvc: Remove tty->low_latency on pseries backends The hvcs and hvsi backends both set tty->low_latency to one, along with more or less scary comments regarding bugs or races that would happen if not doing so. However, they also both call tty_flip_buffer_push() in conexts where it's illegal to do so since some recent tty changes (or at least it may have been illegal always but it nows blows) when low_latency is set (ie, hard interrupt or with spinlock held and irqs disabled). This removes the setting for now to get them back to working condition, we'll have to address the races described in the comments separately if they are still an issue (some of this might have been fixed already). Signed-off-by: Benjamin Herrenschmidt --- Index: linux-work/drivers/char/hvcs.c === --- linux-work.orig/drivers/char/hvcs.c 2009-03-10 11:28:03.0 +1100 +++ linux-work/drivers/char/hvcs.c 2009-03-10 11:28:08.0 +1100 @@ -1139,15 +1139,6 @@ static int hvcs_open(struct tty_struct * hvcsd->tty = tty; tty->driver_data = hvcsd; - /* -* Set this driver to low latency so that we actually have a chance at -* catching a throttled TTY after we flip_buffer_push. Otherwise the -* flush_to_async may not execute until after the kernel_thread has -* yielded and resumed the next flip_buffer_push resulting in data -* loss. -*/ - tty->low_latency = 1; - memset(&hvcsd->buffer[0], 0x00, HVCS_BUFF_LEN); /* Index: linux-work/drivers/char/hvsi.c === --- linux-work.orig/drivers/char/hvsi.c 2009-03-10 11:27:19.0 +1100 +++ linux-work/drivers/char/hvsi.c 2009-03-10 11:27:22.0 +1100 @@ -810,7 +810,6 @@ static int hvsi_open(struct tty_struct * hp = &hvsi_ports[line]; tty->driver_data = hp; - tty->low_latency = 1; /* avoid throttle/tty_flip_buffer_push race */ mb(); if (hp->state == HVSI_FSP_DIED) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO and SPI on CPM2 (8260)?
Hi Sergej, On Fri, Mar 6, 2009 at 9:07 PM, Stepanov, Sergej wrote: > gpio - driver functions pretty well for a pin-setup, but > uninitialized/unexported pins have undefined states -did you achieve this using gpiolib.c? If not, then what files and what kernel are you using? We are trying to get it working for 2.6.27. > I found no spi-support for 8260-based boards with CPM2/1. This is unfortunate. I guess this means SPI on these boards is not used by many engineers... > P.s. Have you seen cpm2-spi-support in u-boot? No, sorry- not in u-boot. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] efp: Fix efp dependence
There is no dependece between efp and math-emu. But when disalbe math-emu, the efp code cannot be built. This patch fixes it. Signed-off-by: Liu Yu --- It would be nice to see this patch go along with 2.6.29 arch/powerpc/Makefile |4 ++-- arch/powerpc/math-emu/Makefile |5 ++--- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 72d17f5..551fc58 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -147,8 +147,8 @@ core-y += arch/powerpc/kernel/ \ arch/powerpc/mm/ \ arch/powerpc/lib/ \ arch/powerpc/sysdev/ \ - arch/powerpc/platforms/ -core-$(CONFIG_MATH_EMULATION) += arch/powerpc/math-emu/ + arch/powerpc/platforms/ \ + arch/powerpc/math-emu/ core-$(CONFIG_XMON)+= arch/powerpc/xmon/ core-$(CONFIG_KVM) += arch/powerpc/kvm/ diff --git a/arch/powerpc/math-emu/Makefile b/arch/powerpc/math-emu/Makefile index f9e506a..0c16ab9 100644 --- a/arch/powerpc/math-emu/Makefile +++ b/arch/powerpc/math-emu/Makefile @@ -1,6 +1,4 @@ -obj-y := math.o fmr.o lfd.o stfd.o - obj-$(CONFIG_MATH_EMULATION) += fabs.o fadd.o fadds.o fcmpo.o fcmpu.o \ fctiw.o fctiwz.o fdiv.o fdivs.o \ fmadd.o fmadds.o fmsub.o fmsubs.o \ @@ -9,7 +7,8 @@ obj-$(CONFIG_MATH_EMULATION)+= fabs.o fadd.o fadds.o fcmpo.o fcmpu.o \ fres.o frsp.o frsqrte.o fsel.o lfs.o \ fsqrt.o fsqrts.o fsub.o fsubs.o \ mcrfs.o mffs.o mtfsb0.o mtfsb1.o \ - mtfsf.o mtfsfi.o stfiwx.o stfs.o + mtfsf.o mtfsfi.o stfiwx.o stfs.o \ + math.o fmr.o lfd.o stfd.o obj-$(CONFIG_SPE) += math_efp.o -- 1.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc 405ex emac1 problem connect to single Giga phy
Hello all：
We use the AMCC PowerPC 405ex through emac1 way RGMII with realtek RTL8211 Giga
phy linked to, At present the PHY Address is: 00110
add delay 2ns for RGMII
CONFIG[8:5]:AUTO_Negotiation
=NWay,advertise ，all capabilities,prefer Slave
mode;1=RGMII mode
Clk on the hardware no problem, Mdio, mdc even on, but at Llinux / driver / net
/ ibm-newemac / core.c discovered phy address, phy ID at .Config file has
joined
NETDEVICE = Y
PHYLIB=Y
REALTEK-PHY=Y
But will be compiled under the best Uimage to board, the feeling of the PHY the
driver has not been mounted use. The following is a kernel information
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 2 TX channels, 2 RX channels
RGMII /plb/opb/emac-rg...@ef600b00 initialized with MDIO support
/plb/opb/emac-rg...@ef600b00: input 0 in RGMII mode
eth0: EMAC-0 /plb/opb/ether...@ef600900, MAC 00:47:41:52:52:59
/plb/opb/emac-rg...@ef600b00: input 1 in RGMII mode
/plb/opb/ether...@ef600a00: find TRL 821X Giga PHY（0x4）
But also in Llinux / driver / net / ibm-newemac / phy.c also add the operation
of RTL8211bg as follows:
#define RTL821x_PHYSR 0x11
#define RTL821x_PHYSR_DUPLEX 0x2000
#define RTL821x_PHYSR_SPEED 0xc000
#define RTL821x_INER 0x12
#define RTL821x_INER_INIT 0x6400
#define RTL821x_INSR 0x13
static int rtl821x_init(struct mii_phy *phy)
{
phy_write(phy, RTL821x_INER, 0x6400); //enable interrupt
return 0;
}
static struct mii_phy_ops rtl821x_phy_ops = {
.init = rtl821x_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 rtl821x_phy_def = {
.phy_id = 0x001cc912, // for rtl8211 single phy
// .phy_id = 0x001cc960, for 8366sr inside phy 4
.phy_id_mask = 0x001f,
.name = "RTL 821X Giga Phy",
.features = PHY_GBIT_FEATURES,
//.flags = PHY_HAS_INTERRUPT,
.ops = &rtl821x_phy_ops
But will be compiled under the best Uimage to board, the feeling of the PHY the
driver has not been mounted use. The following is a kernel information
After IP with a good PC PING board, Return Request Time Out! Troublesome
players you look at what questions are
Connection diagram, see attachment
leowang
2009:03:10
___
好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/
Connection diagram.pdf
Description: Adobe PDF document
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.29-rc7-git2 : crash in kmem_list3_init()
Sachin P. Sant wrote: sure if this is a new problem or a recurring one. Will try booting some older kernels on this box and will report the results. I tried few older kernels till 2.6.28 and all of them had the same problem. I also tried using SLUB instead of SLAB. That also failed to boot with following trace. Unable to handle kernel paging request for data at address 0xc00070001030 Faulting instruction address: 0xc011c7e0 cpu 0x0: Vector: 300 (Data Access) at [c0ac39a0] pc: c011c7e0: .new_slab+0x2b8/0x33c lr: c011c7dc: .new_slab+0x2b4/0x33c sp: c0ac3c20 msr: 80009032 dar: c00070001030 dsisr: 4200 current = 0xc09ea4b0 paca= 0xc0b53480 pid = 0, comm = swapper enter ? for help [c0ac3cc0] c011dc28 .kmem_cache_open+0x1a4/0x448 [c0ac3d90] c011f5dc .create_kmalloc_cache+0x78/0x100 [c0ac3e40] c0948bec .kmem_cache_init+0x8c/0x1c8 [c0ac3ee0] c0920a5c .start_kernel+0x360/0x480 [c0ac3f90] c00083d8 .start_here_common+0x1c/0x44 Complete dmesg log attached. Is there anything else i can try ? Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - boot: Please wait, loading kernel... Allocated 0150 bytes for kernel @ 01c0 Elf64 kernel loaded... Loading ramdisk... ramdisk loaded 004f @ 0570 OF stdout device is: /vdevice/v...@3000 Hypertas detected, assuming LPAR ! command line: root=/dev/sda5 quiet sysrq=1 loglevel=8 mminit_loglevel=4 memory layout at init: alloc_bottom : 05bf alloc_top: 0800 alloc_top_hi : 7200 rmo_top : 0800 ram_top : 7200 Looking for displays instantiating rtas at 0x077c ... done boot cpu hw idx starting cpu hw idx 0002... done starting cpu hw idx 0004... done starting cpu hw idx 0006... done starting cpu hw idx 0008... done starting cpu hw idx 000a... done starting cpu hw idx 000c... done starting cpu hw idx 000e... done starting cpu hw idx 0010... done copying OF device tree ... Building dt strings... Building dt structure... Device tree strings 0x0600 -> 0x060011ed Device tree struct 0x0601 -> 0x0602 Calling quiesce ... returning from prom_init Using pSeries machine description Page orders: linear mapping = 12, virtual = 12, io = 12, vmemmap = 24 Found initrd at 0xc570:0xc5bf console [udbg0] enabled Partition configured for 18 cpus. CPU maps initialized for 2 threads per core (thread shift is 1) Starting Linux PPC64 #5 SMP Tue Mar 10 10:35:45 IST 2009 - ppc64_pft_size= 0x19 physicalMemorySize= 0x7200 htab_hash_mask= 0x3 - Linux version 2.6.29-rc7-git2 (r...@linux-4hy5) (gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) ) #5 SMP Tue Mar 10 10:35:45 IST 2009 [boot]0012 Setup Arch mminit::memory_register Entering add_active_range(1, 0x0, 0x800) 0 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x800, 0xa00) 1 entries of 256 used mminit::memory_register Entering add_active_range(0, 0xa00, 0xc00) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0xc00, 0xe00) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0xe00, 0x1000) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x1000, 0x1200) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x1200, 0x1400) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x1400, 0x1600) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x1600, 0x1800) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x1800, 0x1a00) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x1a00, 0x1c00) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x1c00, 0x1e00) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x1e00, 0x2000) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x2000, 0x2200) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x2200, 0x2400) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x2400, 0x2600) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x2600, 0x2800) 2 entries of 256 used mminit::memory_register Entering add_active_range(0, 0x2800, 0x2a00) 2 entries of 256 used mminit::memory
