Re: Requesting a GPIO that hasn't been registered yet
On Tue, Mar 30, 2010 at 10:05:01PM -0500, Bill Gatliff wrote: [...] > In other words, the GPIO pin I'm using for the key is one of the bits on > my pca953x GPIO expander chip. > > The above would all be great, except that I haven't come up with a way > to make sure that my encoder_button doesn't try to probe before lext60 > is available. In fact, I'm consistently getting initialization in the > wrong order! > > Eventually the GPIO expander chip gets plugged in, because I can see it > show up in sysfs. And what's really odd is, I recently made similar > mods to gpio_leds and they are working fine--- although the GPIO pin is > on a pca953x at address 20, instead of 60. I'm at a loss to explain why > one works, but the other doesn't. And I don't know how to really fix > this problem for good! That's because of drivers/Makefile: obj-$(CONFIG_INPUT) += input/ ... obj-y += i2c/ media/ ... obj-$(CONFIG_NEW_LEDS) += leds/ So, all these drivers use module_init(), which means that the order of execution depends on link order. To fix probing you need to move i2c/ above input/: diff --git a/drivers/Makefile b/drivers/Makefile index 34f1e10..d31bb52 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -67,12 +67,12 @@ obj-$(CONFIG_USB) += usb/ obj-$(CONFIG_USB_MUSB_HDRC)+= usb/musb/ obj-$(CONFIG_PCI) += usb/ obj-$(CONFIG_USB_GADGET) += usb/gadget/ +obj-y += i2c/ media/ obj-$(CONFIG_SERIO)+= input/serio/ obj-$(CONFIG_GAMEPORT) += input/gameport/ obj-$(CONFIG_INPUT)+= input/ obj-$(CONFIG_I2O) += message/ obj-$(CONFIG_RTC_LIB) += rtc/ -obj-y += i2c/ media/ obj-$(CONFIG_PPS) += pps/ obj-$(CONFIG_W1) += w1/ obj-$(CONFIG_POWER_SUPPLY) += power/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC-PATCH] fec_mpc52xx: add NAPI support
This patch adds NAPI support to the MPC52xx FEC network driver. The main
reason for using NAPI is to solve the problem of system hangs under
heavy packet storms causing interrupt flooding. While NAPI support is
straight-forward, recovering from RX FIFO errors is more delicate.
Actually, under packet storms, the RX FIFO error is triggered, requiring
a full reset of the FEC and the Bestcom tasks. Furthermore, the link
goes down and the only way to recover is to reset the phy as well. To
handle the reset properly, it's performed by a work queue task. The
reset does not really harm because the packets can not be digested
(processed) by the system at that rate anyhow. NAPI can be enabled via
Kconfig parameter CONFIG_FEC_MPC52xx_NAPI. Throughput measurements with
netperf showed almost the same results with and without NAPI.
Signed-off-by: Wolfgang Grandegger
---
drivers/net/Kconfig |7 +++
drivers/net/fec_mpc52xx.c | 121 -
drivers/net/fec_mpc52xx_phy.c |4 +-
3 files changed, 127 insertions(+), 5 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0ba5b8e..b973e28 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1938,6 +1938,13 @@ config FEC_MPC52xx
Fast Ethernet Controller
If compiled as module, it will be called fec_mpc52xx.
+config FEC_MPC52xx_NAPI
+ bool "Use NAPI for MPC52xx FEC driver"
+ depends on FEC_MPC52xx
+ ---help---
+ This option enables NAPI support for the MPC5200's on-chip
+ Fast Ethernet Controller driver.
+
config FEC_MPC52xx_MDIO
bool "MPC52xx FEC MDIO bus driver"
depends on FEC_MPC52xx
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 0dbd721..bb64a72 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -44,6 +45,8 @@
#define DRIVER_NAME "mpc52xx-fec"
+#define FEC_MPC52xx_NAPI_WEIGHT 64
+
/* Private driver data structure */
struct mpc52xx_fec_priv {
struct net_device *ndev;
@@ -63,6 +66,10 @@ struct mpc52xx_fec_priv {
struct phy_device *phydev;
enum phy_state link;
int seven_wire_mode;
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ struct work_struct reset_task;
+ struct napi_struct napi;
+#endif
};
@@ -234,6 +241,10 @@ static int mpc52xx_fec_open(struct net_device *dev)
phy_start(priv->phydev);
}
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ napi_enable(&priv->napi);
+#endif
+
if (request_irq(dev->irq, mpc52xx_fec_interrupt, IRQF_SHARED,
DRIVER_NAME "_ctrl", dev)) {
dev_err(&dev->dev, "ctrl interrupt request failed\n");
@@ -281,6 +292,9 @@ static int mpc52xx_fec_open(struct net_device *dev)
priv->phydev = NULL;
}
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ napi_disable(&priv->napi);
+#endif
return err;
}
@@ -288,6 +302,10 @@ static int mpc52xx_fec_close(struct net_device *dev)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ cancel_work_sync(&priv->reset_task);
+ napi_disable(&priv->napi);
+#endif
netif_stop_queue(dev);
mpc52xx_fec_stop(dev);
@@ -386,10 +404,44 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+#ifdef CONFIG_FEC_MPC52xx_NAPI
static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->lock, flags);
+
+ /* Disable the RX interrupt */
+ if (napi_schedule_prep(&priv->napi)) {
+ disable_irq_nosync(irq);
+ __napi_schedule(&priv->napi);
+ } else {
+ dev_err(dev->dev.parent, "FEC BUG: interrupt while in poll\n");
+ }
+
+ spin_unlock_irqrestore(&priv->lock, flags);
+
+ return IRQ_HANDLED;
+}
+#endif
+
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+static int mpc52xx_fec_rx_poll(struct napi_struct *napi, int budget)
+#else
+static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
+#endif
+{
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ struct mpc52xx_fec_priv *priv =
+ container_of(napi, struct mpc52xx_fec_priv, napi);
+ struct net_device *dev = napi->dev;
+ int pkt_received = 0;
+#else
+ struct net_device *dev = dev_id;
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+#endif
struct sk_buff *rskb; /* received sk_buff */
struct sk_buff *skb; /* new sk_buff to enqueue in its place */
struct bcom_fec_bd *bd;
@@ -400,7 +452,11 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void
*dev_id)
spin_lock_irqsave(&priv->lock, flags);
while (bcom_buffer_done(priv->rx_dmatsk)) {
-
+#ifdef CONFIG_F
Re: MPC5200B, many FEC_IEVENT_RFIFO_ERRORs until link down
Hi Roman, Wolfgang Grandegger wrote: > Roman Fietze wrote: >> Hello, >> >> I think this is a never ending story. This error still happens under >> higher load every few seconds, until I get a "PHY: f0003000:00 - Link >> is Down", on my box easiliy reproducable after maybe 15 to 30 seconds. >> I can recover using "ip link set down/up dev eth0". >> >> I double checked that I'm using the most recent version of this driver >> (checked with DENX, benh master/next, using Wolfgang Denk's version of >> the 2.6.33), this includes the locking patches from Asier Llano, the >> hard setting of mii_speed in the PHY mdio transfer routine of course. >> I tried all 8 combinations of PLDIS, BSDIS and SE, with and without >> CONFIG_NOT_COHERENT_CACHE. >> >> As some of you probably remember, I'm running this controller under >> high load on FEC, ATA and LPC. As soon as "the" load is going above a >> certain level I get those FEC RFIFO errors, sometimes ATA errors >> (MWDMA2) and sometimes even lost SDMA interrupts using BestComm with >> the SCLPC (now switched back to simple PIO). I quite sure almost all >> of this is the BestComm's fault. > > This problem shows up quickly with NAPI, but I have never observed it > with the current version. The error occurs when the software is not able > to readout the messages in time. Unfortunately, dealing with Bestcomm is > a pain. > >> Did somebody already try the latest NAPI patches, which might give me >> a slight chance to have a workaround? Any idea or upcoming patch to >> address this problem once more, and if it's just by recovering e.g. >> within mpc52xx_fec_mdio_transfer's timeout using some other dirty >> workaround? > > Yes, I have a NAPI version ready for testing. I will roll it out as RFC > today or tomorrow. I just sent out the patch. Would be nice if you, or somebody else, could do some testing and provide some feedback. FYI, I will be out of office next week. Thanks, Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
kexec for powerpc32
[please CC me as I am not subscribed] Hi, when building a kernel for powerpc32 (PowerBook6,8 / 7447A) I can select CONFIG_KEXEC. However, after booting I can't convince kexec (from kexec-tools, latest git checkout) to load the kernel: # /opt/kexec-tools/sbin/kexec -l /boot/2.6/zImage --append="root=/dev/hda6" get_memory_ranges(): Unsupported platform Could not get memory layout Can anybody comment on wether or not kexec is supported on this platform? If not, is this a limitation of kexec-tools or the kernel? If it's the latter, can't the option be hidden/disabled in Kconfig for this platform? Then again, from looking at the Kconfig files, I see that the "74xx" CPU is among quite a few CPU types and so PPC_BOOK3S_32 is selected, and then ALTIVEC selects 6xx which in turn selects PPC_BOOK3S - so, I guess !PPC_BOOK3S for KEXEC is not an option here? Thanks, Christian. -- BOFH excuse #69: knot in cables caused data stream to become twisted and kinked ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kexec for powerpc32
Hi, On Wed, Mar 31, 2010 at 05:18:18AM -0700, Christian Kujau wrote: > [please CC me as I am not subscribed] > > Hi, > > when building a kernel for powerpc32 (PowerBook6,8 / 7447A) I can select > CONFIG_KEXEC. However, after booting I can't convince kexec (from > kexec-tools, latest git checkout) to load the kernel: > > # /opt/kexec-tools/sbin/kexec -l /boot/2.6/zImage --append="root=/dev/hda6" > get_memory_ranges(): Unsupported platform > Could not get memory layout Kernel has all needed for kexec, but kexec-tools are broken for powerpc32. http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg22498.html I've just asked around, and it seems that Maxim (Cc'ed) will start working on reviving ppc32 support real soon. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v3] net: add PCINet driver
On Tue, Mar 30, 2010 at 11:46:29PM -0500, Kumar Gala wrote: > > On Nov 5, 2008, at 3:22 PM, Ira Snyder wrote: > > > This adds support to Linux for a virtual ethernet interface which uses the > > PCI bus as its transport mechanism. It creates a simple, familiar, and fast > > method of communication for two devices connected by a PCI interface. > > > > I have implemented client support for the Freescale MPC8349EMDS board, > > which is capable of running in PCI Agent mode (It acts like a PCI card, but > > is a complete PowerPC computer, running Linux). It is almost certainly > > trivially ported to any MPC83xx system. > > > > It was developed to work in a CompactPCI crate of computers, one of which > > is a relatively standard x86 system (acting as the host) and many PowerPC > > systems (acting as clients). > > > > RFC v2 -> RFC v3: > > * use inline functions for accessing struct circ_buf_desc > > * use pointer dereferencing on PowerPC local memory instead of ioread32() > > * move IMMR and buffer descriptor accessors inside drivers > > * update for dma_mapping_error() API changes > > * use minimal locking primitives (i.e. spin_lock() instead of _irqsave()) > > * always disable checksumming, PCI is reliable > > * replace typedef cbd_t with struct circ_buf_desc > > * use get_immrbase() to get IMMR register offsets > > > > RFC v1 -> RFC v2: > > * remove vim modelines > > * use net_device->name in request_irq(), for irqbalance > > * remove unneccesary wqt_get_stats(), use default get_stats() instead > > * use dev_printk() and friends > > * add message unit to MPC8349EMDS dts file > > > > Signed-off-by: Ira W. Snyder > > --- > > This is the third RFC posting of this driver. I got some feedback, and have > > corrected the problems. Thanks to everyone who has done review! I have > > gotten off-list feedback from several potential users, so there are > > definitely many potential users. > > > > I'll post up a revised version about once a week as long as the changes are > > minor. If they are more substantial, I'll post them as needed. > > > > The remaining issues I see in this driver: > > 1) Naming > > The name wqt originally stood for "workqueue-test" and somewhat evolved > > over time into the current driver. I'm looking for suggestions for a > > better name. It should be the same between the host and client drivers, > > to make porting the code between them easier. The drivers are /very/ > > similar other than the setup code. > > 2) IMMR Usage > > In the Freescale client driver, I use the whole set of board control > > registers (AKA IMMR registers). I only need a very small subset of them, > > during startup to set up the DMA window. I used the full set of > > registers so that I could share the register offsets between the drivers > > (in pcinet_hw.h) > > 3) Hardcoded DMA Window Address > > In the Freescale client driver, I just hardcoded the address of the > > outbound PCI window into the DMA transfer code. It is 0x8000. > > Suggestions on how to get this value at runtime are welcome. > > > > > > Rationale behind some decisions: > > 1) Usage of the PCINET_NET_REGISTERS_VALID bit > > I want to be able to use this driver from U-Boot to tftp a kernel over > > the PCI backplane, and then boot up the board. This means that the > > device descriptor memory, which lives in the client RAM, becomes invalid > > during boot. > > 2) Buffer Descriptors in client memory > > I chose to put the buffer descriptors in client memory rather than host > > memory. It seemed more logical to me at the time. In my application, > > I'll have 19 boards + 1 host per cPCI chassis. The client -> host > > direction will see most of the traffic, and so I thought I would cut > > down on the number of PCI accesses needed. I'm willing to change this. > > 3) Usage of client DMA controller for all data transfer > > This was done purely for speed. I tried using the CPU to transfer all > > data, and it is very slow: ~3MB/sec. Using the DMA controller gets me to > > ~40MB/sec (as tested with netperf). > > 4) Static 1GB DMA window > > Maintaining a window while DMA's in flight, and then changing it seemed > > too complicated. Also, testing showed that using a static window gave me > > a ~10MB/sec speedup compared to moving the window for each skb. > > 5) The serial driver > > Yes, there are two essentially separate drivers here. I needed a method > > to communicate with the U-Boot bootloader on these boards without > > plugging in a serial cable. With 19 clients + 1 host per chassis, the > > cable clutter is worth avoiding. Since everything is connected via the > > PCI bus anyway, I used that. A virtual serial port was simple to > > implement using the messaging unit hardware that I used for the network > > driver. > > > > I'll post both U-Boot drivers to their mailing list
Re: I can not get my MII working on MPC8247 with Linux 2.6.32.6
Peter Pan wrote: Recently, I'm porting Linux 2.6.32.6 to our customized MPC8247 based board. Everything is fine out except my ethernets. I uses cpm2-scc-enet and cpm2-fcc-enet drivers. My ethernet works fine in U-Boot with the same setting, and our previous Linux 2.6.22 is also working, so there should be nothing wrong with the hardware. The boot log of the MII part is: CPM2 Bitbanged MII: probed mdio_bus f0010d00: error probing PHY at address 0 mdio_bus f0010d00: error probing PHY at address 1 Are 0 and 1 the addresses you're expecting the PHYs to be at? If that's not it, I'd try to examine the specific register accesses that 2.6.22 is doing and see what's different. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Question regarding the DTLB Miss exceptions
> > I'm tracking a problem that's leading me through DSI and DTLB miss > exceptions on an MPC8347 (e300c1 core), and I've come across an oddity > that I'm hoping someone can explain. > > When a DTLB Miss exception can't find a PTE for the virtual address being > written/read, it dummies up the SPRs for a DSI exception and then calls > directly into the DSI exception code. Just before the DTLB miss code > stores a value into DSISR it sets bit 2, which for a DSI exception is a > reserved bit and should be cleared. There's no comment on the code > (.../arch/powerpc/kernel/head_32.S line 619 of the 2.6.33-rc1 kernel). Can > anyone tell me why this bit is getting set? Probably for generic handling in do_page_fault() Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] drivers/net: Remove local #define IW_IOCTL, use STD_IW_HANDLER
Hi, On 03/17/2010 11:21 PM, Joe Perches wrote: > Use #define STD_IW_HANDLER from wireless.h instead > > Signed-off-by: Joe Perches > --- > drivers/net/ps3_gelic_wireless.c | 35 +++--- > drivers/net/wireless/ipw2x00/ipw2200.c | 83 > > 2 files changed, 58 insertions(+), 60 deletions(-) Sorry for the delay. This looks fine for the PS3. Acked-by: Geoff Levand ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kexec for powerpc32
On Wed, 31 Mar 2010 at 17:23, Anton Vorontsov wrote: > Kernel has all needed for kexec, but kexec-tools are broken for > powerpc32. > > http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg22498.html Oh :-\ > I've just asked around, and it seems that Maxim (Cc'ed) will start > working on reviving ppc32 support real soon. Well, in my case the powerpc32 machine is far from being a "production system", but I'm glad to hear that he's working on it! Thanks for the response, Christian. -- BOFH excuse #292: We ran out of dial tone and we're and waiting for the phone company to deliver another bottle. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: I can not get my MII working on MPC8247 with Linux 2.6.32.6
Yes, the PHY address is correct, I've checked the schematics, and 2.6.22 is also using this PHY address. The different between 2.6.22 and 2.6.32.6 is that: In 2.6.22, we use arch/ppc/8260_io/fcc_enet.c as the driver. IMMR address 0xf000 is directly used. In 2.6.32.6, cpm2-fcc-enet driver is used. In that driver, the register address is ioremaped and used. The others are the same. I've tried to use the dir and data register address directly in mii-bitbang.c, but that leads to kernel oops. I've wrote a low level gpio driver for our processor MPC8247, and I used that for our external hardware watchdog, it works fine. Then I use the low level driver in the mii-bitbang.c, it still works incorrect, all I get from MDIO is 1. I'm really confused. 2010/3/31 Scott Wood : > Peter Pan wrote: >> >> Recently, I'm porting Linux 2.6.32.6 to our customized MPC8247 based >> board. Everything is fine out except my ethernets. I uses >> cpm2-scc-enet and cpm2-fcc-enet drivers. >> My ethernet works fine in U-Boot with the same setting, and our >> previous Linux 2.6.22 is also working, so there should be nothing >> wrong with the hardware. >> The boot log of the MII part is: >> >> CPM2 Bitbanged MII: probed >> mdio_bus f0010d00: error probing PHY at address 0 >> mdio_bus f0010d00: error probing PHY at address 1 > > Are 0 and 1 the addresses you're expecting the PHYs to be at? > > If that's not it, I'd try to examine the specific register accesses that > 2.6.22 is doing and see what's different. > > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
spin_lock_irqsave and multi-core
I got a question when reading source code. Hope somebody can give me the answer. On multi-core system, spin_lock_irqsave() can stop all CPU cores receiving interrupts? If the answer is no, what we can do to disable external interrupt for all CPU cores? Thanks, Gavin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spin_lock_irqsave and multi-core
On Thu, 2010-04-01 at 09:59 +0800, gshan wrote: > On multi-core system, spin_lock_irqsave() can stop all CPU cores > receiving interrupts? No. > If the answer is no, what we can do to disable external interrupt for > all CPU cores? You don't :-) Really, you generally don't. Why would you want to do that ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spin_lock_irqsave and multi-core
On Thu, 2010-04-01 at 10:41 +0800, gshan wrote: > One of my private driver need it. I don't know how to do it. Then your driver is most certainly doing something wrong :-) No driver needs that. Ever. What is it trying to do more precisely ? I might be able to explain what the right approach is if you can tell me what the driver is trying to disable all system IRQs for ? Keep in mind that local_irq_save() does a lot more than just masking external interrupts from your device. It masks them from -all- devices, including timer interrupts, perfmon interrupts, etc... Doing so on all cores is generally a big no-no and almost never really necessary. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spin_lock_irqsave and multi-core
Benjamin Herrenschmidt wrote: On Thu, 2010-04-01 at 09:59 +0800, gshan wrote: On multi-core system, spin_lock_irqsave() can stop all CPU cores receiving interrupts? No. Thanks a lot for your answer. If the answer is no, what we can do to disable external interrupt for all CPU cores? You don't :-) Really, you generally don't. Why would you want to do that ? One of my private driver need it. I don't know how to do it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spin_lock_irqsave and multi-core
Then your driver is most certainly doing something wrong :-) No driver needs that. Ever. What is it trying to do more precisely ? I might be able to explain what the right approach is if you can tell me what the driver is trying to disable all system IRQs for ? Keep in mind that local_irq_save() does a lot more than just masking external interrupts from your device. It masks them from -all- devices, including timer interrupts, perfmon interrupts, etc... Doing so on all cores is generally a big no-no and almost never really necessary. I agree with you. Actually, I can disable the individual interrupt via disable_irq_sync() to make sure system cooherence. It's just my concern when reading kernel source. Anyway, thanks a lot for your kindly answer. Thanks, Gavin Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spin_lock_irqsave and multi-core
On Thu, 2010-04-01 at 11:18 +0800, gshan wrote: > I agree with you. Actually, I can disable the individual interrupt via > disable_irq_sync() to make sure > system cooherence. This is also a very heavy hammer and not recommended at all. In most case, you don't need that either. Also don't forget that if your system has shared interrupts, you'll also disable whoever else interrupt you are sharing with. You also cannot call that within a spinlock region for example. You don't normally need any of that if you use spinlocks properly, but again, without more understanding of what your driver is trying to do, it's hard to explain properly what you should do. Normally tho, you synchronize your interrupt handler with your other driver parts using simply a spinlock. You take it with spin_lock/unlock from the interrupt handler and you use spin_lock_irqsave/restore from the non-irq path. You don't normally need more. You only need the irqsave/restore in fact on one CPU because it's goal is purely to avoid a spin deadlock if your interrupt happens on that same CPU at the same time. Only if you want to disable interrupts for an extended period of time should you consider using disable_irq_* and even then, as I mentioned, it has drawbacks and is generally not recommended. Alternatively, most devices have the ability to disable interrupt emission on the device itself using some kind of MMIO register (though you still need to synchronize things properly in your driver as the interrupt might have already been emitted and on its way to the processor when you whack that register. But again, without more detailed knowledge of what you driver is actually doing, it's hard to give you more precise advice. Cheers, Ben. > It's just my concern when reading kernel source. > Anyway, thanks a lot > for your kindly answer. > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
