[git pull] Please pull powerpc.git merge branch
Hi Linus ! Some of these might have been better in -rc4 or earlier, all my fault for having some backlog that I'm still going through. So we have some bug fixes (not necessarily regressions but also generally simple enough that I decided to go for 2.6.32 anyways) and a few very trivial Kconfig cleanups (outside of arch/powerpc but related to our symbols) from Kumar that could go anytime. The following changes since commit 964fe080d94db82a3268443e9b9ece4c60246414: Linus Torvalds (1): Merge git://git.kernel.org/.../rusty/linux-2.6-for-linus are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Andreas Schwab (2): powerpc: Fix segment mapping in vdso32 powerpc: Align vDSO base address Benjamin Herrenschmidt (1): powerpc/ppc64: Use preempt_schedule_irq instead of preempt_schedule Josh Boyer (1): powerpc/booke: Fix xmon single step on PowerPC Book-E Kumar Gala (7): powerpc: Add a Book-3E 64-bit defconfig powerpc: Fix compile errors found by new ppc64e_defconfig powerpc: Limit hugetlbfs support to PPC64 Book-3S machines powerpc: Limit memory hotplug support to PPC64 Book-3S machines powerpc: Minor cleanup to init/Kconfig powerpc: Minor cleanup to sound/ppc/Kconfig powerpc: Minor cleanup to lib/Kconfig.debug Michael Neuling (1): powerpc/perf_events: Fix priority of MSR HV vs PR bits Stephen Rothwell (1): powerpc/iseries: Remove compiler version dependent hack arch/powerpc/configs/ppc64e_defconfig | 2199 +++ arch/powerpc/kernel/entry_64.S | 41 +- arch/powerpc/kernel/pci_64.c|2 + arch/powerpc/kernel/perf_event.c| 17 +- arch/powerpc/kernel/process.c |2 +- arch/powerpc/kernel/setup_64.c |1 - arch/powerpc/kernel/vdso.c | 11 +- arch/powerpc/kernel/vdso32/vdso32.lds.S |4 +- arch/powerpc/platforms/iseries/Makefile | 11 +- arch/powerpc/platforms/iseries/dt.c | 56 +- arch/powerpc/xmon/xmon.c| 20 +- fs/Kconfig |2 +- init/Kconfig|2 +- lib/Kconfig.debug |2 +- mm/Kconfig |2 +- sound/ppc/Kconfig |2 +- 16 files changed, 2294 insertions(+), 80 deletions(-) create mode 100644 arch/powerpc/configs/ppc64e_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] Fix 8xx MMU/TLB
Benjamin Herrenschmidt wrote on 27/10/2009 01:00:53: > > On Mon, 2009-10-26 at 16:26 -0700, Dan Malek wrote: > > Just be careful the get_user() doesn't regenerate the same > > translation error you are trying to fix by being here.. yes, I had some problems with this initially but managed to work around that. I noticed another problem though, I got multiple TLB errors for the same address when I did it in C. Noticed by just printk:ing every hit for a dcbX insn in do_page_fault. I can't explain it, but it seems like when moving to C you have to execute a rfi insn and that might somehow restart the dcbX insn before moving on to the page fault routine(or something totally different) > > It shouldn't since it will always come up with a proper DAR but > you may want to double check before hand that your instruction > address you are loading from is -not- your marker value for bad DAR. hmm, I check that the insn really is a dcbX insn, but not that the address is != 0x00f0. Don't see how it could be as if something is wrong with the insn address you get ITLB error instead of a DTLB error. Anyhow, things seems stalled as I haven't heard from Scott or Rex for a while. If this isn't working now, I really don't know what is wrong and need some debugging help. > > > It is nice doing things in C code, but you have to be aware > > of the environment and the side effects when in this kind > > Yup. > > Cheers, > Ben. > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Acceleration for map_copy_from on powerpc 512x
The simple_map_init() works at a higher level, what I'm redefining is a function called by mtd->read() The block size for e.g. a dd if=/dev/mtd0 of=/dev/null with the default block size (I believe it's 512Bytes), fetches from /dev/mtd0 4096 Bytes at a time. I'd prefer the kernel to be scheduling other tasks meanwhile, instead of busy-waiting on completion. Regards Kenneth Johansson ha scritto: On Mon, 2009-10-19 at 09:52 +0200, Fortini Matteo wrote: I didn't find a cleaner way than just #ifdef'ing the map_copy_from call and substitute with my call on relevant cases. I wonder if there is a cleaner way. Remove the call to simple_map_init() and do it manually in your driver with your own functions. And yes, as soon as I've cleaned up the code a little bit, I will definitely post a patch about it. Moreover: a huge benefit would come from exploiting DMA on these transfers, probably depends on the block size if it's a gain or not. What is the size you normally see. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Acceleration for map_copy_from on powerpc 512x
On Tue, 2009-10-27 at 11:02 +0100, Fortini Matteo wrote: > The simple_map_init() works at a higher level, what I'm redefining is a > function called by mtd->read() not sure I follow. What you want to do is change the access to the flash. You do this by turning on MTD_COMPLEX_MAPPINGS and then setting up the function pointers like is done in simple_map_init() but point to your own functions. Now every access to the NOR flash will be done using your functions and you can do whatever optimization you like. > The block size for e.g. a dd if=/dev/mtd0 of=/dev/null > with the default block size (I believe it's 512Bytes), fetches from > /dev/mtd0 4096 Bytes at a time. > I'd prefer the kernel to be scheduling other tasks meanwhile, instead of > busy-waiting on completion. > > Regards > > Kenneth Johansson ha scritto: > > On Mon, 2009-10-19 at 09:52 +0200, Fortini Matteo wrote: > > > > > >> I didn't find a cleaner way than just #ifdef'ing the map_copy_from call > >> and substitute with my call on relevant cases. I wonder if there is a > >> cleaner way. > >> > > > > Remove the call to simple_map_init() and do it manually in your driver > > with your own functions. > > > > > >> And yes, as soon as I've cleaned up the code a little bit, I will > >> definitely post a patch about it. > >> > >> Moreover: a huge benefit would come from exploiting DMA on these > >> transfers, > >> > > > > probably depends on the block size if it's a gain or not. What is the > > size you normally see. > > > > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Micrel PHY KSZ8001 on MPC5200B FEC
Hello, We would need some help on how to make a Micrel KSZ8001 work on the MPC5200B FEC using the kernel DENX-v2.6.3[01]. We can already boot the kernel and device tree using TFTP and this PHY using a recent U-Boot version, so we would need some pointers how to acomplish that. Add a proper PHY driver in the drivers/net/phy/ directory? Modify the DTS? If yes, how? A link to some documentation that's not already in the kernel sources would already help. Is it correct, when looking at the sources, that the MPC's FEC driver switched to the generic PHY driver interface? Roman -- Roman FietzeTelemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45http://www.telemotive.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Network Stack SKB Reallocation
Hi Jonathan, I've read your post with great interest. I have a custom board with custom fpga's connected to the PPC405EX EBC bus on banks 2 and 3. Running linux 2.6.29.1. The board collects data and dma's it to a scatter-gather dma buffer and then uses TCP/writev + Ethernet 9KB Jumbo packets to transmit data off of the board. Our systems have 7 of these data collection boards, we are seeing the following stack trace, the boards do not crash apparently the just continue to run. ~ # BUG: Bad page state in process dcb pfn:080db page:c03d2b60 flags:00044000 count:0 mapcount:0 mapping:(null) index:3718 Call Trace: [ce871980] [c0006bc0] show_stack+0x44/0x16c (unreliable) [ce8719c0] [c005374c] bad_page+0x94/0x12c [ce8719e0] [c0053c30] __free_pages_ok+0x364/0x3ec [ce871a20] [c0057c00] put_compound_page+0x48/0x60 [ce871a30] [c0075520] kfree+0xd4/0xd8 [ce871a40] [c0175140] skb_release_data+0x80/0xc8 [ce871a50] [c0174f30] __kfree_skb+0x18/0xe8 [ce871a60] [c01ab9e4] tcp_ack+0x48c/0x1a84 [ce871af0] [c01add8c] tcp_rcv_state_process+0x70/0x9ac [ce871b10] [c01b47fc] tcp_v4_do_rcv+0x9c/0x1a8 [ce871b40] [c01b6328] tcp_v4_rcv+0x4d4/0x5b8 [ce871b70] [c0198b90] ip_local_deliver+0x90/0x140 [ce871b90] [c0198f24] ip_rcv+0x2e4/0x4bc The above occurs on at least one of the seven boards over the course of a multi-day run. Another trace from an actual crash, occurs not so often; DCB: tcp connection request accepted - line length: 18168 Unable to handle kernel paging request for data at address 0x0004009c Faulting instruction address: 0xc017500c Oops: Kernel access of bad area, sig: 11 [#1] DCB Modules linked in: ds3b3 dma ds3b2 NIP: c017500c LR: c01351f8 CTR: c013513c REGS: cd779aa0 TRAP: 0300 Not tainted (2.6.29.1) MSR: 00029030 CR: 42424024 XER: 205f DEAR: 0004009c, ESR: TASK = ce8883f0[770] 'dcb' THREAD: cd778000 GPR00: 0060 cd779b50 ce8883f0 0004 0020 c001220c 0001 0014 GPR08: 0002 0004009c 0003 00c0 22424022 10183238 22f4 0001 GPR16: 0020 22f4 000237c0 cd6590e4 13511000 0008 bfe9d520 GPR24: ce8e2c34 ce8e2c2c ce811ce0 0001 0018 ce811360 0300 ce8113c0 NIP [c017500c] kfree_skb+0xc/0x38 LR [c01351f8] emac_poll_tx+0xbc/0x310 Call Trace: [cd779b50] [c001220c] __mtdcr_table+0x0/0x3ff8 (unreliable) [cd779b70] [c0132248] mal_poll+0x44/0x1c8 [cd779ba0] [c017fb10] net_rx_action+0x94/0x188 [cd779bd0] [c0024740] __do_softirq+0x84/0x124 [cd779c00] [c0004f10] do_softirq+0x58/0x5c [cd779c10] [c00245b0] irq_exit+0x48/0x58 [cd779c20] [c0004fb4] do_IRQ+0xa0/0xc4 [cd779c40] [c000eba0] ret_from_except+0x0/0x18 [cd779d00] [c01a4ec0] tcp_sendmsg+0x220/0xbf0 [cd779d80] [c016dd18] sock_aio_write+0xf0/0x104 [cd779de0] [c007a5b0] do_sync_readv_writev+0xbc/0x130 [cd779e90] [c007ae54] do_readv_writev+0xb4/0x1c4 [cd779f10] [c007b010] sys_writev+0x4c/0x90 [cd779f40] [c000e558] ret_from_syscall+0x0/0x3c Instruction dump: 3d20c02b 80695ac4 7fe4fb78 4bf00fb9 80010014 83e1000c 7c0803a6 38210010 4e800020 2c03 4d820020 3923009c <8003009c> 2f81 409e0008 4b00 Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 1 seconds.. So the questions I have for you are as follows; 1. Do either of these trace appear related to the issue your driver patch will fix? 2. If I set path MTU to 1500, will that avoid the issue? 3. Would you have any further suggestions? thanks -Original Message- From: linuxppc-dev-bounces+john.p.price=l-3com@lists.ozlabs.org [mailto:linuxppc-dev-bounces+john.p.price=l-3com@lists.ozlabs.org] On Behalf Of Jonathan Haws Sent: Monday, October 26, 2009 2:43 PM To: linuxppc-dev@lists.ozlabs.org Subject: Network Stack SKB Reallocation Quick question about the network stack in general: Does the stack itself release an SKB allocated by the device driver back to the heap upstream, or does it require that the device driver handle that? Thanks! Jonathan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Network Stack SKB Reallocation
Hi John, > I have a custom board with custom fpga's connected to the PPC405EX > EBC > bus on banks 2 and 3. Running linux 2.6.29.1. The board collects > data > and dma's it to a scatter-gather dma buffer and then uses TCP/writev > + > Ethernet 9KB Jumbo packets to transmit data off of the board. We are also doing something similar, however we do not transmit the data off the board - we are storing it to disk. What we are seeing is that memory gets so fragmented during normal operation that the EMAC driver cannot find a contiguous block of memory large enough for the MTU (a 9000 byte MTU requires 4 pages of memory, or 16384 bytes). > > Our systems have 7 of these data collection boards, we are seeing > the > following stack trace, the boards do not crash apparently the just > continue to run. > > ~ # BUG: Bad page state in process dcb pfn:080db > page:c03d2b60 flags:00044000 count:0 mapcount:0 mapping:(null) > index:3718 > Call Trace: > [ce871980] [c0006bc0] show_stack+0x44/0x16c (unreliable) > [ce8719c0] [c005374c] bad_page+0x94/0x12c > [ce8719e0] [c0053c30] __free_pages_ok+0x364/0x3ec > [ce871a20] [c0057c00] put_compound_page+0x48/0x60 > [ce871a30] [c0075520] kfree+0xd4/0xd8 > [ce871a40] [c0175140] skb_release_data+0x80/0xc8 > [ce871a50] [c0174f30] __kfree_skb+0x18/0xe8 > [ce871a60] [c01ab9e4] tcp_ack+0x48c/0x1a84 > [ce871af0] [c01add8c] tcp_rcv_state_process+0x70/0x9ac > [ce871b10] [c01b47fc] tcp_v4_do_rcv+0x9c/0x1a8 > [ce871b40] [c01b6328] tcp_v4_rcv+0x4d4/0x5b8 > [ce871b70] [c0198b90] ip_local_deliver+0x90/0x140 > [ce871b90] [c0198f24] ip_rcv+0x2e4/0x4bc > > > The above occurs on at least one of the seven boards over the course > of > a multi-day run. This is very similar output that I would get when memory got fragmented, however my BUG showed its face when I tried to allocate, not to free, so the issue might be somewhere else. > Another trace from an actual crash, occurs not so often; > > DCB: tcp connection request accepted - line length: 18168 > Unable to handle kernel paging request for data at address > 0x0004009c > Faulting instruction address: 0xc017500c > Oops: Kernel access of bad area, sig: 11 [#1] > DCB > Modules linked in: ds3b3 dma ds3b2 > NIP: c017500c LR: c01351f8 CTR: c013513c > REGS: cd779aa0 TRAP: 0300 Not tainted (2.6.29.1) > MSR: 00029030 CR: 42424024 XER: 205f > DEAR: 0004009c, ESR: > TASK = ce8883f0[770] 'dcb' THREAD: cd778000 > GPR00: 0060 cd779b50 ce8883f0 0004 0020 c001220c > 0001 > 0014 > GPR08: 0002 0004009c 0003 00c0 22424022 10183238 > 22f4 > 0001 > GPR16: 0020 22f4 000237c0 cd6590e4 13511000 > 0008 > bfe9d520 > GPR24: ce8e2c34 ce8e2c2c ce811ce0 0001 0018 ce811360 > 0300 > ce8113c0 > NIP [c017500c] kfree_skb+0xc/0x38 > LR [c01351f8] emac_poll_tx+0xbc/0x310 > Call Trace: > [cd779b50] [c001220c] __mtdcr_table+0x0/0x3ff8 (unreliable) > [cd779b70] [c0132248] mal_poll+0x44/0x1c8 > [cd779ba0] [c017fb10] net_rx_action+0x94/0x188 > [cd779bd0] [c0024740] __do_softirq+0x84/0x124 > [cd779c00] [c0004f10] do_softirq+0x58/0x5c > [cd779c10] [c00245b0] irq_exit+0x48/0x58 > [cd779c20] [c0004fb4] do_IRQ+0xa0/0xc4 > [cd779c40] [c000eba0] ret_from_except+0x0/0x18 > [cd779d00] [c01a4ec0] tcp_sendmsg+0x220/0xbf0 > [cd779d80] [c016dd18] sock_aio_write+0xf0/0x104 > [cd779de0] [c007a5b0] do_sync_readv_writev+0xbc/0x130 > [cd779e90] [c007ae54] do_readv_writev+0xb4/0x1c4 > [cd779f10] [c007b010] sys_writev+0x4c/0x90 > [cd779f40] [c000e558] ret_from_syscall+0x0/0x3c > Instruction dump: > 3d20c02b 80695ac4 7fe4fb78 4bf00fb9 80010014 83e1000c 7c0803a6 > 38210010 > 4e800020 2c03 4d820020 3923009c <8003009c> 2f81 409e0008 > 4b00 > Kernel panic - not syncing: Fatal exception in interrupt > Rebooting in 1 seconds.. > > > So the questions I have for you are as follows; > > 1. Do either of these trace appear related to the issue your > driver patch will fix? I don't believe so - especially since I do not have a working patch. I have come to the conclusion that the driver works as is and we are just going to have to deal with the memory fragmentation. > 2. If I set path MTU to 1500, will that avoid the issue? I believe it would, see answer to question 3. > 3. Would you have any further suggestions? The road I believe that we are going to take is move to a 4000 byte MTU. The 405EX MAL has a 4080 byte limit anyway, so keeping the MTU to 4000 bytes guarantees that a whole packet will fit into a single page in memory, so if you are still getting memory errors or problems allocating a new SKB, then you have much bigger issues because either your memory is having problems or you are just plain out of memory completely. The reason we are going that route is because the Linux network stack recycles and frees an SKB that is passed up to it from the driver. So, when I allocated 256 4-page buffers and used those to replace the rx_skb that contained the data, t
[PATCH] Xilinx LL-TEMAC: Add Netpoll controller support
From: Santosh Shukla
Date: Tue, 13 Oct 2009 18:55:57 +0530
Subject: [PATCH] Xilinx LL-TEMAC: Add Netpoll controller support
Adding Netpoll controller support to Xilinx LL-TEMAC ethernet
driver.Replaced Rx, Tx tasklet schedule call with their handlers,
Added correct version of call which can execute interrupt on/off
context i.e. dev_kfree_skb_any().
---
drivers/net/xilinx_lltemac/xlltemac_main.c | 41 +++-
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/drivers/net/xilinx_lltemac/xlltemac_main.c
b/drivers/net/xilinx_lltemac/xlltemac_main.c
index b245422..697f474 100644
--- a/drivers/net/xilinx_lltemac/xlltemac_main.c
+++ b/drivers/net/xilinx_lltemac/xlltemac_main.c
@@ -87,11 +87,18 @@
#define BUFFER_ALIGNSEND_PERF(adr) ((ALIGNMENT_SEND_PERF - ((u32) adr)) % 32)
#define BUFFER_ALIGNRECV(adr) ((ALIGNMENT_RECV - ((u32) adr)) % 32)
+#ifndef CONFIG_NET_POLL_CONTROLLER
/* Default TX/RX Threshold and waitbound values for SGDMA mode */
#define DFT_TX_THRESHOLD 24
#define DFT_TX_WAITBOUND 254
#define DFT_RX_THRESHOLD 4
#define DFT_RX_WAITBOUND 254
+#else
+#define DFT_TX_THRESHOLD 1
+#define DFT_TX_WAITBOUND 0
+#define DFT_RX_THRESHOLD 1
+#define DFT_RX_WAITBOUND 0
+#endif
#define XTE_AUTOSTRIPPING 1
@@ -1097,7 +1104,11 @@ static irqreturn_t xenet_dma_rx_interrupt(int
irq, void *dev_id)
list_add_tail(&lp->rcv, &receivedQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.RxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaRecvBH);
+#else
+ DmaRecvHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&receivedQueueSpin, flags);
}
@@ -1134,7 +1145,11 @@ static irqreturn_t xenet_dma_tx_interrupt(int
irq, void *dev_id)
list_add_tail(&lp->xmit, &sentQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.TxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaSendBH);
+#else
+ DmaSendHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&sentQueueSpin, flags);
}
@@ -1711,11 +1726,15 @@ static int xenet_DmaSend(struct sk_buff *skb,
struct net_device *dev)
* SgAlloc, SgCommit sequence, which also exists in DmaSendHandlerBH
Bottom
* Half, or triggered by other processor in SMP case.
*/
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_lock_bh(&XTE_tx_spinlock);
+#endif
xenet_DmaSend_internal(skb, dev);
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_unlock_bh(&XTE_tx_spinlock);
+#endif
return 0;
}
@@ -1764,7 +1783,7 @@ static void DmaSendHandlerBH(unsigned long p)
skb = (struct sk_buff *)
XLlDma_mBdGetId(BdCurPtr);
if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
/* reset BD id */
XLlDma_mBdSetId(BdCurPtr, NULL);
@@ -3220,6 +3239,23 @@ static int detect_phy(struct net_local *lp,
char *dev_name)
return 0; /* default to zero */
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void
+lltemac_poll_controller(struct net_device *ndev)
+{
+ struct net_local *lp = netdev_priv(ndev);
+
+ disable_irq(lp->dma_irq_s);
+ disable_irq(lp->dma_irq_r);
+
+ xenet_dma_tx_interrupt(lp->dma_irq_s, ndev);
+ xenet_dma_rx_interrupt(lp->dma_irq_r, ndev);
+
+ enable_irq(lp->dma_irq_s);
+ enable_irq(lp->dma_irq_r);
+}
+#endif
+
static struct net_device_ops xilinx_netdev_ops;
/* From include/linux/ethtool.h */
@@ -3491,6 +3527,9 @@ static struct net_device_ops xilinx_netdev_ops = {
.ndo_change_mtu = xenet_change_mtu,
.ndo_tx_timeout = xenet_tx_timeout,
.ndo_get_stats = xenet_get_stats,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = lltemac_poll_controller,
+#endif
};
static struct of_device_id xtenet_fifo_of_match[] = {
--
1.6.3.3.220.g609a0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Low BogoMips
Hi All, my name is Luigi. I'm working on a stripped-down mpc8541 board (that has just a serian and twe enets). I have an issue on delay calibration. In fact my at boot time I see the following on the serial console: Calibrating delay loop... 83.20 BogoMIPS (lpj=166400) This value seems to be too low and I suspect an error propagated from u-boot. Can anyone help me to understand a good way to investigate this problem? which registers or configuration values I need to check? I will post the necessary snips of code or configuration if required. Thanks a lot for your help, ciao luigi -- Luigi 'Comio' Mantellini R&D - Software Industrie Dial Face S.p.A. Via Canzo, 4 20068 Peschiera Borromeo (MI), Italy Tel.: +39 02 5167 2813 Fax: +39 02 5167 2459 Email: luigi.mantell...@idf-hit.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Network Stack SKB Reallocation
Hmmm, so if the issue I see is related to what you see then setting mtu to 4KB may clear it otherwise I have a either a potential race condition freeing skb's or ultimately the protocol stack is not freeing the correct buffer... Thanks Jonathan. -Original Message- From: Jonathan Haws [mailto:jonathan.h...@sdl.usu.edu] Sent: Tuesday, October 27, 2009 10:28 AM To: Price, John @ SDS; linuxppc-dev@lists.ozlabs.org Subject: RE: Network Stack SKB Reallocation Hi John, > I have a custom board with custom fpga's connected to the PPC405EX > EBC > bus on banks 2 and 3. Running linux 2.6.29.1. The board collects > data > and dma's it to a scatter-gather dma buffer and then uses TCP/writev > + > Ethernet 9KB Jumbo packets to transmit data off of the board. We are also doing something similar, however we do not transmit the data off the board - we are storing it to disk. What we are seeing is that memory gets so fragmented during normal operation that the EMAC driver cannot find a contiguous block of memory large enough for the MTU (a 9000 byte MTU requires 4 pages of memory, or 16384 bytes). > > Our systems have 7 of these data collection boards, we are seeing > the > following stack trace, the boards do not crash apparently the just > continue to run. > > ~ # BUG: Bad page state in process dcb pfn:080db > page:c03d2b60 flags:00044000 count:0 mapcount:0 mapping:(null) > index:3718 > Call Trace: > [ce871980] [c0006bc0] show_stack+0x44/0x16c (unreliable) > [ce8719c0] [c005374c] bad_page+0x94/0x12c > [ce8719e0] [c0053c30] __free_pages_ok+0x364/0x3ec > [ce871a20] [c0057c00] put_compound_page+0x48/0x60 > [ce871a30] [c0075520] kfree+0xd4/0xd8 > [ce871a40] [c0175140] skb_release_data+0x80/0xc8 > [ce871a50] [c0174f30] __kfree_skb+0x18/0xe8 > [ce871a60] [c01ab9e4] tcp_ack+0x48c/0x1a84 > [ce871af0] [c01add8c] tcp_rcv_state_process+0x70/0x9ac > [ce871b10] [c01b47fc] tcp_v4_do_rcv+0x9c/0x1a8 > [ce871b40] [c01b6328] tcp_v4_rcv+0x4d4/0x5b8 > [ce871b70] [c0198b90] ip_local_deliver+0x90/0x140 > [ce871b90] [c0198f24] ip_rcv+0x2e4/0x4bc > > > The above occurs on at least one of the seven boards over the course > of > a multi-day run. This is very similar output that I would get when memory got fragmented, however my BUG showed its face when I tried to allocate, not to free, so the issue might be somewhere else. > Another trace from an actual crash, occurs not so often; > > DCB: tcp connection request accepted - line length: 18168 > Unable to handle kernel paging request for data at address > 0x0004009c > Faulting instruction address: 0xc017500c > Oops: Kernel access of bad area, sig: 11 [#1] > DCB > Modules linked in: ds3b3 dma ds3b2 > NIP: c017500c LR: c01351f8 CTR: c013513c > REGS: cd779aa0 TRAP: 0300 Not tainted (2.6.29.1) > MSR: 00029030 CR: 42424024 XER: 205f > DEAR: 0004009c, ESR: > TASK = ce8883f0[770] 'dcb' THREAD: cd778000 > GPR00: 0060 cd779b50 ce8883f0 0004 0020 c001220c > 0001 > 0014 > GPR08: 0002 0004009c 0003 00c0 22424022 10183238 > 22f4 > 0001 > GPR16: 0020 22f4 000237c0 cd6590e4 13511000 > 0008 > bfe9d520 > GPR24: ce8e2c34 ce8e2c2c ce811ce0 0001 0018 ce811360 > 0300 > ce8113c0 > NIP [c017500c] kfree_skb+0xc/0x38 > LR [c01351f8] emac_poll_tx+0xbc/0x310 > Call Trace: > [cd779b50] [c001220c] __mtdcr_table+0x0/0x3ff8 (unreliable) > [cd779b70] [c0132248] mal_poll+0x44/0x1c8 > [cd779ba0] [c017fb10] net_rx_action+0x94/0x188 > [cd779bd0] [c0024740] __do_softirq+0x84/0x124 > [cd779c00] [c0004f10] do_softirq+0x58/0x5c > [cd779c10] [c00245b0] irq_exit+0x48/0x58 > [cd779c20] [c0004fb4] do_IRQ+0xa0/0xc4 > [cd779c40] [c000eba0] ret_from_except+0x0/0x18 > [cd779d00] [c01a4ec0] tcp_sendmsg+0x220/0xbf0 > [cd779d80] [c016dd18] sock_aio_write+0xf0/0x104 > [cd779de0] [c007a5b0] do_sync_readv_writev+0xbc/0x130 > [cd779e90] [c007ae54] do_readv_writev+0xb4/0x1c4 > [cd779f10] [c007b010] sys_writev+0x4c/0x90 > [cd779f40] [c000e558] ret_from_syscall+0x0/0x3c > Instruction dump: > 3d20c02b 80695ac4 7fe4fb78 4bf00fb9 80010014 83e1000c 7c0803a6 > 38210010 > 4e800020 2c03 4d820020 3923009c <8003009c> 2f81 409e0008 > 4b00 > Kernel panic - not syncing: Fatal exception in interrupt > Rebooting in 1 seconds.. > > > So the questions I have for you are as follows; > > 1. Do either of these trace appear related to the issue your > driver patch will fix? I don't believe so - especially since I do not have a working patch. I have come to the conclusion that the driver works as is and we are just going to have to deal with the memory fragmentation. > 2. If I set path MTU to 1500, will that avoid the issue? I believe it would, see answer to question 3. > 3. Would you have any further suggestions? The road I believe that we are going to take is move to a 4000 byte MTU. The 405EX MAL has a 4080 byte limit anyway, so keeping the MTU to 4000 bytes guarantees that a whole packet will fit into a single page in
Re:Micrel PHY KSZ8001 on MPC5200B FEC
Romen, A driver for micrel phy exists in /drivers/net/phy/micrel.c. in 2.6.30. You just need to add the structure with your phy information . If you are using older kernel you may want to copy it. Regards Suvidh -- Message: 6 Date: Tue, 27 Oct 2009 13:17:27 +0100 From: Roman Fietze To: linuxppc-dev@lists.ozlabs.org Subject: Micrel PHY KSZ8001 on MPC5200B FEC Message-ID: <200910271317.28007.roman.fie...@telemotive.de> Content-Type: text/plain; charset="iso-8859-1" Hello, We would need some help on how to make a Micrel KSZ8001 work on the MPC5200B FEC using the kernel DENX-v2.6.3[01]. We can already boot the kernel and device tree using TFTP and this PHY using a recent U-Boot version, so we would need some pointers how to acomplish that. Add a proper PHY driver in the Theirdirectory? Modify the DTS? If yes, how? A link to some documentation that's not already in the kernel sources would already help. Is it correct, when looking at the sources, that the MPC's FEC driver switched to the generic PHY driver interface? Roman -- Roman FietzeTelemotive AG B?ro M?hlhausen Breitwiesen 73347 M?hlhausen Tel.: +49(0)7335/18493-45http://www.telemotive.de -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] Fix 8xx MMU/TLB
On Tue, Oct 27, 2009 at 10:16:17AM +0100, Joakim Tjernlund wrote: > Benjamin Herrenschmidt wrote on 27/10/2009 > 01:00:53: > > > > On Mon, 2009-10-26 at 16:26 -0700, Dan Malek wrote: > > > Just be careful the get_user() doesn't regenerate the same > > > translation error you are trying to fix by being here.. > > yes, I had some problems with this initially but managed to work around > that. I noticed another problem though, I got multiple TLB errors for the > same address when I did it in C. Noticed by just printk:ing every hit for > a dcbX insn in do_page_fault. I can't explain it, but it seems like when > moving to C you have to execute a rfi insn and that might somehow restart > the dcbX insn before moving on to the page fault routine(or something > totally different) The rfi should be to other kernel code -- there is no way that it should be restarting the dcbX (other than when trying to turn a TLB miss into a TLB error). Can you post the C version, maybe we can see what's going wrong? Is the empty TLB entry from the miss getting invalidated in the dcbX fixup case? > > It shouldn't since it will always come up with a proper DAR but > > you may want to double check before hand that your instruction > > address you are loading from is -not- your marker value for bad DAR. > > hmm, I check that the insn really is a dcbX insn, but not that the address is > != 0x00f0. Don't see how it could be as if something is wrong with > the insn address you get ITLB error instead of a DTLB error. I'm guessing he meant the data address you're loading. > Anyhow, things seems stalled as I haven't heard from Scott or Rex for a > while. If this isn't working now, I really don't know what is wrong and > need some debugging help. I'll test the latest version, but I have some scheduling latency. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] Fix 8xx MMU/TLB
Scott Wood wrote on 27/10/2009 16:58:41: > > On Tue, Oct 27, 2009 at 10:16:17AM +0100, Joakim Tjernlund wrote: > > Benjamin Herrenschmidt wrote on 27/10/2009 > > 01:00:53: > > > > > > On Mon, 2009-10-26 at 16:26 -0700, Dan Malek wrote: > > > > Just be careful the get_user() doesn't regenerate the same > > > > translation error you are trying to fix by being here.. > > > > yes, I had some problems with this initially but managed to work around > > that. I noticed another problem though, I got multiple TLB errors for the > > same address when I did it in C. Noticed by just printk:ing every hit for > > a dcbX insn in do_page_fault. I can't explain it, but it seems like when > > moving to C you have to execute a rfi insn and that might somehow restart > > the dcbX insn before moving on to the page fault routine(or something > > totally different) > > The rfi should be to other kernel code -- there is no way that it should be > restarting the dcbX (other than when trying to turn a TLB miss into a TLB > error). Can you post the C version, maybe we can see what's going wrong? I don't have it for 2.6 and I never did cleanup up my 2.4 version. Your best bet is to look at one of the earlier patches such as: Add some debug code to do_page_fault and fix the remaining bits. > Is the empty TLB entry from the miss getting invalidated in the dcbX fixup > case? Yes, in all cases it was invalidated. > > > > It shouldn't since it will always come up with a proper DAR but > > > you may want to double check before hand that your instruction > > > address you are loading from is -not- your marker value for bad DAR. > > > > hmm, I check that the insn really is a dcbX insn, but not that the address > > is > > != 0x00f0. Don't see how it could be as if something is wrong with > > the insn address you get ITLB error instead of a DTLB error. > > I'm guessing he meant the data address you're loading. Hopefully and I am already looking at the OP code to make sure it is a dcbX insn. > > > Anyhow, things seems stalled as I haven't heard from Scott or Rex for a > > while. If this isn't working now, I really don't know what is wrong and > > need some debugging help. > > I'll test the latest version, but I have some scheduling latency. :-) Get yourself a new scheduler :) Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Low BogoMips
Luigi 'Comio' Mantellini wrote: Hi All, my name is Luigi. I'm working on a stripped-down mpc8541 board (that has just a serian and twe enets). I have an issue on delay calibration. In fact my at boot time I see the following on the serial console: Calibrating delay loop... 83.20 BogoMIPS (lpj=166400) This value seems to be too low and I suspect an error propagated from u-boot. Can anyone help me to understand a good way to investigate this problem? which registers or configuration values I need to check? I will post the necessary snips of code or configuration if required. Thanks a lot for your help, On the PowerPC, the BogoMIPS is not an estimate of the performance of the CPU, but rather related to the internal timebase register frequency. "With recent kernels, when build with ARCH=powerpc, we now use the hardware timebase instead of bogus processor loops for short timings. Thus our bogomips value is no longer the speed at which the processor runs empty loops, but the actual processor timebase value as obtained after calibration at boot. " - Benjamin Herrenschmidt Google(powerpc, bogomips, timebase)=happiness -- Jeff Angielski The PTR Group www.theptrgroup.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
help with unhandled IRQ error with mpt2sas driver and powerpc 460EX
Hello, I am using the mpt2sas driver on the canyonlands / 460EX board.
I've already found and fixed one problem, but can't get past the
unhandled IRQ.
The first problem I noticed is that the physical address is read into a
32 bit variable, but the 460ex has a 36 bit bus so the ioremap would
always fail. I've change the defn of chip_phys in mpt2sas_base.h to u64
and that cleared up that issue. As soon as the unmask_interrupts
method is called (or not long after), I get an interrupt -- presumably
from the sas controller. If I comment out the unmask, the interrupt
never occurs. If I unmask them, I get the interrupt. I've traced the
code through the interrupt handler all the way to ~ line 757.
rpf = &ioc->reply_post_free[ioc->reply_post_host_index];
I've verified that at the end of this, IRQ_NONE is returned. At this
point the kernel prints the following -- the last statements lead me to
think that the sas controller expected something but never got it. I am
unsure how to proceed at this point. I am using a denx kernel head
pulled from git today since there were some changes to thsi driver for
endian issues.
irq 18: nobody cared (try booting with the "irqpoll" option)
Call Trace:
[c0367df0] [c0005eac] show_stack+0x44/0x16c (unreliable)
[c0367e30] [c004eedc] __report_bad_irq+0x34/0xb8
[c0367e50] [c004f118] note_interrupt+0x1b8/0x224
[c0367e80] [c004ff50] handle_level_irq+0xa0/0x11c
[c0367e90] [c0018ba4] uic_irq_cascade+0xf8/0x12c
[c0367eb0] [c00041d0] do_IRQ+0x98/0xb4
[c0367ed0] [c000df40] ret_from_except+0x0/0x18
[c0367f90] [c0006ed8] cpu_idle+0x50/0xd8
[c0367fb0] [c000197c] rest_init+0x5c/0x70
[c0367fc0] [c0320848] start_kernel+0x224/0x2a0
[c0367ff0] [c200] skpinv+0x190/0x1cc
handlers:
[] (_base_interrupt+0x0/0x8f8)
Disabling IRQ #18
mpt2sas0: _base_event_notification: timeout
mf:
0700 0f2f3fff fffc
mpt2sas0: sending diag reset !!
mpt2sas0: diag reset: SUCCESS
mpt2sas0: failure at
drivers/scsi/mpt2sas/mpt2sas_scsih.c:5989/_scsih_probe()!
Thanks
Ayman
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull mpc5200 and OF changes
Hey Ben, I don't see these pulled into your tree yet. Can you please this tree into your merge branch? Thanks, g. On Thu, Oct 15, 2009 at 10:46 AM, Grant Likely wrote: > Hi Ben. > > Here are some OF and MPC5200 changes needed for 2.6.32. Mostly > defconfig updates and a couple of new board dts files. > > Cheers, > g. > > The following changes since commit 161291396e76e0832c08f617eb9bd364d1648148: > Linus Torvalds (1): > Linux 2.6.32-rc4 > > are available in the git repository at: > > git://git.secretlab.ca/git/linux-2.6 merge > > Grant Likely (1): > powerpc/5200: Update defconfigs > > Heiko Schocher (2): > mpc5200: support for the MAN mpc5200 based board uc101 > mpc5200: support for the MAN mpc5200 based board mucmc52 > > Julia Lawall (1): > drivers/serial/mpc52xx_uart.c: Use UPIO_MEM rather than SERIAL_IO_MEM > > Jérôme Pouiller (1): > of: Remove nested function > > Wolfram Sang (1): > powerpc/boot/dts: drop obsolete 'fsl5200-clocking' > > arch/powerpc/boot/dts/cm5200.dts | 1 - > arch/powerpc/boot/dts/digsy_mtc.dts | 1 - > arch/powerpc/boot/dts/lite5200.dts | 2 - > arch/powerpc/boot/dts/lite5200b.dts | 2 - > arch/powerpc/boot/dts/media5200.dts | 2 - > arch/powerpc/boot/dts/motionpro.dts | 1 - > arch/powerpc/boot/dts/mpc5121ads.dts | 3 - > arch/powerpc/boot/dts/mucmc52.dts | 332 > + > arch/powerpc/boot/dts/pcm030.dts | 2 - > arch/powerpc/boot/dts/pcm032.dts | 2 - > arch/powerpc/boot/dts/tqm5200.dts | 1 - > arch/powerpc/boot/dts/uc101.dts | 284 + > arch/powerpc/configs/52xx/cm5200_defconfig | 136 ++ > arch/powerpc/configs/52xx/lite5200b_defconfig | 153 > arch/powerpc/configs/52xx/motionpro_defconfig | 146 +++ > arch/powerpc/configs/52xx/pcm030_defconfig | 142 ++- > arch/powerpc/configs/52xx/tqm5200_defconfig | 148 +++ > arch/powerpc/configs/mpc5200_defconfig | 192 ++- > arch/powerpc/platforms/52xx/mpc5200_simple.c | 2 + > drivers/of/of_mdio.c | 13 +- > drivers/serial/mpc52xx_uart.c | 2 +- > 21 files changed, 1196 insertions(+), 371 deletions(-) > create mode 100644 arch/powerpc/boot/dts/mucmc52.dts > create mode 100644 arch/powerpc/boot/dts/uc101.dts > > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Micrel PHY KSZ8001 on MPC5200B FEC
Hello Suvidh, On Tuesday 27 October 2009 17:47:51 suvidh kankariya wrote: > A driver for micrel phy exists in /drivers/net/phy/micrel.c. in > 2.6.30. Am I somewhat blind, or do you have access to other 2.6.30's than I have? I searched git.kernel.org, git.denx.de and git.secretlab.ca, but could not find that file, neither in the current master, nor in older tags somewhat related to "2.6.30", nor in any local clone in any version of the 2.6 since "He" created the repos. > If you are using older kernel you may want to copy it. 2.6.30 and 2.6.31 from DENX or kernel.org. Roman -- Roman FietzeTelemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45http://www.telemotive.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Accessing flash directly from User Space
I know this is probably a really dumb question, but a wise man once said that
the only stupid question is the one that is not asked.
So, I have written a flash driver in VxWorks that simply addresses the flash
directly and handles all the hardware accesses just fine. I am porting that to
Linux and need it to run in user space (mainly to simplify the interface with
the user - I want to keep it the same as in VxWorks). Here is a snippet of
what my question is:
static uint8_t bflashEraseSector(int sa, int verbose)
{
uint16_t * flash = (uint16_t *) NOR_FLASH_BASE_ADRS;
uint32_t offset;
...
/* We divide by 2 here to adjust for the 16-bit offset into the address
*/
offset = sa * NOR_FLASH_SECTOR_SIZE / 2;
flash[BFLASH_SECTOR_ERASE_ADDR1] = BFLASH_SECTOR_ERASE_BYTE1;
...
}
I am trying to get a pointer to NOR_FLASH_BASE_ADRS which is defined to be
0xFC00. I then dereference that directly to write to the flash.
How can I get that pointer? Unfortunately I cannot simply use the address of
the flash. Is there some magical function call that gives me access to that
portion of the memory space?
Thanks for the help!
Jonathan
PS - I know that I could simply use the MTD driver provided by the kernel, but
I need to be able to keep the interface the same so we can use previously
written code.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Micrel PHY KSZ8001 on MPC5200B FEC
On Tue, Oct 27, 2009 at 1:54 PM, Roman Fietze wrote: > Hello Suvidh, > > On Tuesday 27 October 2009 17:47:51 suvidh kankariya wrote: > >> A driver for micrel phy exists in /drivers/net/phy/micrel.c. in >> 2.6.30. > > Am I somewhat blind, or do you have access to other 2.6.30's than I > have? > > I searched git.kernel.org, git.denx.de and git.secretlab.ca, but could > not find that file, neither in the current master, nor in older tags > somewhat related to "2.6.30", nor in any local clone in any version of > the 2.6 since "He" created the repos. No, there is a marvell driver, but not a micrel one. If the generic phy driver doesn't work for you, then yes, add a new micrel driver. To hook it up to the MPC5200 FEC, you just need to have the correct PHY address in your board's .dts file. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space
Jonathan Haws wrote: > > How can I get that pointer? Unfortunately I cannot simply use the address of > the flash. Is there some magical function call that gives me access to that > portion of the memory space? > $ man 2 mmap You want MAP_SHARED and O_SYNC. b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Accessing flash directly from User Space
> > How can I get that pointer? Unfortunately I cannot simply use the > address of the flash. Is there some magical function call that > gives me access to that portion of the memory space? > > > > $ man 2 mmap > > You want MAP_SHARED and O_SYNC. To use that I need to have a file descriptor to a device, do I not? However, I do not have a base flash driver to give me that file descriptor. Am I missing something with that call? Thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space
Jonathan Haws wrote: >>> How can I get that pointer? Unfortunately I cannot simply use the >>> >> address of the flash. Is there some magical function call that >> gives me access to that portion of the memory space? >> >> $ man 2 mmap >> >> You want MAP_SHARED and O_SYNC. >> > > > To use that I need to have a file descriptor to a device, do I not? However, > I do not have a base flash driver to give me that file descriptor. Am I > missing something with that call? > /dev/mem b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Accessing flash directly from User Space
> Jonathan Haws wrote: > >>> How can I get that pointer? Unfortunately I cannot simply use > the > >>> > >> address of the flash. Is there some magical function call that > >> gives me access to that portion of the memory space? > >> > >> $ man 2 mmap > >> > >> You want MAP_SHARED and O_SYNC. > >> > > > > > > To use that I need to have a file descriptor to a device, do I > not? However, I do not have a base flash driver to give me that > file descriptor. Am I missing something with that call? > > > > /dev/mem Ah, yes. I told you this was going to be a dumb question. Thanks, Bill. Jonathan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Accessing flash directly from User Space
> >>> How can I get that pointer? Unfortunately I cannot simply use
> the
> >>>
> >> address of the flash. Is there some magical function call that
> >> gives me access to that portion of the memory space?
> >>
> >> $ man 2 mmap
> >>
> >> You want MAP_SHARED and O_SYNC.
> >>
> >
> >
> > To use that I need to have a file descriptor to a device, do I
> not? However, I do not have a base flash driver to give me that
> file descriptor. Am I missing something with that call?
> >
>
> /dev/mem
>
Okay, I now have access to the flash memory, however when I write to it the
writes do not take. I have tried calling msync() on the mapping to no avail.
I have opened the fd with O_SYNC, but cannot get things to work right.
Here are the calls:
int fd = open("/dev/mem", O_SYNC | O_RDWR);
uint16_t * flash = (uint16_t *)mmap(NULL, NOR_FLASH_SIZE,
(PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
NOR_FLASH_BASE_ADRS);
When I do flash[0] = 0x1234, and then check the value, they do not match.
flash[0] = 0x1234;
msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
printf("flash[0] = %#04x\n", flash[0]);
That prints flash[0] = 0x7f45. I have verified that I am reading the correct
values. I can display the flash contents in U-Boot and 7f45 is what is in the
first 16 bits of flash.
Why can I not write to flash? What am I doing wrong?
Thanks!
Jonathan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space
Jonathan Haws wrote:
Okay, I now have access to the flash memory, however when I write to it the
writes do not take. I have tried calling msync() on the mapping to no avail.
I have opened the fd with O_SYNC, but cannot get things to work right.
Here are the calls:
int fd = open("/dev/mem", O_SYNC | O_RDWR);
uint16_t * flash = (uint16_t *)mmap(NULL, NOR_FLASH_SIZE,
(PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
NOR_FLASH_BASE_ADRS);
When I do flash[0] = 0x1234, and then check the value, they do not match.
flash[0] = 0x1234;
msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
printf("flash[0] = %#04x\n", flash[0]);
That prints flash[0] = 0x7f45. I have verified that I am reading the correct
values. I can display the flash contents in U-Boot and 7f45 is what is in the
first 16 bits of flash.
Why can I not write to flash? What am I doing wrong?
Flash does not work that way -- you must send it commands to erase a
block, and then further commands to program new data.
It sounds like what you really want is the /dev/mtd or /dev/mtdblock
interface, not raw access to the flash chip.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Accessing flash directly from User Space
> > Okay, I now have access to the flash memory, however when I write > to > > it the writes do not take. > > > > (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd, > > MAP_SHARED. Bill told you. With MAP_PRIVATE you write to a local > in-ram copy of the data, not to the original one. I apologize, that MAP_PRIVATE was leftover from me trying to get it to work. With MAP_SHARED I am having the problem. Sorry for the confusion. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Accessing flash directly from User Space
> > Okay, I now have access to the flash memory, however when I write
> to it the writes do not take. I have tried calling msync() on the
> mapping to no avail. I have opened the fd with O_SYNC, but cannot
> get things to work right.
> >
> > Here are the calls:
> >
> > int fd = open("/dev/mem", O_SYNC | O_RDWR);
> > uint16_t * flash = (uint16_t *)mmap(NULL, NOR_FLASH_SIZE,
> > (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
> > NOR_FLASH_BASE_ADRS);
> >
> > When I do flash[0] = 0x1234, and then check the value, they do not
> match.
> >
> > flash[0] = 0x1234;
> > msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
> > printf("flash[0] = %#04x\n", flash[0]);
> >
> > That prints flash[0] = 0x7f45. I have verified that I am reading
> the correct values. I can display the flash contents in U-Boot and
> 7f45 is what is in the first 16 bits of flash.
> >
> > Why can I not write to flash? What am I doing wrong?
>
> Flash does not work that way -- you must send it commands to erase a
> block, and then further commands to program new data.
I realize that. I have a driver written that does exactly that. However, I
need to be able to write to certain registers to setup the erasure. The driver
works perfectly in VxWorks, now I am porting it to Linux.
> It sounds like what you really want is the /dev/mtd or /dev/mtdblock
> interface, not raw access to the flash chip.
As mentioned in my initial post, I need to use my custom driver to maintain the
interface to the application that uses the flash for data storage.
I had thought about using MTD, but decided against it because with previous
benchmarking that we did with MTD and our custom driver, we found that our
custom driver was about 10x faster.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space
> Okay, I now have access to the flash memory, however when I write to > it the writes do not take. > (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd, MAP_SHARED. Bill told you. With MAP_PRIVATE you write to a local in-ram copy of the data, not to the original one. /alessandro ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space
Jonathan Haws wrote:
flash[0] = 0x1234;
msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
printf("flash[0] = %#04x\n", flash[0]);
That prints flash[0] = 0x7f45. I have verified that I am reading
the correct values. I can display the flash contents in U-Boot and
7f45 is what is in the first 16 bits of flash.
Why can I not write to flash? What am I doing wrong?
Flash does not work that way -- you must send it commands to erase a
block, and then further commands to program new data.
I realize that. I have a driver written that does exactly that.
However, I need to be able to write to certain registers to setup the
erasure.
Will the device respond to 0x1234 being written at offset zero? You
generally have to poke these things pretty specifically in order to get
them to go into command mode.
The driver works perfectly in VxWorks,
Including the 0x1234 thing?
It sounds like what you really want is the /dev/mtd or /dev/mtdblock
interface, not raw access to the flash chip.
As mentioned in my initial post, I need to use my custom driver to maintain the
interface to the application that uses the flash for data storage.
I had thought about using MTD, but decided against it because with
previous benchmarking that we did with MTD and our custom driver, we
found that our custom driver was about 10x faster.
Ouch. Any idea where the slowdown is coming from?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space
> I realize that. I have a driver written that does exactly that. > However, I need to be able to write to certain registers to setup > the erasure. The driver works perfectly in VxWorks, now I am > porting it to Linux. Most likey you are hit by the compiler reordering the accesses and caching data in registers. You should try to use volatile pointers (but also read the "volatile considered harmful" file in the kernel sources -- anyways you are doing bad things nonetheless), or add memory barriers (copy the mb() and wmb() macros defined for kernel space). Then, the first-word-access you show is wrong, as Scott Wood told you, so the fact that _that_ access is not working even across msync that's another matter. I usually have no serious problems with driving hardware from /dev/mem, although I've never done flash specifically as mtd is there. hope this helps /alessandro ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Accessing flash directly from User Space
> Jonathan Haws wrote:
> >>> flash[0] = 0x1234;
> >>> msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
> >>> printf("flash[0] = %#04x\n", flash[0]);
> >>>
> >>> That prints flash[0] = 0x7f45. I have verified that I am
> reading
> >> the correct values. I can display the flash contents in U-Boot
> and
> >> 7f45 is what is in the first 16 bits of flash.
> >>> Why can I not write to flash? What am I doing wrong?
> >> Flash does not work that way -- you must send it commands to
> erase a
> >> block, and then further commands to program new data.
> >
> > I realize that. I have a driver written that does exactly that.
> > However, I need to be able to write to certain registers to setup
> the
> > erasure.
>
> Will the device respond to 0x1234 being written at offset zero? You
> generally have to poke these things pretty specifically in order to
> get
> them to go into command mode.
>
It should because that is the first data location in flash. Also, just to be
sure I am telling the truth, I tried writing to one of the registers to setup
an erase and got the same results - the value did not get written.
> > The driver works perfectly in VxWorks,
>
> Including the 0x1234 thing?
Actually, I have not tried that - I have not had to since the driver worked.
> >> It sounds like what you really want is the /dev/mtd or
> /dev/mtdblock
> >> interface, not raw access to the flash chip.
> >
> > As mentioned in my initial post, I need to use my custom driver to
> maintain the interface to the application that uses the flash for
> data storage.
> >
> > I had thought about using MTD, but decided against it because with
> > previous benchmarking that we did with MTD and our custom driver,
> we
> > found that our custom driver was about 10x faster.
>
> Ouch. Any idea where the slowdown is coming from?
>From what I remember (I would have to dig up notes to make sure) it is
>something to do with MTD looking for a signal to go high that is processed a
>bunch before MTD even sees it. Our flash produces a hardware ready signal
>that we are triggering off of to move on. MTD took much longer to report to
>us that the hardware was ready.
Thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Tue, 2009-10-27 at 18:11 +1100, Benjamin Herrenschmidt wrote: > Hi Linus ! > > Some of these might have been better in -rc4 or earlier, all my fault > for having some backlog that I'm still going through. So we have some > bug fixes (not necessarily regressions but also generally simple > enough that I decided to go for 2.6.32 anyways) and a few very trivial > Kconfig cleanups (outside of arch/powerpc but related to our symbols) > from Kumar that could go anytime. I also had a pending pull request from Grant that I had forgotten. I added that, it's also minor stuff (device-tree and defconfig updates mostly and a couple of bug fixes). New consolidated pull request below. Cheers, Ben. The following changes since commit 964fe080d94db82a3268443e9b9ece4c60246414: Linus Torvalds (1): Merge git://git.kernel.org/.../rusty/linux-2.6-for-linus are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Andreas Schwab (2): powerpc: Fix segment mapping in vdso32 powerpc: Align vDSO base address Benjamin Herrenschmidt (2): powerpc/ppc64: Use preempt_schedule_irq instead of preempt_schedule Merge commit 'gcl/merge' into merge Grant Likely (1): powerpc/5200: Update defconfigs Heiko Schocher (2): mpc5200: support for the MAN mpc5200 based board uc101 mpc5200: support for the MAN mpc5200 based board mucmc52 Josh Boyer (1): powerpc/booke: Fix xmon single step on PowerPC Book-E Julia Lawall (1): drivers/serial/mpc52xx_uart.c: Use UPIO_MEM rather than SERIAL_IO_MEM Jérôme Pouiller (1): of: Remove nested function Kumar Gala (7): powerpc: Add a Book-3E 64-bit defconfig powerpc: Fix compile errors found by new ppc64e_defconfig powerpc: Limit hugetlbfs support to PPC64 Book-3S machines powerpc: Limit memory hotplug support to PPC64 Book-3S machines powerpc: Minor cleanup to init/Kconfig powerpc: Minor cleanup to sound/ppc/Kconfig powerpc: Minor cleanup to lib/Kconfig.debug Michael Neuling (1): powerpc/perf_events: Fix priority of MSR HV vs PR bits Stephen Rothwell (1): powerpc/iseries: Remove compiler version dependent hack Wolfram Sang (1): powerpc/boot/dts: drop obsolete 'fsl5200-clocking' arch/powerpc/boot/dts/cm5200.dts |1 - arch/powerpc/boot/dts/digsy_mtc.dts |1 - arch/powerpc/boot/dts/lite5200.dts|2 - arch/powerpc/boot/dts/lite5200b.dts |2 - arch/powerpc/boot/dts/media5200.dts |2 - arch/powerpc/boot/dts/motionpro.dts |1 - arch/powerpc/boot/dts/mpc5121ads.dts |3 - arch/powerpc/boot/dts/mucmc52.dts | 332 arch/powerpc/boot/dts/pcm030.dts |2 - arch/powerpc/boot/dts/pcm032.dts |2 - arch/powerpc/boot/dts/tqm5200.dts |1 - arch/powerpc/boot/dts/uc101.dts | 284 arch/powerpc/configs/52xx/cm5200_defconfig| 136 +- arch/powerpc/configs/52xx/lite5200b_defconfig | 153 ++- arch/powerpc/configs/52xx/motionpro_defconfig | 146 +- arch/powerpc/configs/52xx/pcm030_defconfig| 142 +- arch/powerpc/configs/52xx/tqm5200_defconfig | 148 +- arch/powerpc/configs/mpc5200_defconfig| 192 ++- arch/powerpc/configs/ppc64e_defconfig | 2199 + arch/powerpc/kernel/entry_64.S| 41 +- arch/powerpc/kernel/pci_64.c |2 + arch/powerpc/kernel/perf_event.c | 17 +- arch/powerpc/kernel/process.c |2 +- arch/powerpc/kernel/setup_64.c|1 - arch/powerpc/kernel/vdso.c| 11 +- arch/powerpc/kernel/vdso32/vdso32.lds.S |4 +- arch/powerpc/platforms/52xx/mpc5200_simple.c |2 + arch/powerpc/platforms/iseries/Makefile | 11 +- arch/powerpc/platforms/iseries/dt.c | 56 +- arch/powerpc/xmon/xmon.c | 20 +- drivers/of/of_mdio.c | 13 +- drivers/serial/mpc52xx_uart.c |2 +- fs/Kconfig|2 +- init/Kconfig |2 +- lib/Kconfig.debug |2 +- mm/Kconfig|2 +- sound/ppc/Kconfig |2 +- 37 files changed, 3490 insertions(+), 451 deletions(-) create mode 100644 arch/powerpc/boot/dts/mucmc52.dts create mode 100644 arch/powerpc/boot/dts/uc101.dts create mode 100644 arch/powerpc/configs/ppc64e_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Is there a patch for MPC8548 XOR?
On Tue, 27 Oct 2009 11:43:34 +0800 hank peng wrote: > I want to use its' XOR engine to compute raid5 parity, but I can't > find this function in 2.6.30 downloaded from kernel.org, someone know > if there is a patch? try this: http://patchwork.ozlabs.org/patch/36067/ Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] powerpc: tracing: Add powerpc tracepoints for interrupt entry and exit
I have no problem with any of these changes. I guess this is up to Ben and company to decide the rest. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] powerpc: tracing: Add powerpc tracepoints for interrupt entry and exit
On Tue, 2009-10-27 at 18:00 -0400, Steven Rostedt wrote: > I have no problem with any of these changes. I guess this is up to Ben > and company to decide the rest. I'll stick them into my -next branch, hopefully today or tomorrow. The ppc "perf_events" specific bits are going to go via paulus first. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: help with unhandled IRQ error with mpt2sas driver and powerpc 460EX
On Tue, 2009-10-27 at 12:27 -0500, Ayman El-Khashab wrote: > > The first problem I noticed is that the physical address is read into a > 32 bit variable, but the 460ex has a 36 bit bus so the ioremap would > always fail. I've change the defn of chip_phys in mpt2sas_base.h to u64 > and that cleared up that issue. That looks indeed like a common driver bug. Please make sure you submit the fix upstream. The "right" type to use is resource_size_t in fact. >As soon as the unmask_interrupts > method is called (or not long after), What exactly is that "method" ? IE. A driver function that enables emission of interrupts on the device ? > I get an interrupt -- presumably > from the sas controller. If I comment out the unmask, the interrupt > never occurs. If I unmask them, I get the interrupt. I've traced the > code through the interrupt handler all the way to ~ line 757. Unmask at what level ? The linux level (enable_irq() -> UIC unmask) or the card level ? > rpf = &ioc->reply_post_free[ioc->reply_post_host_index]; > > I've verified that at the end of this, IRQ_NONE is returned. At this > point the kernel prints the following -- the last statements lead me to > think that the sas controller expected something but never got it. I am > unsure how to proceed at this point. I am using a denx kernel head > pulled from git today since there were some changes to thsi driver for > endian issues. Well, if the interrupt is indeed coming from the card and the driver's interrupt handler can't figure it out, then you are facing a bug in the driver. I would recommend you work with whoever is maintaining that driver to help sort it out. Cheers, Ben. > irq 18: nobody cared (try booting with the "irqpoll" option) > Call Trace: > [c0367df0] [c0005eac] show_stack+0x44/0x16c (unreliable) > [c0367e30] [c004eedc] __report_bad_irq+0x34/0xb8 > [c0367e50] [c004f118] note_interrupt+0x1b8/0x224 > [c0367e80] [c004ff50] handle_level_irq+0xa0/0x11c > [c0367e90] [c0018ba4] uic_irq_cascade+0xf8/0x12c > [c0367eb0] [c00041d0] do_IRQ+0x98/0xb4 > [c0367ed0] [c000df40] ret_from_except+0x0/0x18 > [c0367f90] [c0006ed8] cpu_idle+0x50/0xd8 > [c0367fb0] [c000197c] rest_init+0x5c/0x70 > [c0367fc0] [c0320848] start_kernel+0x224/0x2a0 > [c0367ff0] [c200] skpinv+0x190/0x1cc > handlers: > [] (_base_interrupt+0x0/0x8f8) > Disabling IRQ #18 > mpt2sas0: _base_event_notification: timeout > mf: > 0700 0f2f3fff fffc > > > mpt2sas0: sending diag reset !! > mpt2sas0: diag reset: SUCCESS > mpt2sas0: failure at > drivers/scsi/mpt2sas/mpt2sas_scsih.c:5989/_scsih_probe()! > > Thanks > Ayman > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Is there a patch for MPC8548 XOR?
2009/10/28 Kim Phillips : > On Tue, 27 Oct 2009 11:43:34 +0800 > hank peng wrote: > >> I want to use its' XOR engine to compute raid5 parity, but I can't >> find this function in 2.6.30 downloaded from kernel.org, someone know >> if there is a patch? > > try this: > > http://patchwork.ozlabs.org/patch/36067/ > Thanks, but I have three questions: 1. Will the patch be added to kernel in the future? 2. If I have problem in using this patch, will you or other guys help me to fix it? 3. Is this patch based on 2.6.30, because we are using this version of kernel. > Kim > -- The simplest is not all best but the best is surely the simplest! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the sh tree with the powerpc-merge tree
Hi Paul,
Today's linux-next merge of the sh tree got a conflict in fs/Kconfig
between commit 0cd9ad73b8d181737005ff4e506b9b6bd043f4dd ("powerpc: Limit
hugetlbfs support to PPC64 Book-3S machines") from the powerpc-merge tree
and commit ffb4a73d8906f71910e6c83ec2b499e70025ee8e ("sh: Fix hugetlbfs
dependencies for SH-3 && MMU configurations") from the sh tree.
I fixed it up (see below) and can carry the fix for a while (the
powerpc-merge commit should be in Linus' tree soon).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/Kconfig
index f93d0ed,48b81f9..000
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@@ -135,8 -135,8 +135,8 @@@ config TMPFS_POSIX_AC
config HUGETLBFS
bool "HugeTLB file system support"
- depends on X86 || IA64 || PPC_BOOK3S_64 || SPARC64 || (SUPERH && MMU)
|| \
- depends on X86 || IA64 || PPC64 || SPARC64 || (S390 && 64BIT) || \
- SYS_SUPPORTS_HUGETLBFS || BROKEN
++ depends on X86 || IA64 || PPC_BOOK3S_64 || SPARC64 || \
+ (S390 && 64BIT) || SYS_SUPPORTS_HUGETLBFS || BROKEN
help
hugetlbfs is a filesystem backing for HugeTLB pages, based on
ramfs. For architectures that support it, say Y here and read
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Xilinx LL-TEMAC: Add Netpoll controller support
From: Santosh Shukla
Date: Tue, 13 Oct 2009 18:55:57 +0530
Subject: [PATCH] Xilinx LL-TEMAC: Add Netpoll controller support
Adding Netpoll controller support to Xilinx LL-TEMAC ethernet
driver.Replaced Rx, Tx tasklet schedule call with their handlers,
Added correct version of call which can execute interrupt on/off
context i.e. dev_kfree_skb_any().
---
drivers/net/xilinx_lltemac/xlltemac_main.c | 41 +++-
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/drivers/net/xilinx_lltemac/xlltemac_main.c
b/drivers/net/xilinx_lltemac/xlltemac_main.c
index b245422..697f474 100644
--- a/drivers/net/xilinx_lltemac/xlltemac_main.c
+++ b/drivers/net/xilinx_lltemac/xlltemac_main.c
@@ -87,11 +87,18 @@
#define BUFFER_ALIGNSEND_PERF(adr) ((ALIGNMENT_SEND_PERF - ((u32) adr)) % 32)
#define BUFFER_ALIGNRECV(adr) ((ALIGNMENT_RECV - ((u32) adr)) % 32)
+#ifndef CONFIG_NET_POLL_CONTROLLER
/* Default TX/RX Threshold and waitbound values for SGDMA mode */
#define DFT_TX_THRESHOLD 24
#define DFT_TX_WAITBOUND 254
#define DFT_RX_THRESHOLD 4
#define DFT_RX_WAITBOUND 254
+#else
+#define DFT_TX_THRESHOLD 1
+#define DFT_TX_WAITBOUND 0
+#define DFT_RX_THRESHOLD 1
+#define DFT_RX_WAITBOUND 0
+#endif
#define XTE_AUTOSTRIPPING 1
@@ -1097,7 +1104,11 @@ static irqreturn_t xenet_dma_rx_interrupt(int irq, void
*dev_id)
list_add_tail(&lp->rcv, &receivedQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.RxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaRecvBH);
+#else
+ DmaRecvHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&receivedQueueSpin, flags);
}
@@ -1134,7 +1145,11 @@ static irqreturn_t xenet_dma_tx_interrupt(int irq, void
*dev_id)
list_add_tail(&lp->xmit, &sentQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.TxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaSendBH);
+#else
+ DmaSendHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&sentQueueSpin, flags);
}
@@ -1711,11 +1726,15 @@ static int xenet_DmaSend(struct sk_buff *skb, struct
net_device *dev)
* SgAlloc, SgCommit sequence, which also exists in DmaSendHandlerBH
Bottom
* Half, or triggered by other processor in SMP case.
*/
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_lock_bh(&XTE_tx_spinlock);
+#endif
xenet_DmaSend_internal(skb, dev);
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_unlock_bh(&XTE_tx_spinlock);
+#endif
return 0;
}
@@ -1764,7 +1783,7 @@ static void DmaSendHandlerBH(unsigned long p)
skb = (struct sk_buff *)
XLlDma_mBdGetId(BdCurPtr);
if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
/* reset BD id */
XLlDma_mBdSetId(BdCurPtr, NULL);
@@ -3220,6 +3239,23 @@ static int detect_phy(struct net_local *lp, char
*dev_name)
return 0; /* default to zero */
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void
+lltemac_poll_controller(struct net_device *ndev)
+{
+ struct net_local *lp = netdev_priv(ndev);
+
+ disable_irq(lp->dma_irq_s);
+ disable_irq(lp->dma_irq_r);
+
+ xenet_dma_tx_interrupt(lp->dma_irq_s, ndev);
+ xenet_dma_rx_interrupt(lp->dma_irq_r, ndev);
+
+ enable_irq(lp->dma_irq_s);
+ enable_irq(lp->dma_irq_r);
+}
+#endif
+
static struct net_device_ops xilinx_netdev_ops;
/* From include/linux/ethtool.h */
@@ -3491,6 +3527,9 @@ static struct net_device_ops xilinx_netdev_ops = {
.ndo_change_mtu = xenet_change_mtu,
.ndo_tx_timeout = xenet_tx_timeout,
.ndo_get_stats = xenet_get_stats,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = lltemac_poll_controller,
+#endif
};
static struct of_device_id xtenet_fifo_of_match[] = {
--
1.6.3.3.220.g609a0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/perf_counter: Enable SDAR in continous sample mode
In continuous sampling mode we want the SDAR to update. While we can
select between dcache misses and erat misses, a decent default is to
enable both.
Signed-off-by: Anton Blanchard
---
Moved MMCRA definitions into asm/reg.h.
Index: linux.trees.git/arch/powerpc/kernel/power7-pmu.c
===
--- linux.trees.git.orig/arch/powerpc/kernel/power7-pmu.c 2009-10-28
14:02:08.0 +1100
+++ linux.trees.git/arch/powerpc/kernel/power7-pmu.c2009-10-28
14:03:04.0 +1100
@@ -51,10 +51,6 @@
#define MMCR1_PMCSEL_MSK 0xff
/*
- * Bits in MMCRA
- */
-
-/*
* Layout of constraint bits:
* 554433221100
* 3210987654321098765432109876543210987654321098765432109876543210
@@ -230,7 +226,7 @@ static int power7_compute_mmcr(u64 event
unsigned int hwc[], unsigned long mmcr[])
{
unsigned long mmcr1 = 0;
- unsigned long mmcra = 0;
+ unsigned long mmcra = MMCRA_SDAR_DCACHE_MISS | MMCRA_SDAR_ERAT_MISS;
unsigned int pmc, unit, combine, l2sel, psel;
unsigned int pmc_inuse = 0;
int i;
Index: linux.trees.git/arch/powerpc/kernel/power5-pmu.c
===
--- linux.trees.git.orig/arch/powerpc/kernel/power5-pmu.c 2009-10-28
14:02:08.0 +1100
+++ linux.trees.git/arch/powerpc/kernel/power5-pmu.c2009-10-28
14:03:04.0 +1100
@@ -73,10 +73,6 @@
#define MMCR1_PMCSEL_MSK 0x7f
/*
- * Bits in MMCRA
- */
-
-/*
* Layout of constraint bits:
* 554433221100
* 3210987654321098765432109876543210987654321098765432109876543210
@@ -390,7 +386,7 @@ static int power5_compute_mmcr(u64 event
unsigned int hwc[], unsigned long mmcr[])
{
unsigned long mmcr1 = 0;
- unsigned long mmcra = 0;
+ unsigned long mmcra = MMCRA_SDAR_DCACHE_MISS | MMCRA_SDAR_ERAT_MISS;
unsigned int pmc, unit, byte, psel;
unsigned int ttm, grp;
int i, isbus, bit, grsel;
Index: linux.trees.git/arch/powerpc/kernel/power6-pmu.c
===
--- linux.trees.git.orig/arch/powerpc/kernel/power6-pmu.c 2009-10-28
14:02:08.0 +1100
+++ linux.trees.git/arch/powerpc/kernel/power6-pmu.c2009-10-28
14:03:04.0 +1100
@@ -178,7 +178,7 @@ static int p6_compute_mmcr(u64 event[],
unsigned int hwc[], unsigned long mmcr[])
{
unsigned long mmcr1 = 0;
- unsigned long mmcra = 0;
+ unsigned long mmcra = MMCRA_SDAR_DCACHE_MISS | MMCRA_SDAR_ERAT_MISS;
int i;
unsigned int pmc, ev, b, u, s, psel;
unsigned int ttmset = 0;
Index: linux.trees.git/arch/powerpc/include/asm/reg.h
===
--- linux.trees.git.orig/arch/powerpc/include/asm/reg.h 2009-10-28
14:02:08.0 +1100
+++ linux.trees.git/arch/powerpc/include/asm/reg.h 2009-10-28
14:03:33.0 +1100
@@ -489,6 +489,8 @@
#define SPRN_MMCR1 798
#define SPRN_MMCRA 0x312
#define MMCRA_SDSYNC 0x8000UL /* SDAR synced with SIAR */
+#define MMCRA_SDAR_DCACHE_MISS 0x4000UL
+#define MMCRA_SDAR_ERAT_MISS 0x2000UL
#define MMCRA_SIHV 0x1000UL /* state of MSR HV when SIAR set */
#define MMCRA_SIPR 0x0800UL /* state of MSR PR when SIAR set */
#define MMCRA_SLOT 0x0700UL /* SLOT bits (37-39) */
Index: linux.trees.git/arch/powerpc/kernel/power5+-pmu.c
===
--- linux.trees.git.orig/arch/powerpc/kernel/power5+-pmu.c 2009-10-28
14:03:57.0 +1100
+++ linux.trees.git/arch/powerpc/kernel/power5+-pmu.c 2009-10-28
14:03:58.0 +1100
@@ -73,10 +73,6 @@
#define MMCR1_PMCSEL_MSK 0x7f
/*
- * Bits in MMCRA
- */
-
-/*
* Layout of constraint bits:
* 554433221100
* 3210987654321098765432109876543210987654321098765432109876543210
Index: linux.trees.git/arch/powerpc/kernel/ppc970-pmu.c
===
--- linux.trees.git.orig/arch/powerpc/kernel/ppc970-pmu.c 2009-10-28
14:03:57.0 +1100
+++ linux.trees.git/arch/powerpc/kernel/ppc970-pmu.c2009-10-28
14:03:58.0 +1100
@@ -84,10 +84,6 @@ static short mmcr1_adder_bits[8] = {
};
/*
- * Bits in MMCRA
- */
-
-/*
* Layout of constraint bits:
* 554433221100
* 3210987654321098765432109876543210987654321098765432109876543210
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: Create PPC_WARN_ALIGNMENT to match PPC_WARN_EMULATED
Hi Stephen,
> I think this last line is not needed?
Right you are!
Anton
--
perf_event wants a separate event for alignment and emulation faults,
so create another emulation event. This will make it easy to hook in
perf_event at one spot.
We pass in regs which will be required for these events.
Signed-off-by: Anton Blanchard
---
Updated to remove unused define, as suggested by Stephen.
Index: linux.trees.git/arch/powerpc/include/asm/emulated_ops.h
===
--- linux.trees.git.orig/arch/powerpc/include/asm/emulated_ops.h
2009-10-19 09:46:58.0 +1100
+++ linux.trees.git/arch/powerpc/include/asm/emulated_ops.h 2009-10-21
14:57:00.0 +1100
@@ -57,7 +57,7 @@ extern u32 ppc_warn_emulated;
extern void ppc_warn_emulated_print(const char *type);
-#define PPC_WARN_EMULATED(type)
\
+#define __PPC_WARN_EMULATED(type) \
do { \
atomic_inc(&ppc_emulated.type.val); \
if (ppc_warn_emulated) \
@@ -66,8 +66,11 @@ extern void ppc_warn_emulated_print(cons
#else /* !CONFIG_PPC_EMULATED_STATS */
-#define PPC_WARN_EMULATED(type)do { } while (0)
+#define __PPC_WARN_EMULATED(type) do { } while (0)
#endif /* !CONFIG_PPC_EMULATED_STATS */
+#define PPC_WARN_EMULATED(type, regs) __PPC_WARN_EMULATED(type)
+#define PPC_WARN_ALIGNMENT(type, regs) __PPC_WARN_EMULATED(type)
+
#endif /* _ASM_POWERPC_EMULATED_OPS_H */
Index: linux.trees.git/arch/powerpc/kernel/align.c
===
--- linux.trees.git.orig/arch/powerpc/kernel/align.c2009-10-19
09:46:58.0 +1100
+++ linux.trees.git/arch/powerpc/kernel/align.c 2009-10-21 10:21:35.0
+1100
@@ -732,7 +732,7 @@ int fix_alignment(struct pt_regs *regs)
#ifdef CONFIG_SPE
if ((instr >> 26) == 0x4) {
- PPC_WARN_EMULATED(spe);
+ PPC_WARN_ALIGNMENT(spe, regs);
return emulate_spe(regs, reg, instr);
}
#endif
@@ -786,7 +786,7 @@ int fix_alignment(struct pt_regs *regs)
flags |= SPLT;
nb = 8;
}
- PPC_WARN_EMULATED(vsx);
+ PPC_WARN_ALIGNMENT(vsx, regs);
return emulate_vsx(addr, reg, areg, regs, flags, nb);
}
#endif
@@ -794,7 +794,7 @@ int fix_alignment(struct pt_regs *regs)
* the exception of DCBZ which is handled as a special case here
*/
if (instr == DCBZ) {
- PPC_WARN_EMULATED(dcbz);
+ PPC_WARN_ALIGNMENT(dcbz, regs);
return emulate_dcbz(regs, addr);
}
if (unlikely(nb == 0))
@@ -804,7 +804,7 @@ int fix_alignment(struct pt_regs *regs)
* function
*/
if (flags & M) {
- PPC_WARN_EMULATED(multiple);
+ PPC_WARN_ALIGNMENT(multiple, regs);
return emulate_multiple(regs, addr, reg, nb,
flags, instr, swiz);
}
@@ -825,11 +825,11 @@ int fix_alignment(struct pt_regs *regs)
/* Special case for 16-byte FP loads and stores */
if (nb == 16) {
- PPC_WARN_EMULATED(fp_pair);
+ PPC_WARN_ALIGNMENT(fp_pair, regs);
return emulate_fp_pair(addr, reg, flags);
}
- PPC_WARN_EMULATED(unaligned);
+ PPC_WARN_ALIGNMENT(unaligned, regs);
/* If we are loading, get the data from user space, else
* get it from register values
Index: linux.trees.git/arch/powerpc/kernel/traps.c
===
--- linux.trees.git.orig/arch/powerpc/kernel/traps.c2009-10-19
09:46:58.0 +1100
+++ linux.trees.git/arch/powerpc/kernel/traps.c 2009-10-21 10:21:35.0
+1100
@@ -759,7 +759,7 @@ static int emulate_instruction(struct pt
/* Emulate the mfspr rD, PVR. */
if ((instword & PPC_INST_MFSPR_PVR_MASK) == PPC_INST_MFSPR_PVR) {
- PPC_WARN_EMULATED(mfpvr);
+ PPC_WARN_EMULATED(mfpvr, regs);
rd = (instword >> 21) & 0x1f;
regs->gpr[rd] = mfspr(SPRN_PVR);
return 0;
@@ -767,7 +767,7 @@ static int emulate_instruction(struct pt
/* Emulating the dcba insn is just a no-op. */
if ((instword & PPC_INST_DCBA_MASK) == PPC_INST_DCBA) {
- PPC_WARN_EMULATED(dcba);
+ PPC_WARN_EMULATED(dcba, regs);
return 0;
}
@@ -776,7 +776,7 @@ static int emulate_instruction(struct pt
int shift = (instword >> 21) & 0x1c;
unsigned long msk = 0xf000UL >> shift;
- PPC_WARN_EMULATED(mcrxr);
+ P
