RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
Hi Ben, The second issue. you told me some hosts has problem, and some hosts worked well. what is the problem-hosts? The issue seems like the hosts did set the NO SNOOP attribute bit at TLP. The PEX_DEVICE_CONTROL is standard PCI configuration space register, it controls the behavior of the initiator's transaction. For 8315, it is outbound, not inbound transaction. Thanks, Dave From: Ben Menchaca [mailto:ben.mench...@gmail.com] Sent: Saturday, March 07, 2009 12:30 AM To: Liu Dave-R63238 Cc: linuxppc-dev@ozlabs.org Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited Thank you for your help! That bit resolved all of the RDMA/WDMA coherency issues on the CSB side...except: We expose a 1MB region of memory from CSB via a BAR (BAR1, if it matters) to the Host. This region is also not behaving correctly with respect to coherency on SOME hosts; again, disabling our cache makes it work correctly on all hosts. We have set PEX_DEVICE_CONTROL in PCI-E Config Space (0x54) to 0x2010 (sorry about the endianness below). We thought that CLEARING the no-snoop bit here would indicate that snooping was required for this region...is this a similar issue? - Ben On Fri, Mar 6, 2009 at 10:12 AM, Ben Menchaca ben.mench...@gmail.com wrote: Testing now...it looks like it (almost) works, though! Why does setting no-snoop cause snooping to work? More on the effect on setting that bit in a few minutes...need more testing. ACR is 0x00030300. - Ben On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238 dave...@freescale.com wrote: Did you enable the descriptor bit 3 to have a try? From: Ben Menchaca [mailto:ben.mench...@gmail.com] Sent: Friday, March 06, 2009 2:10 PM To: Liu Dave-R63238 Cc: linuxppc-dev@ozlabs.org Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited I can look at ACR morning...although I can say with a fair amount of certainty that I have not changed it from the POR value. I will try enabling No Snoop for CSB in the descriptor (bit 3, yes?)...this seems a bit counterintuitive to me. What is the hope regarding these two? Some combination I am not seeing? On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238 dave...@freescale.com wrote: what is the value of ACR register? From: Ben Menchaca [mailto:ben.mench...@gmail.com] Sent: Friday, March 06, 2009 1:38 PM To: Liu Dave-R63238 Cc: linuxppc-dev@ozlabs.org Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited 1. BAT2 in linux is set to WIMG=0010, and covers all 64M 2. PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020 3. PEX_xDMA_CTRL is set to 0x0401 at the initiation of the DMA. 4. OWAR0 is set to 0xF005, so NSNP is 0. 5. The DMA descriptor (randomly chosen when I hit a trigger...just ignore the size...) contains 0002AFF3 at offset 0, so nosnoops are cleared. Core is 400MHz, and CSB is 133MHz. - Ben On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238 dave...@freescale.com wrote: and what settings is DMA description bit 3? -Original Message- From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+daveliu mailto:linuxppc-dev-bounces%2Bdaveliu =freescale@ozlabs.org]
RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
Hi Ben, The second issue. you told me some hosts has problem, and some hosts worked well. what is the problem-hosts? The issue seems like the hosts did set the NO SNOOP attribute bit at TLP. The PEX_DEVICE_CONTROL is standard PCI configuration space register, it controls the behavior of the initiator's transaction. For 8315, it is outbound, not inbound transaction. Thanks, Dave From: Ben Menchaca [mailto:ben.mench...@gmail.com] Sent: Saturday, March 07, 2009 12:30 AM To: Liu Dave-R63238 Cc: linuxppc-dev@ozlabs.org Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited Thank you for your help! That bit resolved all of the RDMA/WDMA coherency issues on the CSB side...except: We expose a 1MB region of memory from CSB via a BAR (BAR1, if it matters) to the Host. This region is also not behaving correctly with respect to coherency on SOME hosts; again, disabling our cache makes it work correctly on all hosts. We have set PEX_DEVICE_CONTROL in PCI-E Config Space (0x54) to 0x2010 (sorry about the endianness below). We thought that CLEARING the no-snoop bit here would indicate that snooping was required for this region...is this a similar issue? - Ben On Fri, Mar 6, 2009 at 10:12 AM, Ben Menchaca ben.mench...@gmail.com wrote: Testing now...it looks like it (almost) works, though! Why does setting no-snoop cause snooping to work? More on the effect on setting that bit in a few minutes...need more testing. ACR is 0x00030300. - Ben On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238 dave...@freescale.com wrote: Did you enable the descriptor bit 3 to have a try? From: Ben Menchaca [mailto:ben.mench...@gmail.com] Sent: Friday, March 06, 2009 2:10 PM To: Liu Dave-R63238 Cc: linuxppc-dev@ozlabs.org Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited I can look at ACR morning...although I can say with a fair amount of certainty that I have not changed it from the POR value. I will try enabling No Snoop for CSB in the descriptor (bit 3, yes?)...this seems a bit counterintuitive to me. What is the hope regarding these two? Some combination I am not seeing? On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238 dave...@freescale.com wrote: what is the value of ACR register? From: Ben Menchaca [mailto:ben.mench...@gmail.com] Sent: Friday, March 06, 2009 1:38 PM To: Liu Dave-R63238 Cc: linuxppc-dev@ozlabs.org Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited 1. BAT2 in linux is set to WIMG=0010, and covers all 64M 2. PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020 3. PEX_xDMA_CTRL is set to 0x0401 at the initiation of the DMA. 4. OWAR0 is set to 0xF005, so NSNP is 0. 5. The DMA descriptor (randomly chosen when I hit a trigger...just ignore the size...) contains 0002AFF3 at offset 0, so nosnoops are cleared. Core is 400MHz, and CSB is 133MHz. - Ben On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238 dave...@freescale.com wrote: and what settings is DMA description bit 3? -Original Message- From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+daveliu mailto:linuxppc-dev-bounces%2Bdaveliu =freescale@ozlabs.org]
Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
The only problem host found so far is a newer Asus 970FX motherboard, regardless of OS. We are seeing that some time after LTSSM finishes, but long before OS load, our PEX_DEVICE_CONTROL register is changed. On the working motherboards, NO_SNOOP is enabled; if I read the spec correctly, this means that TLPs with no-snoop are permitted. On the non-working motherboards, NO_SNOOP is disabled; this is supposed to mean that TLPs with no-snoop are not permitted (again, if I understand correctly). Is it possible that there has been another misinterpretation of this bit? Something regarding the generation of snoops on CSB when it is cleared? This bit could be a complete red herring; it was one of the few differences in the config space, however, so it was my best guess. - Ben On Sun, Mar 8, 2009 at 9:56 PM, Liu Dave-R63238 dave...@freescale.comwrote: Hi Ben, The second issue. you told me some hosts has problem, and some hosts worked well. what is the problem-hosts? The issue seems like the hosts did set the NO SNOOP attribute bit at TLP. The PEX_DEVICE_CONTROL is standard PCI configuration space register, it controls the behavior of the initiator's transaction. For 8315, it is outbound, not inbound transaction. Thanks, Dave -- *From:* Ben Menchaca [mailto:ben.mench...@gmail.com] *Sent:* Saturday, March 07, 2009 12:30 AM *To:* Liu Dave-R63238 *Cc:* linuxppc-dev@ozlabs.org *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited Thank you for your help! That bit resolved all of the RDMA/WDMA coherency issues on the CSB side...except: We expose a 1MB region of memory from CSB via a BAR (BAR1, if it matters) to the Host. This region is also not behaving correctly with respect to coherency on SOME hosts; again, disabling our cache makes it work correctly on all hosts. We have set PEX_DEVICE_CONTROL in PCI-E Config Space (0x54) to 0x2010 (sorry about the endianness below). We thought that CLEARING the no-snoop bit here would indicate that snooping was required for this region...is this a similar issue? - Ben On Fri, Mar 6, 2009 at 10:12 AM, Ben Menchaca ben.mench...@gmail.comwrote: Testing now...it looks like it (almost) works, though! Why does setting no-snoop cause snooping to work? More on the effect on setting that bit in a few minutes...need more testing. ACR is 0x00030300. - Ben On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238 dave...@freescale.comwrote: Did you enable the descriptor bit 3 to have a try? -- *From:* Ben Menchaca [mailto:ben.mench...@gmail.com] *Sent:* Friday, March 06, 2009 2:10 PM *To:* Liu Dave-R63238 *Cc:* linuxppc-dev@ozlabs.org *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited I can look at ACR morning...although I can say with a fair amount of certainty that I have not changed it from the POR value. I will try enabling No Snoop for CSB in the descriptor (bit 3, yes?)...this seems a bit counterintuitive to me. What is the hope regarding these two? Some combination I am not seeing? On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238 dave...@freescale.comwrote: what is the value of ACR register? -- *From:* Ben Menchaca [mailto:ben.mench...@gmail.com] *Sent:* Friday, March 06, 2009 1:38 PM *To:* Liu Dave-R63238 *Cc:* linuxppc-dev@ozlabs.org *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited 1. BAT2 in linux is set to WIMG=0010, and covers all 64M 2. PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020 3. PEX_xDMA_CTRL is set to 0x0401 at the initiation of the DMA. 4. OWAR0 is set to 0xF005, so NSNP is 0. 5. The DMA descriptor (randomly chosen when I hit a trigger...just ignore the size...) contains 0002AFF3 at offset 0, so nosnoops are cleared. Core is 400MHz, and CSB is 133MHz. - Ben On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238 dave...@freescale.com wrote: and what settings is DMA description bit 3? -Original Message- From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+daveliulinuxppc-dev-bounces%2Bdaveliu =freescale@ozlabs.org] On Behalf Of Liu Dave-R63238 Sent: Friday, March 06, 2009 1:22 PM To: Ben Menchaca; linuxppc-dev@ozlabs.org Subject: RE: 83xx: Marking or Allocating Pages as Cache-Inhibited Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP] and PEX_RDMA_CTRL[SNOOP]? What is the freq settings? CORE/CSB bus. Thanks, Dave From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+daveliulinuxppc-dev-bounces%2Bdaveliu =freescale@ozlabs.org] On Behalf Of Ben Menchaca Sent: Friday, March 06, 2009 12:33 PM To: linuxppc-dev@ozlabs.org Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited I am working on a
fasync (Async Notification)
Hello All, I have mpc8313erdb eval board and kernel 2..6.20 on it. I have written GPIO driver and have enabled Async Notification (SIGIO) In the driver I am generating interrupt whenever the status of GPIO pin (GPIO 2) changes, this part is working correct (as soon as the GPIO pin status changes the interrupt is generated). Then I included Async Notification to notify the particluar user space process (to the process which I want to) by using fasync method, kill_fasync is called in Interrupt handler and also the kill_fasync signals the particular process and the Signal handler executes and says SIGIO is received. But the problem is, if I change GPIO pin status twice then two interrupts are generated but I get SIGIO Async Notification only once. Whereras I am expecting that I should get twice SIGIO Async Notification (Theory says the same). Could anyone please let me what is the reason for this ? ? ? Kindly please acknowledge ... thank you ... Kind Regards, Vijay Nikam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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 EE,ME,CE,IR,DR 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 j...@pengutronix.de 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 geert.uytterhoe...@sonycom.com
---
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 geert.uytterhoe...@sonycom.com
Cc: dann frazier da...@hp.com
---
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 geert.uytterhoe...@sonycom.com --- 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 k...@mcmartin.ca); 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 geert.uytterhoe...@sonycom.com
---
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 linux/string.h
#include linux/mm.h
#include linux/rtc.h
+#include linux/platform_device.h
#include asm/machdep.h
#include asm/io.h
@@ -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 geert.uytterhoe...@sonycom.com
---
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 k...@mcmartin.ca
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/rtc.h
+
+#include asm/rtc.h
+
+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,
+
[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 geert.uytterhoe...@sonycom.com
Cc: David Woodhouse dw...@infradead.org
---
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 dw...@infradead.org
- *
- * 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 linux/module.h
-#include linux/err.h
-#include linux/rtc.h
-#include linux/platform_device.h
-#include asm/machdep.h
-
-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 dw...@infradead.org);
-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 geert.uytterhoe...@sonycom.com
Cc: Geoff Levand geoffrey.lev...@am.sony.com
---
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 linux/kernel.h
+#include linux/platform_device.h
#include asm/rtc.h
#include asm/lv1call.h
@@ -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)
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 geert.uytterhoe...@sonycom.com Acked-By: David Woodhouse david.woodho...@intel.com -- 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 geert.uytterhoe...@sonycom.com 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 geert.uytterhoe...@sonycom.com 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 a.zu...@towertech.it 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 s...@denx.de 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 grant.lik...@secretlab.ca 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 grant.lik...@secretlab.ca Reported-by: Eddie Dawydiuk ed...@embeddedarm.com --- 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 geert.uytterhoe...@sonycom.com 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 geert.uytterhoe...@sonycom.com
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 geert.uytterhoe...@sonycom.com
Acked-by: Alessandro Zummo a.zu...@towertech.it
---
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 linux/kernel.h
+#include linux/platform_device.h
#include asm/rtc.h
#include asm/lv1call.h
@@ -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)
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 ti...@freescale.com --- 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 ti...@freescale.com --- 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 dhowe...@redhat.com
---
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 liming.w...@windriver.com --- 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 w.s...@pengutronix.de
---
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 xiaotian.f...@windriver.com --- 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 martyn.we...@gefanuc.com --- 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 geoffrey.lev...@am.sony.com ___ 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: c0119070: .kmem_list3_init+0x68/0x8c lr: c011906c: .kmem_list3_init+0x64/0x8c sp:
[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 and...@cesa.opbu.xerox.com
---
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 linux/init.h
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 asm/udbg.h
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')
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 geert.uytterhoe...@sonycom.com 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 geoffrey.lev...@am.sony.com wrote: Hi, On 03/09/2009 07:12 AM, Alessandro Zummo wrote: On Mon, 9 Mar 2009 14:26:23 +0100 Geert Uytterhoeven geert.uytterhoe...@sonycom.com 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 geoffrey.lev...@am.sony.com wrote: On 03/09/2009 07:12 AM, Alessandro Zummo wrote: On Mon, 9 Mar 2009 14:26:23 +0100 Geert Uytterhoeven geert.uytterhoe...@sonycom.com 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 le...@lebon.org.ua 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 ME,CE,IR,DR 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 mi...@neuling.org 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 b...@kernel.crashing.org --- 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 sergej.stepa...@ids.de 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 yu@freescale.com --- 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
