* Re: [PATCH] Addition to the i2c series, copy the ppc mpc-i2c driver before changing it on powerpc
From: Jon Smirl @ 2007-12-10 22:54 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list
In-Reply-To: <fa686aa40712101444l448657c5jb6117e7a60715651@mail.gmail.com>
On 12/10/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 12/10/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > Copy mpc-i2c to preserve support for ARCH=ppc and allow changes on ARCH=powerpc
> >
> > Temporarily copy the mpc-i2c driver to continue support for the ppc
> > architecture until it is removed in mid-2008. This file should be
> > deleted as part of ppc's final removal.
> >
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> For the record; I'm not fond of this approach. Supporting both bus
> bindings in the single driver is simple and results in less code churn
> when arch/ppc is removed, and encourages separation between the driver
> proper and the bus bindings which is just a good idea for all drivers
> in general.
But it also triggers a testing burden on a bunch of hardware that I
don't own. By copying off the known working ppc driver the testing
burden is avoided.
A subject for later discussion is whether platform bus should even
exist when of_platform_bus is in use. I have removed platform_bus for
the mpc5200 in my local builds. Removing platform bus exposed a bunch
of junk from other platofrms that had inadvertently accumulated into
the mpc5200 build.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH RFC 4/7] [GPIO] Let drivers link if they support GPIO API as an addition
From: David Brownell @ 2007-12-10 22:55 UTC (permalink / raw)
To: linuxppc-dev, avorontsov
In-Reply-To: <20071210204906.GD32278@localhost.localdomain>
> I'm interested in your opinion about that patch. You're also Cc'ed
> to patch that using that feature.
>
> I know, currently that patch will conflict with GPIOLIB patches in -mm,
> so this is only RFC.
The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
tell whether that programming interface is available ... starting
from "#include <asm/gpio.h>", and including all gpio_*() calls.
So my first reaction is to not like this patch. It changes semantics
in an incompatible way. And AFAICT, needlessly so.
What other options did consider? Like, why not #ifdef the GPIO parts
of that NAND driver, or have the whole driver depend on GENERIC_GPIO?
- Dave
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Olof Johansson @ 2007-12-10 23:07 UTC (permalink / raw)
To: Balbir Singh; +Cc: linuxppc-dev, LKML
In-Reply-To: <20071207223714.11448.91386.sendpatchset@balbir-laptop>
On Sat, Dec 08, 2007 at 04:07:14AM +0530, Balbir Singh wrote:
> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Looks good to me. Sure, it could be fleshed out to something more
generic and in common code, but this is small and simple and doesn't
bloat the kernel much as it stands, and it has value for debugging.
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [PATCH RFC 7/7] [POWERPC] MPC8360E-RDK: add support for NAND on UPM
From: David Gibson @ 2007-12-10 23:03 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071210204951.GG32278@localhost.localdomain>
On Mon, Dec 10, 2007 at 11:49:51PM +0300, Anton Vorontsov wrote:
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc836x_rdk.dts | 24 +++++++++++++++++++++++-
> arch/powerpc/platforms/83xx/Kconfig | 2 ++
> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 1 +
> 3 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts b/arch/powerpc/boot/dts/mpc836x_rdk.dts
> index a1b2da6..f57ba53 100644
> --- a/arch/powerpc/boot/dts/mpc836x_rdk.dts
> +++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
> @@ -115,7 +115,7 @@
> device_type = "ipic";
> };
>
> - par_io@1400 {
> + qe_pio: par_io@1400 {
> reg = <0x1400 0x100>;
> num-ports = <7>;
> };
> @@ -229,4 +229,26 @@
> interrupt-parent = <&ipic>;
> };
> };
> +
> + localbus@e0005000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8360erdk-localbus",
> + "fsl,mpc8360e-localbus",
> + "fsl,pq2pro-localbus";
> + reg = <0xe0005000 0xd8>;
> + ranges = <1 0 0x60000000 1>;
The bridge translates a range one byte wide? I don't think so...
> +
> + nand-flash@1,0 {
> + compatible = "STMicro,NAND512W3A2BN6E", "fsl,upm-nand";
> + reg = <1 0 1>;
The device has a register window *one byte* wide? That seems
improbable...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH RFC 0/7] "NAND on UPM" and related patches
From: David Gibson @ 2007-12-10 23:04 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071210204705.GA31263@localhost.localdomain>
On Mon, Dec 10, 2007 at 11:47:05PM +0300, Anton Vorontsov wrote:
> Hi all,
>
> Here are patches to support NAND on UPM. That driver is generic for
> all processors with FSL UPMs. And because of that, few more patches are
> needed -- GPIO API and generic FSL UPM functions.
>
> This is early RFC, all patches are in single thread, so everyone could
> make up overall picture of what is going on. I'll split the thread by
> topics after that RFC.
>
> Ok, the patches and what they are for:
>
> 1,2,3,4. GPIO API:
> ------------------
> Usually NAND chips exports RNB (Ready-Not-Busy) pin, so drivers
> could read it and get a hint when chip is ready.
>
> Often, WP (write protect) pin is also connected to GPIO. So, GPIO API
> is mandatory for generic drivers.
>
> OF device tree GPIOs bindings are similar to IRQs:
>
> node {
> gpios = <bank pin bank pin bank pin>;
> gpio-parent = <&par_io_controller>;
> };
>
> "bank pin" scheme is controller specific, so controllers that want
> to implement flat mappings or any other could do so.
It might be safest to do as is done for interrupts, and not define the
internal format at all. The gpio within the gpio controller would be
defined by a gpio-descriptor whose format is determined by the
controller. You would need to add a #gpio-cells property in this
case, so you can at least determine the size of the descriptors
associated with a particular gpio controller.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/3] Use embedded libfdt in the bootwrapper
From: David Gibson @ 2007-12-10 23:10 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071210173217.GB4497@loki.buserror.net>
On Mon, Dec 10, 2007 at 11:32:17AM -0600, Scott Wood wrote:
> On Mon, Dec 10, 2007 at 02:28:39PM +1100, David Gibson wrote:
> > +#define check_err(err) \
> > + ({ \
> > + if (BAD_ERROR(err) || ((err < 0) && DEBUG)) \
> > + printf("%s():%d %s\n\r", __FUNCTION__, __LINE__, \
> > + fdt_strerror(err)); \
> > + if (BAD_ERROR(err)) \
> > + exit(); \
> > + (err < 0) ? -1 : 0; \
> > + })
> > +
> > +#define offset_devp(off) \
> > + ({ \
> > + int offset = (off); \
> > + check_err(offset) ? NULL : (void *)(offset+1); \
> > + })
> > +
> > +#define devp_offset(devp) (((int)(devp))-1)
>
> How does using offsets as devps work if a devp was previously acquired to a
> node that has to be moved due to a change later made in an earlier part of
> the tree?
It doesn't; don't do that. I just don't think truly persistent
phandles are worth the code complexity to implement them. Especially
since their use more-or-less completely precludes libfdt's "stateless"
approach, which has significant other advantages.
To reduce the confusion over this, the libfdt native interface always
refers to the offsets explicitly as offsets. For the bootwrapper
abstraction layer, unfortunately I'm stuck with the "devp" terminology
for the time being.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH RFC 4/7] [GPIO] Let drivers link if they support GPIO API as an addition
From: Anton Vorontsov @ 2007-12-10 23:04 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev
In-Reply-To: <20071210225525.2F6C6266154@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
> > I'm interested in your opinion about that patch. You're also Cc'ed
> > to patch that using that feature.
> >
> > I know, currently that patch will conflict with GPIOLIB patches in -mm,
> > so this is only RFC.
>
> The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
> tell whether that programming interface is available ... starting
> from "#include <asm/gpio.h>", and including all gpio_*() calls.
>
> So my first reaction is to not like this patch. It changes semantics
> in an incompatible way. And AFAICT, needlessly so.
Why incompatible? gpio-aware drivers will get -ENOSYS on gpio_request,
thus they will not do anything wrong. GPIO-only drivers could still
depend on GENERIC_GPIO, and their behaviour will not change.
> What other options did consider? Like, why not #ifdef the GPIO parts
> of that NAND driver,
Hehe, it's used to avoid #ifdef hell indeed. ;-) And no-op wrappers
like that I purposed is widely used to avoid #ifdefs. They will just
optimize away.
> or have the whole driver depend on GENERIC_GPIO?
Well, this is an option, and I was considering this. Further more,
I implemented gpio api for all platforms which currently using fsl
upm nand, so in theory I can add "depends on GENERIC_GPIO".
But the thing is: some drivers don't actually *require* gpios, they
can use it, but at the same time they might live without it.
As for fsl upm nand (the user of that change), it can poll status
from the nand chip instead of looking for RNB gpio. So, strict
depending on GENERIC_GPIO looks weird in that case.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/3] Use embedded libfdt in the bootwrapper
From: Scott Wood @ 2007-12-10 23:19 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev, Paul Mackerras
In-Reply-To: <20071210231056.GC5495@localhost.localdomain>
David Gibson wrote:
> On Mon, Dec 10, 2007 at 11:32:17AM -0600, Scott Wood wrote:
>> How does using offsets as devps work if a devp was previously
>> acquired to a node that has to be moved due to a change later made
>> in an earlier part of the tree?
>
> It doesn't; don't do that. I just don't think truly persistent
> phandles are worth the code complexity to implement them.
We already have working code to implement them. This is a regression
over flatdevicetree.c, and it (or something else in libfdt) seems to be
breaking the ep8248e wrapper (it didn't make it in to the last window
because of dependency on a netdev patch, but I'll probably send it out
tomorrow).
It breaks the extremely common and useful usage of:
devp = create node;
setprop(devp, "foo", something);
setprop(devp, "bar", something);
> Especially since their use more-or-less completely precludes libfdt's
> "stateless" approach, which has significant other advantages.
It doesn't preclude stateless read-only -- what are the benefits to
stateless read-write that are worth invalidating all node references any
time something changes?
-Scott
^ permalink raw reply
* Re: [PATCH RFC 0/7] "NAND on UPM" and related patches
From: Anton Vorontsov @ 2007-12-10 23:10 UTC (permalink / raw)
To: Anton Vorontsov, linuxppc-dev
In-Reply-To: <20071210230453.GB5495@localhost.localdomain>
On Tue, Dec 11, 2007 at 10:04:53AM +1100, David Gibson wrote:
> On Mon, Dec 10, 2007 at 11:47:05PM +0300, Anton Vorontsov wrote:
> > Hi all,
> >
> > Here are patches to support NAND on UPM. That driver is generic for
> > all processors with FSL UPMs. And because of that, few more patches are
> > needed -- GPIO API and generic FSL UPM functions.
> >
> > This is early RFC, all patches are in single thread, so everyone could
> > make up overall picture of what is going on. I'll split the thread by
> > topics after that RFC.
> >
> > Ok, the patches and what they are for:
> >
> > 1,2,3,4. GPIO API:
> > ------------------
> > Usually NAND chips exports RNB (Ready-Not-Busy) pin, so drivers
> > could read it and get a hint when chip is ready.
> >
> > Often, WP (write protect) pin is also connected to GPIO. So, GPIO API
> > is mandatory for generic drivers.
> >
> > OF device tree GPIOs bindings are similar to IRQs:
> >
> > node {
> > gpios = <bank pin bank pin bank pin>;
> > gpio-parent = <&par_io_controller>;
> > };
> >
> > "bank pin" scheme is controller specific, so controllers that want
> > to implement flat mappings or any other could do so.
>
> It might be safest to do as is done for interrupts, and not define the
> internal format at all.
This is how it is done already. Take a look into second and third patches:
+static int par_io_xlate(struct device_node *np, int index)
+{
+ return __of_parse_gpio_bank_pin(np, index, 32, num_par_io_ports);
+}
+
+static struct of_gpio_chip of_gpio_chip = {
+ .xlate = par_io_xlate,
+};
__of_parse_gpio_bank_pin() is helper function, I just factored
it out, because both QE and CPM2 using same format.
But generally, controllers are encouraged to do their own xlates.
Or am I missing the point?
> The gpio within the gpio controller would be
> defined by a gpio-descriptor whose format is determined by the
> controller. You would need to add a #gpio-cells property in this
> case, so you can at least determine the size of the descriptors
> associated with a particular gpio controller.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH RFC 7/7] [POWERPC] MPC8360E-RDK: add support for NAND on UPM
From: Anton Vorontsov @ 2007-12-10 23:16 UTC (permalink / raw)
To: Anton Vorontsov, linuxppc-dev
In-Reply-To: <20071210230321.GA5495@localhost.localdomain>
On Tue, Dec 11, 2007 at 10:03:21AM +1100, David Gibson wrote:
> On Mon, Dec 10, 2007 at 11:49:51PM +0300, Anton Vorontsov wrote:
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> > arch/powerpc/boot/dts/mpc836x_rdk.dts | 24 +++++++++++++++++++++++-
> > arch/powerpc/platforms/83xx/Kconfig | 2 ++
> > arch/powerpc/platforms/83xx/mpc836x_rdk.c | 1 +
> > 3 files changed, 26 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts b/arch/powerpc/boot/dts/mpc836x_rdk.dts
> > index a1b2da6..f57ba53 100644
> > --- a/arch/powerpc/boot/dts/mpc836x_rdk.dts
> > +++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
> > @@ -115,7 +115,7 @@
> > device_type = "ipic";
> > };
> >
> > - par_io@1400 {
> > + qe_pio: par_io@1400 {
> > reg = <0x1400 0x100>;
> > num-ports = <7>;
> > };
> > @@ -229,4 +229,26 @@
> > interrupt-parent = <&ipic>;
> > };
> > };
> > +
> > + localbus@e0005000 {
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + compatible = "fsl,mpc8360erdk-localbus",
> > + "fsl,mpc8360e-localbus",
> > + "fsl,pq2pro-localbus";
> > + reg = <0xe0005000 0xd8>;
> > + ranges = <1 0 0x60000000 1>;
>
> The bridge translates a range one byte wide? I don't think so...
Nope, 4KB min, IIRC.
> > +
> > + nand-flash@1,0 {
> > + compatible = "STMicro,NAND512W3A2BN6E", "fsl,upm-nand";
> > + reg = <1 0 1>;
>
> The device has a register window *one byte* wide? That seems
> improbable...
Here, actually yes. The device just 8 bits wide. Reading next 8 bits
will return the same value, obviously. ;-)
But points taken. I should not derivate chip width from the
ranges/reg. This looks unusual indeed, will implement chip-width
property.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/3] Use embedded libfdt in the bootwrapper
From: Scott Wood @ 2007-12-10 23:27 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev, Paul Mackerras
In-Reply-To: <475DC966.6070301@freescale.com>
Scott Wood wrote:
> David Gibson wrote:
>> On Mon, Dec 10, 2007 at 11:32:17AM -0600, Scott Wood wrote:
>>> How does using offsets as devps work if a devp was previously
>>> acquired to a node that has to be moved due to a change later made
>>> in an earlier part of the tree?
>>
>> It doesn't; don't do that. I just don't think truly persistent
>> phandles are worth the code complexity to implement them.
[snip]
> It breaks the extremely common and useful usage of:
>
> devp = create node;
> setprop(devp, "foo", something);
> setprop(devp, "bar", something);
BTW, there's code in devtree.c with your name on it that does exactly
this. :-)
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] Use embedded libfdt in the bootwrapper
From: David Gibson @ 2007-12-10 23:32 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <475DC966.6070301@freescale.com>
On Mon, Dec 10, 2007 at 05:19:02PM -0600, Scott Wood wrote:
> David Gibson wrote:
> > On Mon, Dec 10, 2007 at 11:32:17AM -0600, Scott Wood wrote:
> >> How does using offsets as devps work if a devp was previously
> >> acquired to a node that has to be moved due to a change later made
> >> in an earlier part of the tree?
> >
> > It doesn't; don't do that. I just don't think truly persistent
> > phandles are worth the code complexity to implement them.
>
> We already have working code to implement them. This is a regression
> over flatdevicetree.c, and it (or something else in libfdt) seems to be
> breaking the ep8248e wrapper (it didn't make it in to the last window
> because of dependency on a netdev patch, but I'll probably send it out
> tomorrow).
>
> It breaks the extremely common and useful usage of:
>
> devp = create node;
> setprop(devp, "foo", something);
> setprop(devp, "bar", something);
Uh.. no, that idiom is fine. setprop() in the node itself, or any
descendent is guaranteed to be safe.
>
> > Especially since their use more-or-less completely precludes libfdt's
> > "stateless" approach, which has significant other advantages.
>
> It doesn't preclude stateless read-only -- what are the benefits to
> stateless read-write that are worth invalidating all node references any
> time something changes?
It precludes stateless read-only too, unless you have an interface
where devps for read-write are different from those for read-only
which would be nasty.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: Xilinx ML310 Linux 2.6 PCI bridge
From: Rick Moleres @ 2007-12-10 23:57 UTC (permalink / raw)
To: Grant Likely, Jean-Samuel Chenard; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40712082218k7e520e45q1266ecb4692b7dbb@mail.gmail.com>
Grant,
Can you give me more details on why you say the opb_pci bridge is badly
broken? I know there have been issues with it in the past, but I'm not
aware of major outages (perhaps I'm just not in the loop).
> However, word of warning. The Xilinx PCI bridge is badly broken.
> Xilinx is not supporting the PCI core and it is missing the ability to
> do certain types of transfers. Last I heard, Xilinx has no plans to
> fix their PCI core either.
The opb_pci and plb_pci (plbv34) bridges have transitioned to the
plbv36_pci bridge in EDK 9.2 and later. This bridge is fully supported
and has been tested under MontaVista's 2.6.10 kernel. I believe only
critical issues will be fixed in the opb/plbv34.
Thanks,
Rick
^ permalink raw reply
* [PATCH 02/19] [POWERPC] consolidate pci_controller
From: Stephen Rothwell @ 2007-12-11 0:00 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <20071206180608.de14e9b1.sfr@canb.auug.org.au>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/pci-bridge.h | 65 +++++++++++++-------------------------
1 files changed, 22 insertions(+), 43 deletions(-)
diff --git a/include/asm-powerpc/pci-bridge.h b/include/asm-powerpc/pci-bridge.h
index e021314..f67d262 100644
--- a/include/asm-powerpc/pci-bridge.h
+++ b/include/asm-powerpc/pci-bridge.h
@@ -11,33 +11,44 @@
#include <linux/list.h>
#include <linux/ioport.h>
-#ifndef CONFIG_PPC64
/*
* Structure of a PCI controller (host bridge)
*/
struct pci_controller {
struct pci_bus *bus;
char is_dynamic;
+#ifdef CONFIG_PPC64
+ int node;
+#endif
void *arch_data;
struct list_head list_node;
struct device *parent;
int first_busno;
int last_busno;
+#ifndef CONFIG_PPC64
int self_busno;
+#endif
void __iomem *io_base_virt;
+#ifdef CONFIG_PPC64
+ void *io_base_alloc;
+#endif
resource_size_t io_base_phys;
/* Some machines (PReP) have a non 1:1 mapping of
* the PCI memory space in the CPU bus space
*/
resource_size_t pci_mem_offset;
+#ifdef CONFIG_PPC64
+ unsigned long pci_io_size;
+#endif
struct pci_ops *ops;
volatile unsigned int __iomem *cfg_addr;
volatile void __iomem *cfg_data;
+#ifndef CONFIG_PPC64
/*
* Used for variants of PCI indirect handling and possible quirks:
* SET_CFG_TYPE - used on 4xx or any PHB that does explicit type0/1
@@ -58,15 +69,24 @@ struct pci_controller {
#define PPC_INDIRECT_TYPE_NO_PCIE_LINK 0x00000008
#define PPC_INDIRECT_TYPE_BIG_ENDIAN 0x00000010
u32 indirect_type;
-
+#endif /* !CONFIG_PPC64 */
/* Currently, we limit ourselves to 1 IO range and 3 mem
* ranges since the common pci_bus structure can't handle more
*/
struct resource io_resource;
struct resource mem_resources[3];
int global_number; /* PCI domain number */
+#ifdef CONFIG_PPC64
+ unsigned long buid;
+ unsigned long dma_window_base_cur;
+ unsigned long dma_window_size;
+
+ void *private_data;
+#endif /* CONFIG_PPC64 */
};
+#ifndef CONFIG_PPC64
+
static inline struct pci_controller *pci_bus_to_host(struct pci_bus *bus)
{
return bus->sysdata;
@@ -108,47 +128,6 @@ extern void __init update_bridge_resource(struct pci_dev *dev,
#else /* CONFIG_PPC64 */
/*
- * Structure of a PCI controller (host bridge)
- */
-struct pci_controller {
- struct pci_bus *bus;
- char is_dynamic;
- int node;
- void *arch_data;
- struct list_head list_node;
- struct device *parent;
-
- int first_busno;
- int last_busno;
-
- void __iomem *io_base_virt;
- void *io_base_alloc;
- resource_size_t io_base_phys;
-
- /* Some machines have a non 1:1 mapping of
- * the PCI memory space in the CPU bus space
- */
- resource_size_t pci_mem_offset;
- unsigned long pci_io_size;
-
- struct pci_ops *ops;
- volatile unsigned int __iomem *cfg_addr;
- volatile void __iomem *cfg_data;
-
- /* Currently, we limit ourselves to 1 IO range and 3 mem
- * ranges since the common pci_bus structure can't handle more
- */
- struct resource io_resource;
- struct resource mem_resources[3];
- int global_number;
- unsigned long buid;
- unsigned long dma_window_base_cur;
- unsigned long dma_window_size;
-
- void *private_data;
-};
-
-/*
* PCI stuff, for nodes representing PCI devices, pointed to
* by device_node->data.
*/
--
1.5.3.7
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 14/19] [POWERPC] Inline pci_setup_pci_controller as it has become trivial
From: Stephen Rothwell @ 2007-12-11 0:02 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <20071207015901.4b6c80bf.sfr@canb.auug.org.au>
and it becomes clear that we should use zalloc_maybe_bootmem.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/pci-common.c | 21 ++++++---------------
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 15ec71a..78cdb70 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -50,27 +50,18 @@ static DEFINE_SPINLOCK(hose_spinlock);
/* XXX kill that some day ... */
static int global_phb_number; /* Global phb counter */
-/*
- * pci_controller(phb) initialized common variables.
- */
-static void __devinit pci_setup_pci_controller(struct pci_controller *hose)
-{
- memset(hose, 0, sizeof(struct pci_controller));
- spin_lock(&hose_spinlock);
- hose->global_number = global_phb_number++;
- list_add_tail(&hose->list_node, &hose_list);
- spin_unlock(&hose_spinlock);
-}
-
-struct pci_controller * pcibios_alloc_controller(struct device_node *dev)
+struct pci_controller *pcibios_alloc_controller(struct device_node *dev)
{
struct pci_controller *phb;
- phb = alloc_maybe_bootmem(sizeof(struct pci_controller), GFP_KERNEL);
+ phb = zalloc_maybe_bootmem(sizeof(struct pci_controller), GFP_KERNEL);
if (phb == NULL)
return NULL;
- pci_setup_pci_controller(phb);
+ spin_lock(&hose_spinlock);
+ phb->global_number = global_phb_number++;
+ list_add_tail(&phb->list_node, &hose_list);
+ spin_unlock(&hose_spinlock);
phb->arch_data = dev;
phb->is_dynamic = mem_init_done;
#ifdef CONFIG_PPC64
--
1.5.3.7
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 16/19] [POWERPC] iSeries: hose->buid is always zero for iSeries
From: Stephen Rothwell @ 2007-12-11 0:03 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <20071207020155.3466763a.sfr@canb.auug.org.au>
so remove a firmware feature test.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/pci_64.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 69364f3..7e74aa2 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -581,12 +581,8 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
/* Decide whether to display the domain number in /proc */
int pci_proc_domain(struct pci_bus *bus)
{
- if (firmware_has_feature(FW_FEATURE_ISERIES))
- return 0;
- else {
- struct pci_controller *hose = pci_bus_to_host(bus);
- return hose->buid != 0;
- }
+ struct pci_controller *hose = pci_bus_to_host(bus);
+ return hose->buid != 0;
}
void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose,
--
1.5.3.7
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: Powerpc PCI cleanups (mainly iSeries)
From: Stephen Rothwell @ 2007-12-11 0:06 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <20071206180045.0eb1db98.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]
On Thu, 6 Dec 2007 18:00:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> I started out looking for ways to remove our dependencies on pci_dn and
> got sidetracked into clening up the iSeries PCI code. The intention of
> the following set of patches is that there be no semantic changes
> (mostly).
I have rebased this series to remove the dependency on benh's patches and
will repost (as replies to the originals) only those that changed
(numbers 2, 14, 16 and I repoested 19 yesterday).
> Overall diffstat looks like this:
> arch/powerpc/kernel/pci-common.c | 31 +--
> arch/powerpc/kernel/pci_32.c | 6 +-
> arch/powerpc/kernel/pci_64.c | 40 +--
> arch/powerpc/kernel/pci_dn.c | 2 +-
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 2 +-
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 +-
> arch/powerpc/platforms/iseries/pci.c | 426 +++++++++++-----------------
> arch/powerpc/platforms/iseries/pci.h | 20 +-
> arch/powerpc/platforms/iseries/setup.c | 2 +
> arch/powerpc/platforms/iseries/vpdinfo.c | 17 +-
> arch/powerpc/platforms/powermac/pci.c | 2 +-
> arch/powerpc/platforms/pseries/iommu.c | 2 +-
> include/asm-powerpc/pci-bridge.h | 156 ++++------
> include/asm-powerpc/ppc-pci.h | 3 -
> 14 files changed, 266 insertions(+), 445 deletions(-)
Now:
arch/powerpc/kernel/isa-bridge.c | 2 +-
arch/powerpc/kernel/pci-common.c | 34 +--
arch/powerpc/kernel/pci_32.c | 10 +-
arch/powerpc/kernel/pci_64.c | 42 +--
arch/powerpc/kernel/pci_dn.c | 2 +-
arch/powerpc/kernel/prom_parse.c | 2 +-
arch/powerpc/kernel/rtas_pci.c | 2 +-
arch/powerpc/platforms/82xx/pq2.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 2 +-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 2 +-
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 +-
arch/powerpc/platforms/cell/io-workarounds.c | 4 +-
arch/powerpc/platforms/celleb/io-workarounds.c | 4 +-
arch/powerpc/platforms/celleb/pci.c | 2 +-
arch/powerpc/platforms/iseries/pci.c | 426 +++++++++--------------
arch/powerpc/platforms/iseries/pci.h | 20 +-
arch/powerpc/platforms/iseries/setup.c | 2 +
arch/powerpc/platforms/iseries/vpdinfo.c | 17 +-
arch/powerpc/platforms/maple/pci.c | 2 +-
arch/powerpc/platforms/powermac/pci.c | 6 +-
arch/powerpc/platforms/pseries/iommu.c | 2 +-
include/asm-powerpc/pci-bridge.h | 159 ++++------
include/asm-powerpc/ppc-pci.h | 3 -
23 files changed, 287 insertions(+), 462 deletions(-)
The extra files are from the arch_data rename posted earlier.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Update smu command definitions
From: Benjamin Herrenschmidt @ 2007-12-11 0:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
From: Michael Hanselmann <linux-kernel@hansmi.ch>
This patch updates smu.h with several new commands and parameter
descriptions for existing ones.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
include/asm-powerpc/smu.h | 132 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 128 insertions(+), 4 deletions(-)
Index: linux-work/include/asm-powerpc/smu.h
===================================================================
--- linux-work.orig/include/asm-powerpc/smu.h 2007-09-28 11:42:10.000000000 +1000
+++ linux-work/include/asm-powerpc/smu.h 2007-12-11 11:17:09.000000000 +1100
@@ -173,7 +173,7 @@
* Power supply control
*
* The "sub" command is an ASCII string in the data, the
- * data lenght is that of the string.
+ * data length is that of the string.
*
* The VSLEW command can be used to get or set the voltage slewing.
* - lenght 5 (only "VSLEW") : it returns "DONE" and 3 bytes of
@@ -201,20 +201,90 @@
*/
#define SMU_CMD_READ_ADC 0xd8
+
/* Misc commands
*
* This command seem to be a grab bag of various things
+ *
+ * Parameters:
+ * 1: subcommand
*/
#define SMU_CMD_MISC_df_COMMAND 0xdf
-#define SMU_CMD_MISC_df_SET_DISPLAY_LIT 0x02 /* i: 1 byte */
+
+/*
+ * Sets "system ready" status
+ *
+ * I did not yet understand how it exactly works or what it does.
+ *
+ * Guessing from OF code, 0x02 activates the display backlight. Apple uses/used
+ * the same codebase for all OF versions. On PowerBooks, this command would
+ * enable the backlight. For the G5s, it only activates the front LED. However,
+ * don't take this for granted.
+ *
+ * Parameters:
+ * 2: status [0x00, 0x01 or 0x02]
+ */
+#define SMU_CMD_MISC_df_SET_DISPLAY_LIT 0x02
+
+/*
+ * Sets mode of power switch.
+ *
+ * What this actually does is not yet known. Maybe it enables some interrupt.
+ *
+ * Parameters:
+ * 2: enable power switch? [0x00 or 0x01]
+ * 3 (optional): enable nmi? [0x00 or 0x01]
+ *
+ * Returns:
+ * If parameter 2 is 0x00 and parameter 3 is not specified, returns wether
+ * NMI is enabled. Otherwise unknown.
+ */
#define SMU_CMD_MISC_df_NMI_OPTION 0x04
+/* Sets LED dimm offset.
+ *
+ * The front LED dimms itself during sleep. Its brightness (or, well, the PWM
+ * frequency) depends on current time. Therefore, the SMU needs to know the
+ * timezone.
+ *
+ * Parameters:
+ * 2-8: unknown (BCD coding)
+ */
+#define SMU_CMD_MISC_df_DIMM_OFFSET 0x99
+
+
/*
* Version info commands
*
- * I haven't quite tried to figure out how these work
+ * Parameters:
+ * 1 (optional): Specifies version part to retrieve
+ *
+ * Returns:
+ * Version value
*/
#define SMU_CMD_VERSION_COMMAND 0xea
+#define SMU_VERSION_RUNNING 0x00
+#define SMU_VERSION_BASE 0x01
+#define SMU_VERSION_UPDATE 0x02
+
+
+/*
+ * Switches
+ *
+ * These are switches whose status seems to be known to the SMU.
+ *
+ * Parameters:
+ * none
+ *
+ * Result:
+ * Switch bits (ORed, see below)
+ */
+#define SMU_CMD_SWITCHES 0xdc
+
+/* Switches bits */
+#define SMU_SWITCH_CASE_CLOSED 0x01
+#define SMU_SWITCH_AC_POWER 0x04
+#define SMU_SWITCH_POWER_SWITCH 0x08
/*
@@ -243,10 +313,64 @@
*/
#define SMU_CMD_MISC_ee_COMMAND 0xee
#define SMU_CMD_MISC_ee_GET_DATABLOCK_REC 0x02
-#define SMU_CMD_MISC_ee_LEDS_CTRL 0x04 /* i: 00 (00,01) [00] */
+
+/* Retrieves currently used watts.
+ *
+ * Parameters:
+ * 1: 0x03 (Meaning unknown)
+ */
+#define SMU_CMD_MISC_ee_GET_WATTS 0x03
+
+#define SMU_CMD_MISC_ee_LEDS_CTRL 0x04 /* i: 00 (00,01) [00] */
#define SMU_CMD_MISC_ee_GET_DATA 0x05 /* i: 00 , o: ?? */
+/*
+ * Power related commands
+ *
+ * Parameters:
+ * 1: subcommand
+ */
+#define SMU_CMD_POWER_EVENTS_COMMAND 0x8f
+
+/* SMU_POWER_EVENTS subcommands */
+enum {
+ SMU_PWR_GET_POWERUP_EVENTS = 0x00,
+ SMU_PWR_SET_POWERUP_EVENTS = 0x01,
+ SMU_PWR_CLR_POWERUP_EVENTS = 0x02,
+ SMU_PWR_GET_WAKEUP_EVENTS = 0x03,
+ SMU_PWR_SET_WAKEUP_EVENTS = 0x04,
+ SMU_PWR_CLR_WAKEUP_EVENTS = 0x05,
+
+ /*
+ * Get last shutdown cause
+ *
+ * Returns:
+ * 1 byte (signed char): Last shutdown cause. Exact meaning unknown.
+ */
+ SMU_PWR_LAST_SHUTDOWN_CAUSE = 0x07,
+
+ /*
+ * Sets or gets server ID. Meaning or use is unknown.
+ *
+ * Parameters:
+ * 2 (optional): Set server ID (1 byte)
+ *
+ * Returns:
+ * 1 byte (server ID?)
+ */
+ SMU_PWR_SERVER_ID = 0x08,
+};
+
+/* Power events wakeup bits */
+enum {
+ SMU_PWR_WAKEUP_KEY = 0x01, /* Wake on key press */
+ SMU_PWR_WAKEUP_AC_INSERT = 0x02, /* Wake on AC adapter plug */
+ SMU_PWR_WAKEUP_AC_CHANGE = 0x04,
+ SMU_PWR_WAKEUP_LID_OPEN = 0x08,
+ SMU_PWR_WAKEUP_RING = 0x10,
+};
+
/*
* - Kernel side interface -
^ permalink raw reply
* Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
From: Stephen Rothwell @ 2007-12-11 0:18 UTC (permalink / raw)
To: Poonam_Aggrwal-b10812
Cc: michael.barkowski, netdev, kumar.gala, linux-kernel, rubini,
linuxppc-dev, ashish.kalra, rich.cutler
In-Reply-To: <Pine.LNX.4.64.0712101734490.29623@linux121>
[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]
On Mon, 10 Dec 2007 17:39:22 +0530 (IST) Poonam_Aggrwal-b10812 <b10812@freescale.com> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -149,22 +149,116 @@ EXPORT_SYMBOL(qe_issue_cmd);
> */
> static unsigned int brg_clk = 0;
>
> -unsigned int get_brg_clk(void)
> +u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
> {
> - struct device_node *qe;
> - if (brg_clk)
> - return brg_clk;
> + struct device_node *qe, *brg, *clocks;
> + enum qe_clock brg_src;
> + u32 brg_input_freq = 0;
> + u32 brg_num;
> + const unsigned int *prop;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> + *brg_source = 0;
> +
> + brg_num = brgclk - QE_BRG1;
> + brg = of_find_compatible_node(NULL, NULL, "fsl,cpm-brg");
> + if (brg) {
> unsigned int size;
> - const u32 *prop = of_get_property(qe, "brg-frequency", &size);
> - brg_clk = *prop;
> - of_node_put(qe);
> - };
> + prop = of_get_property(brg,
> + "fsl,brg-sources", &size);
> +
> + brg_src = *(prop + brg_num);
You should probably sanity check that prop is not NULL and points to
something large enough.
You don't use brg after here, so the "of_node_put(brg)" could go here to
save putting it in multiple places later. Also, currently there are
paths through the following code that do not do the of_node_put(brg).
> + if (brg_src == 0) {
> + *brg_source = 0;
> + if (brg_clk > 0) {
> + of_node_put(brg);
> + return brg_clk;
> + }
> + qe = of_find_node_by_type(NULL, "qe");
> + if (qe) {
> + unsigned int size;
> + prop = of_get_property
> + (qe, "brg-frequency", &size);
> + of_node_put(qe);
> + of_node_put(brg);
> + return *prop;
NULL check here (yes, I know that the old code didn't check).
> + }
> + } else {
> + *brg_source = brg_src + QE_CLK1 - 1;
> + clocks = of_find_compatible_node(NULL, NULL,
> + "fsl,cpm-clocks");
> + prop = of_get_property(clocks,
> + "#clock-cells", &size);
> + /*
> + * clock-cells = 1 only supported right now.
> + */
> + if (*prop != 1)
Again check for NULL (and possibly size).
> + return 0;
> + prop = of_get_property(clocks,
> + "clock-frequency", &size);
> +
> + brg_input_freq = *(prop+(brg_src - 1));
And again.
> + of_node_put(clocks);
> + of_node_put(brg);
> + return brg_input_freq;
> + }
> + }
> return brg_clk;
> }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Xilinx ML310 Linux 2.6 PCI bridge
From: Grant Likely @ 2007-12-11 0:20 UTC (permalink / raw)
To: Rick Moleres; +Cc: Jean-Samuel Chenard, linuxppc-embedded
In-Reply-To: <20071210235609.91265F18074@mail188-sin.bigfish.com>
On 12/10/07, Rick Moleres <Rick.Moleres@xilinx.com> wrote:
>
> Grant,
>
> Can you give me more details on why you say the opb_pci bridge is badly
> broken? I know there have been issues with it in the past, but I'm not
> aware of major outages (perhaps I'm just not in the loop).
Actually, it's more likely that I'm not in the loop (see below)
I know of 2 projects that had difficulty with the opb_pci core; The
major issue was that it didn't support all of the PCI transfer modes
(IIRC it was the multiple read transfer command). Last I heard from
the FAE was that Xilinx was not offering support for the core.
> The opb_pci and plb_pci (plbv34) bridges have transitioned to the
> plbv36_pci bridge in EDK 9.2 and later. This bridge is fully supported
> and has been tested under MontaVista's 2.6.10 kernel. I believe only
> critical issues will be fixed in the opb/plbv34.
This I was not aware of. I stand corrected.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powerpc: Update smu command definitions
From: Benjamin Herrenschmidt @ 2007-12-11 0:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20071211001849.38E70DDECF@ozlabs.org>
On Tue, 2007-12-11 at 11:18 +1100, Benjamin Herrenschmidt wrote:
> From: Michael Hanselmann <linux-kernel@hansmi.ch>
>
> This patch updates smu.h with several new commands and parameter
> descriptions for existing ones.
>
> Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> ---
Note that this patch has been around for a looooong time. For some
reason, it fell through the cracks but since it's really only
documentation (well, adding #defines for new commands and additional
comments, there is no actual code change), I think it's safe to go
in .24.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: Stephen Rothwell @ 2007-12-11 0:30 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071210202934.GA32046@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 891 bytes --]
On Mon, 10 Dec 2007 23:29:34 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> +++ b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
> +
> +static void __init mpc836x_rdk_setup_arch(void)
> +{
> + struct device_node *np;
> +
> + if (ppc_md.progress)
> + ppc_md.progress("mpc836x_rdk_setup_arch()", 0);
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + qe_reset();
> +
> + np = of_find_node_by_name(NULL, "par_io");
> + if (np)
> + par_io_init(np);
> + else
> + pr_warning("QE PIO not initialized!\n");
of_node_put(np); ?
> +static int __init mpc836x_rdk_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "MPC836xRDK");
You need to include asm/prom.h to use the flattened device tree accessors.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 0/8] powerpc: mv64x60/prpmc2800 - DTS updates, etc.
From: Mark A. Greer @ 2007-12-11 0:31 UTC (permalink / raw)
To: linuxppc-dev
This is the broken out patch series that equates to the "big blob"
patch (with minor modifications) that was sent here:
http://patchwork.ozlabs.org/linuxppc/patch?id=15382
These patches depend on the following patches to apply cleanly:
http://patchwork.ozlabs.org/linuxppc/patch?id=14397
http://patchwork.ozlabs.org/linuxppc/patch?id=14396
http://patchwork.ozlabs.org/linuxppc/patch?id=14631
http://patchwork.ozlabs.org/linuxppc/patch?id=14632
http://patchwork.ozlabs.org/linuxppc/patch?id=14633
http://patchwork.ozlabs.org/linuxppc/patch?id=15007
Please let me know if you have any issues with these patches.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH RFC 0/7] "NAND on UPM" and related patches
From: David Gibson @ 2007-12-11 0:36 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071210231052.GB1141@zarina>
On Tue, Dec 11, 2007 at 02:10:52AM +0300, Anton Vorontsov wrote:
> On Tue, Dec 11, 2007 at 10:04:53AM +1100, David Gibson wrote:
> > On Mon, Dec 10, 2007 at 11:47:05PM +0300, Anton Vorontsov wrote:
> > > Hi all,
> > >
> > > Here are patches to support NAND on UPM. That driver is generic for
> > > all processors with FSL UPMs. And because of that, few more patches are
> > > needed -- GPIO API and generic FSL UPM functions.
> > >
> > > This is early RFC, all patches are in single thread, so everyone could
> > > make up overall picture of what is going on. I'll split the thread by
> > > topics after that RFC.
> > >
> > > Ok, the patches and what they are for:
> > >
> > > 1,2,3,4. GPIO API:
> > > ------------------
> > > Usually NAND chips exports RNB (Ready-Not-Busy) pin, so drivers
> > > could read it and get a hint when chip is ready.
> > >
> > > Often, WP (write protect) pin is also connected to GPIO. So, GPIO API
> > > is mandatory for generic drivers.
> > >
> > > OF device tree GPIOs bindings are similar to IRQs:
> > >
> > > node {
> > > gpios = <bank pin bank pin bank pin>;
> > > gpio-parent = <&par_io_controller>;
> > > };
> > >
> > > "bank pin" scheme is controller specific, so controllers that want
> > > to implement flat mappings or any other could do so.
> >
> > It might be safest to do as is done for interrupts, and not define the
> > internal format at all.
>
> This is how it is done already. Take a look into second and third patches:
>
> +static int par_io_xlate(struct device_node *np, int index)
> +{
> + return __of_parse_gpio_bank_pin(np, index, 32, num_par_io_ports);
> +}
> +
> +static struct of_gpio_chip of_gpio_chip = {
> + .xlate = par_io_xlate,
> +};
>
> __of_parse_gpio_bank_pin() is helper function, I just factored
> it out, because both QE and CPM2 using same format.
>
> But generally, controllers are encouraged to do their own xlates.
>
> Or am I missing the point?
Right, but you are assuming a fixed size (2 cells?) for the bank/pin
information, arent' you - I didn't see any #gpio-cells or similar
looking property. I'm wondering if some gpio controllers might want
less (only one bank) or more (bank, pin, polarity/flags perhaps).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 1/8] powerpc: prpmc2800 - Convert dts file to v1
From: Mark A. Greer @ 2007-12-11 0:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071211003108.GA4995@mag.az.mvista.com>
From: Mark A. Greer <mgreer@mvista.com>
Convert the prpmc2800.dts file to dts-v1. Basically, this means
converting the numeric constants to be 'C'-like (e.g., hexadecimal
numbers start with '0x').
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
arch/powerpc/boot/dts/prpmc2800.dts | 188 +++++++++++++-------------
1 file changed, 96 insertions(+), 92 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts b/arch/powerpc/boot/dts/prpmc2800.dts
index 24944ca..15247a4 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -11,6 +11,8 @@
* if it can determine the exact PrPMC type.
*/
+/dts-v1/;
+
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -25,64 +27,64 @@
PowerPC,7447 {
device_type = "cpu";
reg = <0>;
- clock-frequency = <2bb0b140>; /* Default (733 MHz) */
- bus-frequency = <7f28155>; /* 133.333333 MHz */
- timebase-frequency = <1fca055>; /* 33.333333 MHz */
- i-cache-line-size = <20>;
- d-cache-line-size = <20>;
- i-cache-size = <8000>;
- d-cache-size = <8000>;
+ clock-frequency = <733333333>; /* Default */
+ bus-frequency = <133333333>;
+ timebase-frequency = <33333333>;
+ i-cache-line-size = <0x20>;
+ d-cache-line-size = <0x20>;
+ i-cache-size = <0x8000>;
+ d-cache-size = <0x8000>;
};
};
memory {
device_type = "memory";
- reg = <00000000 20000000>; /* Default (512MB) */
+ reg = <0x00000000 0x20000000>; /* Default (512MB) */
};
mv64x60@f1000000 { /* Marvell Discovery */
#address-cells = <1>;
#size-cells = <1>;
model = "mv64360"; /* Default */
- compatible = "marvell,mv64x60";
- clock-frequency = <7f28155>; /* 133.333333 MHz */
- reg = <f1000000 00010000>;
- virtual-reg = <f1000000>;
- ranges = <88000000 88000000 01000000 /* PCI 0 I/O Space */
- 80000000 80000000 08000000 /* PCI 0 MEM Space */
- a0000000 a0000000 04000000 /* User FLASH */
- 00000000 f1000000 00010000 /* Bridge's regs */
- f2000000 f2000000 00040000>; /* Integrated SRAM */
+ compatible = "marvell,mv64360";
+ clock-frequency = <133333333>;
+ reg = <0xf1000000 0x00010000>;
+ virtual-reg = <0xf1000000>;
+ ranges = <0x88000000 0x88000000 0x01000000 /* PCI 0 I/O Space */
+ 0x80000000 0x80000000 0x08000000 /* PCI 0 MEM Space */
+ 0xa0000000 0xa0000000 0x04000000 /* User FLASH */
+ 0x00000000 0xf1000000 0x00010000 /* Bridge's regs */
+ 0xf2000000 0xf2000000 0x00040000>;/* Integrated SRAM*/
flash@a0000000 {
compatible = "cfi-flash";
- reg = <a0000000 04000000>;
+ reg = <0xa0000000 0x04000000>;
bank-width = <4>;
device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
fw@0 {
label = "FW Image A";
- reg = <00000000 00100000>;
+ reg = <0x00000000 0x00100000>;
read-only;
};
cfg@100000 {
label = "FW Config Data"; /* RW */
- reg = <00100000 00040000>;
+ reg = <0x00100000 0x00040000>;
};
kernel@140000 {
label = "Kernel Image";
- reg = <00140000 00400000>;
+ reg = <0x00140000 0x00400000>;
read-only;
};
fs@540000 {
label = "Filesystem";
- reg = <00540000 039c0000>;
+ reg = <0x00540000 0x039c0000>;
read-only;
};
fw@3f00000 {
label = "FW Image B";
- reg = <03f00000 00100000>;
+ reg = <0x03f00000 0x00100000>;
read-only;
};
};
@@ -95,26 +97,26 @@
ethernet-phy@1 {
device_type = "ethernet-phy";
compatible = "broadcom,bcm5421";
- interrupts = <4c>; /* GPP 12 */
+ interrupts = <76>; /* GPP 12 */
interrupt-parent = <&/mv64x60/pic>;
reg = <1>;
};
ethernet-phy@3 {
device_type = "ethernet-phy";
compatible = "broadcom,bcm5421";
- interrupts = <4c>; /* GPP 12 */
+ interrupts = <76>; /* GPP 12 */
interrupt-parent = <&/mv64x60/pic>;
reg = <3>;
};
};
ethernet@2000 {
- reg = <2000 2000>;
+ reg = <0x2000 0x2000>;
eth0 {
device_type = "network";
compatible = "marvell,mv64x60-eth";
block-index = <0>;
- interrupts = <20>;
+ interrupts = <32>;
interrupt-parent = <&/mv64x60/pic>;
phy = <&/mv64x60/mdio/ethernet-phy@1>;
local-mac-address = [ 00 00 00 00 00 00 ];
@@ -123,7 +125,7 @@
device_type = "network";
compatible = "marvell,mv64x60-eth";
block-index = <1>;
- interrupts = <21>;
+ interrupts = <33>;
interrupt-parent = <&/mv64x60/pic>;
phy = <&/mv64x60/mdio/ethernet-phy@3>;
local-mac-address = [ 00 00 00 00 00 00 ];
@@ -133,110 +135,110 @@
sdma@4000 {
device_type = "dma";
compatible = "marvell,mv64x60-sdma";
- reg = <4000 c18>;
- virtual-reg = <f1004000>;
+ reg = <0x4000 0xc18>;
+ virtual-reg = <0xf1004000>;
interrupt-base = <0>;
- interrupts = <24>;
+ interrupts = <36>;
interrupt-parent = <&/mv64x60/pic>;
};
sdma@6000 {
device_type = "dma";
compatible = "marvell,mv64x60-sdma";
- reg = <6000 c18>;
- virtual-reg = <f1006000>;
+ reg = <0x6000 0xc18>;
+ virtual-reg = <0xf1006000>;
interrupt-base = <0>;
- interrupts = <26>;
+ interrupts = <38>;
interrupt-parent = <&/mv64x60/pic>;
};
brg@b200 {
compatible = "marvell,mv64x60-brg";
- reg = <b200 8>;
+ reg = <0xb200 0x8>;
clock-src = <8>;
- clock-frequency = <7ed6b40>;
- current-speed = <2580>;
+ clock-frequency = <133000000>;
+ current-speed = <9600>;
bcr = <0>;
};
brg@b208 {
compatible = "marvell,mv64x60-brg";
- reg = <b208 8>;
+ reg = <0xb208 0x8>;
clock-src = <8>;
- clock-frequency = <7ed6b40>;
- current-speed = <2580>;
+ clock-frequency = <133000000>;
+ current-speed = <9600>;
bcr = <0>;
};
cunit@f200 {
- reg = <f200 200>;
+ reg = <0xf200 0x200>;
};
mpscrouting@b400 {
- reg = <b400 c>;
+ reg = <0xb400 0xc>;
};
mpscintr@b800 {
- reg = <b800 100>;
- virtual-reg = <f100b800>;
+ reg = <0xb800 0x100>;
+ virtual-reg = <0xf100b800>;
};
mpsc@8000 {
device_type = "serial";
compatible = "marvell,mpsc";
- reg = <8000 38>;
- virtual-reg = <f1008000>;
+ reg = <0x8000 0x38>;
+ virtual-reg = <0xf1008000>;
sdma = <&/mv64x60/sdma@4000>;
brg = <&/mv64x60/brg@b200>;
cunit = <&/mv64x60/cunit@f200>;
mpscrouting = <&/mv64x60/mpscrouting@b400>;
mpscintr = <&/mv64x60/mpscintr@b800>;
block-index = <0>;
- max_idle = <28>;
+ max_idle = <40>;
chr_1 = <0>;
chr_2 = <0>;
chr_10 = <3>;
mpcr = <0>;
- interrupts = <28>;
+ interrupts = <40>;
interrupt-parent = <&/mv64x60/pic>;
};
mpsc@9000 {
device_type = "serial";
compatible = "marvell,mpsc";
- reg = <9000 38>;
- virtual-reg = <f1009000>;
+ reg = <0x9000 0x38>;
+ virtual-reg = <0xf1009000>;
sdma = <&/mv64x60/sdma@6000>;
brg = <&/mv64x60/brg@b208>;
cunit = <&/mv64x60/cunit@f200>;
mpscrouting = <&/mv64x60/mpscrouting@b400>;
mpscintr = <&/mv64x60/mpscintr@b800>;
block-index = <1>;
- max_idle = <28>;
+ max_idle = <40>;
chr_1 = <0>;
chr_2 = <0>;
chr_10 = <3>;
mpcr = <0>;
- interrupts = <2a>;
+ interrupts = <42>;
interrupt-parent = <&/mv64x60/pic>;
};
wdt@b410 { /* watchdog timer */
compatible = "marvell,mv64x60-wdt";
- reg = <b410 8>;
- timeout = <a>; /* wdt timeout in seconds */
+ reg = <0xb410 0x8>;
+ timeout = <10>; /* wdt timeout in seconds */
};
i2c@c000 {
device_type = "i2c";
compatible = "marvell,mv64x60-i2c";
- reg = <c000 20>;
- virtual-reg = <f100c000>;
+ reg = <0xc000 0x20>;
+ virtual-reg = <0xf100c000>;
freq_m = <8>;
freq_n = <3>;
- timeout = <3e8>; /* 1000 = 1 second */
+ timeout = <1000>; /* 1000 = 1 second */
retries = <1>;
- interrupts = <25>;
+ interrupts = <37>;
interrupt-parent = <&/mv64x60/pic>;
};
@@ -244,18 +246,18 @@
#interrupt-cells = <1>;
#address-cells = <0>;
compatible = "marvell,mv64x60-pic";
- reg = <0000 88>;
+ reg = <0x0000 0x88>;
interrupt-controller;
};
mpp@f000 {
compatible = "marvell,mv64x60-mpp";
- reg = <f000 10>;
+ reg = <0xf000 0x10>;
};
gpp@f100 {
compatible = "marvell,mv64x60-gpp";
- reg = <f100 20>;
+ reg = <0xf100 0x20>;
};
pci@80000000 {
@@ -264,66 +266,68 @@
#interrupt-cells = <1>;
device_type = "pci";
compatible = "marvell,mv64x60-pci";
- reg = <0cf8 8>;
- ranges = <01000000 0 0 88000000 0 01000000
- 02000000 0 80000000 80000000 0 08000000>;
- bus-range = <0 ff>;
- clock-frequency = <3EF1480>;
- interrupt-pci-iack = <0c34>;
+ reg = <0x0cf8 0x8>;
+ ranges = <0x01000000 0x0 0x0
+ 0x88000000 0x0 0x01000000
+ 0x02000000 0x0 0x80000000
+ 0x80000000 0x0 0x08000000>;
+ bus-range = <0x0 0xff>;
+ clock-frequency = <66000000>;
+ interrupt-pci-iack = <0x0c34>;
interrupt-parent = <&/mv64x60/pic>;
- interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0a */
- 5000 0 0 1 &/mv64x60/pic 50
- 5000 0 0 2 &/mv64x60/pic 51
- 5000 0 0 3 &/mv64x60/pic 5b
- 5000 0 0 4 &/mv64x60/pic 5d
+ 0x5000 0 0 1 &/mv64x60/pic 80
+ 0x5000 0 0 2 &/mv64x60/pic 81
+ 0x5000 0 0 3 &/mv64x60/pic 91
+ 0x5000 0 0 4 &/mv64x60/pic 93
/* IDSEL 0x0b */
- 5800 0 0 1 &/mv64x60/pic 5b
- 5800 0 0 2 &/mv64x60/pic 5d
- 5800 0 0 3 &/mv64x60/pic 50
- 5800 0 0 4 &/mv64x60/pic 51
+ 0x5800 0 0 1 &/mv64x60/pic 91
+ 0x5800 0 0 2 &/mv64x60/pic 93
+ 0x5800 0 0 3 &/mv64x60/pic 80
+ 0x5800 0 0 4 &/mv64x60/pic 81
/* IDSEL 0x0c */
- 6000 0 0 1 &/mv64x60/pic 5b
- 6000 0 0 2 &/mv64x60/pic 5d
- 6000 0 0 3 &/mv64x60/pic 50
- 6000 0 0 4 &/mv64x60/pic 51
+ 0x6000 0 0 1 &/mv64x60/pic 91
+ 0x6000 0 0 2 &/mv64x60/pic 93
+ 0x6000 0 0 3 &/mv64x60/pic 80
+ 0x6000 0 0 4 &/mv64x60/pic 81
/* IDSEL 0x0d */
- 6800 0 0 1 &/mv64x60/pic 5d
- 6800 0 0 2 &/mv64x60/pic 50
- 6800 0 0 3 &/mv64x60/pic 51
- 6800 0 0 4 &/mv64x60/pic 5b
+ 0x6800 0 0 1 &/mv64x60/pic 93
+ 0x6800 0 0 2 &/mv64x60/pic 80
+ 0x6800 0 0 3 &/mv64x60/pic 81
+ 0x6800 0 0 4 &/mv64x60/pic 91
>;
};
cpu-error@0070 {
compatible = "marvell,mv64x60-cpu-error";
- reg = <0070 10 0128 28>;
- interrupts = <03>;
+ reg = <0x0070 0x10 0x0128 0x28>;
+ interrupts = <3>;
interrupt-parent = <&/mv64x60/pic>;
};
sram-ctrl@0380 {
compatible = "marvell,mv64x60-sram-ctrl";
- reg = <0380 80>;
- interrupts = <0d>;
+ reg = <0x0380 0x80>;
+ interrupts = <13>;
interrupt-parent = <&/mv64x60/pic>;
};
pci-error@1d40 {
compatible = "marvell,mv64x60-pci-error";
- reg = <1d40 40 0c28 4>;
- interrupts = <0c>;
+ reg = <0x1d40 0x40 0x0c28 0x4>;
+ interrupts = <12>;
interrupt-parent = <&/mv64x60/pic>;
};
mem-ctrl@1400 {
compatible = "marvell,mv64x60-mem-ctrl";
- reg = <1400 60>;
- interrupts = <11>;
+ reg = <0x1400 0x60>;
+ interrupts = <17>;
interrupt-parent = <&/mv64x60/pic>;
};
};
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox