* 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
* RE: [PATCH] powerpc/85xx: Fix compiler error with THIS_MODULE and related
From: Manoil Claudiu-B08782 @ 2012-02-01 11:23 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F283D11.4080004@freescale.com>
Hi,
You're right, <linux/export.h> is better for arch/powerpc/sysdev/fsl_85xx_c=
ache_sram.c.
However, it is not enough for arch/powerpc/sysdev/fsl_85xx_l2ctlr.c, as thi=
s one is defined as a module.
I'll resend the patch (with <linux/export.h> for fsl_85xx_cache_sram.c), if=
that's fine with you.
Thanks,
Claudiu
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, January 31, 2012 9:12 PM
> To: Manoil Claudiu-B08782
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/85xx: Fix compiler error with THIS_MODULE
> and related
>=20
> On 01/31/2012 04:15 AM, Claudiu Manoil wrote:
> > 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>
> > ---
> > 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..92cce8d 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/module.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>
> >
>=20
> I believe <linux/export.h> is what you're supposed to include for this
> these days.
>=20
> -Scott
^ permalink raw reply
* Re: next BUG: using smp_processor_id() in preemptible
From: Benjamin Herrenschmidt @ 2012-02-01 10:48 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linuxppc-dev
In-Reply-To: <alpine.LSU.2.00.1201312208270.1859@eggly.anvils>
On Tue, 2012-01-31 at 22:12 -0800, Hugh Dickins wrote:
> > Grrr, my memory is a colander... And now am in Ballarat for the week
> > with a semi working 3g connection. I'll see what I can do.
>
> Sorry to be such a bore - you can guess what I have to say about
> 3.3-rc2 :()
Yeah, I'm looking at reworking the whole thing, I think we have another
deeper problem with lazy interrupt disable and implicit re-enable from
an exception exit too... stay tuned.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix issue of CPU halt when missing USB PHY clock
From: Pavan Kondeti @ 2012-02-01 10:11 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1328088017-9262-1-git-send-email-Shengzhou.Liu@freescale.com>
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 = 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;
Please return a proper error code. -ENODEV ?
> + }
> + 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] powerpc/usb: fix issue of CPU halt when missing USB PHY clock
From: Shengzhou Liu @ 2012-02-01 9:20 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>
---
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..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 = 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;
+ }
+ 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 -1;
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
* [PATCH 2/2 v3] powerpc/dts: Add dts for p1020rdb-pc board
From: Zhicheng Fan @ 2012-02-01 7:35 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Zhicheng Fan
In-Reply-To: <1328081734-19371-1-git-send-email-B32736@freescale.com>
P1020RDB-PC Overview
------------------
1Gbyte DDR3 SDRAM
32 Mbyte NAND flash
10 16Mbyte NOR flash
16 Mbyte SPI flash
SD connector to interface with the SD memory card
Real-time clock on I2C bus
PCIe:
- x1 PCIe slot
- x1 mini-PCIe slot
10/100/1000 BaseT Ethernet ports:
- eTSEC1, RGMII: one 10/100/1000 port using VitesseTM VSC7385 L2 switch
- eTSEC2, SGMII: one 10/100/1000 port using VitesseTM VSC8221
- eTSEC3, RGMII: one 10/100/1000 port using AtherosTM AR8021
USB 2.0 port:
- Two USB2.0 Type A receptacles
- One USB2.0 signal to Mini PCIe slot
Dual RJ45 UART ports:
- DUART interface: supports two UARTs up to 115200 bps for console display
Signed-off-by: Zhicheng Fan <B32736@freescale.com>
---
arch/powerpc/boot/dts/p1020rdb-pc.dts | 90 ++++++++
arch/powerpc/boot/dts/p1020rdb-pc.dtsi | 247 ++++++++++++++++++++++
arch/powerpc/boot/dts/p1020rdb-pc_36b.dts | 90 ++++++++
arch/powerpc/boot/dts/p1020rdb-pc_camp_core0.dts | 64 ++++++
arch/powerpc/boot/dts/p1020rdb-pc_camp_core1.dts | 142 +++++++++++++
5 files changed, 633 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc.dts
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc.dtsi
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc_36b.dts
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc_camp_core0.dts
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/p1020rdb-pc.dts b/arch/powerpc/boot/dts/p1020rdb-pc.dts
new file mode 100644
index 0000000..5c333b0
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb-pc.dts
@@ -0,0 +1,90 @@
+/*
+ * P1020 RDB-PC Device Tree Source
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1020si-pre.dtsi"
+/ {
+ model = "fsl,P1020RDB-PC";
+ compatible = "fsl,P1020RDB-PC";
+
+ memory {
+ device_type = "memory";
+ };
+
+ lbc: localbus@ffe05000 {
+ reg = <0 0xffe05000 0 0x1000>;
+
+ /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
+ ranges = <0x0 0x0 0x0 0xef000000 0x01000000
+ 0x1 0x0 0x0 0xff800000 0x00040000
+ 0x2 0x0 0x0 0xffb00000 0x00020000
+ 0x3 0x0 0x0 0xffa00000 0x00020000>;
+ };
+
+ soc: soc@ffe00000 {
+ ranges = <0x0 0x0 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@ffe09000 {
+ ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
+ reg = <0 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ reg = <0 0xffe0a000 0 0x1000>;
+ ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
+
+/include/ "p1020rdb-pc.dtsi"
+/include/ "fsl/p1020si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1020rdb-pc.dtsi b/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
new file mode 100644
index 0000000..f82958d
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
@@ -0,0 +1,247 @@
+/*
+ * P1020 RDB-PC Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x1000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385 Switch firmware */
+ reg = <0x0 0x00040000>;
+ label = "Vitesse-7385 Firmware";
+ read-only;
+ };
+
+ partition@40000 {
+ /* 256KB for DTB Image */
+ reg = <0x00040000 0x00040000>;
+ label = "DTB Image";
+ };
+
+ partition@80000 {
+ /* 3.5 MB for Linux Kernel Image */
+ reg = <0x00080000 0x00380000>;
+ label = "Linux Kernel Image";
+ };
+
+ partition@400000 {
+ /* 11MB for JFFS2 based Root file System */
+ reg = <0x00400000 0x00b00000>;
+ label = "JFFS2 Root File System";
+ };
+
+ partition@f00000 {
+ /* This location must not be altered */
+ /* 512KB for u-boot Bootloader Image */
+ /* 512KB for u-boot Environment Variables */
+ reg = <0x00f00000 0x00100000>;
+ label = "U-Boot Image";
+ read-only;
+ };
+ };
+
+ nand@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,p1020-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <0x1 0x0 0x40000>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg = <0x0 0x00100000>;
+ label = "U-Boot Image";
+ read-only;
+ };
+
+ partition@100000 {
+ /* 1MB for DTB Image */
+ reg = <0x00100000 0x00100000>;
+ label = "DTB Image";
+ };
+
+ partition@200000 {
+ /* 4MB for Linux Kernel Image */
+ reg = <0x00200000 0x00400000>;
+ label = "Linux Kernel Image";
+ };
+
+ partition@600000 {
+ /* 4MB for Compressed Root file System Image */
+ reg = <0x00600000 0x00400000>;
+ label = "Compressed RFS Image";
+ };
+
+ partition@a00000 {
+ /* 7MB for JFFS2 based Root file System */
+ reg = <0x00a00000 0x00700000>;
+ label = "JFFS2 Root File System";
+ };
+
+ partition@1100000 {
+ /* 15MB for JFFS2 based Root file System */
+ reg = <0x01100000 0x00f00000>;
+ label = "Writable User area";
+ };
+ };
+
+ L2switch@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "vitesse-7385";
+ reg = <0x2 0x0 0x20000>;
+ };
+
+ cpld@3,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cpld";
+ reg = <0x3 0x0 0x20000>;
+ read-only;
+ };
+};
+
+&soc {
+ i2c@3000 {
+ rtc@68 {
+ compatible = "pericom,pt7c4338";
+ reg = <0x68>;
+ };
+ };
+
+ spi@7000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl12801";
+ reg = <0>;
+ spi-max-frequency = <40000000>; /* input clock */
+
+ partition@u-boot {
+ /* 512KB for u-boot Bootloader Image */
+ reg = <0x0 0x00080000>;
+ label = "u-boot";
+ read-only;
+ };
+
+ partition@dtb {
+ /* 512KB for DTB Image*/
+ reg = <0x00080000 0x00080000>;
+ label = "dtb";
+ };
+
+ partition@kernel {
+ /* 4MB for Linux Kernel Image */
+ reg = <0x00100000 0x00400000>;
+ label = "kernel";
+ };
+
+ partition@fs {
+ /* 4MB for Compressed RFS Image */
+ reg = <0x00500000 0x00400000>;
+ label = "file system";
+ };
+
+ partition@jffs-fs {
+ /* 7MB for JFFS2 based RFS */
+ reg = <0x00900000 0x00700000>;
+ label = "file system jffs2";
+ };
+ };
+ };
+
+ usb@22000 {
+ phy_type = "ulpi";
+ };
+
+ /* USB2 is shared with localbus, so it must be disabled
+ by default. We can't put 'status = "disabled";' here
+ since U-Boot doesn't clear the status property when
+ it enables USB2. OTOH, U-Boot does create a new node
+ when there isn't any. So, just comment it out.
+ usb@23000 {
+ phy_type = "ulpi";
+ };
+ */
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ interrupt-parent = <&mpic>;
+ interrupts = <3 1>;
+ reg = <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&mpic>;
+ interrupts = <2 1>;
+ reg = <0x1>;
+ };
+
+ tbi0: tbi-phy@11 {
+ device_type = "tbi-phy";
+ reg = <0x11>;
+ };
+ };
+
+ mdio@25000 {
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@b0000 {
+ fixed-link = <1 1 1000 0 0>;
+ phy-connection-type = "rgmii-id";
+
+ };
+
+ enet1: ethernet@b1000 {
+ phy-handle = <&phy0>;
+ tbi-handle = <&tbi1>;
+ phy-connection-type = "sgmii";
+ };
+
+ enet2: ethernet@b2000 {
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+};
diff --git a/arch/powerpc/boot/dts/p1020rdb-pc_36b.dts b/arch/powerpc/boot/dts/p1020rdb-pc_36b.dts
new file mode 100644
index 0000000..ca736a0
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb-pc_36b.dts
@@ -0,0 +1,90 @@
+/*
+ * P1020 RDB-PC Device Tree Source (36-bit address map)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1020si-pre.dtsi"
+/ {
+ model = "fsl,P1020RDB-PC";
+ compatible = "fsl,P1020RDB-PC";
+
+ memory {
+ device_type = "memory";
+ };
+
+ lbc: localbus@fffe05000 {
+ reg = <0xf 0xffe05000 0 0x1000>;
+
+ /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
+ ranges = <0x0 0x0 0xf 0xef000000 0x01000000
+ 0x1 0x0 0xf 0xff800000 0x00040000
+ 0x2 0x0 0xf 0xffb00000 0x00040000
+ 0x3 0x0 0xf 0xffa00000 0x00020000>;
+ };
+
+ soc: soc@fffe00000 {
+ ranges = <0x0 0xf 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@fffe09000 {
+ reg = <0xf 0xffe09000 0 0x1000>;
+ ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xc0000000
+ 0x2000000 0x0 0xc0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@fffe0a000 {
+ reg = <0xf 0xffe0a000 0 0x1000>;
+ ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
+
+/include/ "p1020rdb.dtsi"
+/include/ "fsl/p1020si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1020rdb-pc_camp_core0.dts b/arch/powerpc/boot/dts/p1020rdb-pc_camp_core0.dts
new file mode 100644
index 0000000..9f93b3a
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb-pc_camp_core0.dts
@@ -0,0 +1,64 @@
+/*
+ * P1020 RDB-PC Core0 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
+ * can be shared, all the other devices must be assigned to one core only.
+ * This dts file allows core0 to have memory, l2, i2c, spi, gpio, tdm, dma, usb,
+ * eth1, eth2, sdhc, crypto, global-util, message, pci0, pci1, msi.
+ *
+ * Please note to add "-b 0" for core0's dts compiling.
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ "p1020rdb-pc.dts"
+
+/ {
+ model = "fsl,P1020RDB-PC";
+ compatible = "fsl,P1020RDB-PC";
+
+ aliases {
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ serial0 = &serial0;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ };
+
+ cpus {
+ PowerPC,P1020@1 {
+ status = "disabled";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ localbus@ffe05000 {
+ status = "disabled";
+ };
+
+ soc@ffe00000 {
+ serial1: serial@4600 {
+ status = "disabled";
+ };
+
+ enet0: ethernet@b0000 {
+ status = "disabled";
+ };
+
+ mpic: pic@40000 {
+ protected-sources = <
+ 42 29 30 34 /* serial1, enet0-queue-group0 */
+ 17 18 24 45 /* enet0-queue-group1, crypto */
+ >;
+ pic-no-reset;
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/p1020rdb-pc_camp_core1.dts b/arch/powerpc/boot/dts/p1020rdb-pc_camp_core1.dts
new file mode 100644
index 0000000..d3281ab
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb-pc_camp_core1.dts
@@ -0,0 +1,142 @@
+/*
+ * P1020 RDB-PC Core1 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
+ * can be shared, all the other devices must be assigned to one core only.
+ * This dts allows core1 to have l2, eth0, crypto.
+ *
+ * Please note to add "-b 1" for core1's dts compiling.
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ "p1020rdb-pc.dts"
+
+/ {
+ model = "fsl,P1020RDB-PC";
+ compatible = "fsl,P1020RDB-PC";
+
+ aliases {
+ ethernet0 = &enet0;
+ serial0 = &serial1;
+ };
+
+ cpus {
+ PowerPC,P1020@0 {
+ status = "disabled";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ localbus@ffe05000 {
+ status = "disabled";
+ };
+
+ soc@ffe00000 {
+ ecm-law@0 {
+ status = "disabled";
+ };
+
+ ecm@1000 {
+ status = "disabled";
+ };
+
+ memory-controller@2000 {
+ status = "disabled";
+ };
+
+ i2c@3000 {
+ status = "disabled";
+ };
+
+ i2c@3100 {
+ status = "disabled";
+ };
+
+ serial0: serial@4500 {
+ status = "disabled";
+ };
+
+ spi@7000 {
+ status = "disabled";
+ };
+
+ gpio: gpio-controller@f000 {
+ status = "disabled";
+ };
+
+ dma@21300 {
+ status = "disabled";
+ };
+
+ mdio@24000 {
+ status = "disabled";
+ };
+
+ mdio@25000 {
+ status = "disabled";
+ };
+
+ enet1: ethernet@b1000 {
+ status = "disabled";
+ };
+
+ enet2: ethernet@b2000 {
+ status = "disabled";
+ };
+
+ usb@22000 {
+ status = "disabled";
+ };
+
+ sdhci@2e000 {
+ status = "disabled";
+ };
+
+ mpic: pic@40000 {
+ protected-sources = <
+ 16 /* ecm, mem, L2, pci0, pci1 */
+ 43 42 59 /* i2c, serial0, spi */
+ 47 63 62 /* gpio, tdm */
+ 20 21 22 23 /* dma */
+ 03 02 /* mdio */
+ 35 36 40 /* enet1-queue-group0 */
+ 51 52 67 /* enet1-queue-group1 */
+ 31 32 33 /* enet2-queue-group0 */
+ 25 26 27 /* enet2-queue-group1 */
+ 28 72 58 /* usb, sdhci, crypto */
+ 0xb0 0xb1 0xb2 /* message */
+ 0xb3 0xb4 0xb5
+ 0xb6 0xb7
+ 0xe0 0xe1 0xe2 /* msi */
+ 0xe3 0xe4 0xe5
+ 0xe6 0xe7 /* sdhci, crypto , pci */
+ >;
+ pic-no-reset;
+ };
+
+ msi@41600 {
+ status = "disabled";
+ };
+
+ global-utilities@e0000 { //global utilities block
+ status = "disabled";
+ };
+ };
+
+ pci0: pcie@ffe09000 {
+ status = "disabled";
+ };
+
+ pci1: pcie@ffe0a000 {
+ status = "disabled";
+ };
+};
--
1.6.4
^ permalink raw reply related
* [PATCH 1/2 v3] powerpc/85xx: Add p1020rdb-pc platform support
From: Zhicheng Fan @ 2012-02-01 7:35 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Zhicheng Fan
Signed-off-by: Zhicheng Fan <B32736@freescale.com>
---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 27 ++++++++++++++++++++++++++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index f5ff911..0b04bef 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -1,7 +1,7 @@
/*
* MPC85xx RDB Board Setup
*
- * Copyright 2009 Freescale Semiconductor Inc.
+ * Copyright 2009,2012 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -121,8 +121,10 @@ static int __init mpc85xxrdb_publish_devices(void)
{
return of_platform_bus_probe(NULL, mpc85xxrdb_ids, NULL);
}
+
machine_device_initcall(p2020_rdb, mpc85xxrdb_publish_devices);
machine_device_initcall(p1020_rdb, mpc85xxrdb_publish_devices);
+machine_device_initcall(p1020_rdb_pc, mpc85xx_common_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -145,6 +147,15 @@ static int __init p1020_rdb_probe(void)
return 0;
}
+static int __init p1020_rdb_pc_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,P1020RDB-PC"))
+ return 1;
+ return 0;
+}
+
define_machine(p2020_rdb) {
.name = "P2020 RDB",
.probe = p2020_rdb_probe,
@@ -172,3 +183,17 @@ define_machine(p1020_rdb) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(p1020_rdb_pc) {
+ .name = "P1020RDB-PC",
+ .probe = p1020_rdb_pc_probe,
+ .setup_arch = mpc85xx_rdb_setup_arch,
+ .init_IRQ = mpc85xx_rdb_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.6.4
^ permalink raw reply related
* Re: [PULL] ARM mach/irqs.h cleanup for 3.4
From: Paul Mundt @ 2012-02-01 5:42 UTC (permalink / raw)
To: Rob Herring
Cc: Aurelien Jacquiot, Paul Mackerras, H. Peter Anvin, jamie,
Robert Jarzmik, Russell King - ARM Linux, linux-c6x-dev, linux-sh,
Haojian Zhuang, Marek Vasut, Ingo Molnar, Mark Salter,
Arnd Bergmann, Nobuhiro Iwamatsu, Thomas Gleixner,
linux-arm-kernel, Eric Miao, Nicolas Pitre, Olof Johansson,
linuxppc-dev
In-Reply-To: <4F284532.90303@gmail.com>
On Tue, Jan 31, 2012 at 01:46:58PM -0600, Rob Herring wrote:
> Can you please pull mach/irqs.h clean-up for 3.4. I've gotten little to
> no response from the affected platform maintainers. It's primarily
> superh and shmobile that have any significant changes though.
>
Sorry about that, it's been in my backlog. The changes as they are are
fine with me, I've got some pending work that switches to dynamic use off
of nr_irqs that will make most of it redundant that I had hoped to have
done in time, but it can be done incrementally at a later point in time,
too.
^ permalink raw reply
* Re: next BUG: using smp_processor_id() in preemptible
From: Hugh Dickins @ 2012-02-01 6:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1326603920.26116.18.camel@pasglop>
On Sun, 15 Jan 2012, Benjamin Herrenschmidt wrote:
> On Sat, 2012-01-14 at 14:21 -0800, Hugh Dickins wrote:
> > On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
> > > On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
> > > > On Mon, 5 Dec 2011, Hugh Dickins wrote:
> > > >
> > > > > 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
> > > > >
> > > > > Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
> > > > > Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
> > > > > Dec 4 20:03:19 thorn kernel: Call Trace:
> > > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
> > > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
> > > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
> > > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
> > > > > Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
> > > > >
> > > > > from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
> > > > > in decrementer_check_overflow(): I've no idea whether it's safe
> > > > > just to use get_cpu_var then put_cpu_var there instead,
> > > > > but no hurry, I can survive with DEBUG_PREEMPT off.
> > > >
> > > > Still a problem in 3.2.0-rc6-next-20111222
> > >
> > > Ah forgot about that, I'll have a look. Thanks for the reminder.
> >
> > I'm afraid it's now blighting Linus's tree for 3.3.
>
> Grrr, my memory is a colander... And now am in Ballarat for the week
> with a semi working 3g connection. I'll see what I can do.
Sorry to be such a bore - you can guess what I have to say about 3.3-rc2 :()
Hugh
^ permalink raw reply
* Re: [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
From: Vinod Koul @ 2012-02-01 5:43 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.1202010022310.31226@axis700.grange>
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...
--
~Vinod
^ permalink raw reply
* RE: [PATCH 1/2 v2] powerpc/dts: Add dts for p1025rdb board
From: Zang Roy-R61911 @ 2012-02-01 2:10 UTC (permalink / raw)
To: Kumar Gala, Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, Fan Zhicheng-B32736, Zhicheng Fan
In-Reply-To: <7D155016-AC91-440A-A88F-FEEF85C13184@kernel.crashing.org>
> -----Original Message-----
> From: linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@lists.ozlabs.or=
g]
> On Behalf Of Kumar Gala
> Sent: Wednesday, February 01, 2012 7:44 AM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; Zhicheng Fan; Fan Zhicheng-B32736
> Subject: Re: [PATCH 1/2 v2] powerpc/dts: Add dts for p1025rdb board
>=20
>=20
> On Jan 31, 2012, at 1:10 PM, Scott Wood wrote:
>=20
> > On 01/31/2012 09:55 AM, Kumar Gala wrote:
> >>
> >> On Jan 31, 2012, at 3:51 AM, Zhicheng Fan wrote:
> >>> Signed-off-by: Zhicheng Fan <b32736@freeescale.com>
> >>> ---
> >>> arch/powerpc/boot/dts/fsl/p1025si-post.dtsi | 228
> +++++++++++++++++++++
> >>> arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi | 70 +++++++
> >>> arch/powerpc/boot/dts/p1025rdb.dts | 137 +++++++++++++
> >>> arch/powerpc/boot/dts/p1025rdb.dtsi | 286
> +++++++++++++++++++++++++++
> >>> arch/powerpc/boot/dts/p1025rdb_36b.dts | 88 ++++++++
> >>> 5 files changed, 809 insertions(+), 0 deletions(-)
> >>> create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-post.dtsi
> >>> create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi
> >>> create mode 100644 arch/powerpc/boot/dts/p1025rdb.dts
> >>> create mode 100644 arch/powerpc/boot/dts/p1025rdb.dtsi
> >>> create mode 100644 arch/powerpc/boot/dts/p1025rdb_36b.dts
> >>
> >> For the p1024 & p1025 I do NOT want to add new dts/fsl/p1025si*.dtsi
> files. We should use the p1020 and p1021 as they are identical.
> >
> > Are they sufficiently software compatible that we want to use
> > p1020/p1021 in all the compatible strings? If yes, how was this verifi=
ed?
>=20
> They are the identical silicon just in different physical packages. It w=
as
> verified by me asking the FSL marketing team.
>=20
> I'll work up a patch to add some comments to the p1020 & p1021si dts file=
s
> about being the same for p1024/p1025.
Should we expose the information "p1024/p1025 are identical to p1020/p1021"=
to our customer?
Thanks.
Roy
^ permalink raw reply
* Re: [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
From: Guennadi Liakhovetski @ 2012-02-01 0:09 UTC (permalink / raw)
To: Vinod Koul
Cc: Jassi Brar, linux-kernel, Alexandre Bounine, akpm, linuxppc-dev,
dan.j.williams, Russell King
In-Reply-To: <1327915849.1527.17.camel@vkoul-udesk3>
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
-struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn, void *fn_param);
+struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn, void *fn_param,
+ struct dma_slave_desc *slave);
where struct dma_slave_desc would basically just contain an opaque slave
ID and would be embedded by dmaengine drivers in their specific
slave-configuration types. The main difference to the API change being
proposed here is, that I was going to configure DMA channels only once for
each slave upon channel allocation, whereas the proposed change does this
on a per-transfer basis. Therefore my question: do I understand the
explanation of the RapidIO DMA architecture from the above quoted thread
right, that DMA channels can be freely used by client drivers, without
binding them to specific DSP cards? In which case you, probably, don't use
DMA_PRIVATE? But that the decision - to which DSP card this specific
transfer is directed - is made by configuring the DMA channels rather than
embedded in the actual data?
Thanks
Guennadi
>
> >
> > Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
> > Cc: Jassi Brar <jaswinder.singh@linaro.org>
> > Cc: Russell King <rmk@arm.linux.org.uk>
> > Cc: Kumar Gala <galak@kernel.crashing.org>
> > Cc: Matt Porter <mporter@kernel.crashing.org>
> > Cc: Li Yang <leoli@freescale.com>
> > ---
> > include/linux/dmaengine.h | 7 ++++---
> > 1 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index 679b349..79d71bb 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -575,7 +575,7 @@ struct dma_device {
> > struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> > struct dma_chan *chan, struct scatterlist *sgl,
> > unsigned int sg_len, enum dma_transfer_direction direction,
> > - unsigned long flags);
> > + unsigned long flags, void *context);
> > struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
> > struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
> > size_t period_len, enum dma_transfer_direction direction);
> > @@ -607,12 +607,13 @@ static inline int dmaengine_slave_config(struct dma_chan *chan,
> >
> > static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
> > struct dma_chan *chan, void *buf, size_t len,
> > - enum dma_transfer_direction dir, unsigned long flags)
> > + enum dma_transfer_direction dir, unsigned long flags, void *context)
> > {
> > struct scatterlist sg;
> > sg_init_one(&sg, buf, len);
> >
> > - return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags);
> > + return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags,
> > + context);
> > }
> >
> > static inline int dmaengine_terminate_all(struct dma_chan *chan)
>
>
> --
> ~Vinod
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH v3 14/25] irq_domain: Remove irq_domain_add_simple()
From: Grant Likely @ 2012-02-01 0:08 UTC (permalink / raw)
To: Shawn Guo
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Milton Miller,
Rob Herring, Thomas Gleixner, Shawn Guo, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20120131135821.GA24804@S2100-06.ap.freescale.net>
On Tue, Jan 31, 2012 at 09:58:22PM +0800, Shawn Guo wrote:
> On Tue, Jan 31, 2012 at 07:15:26AM -0600, Rob Herring wrote:
> ...
> > >> --- a/arch/arm/mach-mx5/imx51-dt.c
> > >> +++ b/arch/arm/mach-mx5/imx51-dt.c
> > >> @@ -47,7 +47,7 @@ static const struct of_dev_auxdata imx51_auxdata_lookup[] __initconst = {
> > >> static int __init imx51_tzic_add_irq_domain(struct device_node *np,
> > >> struct device_node *interrupt_parent)
> > >> {
> > >> - irq_domain_add_simple(np, 0);
> > >> + irq_domain_add_legacy(np, 32, 0, 0, &irq_domain_simple_ops, NULL);
> > >> return 0;
> > >> }
> > >>
> > >> @@ -57,7 +57,7 @@ static int __init imx51_gpio_add_irq_domain(struct device_node *np,
> > >> static int gpio_irq_base = MXC_GPIO_IRQ_START + ARCH_NR_GPIOS;
> > >>
> > >> gpio_irq_base -= 32;
> > >> - irq_domain_add_simple(np, gpio_irq_base);
> > >> + irq_domain_add_legacy(np, 32, gpio_irq_base, 0, &irq_domain_simple_ops, NULL);
> > >
> > > The tzic on imx5 gets 128 irq lines rather than 32 here. The current
> > > code will make any hwirq that is > 32 hit the WARN_ON below in
> > > irq_domain_legacy_revmap().
> >
> > But this is the gpio controller code? Really this should be 4 domains,
> > but this temp fix is probably fine until you use my generic irq chip
> > support.
> >
> Sorry. The comment was put at the wrong place. It should be against
> imx51_tzic_add_irq_domain() just above.
I didn't know how large the bank was, so I just assumed 32. If it should
be 128 then I'll change it. Please confirm (or reply with a fixup patch)
g.
^ permalink raw reply
* Re: [PATCH v3 00/25] irq_domain generalization and refinement
From: Grant Likely @ 2012-02-01 0:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120131045344.GA27609@quad.lixom.net>
On Mon, Jan 30, 2012 at 08:53:44PM -0800, Olof Johansson wrote:
> On Fri, Jan 27, 2012 at 02:35:54PM -0700, Grant Likely wrote:
> > Hey everyone,
> >
> > This patch series is ready for much wider consumption now. I'd like
> > to get it into linux-next ASAP because there will be ARM board support
> > depending on it. I'll wait a few days before I ask Stephen to pull
> > this in.
> >
> > Stephen/Milton/Ben, any testing you can help with here would be
> > appreciated since you've got access to a wider variety of Power
> > machines than I do.
>
> This series has been:
>
> Tested-by: Olof Johansson <olof@lixom.net>
>
> On powerpc/pasemi (it's the only one I still have easy access to).
Excellent, thanks Olof!
g.
^ permalink raw reply
* Re: [PATCH 1/2 v2] powerpc/dts: Add dts for p1025rdb board
From: Kumar Gala @ 2012-01-31 23:44 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Zhicheng Fan, Zhicheng Fan
In-Reply-To: <4F283CB7.4050908@freescale.com>
On Jan 31, 2012, at 1:10 PM, Scott Wood wrote:
> On 01/31/2012 09:55 AM, Kumar Gala wrote:
>>=20
>> On Jan 31, 2012, at 3:51 AM, Zhicheng Fan wrote:
>>> Signed-off-by: Zhicheng Fan <b32736@freeescale.com>
>>> ---
>>> arch/powerpc/boot/dts/fsl/p1025si-post.dtsi | 228 =
+++++++++++++++++++++
>>> arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi | 70 +++++++
>>> arch/powerpc/boot/dts/p1025rdb.dts | 137 +++++++++++++
>>> arch/powerpc/boot/dts/p1025rdb.dtsi | 286 =
+++++++++++++++++++++++++++
>>> arch/powerpc/boot/dts/p1025rdb_36b.dts | 88 ++++++++
>>> 5 files changed, 809 insertions(+), 0 deletions(-)
>>> create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-post.dtsi
>>> create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi
>>> create mode 100644 arch/powerpc/boot/dts/p1025rdb.dts
>>> create mode 100644 arch/powerpc/boot/dts/p1025rdb.dtsi
>>> create mode 100644 arch/powerpc/boot/dts/p1025rdb_36b.dts
>>=20
>> For the p1024 & p1025 I do NOT want to add new dts/fsl/p1025si*.dtsi =
files. We should use the p1020 and p1021 as they are identical.
>=20
> Are they sufficiently software compatible that we want to use
> p1020/p1021 in all the compatible strings? If yes, how was this =
verified?
They are the identical silicon just in different physical packages. It =
was verified by me asking the FSL marketing team.
I'll work up a patch to add some comments to the p1020 & p1021si dts =
files about being the same for p1024/p1025.
- k=
^ permalink raw reply
* [PATCH v2] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-01-31 21:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dan Williams
In-Reply-To: <1327611520-18256-1-git-send-email-iws@ovro.caltech.edu>
The mpc8349ea has been observed to generate spurious end of segments
interrupts despite the fact that they are not enabled by this driver.
Check for them and ignore them to avoid a kernel error message.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Dan Williams <dan.j.williams@intel.com>
---
Changes v1 -> v2:
- skip the descriptor cleanup tasklet if the controller is not yet idle
drivers/dma/fsldma.c | 27 ++++++++++++++++++++++++---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8a78154..037631a 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1052,20 +1052,41 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
stat &= ~FSL_DMA_SR_EOLNI;
}
- /* check that the DMA controller is really idle */
- if (!dma_is_idle(chan))
- chan_err(chan, "irq: controller not idle!\n");
+ /*
+ * This driver does not use this feature, therefore we shouldn't
+ * ever see this bit set in the status register. However, it has
+ * been observed on MPC8349EA parts.
+ */
+ if (stat & FSL_DMA_SR_EOSI) {
+ chan_dbg(chan, "irq: End-of-Segments INT\n");
+ stat &= ~FSL_DMA_SR_EOSI;
+ }
/* check that we handled all of the bits */
if (stat)
chan_err(chan, "irq: unhandled sr 0x%08x\n", stat);
/*
+ * Check that the DMA controller is really idle
+ *
+ * Occasionally on MPC8349EA parts, a spurious End-of-Segments
+ * interrupt is generated. When this happens, the controller is
+ * still busy. In this case, we shouldn't run the tasklet to
+ * clean up idle descriptors, since the controller is not yet idle.
+ */
+ if (!dma_is_idle(chan)) {
+ chan_err(chan, "irq: controller not idle!\n");
+ goto out_skip_tasklet;
+ }
+
+ /*
* Schedule the tasklet to handle all cleanup of the current
* transaction. It will start a new transaction if there is
* one pending.
*/
tasklet_schedule(&chan->tasklet);
+
+out_skip_tasklet:
chan_dbg(chan, "irq: Exit\n");
return IRQ_HANDLED;
}
--
1.7.3.4
^ permalink raw reply related
* [PULL] ARM mach/irqs.h cleanup for 3.4
From: Rob Herring @ 2012-01-31 19:46 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Aurelien Jacquiot, Paul Mackerras, H. Peter Anvin, jamie,
Robert Jarzmik, Russell King, linux-c6x-dev, linux-sh,
Haojian Zhuang, Marek Vasut, Ingo Molnar, Mark Salter,
Nobuhiro Iwamatsu, Thomas Gleixner, linux-arm-kernel, Eric Miao,
Nicolas Pitre, Paul Mundt, Arnd Bergmann, Olof Johansson,
linuxppc-dev
Russell,
Can you please pull mach/irqs.h clean-up for 3.4. I've gotten little to
no response from the affected platform maintainers. It's primarily
superh and shmobile that have any significant changes though.
Rob
The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
Linux 3.3-rc1 (2012-01-19 15:04:48 -0800)
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git sparse_irq
Jamie Iles (1):
ARM: picoxcell: remove mach/irqs.h
Rob Herring (13):
irq: make SPARSE_IRQ an optionally hidden option
sound: pxa2xx-ac97: include mach/irqs.h directly
gpio: pxa: explicitly include mach/irqs.h
ARM: remove mc146818rtc.h from time.c
ARM: mc146818rtc: remove unnecessary include of mach/irqs.h
ARM: it8152: explicitly include mach/irqs.h
sh: intc: unify evt2irq/irq2evt macros for sh and arm
sh: intc: remove dependency on NR_IRQS
ARM: mmp: remove NR_IRQS
ARM: pxa: remove NR_IRQS
ARM: shmobile: remove NR_IRQS
ARM: only include mach/irqs.h for !SPARSE_IRQ
ARM: highbank: select SPARSE_IRQ and remove irqs.h
arch/arm/Kconfig | 2 +-
arch/arm/include/asm/hardware/it8152.h | 3 +++
arch/arm/include/asm/irq.h | 8 ++++++--
arch/arm/include/asm/mc146818rtc.h | 4 +++-
arch/arm/kernel/time.c | 2 --
arch/arm/mach-highbank/highbank.c | 1 -
arch/arm/mach-highbank/include/mach/irqs.h | 6 ------
arch/arm/mach-mmp/aspenite.c | 5 +++--
arch/arm/mach-mmp/avengers_lite.c | 1 +
arch/arm/mach-mmp/brownstone.c | 4 ++--
arch/arm/mach-mmp/flint.c | 3 ++-
arch/arm/mach-mmp/gplugd.c | 2 +-
arch/arm/mach-mmp/include/mach/irqs.h | 3 +--
arch/arm/mach-mmp/irq-mmp2.c | 1 +
arch/arm/mach-mmp/jasper.c | 5 +++--
arch/arm/mach-mmp/tavorevb.c | 1 +
arch/arm/mach-mmp/teton_bga.c | 3 ++-
arch/arm/mach-mmp/ttc_dkb.c | 4 ++--
arch/arm/mach-picoxcell/include/mach/irqs.h | 20 --------------------
arch/arm/mach-pxa/capc7117.c | 1 +
arch/arm/mach-pxa/cm-x300.c | 1 +
arch/arm/mach-pxa/colibri-pxa270.c | 2 ++
arch/arm/mach-pxa/colibri-pxa300.c | 1 +
arch/arm/mach-pxa/colibri-pxa320.c | 1 +
arch/arm/mach-pxa/corgi.c | 3 +++
arch/arm/mach-pxa/csb726.c | 1 +
arch/arm/mach-pxa/devices.c | 1 +
arch/arm/mach-pxa/em-x270.c | 2 ++
arch/arm/mach-pxa/gumstix.c | 1 +
arch/arm/mach-pxa/h5000.c | 1 +
arch/arm/mach-pxa/himalaya.c | 1 +
arch/arm/mach-pxa/icontrol.c | 1 +
arch/arm/mach-pxa/idp.c | 1 +
arch/arm/mach-pxa/include/mach/irqs.h | 2 +-
arch/arm/mach-pxa/mioa701.c | 1 +
arch/arm/mach-pxa/mp900.c | 1 +
arch/arm/mach-pxa/palmld.c | 1 +
arch/arm/mach-pxa/palmt5.c | 1 +
arch/arm/mach-pxa/palmtc.c | 1 +
arch/arm/mach-pxa/palmte2.c | 1 +
arch/arm/mach-pxa/palmtreo.c | 2 ++
arch/arm/mach-pxa/palmtx.c | 1 +
arch/arm/mach-pxa/palmz72.c | 1 +
arch/arm/mach-pxa/pxa3xx.c | 1 +
arch/arm/mach-pxa/raumfeld.c | 3 +++
arch/arm/mach-pxa/saar.c | 1 +
arch/arm/mach-pxa/spitz.c | 3 +++
arch/arm/mach-pxa/stargate2.c | 1 +
arch/arm/mach-pxa/tavorevb.c | 1 +
arch/arm/mach-pxa/time.c | 1 +
arch/arm/mach-pxa/trizeps4.c | 2 ++
arch/arm/mach-pxa/viper.c | 1 +
arch/arm/mach-pxa/vpac270.c | 1 +
arch/arm/mach-pxa/xcep.c | 1 +
arch/arm/mach-pxa/z2.c | 1 +
arch/arm/mach-shmobile/Kconfig | 4 ++++
arch/arm/mach-shmobile/board-ag5evm.c | 1 +
arch/arm/mach-shmobile/board-bonito.c | 1 +
arch/arm/mach-shmobile/board-g3evm.c | 1 +
arch/arm/mach-shmobile/board-g4evm.c | 1 +
arch/arm/mach-shmobile/board-kota2.c | 1 +
arch/arm/mach-shmobile/board-mackerel.c | 1 +
arch/arm/mach-shmobile/board-marzen.c | 1 +
arch/arm/mach-shmobile/include/mach/irqs.h | 6 +-----
arch/arm/mach-shmobile/intc-r8a7740.c | 1 +
arch/arm/mach-shmobile/intc-sh7367.c | 1 +
arch/arm/mach-shmobile/intc-sh7372.c | 1 +
arch/arm/mach-shmobile/intc-sh7377.c | 1 +
arch/arm/mach-shmobile/intc-sh73a0.c | 1 +
arch/arm/mach-shmobile/setup-r8a7740.c | 1 +
arch/arm/mach-shmobile/setup-r8a7779.c | 1 +
arch/arm/mach-shmobile/setup-sh7367.c | 1 +
arch/arm/mach-shmobile/setup-sh7372.c | 1 +
arch/arm/mach-shmobile/setup-sh7377.c | 1 +
arch/arm/mach-shmobile/setup-sh73a0.c | 1 +
arch/c6x/Kconfig | 2 +-
arch/powerpc/Kconfig | 2 +-
arch/sh/Kconfig | 2 +-
arch/sh/include/asm/irq.h | 11 -----------
arch/x86/Kconfig | 1 -
drivers/gpio/gpio-pxa.c | 2 ++
drivers/sh/intc/balancing.c | 2 +-
drivers/sh/intc/core.c | 2 +-
drivers/sh/intc/handle.c | 2 +-
drivers/sh/intc/virq.c | 2 +-
include/linux/sh_intc.h | 17 +++++++++++++++++
kernel/irq/Kconfig | 5 ++---
sound/arm/pxa2xx-ac97-lib.c | 2 +-
88 files changed, 130 insertions(+), 75 deletions(-)
delete mode 100644 arch/arm/mach-highbank/include/mach/irqs.h
delete mode 100644 arch/arm/mach-picoxcell/include/mach/irqs.h
^ permalink raw reply
* Re: RTC on 2.6.36 for PowerMac 8600
From: kevin diggs @ 2012-01-31 19:31 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Linux PPC Development
In-Reply-To: <m2obtmhpx4.fsf@linux-m68k.org>
Hi,
On 1/29/12, Andreas Schwab <schwab@linux-m68k.org> wrote:
> kevin diggs <diggskevin38@gmail.com> writes:
>
>
> Perhaps the RTC was reset due to battery running out? That would set
> the year to 1900, but the kernel RTC interface cannot represent dates
> before 1970. Unfortunately hwclock insists on reading the RTC even when
> you just want to write to it, so you cannot fix that with hwclock -w.
> When the battery of my iBook has run out I'm using the following to
> reset RTC to current time so that it is usable again.
>
> Andreas.
>
>
Thanks! I did not know about this problem with the year. This vintage
of mac sets the year to 1956.
Yes, the battery is dead. It is one of those $20 1/3 AA lithium cells.
I can't afford to replace it. I went into the MacOS Classic date
control panel and set the year to 1971 and it worked!
Thanks for the tip. I would have never figured this one out!
kevin
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>
^ 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