* 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
* 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
* [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: [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] 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] 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 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 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
* 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][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
* [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
* 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
* [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
* 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
* 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 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
* [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: 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
* Re: [PATCH] Implement GET_IP/SET_IP for powerpc architecture.
From: Mike Frysinger @ 2012-02-02 16:28 UTC (permalink / raw)
To: Srikar Dronamraju; +Cc: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20120202144125.GA6221@linux.vnet.ibm.com>
[-- Attachment #1: Type: Text/Plain, Size: 314 bytes --]
On Thursday 02 February 2012 09:41:25 Srikar Dronamraju wrote:
> +#define GET_FP(regs) (0)
> +#define SET_FP(regs, val)
ppc doesn't have a standard FP location ?
> +#define profile_pc(regs) GET_IP(regs)
pretty sure you don't need this as asm-generic/ptrace.h already has a
definition for you
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] Implement GET_IP/SET_IP for powerpc architecture.
From: Srikar Dronamraju @ 2012-02-02 16:36 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <201202021128.49188.vapier@gentoo.org>
* Mike Frysinger <vapier@gentoo.org> [2012-02-02 11:28:46]:
> On Thursday 02 February 2012 09:41:25 Srikar Dronamraju wrote:
> > +#define GET_FP(regs) (0)
> > +#define SET_FP(regs, val)
>
> ppc doesn't have a standard FP location ?
>
> > +#define profile_pc(regs) GET_IP(regs)
>
> pretty sure you don't need this as asm-generic/ptrace.h already has a
> definition for you
On ppc64, profile_pc is an extern function if CONFIG_SMP is set.
else its same as whats defined in asm-generic/ptrace.h
Now if we allow asm-generic/ptrace.h definition to take effect, then
powerpc/time.h (where the actual profile_pc is defined as an extern
function) fails with an error for redefinition.
Hence our approach was to define profile_pc before asm-generic/ptrace.h
gets included. One change that we could do was to define profile_pc
only under CONFIG_SMP. But I think it makes the code less confusing.
Otherwise people might keep wondering why profile_pc is defined only for
CONFIG_SMP case.
--
Thanks and Regards
Srikar
^ permalink raw reply
* Re: Efika (mpc5200b): sound doesn't build/work from linux-2.6.38.x
From: acrux @ 2012-02-02 16:57 UTC (permalink / raw)
To: acrux; +Cc: linuxppc-dev, Jon Smirl
In-Reply-To: <20120202034803.2fb7690b.acrux_it@libero.it>
On Thu, 2 Feb 2012 03:48:03 +0100
acrux <acrux_it@libero.it> wrote:
> 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
>
>
well, i got the same error with also linux-2.6.37. Btw, this was already reported about a year ago:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088415.html
--
acrux <acrux_it@libero.it>
^ permalink raw reply
* Re: [PATCH] Implement GET_IP/SET_IP for powerpc architecture.
From: Mike Frysinger @ 2012-02-02 17:02 UTC (permalink / raw)
To: Srikar Dronamraju; +Cc: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20120202163659.GD31984@linux.vnet.ibm.com>
[-- Attachment #1: Type: Text/Plain, Size: 525 bytes --]
On Thursday 02 February 2012 11:36:59 Srikar Dronamraju wrote:
> * Mike Frysinger <vapier@gentoo.org> [2012-02-02 11:28:46]:
> > On Thursday 02 February 2012 09:41:25 Srikar Dronamraju wrote:
> > > +#define profile_pc(regs) GET_IP(regs)
> >
> > pretty sure you don't need this as asm-generic/ptrace.h already has a
> > definition for you
>
> On ppc64, profile_pc is an extern function if CONFIG_SMP is set.
> else its same as whats defined in asm-generic/ptrace.h
the code i quoted was from !CONFIG_SMP
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: dont include 8250 pre-setup if 8250 driver isn't enabled.
From: Paul Gortmaker @ 2012-02-02 17:56 UTC (permalink / raw)
To: benh, paulus; +Cc: Paul Gortmaker, linuxppc-dev
In-Reply-To: <1327117828-27085-1-git-send-email-paul.gortmaker@windriver.com>
On Fri, Jan 20, 2012 at 10:50 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> The legacy_serial code was setting things up based on the assumption
> that the main 8250 driver would be loaded shortly after. =A0But some
> randconfigs exposed an issue where early debug (UDB) UART support was
> enabled, yet the core UART 8250 support was disabled.
Hi Ben,
Can you mark this in patchworks as Superseded? It is at:
http://patchwork.ozlabs.org/patch/137142/
You fixed it independently with this:
http://git.kernel.org/?p=3Dlinux/kernel/git/benh/powerpc.git;a=3Dcommit;h=
=3D3493c85366ba09c9d0972c919e7123367a39982a
Thanks,
Paul.
>
> In theory a person could care about _really_ early UART output for
> early debug, but not care about generic console output via UART on
> embedded devices, so fix things so it is a valid combination.
>
> While this might seem like a pointless randconfig change, there are
> some existing default configs that actually reflect the above setup.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/le=
gacy_serial.c
> index 3fea368..9a82a49 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -413,6 +413,14 @@ void __init find_legacy_serial_ports(void)
> =A0 =A0 =A0 =A0DBG(" <- find_legacy_serial_port()\n");
> =A0}
>
> +/*
> + * In theory, one could have the early debugging enabled, but yet not ca=
re
> + * about 8250 after that, i.e. PPC_UDBG_16550=3Dy but "SERIAL_8250 is no=
t set".
> + * Mostly appears in randconfig builds, but some defconfigs have this.
> + */
> +
> +#ifdef CONFIG_SERIAL_8250
> +
> =A0static struct platform_device serial_device =3D {
> =A0 =A0 =A0 =A0.name =A0 =3D "serial8250",
> =A0 =A0 =A0 =A0.id =A0 =A0 =3D PLAT8250_DEV_PLATFORM,
> @@ -523,6 +531,7 @@ static int __init serial_dev_init(void)
> =A0}
> =A0device_initcall(serial_dev_init);
>
> +#endif /* CONFIG_SERIAL_8250 */
>
> =A0#ifdef CONFIG_SERIAL_8250_CONSOLE
> =A0/*
> --
> 1.7.7.2
>
> _______________________________________________
> 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 18:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAL_WD7iJceKMOX9dWDM-SuiO5a_M-3Kp4FnZqS+AuEKvphq_-w@mail.gmail.com>
I ran my test overnight with the TX irq time-stamping and finally got
one delayed packet. Based on the time-stamp data the packets are
getting stuck in the FEC TX FIFO.
The calls to the xmit function are spaced our on about 150 us interval
for a larger TCP socket write. The BestComm tx irq is handled within
about 115us of the xmit (so for TCP at least there is unlikely to be
more than 1 skb in the ring). The "stuck" packet generates a tx irq
just like normal. Which tells me that BestComm has copied it to the
FEC TX fifo, but for some reason the FEC has decided to just sit on
it. But BestComm starts adding another packet, it the FEC starts to
transmit the "stuck" packet.
This testing has been on Kernel 3.1.6 (but I've seen the same problem
on a kernel based on the OLEAS pcm030 2.6.23 kernel). The hardware is
a custom board with 16 bit wide DDR SDRAM.
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz
Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
Joey Nelson
On Wed, Feb 1, 2012 at 6:33 PM, Joey Nelson <joey@joescan.com> wrote:
> 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. =A0If we get an rx interrupt while the tx interrupt holds the
> spin lock, this would seem to be a problem. =A0In 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. =A0I 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. =A0There 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. =A0Previously 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. =A0The delayed packet has to be somewhere at
> that point. =A0I 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 =A0 =A0dev_kfree_skb_irq(skb);
> =A0=A0 }
> =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 req=
uest and sends the data back. =A0It is doing this about 300 times per secon=
d. =A0Normally exchange happens in just handful of milliseconds. =A0But ran=
domly every 2 to 15 minutes the MPC5200B sends all but the last packet of t=
he response, and about 200ms later the PC sends a delayed ACK, and the MPC5=
200B TCP stack figures the packet was lost. =A0It then sends two nearly ide=
ntical packets (The IP header Identification and Checksum fields are increm=
ented). =A0I can also see that RetransSegs in /proc/net/snmp increments by =
one for each of these delays.
>>
>> My theory is that the packet is getting suck somewhere in the network st=
ack (most likely toward the bottom). =A0Then when another packet is sent, t=
he suck one gets pushed out.
>>
>> I've done a test where I have another task on the MPC5200B sending UDP p=
ackets to a different PC every 10ms. =A0This eliminated the long delays, an=
d 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 decen=
t. =A0Has anyone seen this=A0behavior=A0before? =A0Any likely candidates fo=
r where the packet is getting stuck? =A0General advice for reference materi=
als (I've started on Linux Device Drivers 3rd Ed, BestComm AN2604, and the =
Datasheets)
>>
>> Thanks in advance.
>>
>> Joey Nelson
>> joey@joescan.com
>>
^ permalink raw reply
* Re: [PATCH v2] powerpc/usb: fix issue of CPU halt when missing USB PHY clock
From: Greg KH @ 2012-02-02 19:14 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-usb, linuxppc-dev, Shengzhou Liu
In-Reply-To: <4F2A7604.9060102@mvista.com>
On Thu, Feb 02, 2012 at 03:39:48PM +0400, Sergei Shtylyov wrote:
> 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.
I fixed this by hand.
^ 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