Re: [PATCH] [powerpc] GPIO: Adding new Xilinx driver
On Fri, Oct 24, 2008 at 3:41 PM, Anton Vorontsov <[EMAIL PROTECTED]> wrote: > On Fri, Oct 24, 2008 at 12:59:00PM -0700, John Linn wrote: >> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig >> index 7f2ee27..f6b0da8 100644 >> --- a/drivers/gpio/Kconfig >> +++ b/drivers/gpio/Kconfig >> @@ -65,6 +65,14 @@ config GPIO_SYSFS >> >> # put expanders in the right section, in alphabetical order >> >> +comment "Memory mapped GPIO expanders:" >> + >> +config GPIO_XILINX >> + bool "Xilinx GPIO support" >> + depends on OF > > I persume that the driver wasn't build-tested on SPARC, so I'd recommend > to change the depends to PPC_OF. Plus, the driver should also select > GENERIC_GPIO and ARCH_REQUIRE_GPIOLIB. (Later we'll switch to > ARCH_WANT_OPTIONAL_GPIOLIB for whole PPC.) ARCH_WANT_OPTIONAL_GPIOLIB seems to already be set for all of powerpc (arch/powerpc/Kconfig, line 113). But, since this is a cross-arch driver living in drivers/gpio the dependencies work the other way around. This driver cannot be selected unless GPIOLIB is turned on. 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: [BUG] oops in net_rx_action on 64-bit powerpc
David Miller wrote: From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Fri, 24 Oct 2008 17:39:00 -0600 So...it would appear that the NAPI code is somehow buggy, and 6ba33ac should probably be reverted until the problem is found and fixed. No I think the problem is simple enough that someone should study the ->poll() routine quickly and audit it's return values. Assuming that amd8111e_rx_poll() is the proper routine, there is only one exit point, and it returns "num_rx_pkt". This variable is initialized to zero and increments for each packet sent up the stack. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH] Cell OProfile: Incorrect local array size in activate spu profiling function
On Fri, 2008-10-24 at 11:47 -0700, Carl Love wrote: > The size of the pm_signal_local array should be equal to the > number of SPUs being configured in the call. Currently, the > array is of size 4 (NR_PHYS_CTRS) but being indexed by a for > loop from 0 to 7 (NUM_SPUS_PER_NODE). While you're at it you should change to using ARRAY_SIZE() in the for loop, and use sizeof in the rtas call - that way you'll only have the size in one place. I notice pm_rtas_activate_signals() also allocates a pm_signal_local on the stack and iterates over it. I take it something guarantees that count in that routine will not exceed NR_PHYS_CTRS ? cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] spi: Add PPC4xx SPI driver
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
Changes in v2:
- Now the gpios property is correctly decoded and the
resulting gpio numbers are used as the devices chip
selects.
So we can describe the SPI node like this:
SPI0: [EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
...
/* two GPIOs, representing two chip selects: 0 and 1 */
gpios = <&GPIO0 5 0 &GPIO1 16 0>;
[EMAIL PROTECTED] {
reg = <0>;
...
};
[EMAIL PROTECTED] {
reg = <1>;
...
};
}
Special thanks to Wolfgang Ocker and Anton Vorontsov for their input.
drivers/spi/Kconfig |7 +
drivers/spi/Makefile |1 +
drivers/spi/spi_ppc4xx.c | 583 ++
3 files changed, 591 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/spi_ppc4xx.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b9d0efb..69d5fee 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -155,6 +155,13 @@ config SPI_ORION
help
This enables using the SPI master controller on the Orion chips.
+config SPI_PPC4xx
+ tristate "PPC4xx SPI Controller"
+ depends on 4xx && SPI_MASTER
+ select SPI_BITBANG
+ help
+ This selects a driver for the PPC4xx SPI Controller.
+
config SPI_PXA2XX
tristate "PXA2xx SSP SPI master"
depends on ARCH_PXA && EXPERIMENTAL
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ccf18de..a2e5816 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_SPI_OMAP24XX)+= omap2_mcspi.o
obj-$(CONFIG_SPI_ORION)+= orion_spi.o
obj-$(CONFIG_SPI_MPC52xx_PSC) += mpc52xx_psc_spi.o
obj-$(CONFIG_SPI_MPC83xx) += spi_mpc83xx.o
+obj-$(CONFIG_SPI_PPC4xx) += spi_ppc4xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
diff --git a/drivers/spi/spi_ppc4xx.c b/drivers/spi/spi_ppc4xx.c
new file mode 100644
index 000..979a8c1
--- /dev/null
+++ b/drivers/spi/spi_ppc4xx.c
@@ -0,0 +1,583 @@
+/*
+ * SPI_PPC4XX SPI controller driver.
+ *
+ * Copyright (C) 2007 Gary Jennejohn <[EMAIL PROTECTED]>
+ * Copyright 2008 Stefan Roese <[EMAIL PROTECTED]>, DENX Software Engineering
+ *
+ * Based in part on drivers/spi/spi_s3c24xx.c
+ *
+ * Copyright (c) 2006 Ben Dooks
+ * Copyright (c) 2006 Simtec Electronics
+ * Ben Dooks <[EMAIL PROTECTED]>
+ *
+ * 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
+#include
+#include
+
+#include
+#include
+#include
+
+/* bits in mode register - bit 0 ist MSb */
+/* data latched on leading edge of clock, else trailing edge */
+#define SPI_PPC4XX_MODE_SCP(0x80 >> 3)
+/* port enabled */
+#define SPI_PPC4XX_MODE_SPE(0x80 >> 4)
+/* MSB first, else LSB first */
+#define SPI_PPC4XX_MODE_RD (0x80 >> 5)
+/* clock invert - idle clock = 1, active clock = 0; else reversed */
+#define SPI_PPC4XX_MODE_CI (0x80 >> 6)
+/* loopback enable */
+#define SPI_PPC4XX_MODE_IL (0x80 >> 7)
+/* bits in control register */
+/* starts a transfer when set */
+#define SPI_PPC4XX_CR_STR (0x80 >> 7)
+/* bits in status register */
+/* port is busy with a transfer */
+#define SPI_PPC4XX_SR_BSY (0x80 >> 6)
+/* RxD ready */
+#define SPI_PPC4XX_SR_RBR (0x80 >> 7)
+
+/* the spi->mode bits understood by this driver: */
+#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
+
+/* clock settings (SCP and CI) for various SPI modes */
+#define SPI_CLK_MODE0 SPI_PPC4XX_MODE_SCP
+#define SPI_CLK_MODE1 0
+#define SPI_CLK_MODE2 SPI_PPC4XX_MODE_CI
+#define SPI_CLK_MODE3 (SPI_PPC4XX_MODE_SCP | SPI_PPC4XX_MODE_CI)
+
+#define DRIVER_NAME"spi_ppc4xx_of"
+
+struct spi_ppc4xx_regs {
+ u8 mode;
+ u8 rxd;
+ u8 txd;
+ u8 cr;
+ u8 sr;
+ u8 dummy;
+ /*
+* Clock divisor modulus register
+* This uses the follwing formula:
+*SCPClkOut = OPBCLK/(4(CDM + 1))
+* or
+*CDM = (OPBCLK/4*SCPClkOut) - 1
+* bit 0 is the MSb!
+*/
+ u8 cdm;
+};
+
+/* SPI Controller driver's private data. */
+struct ppc4xx_spi {
+ /* bitbang has to be first */
+ struct spi_bitbang bitbang;
+ struct completion done;
+
+ u64 mapbase;
+
Re: [RFC] a little disassembly infrastructure
Hollis Blanchard writes: > I've also found xmon's ppc-opc.c. That parses the opcode and operands, > so could use some shared macros. That's a direct copy from GNU binutils. I'm reluctant to modify it because then maintenance becomes more than just copying in the latest version. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] a little disassembly infrastructure
Hollis Blanchard wrote: Hi, I wrote this patch for KVM [1], but now that I look closer it seems like there might be some overlapping functionality. First there's emulate_instruction(), but since that only handles a few instructions it's just an ordered list of if ((instruction & MASK_A) == INST_A) tests, so it doesn't actually parse out opcodes or anything. I've also found xmon's ppc-opc.c. That parses the opcode and operands, so could use some shared macros. Of course, the actual lookup isn't time-sensitive, so that doesn't make sense to share. On the other hand, if we do come up with something fast *and* robust for KVM, maybe xmon could use that. Of course, these macros alone is pretty small, so maybe it's not a big deal to make a kvm-specific copy of them, leaving the other uses alone. Comments? [1] KVM on PowerPC traps when privileged instructions are executed in the guest context. We must then (quickly!) disassemble them and emulate their behavior. Right now we do this with a giant switch statement or two, but are considering more sophisticated techniques in the future. Yeah, personally I like this change. I was looking at emulating some PPC instructions in a driver and based on inspection I was going to use the code you had in for KVM. Having these macros in a generic header is a "Good Thing" IMHO. I think we should have a generic disassembly infrastructure and use that everywhere. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Add missing irq free in fs_enet error path.
If something goes wrong attaching to phy driver, we weren't freeing the IRQ.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
I just noticed this file has already been touched in -rc1 so here is the
patch again, adjusted accordingly.
diff -r -upN 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c
NEW/drivers/net/fs_enet/fs_enet-main.c
--- 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c 2008-10-24
17:54:31.0 -0700
+++ NEW/drivers/net/fs_enet/fs_enet-main.c 2008-10-24 17:57:03.0
-0700
@@ -795,6 +795,7 @@ static int fs_enet_open(struct net_devic
err = fs_init_phy(dev);
if (err) {
+ free_irq(fep->interrupt, dev);
if (fep->fpi->use_napi)
napi_disable(&fep->napi);
return err;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] leds: Let GPIO LEDs keep their current state
On Fri, Oct 24, 2008 at 5:09 PM, Trent Piepho <[EMAIL PROTECTED]> wrote:
> Let GPIO LEDs get their initial value from whatever the current state of
> the GPIO line is. On some systems the LEDs are put into some state by the
> firmware or hardware before Linux boots, and it is desired to have them
> keep this state which is otherwise unknown to Linux.
>
> This requires that the underlying GPIO driver support reading the value of
> output GPIOs. Some drivers support this and some do not.
>
> The platform data for the platform device binding gets a new field
> 'keep_state' which turns this on. keep_state overrides default_state.
>
> For the OpenFirmware bindings, the "default-state" property gains a new
> allowable setting "keep".
Hmmm... I'd prefer firmware to actually update the device tree if the
LED state needs to be preserved. In fact, it might be better use the
name "current-state" instead of "default-state" similar to the
current-speed property used in serial devices. However, I understand
that there are practical implications with this were not all firmware
is device tree aware. I don't see any reason not to support this
approach, so:
Acked-by: Grant Likely <[EMAIL PROTECTED]>
(But consider changing the property name)
This is a good patch series, thanks.
g.
>
> Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
> ---
> Documentation/powerpc/dts-bindings/gpio/led.txt | 16
> drivers/leds/leds-gpio.c| 12
> include/linux/leds.h|3 ++-
> 3 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
> b/Documentation/powerpc/dts-bindings/gpio/led.txt
> index 544ded7..918bf9f 100644
> --- a/Documentation/powerpc/dts-bindings/gpio/led.txt
> +++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
> @@ -21,10 +21,12 @@ LED sub-node properties:
> "ide-disk" - LED indicates disk activity
> "timer" - LED flashes at a fixed, configurable rate
> - default-state: (optional) The initial state of the LED. Valid
> - values are "on" and "off". If the LED is already on or off and the
> - default-state property is set the to same value, then no glitch
> - should be produced where the LED momentarily turns off (or on).
> - The default is off if this property is not present.
> + values are "on", "off", and "keep". If the LED is already on or off
> + and the default-state property is set the to same value, then no
> + glitch should be produced where the LED momentarily turns off (or
> + on). The "keep" setting will keep the LED at whatever its current
> + state is, without producing a glitch. The default is off if this
> + property is not present.
>
> Examples:
>
> @@ -35,6 +37,12 @@ leds {
>gpios = <&mcu_pio 0 1>; /* Active low */
>linux,default-trigger = "ide-disk";
>};
> +
> + fault {
> + gpios = <&mcu_pio 1 0>;
> + /* Keep LED on if BIOS detected hardware fault */
> + default-state = "keep";
> + };
> };
>
> run-control {
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index 0dbad87..bb2a234 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -76,7 +76,7 @@ static int __devinit create_gpio_led(const struct gpio_led
> *template,
>struct gpio_led_data *led_dat, struct device *parent,
>int (*blink_set)(unsigned, unsigned long *, unsigned long *))
> {
> - int ret;
> + int ret, state;
>
>ret = gpio_request(template->gpio, template->name);
>if (ret < 0)
> @@ -92,10 +92,13 @@ static int __devinit create_gpio_led(const struct
> gpio_led *template,
>led_dat->cdev.blink_set = gpio_blink_set;
>}
>led_dat->cdev.brightness_set = gpio_led_set;
> - led_dat->cdev.brightness = template->default_state ? LED_FULL :
> LED_OFF;
> + if (template->keep_state)
> + state = !!gpio_get_value(led_dat->gpio) ^ led_dat->active_low;
> + else
> + state = template->default_state;
> + led_dat->cdev.brightness = state ? LED_FULL : LED_OFF;
>
> - gpio_direction_output(led_dat->gpio,
> - led_dat->active_low ^ template->default_state);
> + gpio_direction_output(led_dat->gpio, led_dat->active_low ^ state);
>
>INIT_WORK(&led_dat->work, gpio_led_work);
>
> @@ -266,6 +269,7 @@ static int __devinit of_gpio_leds_probe(struct of_device
> *ofdev,
>of_get_property(child, "linux,default-trigger", NULL);
>state = of_get_property(child, "default-state", NULL);
>led.default_state = state && !strcmp(state, "on");
> + led.keep_state = state && !strcmp(state, "keep");
>
>ret = create_gpio_led(&led,
> &pdata->led_data[pdata->num_leds++],
> &ofdev->dev, NULL);
>
Re: 2.6.27-git7 compile error (ppc)
On Fri, 2008-10-24 at 16:55 -0600, Chris Friesen wrote: > Rafael J. Wysocki wrote: > > On Friday, 17 of October 2008, Kumar Gala wrote: > > >> I've got a patch that seems to address this for me building w/ > >> CONFIG_RELOCATABLE on ppc32/85xx. > > > > Has that been fixed in 2.6.27 and/or current mainline? > > I think CONFIG_RELOCATABLE was introduced post 2.6.27, so shouldn't be a > problem in that version. > > Chris Not quite true. CONFIG_RELOCATABLE is present in 2.6.27, but the changes to types.h happend post 2.6.27 - so there is no problem with 2.6.27. 2.6.27-git11 compiles fine. Thanks, Badari ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] leds: Add option to have GPIO LEDs start on
On Fri, Oct 24, 2008 at 5:09 PM, Trent Piepho <[EMAIL PROTECTED]> wrote:
> Yes, there is the "default-on" trigger but there are problems with that.
[...]
> The platform device binding gains a field in the platform data "default_state"
> that controls this. The OpenFirmware binding uses a property named
> "default-state" that can be set to "on" or "off". The default the property
> isn't present is off.
This look much preferred to setting the the default-on trigger. Why
not remove the default-on trigger entirely from the binding
documentation so there is no confusion?
Also, my preference would be an empty "led-default-on" property
instead of "default-state" with a value that needs to be parsed, but
I'm not concerned about it enough to argue.
Otherwise:
Acked-by: Grant Likely <[EMAIL PROTECTED]>
>
> Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
> ---
> Documentation/powerpc/dts-bindings/gpio/led.txt |7 +++
> drivers/leds/leds-gpio.c|8 ++--
> include/linux/leds.h|1 +
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
> b/Documentation/powerpc/dts-bindings/gpio/led.txt
> index 9f969c2..544ded7 100644
> --- a/Documentation/powerpc/dts-bindings/gpio/led.txt
> +++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
> @@ -20,6 +20,11 @@ LED sub-node properties:
> "heartbeat" - LED "double" flashes at a load average based rate
> "ide-disk" - LED indicates disk activity
> "timer" - LED flashes at a fixed, configurable rate
> +- default-state: (optional) The initial state of the LED. Valid
> + values are "on" and "off". If the LED is already on or off and the
> + default-state property is set the to same value, then no glitch
> + should be produced where the LED momentarily turns off (or on).
> + The default is off if this property is not present.
>
> Examples:
>
> @@ -36,8 +41,10 @@ run-control {
>compatible = "gpio-leds";
>red {
>gpios = <&mpc8572 6 0>;
> + default-state = "off";
>};
>green {
>gpios = <&mpc8572 7 0>;
> + default-state = "on";
>};
> }
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index f41b841..0dbad87 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -92,9 +92,10 @@ static int __devinit create_gpio_led(const struct gpio_led
> *template,
>led_dat->cdev.blink_set = gpio_blink_set;
>}
>led_dat->cdev.brightness_set = gpio_led_set;
> - led_dat->cdev.brightness = LED_OFF;
> + led_dat->cdev.brightness = template->default_state ? LED_FULL :
> LED_OFF;
>
> - gpio_direction_output(led_dat->gpio, led_dat->active_low);
> + gpio_direction_output(led_dat->gpio,
> + led_dat->active_low ^ template->default_state);
>
>INIT_WORK(&led_dat->work, gpio_led_work);
>
> @@ -256,12 +257,15 @@ static int __devinit of_gpio_leds_probe(struct
> of_device *ofdev,
>memset(&led, 0, sizeof(led));
>for_each_child_of_node(np, child) {
>unsigned int flags;
> + const char *state;
>
>led.gpio = of_get_gpio(child, 0, &flags);
>led.active_low = flags & OF_GPIO_ACTIVE_LOW;
>led.name = of_get_property(child, "label", NULL) ? :
> child->name;
>led.default_trigger =
>of_get_property(child, "linux,default-trigger", NULL);
> + state = of_get_property(child, "default-state", NULL);
> + led.default_state = state && !strcmp(state, "on");
>
>ret = create_gpio_led(&led,
> &pdata->led_data[pdata->num_leds++],
> &ofdev->dev, NULL);
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index d3a73f5..caa3987 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -138,6 +138,7 @@ struct gpio_led {
>const char *default_trigger;
>unsignedgpio;
>u8 active_low;
> + u8 default_state;
> };
>
> struct gpio_led_platform_data {
> --
> 1.5.4.3
>
>
--
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] powerpc: enforce a non-spe kernel build even on broken compilers
On Oct 24, 2008, at 6:51 PM, Nate Case wrote: On Fri, 2008-10-17 at 09:02 -0500, Nate Case wrote: With this patch it compiles and boots fine. The option -mabi=no-spe is not required. Please don't accept this patch yet. My past testing showed that "-mabi=no-spe" was required for my toolchain. I'll go back and double check though. OK, I went back and re-tested. Kernel: 2.6.27 CPU: MPC8572 Toolchain: Cross-compiler built using crosstool-ng gcc 4.3.1, default target CFLAGS include '-mabi=spe -mspe' binutils 2.18.90 snapshot (built with --enable-spe=yes) Kbuild flagsResult -- -mno-spe (*)FAILED -mno-spe -mabi=no-spe FAILED -mno-spe -mspe=no OK -mspe=noOK (*) 2.6.27 default In the failure case, the kernel would repeatedly dump out "SPE used in kernel (task=, pc=)". I think I was fooled before because I added _both_ "-mspe=no" and "-mabi=no-spe" to my KBUILD_CFLAGS and saw the problem go away. Since I trusted the documentation that -mspe=no and -mno-spe were the same, I assumed that -mabi=no-spe was the key. So, I've changed my mind. I now agree with Sebastian that "-mabi=no-spe" is not required. "-mno-spe -mspe=no" is probably the safe way to go. -- Nate Case <[EMAIL PROTECTED]> thanks for testing this all out. I'll submit a patch to remove the -mabi=.*spe.* foo. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Fri, 2008-10-17 at 09:02 -0500, Nate Case wrote: > > With this patch it compiles and boots fine. > > The option -mabi=no-spe is not required. > > Please don't accept this patch yet. My past testing showed that > "-mabi=no-spe" was required for my toolchain. I'll go back and double > check though. OK, I went back and re-tested. Kernel: 2.6.27 CPU: MPC8572 Toolchain: Cross-compiler built using crosstool-ng gcc 4.3.1, default target CFLAGS include '-mabi=spe -mspe' binutils 2.18.90 snapshot (built with --enable-spe=yes) Kbuild flagsResult -- -mno-spe (*)FAILED -mno-spe -mabi=no-spe FAILED -mno-spe -mspe=no OK -mspe=noOK (*) 2.6.27 default In the failure case, the kernel would repeatedly dump out "SPE used in kernel (task=, pc=)". I think I was fooled before because I added _both_ "-mspe=no" and "-mabi=no-spe" to my KBUILD_CFLAGS and saw the problem go away. Since I trusted the documentation that -mspe=no and -mno-spe were the same, I assumed that -mabi=no-spe was the key. So, I've changed my mind. I now agree with Sebastian that "-mabi=no-spe" is not required. "-mno-spe -mspe=no" is probably the safe way to go. -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] leds: Support OpenFirmware led bindings
On Fri, Oct 24, 2008 at 5:08 PM, Trent Piepho <[EMAIL PROTECTED]> wrote: > Add bindings to support LEDs defined as of_platform devices in addition to > the existing bindings for platform devices. > > New options in Kconfig allow the platform binding code and/or the > of_platform code to be turned on. The of_platform code is of course only > available on archs that have OF support. > > The existing probe and remove methods are refactored to use new functions > create_gpio_led(), to create and register one led, and delete_gpio_led(), > to unregister and free one led. The new probe and remove methods for the > of_platform driver can then share most of the common probe and remove code > with the platform driver. > > The suspend and resume methods aren't shared, but they are very short. The > actual led driving code is the same for LEDs created by either binding. > > The OF bindings are based on patch by Anton Vorontsov > <[EMAIL PROTECTED]>. They have been extended to allow multiple LEDs > per device. > > Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> This also looks sane. However, since this modifies a binding, can you please repost to the [EMAIL PROTECTED] mailing list? Also, one comment below. Acked-by: Grant Likely <[EMAIL PROTECTED]> > diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt > b/Documentation/powerpc/dts-bindings/gpio/led.txt > index ff51f4c..9f969c2 100644 > --- a/Documentation/powerpc/dts-bindings/gpio/led.txt > +++ b/Documentation/powerpc/dts-bindings/gpio/led.txt > @@ -1,15 +1,43 @@ > -LED connected to GPIO > +LEDs connected to GPIO lines > > Required properties: > -- compatible : should be "gpio-led". > -- label : (optional) the label for this LED. If omitted, the label is > +- compatible : should be "gpio-leds". > + > +Each LED is represented as a sub-node of the gpio-leds device. Each > +node's name represents the name of the corresponding LED. > + > +LED sub-node properties: > +- gpios : Should specify the LED's GPIO, see "Specifying GPIO information > + for devices" in Documentation/powerpc/booting-without-of.txt. Active > + low LEDs should be indicated using flags in the GPIO specifier. > +- label : (optional) The label for this LED. If omitted, the label is > taken from the node name (excluding the unit address). > -- gpios : should specify LED GPIO. > +- linux,default-trigger : (optional) This parameter, if present, is a > + string defining the trigger assigned to the LED. Current triggers are: > +"backlight" - LED will act as a back-light, controlled by the framebuffer > + system > +"default-on" - LED will turn on > +"heartbeat" - LED "double" flashes at a load average based rate > +"ide-disk" - LED indicates disk activity > +"timer" - LED flashes at a fixed, configurable rate As I'm sure you can predict, I'm not thrilled with this; but it *is* a very linux-specific sort of thing, it *is* a necessary bit of data. :-) My biggest worry is that the Linux internal strings will change in the future which will force the gpio driver to insert a translation between these names and some future internal Linux name... ... I suppose another option is to just codify them here right now (maybe named something like "led-usage") and if Linux changes then the driver just needs to keep up with the new trigger names (translating the old). Either way, I'm not going to oppose this patch over this issue. Nice patch. 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] powerpc/40x: Don't enable HCU4 board by default
On Fri, 24 Oct 2008 23:54:24 +0200 Niklaus Giger <[EMAIL PROTECTED]> wrote: > Am Freitag 24 Oktober 2008 16.31:58 schrieb Josh Boyer: > > Fix the HCU4 Kconfig option to 'default n'. We don't want the > > board to always be enabled for other board defconfigs. > Sorry, for this silly mistake. Thanks for your fix. You don't need to apologize. Have you noticed that I have "fixed" the EMAC driver 3 times this merge window already, all for my own stupid mistakes? :) > My board compiles and runs fine using Linus 2.6.28-rc1. Thanks for testing! josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Right. I had a similar discussion about this the other day with Anton (I think he forwarded it here but I wasn't subscribed at that point..). The current ideology for device trees is to get rid of device_type for new trees that aren't OF-based. I think it's relevant to give nodes fancy names (i.e. not "timer" or even "ethernet") since the name property is entirely descriptive in nature. I also think it's relevant that device_type still exists because since the name is totally irrelevant except from a user-friendliness point of view, marking a device as a generic type is quite important (device_type = serial, ethernet, rtc, keyboard) where compatible properties are usually wildly over-specific. I don't use device_type much, if at all, anymore. Generic name + compatible just works better than device_type + specific name. When I write code that has to find a node that is suitable for a given purpose, I look for the existence of suitable methods and perhaps other properties. I was just too hard to keep the list of device_type values properly synchronized with all the possible things that you might want to infer from that set of names. device_type is one of those things that seemed like a good idea at the time, but didn't work out as well as I had hoped. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] oops in net_rx_action on 64-bit powerpc
From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Fri, 24 Oct 2008 17:39:00 -0600 > So...it would appear that the NAPI code is somehow buggy, and > 6ba33ac should probably be reverted until the problem is found and > fixed. No I think the problem is simple enough that someone should study the ->poll() routine quickly and audit it's return values. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] oops in net_rx_action on 64-bit powerpc
David Miller wrote: From: "Brandeburg, Jesse" <[EMAIL PROTECTED]> Date: Thu, 23 Oct 2008 14:50:06 -0700 Chris Friesen wrote: I tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar to a Maple board). The first time I booted I got the first log below via the serial console. I rebooted and got as far as a login prompt. I was able to log in via the serial console, but then got an almost identical oops again, as shown in the second log below. I configed out the gigE drivers for the backplane so the only remaining network link was the e100 link used for booting, but the problem remained. Anyone have any idea what might be causing this? Thanks, Chris Starting xinetd: [ OK ] Starting cron: [ OK ] Unable to handle kernel paging request for data at address 0x00100108 that 00100108 pattern looks familiar, I'm not much help here, but I think that had something to do with the list management of the poll_list in a netdev struct. so now you just have to figure out why someone's netdev struct is becoming NULL. :-) Usually this is an indication of returning the wrong value from the driver's ->poll() routine. Looks like I was wrong before...the remaining ethernet link is an AMD-8111, not an e100. Sorry about that. I backed out 6ba33ac "amd8111e: delete non NAPI code from the driver". With NAPI disabled, the blade appears stable. With NAPI enabled, the original problem recurred. So...it would appear that the NAPI code is somehow buggy, and 6ba33ac should probably be reverted until the problem is found and fixed. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] of_gpio: Return GPIO flags from of_get_gpio()
On Fri, Oct 24, 2008 at 5:08 PM, Trent Piepho <[EMAIL PROTECTED]> wrote:
> The device binding spec for OF GPIOs defines a flags field, but there is
> currently no way to get it. This patch adds a parameter to of_get_gpio()
> where the flags will be returned if non-NULL. of_get_gpio() in turn passes
> the parameter to the of_gpio_chip's xlate method, which can extract any
> flags present from the gpio_spec.
>
> The default (and currently only) of_gpio_chip xlate method,
> of_gpio_simple_xlate(), is modified to do this.
>
> Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
This looks sane to me
Acked-by: Grant Likely <[EMAIL PROTECTED]>
> ---
> drivers/mtd/nand/fsl_upm.c |2 +-
> drivers/net/fs_enet/fs_enet-main.c |2 +-
> drivers/net/phy/mdio-ofgpio.c |4 ++--
> drivers/of/gpio.c | 13 ++---
> drivers/serial/cpm_uart/cpm_uart_core.c |2 +-
> include/linux/of_gpio.h | 17 +
> 6 files changed, 28 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
> index 024e3ff..a25d962 100644
> --- a/drivers/mtd/nand/fsl_upm.c
> +++ b/drivers/mtd/nand/fsl_upm.c
> @@ -218,7 +218,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
>}
>fun->upm_cmd_offset = *prop;
>
> - fun->rnb_gpio = of_get_gpio(ofdev->node, 0);
> + fun->rnb_gpio = of_get_gpio(ofdev->node, 0, NULL);
>if (fun->rnb_gpio >= 0) {
>ret = gpio_request(fun->rnb_gpio, ofdev->dev.bus_id);
>if (ret) {
> diff --git a/drivers/net/fs_enet/fs_enet-main.c
> b/drivers/net/fs_enet/fs_enet-main.c
> index cb51c1f..5a3c7ee 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -994,7 +994,7 @@ static int __devinit find_phy(struct device_node *np,
>goto out_put_phy;
>}
>
> - bus_id = of_get_gpio(mdionode, 0);
> + bus_id = of_get_gpio(mdionode, 0, NULL);
>if (bus_id < 0) {
>struct resource res;
>ret = of_address_to_resource(mdionode, 0, &res);
> diff --git a/drivers/net/phy/mdio-ofgpio.c b/drivers/net/phy/mdio-ofgpio.c
> index 2ff9775..e3757c6 100644
> --- a/drivers/net/phy/mdio-ofgpio.c
> +++ b/drivers/net/phy/mdio-ofgpio.c
> @@ -78,8 +78,8 @@ static int __devinit mdio_ofgpio_bitbang_init(struct
> mii_bus *bus,
> {
>struct mdio_gpio_info *bitbang = bus->priv;
>
> - bitbang->mdc = of_get_gpio(np, 0);
> - bitbang->mdio = of_get_gpio(np, 1);
> + bitbang->mdc = of_get_gpio(np, 0, NULL);
> + bitbang->mdio = of_get_gpio(np, 1, NULL);
>
>if (bitbang->mdc < 0 || bitbang->mdio < 0)
>return -ENODEV;
> diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
> index 7cd7301..2123517 100644
> --- a/drivers/of/gpio.c
> +++ b/drivers/of/gpio.c
> @@ -22,11 +22,12 @@
> * of_get_gpio - Get a GPIO number from the device tree to use with GPIO API
> * @np:device node to get GPIO from
> * @index: index of the GPIO
> + * @flags: GPIO's flags are returned here if non-NULL
> *
> * Returns GPIO number to use with Linux generic GPIO API, or one of the errno
> * value on the error condition.
> */
> -int of_get_gpio(struct device_node *np, int index)
> +int of_get_gpio(struct device_node *np, int index, unsigned int *flags)
> {
>int ret;
>struct device_node *gc;
> @@ -59,7 +60,9 @@ int of_get_gpio(struct device_node *np, int index)
>goto err1;
>}
>
> - ret = of_gc->xlate(of_gc, np, gpio_spec);
> + if (flags)
> + *flags = 0;
> + ret = of_gc->xlate(of_gc, np, gpio_spec, flags);
>if (ret < 0)
>goto err1;
>
> @@ -77,19 +80,23 @@ EXPORT_SYMBOL(of_get_gpio);
> * @of_gc: pointer to the of_gpio_chip structure
> * @np:device node of the GPIO chip
> * @gpio_spec: gpio specifier as found in the device tree
> + * @flags: if non-NUll flags are returned here
> *
> * This is simple translation function, suitable for the most 1:1 mapped
> * gpio chips. This function performs only one sanity check: whether gpio
> * is less than ngpios (that is specified in the gpio_chip).
> */
> int of_gpio_simple_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
> -const void *gpio_spec)
> +const void *gpio_spec, unsigned int *flags)
> {
>const u32 *gpio = gpio_spec;
>
>if (*gpio > of_gc->gc.ngpio)
>return -EINVAL;
>
> + if (flags && of_gc->gpio_cells > 1)
> + *flags = gpio[1];
> +
>return *gpio;
> }
> EXPORT_SYMBOL(of_gpio_simple_xlate);
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c
> index bde4b4b..7835cd4 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
From: Kumar Gala <[EMAIL PROTECTED]> Date: Fri, 24 Oct 2008 10:39:05 -0500 > As for making it ARCH specific, that doesn't really help since not > all PPC hw has the limitation I spoke of. Not even all MPIC (in our > cases) have the limitation. Since the PPC code knows exactly which MPICs have the problem the PPC code is where the constraining can occur. I agree completely with the suggestion that the arch code has to interpret the cpumask as appropriate for the hardware, since the user can stick "illegal" values there anyways. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
From: Kumar Gala <[EMAIL PROTECTED]> Date: Fri, 24 Oct 2008 10:57:38 -0500 > Commit 18404756765c713a0be4eb1082920c04822ce588 introduced a regression > on a subset of SMP based PPC systems whose interrupt controller only > allow setting an irq to a single processor. The previous behavior > was only CPU0 was initially setup to get interrupts. Revert back > to that behavior. > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> I really don't remember getting all of my interrupts only on cpu 0 on sparc64 before any of these changes. I therefore find all of this quite mysterious. :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.27-git7 compile error (ppc)
On Friday, 17 of October 2008, Kumar Gala wrote: > > On Oct 17, 2008, at 1:11 PM, Badari Pulavarty wrote: > > > On Fri, 2008-10-17 at 10:47 -0700, Badari Pulavarty wrote: > >> Hi, > >> > >> I get this following compile error on my ppc box. > >> > >> Let me know if its a known issue. Otherwise, I can figure out > >> whats happening. > >> > >> Thanks, > >> Badari > > > > This is due to recent changes to move phys_add_t definition from > > arch/powerpc/include/asm/types.h to include/linux/types.h. > > > > arch/powerpc/include/asm/page.h needs phys_addr_t for > > CONFIG_RELOCATABLE. Needs fixing.. > > > > Thanks, > > Badari > > > >> > >> CC arch/powerpc/mm/slb.o > >> In file included from /usr/src/linux-2.6.27/arch/powerpc/include/ > >> asm/mmu-hash64.h:16, > >> from /usr/src/linux-2.6.27/arch/powerpc/include/asm/ > >> mmu.h:7, > >> from /usr/src/linux-2.6.27/arch/powerpc/include/asm/ > >> pgtable.h:7, > >> from arch/powerpc/mm/slb.c:19: > >> /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: error: > >> parse error before "memstart_addr" > >> /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: warning: > >> type defaults to `int' in declaration of `memstart_addr' > >> /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: warning: > >> data definition has no type or storage class > >> /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: error: > >> parse error before "kernstart_addr" > >> /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: warning: > >> type defaults to `int' in declaration of `kernstart_addr' > >> /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: warning: > >> data definition has no type or storage class > >> AS arch/powerpc/lib/string.o > >> CC arch/powerpc/lib/alloc.o > >> CALLarch/powerpc/kernel/systbl_chk.sh > >> CC arch/powerpc/kernel/sysfs.o > >> make[1]: *** [arch/powerpc/mm/slb.o] Error 1 > >> make: *** [arch/powerpc/mm] Error 2 > >> make: *** Waiting for unfinished jobs > > I've got a patch that seems to address this for me building w/ > CONFIG_RELOCATABLE on ppc32/85xx. Has that been fixed in 2.6.27 and/or current mainline? Rafael ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add missing irq free in fs_enet error path.
If something goes wrong attaching to phy driver, we weren't freeing the IRQ.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
cvs diff -r linux-2_6_27 -upN linux/drivers/net/fs_enet/fs_enet-main.c
Index: linux/drivers/net/fs_enet/fs_enet-main.c
===
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 fs_enet-main.c
--- linux/drivers/net/fs_enet/fs_enet-main.c11 Oct 2008 02:53:59 -
1.1.1.1
+++ linux/drivers/net/fs_enet/fs_enet-main.c24 Oct 2008 22:19:47 -
@@ -811,6 +811,7 @@ static int fs_enet_open(struct net_devic
err = fs_init_phy(dev);
if (err) {
+ fs_free_irq(dev, fep->interrupt);
if (fep->fpi->use_napi)
napi_disable(&fep->napi);
return err;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] leds: Let GPIO LEDs keep their current state
Let GPIO LEDs get their initial value from whatever the current state of
the GPIO line is. On some systems the LEDs are put into some state by the
firmware or hardware before Linux boots, and it is desired to have them
keep this state which is otherwise unknown to Linux.
This requires that the underlying GPIO driver support reading the value of
output GPIOs. Some drivers support this and some do not.
The platform data for the platform device binding gets a new field
'keep_state' which turns this on. keep_state overrides default_state.
For the OpenFirmware bindings, the "default-state" property gains a new
allowable setting "keep".
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 16
drivers/leds/leds-gpio.c| 12
include/linux/leds.h|3 ++-
3 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
index 544ded7..918bf9f 100644
--- a/Documentation/powerpc/dts-bindings/gpio/led.txt
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -21,10 +21,12 @@ LED sub-node properties:
"ide-disk" - LED indicates disk activity
"timer" - LED flashes at a fixed, configurable rate
- default-state: (optional) The initial state of the LED. Valid
- values are "on" and "off". If the LED is already on or off and the
- default-state property is set the to same value, then no glitch
- should be produced where the LED momentarily turns off (or on).
- The default is off if this property is not present.
+ values are "on", "off", and "keep". If the LED is already on or off
+ and the default-state property is set the to same value, then no
+ glitch should be produced where the LED momentarily turns off (or
+ on). The "keep" setting will keep the LED at whatever its current
+ state is, without producing a glitch. The default is off if this
+ property is not present.
Examples:
@@ -35,6 +37,12 @@ leds {
gpios = <&mcu_pio 0 1>; /* Active low */
linux,default-trigger = "ide-disk";
};
+
+ fault {
+ gpios = <&mcu_pio 1 0>;
+ /* Keep LED on if BIOS detected hardware fault */
+ default-state = "keep";
+ };
};
run-control {
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index 0dbad87..bb2a234 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -76,7 +76,7 @@ static int __devinit create_gpio_led(const struct gpio_led
*template,
struct gpio_led_data *led_dat, struct device *parent,
int (*blink_set)(unsigned, unsigned long *, unsigned long *))
{
- int ret;
+ int ret, state;
ret = gpio_request(template->gpio, template->name);
if (ret < 0)
@@ -92,10 +92,13 @@ static int __devinit create_gpio_led(const struct gpio_led
*template,
led_dat->cdev.blink_set = gpio_blink_set;
}
led_dat->cdev.brightness_set = gpio_led_set;
- led_dat->cdev.brightness = template->default_state ? LED_FULL : LED_OFF;
+ if (template->keep_state)
+ state = !!gpio_get_value(led_dat->gpio) ^ led_dat->active_low;
+ else
+ state = template->default_state;
+ led_dat->cdev.brightness = state ? LED_FULL : LED_OFF;
- gpio_direction_output(led_dat->gpio,
- led_dat->active_low ^ template->default_state);
+ gpio_direction_output(led_dat->gpio, led_dat->active_low ^ state);
INIT_WORK(&led_dat->work, gpio_led_work);
@@ -266,6 +269,7 @@ static int __devinit of_gpio_leds_probe(struct of_device
*ofdev,
of_get_property(child, "linux,default-trigger", NULL);
state = of_get_property(child, "default-state", NULL);
led.default_state = state && !strcmp(state, "on");
+ led.keep_state = state && !strcmp(state, "keep");
ret = create_gpio_led(&led, &pdata->led_data[pdata->num_leds++],
&ofdev->dev, NULL);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index caa3987..c51b625 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -138,7 +138,8 @@ struct gpio_led {
const char *default_trigger;
unsignedgpio;
u8 active_low;
- u8 default_state;
+ u8 default_state; /* 0 = off, 1 = on */
+ u8 keep_state; /* overrides default_state */
};
struct gpio_led_platform_data {
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] leds: Add option to have GPIO LEDs start on
Yes, there is the "default-on" trigger but there are problems with that.
For one, it's a inefficient way to do it and requires led trigger support
to be compiled in.
But the real reason is that is produces a glitch on the LED. The GPIO is
allocate with the LED *off*, then *later* when then trigger runs it is
turned back on. If the LED was already on via the GPIO's reset default or
action of the firmware, this produces a glitch where the LED goes from on
to off to on. While normally this is fast enough that it wouldn't be
noticeable to a human observer, there are still serious problems.
One is that there may be something else on the GPIO line, like a hardware
alarm or watchdog, that is fast enough to notice the glitch.
Another is that the kernel may panic before the LED is turned back on, thus
hanging with the LED in the wrong state. This is not just speculation, but
actually happened to me with an embedded system that has an LED which
should turn off when the kernel finishes booting, which was left in the
incorrect state due to a bug in the OF LED binding code.
The platform device binding gains a field in the platform data "default_state"
that controls this. The OpenFirmware binding uses a property named
"default-state" that can be set to "on" or "off". The default the property
isn't present is off.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/gpio/led.txt |7 +++
drivers/leds/leds-gpio.c|8 ++--
include/linux/leds.h|1 +
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
index 9f969c2..544ded7 100644
--- a/Documentation/powerpc/dts-bindings/gpio/led.txt
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -20,6 +20,11 @@ LED sub-node properties:
"heartbeat" - LED "double" flashes at a load average based rate
"ide-disk" - LED indicates disk activity
"timer" - LED flashes at a fixed, configurable rate
+- default-state: (optional) The initial state of the LED. Valid
+ values are "on" and "off". If the LED is already on or off and the
+ default-state property is set the to same value, then no glitch
+ should be produced where the LED momentarily turns off (or on).
+ The default is off if this property is not present.
Examples:
@@ -36,8 +41,10 @@ run-control {
compatible = "gpio-leds";
red {
gpios = <&mpc8572 6 0>;
+ default-state = "off";
};
green {
gpios = <&mpc8572 7 0>;
+ default-state = "on";
};
}
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index f41b841..0dbad87 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -92,9 +92,10 @@ static int __devinit create_gpio_led(const struct gpio_led
*template,
led_dat->cdev.blink_set = gpio_blink_set;
}
led_dat->cdev.brightness_set = gpio_led_set;
- led_dat->cdev.brightness = LED_OFF;
+ led_dat->cdev.brightness = template->default_state ? LED_FULL : LED_OFF;
- gpio_direction_output(led_dat->gpio, led_dat->active_low);
+ gpio_direction_output(led_dat->gpio,
+ led_dat->active_low ^ template->default_state);
INIT_WORK(&led_dat->work, gpio_led_work);
@@ -256,12 +257,15 @@ static int __devinit of_gpio_leds_probe(struct of_device
*ofdev,
memset(&led, 0, sizeof(led));
for_each_child_of_node(np, child) {
unsigned int flags;
+ const char *state;
led.gpio = of_get_gpio(child, 0, &flags);
led.active_low = flags & OF_GPIO_ACTIVE_LOW;
led.name = of_get_property(child, "label", NULL) ? :
child->name;
led.default_trigger =
of_get_property(child, "linux,default-trigger", NULL);
+ state = of_get_property(child, "default-state", NULL);
+ led.default_state = state && !strcmp(state, "on");
ret = create_gpio_led(&led, &pdata->led_data[pdata->num_leds++],
&ofdev->dev, NULL);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index d3a73f5..caa3987 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -138,6 +138,7 @@ struct gpio_led {
const char *default_trigger;
unsignedgpio;
u8 active_low;
+ u8 default_state;
};
struct gpio_led_platform_data {
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] leds: Support OpenFirmware led bindings
Add bindings to support LEDs defined as of_platform devices in addition to
the existing bindings for platform devices.
New options in Kconfig allow the platform binding code and/or the
of_platform code to be turned on. The of_platform code is of course only
available on archs that have OF support.
The existing probe and remove methods are refactored to use new functions
create_gpio_led(), to create and register one led, and delete_gpio_led(),
to unregister and free one led. The new probe and remove methods for the
of_platform driver can then share most of the common probe and remove code
with the platform driver.
The suspend and resume methods aren't shared, but they are very short. The
actual led driving code is the same for LEDs created by either binding.
The OF bindings are based on patch by Anton Vorontsov
<[EMAIL PROTECTED]>. They have been extended to allow multiple LEDs
per device.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 46 -
drivers/leds/Kconfig| 21 ++-
drivers/leds/leds-gpio.c| 230 ++-
3 files changed, 243 insertions(+), 54 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
index ff51f4c..9f969c2 100644
--- a/Documentation/powerpc/dts-bindings/gpio/led.txt
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -1,15 +1,43 @@
-LED connected to GPIO
+LEDs connected to GPIO lines
Required properties:
-- compatible : should be "gpio-led".
-- label : (optional) the label for this LED. If omitted, the label is
+- compatible : should be "gpio-leds".
+
+Each LED is represented as a sub-node of the gpio-leds device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+- gpios : Should specify the LED's GPIO, see "Specifying GPIO information
+ for devices" in Documentation/powerpc/booting-without-of.txt. Active
+ low LEDs should be indicated using flags in the GPIO specifier.
+- label : (optional) The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).
-- gpios : should specify LED GPIO.
+- linux,default-trigger : (optional) This parameter, if present, is a
+ string defining the trigger assigned to the LED. Current triggers are:
+"backlight" - LED will act as a back-light, controlled by the framebuffer
+ system
+"default-on" - LED will turn on
+"heartbeat" - LED "double" flashes at a load average based rate
+"ide-disk" - LED indicates disk activity
+"timer" - LED flashes at a fixed, configurable rate
-Example:
+Examples:
[EMAIL PROTECTED] {
- compatible = "gpio-led";
- label = "hdd";
- gpios = <&mcu_pio 0 1>;
+leds {
+ compatible = "gpio-leds";
+ hdd {
+ label = "IDE Activity";
+ gpios = <&mcu_pio 0 1>; /* Active low */
+ linux,default-trigger = "ide-disk";
+ };
};
+
+run-control {
+ compatible = "gpio-leds";
+ red {
+ gpios = <&mpc8572 6 0>;
+ };
+ green {
+ gpios = <&mpc8572 7 0>;
+ };
+}
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index e7fb7d2..6c6dc96 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -111,7 +111,26 @@ config LEDS_GPIO
help
This option enables support for the LEDs connected to GPIO
outputs. To be useful the particular board must have LEDs
- and they must be connected to the GPIO lines.
+ and they must be connected to the GPIO lines. The LEDs must be
+ defined as platform devices and/or OpenFirmware platform devices.
+ The code to use these bindings can be selected below.
+
+config LEDS_GPIO_PLATFORM
+ bool "Platform device bindings for GPIO LEDs"
+ depends on LEDS_GPIO
+ default y
+ help
+ Let the leds-gpio driver drive LEDs which have been defined as
+ platform devices. If you don't know what this means, say yes.
+
+config LEDS_GPIO_OF
+ bool "OpenFirmware platform device bindings for GPIO LEDs"
+ depends on LEDS_GPIO && OF_DEVICE
+ default y
+ help
+ Let the leds-gpio driver drive LEDs which have been defined as
+ of_platform devices. For instance, LEDs which are listed in a "dts"
+ file.
config LEDS_HP_DISK
tristate "LED Support for disk protection LED on HP notebooks"
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index b13bd29..f41b841 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2007 8D Technologies inc.
* Raphael Assenat <[EMAIL PROTECTED]>
+ * Copyright (C) 2008 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General
[PATCH 1/4] of_gpio: Return GPIO flags from of_get_gpio()
The device binding spec for OF GPIOs defines a flags field, but there is
currently no way to get it. This patch adds a parameter to of_get_gpio()
where the flags will be returned if non-NULL. of_get_gpio() in turn passes
the parameter to the of_gpio_chip's xlate method, which can extract any
flags present from the gpio_spec.
The default (and currently only) of_gpio_chip xlate method,
of_gpio_simple_xlate(), is modified to do this.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
drivers/mtd/nand/fsl_upm.c |2 +-
drivers/net/fs_enet/fs_enet-main.c |2 +-
drivers/net/phy/mdio-ofgpio.c |4 ++--
drivers/of/gpio.c | 13 ++---
drivers/serial/cpm_uart/cpm_uart_core.c |2 +-
include/linux/of_gpio.h | 17 +
6 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 024e3ff..a25d962 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -218,7 +218,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
fun->upm_cmd_offset = *prop;
- fun->rnb_gpio = of_get_gpio(ofdev->node, 0);
+ fun->rnb_gpio = of_get_gpio(ofdev->node, 0, NULL);
if (fun->rnb_gpio >= 0) {
ret = gpio_request(fun->rnb_gpio, ofdev->dev.bus_id);
if (ret) {
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index cb51c1f..5a3c7ee 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -994,7 +994,7 @@ static int __devinit find_phy(struct device_node *np,
goto out_put_phy;
}
- bus_id = of_get_gpio(mdionode, 0);
+ bus_id = of_get_gpio(mdionode, 0, NULL);
if (bus_id < 0) {
struct resource res;
ret = of_address_to_resource(mdionode, 0, &res);
diff --git a/drivers/net/phy/mdio-ofgpio.c b/drivers/net/phy/mdio-ofgpio.c
index 2ff9775..e3757c6 100644
--- a/drivers/net/phy/mdio-ofgpio.c
+++ b/drivers/net/phy/mdio-ofgpio.c
@@ -78,8 +78,8 @@ static int __devinit mdio_ofgpio_bitbang_init(struct mii_bus
*bus,
{
struct mdio_gpio_info *bitbang = bus->priv;
- bitbang->mdc = of_get_gpio(np, 0);
- bitbang->mdio = of_get_gpio(np, 1);
+ bitbang->mdc = of_get_gpio(np, 0, NULL);
+ bitbang->mdio = of_get_gpio(np, 1, NULL);
if (bitbang->mdc < 0 || bitbang->mdio < 0)
return -ENODEV;
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 7cd7301..2123517 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -22,11 +22,12 @@
* of_get_gpio - Get a GPIO number from the device tree to use with GPIO API
* @np:device node to get GPIO from
* @index: index of the GPIO
+ * @flags: GPIO's flags are returned here if non-NULL
*
* Returns GPIO number to use with Linux generic GPIO API, or one of the errno
* value on the error condition.
*/
-int of_get_gpio(struct device_node *np, int index)
+int of_get_gpio(struct device_node *np, int index, unsigned int *flags)
{
int ret;
struct device_node *gc;
@@ -59,7 +60,9 @@ int of_get_gpio(struct device_node *np, int index)
goto err1;
}
- ret = of_gc->xlate(of_gc, np, gpio_spec);
+ if (flags)
+ *flags = 0;
+ ret = of_gc->xlate(of_gc, np, gpio_spec, flags);
if (ret < 0)
goto err1;
@@ -77,19 +80,23 @@ EXPORT_SYMBOL(of_get_gpio);
* @of_gc: pointer to the of_gpio_chip structure
* @np:device node of the GPIO chip
* @gpio_spec: gpio specifier as found in the device tree
+ * @flags: if non-NUll flags are returned here
*
* This is simple translation function, suitable for the most 1:1 mapped
* gpio chips. This function performs only one sanity check: whether gpio
* is less than ngpios (that is specified in the gpio_chip).
*/
int of_gpio_simple_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
-const void *gpio_spec)
+const void *gpio_spec, unsigned int *flags)
{
const u32 *gpio = gpio_spec;
if (*gpio > of_gc->gc.ngpio)
return -EINVAL;
+ if (flags && of_gc->gpio_cells > 1)
+ *flags = gpio[1];
+
return *gpio;
}
EXPORT_SYMBOL(of_gpio_simple_xlate);
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index bde4b4b..7835cd4 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1094,7 +1094,7 @@ static int cpm_uart_init_port(struct device_node *np,
}
for (i = 0; i < NUM_GPIOS; i++)
- pinfo->gpios[i] = of_get_gpio(np, i);
+ pinfo->gpios[i] = of_get_gpio(np, i, NULL);
return cpm_uart_request_port(&pinfo->port);
diff --git a/include/
OpenFirmware GPIO LED driver
This series of patches adds support for OpenFirmware bindings for GPIO based LEDs. I last posted a version of this in July but discussion of the OF binding details didn't seem to be going anywhere. I've since been contacted by some people who are actually using the previous patches and have been motivated to try again. All the users of this code are satisfied with the current version and it does everything they need it to do. The first patch extends the of_get_gpio() function to provide the gpio flags. The way this already works (i.e., this is not something I'm adding, it's what's already there) is that the OF gpio specifier is an opaque sequence of words. The GPIO controller driver (of which only one currently exists) provides an ->xlate() method that turns this into a Linux gpiolib gpio number. All current gpio controllers have flags in their gpio specifier, but there is no way to get them. So I extend the xlate method to also produce the flags in a Linux format, the same way it produces a Linux gpio number. The second patch adds OF bindings to the gpio-leds driver. The existing code is refactored so that almost all of the common code is shared between the two binding methods. Either or both bindings can be selected via Kconfig. The bindings do have one "linux," property, but no one has been able to come up with something close to workable that avoids this and still satisfies the *requirement* that the default trigger be settable from the OF bindings. The second and third patches add some additional capabilities for gpio leds that some users need. One is to have a LED start in the on state when it's made known to Linux. There is already a "default-on" trigger that does this, but it produces a glitch where an LED that is already on will turn off then back on. My (tiny) patch avoids this problem. The next lets an LED stay, without glitches, in whatever state it was already in when it's made known to Linux. It may have been put into this state by the BIOS, firmware, bootloader, or the hardware itself. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.27-git7 compile error (ppc)
Rafael J. Wysocki wrote: On Friday, 17 of October 2008, Kumar Gala wrote: I've got a patch that seems to address this for me building w/ CONFIG_RELOCATABLE on ppc32/85xx. Has that been fixed in 2.6.27 and/or current mainline? I think CONFIG_RELOCATABLE was introduced post 2.6.27, so shouldn't be a problem in that version. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Fri, Oct 24, 2008 at 05:17:42PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
>> [...]
Would we suggest a node;
gpio-header {
compatible = "bplan,efika-gpio";
gpios = <&gpio-standard 16 0 17 0>;
};
gpio-header2 {
compatible = "bplan,efika-gpio-wkup";
gpios = <&gpio-wkup 18 0>;
};
>>> IMO this looks very reasonable. You properly describe the hardware:
>>> physical device (header) and its resources.
>>
>> If there are actually two headers, that is. If you use two nodes
>> just to specify which gpio is wkup, that is's a bit ugly... Why not
>>
>> gpio-header {
>> compatible = "bplan,-gpio-header";
>> gpios = <&standard 16 0
>> &standard 17 0
>> &wakeup 18 0>;
>> }
>>
>> And the driver whould know that on this particular
>> third gpio is the wakeup one?
>
> Good point, I concede to your much better plan :D
;-)
> Back to the other discussion, where we give individual GPIOs some
> names so they are detectable and not just programmable as a bank,
> do you have any ideas about that? :/
Pure GPIOs don't have names. But when you use bindings they
automatically translate to names. For example FHCI bindings:
[EMAIL PROTECTED] {
compatible = "fsl,mpc8360-qe-usb",
"fsl,mpc8323-qe-usb";
reg = <0x6c0 0x40 0x8b00 0x100>;
interrupts = <11>;
interrupt-parent = <&qeic>;
fsl,fullspeed-clock = "clk21";
fsl,lowspeed-clock = "brg9";
gpios = <&qe_pio_b 2 0 /* USBOE */
&qe_pio_b 3 0 /* USBTP */
&qe_pio_b 8 0 /* USBTN */
&qe_pio_b 9 0 /* USBRP */
&qe_pio_b 11 0 /* USBRN */
&bcsr135 0 /* SPEED */
&bcsr134 1>; /* POWER */
};
The bindings specify that gpios[0] (here qe_pio_b 2) is USBOE,
gpios[1] (here qe_pin_b 3) is USBTP, and so on.
There is nothing new in this. You can see the reg = <> property in
these bindings. It specify two regions: 0x6c0 0x40 - USB Regs
and 0x8b00 0x100 - USB parameter ram. Pure addresses don't have
names until bindings applied.
The same is for interrupts. Device may specify several interrupts:
enet0: [EMAIL PROTECTED] {
cell-index = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <32 0x8 33 0x8 34 0x8>;
interrupt-parent = <&ipic>;
phy-handle = <&phy1c>;
linux,network-index = <0>;
};
IRQ 32 is tx interrupt, IRQ33 is rx interrupt, and IRQ34 is
error-reporting interrupt.
But w/o any bindings nobody can tell what does IRQ33 mean (well,
actually we can tell it for ipic on this particular processor,
since it has hard-coded "SOC device<->irq" mapping. But it might
be not true for other controllers, or even ipic's external
interrupts).
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: GPIO - marking individual pins (not) available in device tree
> One thing I had a crazy dream about was a GUI-based device tree builder > for platforms. Instead of editing them manually and passing them > through the compiler, wouldn't it be fun to drag and drop system > components (and build new ones) into something like a DirectX Filter > Graph Builder (or the GStreamer one for that matter) or those GUI > SQL database builders, so that you could build a tree and have it > output all the craziness and connect phandles to range properties > etc. > > That way dropping a bunch of pins on a GPIO bank, or i2c devices > on an i2c bus (I have a board here with an i2c bus with 8 devices > on it, I suppose you could have more than 100 if you got your > addresses right) and having a device tree that goes on for 8 > screens would not be so bad to maintain. > > And no, I did NOT just volunteer to write one, I'm happy coding my > device tree updates in Forth :) > > -- > Matt Sealey <[EMAIL PROTECTED]> > Genesi, Manager, Developer Relations Why is this crazy? This is essentially what we do today with PowerPC and Microblaze processors in Xilinx FPGAs. Even for ASIC SOCs, there are several commercial 'connect-your-IP on the bus' tools that could (if SOC providers thought it was important) generate the 'canonical' device tree automagically. I think the real question is: if part of the device tree describes 'hardware' (either in the SOC or on the board that, more or less, doesn't change) and part represents 'hardware configuration' (e.g. My board has my one-off hardware hanging off the gpio bank connected to the 40 pin header), then how do we separate the two so that the hardware can be in a canonical form separate from the configuration. Or perhaps there are even three device tree fragments: one provided by an SOC provider, one by a board provider, and one by the user, which can all be nicely separated once the great device tree update happens... :) Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Anton Vorontsov wrote:
On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
[...]
Would we suggest a node;
gpio-header {
compatible = "bplan,efika-gpio";
gpios = <&gpio-standard 16 0 17 0>;
};
gpio-header2 {
compatible = "bplan,efika-gpio-wkup";
gpios = <&gpio-wkup 18 0>;
};
IMO this looks very reasonable. You properly describe the hardware:
physical device (header) and its resources.
If there are actually two headers, that is. If you use two nodes
just to specify which gpio is wkup, that is's a bit ugly... Why not
gpio-header {
compatible = "bplan,-gpio-header";
gpios = <&standard 16 0
&standard 17 0
&wakeup 18 0>;
}
And the driver whould know that on this particular
third gpio is the wakeup one?
Good point, I concede to your much better plan :D
Back to the other discussion, where we give individual GPIOs some
names so they are detectable and not just programmable as a bank,
do you have any ideas about that? :/
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
David Gibson wrote: Don't be patronising. There is an existing address space defined by the gpio binding. Defining another one is pointless redundancy. This is standard good ideas in computer science, no further argument necessary. The existing address space, and the patches Anton etc. just submitted which I started this discussion to address, don't fulfil certain needs. You could do better than call it insane, by describing how you would define a gpio bank that used 3 seperate pins which are NOT together in a register, using a base address (reg) and base property (offset of first pin) with the current system? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Mitch Bradley wrote:
[EMAIL PROTECTED] {
The name here should reflect the purpose of the pin, i.e. what it does
(perhaps "NAME,magic"), not the fact that is is GPIO pin. By analogy,
an ethernet controller's node name is "ethernet", not "pci-card". The
fact that the node represents one or more gpio pins is implicit and
obvious - all children of a gpio-controller node are gpio pin(s). All
children of a scsi node are SCSI devices, ad nauseum.
Right. I had a similar discussion about this the other day with Anton (I
think he forwarded it here but I wasn't subscribed at that point..). The
current ideology for device trees is to get rid of device_type for new
trees that aren't OF-based. I think it's relevant to give nodes fancy
names (i.e. not "timer" or even "ethernet") since the name property is
entirely descriptive in nature. I also think it's relevant that device_type
still exists because since the name is totally irrelevant except from a
user-friendliness point of view, marking a device as a generic type is
quite important (device_type = serial, ethernet, rtc, keyboard) where
compatible properties are usually wildly over-specific.
This reminded me of a discussion I had a long time back that encoding
the manufacturer and chip name into EVERY child node was bordering on
the insane (and if the dt wasn't compressed in the first place, wasting
space) - if you have /soc/usb and they have compatible="fsl,mpc5200b"
and "fsl,mpc5200b-usb-ohci" respectively, isn't that encoding redundant
information? Someone I think proposed assigning a couple of quirk
properties to notify drivers that fsl,mpc5200b-usb-ohci did things
differently because of the chip revision, and I was shot down when I
asked if the driver could just check it's parent node instead.
Apparently current ideology there is to have every node self-contained
(however the current practise in the Linux kernel, for example with
some PCI quirks, is to search for the parent PCI southbridge and check
off some values or disable features there, which I don't think is that
much different..)
Anyway back to the actual discussion, yes, I should have given it a
much fancier name than "gpio_pin" but at the time I wasn't thinking of
any particular use and didn't want to confuse by giving it a fancy
name like "sleep-controller-wakeup-pin".
It has been my experience that full explicit descriptions are usually a
win in the long run. (Which is not to say that I've always done the
right thing, but when I have it has often been worthwhile.)
In my view, having an overly descriptive and unwieldy device tree is
only bad when you type "ls" on the forth prompt and it scrolls off
the screen 8 times. At the driver level
One thing I had a crazy dream about was a GUI-based device tree builder
for platforms. Instead of editing them manually and passing them
through the compiler, wouldn't it be fun to drag and drop system
components (and build new ones) into something like a DirectX Filter
Graph Builder (or the GStreamer one for that matter) or those GUI
SQL database builders, so that you could build a tree and have it
output all the craziness and connect phandles to range properties
etc.
That way dropping a bunch of pins on a GPIO bank, or i2c devices
on an i2c bus (I have a board here with an i2c bus with 8 devices
on it, I suppose you could have more than 100 if you got your
addresses right) and having a device tree that goes on for 8
screens would not be so bad to maintain.
And no, I did NOT just volunteer to write one, I'm happy coding my
device tree updates in Forth :)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/40x: Don't enable HCU4 board by default
Am Freitag 24 Oktober 2008 16.31:58 schrieb Josh Boyer: > Fix the HCU4 Kconfig option to 'default n'. We don't want the > board to always be enabled for other board defconfigs. Sorry, for this silly mistake. Thanks for your fix. My board compiles and runs fine using Linus 2.6.28-rc1. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> > > --- > > diff --git a/arch/powerpc/platforms/40x/Kconfig > b/arch/powerpc/platforms/40x/Kconfig index 6573027..14e027f 100644 > --- a/arch/powerpc/platforms/40x/Kconfig > +++ b/arch/powerpc/platforms/40x/Kconfig > @@ -35,7 +35,7 @@ config EP405 > config HCU4 > bool "Hcu4" > depends on 40x > - default y > + default n > select 405GPR > help > This option enables support for the Nestal Maschinen HCU4 board. > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev Best regards Niklaus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [powerpc] GPIO: Adding new Xilinx driver
On Fri, Oct 24, 2008 at 3:41 PM, Anton Vorontsov <[EMAIL PROTECTED]> wrote: > On Fri, Oct 24, 2008 at 12:59:00PM -0700, John Linn wrote: >> This driver supports the Xilinx XPS GPIO IP core which has the typical >> GPIO features. >> >> Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]> >> Signed-off-by: John Linn <[EMAIL PROTECTED]> > > Looks good. Just few comments below. > > > If nothing has changed, we should place the arch-specific GPIO > drivers into the arch/. So, Kconfig entry should go into the > arch/powerpc/platforms/Kconfig. > > and the driver itself into arch/powerpc/sysdev/. This isn't just a powerpc driver. It is also used by microblaze so I'd like to keep it in the common directory (Microblaze is in the process of being reviewed for merging). Thanks for the comments. 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] [powerpc] GPIO: Adding new Xilinx driver
On Fri, Oct 24, 2008 at 12:59:00PM -0700, John Linn wrote:
> This driver supports the Xilinx XPS GPIO IP core which has the typical
> GPIO features.
>
> Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]>
> Signed-off-by: John Linn <[EMAIL PROTECTED]>
Looks good. Just few comments below.
> ---
> drivers/gpio/Kconfig |8 ++
> drivers/gpio/Makefile |1 +
> drivers/gpio/xilinx_gpio.c | 240
>
> 3 files changed, 249 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpio/xilinx_gpio.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 7f2ee27..f6b0da8 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -65,6 +65,14 @@ config GPIO_SYSFS
>
> # put expanders in the right section, in alphabetical order
>
> +comment "Memory mapped GPIO expanders:"
> +
> +config GPIO_XILINX
> + bool "Xilinx GPIO support"
> + depends on OF
I persume that the driver wasn't build-tested on SPARC, so I'd recommend
to change the depends to PPC_OF. Plus, the driver should also select
GENERIC_GPIO and ARCH_REQUIRE_GPIOLIB. (Later we'll switch to
ARCH_WANT_OPTIONAL_GPIOLIB for whole PPC.)
> + help
> + Say yes here to support the Xilinx FPGA GPIO device
If nothing has changed, we should place the arch-specific GPIO
drivers into the arch/. So, Kconfig entry should go into the
arch/powerpc/platforms/Kconfig.
and the driver itself into arch/powerpc/sysdev/.
> @@ -0,0 +1,240 @@
> +/*
> + * Xilinx gpio driver
> + *
> + * Copyright 2008 Xilinx, Inc.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
#include
#include
#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
[...]
> + spin_lock_init(&chip->gpio_lock);
> +
> + ofchip->gpio_cells = 2;
> + ofchip->gc.direction_input = xgpio_dir_in;
> + ofchip->gc.direction_output = xgpio_dir_out;
> + ofchip->gc.get = xgpio_get;
> + ofchip->gc.set = xgpio_set;
> +
> + /* Call the OF gpio helper to setup and register the GPIO device */
> + status = of_mm_gpiochip_add(ofdev->node, &chip->mmchip);
> + if (status) {
> + kfree(chip);
> + dev_err(&ofdev->dev, "Error in probe function error value %d\n",
> + status);
> + return status;
> + }
At this point the GPIO controller is registered, so somebody
might already request and work with the GPIOs...
> + /* Finally, write the initial state to the device */
> + out_be32(chip->mmchip.regs + XGPIO_DATA_OFFSET, chip->gpio_state);
> + out_be32(chip->mmchip.regs + XGPIO_TRI_OFFSET, chip->gpio_dir);
But initial values were set up just now, after the registration.
There is the `save_regs' callback in the of_mm_gpio_chip structure,
it is used exactly to avoid this situation.
> + dev_info(&ofdev->dev, "registered Xilinx GPIO controller\n");
> + return 0;
> +}
> +
> +/**
> + * xgpio_of_remove - Remove method for the GPIO device.
> + * @of_dev: pointer to OF device structure.
> + *
> + * This function returns a negative error as we cannot unregister GPIO chips.
> + */
> +static int __devexit xgpio_of_remove(struct of_device *ofdev)
> +{
> + return -EBUSY;
> +}
> +
> +static struct of_device_id xgpio_of_match[] __devinitdata = {
> + { .compatible = "xlnx,xps-gpio-1.00.a", },
> + { /* end of list */ },
> +};
> +
> +MODULE_DEVICE_TABLE(of, xgpio_of_match);
> +
> +static struct of_platform_driver xgpio_of_driver = {
There is no much point in doing the of_platform_driver for the
SOC GPIOs. More than that, of_platform bus is probed at the
device_initcall time, so there is also no point in the subsys_initcall
for this driver.
I'd recommend to do the registration as in
arch/powerpc/sysdev/qe_lib/gpio.c.
> + .name = "xilinx_gpio",
> + .match_table = xgpio_of_match,
> + .probe = xgpio_of_probe,
> + .remove = __devexit_p(xgpio_of_remove),
> +};
> +
> +static int __init xgpio_init(void)
> +{
> + return of_register_platform_driver(&xgpio_of_driver);
> +}
> +
> +/* Make sure we get initialized before anyone else tries to use us */
> +subsys_initcall(xgpio_init);
> +/* No exit call at the moment as we cannot unregister of GPIO chips */
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Added gpios property for SPI slaves
On Sat, 2008-10-25 at 01:10 +0400, Anton Vorontsov wrote: > On Fri, Oct 24, 2008 at 10:08:59PM +0200, Wolfgang Ocker wrote: > > SPI slave devices require the specification of a chip select address. > > This patch allows that specification using the gpios property. The reg > > property remains supported. > > Close, but no cigar. Sorry. ;-) The bindings are fine as is, you don't > need to change them. Oh, what a steep learning curve! Anyway, thank you for your guidance and patience! Looks like I have to adjust the SPI driver. Wolfgang ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Added gpios property for SPI slaves
On Fri, Oct 24, 2008 at 3:10 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> On Fri, Oct 24, 2008 at 10:08:59PM +0200, Wolfgang Ocker wrote:
>> SPI slave devices require the specification of a chip select address.
>> This patch allows that specification using the gpios property. The reg
>> property remains supported.
>>
>> Signed-off-by: Wolfgang Ocker <[EMAIL PROTECTED]>
>> ---
>>
>> --- linux-2.6.27.3/drivers/of/of_spi.c.of_spi_gpio2008-10-22
>> 23:38:01.0 +0200
>> +++ linux-2.6.27.3/drivers/of/of_spi.c.of_spi_cshigh 2008-10-24
>> 21:36:39.0 +0200
> [...]
>> --- linux-2.6.27.3/Documentation/powerpc/booting-without-of.txt.of_spi_gpio
>> 2008-10-22 23:38:01.0 +0200
>> +++
>> linux-2.6.27.3/Documentation/powerpc/booting-without-of.txt.of_spi_cshigh
>> 2008-10-24 21:57:16.0 +0200
>> @@ -1936,7 +1938,7 @@ platforms are moved over to use the flat
>> [EMAIL PROTECTED] {
>> compatible = "ti,tlv320aic26";
>> spi-max-frequency = <10>;
>> - reg = <1>;
>> + gpios = <&GPIO1 3>;
>> };
>> };
>
> Close, but no cigar. Sorry. ;-) The bindings are fine as is, you don't
> need to change them.
>
> The scheme should look like this:
>
> spi-controller {
>#address-cells = <1>;
>#size-cells = <0>;
>
>/* two GPIOs, representing two chip selects: 0 and 1 */
>gpios = <&pio 5 0 &pio 16 0>;
>
>[EMAIL PROTECTED] {
>reg = <0>;
>};
>
>[EMAIL PROTECTED] {
>reg = <1>;
>};
> }
>
> Notice that "gpios" is spi-controller's property, not spi devices'.
> It is truly as hardware works, SPI controllers consists of two units:
> I/O, and chip-select machine. Most spi controllers don't have
> dedicated chip-select machines, so they use GPIOs.
FWIW, I 100% agree.
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] Added gpios property for SPI slaves
On Fri, Oct 24, 2008 at 10:08:59PM +0200, Wolfgang Ocker wrote:
> SPI slave devices require the specification of a chip select address.
> This patch allows that specification using the gpios property. The reg
> property remains supported.
>
> Signed-off-by: Wolfgang Ocker <[EMAIL PROTECTED]>
> ---
>
> --- linux-2.6.27.3/drivers/of/of_spi.c.of_spi_gpio2008-10-22
> 23:38:01.0 +0200
> +++ linux-2.6.27.3/drivers/of/of_spi.c.of_spi_cshigh 2008-10-24
> 21:36:39.0 +0200
[...]
> --- linux-2.6.27.3/Documentation/powerpc/booting-without-of.txt.of_spi_gpio
> 2008-10-22 23:38:01.0 +0200
> +++ linux-2.6.27.3/Documentation/powerpc/booting-without-of.txt.of_spi_cshigh
> 2008-10-24 21:57:16.0 +0200
> @@ -1909,7 +1909,9 @@ platforms are moved over to use the flat
>
> SPI slave nodes must be children of the SPI master node and can
> contain the following properties.
> -- reg - (required) chip select address of device.
> +- reg - chip select address of device.
> +- gpios - chip select address of device (alternatively).
> + one of reg and gpios is required.
> - compatible - (required) name of SPI device following generic names
> recommended practice
> - spi-max-frequency - (required) Maximum SPI clocking speed of device in
> Hz
> @@ -1936,7 +1938,7 @@ platforms are moved over to use the flat
> [EMAIL PROTECTED] {
> compatible = "ti,tlv320aic26";
> spi-max-frequency = <10>;
> - reg = <1>;
> + gpios = <&GPIO1 3>;
> };
> };
Close, but no cigar. Sorry. ;-) The bindings are fine as is, you don't
need to change them.
The scheme should look like this:
spi-controller {
#address-cells = <1>;
#size-cells = <0>;
/* two GPIOs, representing two chip selects: 0 and 1 */
gpios = <&pio 5 0 &pio 16 0>;
[EMAIL PROTECTED] {
reg = <0>;
};
[EMAIL PROTECTED] {
reg = <1>;
};
}
Notice that "gpios" is spi-controller's property, not spi devices'.
It is truly as hardware works, SPI controllers consists of two units:
I/O, and chip-select machine. Most spi controllers don't have
dedicated chip-select machines, so they use GPIOs.
The spi controller driver should request all the specified gpios,
and then work with chip select numbers. Something like this:
struct spi_controller {
int *gpios;
unsigned int num_gpios;
...
}
int spi_set_chipselect(struct spi_controller *spi, int cs, int active)
{
/*
* chip-select is not necessary if there is just one device on
* the bus, so gpios = <> are not necessary either */
*/
if (!spi->num_gpios)
return 0;
if (cs > spi->num_gpios)
return -EINVAL;
gpio_set_value(spi->gpios[cs], active);
}
...
unsigned int of_num_gpios(struct device_node *node)
{
unsigned int num = 0;
while (gpio_is_valid(of_get_gpio(node, num)))
num++;
return num;
}
int spi_controller_probe(...)
{
spi_controller *spi;
...
spi->num_gpios = of_num_gpios(node);
if (spi->num_gpios) {
int i = spi->num_gpios;
spi->gpios = kzalloc(sizeof(int) * i, GFP_KERNEL);
if (!spi->gpios)
return -ENOMEM;
do
spi->gpios[i] = of_get_gpio(node, i);
while (!(i--));
}
...
}
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Added gpios property for SPI slaves
SPI slave devices require the specification of a chip select address.
This patch allows that specification using the gpios property. The reg
property remains supported.
Signed-off-by: Wolfgang Ocker <[EMAIL PROTECTED]>
---
--- linux-2.6.27.3/drivers/of/of_spi.c.of_spi_gpio 2008-10-22
23:38:01.0 +0200
+++ linux-2.6.27.3/drivers/of/of_spi.c.of_spi_cshigh2008-10-24
21:36:39.0 +0200
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/**
* of_register_spi_devices - Register child devices onto the SPI bus
@@ -24,6 +25,7 @@ void of_register_spi_devices(struct spi_
struct spi_device *spi;
struct device_node *nc;
const u32 *prop;
+ int cs_addr;
int rc;
int len;
@@ -48,13 +50,20 @@ void of_register_spi_devices(struct spi_
/* Device address */
prop = of_get_property(nc, "reg", &len);
- if (!prop || len < sizeof(*prop)) {
- dev_err(&master->dev, "%s has no 'reg' property\n",
- nc->full_name);
- spi_dev_put(spi);
- continue;
+ if (prop && len >= sizeof(*prop)) {
+ cs_addr = *prop;
+ }
+ else {
+ cs_addr = of_get_gpio(nc, 0);
+ if (cs_addr < 0) {
+ dev_err(&master->dev,
+ "%s has no 'reg' nor gpios property\n",
+ nc->full_name);
+ spi_dev_put(spi);
+ continue;
+ }
}
- spi->chip_select = *prop;
+ spi->chip_select = cs_addr;
/* Mode (clock phase/polarity/etc.) */
if (of_find_property(nc, "spi-cpha", NULL))
--- linux-2.6.27.3/Documentation/powerpc/booting-without-of.txt.of_spi_gpio
2008-10-22 23:38:01.0 +0200
+++ linux-2.6.27.3/Documentation/powerpc/booting-without-of.txt.of_spi_cshigh
2008-10-24 21:57:16.0 +0200
@@ -1909,7 +1909,9 @@ platforms are moved over to use the flat
SPI slave nodes must be children of the SPI master node and can
contain the following properties.
-- reg - (required) chip select address of device.
+- reg - chip select address of device.
+- gpios - chip select address of device (alternatively).
+ one of reg and gpios is required.
- compatible - (required) name of SPI device following generic names
recommended practice
- spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
@@ -1936,7 +1938,7 @@ platforms are moved over to use the flat
[EMAIL PROTECTED] {
compatible = "ti,tlv320aic26";
spi-max-frequency = <10>;
- reg = <1>;
+ gpios = <&GPIO1 3>;
};
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [powerpc] GPIO: Adding new Xilinx driver
On Fri, Oct 24, 2008 at 1:59 PM, John Linn <[EMAIL PROTECTED]> wrote:
> This driver supports the Xilinx XPS GPIO IP core which has the typical
> GPIO features.
>
> Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]>
> Signed-off-by: John Linn <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
> ---
> drivers/gpio/Kconfig |8 ++
> drivers/gpio/Makefile |1 +
> drivers/gpio/xilinx_gpio.c | 240
>
> 3 files changed, 249 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpio/xilinx_gpio.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 7f2ee27..f6b0da8 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -65,6 +65,14 @@ config GPIO_SYSFS
>
> # put expanders in the right section, in alphabetical order
>
> +comment "Memory mapped GPIO expanders:"
> +
> +config GPIO_XILINX
> + bool "Xilinx GPIO support"
> + depends on OF
> + help
> + Say yes here to support the Xilinx FPGA GPIO device
> +
> comment "I2C GPIO expanders:"
>
> config GPIO_MAX732X
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 6aafdeb..49ac64e 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -10,4 +10,5 @@ obj-$(CONFIG_GPIO_MCP23S08) += mcp23s08.o
> obj-$(CONFIG_GPIO_PCA953X) += pca953x.o
> obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
> obj-$(CONFIG_GPIO_TWL4030) += twl4030-gpio.o
> +obj-$(CONFIG_GPIO_XILINX) += xilinx_gpio.o
> obj-$(CONFIG_GPIO_BT8XX) += bt8xxgpio.o
> diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
> new file mode 100644
> index 000..224d0d5
> --- /dev/null
> +++ b/drivers/gpio/xilinx_gpio.c
> @@ -0,0 +1,240 @@
> +/*
> + * Xilinx gpio driver
> + *
> + * Copyright 2008 Xilinx, Inc.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Register Offset Definitions */
> +#define XGPIO_DATA_OFFSET (0x0) /* Data register */
> +#define XGPIO_TRI_OFFSET(0x4) /* I/O direction register */
> +
> +struct xgpio_instance {
> + struct of_mm_gpio_chip mmchip;
> + u32 gpio_state; /* GPIO state shadow register */
> + u32 gpio_dir; /* GPIO direction shadow register */
> + spinlock_t gpio_lock; /* Lock used for synchronization */
> +};
> +
> +/**
> + * xgpio_get - Read the specified signal of the GPIO device.
> + * @gc: Pointer to gpio_chip device structure.
> + * @gpio: GPIO signal number.
> + *
> + * This function reads the specified signal of the GPIO device. It returns 0
> if
> + * the signal clear, 1 if signal is set or negative value on error.
> + */
> +static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> +
> + return (in_be32(mm_gc->regs + XGPIO_DATA_OFFSET) >> gpio) & 1;
> +}
> +
> +/**
> + * xgpio_set - Write the specified signal of the GPIO device.
> + * @gc: Pointer to gpio_chip device structure.
> + * @gpio: GPIO signal number.
> + * @val:Value to be written to specified signal.
> + *
> + * This function writes the specified value in to the specified signal of the
> + * GPIO device.
> + */
> +static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + unsigned long flags;
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct xgpio_instance *chip =
> + container_of(mm_gc, struct xgpio_instance, mmchip);
> +
> + spin_lock_irqsave(&chip->gpio_lock, flags);
> +
> + /* Write to GPIO signal and set its direction to output */
> + if (val)
> + chip->gpio_state |= 1 << gpio;
> + else
> + chip->gpio_state &= ~(1 << gpio);
> + out_be32(mm_gc->regs + XGPIO_DATA_OFFSET, chip->gpio_state);
> +
> + spin_unlock_irqrestore(&chip->gpio_lock, flags);
> +}
> +
> +/**
> + * xgpio_dir_in - Set the direction of the specified GPIO signal as input.
> + * @gc: Pointer to gpio_chip device structure.
> + * @gpio: GPIO signal number.
> + *
> + * This function sets the direction of specified GPIO signal as input.
> + * It returns 0 if direction of GPIO signals is set as input otherwise it
> + * returns negative error value.
> + */
> +static int xgpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> +{
> + unsigned long flags;
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct xgpio_instance *chip =
> + container_of(mm_gc, struct x
[PATCH] [powerpc] GPIO: Adding new Xilinx driver
This driver supports the Xilinx XPS GPIO IP core which has the typical
GPIO features.
Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]>
Signed-off-by: John Linn <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig |8 ++
drivers/gpio/Makefile |1 +
drivers/gpio/xilinx_gpio.c | 240
3 files changed, 249 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/xilinx_gpio.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 7f2ee27..f6b0da8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -65,6 +65,14 @@ config GPIO_SYSFS
# put expanders in the right section, in alphabetical order
+comment "Memory mapped GPIO expanders:"
+
+config GPIO_XILINX
+ bool "Xilinx GPIO support"
+ depends on OF
+ help
+ Say yes here to support the Xilinx FPGA GPIO device
+
comment "I2C GPIO expanders:"
config GPIO_MAX732X
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6aafdeb..49ac64e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_GPIO_MCP23S08) += mcp23s08.o
obj-$(CONFIG_GPIO_PCA953X) += pca953x.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
obj-$(CONFIG_GPIO_TWL4030) += twl4030-gpio.o
+obj-$(CONFIG_GPIO_XILINX) += xilinx_gpio.o
obj-$(CONFIG_GPIO_BT8XX) += bt8xxgpio.o
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
new file mode 100644
index 000..224d0d5
--- /dev/null
+++ b/drivers/gpio/xilinx_gpio.c
@@ -0,0 +1,240 @@
+/*
+ * Xilinx gpio driver
+ *
+ * Copyright 2008 Xilinx, Inc.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* Register Offset Definitions */
+#define XGPIO_DATA_OFFSET (0x0) /* Data register */
+#define XGPIO_TRI_OFFSET(0x4) /* I/O direction register */
+
+struct xgpio_instance {
+ struct of_mm_gpio_chip mmchip;
+ u32 gpio_state; /* GPIO state shadow register */
+ u32 gpio_dir; /* GPIO direction shadow register */
+ spinlock_t gpio_lock; /* Lock used for synchronization */
+};
+
+/**
+ * xgpio_get - Read the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function reads the specified signal of the GPIO device. It returns 0 if
+ * the signal clear, 1 if signal is set or negative value on error.
+ */
+static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+
+ return (in_be32(mm_gc->regs + XGPIO_DATA_OFFSET) >> gpio) & 1;
+}
+
+/**
+ * xgpio_set - Write the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ * @val:Value to be written to specified signal.
+ *
+ * This function writes the specified value in to the specified signal of the
+ * GPIO device.
+ */
+static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ unsigned long flags;
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct xgpio_instance *chip =
+ container_of(mm_gc, struct xgpio_instance, mmchip);
+
+ spin_lock_irqsave(&chip->gpio_lock, flags);
+
+ /* Write to GPIO signal and set its direction to output */
+ if (val)
+ chip->gpio_state |= 1 << gpio;
+ else
+ chip->gpio_state &= ~(1 << gpio);
+ out_be32(mm_gc->regs + XGPIO_DATA_OFFSET, chip->gpio_state);
+
+ spin_unlock_irqrestore(&chip->gpio_lock, flags);
+}
+
+/**
+ * xgpio_dir_in - Set the direction of the specified GPIO signal as input.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function sets the direction of specified GPIO signal as input.
+ * It returns 0 if direction of GPIO signals is set as input otherwise it
+ * returns negative error value.
+ */
+static int xgpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ unsigned long flags;
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct xgpio_instance *chip =
+ container_of(mm_gc, struct xgpio_instance, mmchip);
+
+ spin_lock_irqsave(&chip->gpio_lock, flags);
+
+ /* Set the GPIO bit in shadow register and set direction as input */
+ chip->gpio_dir |= (1 << gpio);
+ out_be32(mm_gc->regs + XGPIO_TRI_OFFSET, chip->gpio_dir);
+
+ spin_unlock_irqrestore(&chip->gpio_lock, flags);
+
+ return 0;
+}
+
+/**
+ * xgpio_dir_out - Set the direct
Re: [PATCH] ehea: Add hugepage detection
On Fri, 2008-10-24 at 13:07 +0200, Thomas Klein wrote:
> 16GB hugepages may not be part of a memory region (firmware restriction).
> This patch
> modifies the walk_memory_resource callback fn to filter hugepages and add
> only standard
> memory to the busmap which is later on used for MR registration.
Does this support a case where a userspace app is reading network
packets into a 16GB page backed area? I think you need to elaborate on
what kind of memory you need to have registered in these memory regions.
It's hard to review what you've done here otherwise.
> --- linux-2.6.27/drivers/net/ehea/ehea_qmr.c 2008-10-24 09:29:19.0
> +0200
> +++ patched_kernel/drivers/net/ehea/ehea_qmr.c2008-10-24
> 09:45:15.0 +0200
> @@ -636,6 +636,9 @@ static int ehea_update_busmap(unsigned l
> {
> unsigned long i, start_section, end_section;
>
> + if (!pgnum)
> + return 0;
This probably needs a comment. It's not obvious what it is doing.
> if (!ehea_bmap) {
> ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL);
> if (!ehea_bmap)
> @@ -692,10 +695,47 @@ int ehea_rem_sect_bmap(unsigned long pfn
> return ret;
> }
>
> -static int ehea_create_busmap_callback(unsigned long pfn,
> -unsigned long nr_pages, void *arg)
> +static int ehea_is_hugepage(unsigned long pfn)
> +{
> + return pfn << PAGE_SHIFT) & (EHEA_HUGEPAGE_SIZE - 1)) == 0)
> + && (compound_order(pfn_to_page(pfn)) + PAGE_SHIFT
> + == EHEA_HUGEPAGESHIFT) );
> +}
Whoa. That's dense. Can you actually read that in less than 5 minutes?
Seriously.
I'm not sure what else you use EHEA_HUGEPAGE_SIZE for or if this gets
duplicated, but this would look nicer if you just had a:
#define EHEA_HUGEPAGE_PFN_MASK ((EHEA_HUGEPAGE_SIZE - 1) >> PAGE_SHIFT)
if (pfn & EHEA_HUGEPAGE_PFN_MASK)
return 0;
Or, with no new macro:
if ((pfn << PAGE_SHIFT) & (EHEA_HUGEPAGE_SIZE - 1) != 0)
return 0;
page_order = compound_order(pfn_to_page(pfn));
if (page_order + PAGE_SHIFT != EHEA_HUGEPAGESHIFT)
return 0;
return 1;
}
Please break that up into something that is truly readable. gcc will
generate the exact same code.
> +static int ehea_create_busmap_callback(unsigned long initial_pfn,
> +unsigned long total_nr_pages, void *arg)
> {
> - return ehea_update_busmap(pfn, nr_pages, EHEA_BUSMAP_ADD_SECT);
> + int ret;
> + unsigned long pfn, start_pfn, end_pfn, nr_pages;
> +
> + if ((total_nr_pages * PAGE_SIZE) < EHEA_HUGEPAGE_SIZE)
> + return ehea_update_busmap(initial_pfn, total_nr_pages,
> + EHEA_BUSMAP_ADD_SECT);
> +
> + /* Given chunk is >= 16GB -> check for hugepages */
> + start_pfn = initial_pfn;
> + end_pfn = initial_pfn + total_nr_pages;
> + pfn = start_pfn;
> +
> + while (pfn < end_pfn) {
> + if (ehea_is_hugepage(pfn)) {
> + /* Add mem found in front of the hugepage */
> + nr_pages = pfn - start_pfn;
> + ret = ehea_update_busmap(start_pfn, nr_pages,
> + EHEA_BUSMAP_ADD_SECT);
> + if (ret)
> + return ret;
> +
> + /* Skip the hugepage */
> + pfn += (EHEA_HUGEPAGE_SIZE / PAGE_SIZE);
> + start_pfn = pfn;
> + } else
> + pfn += (EHEA_SECTSIZE / PAGE_SIZE);
> + }
> +
> + /* Add mem found behind the hugepage(s) */
> + nr_pages = pfn - start_pfn;
> + return ehea_update_busmap(start_pfn, nr_pages, EHEA_BUSMAP_ADD_SECT);
> }
>
> int ehea_create_busmap(void)
> diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_qmr.h
> patched_kernel/drivers/net/ehea/ehea_qmr.h
> --- linux-2.6.27/drivers/net/ehea/ehea_qmr.h 2008-10-24 09:29:19.0
> +0200
> +++ patched_kernel/drivers/net/ehea/ehea_qmr.h2008-10-24
> 09:45:15.0 +0200
> @@ -40,6 +40,8 @@
> #define EHEA_PAGESIZE (1UL << EHEA_PAGESHIFT)
> #define EHEA_SECTSIZE (1UL << 24)
> #define EHEA_PAGES_PER_SECTION (EHEA_SECTSIZE >> EHEA_PAGESHIFT)
> +#define EHEA_HUGEPAGESHIFT 34
> +#define EHEA_HUGEPAGE_SIZE (1UL << EHEA_HUGEPAGESHIFT)
I'm a bit worried that you're basically duplicating hugetlb.h here. Why
not just use the existing 16GB page macros? While you're at it please
expand these to give some more useful macros so you don't have to do
arithmetic on them in the code as much.
#define EHEA_SECT_NR_PAGES (EHEA_SECTSIZE / PAGE_SIZE)
for instance.
-- Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[Cbe-oss-dev] [PATCH] Cell OProfile: Incorrect local array size in activate spu profiling function
The size of the pm_signal_local array should be equal to the
number of SPUs being configured in the call. Currently, the
array is of size 4 (NR_PHYS_CTRS) but being indexed by a for
loop from 0 to 7 (NUM_SPUS_PER_NODE).
Signed-off-by: Carl Love <[EMAIL PROTECTED]>
Index: Cell_kernel_10_24_2008/arch/powerpc/oprofile/op_model_cell.c
===
--- Cell_kernel_10_24_2008.orig/arch/powerpc/oprofile/op_model_cell.c
+++ Cell_kernel_10_24_2008/arch/powerpc/oprofile/op_model_cell.c
@@ -830,7 +830,7 @@ static int calculate_lfsr(int n)
static int pm_rtas_activate_spu_profiling(u32 node)
{
int ret, i;
- struct pm_signal pm_signal_local[NR_PHYS_CTRS];
+ struct pm_signal pm_signal_local[NUM_SPUS_PER_NODE];
/*
* Set up the rtas call to configure the debug bus to
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Chris Snook wrote: Scott Wood wrote: Kumar Gala wrote: So why not just have x86 startup code set irq_default_affinity = CPU_MASK_ALL than? That doesn't really solve the problem, as a user could still manually set an invalid affinity. The MPIC driver should reduce the affinity itself to what the hardware can handle. Does the MPIC code actually allow that to happen? As far as I can tell, though I haven't tested it. I can't quite tell, but I noticed this: [EMAIL PROTECTED] sysdev]$ fgrep '#ifdef CONFIG_' mpic.c | sort -u #ifdef CONFIG_IRQ_ALL_CPUS #ifdef CONFIG_MPIC_BROKEN_REGREAD #ifdef CONFIG_MPIC_U3_HT_IRQS #ifdef CONFIG_MPIC_WEIRD #ifdef CONFIG_PCI_MSI #ifdef CONFIG_PM #ifdef CONFIG_PPC32 /* XXX for now */ #ifdef CONFIG_PPC_DCR #ifdef CONFIG_SMP Do any of those config options (or combinations thereof) imply an MPIC that can't handle an IRQ masked to multiple CPUs? If so, this can be fixed rather easily at build time, without having to muck around with arch-specific initialization code. I don't think so, and in any case it should be detected at runtime from the device tree. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix i2c on PPC linkstation / kurobox machines
On Fri, 24 Oct 2008, Benjamin Herrenschmidt wrote: > On Fri, 2008-10-24 at 01:05 +0200, Guennadi Liakhovetski wrote: > > i2c is broken on linkstation / kurobox machines since at least 2.6.27. Fix > > it. Also remove CONFIG_SERIAL_OF_PLATFORM, which, if enabled, breaks the > > serial console after the "console handover: boot [udbg0] -> real [ttyS1]" > > message. > > > > Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> > > You may want to use udbg_printf() to track down what's up. There's some > fishy code there indeed, what happens is that the legacy serial code > creates a platform device at boot time. Then, the of_serial attaches to > the device node for the same device and tries to register it. It's > supposed to "detect" that it's the same device but yeah, it may be > buggy, I've seen problems with it in the past, among others, I think it > can lose some state. > > In the meantime, removing SERIAL_OF_PLATFORM is a good solution. > > Ben. I think, this needs an acked-by for -stable. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Scott Wood wrote: Kumar Gala wrote: So why not just have x86 startup code set irq_default_affinity = CPU_MASK_ALL than? That doesn't really solve the problem, as a user could still manually set an invalid affinity. The MPIC driver should reduce the affinity itself to what the hardware can handle. Does the MPIC code actually allow that to happen? I can't quite tell, but I noticed this: [EMAIL PROTECTED] sysdev]$ fgrep '#ifdef CONFIG_' mpic.c | sort -u #ifdef CONFIG_IRQ_ALL_CPUS #ifdef CONFIG_MPIC_BROKEN_REGREAD #ifdef CONFIG_MPIC_U3_HT_IRQS #ifdef CONFIG_MPIC_WEIRD #ifdef CONFIG_PCI_MSI #ifdef CONFIG_PM #ifdef CONFIG_PPC32 /* XXX for now */ #ifdef CONFIG_PPC_DCR #ifdef CONFIG_SMP Do any of those config options (or combinations thereof) imply an MPIC that can't handle an IRQ masked to multiple CPUs? If so, this can be fixed rather easily at build time, without having to muck around with arch-specific initialization code. -- Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: Specify GPIO number base for controller in DT
On Fri, 2008-10-24 at 11:12 -0600, Grant Likely wrote: > On Fri, Oct 24, 2008 at 10:54 AM, Anton Vorontsov > <[EMAIL PROTECTED]> wrote: > > On Thu, Oct 23, 2008 at 08:13:00PM +0200, Stefan Roese wrote: > >> On Thursday 23 October 2008, Wolfgang Ocker wrote: > >> > The GPIOLIB allows the specification of a base gpio number for a > >> > controller. That is not possible using OF. Instead, free gpio numbers > >> > are assigned. > >> > > >> > In order to allow static, predefined gpio numbers, a base property in > >> > the gpio controller node specifies the first gpio number. > >> > > >> > v2, v3: added/improved description of base property in doc > >> > >> These version descriptions are better placed below the "---" line. And you > >> should remove the "Re: " from the subject line. Other than this: > >> > >> Acked-by: Stefan Roese <[EMAIL PROTECTED]> > Yeah, I don't like this patch either. GPIO numbering is a Linux > internal detail and has no bearing on the hardware description. If > you need to know what a particular gpio number is then it should be > resolved by finding the device tree node; not by trying to fix a GPIO > controller to a particular number. Okay, now I think I understand. I'll try to solve the chip select pin addressing in the spi driver differently. Thank you guys! Wolfgang ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Kumar Gala wrote: On Oct 24, 2008, at 11:09 AM, Chris Snook wrote: Kumar Gala wrote: On Oct 24, 2008, at 10:17 AM, Chris Snook wrote: Kumar Gala wrote: It appears the default IRQ affinity changes from being just cpu 0 to all cpu's. This breaks several PPC SMP systems in which only a single processor is allowed to be selected as the destination of the IRQ. What is the right answer in fixing this? Should we: cpumask_t irq_default_affinity = 1; instead of cpumask_t irq_default_affinity = CPU_MASK_ALL? On those systems, perhaps, but not universally. There's plenty of hardware where the physical topology of the machine is abstracted away from the OS, and you need to leave the mask wide open and let the APIC figure out where to map the IRQs. Ideally, we should probably make this decision based on the APIC, but if there's no PPC hardware that uses this technique, then it would suffice to make this arch-specific. What did those systems do before this patch? Its one thing to expose a mask in the ability to change the default mask in /proc/irq/default_smp_affinity. Its another (and a regression in my opinion) to change the mask value itself. Before the patch they took an extremely long time to boot if they had storage attached to each node of a multi-chassis system, performed poorly unless special irqbalance hackery or manual assignment was used, and imposed artificial restrictions on the granularity of hardware partitioning to ensure that CPU 0 would always be a CPU that could service all interrupts necessary to boot the OS. As for making it ARCH specific, that doesn't really help since not all PPC hw has the limitation I spoke of. Not even all MPIC (in our cases) have the limitation. What did those systems do before this patch? :) Making it arch-specific is an extremely simple way to solve your problem without making trouble for the people who wanted this patch in the first place. If PPC needs further refinement to handle particular *PICs, you can implement that without touching any arch-generic code. So why not just have x86 startup code set irq_default_affinity = CPU_MASK_ALL than? It's an issue on Itanium as well, and potentially any SMP architecture with a non-trivial interconnect. -- Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Kumar Gala wrote: So why not just have x86 startup code set irq_default_affinity = CPU_MASK_ALL than? That doesn't really solve the problem, as a user could still manually set an invalid affinity. The MPIC driver should reduce the affinity itself to what the hardware can handle. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: Specify GPIO number base for controller in DT
On Fri, Oct 24, 2008 at 10:54 AM, Anton Vorontsov <[EMAIL PROTECTED]> wrote: > On Thu, Oct 23, 2008 at 08:13:00PM +0200, Stefan Roese wrote: >> On Thursday 23 October 2008, Wolfgang Ocker wrote: >> > The GPIOLIB allows the specification of a base gpio number for a >> > controller. That is not possible using OF. Instead, free gpio numbers >> > are assigned. >> > >> > In order to allow static, predefined gpio numbers, a base property in >> > the gpio controller node specifies the first gpio number. >> > >> > v2, v3: added/improved description of base property in doc >> >> These version descriptions are better placed below the "---" line. And you >> should remove the "Re: " from the subject line. Other than this: >> >> Acked-by: Stefan Roese <[EMAIL PROTECTED]> > > Please-defer-this-patch-by: Anton Vorontsov <[EMAIL PROTECTED]> > > Wolfgang, Stefan, see this comment: > > http://ozlabs.org/pipermail/linuxppc-dev/2008-October/064505.html > > ..just tell me what are you trying to solve. Yeah, I don't like this patch either. GPIO numbering is a Linux internal detail and has no bearing on the hardware description. If you need to know what a particular gpio number is then it should be resolved by finding the device tree node; not by trying to fix a GPIO controller to a particular number. 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: GPIO - marking individual pins (not) available in device tree
On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
[...]
> > So, how do we define in a bank of GPIOs, which ones are free for use,
> > without them being attached to a device and given as a "gpios" property?
> >
> > Would we suggest a node;
> >
> > gpio-header {
> > compatible = "bplan,efika-gpio";
> > gpios = <&gpio-standard 16 0 17 0>;
> > };
> >
> > gpio-header2 {
> > compatible = "bplan,efika-gpio-wkup";
> > gpios = <&gpio-wkup 18 0>;
> > };
>
> IMO this looks very reasonable. You properly describe the hardware:
> physical device (header) and its resources.
If there are actually two headers, that is. If you use two nodes
just to specify which gpio is wkup, that is's a bit ugly... Why not
gpio-header {
compatible = "bplan,-gpio-header";
gpios = <&standard 16 0
&standard 17 0
&wakeup 18 0>;
}
And the driver whould know that on this particular
third gpio is the wakeup one?
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] a little disassembly infrastructure
Hi, I wrote this patch for KVM [1], but now that I look closer it seems
like there might be some overlapping functionality.
First there's emulate_instruction(), but since that only handles a few
instructions it's just an ordered list of if ((instruction & MASK_A) ==
INST_A) tests, so it doesn't actually parse out opcodes or anything.
I've also found xmon's ppc-opc.c. That parses the opcode and operands,
so could use some shared macros. Of course, the actual lookup isn't
time-sensitive, so that doesn't make sense to share. On the other hand,
if we do come up with something fast *and* robust for KVM, maybe xmon
could use that.
Of course, these macros alone is pretty small, so maybe it's not a big
deal to make a kvm-specific copy of them, leaving the other uses alone.
Comments?
[1] KVM on PowerPC traps when privileged instructions are executed in
the guest context. We must then (quickly!) disassemble them and emulate
their behavior. Right now we do this with a giant switch statement or
two, but are considering more sophisticated techniques in the future.
--
Hollis Blanchard
IBM Linux Technology Center
ppc: Create disassemble.h to extract instruction fields
This is used in a couple places in KVM, but isn't KVM-specific.
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/include/asm/disassemble.h b/arch/powerpc/include/asm/disassemble.h
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/include/asm/disassemble.h
@@ -0,0 +1,80 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * Authors: Hollis Blanchard <[EMAIL PROTECTED]>
+ */
+
+#ifndef __ASM_PPC_DISASSEMBLE_H__
+#define __ASM_PPC_DISASSEMBLE_H__
+
+#include
+
+static inline unsigned int get_op(u32 inst)
+{
+ return inst >> 26;
+}
+
+static inline unsigned int get_xop(u32 inst)
+{
+ return (inst >> 1) & 0x3ff;
+}
+
+static inline unsigned int get_sprn(u32 inst)
+{
+ return ((inst >> 16) & 0x1f) | ((inst >> 6) & 0x3e0);
+}
+
+static inline unsigned int get_dcrn(u32 inst)
+{
+ return ((inst >> 16) & 0x1f) | ((inst >> 6) & 0x3e0);
+}
+
+static inline unsigned int get_rt(u32 inst)
+{
+ return (inst >> 21) & 0x1f;
+}
+
+static inline unsigned int get_rs(u32 inst)
+{
+ return (inst >> 21) & 0x1f;
+}
+
+static inline unsigned int get_ra(u32 inst)
+{
+ return (inst >> 16) & 0x1f;
+}
+
+static inline unsigned int get_rb(u32 inst)
+{
+ return (inst >> 11) & 0x1f;
+}
+
+static inline unsigned int get_rc(u32 inst)
+{
+ return inst & 0x1;
+}
+
+static inline unsigned int get_ws(u32 inst)
+{
+ return (inst >> 11) & 0x1f;
+}
+
+static inline unsigned int get_d(u32 inst)
+{
+ return inst & 0x;
+}
+
+#endif /* __ASM_PPC_DISASSEMBLE_H__ */
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -28,62 +28,7 @@
#include
#include
#include
-
-/* Instruction decoding */
-static inline unsigned int get_op(u32 inst)
-{
- return inst >> 26;
-}
-
-static inline unsigned int get_xop(u32 inst)
-{
- return (inst >> 1) & 0x3ff;
-}
-
-static inline unsigned int get_sprn(u32 inst)
-{
- return ((inst >> 16) & 0x1f) | ((inst >> 6) & 0x3e0);
-}
-
-static inline unsigned int get_dcrn(u32 inst)
-{
- return ((inst >> 16) & 0x1f) | ((inst >> 6) & 0x3e0);
-}
-
-static inline unsigned int get_rt(u32 inst)
-{
- return (inst >> 21) & 0x1f;
-}
-
-static inline unsigned int get_rs(u32 inst)
-{
- return (inst >> 21) & 0x1f;
-}
-
-static inline unsigned int get_ra(u32 inst)
-{
- return (inst >> 16) & 0x1f;
-}
-
-static inline unsigned int get_rb(u32 inst)
-{
- return (inst >> 11) & 0x1f;
-}
-
-static inline unsigned int get_rc(u32 inst)
-{
- return inst & 0x1;
-}
-
-static inline unsigned int get_ws(u32 inst)
-{
- return (inst >> 11) & 0x1f;
-}
-
-static inline unsigned int get_d(u32 inst)
-{
- return inst & 0x;
-}
+#include
static void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: Specify GPIO number base for controller in DT
On Thu, Oct 23, 2008 at 08:13:00PM +0200, Stefan Roese wrote: > On Thursday 23 October 2008, Wolfgang Ocker wrote: > > The GPIOLIB allows the specification of a base gpio number for a > > controller. That is not possible using OF. Instead, free gpio numbers > > are assigned. > > > > In order to allow static, predefined gpio numbers, a base property in > > the gpio controller node specifies the first gpio number. > > > > v2, v3: added/improved description of base property in doc > > These version descriptions are better placed below the "---" line. And you > should remove the "Re: " from the subject line. Other than this: > > Acked-by: Stefan Roese <[EMAIL PROTECTED]> Please-defer-this-patch-by: Anton Vorontsov <[EMAIL PROTECTED]> Wolfgang, Stefan, see this comment: http://ozlabs.org/pipermail/linuxppc-dev/2008-October/064505.html ..just tell me what are you trying to solve. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Specify GPIO number base for controller in DT
On Thu, Oct 23, 2008 at 02:27:30PM +0200, Wolfgang Ocker wrote: > The GPIOLIB allows the specification of a base gpio number for a > controller. That is not possible using OF. Instead, free gpio numbers > are assigned. > > In order to allow static, predefined gpio numbers, a base property in > the gpio controller node specifies the first gpio number. > > Signed-off-by: Wolfgang Ocker <[EMAIL PROTECTED]> [...] > --- > linux-2.6.27-rc7/Documentation/powerpc/booting-without-of.txt.spi_gpio_doc > 2008-09-29 14:14:08.0 +0200 > +++ linux-2.6.27-rc7/Documentation/powerpc/booting-without-of.txt > 2008-09-29 14:24:26.0 +0200 > @@ -2586,6 +2588,7 @@ > #gpio-cells = <2>; > compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank"; > reg = <0x1400 0x18>; > + base = < 0x20 >; The base has nothing to do with the hardware description, thus device tree should not include it. Why exactly you need this? I'm sure there is another way to solve the problem (whatever it is). -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Thu, Oct 23, 2008 at 04:32:49PM -0500, Matt Sealey wrote:
> Hi guys,
>
> I'm a little perplexed as to how I would define a GPIO controller in a
> device tree but mark off pins as available or not, so users can geek
> around in their own drivers without defining in a device tree exactly
> what they intend to use it for (especially if it's something really
> weird).
>
> Easiest example - the Efika runs an MPC5200B has 3 GPIO pins on the
> board. It's not much, but they're there for use. All the other GPIOs are
> absolutely out of bounds, off limits and probably dangerous to touch, but
> since each GPIO block has a 32-bit register to handle them, you can
> twiddle any bit you like with impunity and cause all the damage you want.
> A simple thought comes to mind in that the gpiolib should not allow a
> request for one of these "bad" GPIO pins to succeed.
Well, the same applies to the IRQ controllers. I bet you can request a
reserved IRQ on some particular board/CPU, but results would be
unpredictable (the driver would touch reserved bits etc). The device
tree should be sane for this particular platform and not specify bogus
gpios/irqs/regs/sizes/etc.
> So, how do we define in a bank of GPIOs, which ones are free for use,
> without them being attached to a device and given as a "gpios" property?
>
> Would we suggest a node;
>
> gpio-header {
> compatible = "bplan,efika-gpio";
> gpios = <&gpio-standard 16 0 17 0>;
> };
>
> gpio-header2 {
> compatible = "bplan,efika-gpio-wkup";
> gpios = <&gpio-wkup 18 0>;
> };
IMO this looks very reasonable. You properly describe the hardware:
physical device (header) and its resources.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
On Oct 24, 2008, at 11:09 AM, Chris Snook wrote: Kumar Gala wrote: On Oct 24, 2008, at 10:17 AM, Chris Snook wrote: Kumar Gala wrote: It appears the default IRQ affinity changes from being just cpu 0 to all cpu's. This breaks several PPC SMP systems in which only a single processor is allowed to be selected as the destination of the IRQ. What is the right answer in fixing this? Should we: cpumask_t irq_default_affinity = 1; instead of cpumask_t irq_default_affinity = CPU_MASK_ALL? On those systems, perhaps, but not universally. There's plenty of hardware where the physical topology of the machine is abstracted away from the OS, and you need to leave the mask wide open and let the APIC figure out where to map the IRQs. Ideally, we should probably make this decision based on the APIC, but if there's no PPC hardware that uses this technique, then it would suffice to make this arch-specific. What did those systems do before this patch? Its one thing to expose a mask in the ability to change the default mask in /proc/ irq/default_smp_affinity. Its another (and a regression in my opinion) to change the mask value itself. Before the patch they took an extremely long time to boot if they had storage attached to each node of a multi-chassis system, performed poorly unless special irqbalance hackery or manual assignment was used, and imposed artificial restrictions on the granularity of hardware partitioning to ensure that CPU 0 would always be a CPU that could service all interrupts necessary to boot the OS. As for making it ARCH specific, that doesn't really help since not all PPC hw has the limitation I spoke of. Not even all MPIC (in our cases) have the limitation. What did those systems do before this patch? :) Making it arch-specific is an extremely simple way to solve your problem without making trouble for the people who wanted this patch in the first place. If PPC needs further refinement to handle particular *PICs, you can implement that without touching any arch- generic code. So why not just have x86 startup code set irq_default_affinity = CPU_MASK_ALL than? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Specify GPIO number base for controller in DT
On Thu, 2008-10-23 at 16:35 -0500, Matt Sealey wrote: > > On Oct 23, 2008, at 7:27 AM, Wolfgang Ocker wrote: > >> The GPIOLIB allows the specification of a base gpio number for a > >> controller. That is not possible using OF. Instead, free gpio numbers > >> are assigned. > >> > >> In order to allow static, predefined gpio numbers, a base property in > >> the gpio controller node specifies the first gpio number. > > See my latest mail. > > I don't think it's enough to say which pin the GPIOs exposed > start at; you need some sort of mask, or array of applicable > GPIOs so that GPIOLIB can check which perhaps 3 pins out of a > possible 32 are allocated to a controller and usable (these > may be pin 5, pin 9 and pin 20, so a "base" of pin 5 would be > outrageously inadequate). I'm not sure what you mean. That "base" is used in gpiochip_add() when registering the gpio controller. There is no magic with a mask or so. What do I miss? Thanks, Wolfgang signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Kumar Gala wrote: On Oct 24, 2008, at 10:17 AM, Chris Snook wrote: Kumar Gala wrote: It appears the default IRQ affinity changes from being just cpu 0 to all cpu's. This breaks several PPC SMP systems in which only a single processor is allowed to be selected as the destination of the IRQ. What is the right answer in fixing this? Should we: cpumask_t irq_default_affinity = 1; instead of cpumask_t irq_default_affinity = CPU_MASK_ALL? On those systems, perhaps, but not universally. There's plenty of hardware where the physical topology of the machine is abstracted away from the OS, and you need to leave the mask wide open and let the APIC figure out where to map the IRQs. Ideally, we should probably make this decision based on the APIC, but if there's no PPC hardware that uses this technique, then it would suffice to make this arch-specific. What did those systems do before this patch? Its one thing to expose a mask in the ability to change the default mask in /proc/irq/default_smp_affinity. Its another (and a regression in my opinion) to change the mask value itself. Before the patch they took an extremely long time to boot if they had storage attached to each node of a multi-chassis system, performed poorly unless special irqbalance hackery or manual assignment was used, and imposed artificial restrictions on the granularity of hardware partitioning to ensure that CPU 0 would always be a CPU that could service all interrupts necessary to boot the OS. As for making it ARCH specific, that doesn't really help since not all PPC hw has the limitation I spoke of. Not even all MPIC (in our cases) have the limitation. What did those systems do before this patch? :) Making it arch-specific is an extremely simple way to solve your problem without making trouble for the people who wanted this patch in the first place. If PPC needs further refinement to handle particular *PICs, you can implement that without touching any arch-generic code. -- Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
rebasing master branch of galak/powerpc.git
Now that 2.6.28-rc1 is out I'm rebasing my master branch against it. Sorry for any pains this causes. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] genirq: Set initial default irq affinity to just CPU0
Commit 18404756765c713a0be4eb1082920c04822ce588 introduced a regression on a subset of SMP based PPC systems whose interrupt controller only allow setting an irq to a single processor. The previous behavior was only CPU0 was initially setup to get interrupts. Revert back to that behavior. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- kernel/irq/manage.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index c498a1b..728d36a 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -17,7 +17,7 @@ #ifdef CONFIG_SMP -cpumask_t irq_default_affinity = CPU_MASK_ALL; +cpumask_t irq_default_affinity = CPU_MASK_CPU0; /** * synchronize_irq - wait for pending IRQ handlers (on other CPUs) -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
On Oct 24, 2008, at 10:17 AM, Chris Snook wrote: Kumar Gala wrote: It appears the default IRQ affinity changes from being just cpu 0 to all cpu's. This breaks several PPC SMP systems in which only a single processor is allowed to be selected as the destination of the IRQ. What is the right answer in fixing this? Should we: cpumask_t irq_default_affinity = 1; instead of cpumask_t irq_default_affinity = CPU_MASK_ALL? On those systems, perhaps, but not universally. There's plenty of hardware where the physical topology of the machine is abstracted away from the OS, and you need to leave the mask wide open and let the APIC figure out where to map the IRQs. Ideally, we should probably make this decision based on the APIC, but if there's no PPC hardware that uses this technique, then it would suffice to make this arch-specific. What did those systems do before this patch? Its one thing to expose a mask in the ability to change the default mask in /proc/irq/ default_smp_affinity. Its another (and a regression in my opinion) to change the mask value itself. As for making it ARCH specific, that doesn't really help since not all PPC hw has the limitation I spoke of. Not even all MPIC (in our cases) have the limitation. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Kumar Gala wrote: It appears the default IRQ affinity changes from being just cpu 0 to all cpu's. This breaks several PPC SMP systems in which only a single processor is allowed to be selected as the destination of the IRQ. What is the right answer in fixing this? Should we: cpumask_t irq_default_affinity = 1; instead of cpumask_t irq_default_affinity = CPU_MASK_ALL? On those systems, perhaps, but not universally. There's plenty of hardware where the physical topology of the machine is abstracted away from the OS, and you need to leave the mask wide open and let the APIC figure out where to map the IRQs. Ideally, we should probably make this decision based on the APIC, but if there's no PPC hardware that uses this technique, then it would suffice to make this arch-specific. -- Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/40x: Don't enable HCU4 board by default
Fix the HCU4 Kconfig option to 'default n'. We don't want the board to always be enabled for other board defconfigs. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig index 6573027..14e027f 100644 --- a/arch/powerpc/platforms/40x/Kconfig +++ b/arch/powerpc/platforms/40x/Kconfig @@ -35,7 +35,7 @@ config EP405 config HCU4 bool "Hcu4" depends on 40x - default y + default n select 405GPR help This option enables support for the Nestal Maschinen HCU4 board. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ibm_newemac: Fix typo in flow control config option
The recent build fix for ibm_newemac has a typo in the config
option #ifdef used for disabling flow control. This corrects
it to the proper Kconfig option name.
Reported-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 2ee2622..901212a 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2605,7 +2605,7 @@ static int __devinit emac_init_config(struct
emac_instance *dev)
of_device_is_compatible(np, "ibm,emac-440gr"))
dev->features |= EMAC_FTR_440EP_PHY_CLK_FIX;
if (of_device_is_compatible(np, "ibm,emac-405ez")) {
-#ifdef CONFIG_IBM_NEW_EMAC_NO_FLOW_CONTROL
+#ifdef CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL
dev->features |= EMAC_FTR_NO_FLOW_CONTROL_40x;
#else
printk(KERN_ERR "%s: Flow control not disabled!\n",
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
It appears the default IRQ affinity changes from being just cpu 0 to all cpu's. This breaks several PPC SMP systems in which only a single processor is allowed to be selected as the destination of the IRQ. What is the right answer in fixing this? Should we: cpumask_t irq_default_affinity = 1; instead of cpumask_t irq_default_affinity = CPU_MASK_ALL? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: adding more machines to snd-aoa
Here's a patch that actually applies against 2.6.27.
---
sound/aoa/fabrics/snd-aoa-fabric-layout.c | 73 +++---
sound/aoa/soundbus/i2sbus/i2sbus-core.c | 16 --
2 files changed, 68 insertions(+), 21 deletions(-)
--- everything.orig/sound/aoa/fabrics/snd-aoa-fabric-layout.c 2008-10-24
13:35:00.0 +0200
+++ everything/sound/aoa/fabrics/snd-aoa-fabric-layout.c2008-10-24
14:42:32.0 +0200
@@ -1,16 +1,14 @@
/*
- * Apple Onboard Audio driver -- layout fabric
+ * Apple Onboard Audio driver -- layout/machine id fabric
*
- * Copyright 2006 Johannes Berg <[EMAIL PROTECTED]>
+ * Copyright 2006, 2008 Johannes Berg <[EMAIL PROTECTED]>
*
* GPL v2, can be found in COPYING.
*
*
- * This fabric module looks for sound codecs
- * based on the layout-id property in the device tree.
- *
+ * This fabric module looks for sound codecs based on the
+ * layout-id or device-id property in the device tree.
*/
-
#include
#include
#include
@@ -63,7 +61,7 @@ struct codec_connect_info {
#define LAYOUT_FLAG_COMBO_LINEOUT_SPDIF(1<<0)
struct layout {
- unsigned int layout_id;
+ unsigned int layout_id, device_id;
struct codec_connect_info codecs[MAX_CODECS_PER_BUS];
int flags;
@@ -111,6 +109,10 @@ MODULE_ALIAS("sound-layout-96");
MODULE_ALIAS("sound-layout-98");
MODULE_ALIAS("sound-layout-100");
+MODULE_ALIAS("aoa-device-id-14");
+MODULE_ALIAS("aoa-device-id-22");
+MODULE_ALIAS("aoa-device-id-35");
+
/* onyx with all but microphone connected */
static struct codec_connection onyx_connections_nomic[] = {
{
@@ -518,6 +520,27 @@ static struct layout layouts[] = {
.connections = onyx_connections_noheadphones,
},
},
+ /* PowerMac3,4 */
+ { .device_id = 14,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_noline,
+ },
+ },
+ /* PowerMac3,6 */
+ { .device_id = 22,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_all,
+ },
+ },
+ /* PowerBook5,2 */
+ { .device_id = 35,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_all,
+ },
+ },
{}
};
@@ -526,7 +549,7 @@ static struct layout *find_layout_by_id(
struct layout *l;
l = layouts;
- while (l->layout_id) {
+ while (l->codecs[0].name) {
if (l->layout_id == id)
return l;
l++;
@@ -534,6 +557,19 @@ static struct layout *find_layout_by_id(
return NULL;
}
+static struct layout *find_layout_by_device(unsigned int id)
+{
+ struct layout *l;
+
+ l = layouts;
+ while (l->codecs[0].name) {
+ if (l->device_id == id)
+ return l;
+ l++;
+ }
+ return NULL;
+}
+
static void use_layout(struct layout *l)
{
int i;
@@ -938,8 +974,8 @@ static struct aoa_fabric layout_fabric =
static int aoa_fabric_layout_probe(struct soundbus_dev *sdev)
{
struct device_node *sound = NULL;
- const unsigned int *layout_id;
- struct layout *layout;
+ const unsigned int *id;
+ struct layout *layout = NULL;
struct layout_dev *ldev = NULL;
int err;
@@ -952,15 +988,18 @@ static int aoa_fabric_layout_probe(struc
if (sound->type && strcasecmp(sound->type, "soundchip") == 0)
break;
}
- if (!sound) return -ENODEV;
+ if (!sound)
+ return -ENODEV;
- layout_id = of_get_property(sound, "layout-id", NULL);
- if (!layout_id)
- goto outnodev;
- printk(KERN_INFO "snd-aoa-fabric-layout: found bus with layout %d\n",
- *layout_id);
+ id = of_get_property(sound, "layout-id", NULL);
+ if (id) {
+ layout = find_layout_by_id(*id);
+ } else {
+ id = of_get_property(sound, "device-id", NULL);
+ if (id)
+ layout = find_layout_by_device(*id);
+ }
- layout = find_layout_by_id(*layout_id);
if (!layout) {
printk(KERN_ERR "snd-aoa-fabric-layout: unknown layout\n");
goto outnodev;
--- everything.orig/sound/aoa/soundbus/i2sbus/i2sbus-core.c 2008-10-24
14:01:15.0 +0200
+++ everything/sound/aoa/soundbus/i2sbus/i2sbus-core.c 2008-10-24
14:42:32.0 +0200
@@ -186,13 +186,21 @@ static int i2sbus_add_dev(struct macio_d
}
}
if (i == 1) {
- const u32 *layout_id =
- of_get_property(sound, "layout-id", NULL);
- if (layout_id) {
- layout = *layout_id;
+ const u32 *id = of_get_property(sound, "layout-id", NULL);
+
+ if (id) {
+
Re: adding more machines to snd-aoa
On Fri, 2008-10-24 at 14:26 +0200, Gabriel Paubert wrote: > > Right. I'll assume it has a microphone too, built-in. > > I doubt it: > - no mention found in the doc > - it seems to be output-only (#-inputs in the device tree is 0, > #-outputs is 3). Yeah, I've disabled it in the patch I sent you. > I could also send you the device tree of my PowerBook G3: it does > have the device-id property with a value of 10, but the parent > node is called davbus instead of i2s. That one definitely has > a microphone... No, I don't really care about davbus at this point. TBH, I don't care much about the other machines either, and there are lots... I'll have to find a way to map the #-inputs and #-outputs to the information otherwise I'll have to dig out all the manuals or something... > > Could you try the > > patch below, enable all snd-aoa modules and see what happens? > > > > I won't have time in the next few days, sorry. No worries, let me know when you can. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: adding more machines to snd-aoa
On Fri, Oct 24, 2008 at 10:40:23AM +0200, Johannes Berg wrote: > On Thu, 2008-10-23 at 18:43 +0200, Gabriel Paubert wrote: > > > > Can you tell me which devices it has, like does it have line-in, > > > microphone, headphones, ...? > > > > I'm not an audio specialist, so the symbols used to > > identify the ports look like hieroglyphs to me, but > > The documentation says that the two ports on the > > back are for headphones and external stereo loudspeakers. > > Right. I'll assume it has a microphone too, built-in. I doubt it: - no mention found in the doc - it seems to be output-only (#-inputs in the device tree is 0, #-outputs is 3). I have attached the device tree corresponding to the PCI domain. I could also send you the device tree of my PowerBook G3: it does have the device-id property with a value of 10, but the parent node is called davbus instead of i2s. That one definitely has a microphone... > Could you try the > patch below, enable all snd-aoa modules and see what happens? > I won't have time in the next few days, sorry. Regards, Gabriel pmac4,3-pci@f200.tar.gz Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ehea: Add hugepage detection
16GB hugepages may not be part of a memory region (firmware restriction). This
patch
modifies the walk_memory_resource callback fn to filter hugepages and add only
standard
memory to the busmap which is later on used for MR registration.
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
This patch is based on davem's net-2.6.git.
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.27/drivers/net/ehea/ehea.h2008-10-24 09:29:19.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea.h 2008-10-24 09:45:15.0
+0200
@@ -40,7 +40,7 @@
#include
#define DRV_NAME "ehea"
-#define DRV_VERSION"EHEA_0094"
+#define DRV_VERSION"EHEA_0095"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_qmr.c
patched_kernel/drivers/net/ehea/ehea_qmr.c
--- linux-2.6.27/drivers/net/ehea/ehea_qmr.c2008-10-24 09:29:19.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea_qmr.c 2008-10-24 09:45:15.0
+0200
@@ -636,6 +636,9 @@ static int ehea_update_busmap(unsigned l
{
unsigned long i, start_section, end_section;
+ if (!pgnum)
+ return 0;
+
if (!ehea_bmap) {
ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL);
if (!ehea_bmap)
@@ -692,10 +695,47 @@ int ehea_rem_sect_bmap(unsigned long pfn
return ret;
}
-static int ehea_create_busmap_callback(unsigned long pfn,
- unsigned long nr_pages, void *arg)
+static int ehea_is_hugepage(unsigned long pfn)
+{
+ return pfn << PAGE_SHIFT) & (EHEA_HUGEPAGE_SIZE - 1)) == 0)
+ && (compound_order(pfn_to_page(pfn)) + PAGE_SHIFT
+ == EHEA_HUGEPAGESHIFT) );
+}
+
+static int ehea_create_busmap_callback(unsigned long initial_pfn,
+ unsigned long total_nr_pages, void *arg)
{
- return ehea_update_busmap(pfn, nr_pages, EHEA_BUSMAP_ADD_SECT);
+ int ret;
+ unsigned long pfn, start_pfn, end_pfn, nr_pages;
+
+ if ((total_nr_pages * PAGE_SIZE) < EHEA_HUGEPAGE_SIZE)
+ return ehea_update_busmap(initial_pfn, total_nr_pages,
+ EHEA_BUSMAP_ADD_SECT);
+
+ /* Given chunk is >= 16GB -> check for hugepages */
+ start_pfn = initial_pfn;
+ end_pfn = initial_pfn + total_nr_pages;
+ pfn = start_pfn;
+
+ while (pfn < end_pfn) {
+ if (ehea_is_hugepage(pfn)) {
+ /* Add mem found in front of the hugepage */
+ nr_pages = pfn - start_pfn;
+ ret = ehea_update_busmap(start_pfn, nr_pages,
+EHEA_BUSMAP_ADD_SECT);
+ if (ret)
+ return ret;
+
+ /* Skip the hugepage */
+ pfn += (EHEA_HUGEPAGE_SIZE / PAGE_SIZE);
+ start_pfn = pfn;
+ } else
+ pfn += (EHEA_SECTSIZE / PAGE_SIZE);
+ }
+
+ /* Add mem found behind the hugepage(s) */
+ nr_pages = pfn - start_pfn;
+ return ehea_update_busmap(start_pfn, nr_pages, EHEA_BUSMAP_ADD_SECT);
}
int ehea_create_busmap(void)
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_qmr.h
patched_kernel/drivers/net/ehea/ehea_qmr.h
--- linux-2.6.27/drivers/net/ehea/ehea_qmr.h2008-10-24 09:29:19.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea_qmr.h 2008-10-24 09:45:15.0
+0200
@@ -40,6 +40,8 @@
#define EHEA_PAGESIZE (1UL << EHEA_PAGESHIFT)
#define EHEA_SECTSIZE (1UL << 24)
#define EHEA_PAGES_PER_SECTION (EHEA_SECTSIZE >> EHEA_PAGESHIFT)
+#define EHEA_HUGEPAGESHIFT 34
+#define EHEA_HUGEPAGE_SIZE (1UL << EHEA_HUGEPAGESHIFT)
#if ((1UL << SECTION_SIZE_BITS) < EHEA_SECTSIZE)
#error eHEA module cannot work if kernel sectionsize < ehea sectionsize
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: adding more machines to snd-aoa
On Thu, 2008-10-23 at 18:43 +0200, Gabriel Paubert wrote:
> > Can you tell me which devices it has, like does it have line-in,
> > microphone, headphones, ...?
>
> I'm not an audio specialist, so the symbols used to
> identify the ports look like hieroglyphs to me, but
> The documentation says that the two ports on the
> back are for headphones and external stereo loudspeakers.
Right. I'll assume it has a microphone too, built-in. Could you try the
patch below, enable all snd-aoa modules and see what happens?
johannes
---
sound/aoa/fabrics/snd-aoa-fabric-layout.c | 73 +++---
sound/aoa/soundbus/i2sbus/i2sbus-core.c | 16 --
2 files changed, 68 insertions(+), 21 deletions(-)
--- everything.orig/sound/aoa/fabrics/snd-aoa-fabric-layout.c 2008-10-24
10:39:20.0 +0200
+++ everything/sound/aoa/fabrics/snd-aoa-fabric-layout.c2008-10-24
10:40:08.0 +0200
@@ -1,16 +1,14 @@
/*
- * Apple Onboard Audio driver -- layout fabric
+ * Apple Onboard Audio driver -- layout/machine id fabric
*
- * Copyright 2006 Johannes Berg <[EMAIL PROTECTED]>
+ * Copyright 2006, 2008 Johannes Berg <[EMAIL PROTECTED]>
*
* GPL v2, can be found in COPYING.
*
*
- * This fabric module looks for sound codecs
- * based on the layout-id property in the device tree.
- *
+ * This fabric module looks for sound codecs based on the
+ * layout-id or device-id property in the device tree.
*/
-
#include
#include
#include
@@ -63,7 +61,7 @@ struct codec_connect_info {
#define LAYOUT_FLAG_COMBO_LINEOUT_SPDIF(1<<0)
struct layout {
- unsigned int layout_id;
+ unsigned int layout_id, device_id;
struct codec_connect_info codecs[MAX_CODECS_PER_BUS];
int flags;
@@ -111,6 +109,10 @@ MODULE_ALIAS("sound-layout-96");
MODULE_ALIAS("sound-layout-98");
MODULE_ALIAS("sound-layout-100");
+MODULE_ALIAS("aoa-device-id-14");
+MODULE_ALIAS("aoa-device-id-22");
+MODULE_ALIAS("aoa-device-id-35");
+
/* onyx with all but microphone connected */
static struct codec_connection onyx_connections_nomic[] = {
{
@@ -518,6 +520,27 @@ static struct layout layouts[] = {
.connections = onyx_connections_noheadphones,
},
},
+ /* PowerMac3,4 */
+ { .device_id = 14,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_noline,
+ },
+ },
+ /* PowerMac3,6 */
+ { .device_id = 22,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_all,
+ },
+ },
+ /* PowerBook5,2 */
+ { .device_id = 35,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_all,
+ },
+ },
{}
};
@@ -526,7 +549,7 @@ static struct layout *find_layout_by_id(
struct layout *l;
l = layouts;
- while (l->layout_id) {
+ while (l->codecs[0].name) {
if (l->layout_id == id)
return l;
l++;
@@ -534,6 +557,19 @@ static struct layout *find_layout_by_id(
return NULL;
}
+static struct layout *find_layout_by_device(unsigned int id)
+{
+ struct layout *l;
+
+ l = layouts;
+ while (l->codecs[0].name) {
+ if (l->device_id == id)
+ return l;
+ l++;
+ }
+ return NULL;
+}
+
static void use_layout(struct layout *l)
{
int i;
@@ -938,8 +974,8 @@ static struct aoa_fabric layout_fabric =
static int aoa_fabric_layout_probe(struct soundbus_dev *sdev)
{
struct device_node *sound = NULL;
- const unsigned int *layout_id;
- struct layout *layout;
+ const unsigned int *id;
+ struct layout *layout = NULL;
struct layout_dev *ldev = NULL;
int err;
@@ -952,15 +988,18 @@ static int aoa_fabric_layout_probe(struc
if (sound->type && strcasecmp(sound->type, "soundchip") == 0)
break;
}
- if (!sound) return -ENODEV;
+ if (!sound)
+ return -ENODEV;
- layout_id = of_get_property(sound, "layout-id", NULL);
- if (!layout_id)
- goto outnodev;
- printk(KERN_INFO "snd-aoa-fabric-layout: found bus with layout %d\n",
- *layout_id);
+ id = of_get_property(sound, "layout-id", NULL);
+ if (id) {
+ layout = find_layout_by_id(*id);
+ } else {
+ id = of_get_property(sound, "device-id", NULL);
+ if (id)
+ layout = find_layout_by_device(*id);
+ }
- layout = find_layout_by_id(*layout_id);
if (!layout) {
printk(KERN_ERR "snd-aoa-fabric-layout: unknown layout\n");
goto outnodev;
--- everything.orig/sound/aoa/soundbus/i2sbus/i2sbus-core.c 2008-10-24
10:39:20.0 +0200
+++ everything/sound/
Re: [PATCH] Allocate resources for PHB DLPAR add
On Thu, 2008-10-23 at 23:08 -0500, Nathan Fontenot wrote: > Resources for PHB's that are DLPAR added to a system are not acquired. > Not having these resources allocated causes an oops during DLPAR > remove of the PHB when we try to release non-existant resources. > > The patch appears a bit messy, this is mainly due to moving everything > one tab to the left in the pcibios_allocate_bus_resources routine. The > big functionality change in this routine is only that the > list_for_each_entry() loop is pulled out and moved to the necessary > calling routine. > > Signed-off-by: Nathan Fontenot <[EMAIL PROTECTED]> > > --- Patch looks good. I'll include it in the next batch hopefully along with a variant of another patch I'm working on to fix other issues I found with our PCI hotplug resource management. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
