* Re: Patches added to powerpc.git master and powerpc-next branches
From: Kumar Gala @ 2008-04-18 13:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18440.34891.440661.248400@cargo.ozlabs.ibm.com>
On Apr 18, 2008, at 6:38 AM, Paul Mackerras wrote:
> I have pushed out the following commits to the master and powerpc-next
> branches of the powerpc.git tree. This includes commits from Kumar's
> and Jeremy's trees.
>
> I am intending to ask Linus to pull the powerpc-next branch once we
> have the breakage from the OF helpers for i2c patch sorted out.
>
> Paul.
What are we doing with these two patches:
[POWERPC] 85xx: Add support for relocatble kernel (and booting at non-
zero)
[POWERPC] Port fixmap from x86 and use for kmap_atomic
I know the second was late, but I'd like us to think about putting it
in for v2.6.26. It gives us a good basis for the PCIe 44x and 83xx
config cycle work and kexec/kdump work for v2.6.27.
thanks.
- k
^ permalink raw reply
* Re: [PATCH v3] powerpc: Add irqtrace support for 32-bit powerpc
From: Kumar Gala @ 2008-04-18 13:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1207690574.7442.4.camel@johannes.berg>
On Apr 8, 2008, at 4:36 PM, Johannes Berg wrote:
>
>>> This version fixes the clobbering of r12 by the call to
>>> trace_hardirqs_off() that was pointed out by BenH.
>>>
>>> Johannes, I'd appreciate your trying this version if/when
>>> you get the chance.
>>
>> Thanks Dale, this version seems to work. I'll stress it a bit more
>> later, but so far it has survived *much* longer than both previous
>> versions.
>
> Hmm. Bad news. I got a crash in console_callback() again where
> apparently r28 had a bogus value. That, however, doesn't make sense,
> so
> maybe that register value was calculated from another register.
did we ever figure this out?
- k
^ permalink raw reply
* Re: BestComm/FEC Linux system crash
From: Rob Broersen @ 2008-04-18 12:08 UTC (permalink / raw)
To: Sylvain Munaut, linuxppc-dev; +Cc: Cees van Teylingen, dve, Nathan Huizinga
In-Reply-To: <4804D5C2.3050104@246tnt.com>
Hi Sylvain,
I'm a colleague of Cees at Chess and also working on the FEC crash error
on our MPC5200B based system running Linux kernel 2.6.15. We seem to
have a breakthrough in the process of finding the bug. We've
investigated the fec_rx_interrupt handler, which contains the following
construction:
for (;;) {
sdma_clear_irq(priv->rx_sdma);
if (!sdma_buffer_done(priv->rx_sdma))
{
break;
}
In this construction, the assumption seems to be made that when an
interrupt is pending (indicating a (new) buffer is filled) the status
field in the buffer descriptor table (checked by sdma_buffer_done() ) is
already updated. We've tested this assumption:
- First, when an interrupt is pending, I've implemented a loop polling
for the buffer to become 'done' with no sleep inbetween for a maximum of
100000 times. The result was that often it took a few 100 polls for the
buffer to become done, followed by the polling loop breaking at 100000
loops without the buffer becoming done.
- After that, I put a 1millisecond sleep period in this polling loop. In
this situation, the buffer always was done within 1 millisecond.
Therefore, it seems that there is some latency between the interrupt
being asserted and the status being written, and continuously polling
the status field from the processor seems to (often) have priority over
the bestComm writing it. The assumption above is proven be wrong,
because the situation where the interrupt is pending but the
corresponding buffer is not done, occurs almost every second in our test
system.
Therefore, it is possible for an interrupt to be cleared while the
corresponding buffer is not handled. We implemented a fix for this
situation, to prevent the interrupt from being cleared when the
corresponding buffer is not yet done:
if (!sdma_buffer_done(priv->rx_sdma)) return IRQ_HANDLED;
sdma_clear_irq(priv->rx_sdma);
for (;;) {
if (!sdma_buffer_done(priv->rx_sdma))
{
break;
}
....
With this fix, our systems have been running smoothly for over 16 hours
and counting. The FEC_IEVENT_RFIFO_ERROR hasn't occured anymore. Because
the interrupt isn't cleared but returned immediately in some cases, the
interrupt handler is invoked more often than before, but we don't see a
detremental effect on system performance.
Could you please comment on our findings and our fix? And can you
explain why we see that the interrupt is often received while the status
isn't yet updated? It is not clear to us what is causing the latency
between the update and the interrupt, as it seems to originate from the
same DRD in the BestComm microcode:
0x046acf80, /* DRD1A: *idx3 = *idx0; FN=0 INT init=3 WS=1 RS=1
*/
Thanx for your help!
Regards,
Rob Broersen.
Chess.
Sylvain Munaut schreef:
> Hi
>
>> I hereby take the liberty to contact you regarding an issue we
>> experience with the
>> MPC5200 BestComm/FEC in our system. I found that you are the writer of
>> the drivers
>> for these, so apparently with a lot of experience with these devices.
>> I hope you can find
>> the time and inspiration to look into our case.
>>
> Well, feel free to CC me to bring my attention to it, but such question
> should still go to the list.
> It's been a while since I worked on the 5200 and some other people might
> have more recent expertise than I do.
>
> Plus, it's actually Domen Puncer who reworked a lot of the network
> driver code quite recently ...
>
>
>> We are running a Lunix based system based on a MPC5200
>>
> Need more precision.
> - 5200 or 5200B ?
> - What kernel version (version ?, where did you get it ?, external patch
> applied ?)
>
>
>> This process dies after several minutes due to a FEC RxFifo overflow
>> interrupt. This interrupt
>> now causes the FEC to be re-initialized, but for some reason the
>> receiver channel still does
>> not work properly, causing the RxFifo overflow to occur nearly
>> immediately again, causing
>> a subsequent FEC re-init again, again resulting in failing receiver
>> channel, causing another
>> RxFifo overflow interrupt etc etc etc......
>>
> Huh ... you transmit lots of data ... and it's the RX fifo that overlow ...
>
>
>> In the FEC driver we stumbled upon the following code:
>>
>> static irqreturn_t fec_rx_interrupt(int irq, void *dev_id)
>> {
>> struct net_device *dev = dev_id;
>> struct fec_priv *priv = (struct fec_priv *)dev->priv;
>>
>> for (;;) {
>> struct sk_buff *skb;
>> struct sk_buff *rskb;
>> struct bcom_fec_bd *bd;
>> u32 status;
>>
>> if (!bcom_buffer_done(priv->rx_dmatsk))
>> break;
>>
>> [...snipped...]
>> Now what we see is that the statement in the FEC interrupt handler
>>
>> if (!bcom_buffer_done(priv->rx_dmatsk))
>> break;
>>
>> is executed frequently.
>>
>> Can you explain why this statement is there?
>>
> Well ... that test is inside an infinite loop ( for(;;) ... ), so yes,
> hopefully it will be 'break' at some point ...
> What we do here is that we try to process as much receive buffer as
> possible ... So we loop indefinitly until no more buffers are ready ...
>
>
>> During debug, after receiving the first RxFifo overflow interrupt, we
>> suspended all further FEC processing and dumped
>> various system status, of which the BestComm receiver descriptors.
>> Here we found that always all but one were initialized
>> to 0x4000005f2, but the different one to 0x08000040.
>>
> Theses are Receive Buffer descriptor. So it the BCOM_BD_READY bit is
> _set_, that means, that they're _not_ done (i.e. they are ready for
> bestcomm to fill).
> If you check the definition of bcom_buffer_done, you'll see that we
> check if the bit is _cleared_
>
> So the situation you are describing is essentially :
> - One of the buffer is filled with some received packet (length = 0x40)
> - All the other buffers are ready for bestcomm and they can contain at
> maximum 1522 bytes (0x5f2)
>
> There is nothing 'wrong' about this situation.
>
>
>> This all directs us somewhat to the believe that the following is
>> occurring:
>>
>> For some reason the BestComm gets confused during FEC reception
>> causing a descriptor not to be handled properly, which
>> causes its status never to be set to 'ready' (BCOM_BD_READY
>> 0x40000000ul). Eventually, because of all receiving
>> traffic to be ceased, the RxFifo will overflow causing the described
>> interrupt and following re-initialization actions. But the
>> BestComm FEC receiver channel fails to re-initialize (or even does not
>> get re-initialized at all) and/or the BestComm FEC
>> receiver descriptor table does not get re-initialized, causing the
>> 0x08000040 status to remain in there. So either BestComm
>> fails to work at all for the FEC Receiver channel and/or BestComm
>> eventually stumbles upon the 'incorrect' descriptor causing
>> the FEC receiver to stall again causing an RxFifo overflow again etc
>> etc etc.
>>
> Well, given you misunderstood the meaning of BCOM_BD_READY, this theory
> doesn't make much sense sorry ...
>
> The re-initialize process should work however ... there is a bug there.
>
>
>> This all seems plausible for what we experience so far, but does get
>> confirmed by any data we can find in datasheets and
>> hard-/software descriptions. The FEC receiver has the highest priority
>> within BestComm and thus should always get serviced.
>> The thing we can not find however is what system impact the PCI DMA by
>> the PLX9056 is causing on the BestComm
>> performance.
>>
> The only interference I see would be contention on the XLB bus ... Maybe
> you can try to play with the xlb priority and give a higher one to
> bestcomm or a lower one to the PCI.
> Look in the platform setup there is some code setting xlb priorities.
> And refer to the 'XLB arbiter' section of the manual for the registers
> to tweak.
>
> What kind of bandwidth are you using for RX/TX on ethernet and PCI ?
> Does your PCI card do _very_ long bursts without releasing the bus
> (locking the xlb for a long time), or _very_ short burst causing big
> overhead ?
>
> You can also try playing the FEC RX fifo alarm levels.
>
>
>> We can imagine that it disrupts 'normal' BestComm performance i.e.
>> Ethernet traffic, but then again the overflow
>> interrupt should take care of a proper re-initialization of all hard-
>> and software, allowing the TCP/IP stack to subsequently
>> handle correct transfer of missing packets.
>>
> The overflow should still not happen ... that's a pretty serious error
> imho.
>
>
> Sylvain
>
^ permalink raw reply
* Re: [PATCH] Fix the wrong serial1 interrupt for 8610 board
From: Kumar Gala @ 2008-04-18 12:51 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev
In-Reply-To: <1208588876-23103-1-git-send-email-Jason.jin@freescale.com>
On Apr 19, 2008, at 2:07 AM, Jason Jin wrote:
> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8610_hpcd.dts | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/
> boot/dts/mpc8610_hpcd.dts
> index 16c947b..97fdb01 100644
> --- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
> +++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
> @@ -100,7 +100,7 @@
> compatible = "ns16550";
> reg = <0x4600 0x100>;
> clock-frequency = <0>;
> - interrupts = <28 2>;
> + interrupts = <42 2>;
I've converted the .dts to v1 syntax but I'll fix this when I apply
since its trivial.
>
> interrupt-parent = <&mpic>;
> };
- k
^ permalink raw reply
* [PATCHv3 3/7] i2c: OF helpers for the i2c API
From: Jochen Friedrich @ 2008-04-18 12:43 UTC (permalink / raw)
To: Kumar Gala
Cc: Stephen Rothwell, linuxppc-dev list, Kernel, Linux, Scott Wood,
Paul Mackerras, Jean Delvare, David Miller, Linux I2C
This patch implements various helpers to support OF bindings for
the i2c API.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/of/Kconfig | 6 +++
drivers/of/Makefile | 1 +
drivers/of/of_i2c.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of_i2c.h | 24 ++++++++++
4 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 drivers/of/of_i2c.c
create mode 100644 include/linux/of_i2c.h
Changes to v2:
- make helpers compile as module as well, if i2c-core is compiled as module.
- rename drivers/of/i2c.c to drivers/of/of_i2c.c to avoid module namespace conflict.
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index c03072b..210bf37 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -1,3 +1,9 @@
config OF_DEVICE
def_bool y
depends on OF && (SPARC || PPC_OF)
+
+config OF_I2C
+ def_tristate I2C
+ depends on OF && I2C
+ help
+ OpenFirmware I2C accessors
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ab9be5d..121d9ed 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,2 +1,3 @@
obj-y = base.o
obj-$(CONFIG_OF_DEVICE) += device.o platform.o
+obj-$(CONFIG_OF_I2C) += of_i2c.o
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
new file mode 100644
index 0000000..6316891
--- /dev/null
+++ b/drivers/of/of_i2c.c
@@ -0,0 +1,115 @@
+/*
+ * OF helpers for the I2C API
+ *
+ * Copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
+ *
+ * Based on a previous patch from Jon Smirl <jonsmirl@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/i2c.h>
+#include <linux/of.h>
+
+struct i2c_driver_device {
+ char *of_device;
+ char *i2c_type;
+};
+
+static struct i2c_driver_device i2c_devices[] = {
+ { "dallas,ds1374", "rtc-ds1374" },
+};
+
+static int of_find_i2c_driver(struct device_node *node,
+ struct i2c_board_info *info)
+{
+ int i, cplen;
+ const char *compatible;
+ const char *p;
+
+ /* 1. search for exception list entry */
+ for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
+ if (!of_device_is_compatible(node, i2c_devices[i].of_device))
+ continue;
+ if (strlcpy(info->type, i2c_devices[i].i2c_type,
+ I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ return -ENOMEM;
+
+ return 0;
+ }
+
+ compatible = of_get_property(node, "compatible", &cplen);
+ if (!compatible)
+ return -ENODEV;
+
+ /* 2. search for linux,<i2c-type> entry */
+ p = compatible;
+ while (cplen > 0) {
+ if (!strncmp(p, "linux,", 6)) {
+ p += 6;
+ if (strlcpy(info->type, p,
+ I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ return -ENOMEM;
+ return 0;
+ }
+
+ i = strlen(p) + 1;
+ p += i;
+ cplen -= i;
+ }
+
+ /* 3. take fist compatible entry and strip manufacturer */
+ p = strchr(compatible, ',');
+ if (!p)
+ return -ENODEV;
+ p++;
+ if (strlcpy(info->type, p, I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ return -ENOMEM;
+ return 0;
+}
+
+void of_register_i2c_devices(struct i2c_adapter *adap,
+ struct device_node *adap_node)
+{
+ void *result;
+ struct device_node *node;
+
+ for_each_child_of_node(adap_node, node) {
+ struct i2c_board_info info = {};
+ const u32 *addr;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
+ printk(KERN_ERR
+ "of-i2c: invalid i2c device entry\n");
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ if (of_find_i2c_driver(node, &info) < 0) {
+ irq_dispose_mapping(info.irq);
+ continue;
+ }
+
+ info.addr = *addr;
+
+ request_module(info.type);
+
+ result = i2c_new_device(adap, &info);
+ if (result == NULL) {
+ printk(KERN_ERR
+ "of-i2c: Failed to load driver for %s\n",
+ info.type);
+ irq_dispose_mapping(info.irq);
+ continue;
+ }
+ }
+}
+EXPORT_SYMBOL(of_register_i2c_devices);
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
new file mode 100644
index 0000000..2e5a967
--- /dev/null
+++ b/include/linux/of_i2c.h
@@ -0,0 +1,24 @@
+/*
+ * Generic I2C API implementation for PowerPC.
+ *
+ * Copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_OF_I2C_H
+#define __LINUX_OF_I2C_H
+
+#include <linux/i2c.h>
+
+#ifdef CONFIG_OF_I2C
+
+void of_register_i2c_devices(struct i2c_adapter *adap,
+ struct device_node *adap_node);
+
+#endif /* CONFIG_OF_I2C */
+
+#endif /* __LINUX_OF_I2C_H */
--
1.5.5
^ permalink raw reply related
* Re: build breakage from of i2c helper patch
From: Jochen Friedrich @ 2008-04-18 12:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Stephen Rothwell, Linux I2C, linuxppc-dev@ozlabs.org list
In-Reply-To: <18440.34234.28845.7398@cargo.ozlabs.ibm.com>
Hi Paul,
> Which way around is this dependency? Do you mean that the patches you
> listed depend on the "OF helpers for the i2c API" patch, or that the
> OF helpers patch depends on these other ones?
The OF helpers patch depends on the patches below to support autoloading
i2c modules using the alias mechanism. Otherwise, we need to translate
between i2c module type and driver_name in the helper patch (like currently
done in fsl_soc.c function of_find_i2c_driver()). However, this old way
doesn't really scale well.
>
>> http://patchwork.ozlabs.org/linuxppc/patch?id=17833
>> http://patchwork.ozlabs.org/linuxppc/patch?id=17834
>>
>> or the original ones from Jean Delvare:
>>
>> http://patchwork.ozlabs.org/linuxppc/patch?id=16282
>> http://patchwork.ozlabs.org/linuxppc/patch?id=16283
>> http://patchwork.ozlabs.org/linuxppc/patch?id=16284
>
> What's the best way to fix this now? We need to get a reasonable fix
> in before I ask Linux to pull the powerpc tree.
Thanks,
Jochen
^ permalink raw reply
* Re: build breakage from of i2c helper patch
From: Jochen Friedrich @ 2008-04-18 12:27 UTC (permalink / raw)
To: Jean Delvare
Cc: linuxppc-dev@ozlabs.org list, Stephen Rothwell, Paul Mackerras,
Linux I2C
In-Reply-To: <20080417113703.0f24c578@hyperion.delvare>
Hi Jean,
> (blind shot) Maybe this means that some code that is in i2c-core should
> be moved to i2c-boardinfo instead? i2c-boardinfo is always built into
> the kernel even when i2c-core is modular.
unfortunately, i2c_new_device() tries to attach the module, so this function
really needs full i2c-core functionality.
I think the best way to fix this is to make the OF helpers def_tristate I2C, so
it will be compiled as module if i2c-core is compiled as module, as well.
I'll send an updated patch in a minute.
Thanks,
Jochen
^ permalink raw reply
* pci issue - wrong detection of pci ressources
From: Christian Ehrhardt @ 2008-04-18 12:07 UTC (permalink / raw)
To: linuxppc-dev, Hollis Blanchard, Detlev Zundel, Wolfgang Denk
Hi,
I tried to use a radeon r200 based graphic card on a sequoia ppc (440epx) board. I wondered about the initialization of radeonfb that failed with
__ioremap(): phys addr 0x0 is RAM lr c029cf80
radeonfb (0000:00:0a.0): cannot map MMIO
radeonfb: probe of 0000:00:0a.0 failed with error -5
I trigger a check in ioremap, because the address it wants to remap is 0x0 which can never work. The reason of that is that the pci ressource of that graphic card is not properly detected.
With some help I found two kernels - one that work and one that has this issue.
Unfortunately they are very different:
good => 2.6.24.2 from the linux-2.6-denx - built for arch=ppc
bad => we have 2.6.25-rc9 (used in our kvm ppc project atm) - build for arch=powerpc
I tried building the 2.6.25-rc9 with arch=ppc, but that one does not boot so far. Because of that I can't surely tell you if it is only that difference that breaks the pci detection.
We need arch=powerpc for our kvm code anyway, so I hope there is another solution than to switch to arch=ppc ;-)
I just started to debug into that, but I wanted to ask here if there might be some known issues causing that and/or to get some hints where to look at.
The issue is much better visible when I boot with these two kernels and use "lspci -vvv"
Good kernel:
00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA])
Subsystem: PC Partner Limited Unknown device 0250
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min)
Interrupt: pin A routed to IRQ 67
Region 0: Memory at 88000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at ff00 [size=256]
Region 2: Memory at 87ff0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 80020000 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bad kernel:
00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA])
Subsystem: PC Partner Limited Unknown device 0250
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at 1000 [size=256]
Region 2: Memory at <ignored> (32-bit, non-prefetchable)
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
=> Region 2 is not detected with our kernel, this later break things like radeonfb initialization.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
P.S. I tested both pci slots of my board and both behave the same
^ permalink raw reply
* Re: [PATCH 3/3] Enable MSI support for 85xxds board.
From: Segher Boessenkool @ 2008-04-18 11:51 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <1208597267-30960-3-git-send-email-Jason.jin@freescale.com>
> + msi@41600 {
> + compatible = "fsl,MPIC-msi";
You need a more exact name here.
Also, where's the binding documentation?
Segher
^ permalink raw reply
* Patches added to powerpc.git master and powerpc-next branches
From: Paul Mackerras @ 2008-04-18 11:38 UTC (permalink / raw)
To: linuxppc-dev
I have pushed out the following commits to the master and powerpc-next
branches of the powerpc.git tree. This includes commits from Kumar's
and Jeremy's trees.
I am intending to ask Linus to pull the powerpc-next branch once we
have the breakage from the OF helpers for i2c patch sorted out.
Paul.
Alexander van Heukelum (1):
[POWERPC] Use asm-generic/bitops/find.h in bitops.h
Anton Vorontsov (9):
[POWERPC] QE: UCC nodes cleanup
[POWERPC] fsl_elbc_nand: factor out localbus defines
[POWERPC] fsl_lbc: implement few UPM routines
[POWERPC] QE: implement qe_muram_offset
[POWERPC] QE: immap_qe.h should include asm/io.h
[POWERPC] QE: export qe_get_brg_clk()
[POWERPC] QE: fix sparse warnings
[POWERPC] 83xx: mpc837x_rdb: add simple-bus compatible matching
[POWERPC] 83xx: mpc8315 - fix USB UTMI Host setup
Benjamin Herrenschmidt (3):
[POWERPC] Fix device-tree locking vs. interrupts
[POWERPC] Move stackframe definitions to common header
[POWERPC] irqtrace support for 64-bit powerpc
Christoph Hellwig (1):
[POWERPC] Stacktrace support for lockdep
Gerhard Stenzel (1):
[POWERPC] spufs: fix incorrect file descriptors in SPU coredump note names
Haiying Wang (1):
[POWERPC] 85xx: Fix the size of qe muram for MPC8568E
Jeremy Kerr (3):
[POWERPC] spufs: add newline to signal{1,2}_type files
[POWERPC] spufs: reacquire LS pointer in spu_process_callback
[POWERPC] spufs: save MFC command channel before purging MFC queue
Kumar Gala (8):
[POWERPC] Rework Book-E debug exception handling
[POWERPC] 83xx/85xx: Reorganize defconfigs
[POWERPC] Make Book-E debug handling SMP safe
[POWERPC] 83xx: Enable FCM NAND and OF partitions in defconfig
[POWERPC] 85xx: Fix compile warning
[POWERPC] 85xx: Convert dts to v1 syntax
[POWERPC] 85xx: minor .dts cleanups
[POWERPC] fsl: Convert dts to v1 syntax
Laurent Pinchart (6):
[POWERPC] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
[POWERPC] Add bootwrapper function to get virtual reg from the device tree.
[POWERPC] cpm-serial: Relocate CPM buffer descriptors and SMC parameter ram.
[POWERPC] ep8248e: Reference SMC parameter RAM base in the device tree.
[POWERPC] CPM2: Reset the CPM when early debugging is not enabled.
[POWERPC] CPM: Move opcodes common to CPM1 and CPM2 to include/asm-powerpc/cpm.h
Michael Ellerman (4):
[POWERPC] Move xics_setup_8259_cascade() into platforms/pseries/setup.c
[POWERPC] Turn xics_setup_8259_cascade() into a generic pseries_setup_i8259_cascade()
[POWERPC] Use pseries_setup_i8259_cascade() in pseries_mpic_init_IRQ()
[POWERPC] Simplify xics direct/lpar irq_host setup
Olof Johansson (1):
[POWERPC] Remove unused __max_memory variable
Paul Gortmaker (5):
[POWERPC] 86xx: Add support for Wind River SBC8641D board
[POWERPC] 86xx: Add defconfig for Wind River SBC8641D board
[POWERPC] 86xx: Add device tree source for Wind River SBC8641D
[POWERPC] 86xx: mark functions static, other minor cleanups
[POWERPC] 86xx: mpc86xx_hpcn - Temporarily accept old dts node identifier.
Paul Mackerras (1):
[POWERPC] Optimize fls64() on 64-bit processors
Scott Wood (4):
[POWERPC] CPM: Always use new binding.
[POWERPC] fsl_soc: Factor fsl_get_sys_freq() out of the wdt and spi inits.
[POWERPC] cuboot-pq2: PCI fixes
[POWERPC] 83xx: mpc8313erdb - Enable FCM NAND and OF partitions in defconfig
Sebastian Siewior (1):
[POWERPC] 85xx: Enable DMA engine on the MPC8544 DS
Timur Tabi (1):
[POWERPC] Make rheap safe for spinlocks
Trent Piepho (1):
[POWERPC] Make pci_bus_to_host()'s struct pci_bus * argument const
^ permalink raw reply
* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Laurent Pinchart @ 2008-04-18 11:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, netdev
In-Reply-To: <200804161809.40805.laurentp@cse-semaphore.com>
[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]
On Wednesday 16 April 2008 18:09, Laurent Pinchart wrote:
> On Wednesday 16 April 2008 18:05, Anton Vorontsov wrote:
> > On Wed, Apr 16, 2008 at 04:40:42PM +0200, Laurent Pinchart wrote:
> > > This patch converts the MII bitband driver to use GPIO lib for GPIO
> > > access. The driver can now handle MDC and MDIO on different GPIO banks.
> > >
> > > The patch depends on Anton Vorontsov GPIO lib support scheduled for
> > > 2.6.26. It is by no means complete, I just would like to get some
> > > feedback on the approach. I'll resubmit it when the CPM2 GPIO support
> > > patches will be available in the powerpc git tree.
> >
> > Cool! By the way, maybe it is worth splitting it into completely separate
> > driver, e.g. net/mdio_gpio.c?
>
> Splitting it into a completely separate driver makes sense.
>
> > Plus, keep in mind that somebody will eventually want this cool stuff with
> > platform_device bindings in addition. :-)
>
> I'm sure that person will be happy to implement platform_device bindings :-)
I had a first try at moving mdio gpio code into a separate driver.
Very little code is OF-independant, so the driver should probably be called
mdio_of_gpio.c or mdio_ofgpio.c.
Scott Wood was concerned in
http://patchwork.ozlabs.org/linuxppc/patch?id=17490 that the gpio lib might
be an unnecessary burden for memory-constraint platforms. Should we keep two
mdio bitbang drivers, one with direct access to the ports and one using gpio
lib ? The later solves the concurrent access issues present in the current
fs_enet mdio bitbang driber.
I'll submit a patch for whichever solution gets selected (modifying the
current fs enet mdio bitbang driver to use the gpio lib, or creating a new
driver).
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: build breakage from of i2c helper patch
From: Paul Mackerras @ 2008-04-18 11:27 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Stephen Rothwell, Linux I2C, linuxppc-dev@ozlabs.org list
In-Reply-To: <48071778.2000405@scram.de>
Jochen Friedrich writes:
> It looks like it. i2c-core needs to be compiled static for the OF
> bindings to work.
> I guess in Kconfig "depends on OF && I2C" must be changed into
> "depends on OF && (I2C=y)"
>
> On the other hand, i didn't test the patch without the dependent
> patches, so it might not work as expected:
Which way around is this dependency? Do you mean that the patches you
listed depend on the "OF helpers for the i2c API" patch, or that the
OF helpers patch depends on these other ones?
> http://patchwork.ozlabs.org/linuxppc/patch?id=17833
> http://patchwork.ozlabs.org/linuxppc/patch?id=17834
>
> or the original ones from Jean Delvare:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=16282
> http://patchwork.ozlabs.org/linuxppc/patch?id=16283
> http://patchwork.ozlabs.org/linuxppc/patch?id=16284
What's the best way to fix this now? We need to get a reasonable fix
in before I ask Linux to pull the powerpc tree.
Paul.
^ permalink raw reply
* Re: [PATCH 2.6.26?] Raise the upper limit of NR_CPUS.
From: Michael Ellerman @ 2008-04-18 10:33 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20080418053349.GE20457@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
On Fri, 2008-04-18 at 15:33 +1000, Tony Breeds wrote:
> As the pacas are statically initialised increasing NR_CPUS beyond 128,
> means that any additional pacas will be empty ... which is bad.
>
> This patch adds the required functionality to fill in any excess pacas
> at runtime.
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
> I know it's late, but can this be considered for 2.6.26?
>
> arch/powerpc/kernel/paca.c | 33 ++++++++++------------------
> arch/powerpc/kernel/prom_init.c | 36 ++++++++++++++++++++++++++++++++
> arch/powerpc/platforms/Kconfig.cputype | 4 +-
> include/asm-powerpc/paca.h | 19 ++++++++++++++++
What happens on non prom-init platforms?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] [POWERPC] sysdev: implement FSL GTM support
From: Anton Vorontsov @ 2008-04-18 9:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <E0A0E0FF-C2D5-432B-86A4-59AF23D3B63F@kernel.crashing.org>
On Thu, Apr 17, 2008 at 11:19:39PM -0500, Kumar Gala wrote:
[...]
>>> + * interval value, and fires the interrupt when the value is
>>> reached. This
>>> + * function will reduce the precision of the timer as needed in
>>> order for the
>>> + * requested timeout to fit in a 16-bit register.
>>> + */
>>> +int gtm_reset_timer16(struct gtm_timer *tmr, unsigned long usec,
>>> bool reload)
>>> +{
>>> + /* quite obvious, frequency which is enough for µSec precision */
>>> + int freq = 1000000;
>>> + unsigned int bit;
>>> +
>>> + bit = fls_long(usec);
>>> + if (bit > 15) {
>>> + freq >>= bit - 15;
>>> + usec >>= bit - 15;
>>> + }
>>
>> if (!freq)
>> return -EINVAL;
>
> do you want me to fix this up on commit or are you going to respin the
> patch set based on feedback?
I would better respin the whole thing. Will do this today.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 3/3] Enable MSI support for 85xxds board.
From: Jason Jin @ 2008-04-19 9:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Jason Jin
In-Reply-To: <1208597267-30960-2-git-send-email-Jason.jin@freescale.com>
This patch enabled MSI on 8544ds and 8572ds board.
only one MSI interrupt can generate on 8544 board.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
arch/powerpc/boot/dts/mpc8544ds.dts | 16 ++++++++++++++++
arch/powerpc/boot/dts/mpc8572ds.dts | 16 ++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 7 ++++++-
3 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts
index 6a0d8db..1059281 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -219,6 +219,22 @@
device_type = "open-pic";
big-endian;
};
+
+ msi@41600 {
+ compatible = "fsl,MPIC-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
};
pci0: pci@e0008000 {
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/boot/dts/mpc8572ds.dts
index 66f27ab..1c5ae9d 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -221,6 +221,22 @@
fsl,has-rstcr;
};
+ msi@41600 {
+ compatible = "fsl,MPIC-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
mpic: pic@40000 {
clock-frequency = <0>;
interrupt-controller;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index dfd8b4a..2696d2f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -79,9 +79,13 @@ void __init mpc85xx_ds_pic_init(void)
mpic = mpic_alloc(np, r.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
- 0, 256, " OpenPIC ");
+ 64, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
+ mpic_assign_isu(mpic, 0, r.start + 0x10000);
+ mpic_assign_isu(mpic, 1, r.start + 0x10800);
+ mpic_assign_isu(mpic, 2, r.start + 0x11600);
+
mpic_init(mpic);
#ifdef CONFIG_PPC_I8259
@@ -195,6 +199,7 @@ static int __init mpc85xxds_publish_devices(void)
return of_platform_bus_probe(NULL, mpc85xxds_ids, NULL);
}
machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices);
+machine_device_initcall(mpc8572_ds, mpc85xxds_publish_devices);
/*
* Called very early, device-tree isn't unflattened
--
1.5.4
^ permalink raw reply related
* [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
From: Jason Jin @ 2008-04-19 9:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Jason Jin
This MSI driver can be used on 83xx/85xx/86xx board.
In this driver, virtual interrupt host and chip were
setup. There are 256 MSI interrupts in this host, Every 32
MSI interrupts cascaded to one IPIC/MPIC interrupt.
The chip was treated as edge sensitive and some necessary
functions were setup for this chip.
Before using the MSI interrupt, PCI/PCIE device need to
ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
bitmap show which MSI interrupt was used, reserve bit in
the bitmap can be used to force the device use some designate
MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
for testing the all the MSI interrupts. The msi-available-ranges
property in the dts file was used for this purpose.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_msi.c | 457 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_msi.h | 40 ++++
arch/powerpc/sysdev/fsl_pci.c | 14 ++
4 files changed, 512 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_msi.c
create mode 100644 arch/powerpc/sysdev/fsl_msi.h
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 6d386d0..bfd3fe4 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,7 @@ endif
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+obj-$(CONFIG_PCI_MSI) += fsl_msi.o
obj-$(CONFIG_PPC_MPC106) += grackle.o
obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
new file mode 100644
index 0000000..e8132cf
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -0,0 +1,457 @@
+/*
+ * Copyright (C) 2007-2008 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Tony Li <tony.li@freescale.com>
+ * Jason Jin <Jason.jin@freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/irq.h>
+#include <linux/bootmem.h>
+#include <linux/bitmap.h>
+#include <linux/msi.h>
+#include <asm/prom.h>
+#include <asm/hw_irq.h>
+#include <linux/pci.h>
+#include <asm/ppc-pci.h>
+#include <linux/of_platform.h>
+
+#include <sysdev/fsl_soc.h>
+#include "fsl_msi.h"
+
+#ifdef DEBUG
+#define pr_debug(fmt...) printk(fmt)
+#else
+#define pr_debug(fmt...)
+#endif
+
+/* A bit ugly, can we get this from the pci_dev somehow? */
+static struct fsl_msi *fsl_msi;
+
+static inline u32 fsl_msi_read(u32 __iomem *base,
+ unsigned int reg)
+{
+ return in_be32(base + (reg >> 2));
+}
+
+static inline void fsl_msi_write(u32 __iomem *base,
+ unsigned int reg, u32 value)
+{
+ out_be32(base + (reg >> 2), value);
+}
+
+#define fsl_msi_irq_to_hw(virq) ((unsigned int)irq_map[virq].hwirq)
+
+/*
+ * We do not need this actually. The MSIR register has been read once
+ * in the cascade interrupt. So, this MSI interrupt has been acked
+*/
+static void fsl_msi_end_irq(unsigned int virq)
+{
+}
+
+static struct irq_chip fsl_msi_chip = {
+ .mask = mask_msi_irq,
+ .unmask = unmask_msi_irq,
+ .ack = fsl_msi_end_irq,
+ .typename = " FSL-MSI ",
+};
+
+static int fsl_msi_host_match(struct irq_host *h, struct device_node *node)
+{
+ struct fsl_msi *msi = h->host_data;
+
+ /* Exact match, unless node is NULL */
+ return msi->of_node == NULL || msi->of_node == node;
+}
+
+
+static int fsl_msi_host_map(struct irq_host *h, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ struct fsl_msi *msi = h->host_data;
+ struct irq_chip *chip = msi->hc_irq;
+
+ set_irq_chip_data(virq, msi);
+ get_irq_desc(virq)->status |= IRQ_TYPE_EDGE_FALLING;
+
+ set_irq_chip_and_handler(virq, chip, handle_edge_irq);
+
+ return 0;
+}
+
+static struct irq_host_ops fsl_msi_host_ops = {
+ .match = fsl_msi_host_match,
+ .map = fsl_msi_host_map,
+};
+
+irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
+{
+ unsigned long flags;
+ int offset, order = get_count_order(num);
+
+ spin_lock_irqsave(&msi->bitmap_lock, flags);
+
+ offset = bitmap_find_free_region(msi->fsl_msi_bitmap,
+ NR_MSI_IRQS, order);
+
+ spin_unlock_irqrestore(&msi->bitmap_lock, flags);
+
+ pr_debug("%s: allocated 0x%x (2^%d) at offset 0x%x\n",
+ __func__, num, order, offset);
+
+ return offset;
+}
+
+void fsl_msi_free_hwirqs(struct fsl_msi *msi, int offset, int num)
+{
+ unsigned long flags;
+ int order = get_count_order(num);
+
+ pr_debug("%s: freeing 0x%x (2^%d) at offset 0x%x\n",
+ __func__, num, order, offset);
+
+ spin_lock_irqsave(&msi->bitmap_lock, flags);
+ bitmap_release_region(msi->fsl_msi_bitmap, offset, order);
+ spin_unlock_irqrestore(&msi->bitmap_lock, flags);
+}
+
+static int fsl_msi_reserve_dt_hwirqs(struct fsl_msi *msi)
+{
+ int i, len;
+ const u32 *p;
+
+ p = of_get_property(msi->of_node, "msi-available-ranges", &len);
+ if (!p) {
+ pr_debug("fsl_msi: no msi-available-ranges property found \
+ on %s\n", msi->of_node->full_name);
+ return -ENODEV;
+ }
+
+ if (len & 0x8 != 0) {
+ printk(KERN_WARNING "fsl_msi: Malformed msi-available-ranges "
+ "property on %s\n", msi->of_node->full_name);
+ return -EINVAL;
+ }
+
+ bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
+ get_count_order(msi->irq_count));
+
+ /* Format is: (<u32 start> <u32 count>)+ */
+ len /= sizeof(u32);
+ len /= 2;
+ for (i = 0; i < len; i++, p += 2)
+ fsl_msi_free_hwirqs(msi, *p, *(p + 1));
+
+ return 0;
+}
+
+static int fsl_msi_init_allocator(struct fsl_msi *msi)
+{
+ int rc, size;
+
+ size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(long);
+
+ msi->fsl_msi_bitmap = kmalloc(size, GFP_KERNEL);
+
+ if (msi->fsl_msi_bitmap == NULL) {
+ pr_debug("%s: ENOMEM allocating allocator bitmap!\n",
+ __func__);
+ return -ENOMEM;
+ }
+ memset(msi->fsl_msi_bitmap, 0, size);
+
+ rc = fsl_msi_reserve_dt_hwirqs(msi);
+ if (rc)
+ goto out_free;
+
+ return 0;
+out_free:
+ if (mem_init_done)
+ kfree(msi->fsl_msi_bitmap);
+
+ msi->fsl_msi_bitmap = NULL;
+ return rc;
+
+}
+
+static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
+{
+ if (type == PCI_CAP_ID_MSIX)
+ pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
+
+ return 0;
+}
+
+static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
+{
+ struct msi_desc *entry;
+ struct fsl_msi *msi = fsl_msi;
+
+ list_for_each_entry(entry, &pdev->msi_list, list) {
+ if (entry->irq == NO_IRQ)
+ continue;
+ set_irq_msi(entry->irq, NULL);
+ fsl_msi_free_hwirqs(msi, virq_to_hw(entry->irq), 1);
+ irq_dispose_mapping(entry->irq);
+ }
+
+ return;
+}
+
+static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
+ struct msi_msg *msg)
+{
+ unsigned int srs;
+ unsigned int ibs;
+ struct fsl_msi *msi = fsl_msi;
+
+ srs = hwirq / INT_PER_MSIR;
+ ibs = hwirq % INT_PER_MSIR;
+
+ msg->address_lo = msi->msi_addr_lo;
+ msg->address_hi = msi->msi_addr_hi;
+ msg->data = (srs << 5) | (ibs & 0x1F);
+
+ pr_debug("%s: allocated srs: %d, ibs: %d\n",
+ __func__, srs, ibs);
+}
+
+static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
+{
+ irq_hw_number_t hwirq;
+ int rc;
+ unsigned int virq;
+ struct msi_desc *entry;
+ struct msi_msg msg;
+ struct fsl_msi *msi = fsl_msi;
+
+ list_for_each_entry(entry, &pdev->msi_list, list) {
+ hwirq = fsl_msi_alloc_hwirqs(msi, 1);
+ if (hwirq < 0) {
+ rc = hwirq;
+ pr_debug("%s: fail allocating msi interrupt\n",
+ __func__);
+ goto out_free;
+ }
+
+ virq = irq_create_mapping(msi->irqhost, hwirq);
+
+ if (virq == NO_IRQ) {
+ pr_debug("%s: fail mapping hwirq 0x%lx\n",
+ __func__, hwirq);
+ fsl_msi_free_hwirqs(msi, hwirq, 1);
+ rc = -ENOSPC;
+ goto out_free;
+ }
+ set_irq_msi(virq, entry);
+
+ fsl_compose_msi_msg(pdev, hwirq, &msg);
+ write_msi_msg(virq, &msg);
+ }
+ return 0;
+
+out_free:
+ fsl_teardown_msi_irqs(pdev);
+ return rc;
+}
+
+void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq;
+ struct fsl_msi *msi = fsl_msi;
+ int msir_index = -1;
+ int i;
+ u32 msir_value = 0;
+ u32 intr_index;
+ u32 have_shift = 0;
+
+ spin_lock(&desc->lock);
+ if ((msi->feature & FSL_PIC_IP_MASK) == FSL_PIC_IP_IPIC) {
+ if (desc->chip->mask_ack)
+ desc->chip->mask_ack(irq);
+ else {
+ desc->chip->mask(irq);
+ desc->chip->ack(irq);
+ }
+ }
+
+ if (unlikely(desc->status & IRQ_INPROGRESS))
+ goto unlock;
+
+ for (i = 0; i < NR_MSIR; i++)
+ if (irq == msi->msir[i]) {
+ msir_index = i;
+ break;
+ }
+
+ if (i >= NR_MSIR)
+ cascade_irq = NO_IRQ;
+
+ desc->status |= IRQ_INPROGRESS;
+ switch (fsl_msi->feature & FSL_PIC_IP_MASK) {
+ case FSL_PIC_IP_MPIC:
+ msir_value = fsl_msi_read(msi->msi_regs, msir_index * 0x10);
+ break;
+ case FSL_PIC_IP_IPIC:
+ msir_value = fsl_msi_read(msi->msi_regs, msir_index * 0x4);
+ break;
+ }
+
+ while (msir_value) {
+ intr_index = ffs(msir_value) - 1;
+
+ cascade_irq = irq_linear_revmap(msi->irqhost,
+ (msir_index * INT_PER_MSIR + intr_index + have_shift));
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+ have_shift += (intr_index + 1);
+ msir_value = (msir_value >> (intr_index + 1));
+ }
+ desc->status &= ~IRQ_INPROGRESS;
+
+ switch (fsl_msi->feature & FSL_PIC_IP_MASK) {
+ case FSL_PIC_IP_MPIC:
+ desc->chip->eoi(irq);
+ break;
+ case FSL_PIC_IP_IPIC:
+ if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+ desc->chip->unmask(irq);
+ break;
+ }
+unlock:
+ spin_unlock(&desc->lock);
+}
+
+static int __devinit fsl_of_msi_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ struct fsl_msi *msi;
+ struct resource res;
+ int err, i, count;
+ int rc;
+ int virt_msir;
+ const u32 *p;
+ struct fsl_msi_data *tmp_data;
+
+ printk(KERN_INFO "Setting up fsl msi support\n");
+
+ msi = kzalloc(sizeof(struct fsl_msi), GFP_KERNEL);
+ if (!msi) {
+ dev_err(&dev->dev, "No memory for MSI structure\n");
+ err = -ENOMEM;
+ goto error_out;
+ }
+
+ msi->of_node = dev->node;
+
+ msi->irqhost = irq_alloc_host(of_node_get(dev->node),
+ IRQ_HOST_MAP_LINEAR,
+ NR_MSI_IRQS, &fsl_msi_host_ops, 0);
+ if (msi->irqhost == NULL) {
+ dev_err(&dev->dev, "No memory for MSI irqhost\n");
+ err = -ENOMEM;
+ goto error_out;
+ }
+
+ /*Get the MSI reg base */
+ err = of_address_to_resource(dev->node, 0, &res);
+ if (err) {
+ dev_err(&dev->dev, "Can't get %s property 'reg'\n",
+ dev->node->full_name);
+ goto error_out;
+ }
+
+ msi->msi_regs = ioremap(res.start, res.end - res.start + 1);
+
+ tmp_data = (struct fsl_msi_data *)match->data;
+
+ msi->feature = tmp_data->fsl_pic_ip;
+
+ msi->irqhost->host_data = msi;
+ msi->hc_irq = &fsl_msi_chip;
+
+ msi->msi_addr_hi = 0x0;
+ msi->msi_addr_lo = res.start + tmp_data->msiir_offset;
+
+ msi->irq_count = NR_MSI_IRQS;
+
+ p = of_get_property(dev->node, "interrupts", &count);
+ if (!p) {
+ dev_err(&dev->dev, "no msi-interrupts property found on %s\n",
+ dev->node->full_name);
+ err = -ENODEV;
+ goto error_out;
+ }
+ if (count % 8 != 0) {
+ dev_err(&dev->dev, "Malformed msi-interrupts property on %s\n",
+ dev->node->full_name);
+ err = -EINVAL;
+ goto error_out;
+ }
+
+ count /= sizeof(u32);
+ for (i = 0; i < count / 2; i++) {
+ if (i > NR_MSIR)
+ break;
+ virt_msir = irq_of_parse_and_map(dev->node, i);
+ if (virt_msir != NO_IRQ) {
+ set_irq_data(virt_msir, msi);
+ set_irq_chained_handler(virt_msir, fsl_msi_cascade);
+ msi->msir[i] = virt_msir;
+ } else
+ msi->msir[i] = NO_IRQ;
+ }
+
+ rc = fsl_msi_init_allocator(msi);
+ if (rc) {
+ dev_err(&dev->dev, "Error allocating MSI bitmap\n");
+ goto error_out;
+ }
+
+ fsl_msi = msi;
+
+ WARN_ON(ppc_md.setup_msi_irqs);
+ ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
+ ppc_md.msi_check_device = fsl_msi_check_device;
+ return 0;
+error_out:
+ if (msi)
+ kfree(msi);
+ return err;
+}
+
+static const struct fsl_msi_data mpic_msi_feature = {FSL_PIC_IP_MPIC, 0x140};
+static const struct fsl_msi_data ipic_msi_feature = {FSL_PIC_IP_IPIC, 0x38};
+
+static const struct of_device_id fsl_of_msi_ids[] = {
+ {
+ .compatible = "fsl,MPIC-MSI",
+ .data = (void *)&mpic_msi_feature,
+ },
+ {
+ .compatible = "fsl,IPIC-MSI",
+ .data = (void *)&ipic_msi_feature,
+ },
+ {}
+};
+
+static struct of_platform_driver fsl_of_msi_driver = {
+ .name = "fsl-of-msi",
+ .match_table = fsl_of_msi_ids,
+ .probe = fsl_of_msi_probe,
+};
+
+static __init int fsl_of_msi_init(void)
+{
+ return of_register_platform_driver(&fsl_of_msi_driver);
+}
+
+subsys_initcall(fsl_of_msi_init);
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
new file mode 100644
index 0000000..7eef9ec
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -0,0 +1,40 @@
+#ifndef _ASM_POWERPC_MSI_H
+#define _ASM_POWERPC_MSI_H
+
+#define NR_MSIR 8
+#define INT_PER_MSIR 32
+#define NR_MSI_IRQS (NR_MSIR * INT_PER_MSIR)
+
+#define FSL_PIC_IP_MASK 0x0000000F
+#define FSL_PIC_IP_MPIC 0x00000001
+#define FSL_PIC_IP_IPIC 0x00000002
+
+struct fsl_msi {
+ /* Device node of the MSI interrupt*/
+ struct device_node *of_node;
+
+ struct irq_host *irqhost;
+ struct irq_chip *hc_irq;
+
+ unsigned long cascade_irq;
+ unsigned int msir[NR_MSIR];
+
+ u32 msi_addr_lo;
+ u32 msi_addr_hi;
+ void __iomem *msi_regs;
+ u32 irq_count;
+ u32 feature;
+
+ spinlock_t fsl_msi_lock;
+ unsigned long *fsl_msi_bitmap;
+ spinlock_t bitmap_lock;
+ const char *name;
+};
+
+struct fsl_msi_data {
+ u32 fsl_pic_ip;
+ u32 msiir_offset;
+};
+
+#endif /* _ASM_POWERPC_MSI_H */
+
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index bf13c21..fede767 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -106,6 +106,16 @@ void __init setup_pci_cmd(struct pci_controller *hose)
}
}
+#ifdef CONFIG_PCI_MSI
+void __init setup_pci_pcsrbar(struct pci_controller *hose)
+{
+ phys_addr_t immr_base;
+
+ immr_base = get_immrbase();
+ early_write_config_dword(hose, 0, 0, PCI_BASE_ADDRESS_0, immr_base);
+}
+#endif
+
static int fsl_pcie_bus_fixup;
static void __init quirk_fsl_pcie_header(struct pci_dev *dev)
@@ -211,6 +221,10 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
/* Setup PEX window registers */
setup_pci_atmu(hose, &rsrc);
+ /*Setup PEXCSRBAR */
+#ifdef CONFIG_PCI_MSI
+ setup_pci_pcsrbar(hose);
+#endif
return 0;
}
--
1.5.4
^ permalink raw reply related
* Re: [PATCH 3/3] Use __weak macro for smp_setup_processor_id
From: Andrew Morton @ 2008-04-18 8:38 UTC (permalink / raw)
To: benh; +Cc: Linux-Arch, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1208506747.6958.402.camel@pasglop>
On Fri, 18 Apr 2008 18:19:07 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Fri, 2008-04-18 at 00:07 -0700, Andrew Morton wrote:
> > On Fri, 18 Apr 2008 16:56:18 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > Use the __weak macro instead of the longer __attribute__ ((weak)) form
> > >
> > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > --
> > >
> > > init/main.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > --- linux-work.orig/init/main.c 2008-04-18 16:44:32.000000000 +1000
> > > +++ linux-work/init/main.c 2008-04-18 16:44:37.000000000 +1000
> > > @@ -500,7 +500,7 @@ static void __init boot_cpu_init(void)
> > > cpu_set(cpu, cpu_possible_map);
> > > }
> > >
> > > -void __init __attribute__((weak)) smp_setup_processor_id(void)
> > > +void __init __weak smp_setup_processor_id(void)
> > > {
> > > }
> >
> > ack on all three. Please fold #3 into #1 and add both to git-powerpc.
>
> Damn ! I took 5mn to actually split it out in order to not do two
> different things in one patch :-)
ah, I misread it. I thought this was changing the __attribute__((weak))
which patch #1 added. But it's changing a different one. I though that
was odd.
> Will do.
whatever ;)
^ permalink raw reply
* Re: [EFIKA] Really, don't pretend to be CHRP
From: Benjamin Herrenschmidt @ 2008-04-18 8:24 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, David Woodhouse, paulus
In-Reply-To: <48076A00.1080608@genesi-usa.com>
On Thu, 2008-04-17 at 16:17 +0100, Matt Sealey wrote:
>
> I said the kernel has had braindead patches shoved into it that sort
> of
> obviate the need for the most heinous of crimes committed in the Efika
> device tree.
>
> The Linux kernel fixups don't add the CDM or XLB arbiter or many other
> components some out-of-mainline drivers will need (and should be able
> to just access without writing a fixup first) to map to work properly.
> Adding these will clean up things like the UART module, Sylvain's
> sleep
> patches will work on Efika, etc.
What about you guys fix the firmware once for all instead of spamming
our mailboxes ?
> > can't set environment variables from within Linux (and yes, we can
> > probably improve on that too, but we let them setenv for themselves,
> for
> > now).
>
> You really won't be improving on it because there's no reliable way to
> pass setenv back to the firmware from userland :D
They aren't in nvram ? If they are and using the standard OF CHRP
format, then we can.
Ben.
^ permalink raw reply
* Re: [PATCH 02/11] Add udbg_console_anytime() which sets udbg console to CON_ANYTIME
From: Benjamin Herrenschmidt @ 2008-04-18 8:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <bdf32a463da3cf9603c0b0bd257ac5deedcbbfe0.1208505275.git.michael@ellerman.id.au>
On Fri, 2008-04-18 at 17:54 +1000, Michael Ellerman wrote:
> In theory the udbg console should be safe to call basically at any time
> after boot. It does not need any per-cpu resources or for the cpu to be
> online, as long as there is a udbg_putc routine hooked up it should
> work. So it should be able to be marked as CON_ANYTIME.
>
> Verifying this will take a bit of time and testing though, so instead of
> marking udbg console as CON_ANYTIME for all platforms, add a routine so
> that a platform can opt-in to having udbg console called early.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Nah, just stick it always.
Cheers,
Ben.
> ---
> arch/powerpc/kernel/udbg.c | 5 +++++
> include/asm-powerpc/udbg.h | 1 +
> 2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
> index 9ac5f3a..7b1fd86 100644
> --- a/arch/powerpc/kernel/udbg.c
> +++ b/arch/powerpc/kernel/udbg.c
> @@ -158,6 +158,11 @@ static struct console udbg_console = {
> .index = 0,
> };
>
> +void udbg_console_anytime(void)
> +{
> + udbg_console.flags |= CON_ANYTIME;
> +}
> +
> static int early_console_initialized;
>
> /*
> diff --git a/include/asm-powerpc/udbg.h b/include/asm-powerpc/udbg.h
> index 6418cee..102fa91 100644
> --- a/include/asm-powerpc/udbg.h
> +++ b/include/asm-powerpc/udbg.h
> @@ -23,6 +23,7 @@ extern int udbg_write(const char *s, int n);
> extern int udbg_read(char *buf, int buflen);
>
> extern void register_early_udbg_console(void);
> +extern void udbg_console_anytime(void);
> extern void udbg_printf(const char *fmt, ...)
> __attribute__ ((format (printf, 1, 2)));
> extern void udbg_progress(char *s, unsigned short hex);
^ permalink raw reply
* Re: [PATCH 3/3] Use __weak macro for smp_setup_processor_id
From: Benjamin Herrenschmidt @ 2008-04-18 8:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux-Arch, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20080418000717.5a9c9758.akpm@linux-foundation.org>
On Fri, 2008-04-18 at 00:07 -0700, Andrew Morton wrote:
> On Fri, 18 Apr 2008 16:56:18 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Use the __weak macro instead of the longer __attribute__ ((weak)) form
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > --
> >
> > init/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- linux-work.orig/init/main.c 2008-04-18 16:44:32.000000000 +1000
> > +++ linux-work/init/main.c 2008-04-18 16:44:37.000000000 +1000
> > @@ -500,7 +500,7 @@ static void __init boot_cpu_init(void)
> > cpu_set(cpu, cpu_possible_map);
> > }
> >
> > -void __init __attribute__((weak)) smp_setup_processor_id(void)
> > +void __init __weak smp_setup_processor_id(void)
> > {
> > }
>
> ack on all three. Please fold #3 into #1 and add both to git-powerpc.
Damn ! I took 5mn to actually split it out in order to not do two
different things in one patch :-)
Will do.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Fix kernel stack allocation alignment
From: Benjamin Herrenschmidt @ 2008-04-18 8:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux-Arch, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20080418000618.0c46c78f.akpm@linux-foundation.org>
> so... the "0" defeats all of SLAB_DEBUG_FREE, SLAB_RED_ZONE, SLAB_POISON
> and SLAB_STORE_USER, if the comment in slab.h is to be believed.
>
> Was that overkill?
Well, I copied over from something else, looks like there's a -lot- of 0
users here...
Shouldn't there be some kind of SLAB_DEFAULT that contain those things ?
Ben.
^ permalink raw reply
* Re: mpc5200: add interrupt type function
From: Sascha Hauer @ 2008-04-18 8:19 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804162341h5e68e460t975f69118ff8beca@mail.gmail.com>
On Wed, Apr 16, 2008 at 11:41:08PM -0700, Grant Likely wrote:
> On Wed, Apr 16, 2008 at 11:00 PM, Robert Schwebel
> <r.schwebel@pengutronix.de> wrote:
> > On Tue, Apr 15, 2008 at 05:29:54PM +0200, Robert Schwebel wrote:
> > > From: Sascha Hauer <s.hauer@pengutronix.de>
> > >
> > > Add a set_type function for external (GPIO) interrupts.
> > >
> > > Signed-off-by: Juergen Beisert <j.beisert@pengutronix.de>
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >
> > As we didn't get negative feedback yet, could this go into the 2.6.26
> > merge window?
>
> I didn't see this the first time (didn't get cc'd).
>
> It looks mostly okay, but in doesn't have any mutual exclusion which
> it probably should have. What are the users of this?
No, it is used in kernel/irq/chip.c and kernel/irq/manage.c. Both
callers already hold the mpc52xx_extirq_irqchip.lock spinlock.
Sascha
--
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
^ permalink raw reply
* [PATCH 11/11] Add CONFIG_PPC_PSERIES_DEBUG to enable debugging for platforms/pseries
From: Michael Ellerman @ 2008-04-18 7:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fbb91d0892c720d6f28501e1830028c78eb6664f.1208505275.git.michael@ellerman.id.au>
Add a DEBUG config setting which turns on all (most) of the debugging
under platforms/pseries.
To have this take effect we need to remove all the #undef DEBUG's, in
various files. We leave the #undef DEBUG in platforms/pseries/lpar.c,
as this enables debugging printks from the low-level hash table routines,
and tends to make your system unusable. If you want those enabled you
still have to turn them on by hand.
Also some of the RAS code has a DEBUG block which causes a functional
change, so I've keyed this off a different (non-existant) debug #define.
This is only enabled if you have PPC_EARLY_DEBUG enabled also.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/Kconfig | 5 +++++
arch/powerpc/platforms/pseries/Makefile | 4 ++++
arch/powerpc/platforms/pseries/eeh.c | 1 -
arch/powerpc/platforms/pseries/eeh_cache.c | 1 -
arch/powerpc/platforms/pseries/firmware.c | 1 -
arch/powerpc/platforms/pseries/ras.c | 4 +---
arch/powerpc/platforms/pseries/setup.c | 2 --
arch/powerpc/platforms/pseries/smp.c | 1 -
arch/powerpc/platforms/pseries/xics.c | 1 -
9 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 306a9d0..07fe5b6 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -34,3 +34,8 @@ config LPARCFG
help
Provide system capacity information via human readable
<key word>=<value> pairs through a /proc/ppc64/lparcfg interface.
+
+config PPC_PSERIES_DEBUG
+ depends on PPC_PSERIES && PPC_EARLY_DEBUG
+ bool "Enable extra debug logging in platforms/pseries"
+ default y
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index bdae04b..bd2593e 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -2,6 +2,10 @@ ifeq ($(CONFIG_PPC64),y)
EXTRA_CFLAGS += -mno-minimal-toc
endif
+ifeq ($(CONFIG_PPC_PSERIES_DEBUG),y)
+EXTRA_CFLAGS += -DDEBUG
+endif
+
obj-y := lpar.o hvCall.o nvram.o reconfig.o \
setup.o iommu.o ras.o rtasd.o \
firmware.o power.o
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 550b2f7..a3fd56b 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -39,7 +39,6 @@
#include <asm/ppc-pci.h>
#include <asm/rtas.h>
-#undef DEBUG
/** Overview:
* EEH, or "Extended Error Handling" is a PCI bridge technology for
diff --git a/arch/powerpc/platforms/pseries/eeh_cache.c b/arch/powerpc/platforms/pseries/eeh_cache.c
index 1e83fcd..ce37040 100644
--- a/arch/powerpc/platforms/pseries/eeh_cache.c
+++ b/arch/powerpc/platforms/pseries/eeh_cache.c
@@ -28,7 +28,6 @@
#include <asm/pci-bridge.h>
#include <asm/ppc-pci.h>
-#undef DEBUG
/**
* The pci address cache subsystem. This subsystem places
diff --git a/arch/powerpc/platforms/pseries/firmware.c b/arch/powerpc/platforms/pseries/firmware.c
index 743d494..9d3a40f 100644
--- a/arch/powerpc/platforms/pseries/firmware.c
+++ b/arch/powerpc/platforms/pseries/firmware.c
@@ -21,7 +21,6 @@
* 2 of the License, or (at your option) any later version.
*/
-#undef DEBUG
#include <asm/firmware.h>
#include <asm/prom.h>
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index a1ab25c..2b548af 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -67,8 +67,6 @@ static int ras_check_exception_token;
static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
-/* #define DEBUG */
-
static void request_ras_irqs(struct device_node *np,
irq_handler_t handler,
@@ -237,7 +235,7 @@ static irqreturn_t ras_error_interrupt(int irq, void *dev_id)
printk(KERN_EMERG "Error: Fatal hardware error <0x%lx 0x%x>\n",
*((unsigned long *)&ras_log_buf), status);
-#ifndef DEBUG
+#ifndef DEBUG_RTAS_POWER_OFF
/* Don't actually power off when debugging so we can test
* without actually failing while injecting errors.
* Error data will not be logged to syslog.
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 5486bea..efc8df4 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -16,8 +16,6 @@
* bootup setup stuff..
*/
-#undef DEBUG
-
#include <linux/cpu.h>
#include <linux/errno.h>
#include <linux/sched.h>
diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
index e9bc2a5..9d8f8c8 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -12,7 +12,6 @@
* 2 of the License, or (at your option) any later version.
*/
-#undef DEBUG
#include <linux/kernel.h>
#include <linux/module.h>
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index a977f20..738f005 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -9,7 +9,6 @@
* 2 of the License, or (at your option) any later version.
*/
-#undef DEBUG
#include <linux/types.h>
#include <linux/threads.h>
--
1.5.5
^ permalink raw reply related
* [PATCH 10/11] Convert from DEBUG() to pr_debug() in platforms/pseries/scanlog.c
From: Michael Ellerman @ 2008-04-18 7:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fbb91d0892c720d6f28501e1830028c78eb6664f.1208505275.git.michael@ellerman.id.au>
While we're at it, remove the hand-rolled runtime debugging support
in there. This file has been largely unchanged for eons, if we need to
debug it in future we can recompile.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/scanlog.c | 23 ++++++++---------------
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/scanlog.c b/arch/powerpc/platforms/pseries/scanlog.c
index e5b0ea8..bec3803 100644
--- a/arch/powerpc/platforms/pseries/scanlog.c
+++ b/arch/powerpc/platforms/pseries/scanlog.c
@@ -38,9 +38,7 @@
#define SCANLOG_HWERROR -1
#define SCANLOG_CONTINUE 1
-#define DEBUG(A...) do { if (scanlog_debug) printk(KERN_ERR "scanlog: " A); } while (0)
-static int scanlog_debug;
static unsigned int ibm_scan_log_dump; /* RTAS token */
static struct proc_dir_entry *proc_ppc64_scan_log_dump; /* The proc file */
@@ -86,14 +84,14 @@ static ssize_t scanlog_read(struct file *file, char __user *buf,
memcpy(data, rtas_data_buf, RTAS_DATA_BUF_SIZE);
spin_unlock(&rtas_data_buf_lock);
- DEBUG("status=%d, data[0]=%x, data[1]=%x, data[2]=%x\n",
- status, data[0], data[1], data[2]);
+ pr_debug("scanlog: status=%d, data[0]=%x, data[1]=%x, " \
+ "data[2]=%x\n", status, data[0], data[1], data[2]);
switch (status) {
case SCANLOG_COMPLETE:
- DEBUG("hit eof\n");
+ pr_debug("scanlog: hit eof\n");
return 0;
case SCANLOG_HWERROR:
- DEBUG("hardware error reading scan log data\n");
+ pr_debug("scanlog: hardware error reading data\n");
return -EIO;
case SCANLOG_CONTINUE:
/* We may or may not have data yet */
@@ -110,7 +108,8 @@ static ssize_t scanlog_read(struct file *file, char __user *buf,
/* Assume extended busy */
wait_time = rtas_busy_delay_time(status);
if (!wait_time) {
- printk(KERN_ERR "scanlog: unknown error from rtas: %d\n", status);
+ printk(KERN_ERR "scanlog: unknown error " \
+ "from rtas: %d\n", status);
return -EIO;
}
}
@@ -134,15 +133,9 @@ static ssize_t scanlog_write(struct file * file, const char __user * buf,
if (buf) {
if (strncmp(stkbuf, "reset", 5) == 0) {
- DEBUG("reset scanlog\n");
+ pr_debug("scanlog: reset scanlog\n");
status = rtas_call(ibm_scan_log_dump, 2, 1, NULL, 0, 0);
- DEBUG("rtas returns %d\n", status);
- } else if (strncmp(stkbuf, "debugon", 7) == 0) {
- printk(KERN_ERR "scanlog: debug on\n");
- scanlog_debug = 1;
- } else if (strncmp(stkbuf, "debugoff", 8) == 0) {
- printk(KERN_ERR "scanlog: debug off\n");
- scanlog_debug = 0;
+ pr_debug("scanlog: rtas returns %d\n", status);
}
}
return count;
--
1.5.5
^ permalink raw reply related
* [PATCH 09/11] Convert from DEBUG() to pr_debug() in platforms/pseries/rtasd.c
From: Michael Ellerman @ 2008-04-18 7:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fbb91d0892c720d6f28501e1830028c78eb6664f.1208505275.git.michael@ellerman.id.au>
Add "rtasd" to some messages to make it clear where they're coming from.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/rtasd.c | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index e3078ce..befadd4 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -29,11 +29,6 @@
#include <asm/atomic.h>
#include <asm/machdep.h>
-#if 0
-#define DEBUG(A...) printk(KERN_ERR A)
-#else
-#define DEBUG(A...)
-#endif
static DEFINE_SPINLOCK(rtasd_log_lock);
@@ -198,7 +193,7 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
unsigned long s;
int len = 0;
- DEBUG("logging event\n");
+ pr_debug("rtasd: logging event\n");
if (buf == NULL)
return;
@@ -409,7 +404,8 @@ static int rtasd(void *unused)
daemonize("rtasd");
printk(KERN_DEBUG "RTAS daemon started\n");
- DEBUG("will sleep for %d milliseconds\n", (30000/rtas_event_scan_rate));
+ pr_debug("rtasd: will sleep for %d milliseconds\n",
+ (30000 / rtas_event_scan_rate));
/* See if we have any error stored in NVRAM */
memset(logdata, 0, rtas_error_log_max);
@@ -428,9 +424,9 @@ static int rtasd(void *unused)
do_event_scan_all_cpus(1000);
if (surveillance_timeout != -1) {
- DEBUG("enabling surveillance\n");
+ pr_debug("rtasd: enabling surveillance\n");
enable_surveillance(surveillance_timeout);
- DEBUG("surveillance enabled\n");
+ pr_debug("rtasd: surveillance enabled\n");
}
/* Delay should be at least one second since some
--
1.5.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox