* RE: [PATCH 1/5 v3] Add the explanation and a sample of RapidIO OF node to the document of booting-without-of.txt file.
From: Zhang Wei-r63237 @ 2007-07-27 9:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <98CA70A1-9888-4508-A0E9-0EB28C14945F@kernel.crashing.org>
Hi, Kumar,=20
> + RapidIO is a definition of a system interconnect. This node add
> > + the support for RapidIO processor in kernel. The node name is
> > + suggested to be 'rapidio'.
> > +
> > + Required properties:
> > +
> > + - compatible : Using "fsl,rapidio-delta" for Freescale PowerPC
> > + RapidIO controller.
> > + - #address-cells : Address representation for=20
> "rapidio" devices.
> > + This field represents the number of cells needed to represent
> > + the RapidIO address of the registers.
>=20
> Can you explain this a little further. I'm a bit confused by =20
> 'RapidIO address of the registers'.
>=20
I want to present "This field represents the number of cells [needed to
represent the RapidIO address] of the registers."
Maybe I should remove 'of the registers' to be more clear.
Thanks!
-zw
^ permalink raw reply
* RE: [PATCH 4/5 v3] Add RapidIO support to powerpc architecture.
From: Zhang Wei-r63237 @ 2007-07-27 9:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <FFA9FE6D-81C8-429C-A0CD-FE356CF98C69@kernel.crashing.org>
Hi, Kumar,=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> On Jul 26, 2007, at 3:42 AM, Zhang Wei wrote:
>=20
> > This patch adds the RapidIO support to the powerpc architecture.
> > Some files are moved from ppc. OF-tree and OF-device supports are =20
> > added.
> > New silicons such as MPC8548, MPC8641 with serial RapidIO =20
> > controller are
> > all supported.
> > Memory driver hardware operations are added.
> > Global mport variables are changed to master port private variables.
> > Multi master ports are supported.
> >
> > Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> > ---
> > arch/powerpc/Kconfig | 8 +
> > arch/powerpc/kernel/Makefile | 1 +
> > arch/powerpc/kernel/rio.c | 64 ++
> > arch/powerpc/sysdev/Makefile | 1 +
> > arch/powerpc/sysdev/fsl_rio.c | 1455=20
> ++++++++++++++++++++++++++++++=20
> > +++++++++++
>=20
> how much of this moved from ppc85xx_rio.c?
>From the code size, 2/3 are moved from pcc85xx_rio.c with clean up, 1/3
are new coding.
>=20
> > arch/powerpc/sysdev/fsl_rio.h | 20 +
> > 6 files changed, 1549 insertions(+), 0 deletions(-)
> > create mode 100644 arch/powerpc/kernel/rio.c
> > create mode 100644 arch/powerpc/sysdev/fsl_rio.c
> > create mode 100644 arch/powerpc/sysdev/fsl_rio.h
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 00099ef..45f32f1 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -492,6 +492,14 @@ source "drivers/pci/Kconfig"
> >
> > source "drivers/pcmcia/Kconfig"
> >
> > +config RAPIDIO
> > + bool "RapidIO support" if MPC8540 || MPC8560 || MPC8641=20
> || MPC8548
> > + help
> > + If you say Y here, the kernel will include drivers and
> > + infrastructure code to support RapidIO interconnect devices.
>=20
> why not make this depend on something like HAS_RAPIDIO and let the =20
> boards select HAS_RAPIDIO if they have it
It's more clear, We can know how many and which processors support
RapidIO. :-)
>=20
> > +
> > +source "drivers/rapidio/Kconfig"
> > +
> > source "drivers/pci/hotplug/Kconfig"
> >
> > endmenu
> > diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/=20
> > Makefile
> > index 42c42ec..02d4100 100644
> > --- a/arch/powerpc/kernel/Makefile
> > +++ b/arch/powerpc/kernel/Makefile
> > @@ -70,6 +70,7 @@ pci64-$(CONFIG_PPC64) +=3D=20
> pci_64.o pci_dn.o isa-=20
> > bridge.o
> > pci32-$(CONFIG_PPC32) :=3D pci_32.o
> > obj-$(CONFIG_PCI) +=3D $(pci64-y) $(pci32-y) pci-common.o
> > obj-$(CONFIG_PCI_MSI) +=3D msi.o
> > +obj-$(CONFIG_RAPIDIO) +=3D rio.o
>=20
> should probably live in sysdev/rio.c
This just keep the same position of ppc arch.
Thanks!
-zw
^ permalink raw reply
* Re: [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Kumar Gala @ 2007-07-27 8:54 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070726135655.GA5643@localhost.localdomain>
On Jul 26, 2007, at 8:56 AM, Anton Vorontsov wrote:
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/fsl_soc.c | 76 ++++++++++++++++++++++++++++++
> +++++++++++
> arch/powerpc/sysdev/fsl_soc.h | 3 ++
> 2 files changed, 79 insertions(+), 0 deletions(-)
There should be 2nd patch with updates to documentation for the SPI
device node.
>
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/
> fsl_soc.c
> index 3289fab..0599851 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -1125,3 +1125,79 @@ err:
> arch_initcall(cpm_smc_uart_of_init);
>
> #endif /* CONFIG_8xx */
> +
> +void (*fsl_spi_activate_cs)(u8 cs, u8 polarity) = NULL;
> +EXPORT_SYMBOL(fsl_spi_activate_cs);
> +void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity) = NULL;
> +EXPORT_SYMBOL(fsl_spi_deactivate_cs);
> +
I don't think we should do it this way. We shouldn't arch_initcall()
scan for fsl_spi, but have the board code call a function and pass
some things into it.
> +static int __init fsl_spi_of_init(void)
> +{
> + struct device_node *np;
> + unsigned int i;
> +
> + for (np = NULL, i = 1;
> + (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
> + i++) {
> + int ret = 0;
> + const char *devid, *sysclk, *mode, *max_cs;
> + struct resource res[2];
> + struct platform_device *pdev = NULL;
> + struct fsl_spi_platform_data pdata = {
> + .activate_cs = fsl_spi_activate_cs,
> + .deactivate_cs = fsl_spi_deactivate_cs,
> + };
> +
> + memset(res, 0, sizeof(res));
> +
> + devid = of_get_property(np, "device-id", NULL);
> + sysclk = of_get_property(np, "sysclk", NULL);
> + mode = of_get_property(np, "mode", NULL);
> + max_cs = of_get_property(np, "max-chipselect", NULL);
> + if (!devid || !sysclk || !mode || !max_cs)
> + goto err;
> +
> + pdata.bus_num = *(u32 *)devid;
> + pdata.sysclk = *(u32 *)sysclk;
> + pdata.max_chipselect = *(u32 *)max_cs;
> + if (!strcmp(mode, "qe"))
> + pdata.qe_mode = 1;
> +
> + ret = of_address_to_resource(np, 0, &res[0]);
> + if (ret)
> + goto err;
> +
> + res[1].start = res[2].end = irq_of_parse_and_map(np, 0);
> + if (res[1].start == NO_IRQ)
> + goto err;
> +
> + res[1].name = "mpc83xx_spi";
> + res[1].flags = IORESOURCE_IRQ;;
> +
> + pdev = platform_device_alloc("mpc83xx_spi", i);
> + if (!pdev)
> + goto err;
> +
> + ret = platform_device_add_data(pdev, &pdata, sizeof(pdata));
> + if (ret)
> + goto unreg;
> +
> + ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
> + if (ret)
> + goto unreg;
> +
> + ret = platform_device_register(pdev);
> + if (ret)
> + goto unreg;
> +
> + continue;
> +unreg:
> + platform_device_del(pdev);
> +err:
> + continue;
> + }
> +
> + return 0;
> +}
> +
> +arch_initcall(fsl_spi_of_init);
> diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/
> fsl_soc.h
> index 04e145b..c9de2a2 100644
> --- a/arch/powerpc/sysdev/fsl_soc.h
> +++ b/arch/powerpc/sysdev/fsl_soc.h
> @@ -8,5 +8,8 @@ extern phys_addr_t get_immrbase(void);
> extern u32 get_brgfreq(void);
> extern u32 get_baudrate(void);
>
> +extern void (*fsl_spi_activate_cs)(u8 cs, u8 polarity);
> +extern void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity);
> +
> #endif
> #endif
> --
> 1.5.0.6
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/5 v3] Add the explanation and a sample of RapidIO OF node to the document of booting-without-of.txt file.
From: Kumar Gala @ 2007-07-27 8:51 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11854393733580-git-send-email-wei.zhang@freescale.com>
On Jul 26, 2007, at 3:42 AM, Zhang Wei wrote:
> Add the explanation and a sample of RapidIO OF node to the document
> of booting-without-of.txt file.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 37 +++++++++++++++
> +++++++++++
> 1 files changed, 37 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/
> Documentation/powerpc/booting-without-of.txt
> index 76733a3..d89b805 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1824,6 +1824,43 @@ platforms are moved over to use the
> flattened-device-tree model.
> fsl,has-rstcr;
> };
>
> + l) RapidIO
> +
> + RapidIO is a definition of a system interconnect. This node add
> + the support for RapidIO processor in kernel. The node name is
> + suggested to be 'rapidio'.
> +
> + Required properties:
> +
> + - compatible : Using "fsl,rapidio-delta" for Freescale PowerPC
> + RapidIO controller.
> + - #address-cells : Address representation for "rapidio" devices.
> + This field represents the number of cells needed to represent
> + the RapidIO address of the registers.
Can you explain this a little further. I'm a bit confused by
'RapidIO address of the registers'.
> + See 1) above for more details on defining #address-cells.
> + - reg : Offset and length of the register set for the device
> + - ranges : Should be defined as specified in 1) to describe the
> + translation of addresses for memory mapped RapidIO memory
> + space.
> + - interrupts : binding interrupts for this device node,
> + please follow below orders:
> + <err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
> + msg2_tx_irq msg2_rx_irq ... msgN_tx_irq msgN_rx_irq>.
> +
> + Example:
> +
> + rapidio@c0000 {
> + compatible = "fsl,rapidio-delta";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = <c0000 20000>;
> + ranges = <0 0 c0000000 20000000>;
> + interrupt-parent = <&mpic>;
> + /* err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
> + msg2_tx_irq msg2_rx_irq */
> + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> + };
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
> --
> 1.5.1
^ permalink raw reply
* Re: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
From: Kumar Gala @ 2007-07-27 8:28 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11854393721520-git-send-email-wei.zhang@freescale.com>
On Jul 26, 2007, at 3:42 AM, Zhang Wei wrote:
> These patches are the version 3 patches for RapidIO with dts update
> and some minor fixups.
>
> These patches are used for supporting RapidIO controllers of
> Freescale. I ported them from ppc architecture to powerpc
> architecture and added some new features, such as memory mapped
> driver.
>
> [PATCH 1/5] Add the explanation and sample of RapidIO DTS OF-node
> to the document of booting-without-of.txt file.
> [PATCH 2/5] Add RapidIO OF-node to MPC8641HPCN board dts file.
> [PATCH 3/5] Add the platform device support with RapidIO to
> MPC8641HPCN platform.
> [PATCH 4/5] Add RapidIO support to powerpc architecture.
> [PATCH 5/5] Add the memory management driver to RapidIO.
>
> Please see below descriptions of these patches:
> 1. Add the RapidIO driver of-device support.
> 2. Add the RapidIO driver support to MPC8641HPCN board.
> 3. Port the RapidIO from ppc to powerpc architecture.
Can we do the port from ppc as follows:
- cp arch/ppc/syslib/*85xx*rio to arch/powerpc/syslib/fsl_rio.{c,h}
make everything still build
- rename cleanup the code in fsl_rio.{c,h}
this makes it easier to see what changes actually are to fsl_rio.{c,h}
> 4. Add Memory mapped RapidIO driver.
> 5. Add the support to multi master ports.
> 6. Add a simple bitmap RapidIO space allocator driver.
> 7. Change the RapidIO system size of menuconfig to automatically
> detection.
also you describe 7 items, was expect 7 patches :)
- k
^ permalink raw reply
* Re: [PATCH 4/5 v3] Add RapidIO support to powerpc architecture.
From: Kumar Gala @ 2007-07-27 8:22 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11854393763547-git-send-email-wei.zhang@freescale.com>
On Jul 26, 2007, at 3:42 AM, Zhang Wei wrote:
> This patch adds the RapidIO support to the powerpc architecture.
> Some files are moved from ppc. OF-tree and OF-device supports are
> added.
> New silicons such as MPC8548, MPC8641 with serial RapidIO
> controller are
> all supported.
> Memory driver hardware operations are added.
> Global mport variables are changed to master port private variables.
> Multi master ports are supported.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
> arch/powerpc/Kconfig | 8 +
> arch/powerpc/kernel/Makefile | 1 +
> arch/powerpc/kernel/rio.c | 64 ++
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/fsl_rio.c | 1455 ++++++++++++++++++++++++++++++
> +++++++++++
how much of this moved from ppc85xx_rio.c?
> arch/powerpc/sysdev/fsl_rio.h | 20 +
> 6 files changed, 1549 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/kernel/rio.c
> create mode 100644 arch/powerpc/sysdev/fsl_rio.c
> create mode 100644 arch/powerpc/sysdev/fsl_rio.h
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 00099ef..45f32f1 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -492,6 +492,14 @@ source "drivers/pci/Kconfig"
>
> source "drivers/pcmcia/Kconfig"
>
> +config RAPIDIO
> + bool "RapidIO support" if MPC8540 || MPC8560 || MPC8641 || MPC8548
> + help
> + If you say Y here, the kernel will include drivers and
> + infrastructure code to support RapidIO interconnect devices.
why not make this depend on something like HAS_RAPIDIO and let the
boards select HAS_RAPIDIO if they have it
> +
> +source "drivers/rapidio/Kconfig"
> +
> source "drivers/pci/hotplug/Kconfig"
>
> endmenu
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/
> Makefile
> index 42c42ec..02d4100 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -70,6 +70,7 @@ pci64-$(CONFIG_PPC64) += pci_64.o pci_dn.o isa-
> bridge.o
> pci32-$(CONFIG_PPC32) := pci_32.o
> obj-$(CONFIG_PCI) += $(pci64-y) $(pci32-y) pci-common.o
> obj-$(CONFIG_PCI_MSI) += msi.o
> +obj-$(CONFIG_RAPIDIO) += rio.o
should probably live in sysdev/rio.c
> kexec-$(CONFIG_PPC64) := machine_kexec_64.o
> kexec-$(CONFIG_PPC32) := machine_kexec_32.o
> obj-$(CONFIG_KEXEC) += machine_kexec.o crash.o $(kexec-y)
> diff --git a/arch/powerpc/kernel/rio.c b/arch/powerpc/kernel/rio.c
> new file mode 100644
> index 0000000..8d41e93
> --- /dev/null
> +++ b/arch/powerpc/kernel/rio.c
> @@ -0,0 +1,64 @@
> +/*
> + * RapidIO PowerPC support
> + *
> + * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights
> reserved.
> + * Zhang Wei <wei.zhang@freescale.com>, Jun 2007
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + *
> + * New RapidIO peer-to-peer network initialize with of-device
> supoort.
> + *
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/rio.h>
> +
> +#include <asm/rio.h>
> +#include <asm/of_device.h>
> +#include <asm/of_platform.h>
> +
> +#include <../sysdev/fsl_rio.h>
> +
> +
> +/* The probe function for RapidIO peer-to-peer network.
> + */
> +static int __devinit of_rio_rpn_probe(struct of_device *dev,
> + const struct of_device_id *match)
> +{
> + int rc;
> + printk(KERN_INFO "Setting up RapidIO peer-to-peer network %s\n",
> + dev->node->full_name);
> +
> + rc = fsl_rio_setup(dev);
> + if (rc)
> + goto out;
> +
> + /* Enumerate all registered ports */
> + rc = rio_init_mports();
> +out:
> + return rc;
> +};
> +
> +static struct of_device_id of_rio_rpn_ids[] = {
> + {
> + .compatible = "fsl,rapidio-delta",
> + },
> + {},
> +};
> +
> +static struct of_platform_driver of_rio_rpn_driver = {
> + .name = "of-rio",
> + .match_table = of_rio_rpn_ids,
> + .probe = of_rio_rpn_probe,
> +};
> +
> +static __init int of_rio_rpn_init(void)
> +{
> + return of_register_platform_driver(&of_rio_rpn_driver);
> +}
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Kumar Gala @ 2007-07-27 8:14 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070726135738.GB5643@localhost.localdomain>
On Jul 26, 2007, at 8:57 AM, Anton Vorontsov wrote:
> mmc_spi already tested to work. When it will hit mainline
> the only change that would be needed is replacing "spidev"
> by "mmc_spi", and adding trivial platform data to mmc_spi
> driver.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 33 ++++++++++++++++++
> ++-
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 46 ++++++++++++++++++
> +++++++++++
> 2 files changed, 78 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/
> boot/dts/mpc832x_rdb.dts
> index 7c4beff..5dcbdd3 100644
> --- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> @@ -183,6 +183,21 @@
> 1 c 1 0 1 0 /* TX_EN */
> 1 d 2 0 1 0>; /* CRS */
> };
> + spi1pio:spi_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 3 0 3 0 1 0 /* SPI1 MOSI, I/O */
> + 3 1 3 0 1 0 /* SPI1 MISO, I/O */
> + 3 2 3 0 1 0 /* SPI1 CLK, I/O */
> + 3 3 2 0 1 0>; /* SPI1 SEL, I */
> + };
> + mmc1pio:mmc_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 3 d 1 0 0 0 /* !SD_CS */
> + 3 e 2 0 0 0 /* SD_INSERT */
> + 3 f 2 0 0 0>; /* SD_PROTECT */
> + };
> };
> };
>
> @@ -207,20 +222,36 @@
>
> spi@4c0 {
> device_type = "spi";
> + device-id = <1>;
Can we just use the reg value for bus_num in the kernel.
> compatible = "fsl_spi";
> reg = <4c0 40>;
> interrupts = <2>;
> interrupt-parent = <&qeic>;
> - mode = "cpu";
> + mode = "qe";
> + sysclk = <5f5e100>; /* 100000000 Hz */
we don't need this in the spi node, its just the system clock
frequency which we can get other ways.
> + max-chipselect = <1>;
I'm not sure how I feel about this in here, I'm thinking it should go.
> + pio-handle = <&spi1pio>;
> +
> + mmc@01 {
> + device_type = "mmc";
> + compatible = "mmc-spi";
> + device-id = <1>;
> + max-speed-hz = <bebc20>; /* 12500000 Hz */
> + chip-select = <0>;
> + pio-handle = <&mmc1pio>;
> + };
we should do this in board code and not the device tree.
> };
>
> spi@500 {
> device_type = "spi";
> + device-id = <2>;
> compatible = "fsl_spi";
> reg = <500 40>;
> interrupts = <1>;
> interrupt-parent = <&qeic>;
> mode = "cpu";
> + sysclk = <5f5e100>; /* 100000000 Hz */
> + max_chipselect = <1>;
> };
>
> ucc@3000 {
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/
> powerpc/platforms/83xx/mpc832x_rdb.c
> index b2b28a4..c5463c7 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> @@ -15,6 +15,7 @@
> */
>
> #include <linux/pci.h>
> +#include <linux/spi/spi.h>
>
> #include <asm/of_platform.h>
> #include <asm/time.h>
> @@ -24,6 +25,7 @@
> #include <asm/qe_ic.h>
>
> #include "mpc83xx.h"
> +#include "../../sysdev/fsl_soc.h"
>
> #undef DEBUG
> #ifdef DEBUG
> @@ -32,6 +34,43 @@
> #define DBG(fmt...)
> #endif
>
> +extern int par_io_data_set(u8 port, u8 pin, u8 val);
> +
> +static void mpc83xx_spi_activate_cs(u8 cs, u8 polarity)
> +{
> + pr_debug("%s %d %d\n", __func__, cs, polarity);
> + par_io_data_set(3, 13, polarity);
> +}
> +
> +static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
> +{
> + pr_debug("%s %d %d\n", __func__, cs, polarity);
> + par_io_data_set(3, 13, !polarity);
> +}
> +
> +static int __init mpc83xx_spi_devices_init(void)
> +{
> + struct spi_board_info spi_bi = {
> + .bus_num = 1,
> + /*
> + * XXX: This is spidev (spi in userspace) stub, should
> + * be replaced by "mmc_spi" when mmc_spi will hit mainline.
> + */
> + .modalias = "spidev",
> + };
> + struct device_node *np = NULL;
> +
> + np = of_find_compatible_node(np, "mmc", "mmc-spi");
> + if (!np)
> + return 0;
> +
> + spi_bi.max_speed_hz = *((u32 *)of_get_property(np, "max-speed-
> hz", NULL));
> + spi_bi.chip_select = *((u32 *)of_get_property(np, "chip-select",
> NULL));
> +
> + return spi_register_board_info(&spi_bi, 1);
> +}
> +device_initcall(mpc83xx_spi_devices_init);
> +
> /*
> **********************************************************************
> **
> *
> * Setup the architecture
> @@ -62,8 +101,15 @@ static void __init mpc832x_rdb_setup_arch(void)
>
> for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
> par_io_of_config(np);
> + for (np = NULL; (np = of_find_node_by_name(np, "spi")) != NULL;)
> + par_io_of_config(np);
> + for (np = NULL; (np = of_find_node_by_name(np, "mmc")) != NULL;)
> + par_io_of_config(np);
> }
> #endif /* CONFIG_QUICC_ENGINE */
> +
> + fsl_spi_activate_cs = mpc83xx_spi_activate_cs;
> + fsl_spi_deactivate_cs = mpc83xx_spi_deactivate_cs;
> }
>
> static struct of_device_id mpc832x_ids[] = {
> --
> 1.5.0.6
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 4/5 v3] Add RapidIO support to powerpc architecture.
From: Stephen Rothwell @ 2007-07-27 8:12 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11854393763547-git-send-email-wei.zhang@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Thu, 26 Jul 2007 16:42:51 +0800 Zhang Wei <wei.zhang@freescale.com> wrote:
>
> +
> +#include <../sysdev/fsl_rio.h>
This can just be <sysdev/fsl_rio.h> if it is only built on 32bit.
--
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: [PATCH 3/5 v3] Add the platform device support with RapidIO to MPC8641HPCN platform.
From: Stephen Rothwell @ 2007-07-27 7:54 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11854393753986-git-send-email-wei.zhang@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
On Thu, 26 Jul 2007 16:42:50 +0800 Zhang Wei <wei.zhang@freescale.com> wrote:
>
> +#include <asm/of_device.h>
> +#include <asm/of_platform.h>
These should now be <linux/of_device.h> and <linux/of_platform.h>
--
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: [RFC][PATCH] MPC832x_RDB: update dts to use spi, registermmc_spi stub
From: Kumar Gala @ 2007-07-27 7:55 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <02bd01c7cfbc$cf213610$02ac10ac@Jocke>
On Jul 26, 2007, at 2:40 PM, Joakim Tjernlund wrote:
>
>
>> -----Original Message-----
>> From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]
>> Sent: den 26 juli 2007 17:48
>> To: Joakim Tjernlund
>> Cc: linuxppc-dev@ozlabs.org
>> Subject: Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi,
>> registermmc_spi stub
>>
>> On Thu, Jul 26, 2007 at 05:36:06PM +0200, Joakim Tjernlund wrote:
>> [...]
>>>> spi@4c0 {
>>>> device_type = "spi";
>>>> + device-id = <1>;
>>>> compatible = "fsl_spi";
>>>> reg = <4c0 40>;
>>>> interrupts = <2>;
>>>> interrupt-parent = <&qeic>;
>>>> - mode = "cpu";
>>>> + mode = "qe";
>>>
>>> The driver is still using "cpu" mode. It just happens that
>> the cpu mode for QE
>>> enabled CPUs isn't 100% compatible with the defacto cpu
>> mode used by other CPU:s.
>>
>> Yup, indeed.
>>
>>> So mode should probably be "cpu_qe" or, even better, if the
>> drver could
>>
>> That's easy to change, thanks.
>>
>>> autodetect that it is running on a QE enabled CPU and
>> adjust accordinly.
>>> Maybe the Freescale guys have some ideas how to do that.
>>
>> Ok. Well, for now could we use machine_is() for kind of autodetect?
>> Or it's better leave it as is, and just rename mode to cpu_qe?
>
> Unless the DTS guys thinks otherwise, just rename to "cpu_qe".
> "qe" would then be reserved for true QE mode.
Agreed, we need to update booting-without-of.txt.
- k
^ permalink raw reply
* Re: [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Kumar Gala @ 2007-07-27 7:52 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070726210507.18829b9a@vitb.ru.mvista.com>
On Jul 26, 2007, at 12:05 PM, Vitaly Bordug wrote:
> On Thu, 26 Jul 2007 11:45:08 -0500
> Scott Wood <scottwood@freescale.com> wrote:
>
>> On Thu, Jul 26, 2007 at 05:56:55PM +0400, Anton Vorontsov wrote:
>>> +void (*fsl_spi_activate_cs)(u8 cs, u8 polarity) = NULL;
>>> +EXPORT_SYMBOL(fsl_spi_activate_cs);
>>> +void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity) = NULL;
>>> +EXPORT_SYMBOL(fsl_spi_deactivate_cs);
>>
>> What are these for? It looks like you're using them to set pins,
>> but that should be done in the firmware (and if the firmware
>> sucks, then
>> do it in the platform code at bootup).
>>
> That is not exactly the point.
> I won't respond for Anton, but we already had such hooks justified
> in SPI case iirc.
No they are used for runtime chip select handling. The SPI
controller is able to handle multiple devices, however the chipselect
is not specified by SPI and thus it left to board code.
>>> +static int __init fsl_spi_of_init(void)
>>> +{
>>> + struct device_node *np;
>>> + unsigned int i;
>>> +
>>> + for (np = NULL, i = 1;
>>> + (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
>>> + i++) {
>>
>> s/fsl_spi/fsl,mpc8323-spi/, please.
>>
>> Why not make the fsl spi driver an of_platform device?
>>
> Because this particular thing is not ppc-only from what I recall.
The device node name already existed before this patch.
- k
^ permalink raw reply
* Re: creation of jffs2 rootfile system..
From: Florian A. Voegel @ 2007-07-27 8:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11823840.post@talk.nabble.com>
Hi Nethra,
what does your inittab and your startup files look like? It looks like
- your inittab does not start a getty but rather a shell, thus no login
- your /proc isn't mounted, and it's needed for ps to work properly
Greets,
Florian Voegel
Carangul.Tech
On Thu, 26 Jul 2007 23:41:32 -0700 (PDT)
Nethra <nethra_gmit@yahoo.co.in> wrote:
>
> when boot the board with jffs2 rootfile system i m getting output like this,
>
> TCP: Hash tables configured (established 4096 bind 8192)
> IPv4 over IPv4 tunneling driver
> NET: Registered protocol family 1
> NET: Registered protocol family 10
> IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> Disabled Privacy Extensions on device c02527a0(lo)
> IP-Config: Incomplete network configuration information.
> Empty flash at 0x0000ffa0 ends at 0x00010000
> Empty flash at 0x0002ffec ends at 0x00030000
> Empty flash at 0x0004ffe8 ends at 0x00050000
> Empty flash at 0x0006ffc8 ends at 0x00070000
> Empty flash at 0x0008fffc ends at 0x00090000
> Empty flash at 0x000afffc ends at 0x000b0000
> Empty flash at 0x000cfffc ends at 0x000d0000
> Empty flash at 0x000efffc ends at 0x000f0000
> Empty flash at 0x0010fffc ends at 0x00110000
> Empty flash at 0x0012fffc ends at 0x00130000
> Empty flash at 0x0014fffc ends at 0x00150000
> Empty flash at 0x0016fffc ends at 0x00170000
> Empty flash at 0x0018fffc ends at 0x00190000
> Empty flash at 0x001cfffc ends at 0x001d0000
> Empty flash at 0x001efffc ends at 0x001f0000
> Empty flash at 0x0020fffc ends at 0x00210000
> Empty flash at 0x0022fffc ends at 0x00230000
> Empty flash at 0x0024fffc ends at 0x00250000
> Empty flash at 0x0026fffc ends at 0x00270000
> Empty flash at 0x002afffc ends at 0x002b0000
> Empty flash at 0x002cfffc ends at 0x002d0000
> VFS: Mounted root (jffs2 filesystem).
> Freeing unused kernel memory: 108k init
>
> Please press Enter to activate this console.
> / #
> / #
> / #
>
> login prompt itself is not coming and
>
> ps command is not working....
> # ps
> PID Uid VmSize Stat Command
> #
>
> what is the problem..?
>
> waiting for early response,
> Nethra
>
> --
> View this message in context: http://www.nabble.com/creation-of-jffs2-rootfile-system..-tf4155759.html#a11823840
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Decermenter overflow interrupt atfer the init.d launch.
From: Benjamin Herrenschmidt @ 2007-07-27 7:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <D4037DB6-8832-4057-A9FF-BAD32592E6C9@kernel.crashing.org>
On Fri, 2007-07-27 at 01:46 -0500, Kumar Gala wrote:
> On Jul 27, 2007, at 1:36 AM, Nicolas Mederle wrote:
>
> > Hi,
> >
> > I want to know how the kernel switch the task. Because my
> > kernel
> > start very well, and it launch the init.d. With the log, i can see
> > that
> > the kernel launch the getty task. But after, there is a decrementer
> > overflow interrupt ( vector at adress 900 ). Is it the task
> > switch? Or
> > is it an error in the decrementer init.
>
> This should be a task switch. The decrementer is used to handle the
> periodic interrupt to switch processes.
I would have expected quite of few of these actually before you get
there :-)
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Benjamin Herrenschmidt @ 2007-07-27 7:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Alan Curry, linux-kernel
In-Reply-To: <20070726212241.032e9755.akpm@linux-foundation.org>
On Thu, 2007-07-26 at 21:22 -0700, Andrew Morton wrote:
>
> > Merged a fixed version:
> >
> > f5d834fc34e61f1a40435981062000e5d2b2baa8
> >
> > (In linus tree as of now)
>
> I hope so. Alan's patch looks rather different from what you have
> now:
> fall back to of_find_node_by_name() if of_find_node_by_type() failed.
Which is just waht that commit does :-)
Ben.
^ permalink raw reply
* Re: ping command
From: Nethra @ 2007-07-27 6:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1185458965.6839.8.camel@saruman.qstreams.net>
root@cashel:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.32.0 0.0.0.0 255.255.248.0 U 0 0 0 eth1
0.0.0.0 192.168.32.47 0.0.0.0 UG 0 0 0 eth1
0.0.0.0 192.168.178.47 0.0.0.0 UG 0 0 0 eth0
root@cashel:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:72:FE:A9:02
inet addr:192.168.178.89 Bcast:192.168.178.255
Mask:255.255.255.0
inet6 addr: fe80::213:72ff:fefe:a902/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15665 errors:0 dropped:0 overruns:0 frame:0
TX packets:9285 errors:0 dropped:0 overruns:0 carrier:9019
collisions:0 txqueuelen:1000
RX bytes:12957285 (12.3 MiB) TX bytes:2720267 (2.5 MiB)
Base address:0x8400
eth1 Link encap:Ethernet HWaddr 00:13:72:7E:A9:02
inet addr:192.168.33.135 Bcast:192.168.33.255 Mask:255.255.248.0
inet6 addr: fe80::213:72ff:fe7e:a902/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:634 errors:0 dropped:0 overruns:0 frame:0
TX packets:84 errors:0 dropped:0 overruns:0 carrier:82
collisions:0 txqueuelen:1000
RX bytes:103558 (101.1 KiB) TX bytes:12832 (12.5 KiB)
Base address:0x8500
lo Link encap:Local Loopback
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
root@cashel:~#
On Wed, 2007-07-25 at 02:29 -0700, Nethra wrote:
> hi,
>
> I m using custom board same as eval board MPC8272ADS board.
>
> IP assigned for both ethernets are...
>
> ifconfig eth1 192.168.33.135 up
> ifconfig eth1 netmask 255.255.248.0
> route add default gw 192.168.32.47 eth1
>
>
> ifconfig eth0 192.168.178.89 up
> ifconfig eth0netmask 255.255.255.0
> route add default gw 192.168.178.47 eth0
>
> but if i try for ping 192.168.33.135 command pails by the server of 178
> series
> similarly ping 192.168.178.89 command pails by the server of 33 series..
>
> what is the problem..and whre i m going wrong..?
What does your routing table show? (route -n). It wouldn't hurt to
also post the output of ifconfig for both interfaces.
regards,
Ben
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
View this message in context: http://www.nabble.com/ping-command-tf4141032.html#a11823845
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Decermenter overflow interrupt atfer the init.d launch.
From: Kumar Gala @ 2007-07-27 6:46 UTC (permalink / raw)
To: Nicolas Mederle; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <46A9925A.2060508@yahoo.fr>
On Jul 27, 2007, at 1:36 AM, Nicolas Mederle wrote:
> Hi,
>
> I want to know how the kernel switch the task. Because my
> kernel
> start very well, and it launch the init.d. With the log, i can see
> that
> the kernel launch the getty task. But after, there is a decrementer
> overflow interrupt ( vector at adress 900 ). Is it the task
> switch? Or
> is it an error in the decrementer init.
This should be a task switch. The decrementer is used to handle the
periodic interrupt to switch processes.
- k
^ permalink raw reply
* creation of jffs2 rootfile system..
From: Nethra @ 2007-07-27 6:41 UTC (permalink / raw)
To: linuxppc-embedded
when boot the board with jffs2 rootfile system i m getting output like this,
TCP: Hash tables configured (established 4096 bind 8192)
IPv4 over IPv4 tunneling driver
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
Disabled Privacy Extensions on device c02527a0(lo)
IP-Config: Incomplete network configuration information.
Empty flash at 0x0000ffa0 ends at 0x00010000
Empty flash at 0x0002ffec ends at 0x00030000
Empty flash at 0x0004ffe8 ends at 0x00050000
Empty flash at 0x0006ffc8 ends at 0x00070000
Empty flash at 0x0008fffc ends at 0x00090000
Empty flash at 0x000afffc ends at 0x000b0000
Empty flash at 0x000cfffc ends at 0x000d0000
Empty flash at 0x000efffc ends at 0x000f0000
Empty flash at 0x0010fffc ends at 0x00110000
Empty flash at 0x0012fffc ends at 0x00130000
Empty flash at 0x0014fffc ends at 0x00150000
Empty flash at 0x0016fffc ends at 0x00170000
Empty flash at 0x0018fffc ends at 0x00190000
Empty flash at 0x001cfffc ends at 0x001d0000
Empty flash at 0x001efffc ends at 0x001f0000
Empty flash at 0x0020fffc ends at 0x00210000
Empty flash at 0x0022fffc ends at 0x00230000
Empty flash at 0x0024fffc ends at 0x00250000
Empty flash at 0x0026fffc ends at 0x00270000
Empty flash at 0x002afffc ends at 0x002b0000
Empty flash at 0x002cfffc ends at 0x002d0000
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 108k init
Please press Enter to activate this console.
/ #
/ #
/ #
login prompt itself is not coming and
ps command is not working....
# ps
PID Uid VmSize Stat Command
#
what is the problem..?
waiting for early response,
Nethra
--
View this message in context: http://www.nabble.com/creation-of-jffs2-rootfile-system..-tf4155759.html#a11823840
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Decermenter overflow interrupt atfer the init.d launch.
From: Nicolas Mederle @ 2007-07-27 6:36 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
Hi,
I want to know how the kernel switch the task. Because my kernel
start very well, and it launch the init.d. With the log, i can see that
the kernel launch the getty task. But after, there is a decrementer
overflow interrupt ( vector at adress 900 ). Is it the task switch? Or
is it an error in the decrementer init.
--
Cordialement,
MEDERLE Nicolas.
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 0/4] Few spi_mpc83xx.c fixes and improvements
From: Kumar Gala @ 2007-07-27 6:32 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <200707261958.09127.david-b@pacbell.net>
On Jul 26, 2007, at 9:58 PM, David Brownell wrote:
> On Thursday 26 July 2007, Anton Vorontsov wrote:
>> Hi all,
>>
>> These patches based on Linus' tree, as of today.
>
> I don't know mpc83xx ... are there any PPC folk who can see
> any reason not to just merge these patches? They look OK
> to me, but in this case that doesn't mean much. :)
>
> If I don't hear otherwise, I'll forward all four of these
> patches upstream on Monday.
>
> (Anton, thanks for these updates!)
These all look good to me for upstream.
Acked-off-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 1/4] [POWERPC][SPI] spi_mpc83xx.c: should turn off SPI unit while switching any mode.
From: Kumar Gala @ 2007-07-27 6:32 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <20070726131346.GA3417@localhost.localdomain>
On Jul 26, 2007, at 8:13 AM, Anton Vorontsov wrote:
> Documentation clearly states, that mode should not be changed
> till SPMODE_ENABLE bit set. I've seen hangs w/o this patch.
Out of interest what board/part do you see the hang on?
- k
^ permalink raw reply
* Re: [PATCH] xmon consistency clean up
From: Ishizaki Kou @ 2007-07-27 6:11 UTC (permalink / raw)
To: benh, michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1185365630.21877.4.camel@concordia.ozlabs.ibm.com>
Michael Ellerman <michael@ellerman.id.au> wrote:
> On Wed, 2007-07-25 at 16:21 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2007-07-25 at 11:57 +0900, Ishizaki Kou wrote:
> > > This patch cleans up xmon to keep consistency.
> > >
> > > In xmon, we should use console I/O functions that are named the
same
> > > as user space stdio functions. But commit
> > > 4d404edce30f911004850d472e05a31efd751662 broke this consistency.
> > >
> > > Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> > > ---
> > >
> > > Index: linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
> > >
===================================================================
> > > --- linux-powerpc-git.orig/arch/powerpc/xmon/nonstdio.c
> > > +++ linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
> > > @@ -133,7 +133,7 @@ void xmon_printf(const char *format, ...
> > > xmon_write(xmon_outbuf, n);
> > > }
> > >
> > > -void xmon_puts(const char *str)
> > > +void xmon_fputs(const char *str)
> > > {
> > > xmon_write(str, strlen(str));
> >
> > Nah, keep it xmon_puts, since it doesn't take a stream argument and
> > define a "puts" for use by xmon core.
>
> But then it needs to add a newline .. and we've gone around in a
circle
> again. Funny how the trivialest of patches gets the most review.
In my opinion, our goal is providing stdio functions like fputs to
xmon.c. So, xmon_fputs need not be compatible with fputs because
xmon.c doesn't use it directly.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Alan Curry @ 2007-07-27 4:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <20070726212241.032e9755.akpm@linux-foundation.org>
Andrew Morton writes the following:
>> >
>> > Did this get merged, or otherwise fixed? Even though the code in there has
>> > changed quite a bit, it looks to my untrained eye like the fix is still
>> > applicable?
>>
>> Merged a fixed version:
>>
>> f5d834fc34e61f1a40435981062000e5d2b2baa8
>>
>> (In linus tree as of now)
>
>I hope so. Alan's patch looks rather different from what you have now:
>fall back to of_find_node_by_name() if of_find_node_by_type() failed.
>
Looking at it via gitweb, I think the commit mentioned above is actually the
same as what I submitted. The diff context lines are different because there
was a similar patch in between the 2.6.22 release and my patch, which
apparently fixed the same problem on a different type of machine. It looks
like these 2 workarounds will function independently of each other.
The first 8042-detection fix was:
db0dbae9d9680bce69fe1ce775709e60c8ee9c29
And mine is:
f5d834fc34e61f1a40435981062000e5d2b2baa8
--
Alan Curry
pacman@world.std.com
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Andrew Morton @ 2007-07-27 4:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Alan Curry, linux-kernel
In-Reply-To: <1185505222.5495.182.camel@localhost.localdomain>
On Fri, 27 Jul 2007 13:00:21 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2007-07-26 at 18:48 -0700, Andrew Morton wrote:
> > On Wed, 25 Jul 2007 17:12:45 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > On Tue, 2007-07-24 at 21:28 -0400, Alan Curry wrote:
> > > > As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse controller
> > > > on the PegasosPPC. This is because of a feature/bug in the OF device tree:
> > > > the "device_type" attribute is an empty string instead of "8042" as the
> > > > kernel expects. This patch (against 2.6.22.1) adds a secondary detection
> > > > which looks for a device whose *name* is "8042" if there is no device whose
> > > > *type* is "8042".
> > > >
> > > > Signed-off-by: Alan Curry <pacman@world.std.com>
> > >
> > > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > >
> > > Note, if there's a volunteer, we could probably turn that code into a
> > > nice table lookup.
> >
> > Did this get merged, or otherwise fixed? Even though the code in there has
> > changed quite a bit, it looks to my untrained eye like the fix is still
> > applicable?
>
> Merged a fixed version:
>
> f5d834fc34e61f1a40435981062000e5d2b2baa8
>
> (In linus tree as of now)
I hope so. Alan's patch looks rather different from what you have now:
fall back to of_find_node_by_name() if of_find_node_by_type() failed.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add support of platforms without PHY to gianfar driver
From: Kumar Gala @ 2007-07-27 4:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, linuxppc-dev
In-Reply-To: <46A7BEE2.8020504@garzik.org>
On Jul 25, 2007, at 4:21 PM, Jeff Garzik wrote:
> I'll let paulus and linuxppc merge this one (or not)...
That would most likely be me, than paulus. Since this is for a
Freescale PPC SoC.
- k
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 2/3] [SPI] Add new mode: SPI_LOOP
From: Ned Forrester @ 2007-07-27 3:34 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general, Stephen Street, linuxppc-dev
In-Reply-To: <200707262007.07537.david-b@pacbell.net>
David Brownell wrote:
> On Thursday 26 July 2007, Anton Vorontsov wrote:
>> Loopback mode is supported by various controllers, this mode
>> is useful for testing, especially in conjunction with spidev
>> driver.
>
> ISTR that Stephen Street provided a loopback mode for debug
> in his pxa2xx_spi code. And I know you're fight that this
> mode shows up in a lot of hardware.
>
> Comments, anyone? This seems like a fair way to expose this
> mechanism. And I tend to agree that it'd mostly be useful in
> conjunction with "spidev".
Yes, it is in pxa2xx_spi. It is passed in a structure that is attached
to spi_board_info.controller_data. I have used it to great effect to
test data modes in the driver for which I have no external hardware
support: various bits/word, clock frequencies, fifo thresholds, dma
burst sizes, etc.
It works for me if this is moved to struct spi_device.
I don't think I have any code that could be readily turned into a
generic test program.
--
Ned Forrester nforrester@whoi.edu
Oceanographic Systems Lab 508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox