* Re: General question : Debugging Kernel on PPC
From: McClintock Matthew-B29882 @ 2012-02-02 16:07 UTC (permalink / raw)
To: Arshad, Farrukh; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <93CD5F41FDBC6042A6B449764F3B35CC050CECE7@EU-MBX-03.mgc.mentorg.com>
On Thu, Feb 2, 2012 at 2:59 AM, Arshad, Farrukh
<Farrukh_Arshad@mentor.com> wrote:
> Greetings All,
>
> I have general question regarding kernel debugging on PowerPC platform.
> Except printk what are other ways for kernel / kernel modules debugging o=
n
> PowerPC architecture (i.e P1022DS/RDK boards). I am specifically referrin=
g
> to the option of connecting hardware probe and debug the kernel / kernel
> module via gdb/kgdb or some IDE. Please suggest any probe & IDE which
> provide this facility.
BDI(2|3)000 and gdb works pretty well, then there are USBTAPs from
Freescale and CodeWarrior. You could also use an RTL simulator like
simics for this part which has a lot of advanced features.
-M=
^ permalink raw reply
* [PATCH] Implement GET_IP/SET_IP for powerpc architecture.
From: Srikar Dronamraju @ 2012-02-02 14:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev; +Cc: Mike Frysinger
With this change, helpers such as instruction_pointer() et al, get defined
in the generic header in terms of GET_IP
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
---
arch/powerpc/include/asm/ptrace.h | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 78a2051..889408d 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -83,8 +83,20 @@ struct pt_regs {
#ifndef __ASSEMBLY__
-#define instruction_pointer(regs) ((regs)->nip)
-#define user_stack_pointer(regs) ((regs)->gpr[1])
+#define GET_IP(regs) ((regs)->nip)
+#define GET_USP(regs) ((regs)->gpr[1])
+#define GET_FP(regs) (0)
+#define SET_FP(regs, val)
+
+#ifdef CONFIG_SMP
+extern unsigned long profile_pc(struct pt_regs *regs);
+#define profile_pc profile_pc
+#else
+#define profile_pc(regs) GET_IP(regs)
+#endif
+
+#include <asm-generic/ptrace.h>
+
#define kernel_stack_pointer(regs) ((regs)->gpr[1])
static inline int is_syscall_success(struct pt_regs *regs)
{
@@ -99,12 +111,6 @@ static inline long regs_return_value(struct pt_regs *regs)
return -regs->gpr[3];
}
-#ifdef CONFIG_SMP
-extern unsigned long profile_pc(struct pt_regs *regs);
-#else
-#define profile_pc(regs) instruction_pointer(regs)
-#endif
-
#ifdef __powerpc64__
#define user_mode(regs) ((((regs)->msr) >> MSR_PR_LG) & 0x1)
#else
^ permalink raw reply related
* Re: [PATCH v2] powerpc/usb: fix issue of CPU halt when missing USB PHY clock
From: Sergei Shtylyov @ 2012-02-02 11:39 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1328152994-2879-1-git-send-email-Shengzhou.Liu@freescale.com>
Hello.
On 02-02-2012 7:23, Shengzhou Liu wrote:
> when missing USB PHY clock, kernel booting up will halt during USB
> initialization. We should check USBGP[PHY_CLK_VALID] bit to avoid
> CPU hang in this case.
> Signed-off-by: Shengzhou Liu<Shengzhou.Liu@freescale.com>
[...]
> diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
> index 4918062..dd3dc47 100644
> --- a/drivers/usb/host/ehci-fsl.h
> +++ b/drivers/usb/host/ehci-fsl.h
> @@ -45,5 +45,6 @@
> #define FSL_SOC_USB_PRICTRL 0x40c /* NOTE: big-endian */
> #define FSL_SOC_USB_SICTRL 0x410 /* NOTE: big-endian */
> #define FSL_SOC_USB_CTRL 0x500 /* NOTE: big-endian */
> +#define CTRL_PHY_CLK_VALID (1 << 17)
Indent the macro value with tabs please.
WBR, Sergei
^ permalink raw reply
* General question : Debugging Kernel on PPC
From: Arshad, Farrukh @ 2012-02-02 8:59 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 443 bytes --]
Greetings All,
I have general question regarding kernel debugging on PowerPC platform. Except printk what are other ways for kernel / kernel modules debugging on PowerPC architecture (i.e P1022DS/RDK boards). I am specifically referring to the option of connecting hardware probe and debug the kernel / kernel module via gdb/kgdb or some IDE. Please suggest any probe & IDE which provide this facility.
Best Regards
Farrukh Arshad
[-- Attachment #2: Type: text/html, Size: 2555 bytes --]
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix issue of CPU halt when missing USB PHY clock
From: Liu Shengzhou-B36685 @ 2012-02-02 3:31 UTC (permalink / raw)
To: Pavan Kondeti; +Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F290FCF.1040406@codeaurora.org>
> -----Original Message-----
> From: Pavan Kondeti [mailto:pkondeti@codeaurora.org]
> Sent: Wednesday, February 01, 2012 6:11 PM
> To: Liu Shengzhou-B36685
> Cc: linux-usb@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/usb: fix issue of CPU halt when missing
> USB PHY clock
>=20
> On 2/1/2012 2:50 PM, Shengzhou Liu wrote:
> > diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-
> fsl.c
> > index b556a72..834237e 100644
> > --- a/drivers/usb/host/ehci-fsl.c
> > +++ b/drivers/usb/host/ehci-fsl.c
> > @@ -239,7 +239,7 @@ static void ehci_fsl_setup_phy(struct ehci_hcd
> *ehci,
> > ehci_writel(ehci, portsc, &ehci->regs->port_status[port_offset]);
> > }
> >
> > -static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
> > +static int ehci_fsl_usb_setup(struct ehci_hcd *ehci)
> > {
> > struct usb_hcd *hcd =3D ehci_to_hcd(ehci);
> > struct fsl_usb2_platform_data *pdata; @@ -299,12 +299,19 @@
> static
> > void ehci_fsl_usb_setup(struct ehci_hcd *ehci) #endif
> > out_be32(non_ehci + FSL_SOC_USB_SICTRL, 0x00000001);
> > }
> > +
> > + if (!(in_be32(non_ehci + FSL_SOC_USB_CTRL) & CTRL_PHY_CLK_VALID))
> {
> > + printk(KERN_WARNING "fsl-ehci: USB PHY clock invalid\n");
> > + return -1;
>=20
> Please return a proper error code. -ENODEV ?
[Shengzhou] Ok, updated in v2, thanks.
>=20
> > + }
> > + return 0;
> > }
> >
> --
> Sent by a consultant of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum.
^ permalink raw reply
* [PATCH v2] powerpc/usb: fix issue of CPU halt when missing USB PHY clock
From: Shengzhou Liu @ 2012-02-02 3:23 UTC (permalink / raw)
To: linux-usb; +Cc: linuxppc-dev, Shengzhou Liu
when missing USB PHY clock, kernel booting up will halt during USB
initialization. We should check USBGP[PHY_CLK_VALID] bit to avoid
CPU hang in this case.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
v2: changes: return -ENODEV instead of -1
drivers/usb/host/ehci-fsl.c | 11 +++++++++--
drivers/usb/host/ehci-fsl.h | 1 +
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index b556a72..c26a82e 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -239,7 +239,7 @@ static void ehci_fsl_setup_phy(struct ehci_hcd *ehci,
ehci_writel(ehci, portsc, &ehci->regs->port_status[port_offset]);
}
-static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
+static int ehci_fsl_usb_setup(struct ehci_hcd *ehci)
{
struct usb_hcd *hcd = ehci_to_hcd(ehci);
struct fsl_usb2_platform_data *pdata;
@@ -299,12 +299,19 @@ static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
#endif
out_be32(non_ehci + FSL_SOC_USB_SICTRL, 0x00000001);
}
+
+ if (!(in_be32(non_ehci + FSL_SOC_USB_CTRL) & CTRL_PHY_CLK_VALID)) {
+ printk(KERN_WARNING "fsl-ehci: USB PHY clock invalid\n");
+ return -ENODEV;
+ }
+ return 0;
}
/* called after powerup, by probe or system-pm "wakeup" */
static int ehci_fsl_reinit(struct ehci_hcd *ehci)
{
- ehci_fsl_usb_setup(ehci);
+ if (ehci_fsl_usb_setup(ehci))
+ return -ENODEV;
ehci_port_power(ehci, 0);
return 0;
diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
index 4918062..dd3dc47 100644
--- a/drivers/usb/host/ehci-fsl.h
+++ b/drivers/usb/host/ehci-fsl.h
@@ -45,5 +45,6 @@
#define FSL_SOC_USB_PRICTRL 0x40c /* NOTE: big-endian */
#define FSL_SOC_USB_SICTRL 0x410 /* NOTE: big-endian */
#define FSL_SOC_USB_CTRL 0x500 /* NOTE: big-endian */
+#define CTRL_PHY_CLK_VALID (1 << 17)
#define SNOOP_SIZE_2GB 0x1e
#endif /* _EHCI_FSL_H */
--
1.6.4
^ permalink raw reply related
* Efika (mpc5200b): sound doesn't build/work from linux-2.6.38.x
From: acrux @ 2012-02-02 2:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jon Smirl
[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]
board: Genesi Efika (MPC5200B)
problem: unable to use sound subsystem instead it works fine with linux-2.6.36.4 (+ device tree supplement, attached) .
With linux-2.6.38.8 and linux-2.6.39.4 it doesn't build.
That's from my build log:
[...]
LD sound/soc/blackfin/built-in.o
LD sound/soc/codecs/built-in.o
CC [M] sound/soc/codecs/stac9766.o
LD [M] sound/soc/codecs/snd-soc-stac9766.o
LD sound/soc/davinci/built-in.o
LD sound/soc/ep93xx/built-in.o
LD sound/soc/fsl/built-in.o
CC [M] sound/soc/fsl/mpc5200_dma.o
sound/soc/fsl/mpc5200_dma.c:372:16: warning: 'struct of_device' declared inside parameter list
sound/soc/fsl/mpc5200_dma.c:372:16: warning: its scope is only this definition or declaration, which is probably not what you want
sound/soc/fsl/mpc5200_dma.c: In function 'mpc5200_hpcd_probe':
sound/soc/fsl/mpc5200_dma.c:383:31: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:384:31: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:385:14: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:390:14: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:402:27: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:414:20: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:428:14: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:475:21: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:478:38: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c: At top level:
sound/soc/fsl/mpc5200_dma.c:490:39: warning: 'struct of_device' declared inside parameter list
sound/soc/fsl/mpc5200_dma.c: In function 'mpc5200_hpcd_remove':
sound/soc/fsl/mpc5200_dma.c:492:47: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:494:2: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:496:33: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c:508:21: error: dereferencing pointer to incomplete type
sound/soc/fsl/mpc5200_dma.c: At top level:
sound/soc/fsl/mpc5200_dma.c:522:2: error: unknown field 'owner' specified in initializer
sound/soc/fsl/mpc5200_dma.c:522:2: warning: initialization from incompatible pointer type
sound/soc/fsl/mpc5200_dma.c:523:2: error: unknown field 'name' specified in initializer
sound/soc/fsl/mpc5200_dma.c:523:2: warning: initialization from incompatible pointer type
sound/soc/fsl/mpc5200_dma.c:524:2: error: unknown field 'match_table' specified in initializer
sound/soc/fsl/mpc5200_dma.c:524:2: warning: initialization from incompatible pointer type
sound/soc/fsl/mpc5200_dma.c:525:2: warning: initialization from incompatible pointer type
sound/soc/fsl/mpc5200_dma.c:526:2: warning: initialization from incompatible pointer type
make[3]: *** [sound/soc/fsl/mpc5200_dma.o] Error 1
make[2]: *** [sound/soc/fsl] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
With linux-3.0.18, linux-3.1.10 and linux-3.2.2 it builds but doesn't work.
That's from my dmesg:
[...]
asoc: error - multiple DAI f0002200.sound registered with no name
mpc5200-psc-ac97 f0002200.sound: Failed to register DAI
mpc5200-psc-ac97: probe of f0002200.sound failed with error -22
best,
--nico
--
acrux <acrux@cruxppc.org>
[-- Attachment #2: efika.forth.gz --]
[-- Type: application/octet-stream, Size: 2518 bytes --]
^ permalink raw reply
* [RFC] Removing support for legacy iSeries
From: Benjamin Herrenschmidt @ 2012-02-02 2:36 UTC (permalink / raw)
To: linuxppc-dev
Cc: Stephen Rothwell, Anton Blanchard, Linus Torvalds,
Linux Kernel list, Paul Mackerras
So I (and Stephen) believe the time has come that we get rid of the
legacy iSeries support in the kernel....
Is there any objection ? Do we have any user left ?
The hypervisor on these is really nasty, and removing support for it
would allow us to clean up quite a bit of code path including low level
& asm ones from iSeries special cases.
Also it's becoming increasingly hard for me to test that we are still
capable of booting these.
I will keep it if we have users but since distros don't support it
anymore (and haven't for a while now) I am pretty keen.
Any objection ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH][v2] powerpc/85xx: Fix compiler error with THIS_MODULE and related
From: Paul Gortmaker @ 2012-02-02 2:34 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: linuxppc-dev
In-Reply-To: <1328115915-16172-1-git-send-email-claudiu.manoil@freescale.com>
On Wed, Feb 1, 2012 at 12:05 PM, Claudiu Manoil
<claudiu.manoil@freescale.com> wrote:
> CC =A0 =A0 =A0arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:209:13: error: 'THIS_MODULE' undecl=
ared here (not in a function)
Looks OK to me -- must be the 1st time this code has been
merged into the 3.2 baseline, since the export.h change was
news in the last release, and not anything new for 3.3.
Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Paul.
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:20: error: expected declaration=
specifiers or '...' before string constant
> cc1: warnings being treated as errors
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:1: error: data definition has n=
o type or storage class
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:1: error: type defaults to 'int=
' in declaration of 'MODULE_DESCRIPTION'
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:20: error: function declaration=
isn't a prototype
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:16: error: expected declaration=
specifiers or '...' before string constant
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:1: error: data definition has n=
o type or storage class
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:1: error: type defaults to 'int=
' in declaration of 'MODULE_LICENSE'
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:16: error: function declaration=
isn't a prototype
> make[1]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
>
> ...
>
> =A0CC =A0 =A0 =A0arch/powerpc/sysdev/fsl_85xx_cache_sram.o
> cc1: warnings being treated as errors
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: data definition ha=
s no type or storage class
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: type defaults to '=
int' in declaration of 'EXPORT_SYMBOL'
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: parameter names (w=
ithout types) in function declaration
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: data definition ha=
s no type or storage class
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: type defaults to '=
int' in declaration of 'EXPORT_SYMBOL'
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: parameter names (w=
ithout types) in function declaration
> make[1]: *** [arch/powerpc/sysdev/fsl_85xx_cache_sram.o] Error 1
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> ---
> Replaced <linux/module.h> with <linux/export.h> for fsl_85xx_cache_sram.c=
.
>
> =A0arch/powerpc/sysdev/fsl_85xx_cache_sram.c | =A0 =A01 +
> =A0arch/powerpc/sysdev/fsl_85xx_l2ctlr.c =A0 =A0 | =A0 =A01 +
> =A02 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sys=
dev/fsl_85xx_cache_sram.c
> index 1164158..37a6909 100644
> --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> @@ -24,6 +24,7 @@
> =A0*/
>
> =A0#include <linux/kernel.h>
> +#include <linux/export.h>
> =A0#include <linux/slab.h>
> =A0#include <linux/err.h>
> =A0#include <linux/of_platform.h>
> diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/=
fsl_85xx_l2ctlr.c
> index 5f88797..1957e53 100644
> --- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
> +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
> @@ -21,6 +21,7 @@
> =A0*/
>
> =A0#include <linux/kernel.h>
> +#include <linux/module.h>
> =A0#include <linux/of_platform.h>
> =A0#include <asm/io.h>
>
> --
> 1.6.6
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: MPC5200B FEC TX packets getting stuck
From: Joey Nelson @ 2012-02-02 2:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAL_WD7hYZoaB87vZzj4Fk9nsHYSoe+qWq87g72ERLAkMur5vYg@mail.gmail.com>
First I think the spin_locks in the irq handlers should be
spin_lock_irqsave(), because the same lock is used in multiple irq
handlers. If we get an rx interrupt while the tx interrupt holds the
spin lock, this would seem to be a problem. In this case maybe not
because it is a single processor system and spin_locks should compile
to nothing(I haven't verified this), and the rx and tx handlers don't
really touch any common data elements. I haven't tested changing
this, because I've currently running a long test.
On another front, I put some time stamp tracing into the
mpc52xx_fec_start_xmit, and verified that the delay is happening after
the packet is added the the BestComm ring buffer. There will be 3
quick calls to the xmit, but I'll only see 2 packets at the PC, until
200 - 400 ms later, when I'll get another xmit call (for the
retransmit), and then get two duplicate packets at pc.
Attempting to add time stamping to the TX irq handler have revealed
this to be a Heisenbug of sorts. After the following changes, I
haven't seen any delays two hours of running. Previously every minute
of so.
I'll let it run over night and see if I see an additional delays.
Next I'll remove the timestamp code, and attempt to capture the state
of the ring buffer and BestComm at the point the retransmit packet is
handed off to the driver. The delayed packet has to be somewhere at
that point. I could be in the FEC Queue, as I don't think I've seen a
delayed packet larger than 1k.
@@ -382,6 +414,8 @@
=A0 =A0 =A0dev_kfree_skb_irq(skb);
=A0 }
=A0 spin_unlock(&priv->lock);
+ =A0 js_irq_timestamps[js_irq_idx] =3D get_tbl();
+ =A0 js_irq_idx =3D (js_irq_idx+1 =3D=3D TS_COUNT)? 0 : js_irq_idx+1;
=A0 =A0 netif_wake_queue(dev);
@@ -409,6 +443,7 @@
Joey Nelson
On Fri, Jan 27, 2012 at 12:14 PM, Joey Nelson <joey@joescan.com> wrote:
>
>
> In my application, I have a PC connected through TCP to a MPC5200B based =
system. =A0The PC sends a short request, the MPC5200B=A0receives=A0the requ=
est and sends the data back. =A0It is doing this about 300 times per second=
. =A0Normally exchange happens in just handful of milliseconds. =A0But rand=
omly every 2 to 15 minutes the MPC5200B sends all but the last packet of th=
e response, and about 200ms later the PC sends a delayed ACK, and the MPC52=
00B TCP stack figures the packet was lost. =A0It then sends two nearly iden=
tical packets (The IP header Identification and Checksum fields are increme=
nted). =A0I can also see that RetransSegs in /proc/net/snmp increments by o=
ne for each of these delays.
>
> My theory is that the packet is getting suck somewhere in the network sta=
ck (most likely toward the bottom). =A0Then when another packet is sent, th=
e suck one gets pushed out.
>
> I've done a test where I have another task on the MPC5200B sending UDP pa=
ckets to a different PC every 10ms. =A0This eliminated the long delays, and=
seems to support my stuck packet theory.
>
> I'm seeing the same issue with 2.6.23 and 3.1.6.
>
> I'm getting ready to dive into the hairy world of Bestcomm and FEC, but I=
figured I'd see if anyone else has any suggestions before I make my decent=
. =A0Has anyone seen this=A0behavior=A0before? =A0Any likely candidates for=
where the packet is getting stuck? =A0General advice for reference materia=
ls (I've started on Linux Device Drivers 3rd Ed, BestComm AN2604, and the D=
atasheets)
>
> Thanks in advance.
>
> Joey Nelson
> joey@joescan.com
>
^ permalink raw reply
* Re: [PATCH] powerpc: Define cpus_in_crash only for SMP kernels
From: Paul E. McKenney @ 2012-02-01 23:15 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: mikey, linuxppc-dev, linux-kernel, paulus, anton, ben
In-Reply-To: <4F29A072.9050203@windriver.com>
On Wed, Feb 01, 2012 at 03:28:34PM -0500, Paul Gortmaker wrote:
> On 12-02-01 01:55 PM, Paul E. McKenney wrote:
> > The variable cpus_in_crash gets a defined-but-not-used warning when
> > CONFIG_SMP=n, so fix by placing the variable under ifdef.
>
> I think Ben already merged a similar fix.
>
> http://patchwork.ozlabs.org/patch/136549/
>
> P.
Linus's tree does now have cpus_in_crash, so agreed. Sorry for the
noise!
Thanx, Paul
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >
> > diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> > index 28be345..eb3384e 100644
> > --- a/arch/powerpc/kernel/crash.c
> > +++ b/arch/powerpc/kernel/crash.c
> > @@ -46,7 +46,9 @@
> >
> > /* This keeps a track of which one is the crashing cpu. */
> > int crashing_cpu = -1;
> > +#ifdef CONFIG_SMP
> > static atomic_t cpus_in_crash;
> > +#endif /* #ifdef CONFIG_SMP */
> > static int time_to_dump;
> >
> > #define CRASH_HANDLER_MAX 3
> >
>
^ permalink raw reply
* [PATCH 07/15] PCI, powerpc: Register busn_res for root buses
From: Yinghai Lu @ 2012-02-01 22:43 UTC (permalink / raw)
To: Jesse Barnes, Benjamin Herrenschmidt, Tony Luck
Cc: linux-arch, linux-pci, linuxppc-dev, linux-kernel,
Dominik Brodowski, Yinghai Lu, Bjorn Helgaas, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <1328136242-17725-1-git-send-email-yinghai@kernel.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/pci-common.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index cce98d7..501f29b 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1732,6 +1732,8 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)
bus->secondary = hose->first_busno;
hose->bus = bus;
+ pci_bus_insert_busn_res(bus, hose->first_busno, hose->last_busno);
+
/* Get probe mode and perform scan */
mode = PCI_PROBE_NORMAL;
if (node && ppc_md.pci_probe_mode)
@@ -1742,8 +1744,11 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)
of_scan_bus(node, bus);
}
- if (mode == PCI_PROBE_NORMAL)
+ if (mode == PCI_PROBE_NORMAL) {
+ pci_bus_update_busn_res_end(bus, 255);
hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);
+ pci_bus_update_busn_res_end(bus, bus->subordinate);
+ }
/* Platform gets a chance to do some global fixups before
* we proceed to resource allocation
--
1.7.7
^ permalink raw reply related
* Re: [PATCH] powerpc: Define cpus_in_crash only for SMP kernels
From: Paul Gortmaker @ 2012-02-01 20:28 UTC (permalink / raw)
To: paulmck; +Cc: mikey, linuxppc-dev, linux-kernel, paulus, anton, ben
In-Reply-To: <20120201185510.GA8542@linux.vnet.ibm.com>
On 12-02-01 01:55 PM, Paul E. McKenney wrote:
> The variable cpus_in_crash gets a defined-but-not-used warning when
> CONFIG_SMP=n, so fix by placing the variable under ifdef.
I think Ben already merged a similar fix.
http://patchwork.ozlabs.org/patch/136549/
P.
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> index 28be345..eb3384e 100644
> --- a/arch/powerpc/kernel/crash.c
> +++ b/arch/powerpc/kernel/crash.c
> @@ -46,7 +46,9 @@
>
> /* This keeps a track of which one is the crashing cpu. */
> int crashing_cpu = -1;
> +#ifdef CONFIG_SMP
> static atomic_t cpus_in_crash;
> +#endif /* #ifdef CONFIG_SMP */
> static int time_to_dump;
>
> #define CRASH_HANDLER_MAX 3
>
^ permalink raw reply
* [PATCH] powerpc: Define cpus_in_crash only for SMP kernels
From: Paul E. McKenney @ 2012-02-01 18:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey, linux-kernel, paul.gortmaker, paulus, anton, ben
The variable cpus_in_crash gets a defined-but-not-used warning when
CONFIG_SMP=n, so fix by placing the variable under ifdef.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 28be345..eb3384e 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -46,7 +46,9 @@
/* This keeps a track of which one is the crashing cpu. */
int crashing_cpu = -1;
+#ifdef CONFIG_SMP
static atomic_t cpus_in_crash;
+#endif /* #ifdef CONFIG_SMP */
static int time_to_dump;
#define CRASH_HANDLER_MAX 3
^ permalink raw reply related
* Re: [PATCH v3 22/25] irq_domain/x86: Convert x86 (embedded) to use common irq_domain
From: Grant Likely @ 2012-02-01 18:06 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120201141705.GF9587@linutronix.de>
On Wed, Feb 1, 2012 at 7:17 AM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> * Grant Likely | 2012-01-30 12:58:42 [-0700]:
>
>>Ugh. =A0This isn't easy. =A0The legacy mapping really needs all the
>
> Feel free to merge this patch. I don't have the time to look at this now
> so I take a look at the ioapic later.
There's no rush here. I can leave it as-is with IRQ_DOMAIN turned off
for x86 for now.
g.
^ permalink raw reply
* [PATCH][v2] powerpc/85xx: Fix compiler error with THIS_MODULE and related
From: Claudiu Manoil @ 2012-02-01 17:05 UTC (permalink / raw)
To: linuxppc-dev
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:209:13: error: 'THIS_MODULE' undeclared here (not in a function)
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:20: error: expected declaration specifiers or '...' before string constant
cc1: warnings being treated as errors
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:1: error: data definition has no type or storage class
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:1: error: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:20: error: function declaration isn't a prototype
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:16: error: expected declaration specifiers or '...' before string constant
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:1: error: data definition has no type or storage class
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:1: error: type defaults to 'int' in declaration of 'MODULE_LICENSE'
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:16: error: function declaration isn't a prototype
make[1]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
...
CC arch/powerpc/sysdev/fsl_85xx_cache_sram.o
cc1: warnings being treated as errors
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: data definition has no type or storage class
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: parameter names (without types) in function declaration
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: data definition has no type or storage class
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: parameter names (without types) in function declaration
make[1]: *** [arch/powerpc/sysdev/fsl_85xx_cache_sram.o] Error 1
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
Replaced <linux/module.h> with <linux/export.h> for fsl_85xx_cache_sram.c.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 +
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index 1164158..37a6909 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -24,6 +24,7 @@
*/
#include <linux/kernel.h>
+#include <linux/export.h>
#include <linux/slab.h>
#include <linux/err.h>
#include <linux/of_platform.h>
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
index 5f88797..1957e53 100644
--- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -21,6 +21,7 @@
*/
#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/of_platform.h>
#include <asm/io.h>
--
1.6.6
^ permalink raw reply related
* Re: Question about GPIO Lib
From: Mark Brown @ 2012-02-01 16:53 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linuxppc-dev, Bruce_Leonard
In-Reply-To: <CADkCAus2r-dzXsHEa6nRAgrz-v+AnmbSDBeVcHHzmM=FcwgePg@mail.gmail.com>
On Wed, Feb 01, 2012 at 09:56:45AM -0600, Bill Gatliff wrote:
> On Wed, Feb 1, 2012 at 6:32 AM, Mark Brown <broonie@sirena.org.uk> wrote:
> > Just to expand on this a bit: lots of people would prefer not to have a
> > userspace component at all due to the same hardware safety concerns that
> > you have, or to have the userspace component be a driver using gpiolib
> > which needs to be explicitly connected to the GPIOs.
> ... which I think is a spectacularly bad idea. :)
> Diversion from the original theme of this thread notwithstanding, I
> don't see the point in the additional complexity of implementing such
> a heavy-handed lockout when it's pretty darned easy to just do a
> gpio_request() in kernel space to take the pin entirely away from
> users. I do that pretty routinely, but then in the relevant
Well, it's about the default - some people feel a lot safer blocking
everything by default and then enabling particular signals they want
userspace to control. That default is more annoying for people who want
to do debug but a lot less controversial in terms of things possibly
going wrong.
> I have often considered a gpiolib patch that just makes sysfs
> attributes read-only when kernel-side does a gpio_request(), rather
> than taking the pin attributes away entirely. That way I can have
> simple tools in userspace to silently log GPIO activity for
> troubleshooting. The blocking reads that some versions of gpiolib
> offer today make this work even better.
That's a useful idea.
^ permalink raw reply
* Re: Question about GPIO Lib
From: Bill Gatliff @ 2012-02-01 15:56 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, Bruce_Leonard
In-Reply-To: <20120201123231.GB13723@sirena.org.uk>
Mark:
On Wed, Feb 1, 2012 at 6:32 AM, Mark Brown <broonie@sirena.org.uk> wrote:
>
> Just to expand on this a bit: lots of people would prefer not to have a
> userspace component at all due to the same hardware safety concerns that
> you have, or to have the userspace component be a driver using gpiolib
> which needs to be explicitly connected to the GPIOs.
... which I think is a spectacularly bad idea. :)
Diversion from the original theme of this thread notwithstanding, I
don't see the point in the additional complexity of implementing such
a heavy-handed lockout when it's pretty darned easy to just do a
gpio_request() in kernel space to take the pin entirely away from
users. I do that pretty routinely, but then in the relevant
kernel-side driver I almost always offer a sysfs attribute of my own
that lets me grant users controlled access to the functionality
provided by the pin.
For example, if it's a RESET-type pin for an external chip, then I'll
have a /sys/.../assert_reset attribute such that when root writes to
it, my store() method sends a timed pulse to the physical GPIO pin. Or
not, depending on what mood the device is in at the time--- which the
driver always knows.
I won't let the user kill anyone, of course, but I WILL grant them
tools like the above to bring the platform under control and
investigate problems during hardware integration. The productivity
improvement more than offsets the thought and code investment
required.
I have often considered a gpiolib patch that just makes sysfs
attributes read-only when kernel-side does a gpio_request(), rather
than taking the pin attributes away entirely. That way I can have
simple tools in userspace to silently log GPIO activity for
troubleshooting. The blocking reads that some versions of gpiolib
offer today make this work even better.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* [PATCH] powerpc/dts: Added aliased MSIIR register address to MSI node in dts
From: Diana Craciun @ 2012-02-01 15:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Diana CRACIUN
From: Diana CRACIUN <Diana.Craciun@freescale.com>
The MSIIR register for each MSI bank is aliased to a different
address. The MSI node reg property was updated to contain this
address:
e.g. reg = <0x41600 0x200 0x44140 4>;
The first region contains the address and length of the MSI
register set and the second region contains the address of
the aliased MSIIR register at 0x44140.
Signed-off-by: Diana CRACIUN <Diana.Craciun@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/msi-pic.txt | 6 ++++--
arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi | 6 +++---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
index 5d586e1..5693877 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
@@ -6,8 +6,10 @@ Required properties:
etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
the parent type.
-- reg : should contain the address and the length of the shared message
- interrupt register set.
+- reg : It may contain one or two regions. The first region should contain
+ the address and the length of the shared message interrupt register set.
+ The second region should contain the address of aliased MSIIR register for
+ platforms that have such an alias.
- msi-available-ranges: use <start count> style section to define which
msi interrupt can be used in the 256 msi interrupts. This property is
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
index b9bada6..08f4227 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
@@ -53,7 +53,7 @@ timer@41100 {
msi0: msi@41600 {
compatible = "fsl,mpic-msi";
- reg = <0x41600 0x200>;
+ reg = <0x41600 0x200 0x44140 4>;
msi-available-ranges = <0 0x100>;
interrupts = <
0xe0 0 0 0
@@ -68,7 +68,7 @@ msi0: msi@41600 {
msi1: msi@41800 {
compatible = "fsl,mpic-msi";
- reg = <0x41800 0x200>;
+ reg = <0x41800 0x200 0x45140 4>;
msi-available-ranges = <0 0x100>;
interrupts = <
0xe8 0 0 0
@@ -83,7 +83,7 @@ msi1: msi@41800 {
msi2: msi@41a00 {
compatible = "fsl,mpic-msi";
- reg = <0x41a00 0x200>;
+ reg = <0x41a00 0x200 0x46140 4>;
msi-available-ranges = <0 0x100>;
interrupts = <
0xf0 0 0 0
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH][upstream] Added aliased MSIIR register address to MSI node in dts
From: Diana CRACIUN @ 2012-02-01 15:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1328110836-343-1-git-send-email-diana.craciun@freescale.com>
Please ignore this, I put a wrong subject.
Thanks,
Diana
On 02/01/2012 05:40 PM, Diana Craciun wrote:
> From: Diana CRACIUN<Diana.Craciun@freescale.com>
>
> The MSIIR register for each MSI bank is aliased to a different
> address. The MSI node reg property was updated to contain this
> address:
>
> e.g. reg =<0x41600 0x200 0x44140 4>;
>
> The first region contains the address and length of the MSI
> register set and the second region contains the address of
> the aliased MSIIR register at 0x44140.
>
> Signed-off-by: Diana CRACIUN<Diana.Craciun@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/msi-pic.txt | 6 ++++--
> arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi | 6 +++---
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
> index 5d586e1..5693877 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
> @@ -6,8 +6,10 @@ Required properties:
> etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
> the parent type.
>
> -- reg : should contain the address and the length of the shared message
> - interrupt register set.
> +- reg : It may contain one or two regions. The first region should contain
> + the address and the length of the shared message interrupt register set.
> + The second region should contain the address of aliased MSIIR register for
> + platforms that have such an alias.
>
> - msi-available-ranges: use<start count> style section to define which
> msi interrupt can be used in the 256 msi interrupts. This property is
> diff --git a/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
> index b9bada6..08f4227 100644
> --- a/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
> @@ -53,7 +53,7 @@ timer@41100 {
>
> msi0: msi@41600 {
> compatible = "fsl,mpic-msi";
> - reg =<0x41600 0x200>;
> + reg =<0x41600 0x200 0x44140 4>;
> msi-available-ranges =<0 0x100>;
> interrupts =<
> 0xe0 0 0 0
> @@ -68,7 +68,7 @@ msi0: msi@41600 {
>
> msi1: msi@41800 {
> compatible = "fsl,mpic-msi";
> - reg =<0x41800 0x200>;
> + reg =<0x41800 0x200 0x45140 4>;
> msi-available-ranges =<0 0x100>;
> interrupts =<
> 0xe8 0 0 0
> @@ -83,7 +83,7 @@ msi1: msi@41800 {
>
> msi2: msi@41a00 {
> compatible = "fsl,mpic-msi";
> - reg =<0x41a00 0x200>;
> + reg =<0x41a00 0x200 0x46140 4>;
> msi-available-ranges =<0 0x100>;
> interrupts =<
> 0xf0 0 0 0
^ permalink raw reply
* [PATCH][upstream] Added aliased MSIIR register address to MSI node in dts
From: Diana Craciun @ 2012-02-01 15:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Diana CRACIUN
From: Diana CRACIUN <Diana.Craciun@freescale.com>
The MSIIR register for each MSI bank is aliased to a different
address. The MSI node reg property was updated to contain this
address:
e.g. reg = <0x41600 0x200 0x44140 4>;
The first region contains the address and length of the MSI
register set and the second region contains the address of
the aliased MSIIR register at 0x44140.
Signed-off-by: Diana CRACIUN <Diana.Craciun@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/msi-pic.txt | 6 ++++--
arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi | 6 +++---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
index 5d586e1..5693877 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
@@ -6,8 +6,10 @@ Required properties:
etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
the parent type.
-- reg : should contain the address and the length of the shared message
- interrupt register set.
+- reg : It may contain one or two regions. The first region should contain
+ the address and the length of the shared message interrupt register set.
+ The second region should contain the address of aliased MSIIR register for
+ platforms that have such an alias.
- msi-available-ranges: use <start count> style section to define which
msi interrupt can be used in the 256 msi interrupts. This property is
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
index b9bada6..08f4227 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
@@ -53,7 +53,7 @@ timer@41100 {
msi0: msi@41600 {
compatible = "fsl,mpic-msi";
- reg = <0x41600 0x200>;
+ reg = <0x41600 0x200 0x44140 4>;
msi-available-ranges = <0 0x100>;
interrupts = <
0xe0 0 0 0
@@ -68,7 +68,7 @@ msi0: msi@41600 {
msi1: msi@41800 {
compatible = "fsl,mpic-msi";
- reg = <0x41800 0x200>;
+ reg = <0x41800 0x200 0x45140 4>;
msi-available-ranges = <0 0x100>;
interrupts = <
0xe8 0 0 0
@@ -83,7 +83,7 @@ msi1: msi@41800 {
msi2: msi@41a00 {
compatible = "fsl,mpic-msi";
- reg = <0x41a00 0x200>;
+ reg = <0x41a00 0x200 0x46140 4>;
msi-available-ranges = <0 0x100>;
interrupts = <
0xf0 0 0 0
--
1.7.3.4
^ permalink raw reply related
* Re: [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
From: Vinod Koul @ 2012-02-01 14:39 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Jassi Brar, linux-kernel, Alexandre Bounine, akpm, linuxppc-dev,
dan.j.williams, Russell King
In-Reply-To: <Pine.LNX.4.64.1202011234180.24739@axis700.grange>
On Wed, 2012-02-01 at 12:58 +0100, Guennadi Liakhovetski wrote:
> > The two things are completely orthogonal and shouldn't be clubbed.
> > For your issue we need a separate debate on how to solve this... I am
> > open to ideas...
>
> Well, I'm not sure whether they are necessarily always orthogonal, they
> don't seem so in my case at least. We definitely can use our approach -
> configure the channel during allocation. I _think_ we could also perform
> the configuration on a per-transfer basis, during the prepare stage, as
> this RFC is suggesting, but that definitely would require reworking the
> driver somewhat and changing the concept. The current concept is a fixed
> DMA channel allocation to slaves for as long as the slave is using DMA.
> This is simpler, avoids some overhead during operation and fits well with
> the dmaengine PRIVATE channel concept. So, given the choice, we would
> prefer to perform the configuration during channel allocation.
>
> Maybe there are cases, where the driver absolutely needs this additional
> information during allocation, in which case my proposal would be the only
> way to go for them.
what are you trying to address, sending controller specific information
at allocation or the channel allocation itself. I kind of sense both.
But apprach here is discussed is to pass paramters which are required
for each transfer, not static for a channel, hence the additional
controller specific parameter in respective prepare.
>
> I'll post an RFC soon - stay tuned:-)
Patch is always the best idea :-)
--
~Vinod
^ permalink raw reply
* Re: [PATCH v3 22/25] irq_domain/x86: Convert x86 (embedded) to use common irq_domain
From: Sebastian Andrzej Siewior @ 2012-02-01 14:17 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120130195842.GT28397@ponder.secretlab.ca>
* Grant Likely | 2012-01-30 12:58:42 [-0700]:
>Ugh. This isn't easy. The legacy mapping really needs all the
Feel free to merge this patch. I don't have the time to look at this now
so I take a look at the ioapic later.
>g.
Sebastian
^ permalink raw reply
* Re: Question about GPIO Lib
From: Mark Brown @ 2012-02-01 12:32 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linuxppc-dev, Bruce_Leonard
In-Reply-To: <CADkCAuvkWvBLbDwhDFBdZ0mGoPv5HyZSD-ivXPyTKbMo_9GXvg@mail.gmail.com>
On Tue, Jan 31, 2012 at 10:39:05AM -0600, Bill Gatliff wrote:
> I'm just saying that, sadly, in many ways gpiolib is still a
> work-in-progress. The userspace component has been somewhat
> controversial in general over the years, and definitely lacks several
> key features in addition to the one you are asking for.
Just to expand on this a bit: lots of people would prefer not to have a
userspace component at all due to the same hardware safety concerns that
you have, or to have the userspace component be a driver using gpiolib
which needs to be explicitly connected to the GPIOs.
^ permalink raw reply
* Re: [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
From: Guennadi Liakhovetski @ 2012-02-01 11:58 UTC (permalink / raw)
To: Vinod Koul
Cc: Jassi Brar, linux-kernel, Alexandre Bounine, akpm, linuxppc-dev,
dan.j.williams, Russell King
In-Reply-To: <1328075003.1610.6.camel@vkoul-udesk3>
On Wed, 1 Feb 2012, Vinod Koul wrote:
> On Wed, 2012-02-01 at 01:09 +0100, Guennadi Liakhovetski wrote:
> > On Mon, 30 Jan 2012, Vinod Koul wrote:
> >
> > > On Thu, 2012-01-26 at 16:22 -0500, Alexandre Bounine wrote:
> > > > As we agreed during our discussion about adding DMA Engine support for RapidIO
> > > > subsystem, RapidIO and similar clients may benefit from adding an extra context
> > > > parameter to device_prep_slave_sg() callback.
> > > > See https://lkml.org/lkml/2011/10/24/275 for more details.
> > > >
> > > > Adding the context parameter will allow to pass client/target specific
> > > > information associated with an individual data transfer request.
> > > >
> > > > In the case of RapidIO support this additional information consists of target
> > > > destination ID and its buffer address (which is not mapped into the local CPU
> > > > memory space). Because a single RapidIO-capable DMA channel may queue data
> > > > transfer requests to different target devices, the per-request configuration
> > > > is required.
> > > >
> > > > The proposed change eliminates need for new subsystem-specific API.
> > > > Existing DMA_SLAVE clients will ignore the new parameter.
> > > >
> > > > This RFC only demonstrates the API change and does not include corresponding
> > > > changes to existing DMA_SLAVE clients. Complete set of patches will be provided
> > > > after (if) this API change is accepted.
> > > This looks good to me. But was thinking if we need to add this new
> > > parameter for other slave calls (circular, interleaved, memcpy...)
> >
> > Yes, we (shdma.c) also need to pass additional slave configuration
> > information to the dmaengine driver and I also was thinking about
> > extending the existing API, but my ideas were going more in the direction
> > of adding a parameter to __dma_request_channel() along the lines of
> So your question is more on the lines of channel mapping/allocation?
> The approach here is to pass controller specific parameters which are
> required to setup the respective transfer. Since this is dependent on
> each transfer, this needs to be passed in respective prepare.
>
> The two things are completely orthogonal and shouldn't be clubbed.
> For your issue we need a separate debate on how to solve this... I am
> open to ideas...
Well, I'm not sure whether they are necessarily always orthogonal, they
don't seem so in my case at least. We definitely can use our approach -
configure the channel during allocation. I _think_ we could also perform
the configuration on a per-transfer basis, during the prepare stage, as
this RFC is suggesting, but that definitely would require reworking the
driver somewhat and changing the concept. The current concept is a fixed
DMA channel allocation to slaves for as long as the slave is using DMA.
This is simpler, avoids some overhead during operation and fits well with
the dmaengine PRIVATE channel concept. So, given the choice, we would
prefer to perform the configuration during channel allocation.
Maybe there are cases, where the driver absolutely needs this additional
information during allocation, in which case my proposal would be the only
way to go for them.
I'll post an RFC soon - stay tuned:-)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
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