Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one

2008-06-28 Thread Grant Likely
On Sun, Jun 29, 2008 at 08:31:43AM +0200, Jean Delvare wrote:
> Hi Jon, Grant,
> 
> On Sat, 28 Jun 2008 22:49:40 -0600, Grant Likely wrote:
> > On Sat, Jun 28, 2008 at 10:05:28PM -0400, Jon Smirl wrote:
> > > >
> > > > The driver was previously using i2c_add_numbered_adapter(), giving MPC
> > > >  platform the possibility to use new-style i2c drivers:
> > > >  
> > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1469fa263870acd890a4b9f6ef557acc5d673b44
> > > >  You're breaking this, I doubt it's on purpose?
> > > 
> > > Grant, what do you want here? You're the one who converted it to
> > > i2c_add_numbered_adapter. But in other posts you've said that the
> > > device tree should have nothing to do with bus numbering.
> > 
> > Yes, I did make that change, but that was when it was a platform bus
> > driver.  Converting it to an of_platform bus driver entirely changes the
> > situation and it should go back to using i2c_add_adapter() with a parse
> > of the device tree for child nodes.
> 
> I am surprised and disappointed, as this sounds like a regression.
> Registering the i2c buses with random numbers and parsing the device
> tree later to figure out which devices are where, is what everybody was
> doing before the new i2c device/driver matching model was implemented,
> because there was no other way. I'm curious why you are going back to
> this approach when i2c-core now offers something way cleaner and more
> efficient.

Ah, but the whole random number parsing thing is no longer necessary
because we ensure that registration of i2c devices always occurs
after the i2c adapter is created (for device tree aware i2c adapter
drivers.  adapters that aren't device tree aware still need to assign a
number).

After the i2c adapter registers itself, of_register_i2c_devices() is called
which walks through the child nodes of the i2c adapter node in the device
tree.  Each child node is an i2c device, and it immediately get
registered with the adapter.  Because this ensures that i2c device
registration always happens after adapter registration, and since the
pointer to the i2c_adapter is known, then i2c_new_device() can be used
directly without ever needing to know the bus number.

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one

2008-06-28 Thread Jean Delvare
Hi Jon, Grant,

On Sat, 28 Jun 2008 22:49:40 -0600, Grant Likely wrote:
> On Sat, Jun 28, 2008 at 10:05:28PM -0400, Jon Smirl wrote:
> > On 6/25/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > >  >
> > >  >   i2c->adap = mpc_ops;
> > >  > - i2c->adap.nr = pdev->id;
> > >  >   i2c_set_adapdata(&i2c->adap, i2c);
> > >  > - i2c->adap.dev.parent = &pdev->dev;
> > >  > - if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
> > >  > + i2c->adap.dev.parent = &op->dev;
> > >  > +
> > >  > + result = i2c_add_adapter(&i2c->adap);
> > >
> > >
> > > The driver was previously using i2c_add_numbered_adapter(), giving MPC
> > >  platform the possibility to use new-style i2c drivers:
> > >  
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1469fa263870acd890a4b9f6ef557acc5d673b44
> > >  You're breaking this, I doubt it's on purpose?
> > 
> > Grant, what do you want here? You're the one who converted it to
> > i2c_add_numbered_adapter. But in other posts you've said that the
> > device tree should have nothing to do with bus numbering.
> 
> Yes, I did make that change, but that was when it was a platform bus
> driver.  Converting it to an of_platform bus driver entirely changes the
> situation and it should go back to using i2c_add_adapter() with a parse
> of the device tree for child nodes.

I am surprised and disappointed, as this sounds like a regression.
Registering the i2c buses with random numbers and parsing the device
tree later to figure out which devices are where, is what everybody was
doing before the new i2c device/driver matching model was implemented,
because there was no other way. I'm curious why you are going back to
this approach when i2c-core now offers something way cleaner and more
efficient.

But well, you'll know better. I'm not familiar with the platform, and
don't have the time to look into it anyway.

> > Once this driver is converted to an OF one it shouldn't need bus ids
> > since all of the i2c devices will be children of the bus node. We can
> > just let the i2c subsystem assign a bus number.
> 
> Exactly.
> 
> > Timur has some issues with the i2c bus number in his ALSA driver. The
> > problem is locating the i2c device when the i2s driver loads. Parsing
> > the device tree to extract an i2c bus and device number is not a good
> > solution.
> 
> The trick here is to store the pointer to the device node inside the
> i2c device.  I do this with SPI devices like this:
> 
>   /* Store a pointer to the node in the device structure */
>   of_node_get(nc);
>   spi->dev.archdata.of_node = nc;
> 
> Then, when you've got a device_node pointer, you can parse through the
> set of registered SPI devices and match against the one that has the
> same device node pointer.
> 
> > codec-handle should give you the i2c device node. But then we can't
> > use of_find_device_by_node because the i2c device is not an of_device,
> > it's a cross platform i2c_device. Should of_find_device_by_node()
> > return a 'struct device' instead of a 'struct of_device' and leave it
> > as a user exercise to cast up? It is used nine times in the kernel,
> > mostly sparc.
> 
> No, this doesn't work because I2C and SPI devices are not of_platform
> devices.  They aren't even platform devices.  of_find_device_by_node()
> only works for the of_platform bus.
> 
> Using archdata.of_node is part of the device structure and works for
> every bus type (platform, of_platform, SPI, I2C, PCI, etc.)

-- 
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [Resend][PATCH 1/8][Version 2] MPC5121 Update MPC5121ADS device tree

2008-06-28 Thread Grant Likely
On Thu, Jun 26, 2008 at 09:40:57PM -0600, John Rigby wrote:
> On Thu, Jun 26, 2008 at 7:42 PM, David Gibson <[EMAIL PROTECTED]> wrote:
> > On Wed, Jun 18, 2008 at 02:24:46PM -0600, John Rigby wrote:
> >>   [EMAIL PROTECTED] {
> >>   compatible = "fsl,mpc5121-immr";
> >> + device_type = "soc";
> >
> > I realise we still need the unwanted device_type value on the soc in
> > some cases for backwards compatibility, but why are you adding it
> > where it wasn't before..?
> >
> Because get_immrbase in fsl_soc.c does not work without it.

I think I'd rather see get_immrbase() instead then.

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [Resend][PATCH 1/8][Version 2] MPC5121 Update MPC5121ADS device tree

2008-06-28 Thread Grant Likely
On Wed, Jun 18, 2008 at 02:24:46PM -0600, John Rigby wrote:
> Updated device tree for MPC5121ADS

Really should be more detailed in the commit message.

> 
> Signed-off-by: John Rigby <[EMAIL PROTECTED]>
> ---
>  arch/powerpc/boot/dts/mpc5121ads.dts |  309 -
>  1 files changed, 299 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts 
> b/arch/powerpc/boot/dts/mpc5121ads.dts
> index 94ad7b2..67dc920 100644
> --- a/arch/powerpc/boot/dts/mpc5121ads.dts
> +++ b/arch/powerpc/boot/dts/mpc5121ads.dts
> @@ -1,7 +1,7 @@
>  /*
> - * MPC5121E MDS Device Tree Source
> + * MPC5121E ADS Device Tree Source
>   *
> - * Copyright 2007 Freescale Semiconductor Inc.
> + * Copyright 2007,2008 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
> @@ -17,6 +17,10 @@
>   #address-cells = <1>;
>   #size-cells = <1>;
>  
> + aliases {
> + pci = &pci;
> + };
> +
>   cpus {
>   #address-cells = <1>;
>   #size-cells = <0>;
> @@ -39,6 +43,39 @@
>   reg = <0x 0x1000>;  // 256MB at 0
>   };
>  
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc5121-mbx";
> + reg = <0x2000 0x4000>;
> + interrupts = <66 0x8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc5121-sram";
> + reg = <0x3000 0x2>; // 128K at 0x3000
> + };
> +
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc5121-nfc";
> + reg = <0x4000 0x10>;// 1M at 0x4000
> + interrupts = <6 8>;
> + interrupt-parent = < &ipic >;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <1>;
> + // ADS has two Hynix 512MB Nand flash chips in a single
> + // stacked package .
> + chips = <2>;
> + [EMAIL PROTECTED] {
> + label = "nand0";
> + reg = <0x 0x0200>;  // first 32 MB of chip 0
> + };
> + [EMAIL PROTECTED] {
> + label = "nand1";
> + reg = <0x2000 0x0200>;  // first 32 MB of chip 1
> + };
> + };
> +
>   [EMAIL PROTECTED] {
>   compatible = "fsl,mpc5121ads-localbus";
>   #address-cells = <2>;
> @@ -51,18 +88,56 @@
>   [EMAIL PROTECTED],0 {
>   compatible = "cfi-flash";
>   reg = <0 0x0 0x400>;
> + #address-cells = <1>;
> + #size-cells = <1>;
>   bank-width = <4>;
> - device-width = <1>;
> + device-width = <2>;
> + [EMAIL PROTECTED] {
> + label = "protected";
> + reg = <0x 0x0004>;  // first sector 
> is protected
> + read-only;
> + };
> + [EMAIL PROTECTED] {
> + label = "filesystem";
> + reg = <0x0004 0x03c0>;  // 60M for 
> filesystem
> + };
> + [EMAIL PROTECTED] {
> + label = "kernel";
> + reg = <0x03c4 0x0028>;  // 2.5M for 
> kernel
> + };
> + [EMAIL PROTECTED] {
> + label = "device-tree";
> + reg = <0x03ec 0x0004>;  // one sector 
> for device tree
> + };
> + [EMAIL PROTECTED] {
> + label = "u-boot";
> + reg = <0x03f0 0x0010>;  // 1M for u-boot
> + read-only;
> + };
>   };
>  
>   [EMAIL PROTECTED],0 {
>   compatible = "fsl,mpc5121ads-cpld";
>   reg = <0x2 0x0 0x8000>;
>   };
> +
> + cpld_pic: [EMAIL PROTECTED],a {
> + compatible = "fsl,mpc5121ads-cpld-pic";
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + reg = <0x2 0xa 0x5>;
> + interrupt-parent = < &ipic >;
> + // irq routing
> + //  all irqs but touch screen are routed to irq0 
> (ipic 48)
> + //  touch screen is statically routed to irq1 (ipic 
> 17)
> + //  so don't use it here
> + interrupts = <48 0x8>;
> + };
>   };
>  
> 

Re: [PATCH 2/2] powerpc: Move mpc83xx_add_bridge to fsl_pci.c [rev2]

2008-06-28 Thread Grant Likely
On Thu, Jun 26, 2008 at 11:07:57AM -0600, John Rigby wrote:
> This allows other platforms with the same pci
> block like MPC5121 to use it.
> 
> Signed-off-by: John Rigby <[EMAIL PROTECTED]>

Acked-by: Grant Likely <[EMAIL PROTECTED]>

> ---
>  arch/powerpc/platforms/83xx/Kconfig   |2 +-
>  arch/powerpc/platforms/83xx/Makefile  |1 -
>  arch/powerpc/platforms/83xx/mpc831x_rdb.c |1 +
>  arch/powerpc/platforms/83xx/mpc832x_mds.c |1 +
>  arch/powerpc/platforms/83xx/mpc832x_rdb.c |1 +
>  arch/powerpc/platforms/83xx/mpc834x_itx.c |1 +
>  arch/powerpc/platforms/83xx/mpc834x_mds.c |1 +
>  arch/powerpc/platforms/83xx/mpc836x_mds.c |1 +
>  arch/powerpc/platforms/83xx/mpc837x_mds.c |1 +
>  arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 +
>  arch/powerpc/platforms/83xx/mpc83xx.h |1 -
>  arch/powerpc/platforms/83xx/pci.c |   91 
> -
>  arch/powerpc/platforms/83xx/sbc834x.c |1 +
>  arch/powerpc/sysdev/fsl_pci.c |   61 +++
>  arch/powerpc/sysdev/fsl_pci.h |1 +
>  15 files changed, 72 insertions(+), 94 deletions(-)
>  delete mode 100644 arch/powerpc/platforms/83xx/pci.c
> 
> diff --git a/arch/powerpc/platforms/83xx/Kconfig 
> b/arch/powerpc/platforms/83xx/Kconfig
> index 0a306eb..ca2c149 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -3,7 +3,7 @@ menuconfig MPC83xx
>   depends on PPC_83xx
>   select PPC_UDBG_16550
>   select PPC_PCI_CHOICE
> - select PPC_INDIRECT_PCI
> + select FSL_PCI if PCI
>  
>  if MPC83xx
>  
> diff --git a/arch/powerpc/platforms/83xx/Makefile 
> b/arch/powerpc/platforms/83xx/Makefile
> index 76494be..59c413c 100644
> --- a/arch/powerpc/platforms/83xx/Makefile
> +++ b/arch/powerpc/platforms/83xx/Makefile
> @@ -2,7 +2,6 @@
>  # Makefile for the PowerPC 83xx linux kernel.
>  #
>  obj-y:= misc.o usb.o
> -obj-$(CONFIG_PCI)+= pci.o
>  obj-$(CONFIG_MPC831x_RDB)+= mpc831x_rdb.o
>  obj-$(CONFIG_MPC832x_RDB)+= mpc832x_rdb.o
>  obj-$(CONFIG_MPC834x_MDS)+= mpc834x_mds.o
> diff --git a/arch/powerpc/platforms/83xx/mpc831x_rdb.c 
> b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
> index c4db517..a428f8d 100644
> --- a/arch/powerpc/platforms/83xx/mpc831x_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mpc83xx.h"
>  
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c 
> b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> index 6dbc6ea..dd4be4a 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c 
> b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> index e7f706b..f049d69 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mpc83xx.h"
>  
> diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c 
> b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> index 50e8f63..7301d77 100644
> --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mpc83xx.h"
>  
> diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c 
> b/arch/powerpc/platforms/83xx/mpc834x_mds.c
> index 2b8a0a3..30d509a 100644
> --- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mpc83xx.h"
>  
> diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c 
> b/arch/powerpc/platforms/83xx/mpc836x_mds.c
> index c2e5de6..75b80e8 100644
> --- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c 
> b/arch/powerpc/platforms/83xx/mpc837x_mds.c
> index 64d17b0..be62de2 100644
> --- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mpc83xx.h"
>  
> diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c 
> b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
> index c00356b..da030af 100644
> --- a/arch/powerpc/platforms/83xx/mpc837x_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mpc83xx.h"
>  
> diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h 
> b/arch/powerpc/platforms/83xx/mpc83xx.h
> index 88a3b5c..3

Re: [PATCH 1/2] powerpc: pci config cleanup [rev2]

2008-06-28 Thread Grant Likely
On Thu, Jun 26, 2008 at 11:07:56AM -0600, John Rigby wrote:
> Choosing PCI or not at config time is allowed on some
> platforms via an if expression in arch/powerpc/Kconfig.
> To add a new platform with PCI support selectable at
> config time, you must change the if expression.  This
> patch makes this easier by changing:
> bool "PCI support" if 
> to
> bool "PCI support" if PPC_PCI_CHOICE
> and adding select PPC_PCI_CHOICE to all the config nodes that
> were previously in the PCI if expression.
> 
> Platforms with unconditional PCI support continue to
> just select PCI in their config nodes.
> 
> Signed-off-by: John Rigby <[EMAIL PROTECTED]>

Acked-by: Grant Likely <[EMAIL PROTECTED]>

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support

2008-06-28 Thread Grant Likely
On Tue, Jun 24, 2008 at 03:07:48PM -0600, John Linn wrote:
> Hi Grant,
> 
> It appears that you designed the simpleImage around Xilinx FPGAs.

Yes.

> Since we have to initialize the 16550 UART in the bootstrap and there's
> no boot loader, were you thinking we would add the 16550 initialization
> to simpleboot.c?

Yes; or at least break out the common routine to be called by all
simpleImage targets and have a virtex-specific 'frontend' to it called
simpleboot-virtex405.c.

> 
> Why do we want a flat binary rather than an elf file for the target?

'Cause a flat binary can be loaded anywhere in RAM and is smaller than
an ELF image (no headers).

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support

2008-06-28 Thread Grant Likely
On Mon, Jun 23, 2008 at 09:35:56PM -0400, Josh Boyer wrote:
> On Mon, 23 Jun 2008 15:30:35 -0600 John Linn <[EMAIL PROTECTED]> wrote:
> > I'll try to better understand if we can detect the compressed device
> > tree and if we really have to disable the APU.
> > 
> > What's the reasoning for being independent of the kernel, maybe it's
> > obvious to everyone but me?
> 
> The intention, as I understand it, is that the wrapper utilities can be
> installed stand-alone and used to wrap other kernels if needs be.  In
> practice I've not seen this happen yet, as most PowerPC kernels
> are built directly from the kernel source.  Fedora does have a
> separate package for the wrapper bits, but I'm not entirely sure it's
> used.
> 
> My understanding could be totally wrong, and if so I'll politely ask
> Paul or anyone else to hit me with a cluebat :).

AFAIK, the reason is to be able to build multiple bootwrapper
configurations around a single kernel image without multiple compiles of
the wrapper bits, and to increase the amount of compile testing that all
the wrapper bits are subjected to.  (this way they get compiled on all
PowerPC kernel compiles instead of just when they are needed for an
obscure platform)

g.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 6/6] MPC5121 Hide pci bridge

2008-06-28 Thread Grant Likely
On Fri, Jun 20, 2008 at 10:58:39AM -0600, John Rigby wrote:
> The class of the MPC5121 pci host bridge is PCI_CLASS_BRIDGE_OTHER
> while other freescale host bridges have class set to
> PCI_CLASS_PROCESSOR_POWERPC.
> 
> This patch makes fixup_hide_host_resource_fsl match
> PCI_CLASS_BRIDGE_OTHER in addition to PCI_CLASS_PROCESSOR_POWERPC.
> 
> Signed-off-by: John Rigby <[EMAIL PROTECTED]>

This looks right to me, but I'm not really qualified to say if it is
correct or not (limited PCI experience).  I don't know who needs to look
at it.  Kumar perhaps?

Cheers,
g.

> ---
>  arch/powerpc/kernel/pci_32.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
> index 88db4ff..3d33935 100644
> --- a/arch/powerpc/kernel/pci_32.c
> +++ b/arch/powerpc/kernel/pci_32.c
> @@ -54,11 +54,12 @@ LIST_HEAD(hose_list);
>  static int pci_bus_count;
>  
>  static void
> -fixup_hide_host_resource_fsl(struct pci_dev* dev)
> +fixup_hide_host_resource_fsl(struct pci_dev *dev)
>  {
>   int i, class = dev->class >> 8;
>  
> - if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
> + if ((class == PCI_CLASS_PROCESSOR_POWERPC
> + || class == PCI_CLASS_BRIDGE_OTHER) &&
>   (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
>   (dev->bus->parent == NULL)) {
>   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> -- 
> 1.5.6.rc0.46.gd2b3
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 5/6] MPC5121 Add PCI support

2008-06-28 Thread Grant Likely
On Fri, Jun 20, 2008 at 10:58:38AM -0600, John Rigby wrote:
> Copied from 83xx minus support for two busses.

If this is a copy, then can it be shared?

g.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 4/6] MPC5121 Add MPC5121ADS cpld support

2008-06-28 Thread Grant Likely
Minor comments below.

On Fri, Jun 20, 2008 at 10:58:37AM -0600, John Rigby wrote:
> Add a interrupt host for the interrupt
> controller in the mpc5121ads cpld.
> PCI interrupts are 0-7 the rest are 8-15
> Touchscreen pendown irq is hardwired to irq1
> All other irqs are chainged to irq0
> 
> Signed-off-by: John Rigby <[EMAIL PROTECTED]>
> ---
>  arch/powerpc/platforms/512x/Kconfig|1 +
>  arch/powerpc/platforms/512x/Makefile   |2 +-
>  arch/powerpc/platforms/512x/mpc5121_ads.c  |   14 ++-
>  arch/powerpc/platforms/512x/mpc5121_ads.h  |   14 ++
>  arch/powerpc/platforms/512x/mpc5121_ads_cpld.c |  204 
> 
>  5 files changed, 233 insertions(+), 2 deletions(-)
>  create mode 100644 arch/powerpc/platforms/512x/mpc5121_ads.h
>  create mode 100644 arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
> 
> diff --git a/arch/powerpc/platforms/512x/Kconfig 
> b/arch/powerpc/platforms/512x/Kconfig
> index f9a04da..0fd3b00 100644
> --- a/arch/powerpc/platforms/512x/Kconfig
> +++ b/arch/powerpc/platforms/512x/Kconfig
> @@ -12,6 +12,7 @@ config MPC5121_ADS
>   depends on PPC_MULTIPLATFORM && PPC32
>   select DEFAULT_UIMAGE
>   select PPC_MPC5121
> + select MPC5121_ADS_CPLD

What is this for?  I don't see it used anywhere.

>   help
> This option enables support for the MPC5121E ADS board.
>  
> diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c 
> b/arch/powerpc/platforms/512x/mpc5121_ads.c
> index 45bb2ef..36805fd 100644
> --- a/arch/powerpc/platforms/512x/mpc5121_ads.c
> +++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
> + * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc. All rights 
> reserved.
>   *
>   * Author: John Rigby, <[EMAIL PROTECTED]>, Thur Mar 29 2007
>   *
> @@ -23,6 +23,16 @@
>  #include 
>  
>  #include "mpc512x.h"
> +#include "mpc5121_ads.h"
> +
> +static void __init mpc5121_ads_setup_arch(void)
> +{
> + printk(KERN_INFO "MPC5121 ADS board from Freescale Semiconductor\n");
> + /*
> +  * cpld regs are needed early
> +  */
> + mpc5121_ads_cpld_map();
> +}
>  
>  static struct of_device_id __initdata of_bus_ids[] = {
>   { .name = "soc", },
> @@ -41,6 +51,7 @@ static void __init 
> mpc5121_ads_declare_of_platform_devices(void)
>  static void __init mpc5121_ads_init_IRQ(void)
>  {
>   mpc512x_init_IRQ();
> + mpc5121_ads_cpld_pic_init();

Ah, I understand now.  Ignore my related comment in the previous patch.

>  }
>  
>  /*
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 3/6] MPC5121 Add generic board support

2008-06-28 Thread Grant Likely
Mostly looks good, but a few comments below.

On Fri, Jun 20, 2008 at 10:58:36AM -0600, John Rigby wrote:
> Move shared code from mpc5121_ads.c to mpc512x_shared.c.
> Add new generic board setup mpc5121_generic.c
> 
> Signed-off-by: John Rigby <[EMAIL PROTECTED]>
> ---
>  arch/powerpc/platforms/512x/Kconfig   |   15 -
>  arch/powerpc/platforms/512x/Makefile  |3 +-
>  arch/powerpc/platforms/512x/mpc5121_ads.c |   45 +---
>  arch/powerpc/platforms/512x/mpc5121_generic.c |   72 
> +
>  arch/powerpc/platforms/512x/mpc512x.h |   14 +
>  arch/powerpc/platforms/512x/mpc512x_shared.c  |   66 ++
>  6 files changed, 168 insertions(+), 47 deletions(-)
>  create mode 100644 arch/powerpc/platforms/512x/mpc5121_generic.c
>  create mode 100644 arch/powerpc/platforms/512x/mpc512x.h
>  create mode 100644 arch/powerpc/platforms/512x/mpc512x_shared.c
> 
> diff --git a/arch/powerpc/platforms/512x/Kconfig 
> b/arch/powerpc/platforms/512x/Kconfig
> index 4c0da0c..f9a04da 100644
> --- a/arch/powerpc/platforms/512x/Kconfig
> +++ b/arch/powerpc/platforms/512x/Kconfig
> @@ -2,12 +2,10 @@ config PPC_MPC512x
>   bool
>   select FSL_SOC
>   select IPIC
> - default n
>  
>  config PPC_MPC5121
>   bool
>   select PPC_MPC512x
> - default n
>  
>  config MPC5121_ADS
>   bool "Freescale MPC5121E ADS"
> @@ -16,4 +14,15 @@ config MPC5121_ADS
>   select PPC_MPC5121
>   help
> This option enables support for the MPC5121E ADS board.
> - default n
> +
> +config MPC5121_GENERIC
> + bool "Generic support for simple MPC5121 based boards"
> + depends on PPC_MULTIPLATFORM && PPC32
> + select DEFAULT_UIMAGE
> + select PPC_MPC5121
> + help
> +   This option enables support for simple MPC5121 based boards
> +   which do not need custome platform specific setup.

typo

> +
> +   Compatible boards include:  Protonic LVT base boards (ZANMCU
> +   and VICVT2).
> diff --git a/arch/powerpc/platforms/512x/Makefile 
> b/arch/powerpc/platforms/512x/Makefile
> index ef6c925..e6674c8 100644
> --- a/arch/powerpc/platforms/512x/Makefile
> +++ b/arch/powerpc/platforms/512x/Makefile
> @@ -1,5 +1,6 @@
>  #
>  # Makefile for the Freescale PowerPC 512x linux kernel.
>  #
> -obj-y:= clock.o
> +obj-y:= clock.o mpc512x_shared.o
>  obj-$(CONFIG_MPC5121_ADS)+= mpc5121_ads.o
> +obj-$(CONFIG_MPC5121_GENERIC)+= mpc5121_generic.o
> diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c 
> b/arch/powerpc/platforms/512x/mpc5121_ads.c
> index 50bd3a3..45bb2ef 100644
> --- a/arch/powerpc/platforms/512x/mpc5121_ads.c
> +++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
> @@ -68,20 +40,7 @@ static void __init 
> mpc5121_ads_declare_of_platform_devices(void)
>  
>  static void __init mpc5121_ads_init_IRQ(void)
>  {
> - struct device_node *np;
> -
> - np = of_find_compatible_node(NULL, NULL, "fsl,ipic");
> - if (!np)
> - return;
> -
> - ipic_init(np, 0);
> - of_node_put(np);
> -
> - /*
> -  * Initialize the default interrupt mapping priorities,
> -  * in case the boot rom changed something on us.
> -  */
> - ipic_set_default_priority();
> + mpc512x_init_IRQ();
>  }

Why not just put mpc512x_init_IRQ directly into the machine structure?
>  
>  /*
> diff --git a/arch/powerpc/platforms/512x/mpc5121_generic.c 
> b/arch/powerpc/platforms/512x/mpc5121_generic.c
> new file mode 100644
> index 000..0111a98
> --- /dev/null
> +++ b/arch/powerpc/platforms/512x/mpc5121_generic.c
> @@ -0,0 +1,72 @@
> +/*
> + * Copyright (C) 2007,2008 Freescale Semiconductor, Inc. All rights reserved.
> + *
> + * Author: John Rigby, <[EMAIL PROTECTED]>
> + *
> + * Description:
> + * MPC5121 SoC setup
> + *
> + * This 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 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "mpc512x.h"
> +
> +static struct of_device_id __initdata of_bus_ids[] = {
> + { .name = "soc", },
> + { .name = "localbus", },

Ugh.  Not good.  Bind against compatible, not name or type.

> + {},
> +};
> +
> +static void __init mpc5121_generic_declare_of_platform_devices(void)
> +{
> + /* Find every child of the SOC node and add it to of_platform */
> + if (of_platform_bus_probe(NULL, of_bus_ids, NULL))
> + printk(KERN_ERR __FILE__ ": "
> + "Error while probing of_platform bus\n");
> +}
> +
> +/*
> + * list of supported boards
> + */
> +static char *board[] __initdata = {
> + "prt,prtlvt",
> + NULL
> +};
> +
> +/*
> + * Called very early, MMU is off, device-tree isn't unflattened
>

Re: [PATCH 2/6] MPC5121 clock driver

2008-06-28 Thread Grant Likely
Mostly looks good, a few comments below.

On Fri, Jun 20, 2008 at 10:58:35AM -0600, John Rigby wrote:
> Implements the api defined in include/clk.h
> 
> Current only getting frequencies is supported
> not setting.

Need a more detailed commit message.  This doesn't tell me much.

> 
> Signed-off-by: John Rigby <[EMAIL PROTECTED]>
> ---
>  arch/powerpc/platforms/512x/Makefile |1 +
>  arch/powerpc/platforms/512x/clock.c  |  729 
> ++
>  2 files changed, 730 insertions(+), 0 deletions(-)
>  create mode 100644 arch/powerpc/platforms/512x/clock.c
> 
> diff --git a/arch/powerpc/platforms/512x/Makefile 
> b/arch/powerpc/platforms/512x/Makefile
> index 232c89f..ef6c925 100644
> --- a/arch/powerpc/platforms/512x/Makefile
> +++ b/arch/powerpc/platforms/512x/Makefile
> @@ -1,4 +1,5 @@
>  #
>  # Makefile for the Freescale PowerPC 512x linux kernel.
>  #
> +obj-y:= clock.o

should be +=

>  obj-$(CONFIG_MPC5121_ADS)+= mpc5121_ads.o
> diff --git a/arch/powerpc/platforms/512x/clock.c 
> b/arch/powerpc/platforms/512x/clock.c
> new file mode 100644
> index 000..39db722
> --- /dev/null
> +++ b/arch/powerpc/platforms/512x/clock.c
> @@ -0,0 +1,729 @@
> +/*
> + * Copyright (C) 2007,2008 Freescale Semiconductor, Inc. All rights reserved.
> + *
> + * Author: John Rigby <[EMAIL PROTECTED]>
> + *
> + * Implements the clk api defined in include/linux/clk.h
> + *
> + *Original based on linux/arch/arm/mach-integrator/clock.c
> + *
> + *Copyright (C) 2004 ARM Limited.
> + *Written by Deep Blue Solutions Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static int clocks_initialized;
> +
> +struct module;

This is already defined in linux/module.h?

> +
> +#undef CLK_DEBUG

I think this line should be at the top of the file to be easier to find
when toggling it.

> +#ifdef CLK_DEBUG
> +void dump_clocks(void)
> +{
> + struct clk *p;
> +
> + mutex_lock(&clocks_mutex);
> + printk(KERN_INFO "CLOCKS:\n");
> + list_for_each_entry(p, &clocks, node) {
> + printk(KERN_INFO "  %s %ld", p->name, p->rate);
> + if (p->parent)
> + printk(KERN_INFO " %s %ld", p->parent->name,
> +p->parent->rate);
> + if (p->flags & CLK_HAS_CTRL)
> + printk(KERN_INFO " reg/bit %d/%d", p->reg, p->bit);
> + printk("\n");
> + }
> + mutex_unlock(&clocks_mutex);
> +}
> +#define  DEBUG_CLK_DUMP() dump_clocks()
> +#else
> +#define  DEBUG_CLK_DUMP()
> +#endif
> +
> +static long ips_to_ref(unsigned long rate)
> +{
> + int ips_div = (clockctl->scfr1 >> 23) & 0x7;
> +
> + rate *= ips_div;/* csb_clk = ips_clk * ips_div */
> + rate *= 2;  /* sys_clk = csb_clk * 2 */
> + return sys_to_ref(rate);
> +}
> +
> +static unsigned long devtree_getfreq(char *nodetype, char *clockname)

Why is nodetype even passed in here?  It isn't used, and besides, you
shouldn't test against device_type anyway.  Test against compatible
instead.

> +{
> + struct device_node *node;
> + const unsigned int *fp;
> + unsigned int val = 0;
> +
> + node = of_find_node_by_type(NULL, "soc");

Once again; don't look for device_type == "soc".  Use compatible.

> + if (node) {
> + fp = of_get_property(node, clockname, NULL);
> + if (fp)
> + val = of_read_ulong(fp, 1);
> + }
> + return val;
> +}
> +
> +static void ref_clk_calc(struct clk *clk)
> +{
> + unsigned long rate;
> +
> + rate = devtree_getfreq("soc", "ref-frequency");
> + if (rate == 0) {
> + /*
> +  * no reference clock in device tree
> +  * get ips clock freq and go backwards from there
> +  */
> + rate = devtree_getfreq("soc", "bus-frequency");
> + if (rate == 0) {
> + printk(KERN_WARNING
> + "No bus-frequency in dev tree using 66MHz\n");
> + clk->rate = 6600;

Is it even worth trying to use a default here?  I think it should fail
loudly instead to reduce the risk of people shipping boards with badly
formed device trees.  I don't think there is any backwards compatibility
need for doing this.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Convert i2c-mpc from a platform driver to an of_platform one

2008-06-28 Thread Grant Likely
On Tue, Jun 10, 2008 at 8:40 PM, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Convert i2c-mpc from a platform driver into an of_platform driver.
> This patch is much smaller since Jochen already added
> of_find_i2c_driver(). Versions of this have been posted before.
>
> Signed-ff-by: Jon Smirl <[EMAIL PROTECTED]>
>
> --
> +   if (of_device_is_compatible(op->node, "mpc5200-i2c"))
> +   i2c->flags |= FSL_I2C_DEV_CLOCK_5200;

This needs to also test for "fsl,mpc5200-i2c".  "mpc5200-i2c" isn't
used on current device trees, but there may be some deployed boards
which still have this string.

> +static const struct of_device_id mpc_i2c_of_match[] = {
> +   {
> +   .compatible = "fsl-i2c",
> +   },

You can probably shorten this by 2 lines if you change it to:
+   { .compatible = "fsl-i2c", },

Doing so makes it more readable when you need to add additional
compatible values.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one

2008-06-28 Thread Grant Likely
On Sat, Jun 28, 2008 at 10:05:28PM -0400, Jon Smirl wrote:
> On 6/25/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> >  >
> >  >   i2c->adap = mpc_ops;
> >  > - i2c->adap.nr = pdev->id;
> >  >   i2c_set_adapdata(&i2c->adap, i2c);
> >  > - i2c->adap.dev.parent = &pdev->dev;
> >  > - if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
> >  > + i2c->adap.dev.parent = &op->dev;
> >  > +
> >  > + result = i2c_add_adapter(&i2c->adap);
> >
> >
> > The driver was previously using i2c_add_numbered_adapter(), giving MPC
> >  platform the possibility to use new-style i2c drivers:
> >  
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1469fa263870acd890a4b9f6ef557acc5d673b44
> >  You're breaking this, I doubt it's on purpose?
> 
> Grant, what do you want here? You're the one who converted it to
> i2c_add_numbered_adapter. But in other posts you've said that the
> device tree should have nothing to do with bus numbering.

Yes, I did make that change, but that was when it was a platform bus
driver.  Converting it to an of_platform bus driver entirely changes the
situation and it should go back to using i2c_add_adapter() with a parse
of the device tree for child nodes.

> Once this driver is converted to an OF one it shouldn't need bus ids
> since all of the i2c devices will be children of the bus node. We can
> just let the i2c subsystem assign a bus number.

Exactly.

> Timur has some issues with the i2c bus number in his ALSA driver. The
> problem is locating the i2c device when the i2s driver loads. Parsing
> the device tree to extract an i2c bus and device number is not a good
> solution.

The trick here is to store the pointer to the device node inside the
i2c device.  I do this with SPI devices like this:

/* Store a pointer to the node in the device structure */
of_node_get(nc);
spi->dev.archdata.of_node = nc;

Then, when you've got a device_node pointer, you can parse through the
set of registered SPI devices and match against the one that has the
same device node pointer.

> codec-handle should give you the i2c device node. But then we can't
> use of_find_device_by_node because the i2c device is not an of_device,
> it's a cross platform i2c_device. Should of_find_device_by_node()
> return a 'struct device' instead of a 'struct of_device' and leave it
> as a user exercise to cast up? It is used nine times in the kernel,
> mostly sparc.

No, this doesn't work because I2C and SPI devices are not of_platform
devices.  They aren't even platform devices.  of_find_device_by_node()
only works for the of_platform bus.

Using archdata.of_node is part of the device structure and works for
every bus type (platform, of_platform, SPI, I2C, PCI, etc.)

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Non-numbered ibm iic driver

2008-06-28 Thread Grant Likely
On Sat, Jun 28, 2008 at 11:43:39PM -0400, Sean MacLennan wrote:
> On Sat, 28 Jun 2008 23:25:05 -0400
> "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> 
> > On 6/28/08, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> > > This is a patch to the ibm iic driver that uses the non-numbered
> > >  i2c call and therefore does not need an index. Instead, it
> > > registers the ibm iic, then walks all the child nodes and adds
> > > them. This is required for new style drivers, old style drivers
> > > "just work".
> > 
> > Check out the code in drivers/of/of_i2c.c. Can you use it instead?
> 
> Sure can. The for loop can be replaced with:
> 
>   of_register_i2c_devices(adap, np);
> 
> I have tested it and it works. I guess it makes sense to put of_i2c.c
> under drivers/of, but if it had been under drivers/i2c, I would have
> noticed it ;)
> 
> But is this the way we want to go? I personally like it. It gets rid of
> the index and gets rid of the i2c_register_board_info() from the
> platform code.

Oops, forgot to include the list on my first reply...

Yes, this is the way to go.  I've got a patch that does the same thing
for SPI busses which I need to post for 2nd review.

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Non-numbered ibm iic driver

2008-06-28 Thread Sean MacLennan
On Sat, 28 Jun 2008 23:25:05 -0400
"Jon Smirl" <[EMAIL PROTECTED]> wrote:

> On 6/28/08, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> > This is a patch to the ibm iic driver that uses the non-numbered
> >  i2c call and therefore does not need an index. Instead, it
> > registers the ibm iic, then walks all the child nodes and adds
> > them. This is required for new style drivers, old style drivers
> > "just work".
> 
> Check out the code in drivers/of/of_i2c.c. Can you use it instead?

Sure can. The for loop can be replaced with:

of_register_i2c_devices(adap, np);

I have tested it and it works. I guess it makes sense to put of_i2c.c
under drivers/of, but if it had been under drivers/i2c, I would have
noticed it ;)

But is this the way we want to go? I personally like it. It gets rid of
the index and gets rid of the i2c_register_board_info() from the
platform code.

Cheers,
   Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Non-numbered ibm iic driver

2008-06-28 Thread Jon Smirl
On 6/28/08, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> This is a patch to the ibm iic driver that uses the non-numbered
>  i2c call and therefore does not need an index. Instead, it registers the
>  ibm iic, then walks all the child nodes and adds them. This is required
>  for new style drivers, old style drivers "just work".

Check out the code in drivers/of/of_i2c.c. Can you use it instead?

>
>  The warp has both a new style driver (ad7414) and old style (eeprom)
>  devices.
>
>  This patch is completely function but not a complete patch (the index
>  code is not needed for example). It is just for comment.
>
>  The warp.dts needed for this to work is, I believe, in Josh's next tree.
>
>  Cheers,
>Sean
>
>  P.S. Do I need a signed-off-by for an RFC?
>
>  Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
>  ---
>
>  diff --git a/drivers/i2c/busses/i2c-ibm_iic.c 
> b/drivers/i2c/busses/i2c-ibm_iic.c
>  index 85dbf34..0ec6849 100644
>  --- a/drivers/i2c/busses/i2c-ibm_iic.c
>  +++ b/drivers/i2c/busses/i2c-ibm_iic.c
>  @@ -753,7 +753,7 @@ static int __devinit iic_probe(struct ocp_device *ocp){
>  */
> adap->nr = dev->idx >= 0 ? dev->idx : 0;
>
>  -   if ((ret = i2c_add_numbered_adapter(adap)) < 0) {
>  +   if ((ret = i2c_add_adapter(adap)) < 0) {
> printk(KERN_ERR "ibm-iic%d: failed to register i2c adapter\n",
> dev->idx);
> goto fail;
>  @@ -874,6 +874,7 @@ static int __devinit iic_probe(struct of_device *ofdev,
>const struct of_device_id *match)
>   {
> struct device_node *np = ofdev->node;
>  +   struct device_node *child;
> struct ibm_iic_private *dev;
> struct i2c_adapter *adap;
> const u32 *indexp, *freq;
>  @@ -939,12 +940,33 @@ static int __devinit iic_probe(struct of_device *ofdev,
> adap->timeout = 1;
> adap->nr = dev->idx;
>
>  -   ret = i2c_add_numbered_adapter(adap);
>  +   ret = i2c_add_adapter(adap);
> if (ret  < 0) {
> dev_err(&ofdev->dev, "failed to register i2c adapter\n");
> goto error_cleanup;
> }
>
>  +   for_each_child_of_node(np, child) {
>  +   struct i2c_board_info info;
>  +   const u32 *reg;
>  +
>  +   reg = of_get_property(child, "reg", NULL);
>  +   if (!reg) {
>  +   printk(KERN_ERR "Could not find address for %s\n",
>  +  child->name);
>  +   continue;
>  +   }
>  +
>  +   memset(&info, 0, sizeof(info));
>  +   strlcpy(info.type, child->name, I2C_NAME_SIZE);
>  +   info.addr = *reg;
>  +
>  +   if (!i2c_new_device(adap, &info))
>  +   printk(KERN_ERR "Could not add i2c device %s.\n",
>  +  child->name);
>  +   }
>  +
>  +
> dev_info(&ofdev->dev, "using %s mode\n",
>  dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
>
>  ___
>  Linuxppc-dev mailing list
>  Linuxppc-dev@ozlabs.org
>  https://ozlabs.org/mailman/listinfo/linuxppc-dev
>


-- 
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[RFC] Non-numbered ibm iic driver

2008-06-28 Thread Sean MacLennan
This is a patch to the ibm iic driver that uses the non-numbered
i2c call and therefore does not need an index. Instead, it registers the
ibm iic, then walks all the child nodes and adds them. This is required
for new style drivers, old style drivers "just work".

The warp has both a new style driver (ad7414) and old style (eeprom)
devices.

This patch is completely function but not a complete patch (the index
code is not needed for example). It is just for comment.

The warp.dts needed for this to work is, I believe, in Josh's next tree.

Cheers,
   Sean

P.S. Do I need a signed-off-by for an RFC?

Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---

diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 85dbf34..0ec6849 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -753,7 +753,7 @@ static int __devinit iic_probe(struct ocp_device *ocp){
 */
adap->nr = dev->idx >= 0 ? dev->idx : 0;
 
-   if ((ret = i2c_add_numbered_adapter(adap)) < 0) {
+   if ((ret = i2c_add_adapter(adap)) < 0) {
printk(KERN_ERR "ibm-iic%d: failed to register i2c adapter\n",
dev->idx);
goto fail;
@@ -874,6 +874,7 @@ static int __devinit iic_probe(struct of_device *ofdev,
   const struct of_device_id *match)
 {
struct device_node *np = ofdev->node;
+   struct device_node *child;
struct ibm_iic_private *dev;
struct i2c_adapter *adap;
const u32 *indexp, *freq;
@@ -939,12 +940,33 @@ static int __devinit iic_probe(struct of_device *ofdev,
adap->timeout = 1;
adap->nr = dev->idx;
 
-   ret = i2c_add_numbered_adapter(adap);
+   ret = i2c_add_adapter(adap);
if (ret  < 0) {
dev_err(&ofdev->dev, "failed to register i2c adapter\n");
goto error_cleanup;
}
 
+   for_each_child_of_node(np, child) {
+   struct i2c_board_info info;
+   const u32 *reg;
+
+   reg = of_get_property(child, "reg", NULL);
+   if (!reg) {
+   printk(KERN_ERR "Could not find address for %s\n",
+  child->name);
+   continue;
+   }
+
+   memset(&info, 0, sizeof(info));
+   strlcpy(info.type, child->name, I2C_NAME_SIZE);
+   info.addr = *reg;
+
+   if (!i2c_new_device(adap, &info))
+   printk(KERN_ERR "Could not add i2c device %s.\n",
+  child->name);
+   }
+
+
dev_info(&ofdev->dev, "using %s mode\n",
 dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one

2008-06-28 Thread Jon Smirl
On 6/25/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
>  >
>  >   i2c->adap = mpc_ops;
>  > - i2c->adap.nr = pdev->id;
>  >   i2c_set_adapdata(&i2c->adap, i2c);
>  > - i2c->adap.dev.parent = &pdev->dev;
>  > - if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
>  > + i2c->adap.dev.parent = &op->dev;
>  > +
>  > + result = i2c_add_adapter(&i2c->adap);
>
>
> The driver was previously using i2c_add_numbered_adapter(), giving MPC
>  platform the possibility to use new-style i2c drivers:
>  
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1469fa263870acd890a4b9f6ef557acc5d673b44
>  You're breaking this, I doubt it's on purpose?

Grant, what do you want here? You're the one who converted it to
i2c_add_numbered_adapter. But in other posts you've said that the
device tree should have nothing to do with bus numbering.

Once this driver is converted to an OF one it shouldn't need bus ids
since all of the i2c devices will be children of the bus node. We can
just let the i2c subsystem assign a bus number.

Timur has some issues with the i2c bus number in his ALSA driver. The
problem is locating the i2c device when the i2s driver loads. Parsing
the device tree to extract an i2c bus and device number is not a good
solution.

codec-handle should give you the i2c device node. But then we can't
use of_find_device_by_node because the i2c device is not an of_device,
it's a cross platform i2c_device. Should of_find_device_by_node()
return a 'struct device' instead of a 'struct of_device' and leave it
as a user exercise to cast up? It is used nine times in the kernel,
mostly sparc.

[EMAIL PROTECTED] { /* PSC1 in i2s mode */
device_type = "sound";
compatible = "mpc5200b-psc-i2s","fsl,mpc5200b-psc-i2s";
cell-index = <0>;
reg = <0x2000 0x100>;
interrupts = <0x2 0x2 0x0>;
interrupt-parent = <&mpc5200_pic>;
codec-handle = <&tas0>;
};
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
compatible = 
"fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
cell-index = <0>;
reg = <0x3d00 0x40>;
interrupts = <0x2 0xf 0x0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;

tas0:[EMAIL PROTECTED] {
compatible = "ti,tas5504";
reg = <0x1b>;
};
};

-- 
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v2] update crypto node definition and device tree instances

2008-06-28 Thread Segher Boessenkool

I'm really don't like "fsl,sec1.0" or any of the variants as a
compatible property either because it can easily be abused (it's not
anchored to a specific physical part so the meaning can shift over
time); but that is another argument and it is well documented in other
email threads  
(http://thread.gmane.org/gmane.linux.ports.ppc64.devel/38977/ 
focus=39147)


Also, these made-up names make you do more work: you'll need to
write up a binding for them, explaining exactly what a 1.0 device
etc. is (or at least point to documentation for it).  If you use
a name that refers to some device that people can easily google
for documentation, you can skip this (well, you might need to
write a binding anyway; but at least you won't have to explain
what the device _is_).

Using actual model names also reduces the namespace pollution
(hopefully Freescale will not create some other MPC8272 device
ever, so "fsl,mpc8272-whatever" will never be a nice name to
use for any other device; OTOH, it's likely that Freescale will
create some other device called "SEC" (there are only so many
TLAs, after all), so "fsl,sec-n.m" isn't as future-proof.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 19/60] microblaze_v4: checksum support

2008-06-28 Thread Segher Boessenkool

+static inline unsigned int
+csum_tcpudp_nofold(unsigned long saddr, unsigned long daddr, unsigned 
short len,

+   unsigned short proto, unsigned int sum)
+{
+   __asm__("add %0, %4, %1\n\t"
+   "addc %0, %4, %2\n\t"
+   "addc %0, %4, %3\n\t"
+   "addc %0, %4, r0\n\t"
+   : "=d" (sum)
+   : "d" (saddr), "d" (daddr), "d" (len + proto),
+   "0"(sum));


"sum" should use an earlyclobber, i.e.  "=&d"(sum)  , since some
inputs are used after %0 is first written to.

Also, you can use "+" instead of "=" to say the argument is both
input and output, and get rid of %4, if you like.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: FW: [PATCH] powerpc: Xilinx: adding virtex5 powerpc 440 support

2008-06-28 Thread Grant Likely
Hi John.

Oops, you had also posted this patch to the list later, so I'm also
forwarding my comments to the list.

Cheers,
g.

On Sat, Jun 28, 2008 at 3:56 PM, Grant Likely <[EMAIL PROTECTED]> wrote:
> Sorry for the late reply on this one, I had gotten rather busy.
>
> On Wed, Jun 18, 2008 at 03:09:39PM -0600, John Linn wrote:
>> 1.I'm not sure why we need to disable the interrupts in the
>> bootstrap loader?
>
> You don't.  That's old zImage.raw stuff that you don't need.
>
>> 2.I see some SecetLab copyright in new files that might be just a
>> cut/paste type error?
>
> If it is mostly based on my code, then it is appropriate to preserve my
> copyright and add Xilinx's copyright above it.  If it is really heavily
> modified, then the Secret lab copyright can be dropped.
>
>> 3.I don't see the cputable.c up to date with the 440?
>
>> Thanks,
>> John
>>
>> -Original Message-
>> From: John Linn [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, June 18, 2008 2:58 PM
>> Cc: John Linn
>> Subject: [PATCH] powerpc: Xilinx: adding virtex5 powerpc 440 support
>>
>>
>>
>> The following files add support for Virtex5 with Powerpc 440.
>>
>>
>>
>> Device trees are currently handled differently than other embedded
>>
>> systems as there may not be a boot loader such that the device
>>
>> tree is compiled into the kernel or pulled from a BRAM.
>>
>>
>>
>> The UART 16550 has extra initialization in the bootstrap loader
>>
>> since a boot loader is not used many times.
>>
>
> Your mailer seems to have damaged the patch by wrapping lines and
> inserting extra blank lines.  You'll need to resend.  I've removed
> them below so I could make comments.
>
>>
>> Signed-off-by: John Linn <[EMAIL PROTECTED]>
>> ---
>>  arch/powerpc/Kconfig |   75 +++
>>  arch/powerpc/boot/Makefile   |   24 +-
>>  arch/powerpc/boot/dts/ml507.dts  |  254 
>>  arch/powerpc/boot/io.h   |7 +
>>  arch/powerpc/boot/virtex.c   |  246 
>>  arch/powerpc/configs/44x/ml507_defconfig | 1010 
>> ++
>>  arch/powerpc/platforms/44x/Kconfig   |   62 ++
>>  arch/powerpc/platforms/44x/Makefile  |1 +
>>  arch/powerpc/platforms/44x/virtex.c  |   58 ++
>>  arch/powerpc/platforms/Kconfig   |7 +
>>  10 files changed, 1739 insertions(+), 5 deletions(-)
>>  create mode 100644 arch/powerpc/boot/dts/ml507.dts
>>  create mode 100644 arch/powerpc/boot/virtex.c
>>  create mode 100644 arch/powerpc/configs/44x/ml507_defconfig
>>  create mode 100644 arch/powerpc/platforms/44x/virtex.c
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 3934e26..94adfe1 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -483,6 +483,81 @@ config SECCOMP
>>
>> If unsure, say Y. Only embedded should say N here.
>>
>> +config WANT_DEVICE_TREE
>> + bool
>> + default n
>
> This shouldn't be here.
>
>> +
>> +config BUILD_RAW_IMAGE
>> + bool "Build firmware-independent image"
>> + select WANT_DEVICE_TREE
>> + help
>> +   If this is enabled, a firmware independent "raw" image will be
>> +   built, as zImage.raw.  This requires a completely filled-in
>> +   device tree, with the following labels:
>> +
>> +   mem_size_cells: on /#address-cells
>> +   memsize: on the size portion of /memory/reg
>> +   timebase: on the boot CPU's timebase property
>
> Obsolete stuff; replaced with simpleImage
>
>> +config DEVICE_TREE
>> + string "Static device tree source file"
>> + depends on WANT_DEVICE_TREE
>> + help
>> +   This specifies the device tree source (.dts) file to be
>> +   compiled and included when building the bootwrapper.  If a
>> +   relative filename is given, then it will be relative to
>> +   arch/powerpc/boot/dts.  If you are not using the bootwrapper,
>> +   or do not need to build a dts into the bootwrapper, this
>> +   field is ignored.
>> +
>> +   For example, this is required when building a cuImage target
>> +   for an older U-Boot, which cannot pass a device tree itself.
>> +   Such a kernel will not work with a newer U-Boot that tries to
>> +   pass a device tree (unless you tell it not to).  If your U-Boot
>> +   does not mention a device tree in "help bootm", then use the
>> +   cuImage target and specify a device tree here.  Otherwise, use
>> +   the uImage target and leave this field blank.
>
> Obsolete
>
>> +config COMPRESSED_DEVICE_TREE
>> + bool "Use compressed device tree"
>> + depends on XILINX_VIRTEX
>> + depends on WANT_DEVICE_TREE
>> + help
>> +   In Xilinx FPGAs, the hardware can change quite dramatically
>> while
>> +   still running the same kernel.  In this case and other similar
>> +   ones, it is preferable to associate the device tree with a
>> +   particular build of the hardware design.  This configuration
>> +   option assumes tha

Re: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.

2008-06-28 Thread Grant Likely
On Fri, Jun 6, 2008 at 10:16 AM, Stephen Neuendorffer
<[EMAIL PROTECTED]> wrote:
>
> legacy_serial identifies a valid ns16550 on a simple-bus, but the
> legacy_serial driver doesn't understand the shift and offset flags
> necessary to get it to work, which results in no console.
>
> I think the easiest solution is to change the Kconfig so that
> PPC_UDBG_16550 is only selected based on !XILINX_VIRTEX.  I've done this
> in my tree, but I've been swamped with other things at the moment, so I
> haven't verified it.

This is an easy solution, but it is not a good one.  Doing so would
break UDBG on other 405 boards when building multiplatform kernels.
It would be better to teach legacy serial about the shift and offset.
Alternately, add code to add_legacy_soc_port() to skip it if the
shift/offset properties are present.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Fix wrong 'no interrupt' handling in of_i2c

2008-06-28 Thread Grant Likely
On Sat, Jun 28, 2008 at 12:31 PM, Wolfram Sang <[EMAIL PROTECTED]> wrote:
> If an I2C device node does not specify an interrupt, the .irq member of the
> board_info struct was set to -1. This caused crashes on following
> irq_dispose_mappings. Leave it NO_IRQ as returned from irq_of_parse_and_map.
> (Suggesting -1 as 'i2c-no-irq' used to be a bug in linux/i2c.h.)
>
> Signed-off-by: Wolfram Sang <[EMAIL PROTECTED]>

Acked-by: Grant Likely <[EMAIL PROTECTED]>

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] Fix wrong 'no interrupt' handling in of_i2c

2008-06-28 Thread Wolfram Sang
If an I2C device node does not specify an interrupt, the .irq member of the
board_info struct was set to -1. This caused crashes on following
irq_dispose_mappings. Leave it NO_IRQ as returned from irq_of_parse_and_map.
(Suggesting -1 as 'i2c-no-irq' used to be a bug in linux/i2c.h.)

Signed-off-by: Wolfram Sang <[EMAIL PROTECTED]>
---

 drivers/of/of_i2c.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..500cb1e 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -90,8 +90,6 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
}
 
info.irq = irq_of_parse_and_map(node, 0);
-   if (info.irq == NO_IRQ)
-   info.irq = -1;
 
if (of_find_i2c_driver(node, &info) < 0) {
irq_dispose_mapping(info.irq);

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings

2008-06-28 Thread Bart Van Assche
On Sat, Jun 28, 2008 at 5:07 PM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Jun 28, 2008, at 1:51 AM, Bart Van Assche wrote:
>
>> When compiling kernel modules for ppc that include , gcc
>> prints a warning message every time it encounters a function declaration
>> where
>> the inline keyword appears after the return type. The patch below makes
>> sure
>> that the order of the inline keyword and the return type is as gcc expects
>> it.
>> Additionally, the __inline__ keyword is replaced by inline, as checkpatch
>> expects.
>>
>> Signed-off-by: Bart Van Assche <[EMAIL PROTECTED]>
>
> what version of gcc and what config are you building for?

The gcc details are as follows (openSUSE 10.3 PPC running on a PS3):

$ gcc -v
Using built-in specs.
Target: powerpc64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.2.1 --enable-ssp
--disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=default32 --enable-secureplt
--with-long-double-128 --host=powerpc64-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)

Bart.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings

2008-06-28 Thread Kumar Gala


On Jun 28, 2008, at 1:51 AM, Bart Van Assche wrote:

When compiling kernel modules for ppc that include spinlock.h>, gcc
prints a warning message every time it encounters a function  
declaration where
the inline keyword appears after the return type. The patch below  
makes sure
that the order of the inline keyword and the return type is as gcc  
expects it.
Additionally, the __inline__ keyword is replaced by inline, as  
checkpatch

expects.

Signed-off-by: Bart Van Assche <[EMAIL PROTECTED]>


what version of gcc and what config are you building for?

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 01/12] pata_mpc52xx: use linux/of_platform.h instead of asm

2008-06-28 Thread Stephen Rothwell
On Fri, 27 Jun 2008 22:31:54 -0700 "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 26, 2008 at 11:37 PM, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > Stephen Rothwell wrote:
> >>
> >> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
> >> ---
> >>  drivers/ata/pata_mpc52xx.c |2 +-
> >
> > ACK.  send it via an arch tree
> 
> I'll pick it up.

Thanks, Grant.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpzgvlBUPM7R.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings

2008-06-28 Thread Bart Van Assche
When compiling kernel modules for ppc that include , gcc
prints a warning message every time it encounters a function declaration where
the inline keyword appears after the return type. The patch below makes sure
that the order of the inline keyword and the return type is as gcc expects it.
Additionally, the __inline__ keyword is replaced by inline, as checkpatch
expects.

Signed-off-by: Bart Van Assche <[EMAIL PROTECTED]>

diff -uprN orig/linux-2.6.25.9/include/asm-powerpc/spinlock.h 
linux-2.6.25.9/include/asm-powerpc/spinlock.h
--- orig/linux-2.6.25.9/include/asm-powerpc/spinlock.h  2008-06-24 
23:09:06.0 +0200
+++ linux-2.6.25.9/include/asm-powerpc/spinlock.h   2008-06-28 
08:34:52.0 +0200
@@ -53,7 +53,7 @@
  * This returns the old value in the lock, so we succeeded
  * in getting the lock if the return value is 0.
  */
-static __inline__ unsigned long __spin_trylock(raw_spinlock_t *lock)
+static inline unsigned long __spin_trylock(raw_spinlock_t *lock)
 {
unsigned long tmp, token;
 
@@ -72,7 +72,7 @@ static __inline__ unsigned long __spin_t
return tmp;
 }
 
-static int __inline__ __raw_spin_trylock(raw_spinlock_t *lock)
+static inline int __raw_spin_trylock(raw_spinlock_t *lock)
 {
CLEAR_IO_SYNC;
return __spin_trylock(lock) == 0;
@@ -103,7 +103,7 @@ extern void __rw_yield(raw_rwlock_t *loc
 #define SHARED_PROCESSOR   0
 #endif
 
-static void __inline__ __raw_spin_lock(raw_spinlock_t *lock)
+static inline void __raw_spin_lock(raw_spinlock_t *lock)
 {
CLEAR_IO_SYNC;
while (1) {
@@ -118,7 +118,8 @@ static void __inline__ __raw_spin_lock(r
}
 }
 
-static void __inline__ __raw_spin_lock_flags(raw_spinlock_t *lock, unsigned 
long flags)
+static inline
+void __raw_spin_lock_flags(raw_spinlock_t *lock, unsigned long flags)
 {
unsigned long flags_dis;
 
@@ -138,7 +139,7 @@ static void __inline__ __raw_spin_lock_f
}
 }
 
-static __inline__ void __raw_spin_unlock(raw_spinlock_t *lock)
+static inline void __raw_spin_unlock(raw_spinlock_t *lock)
 {
SYNC_IO;
__asm__ __volatile__("# __raw_spin_unlock\n\t"
@@ -179,7 +180,7 @@ extern void __raw_spin_unlock_wait(raw_s
  * This returns the old value in the lock + 1,
  * so we got a read lock if the return value is > 0.
  */
-static long __inline__ __read_trylock(raw_rwlock_t *rw)
+static inline long __read_trylock(raw_rwlock_t *rw)
 {
long tmp;
 
@@ -203,7 +204,7 @@ static long __inline__ __read_trylock(ra
  * This returns the old value in the lock,
  * so we got the write lock if the return value is 0.
  */
-static __inline__ long __write_trylock(raw_rwlock_t *rw)
+static inline long __write_trylock(raw_rwlock_t *rw)
 {
long tmp, token;
 
@@ -223,7 +224,7 @@ static __inline__ long __write_trylock(r
return tmp;
 }
 
-static void __inline__ __raw_read_lock(raw_rwlock_t *rw)
+static inline void __raw_read_lock(raw_rwlock_t *rw)
 {
while (1) {
if (likely(__read_trylock(rw) > 0))
@@ -237,7 +238,7 @@ static void __inline__ __raw_read_lock(r
}
 }
 
-static void __inline__ __raw_write_lock(raw_rwlock_t *rw)
+static inline void __raw_write_lock(raw_rwlock_t *rw)
 {
while (1) {
if (likely(__write_trylock(rw) == 0))
@@ -251,17 +252,17 @@ static void __inline__ __raw_write_lock(
}
 }
 
-static int __inline__ __raw_read_trylock(raw_rwlock_t *rw)
+static inline int __raw_read_trylock(raw_rwlock_t *rw)
 {
return __read_trylock(rw) > 0;
 }
 
-static int __inline__ __raw_write_trylock(raw_rwlock_t *rw)
+static inline int __raw_write_trylock(raw_rwlock_t *rw)
 {
return __write_trylock(rw) == 0;
 }
 
-static void __inline__ __raw_read_unlock(raw_rwlock_t *rw)
+static inline void __raw_read_unlock(raw_rwlock_t *rw)
 {
long tmp;
 
@@ -278,7 +279,7 @@ static void __inline__ __raw_read_unlock
: "cr0", "memory");
 }
 
-static __inline__ void __raw_write_unlock(raw_rwlock_t *rw)
+static inline void __raw_write_unlock(raw_rwlock_t *rw)
 {
__asm__ __volatile__("# write_unlock\n\t"
LWSYNC_ON_SMP: : :"memory");
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev