* Re: [PATCH 09/11] [POWERPC] Motion-PRO: Add LED support.
From: Grant Likely @ 2007-10-24 14:18 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071023231358.29359.90259.stgit@hekate.izotz.org>
On 10/23/07, Marian Balakowicz <m8@semihalf.com> wrote:
> Add LED driver for Promess Motion-PRO board.
>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> ---
>
> drivers/leds/Kconfig | 7 +
> drivers/leds/Makefile | 3 -
> drivers/leds/leds-motionpro.c | 222 +++++++++++++++++++++++++++++++++++++++++
> include/asm-powerpc/mpc52xx.h | 5 +
> 4 files changed, 236 insertions(+), 1 deletions(-)
> create mode 100644 drivers/leds/leds-motionpro.c
>
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index ec568fa..1567ed6 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -55,6 +55,13 @@ config LEDS_TOSA
> This option enables support for the LEDs on Sharp Zaurus
> SL-6000 series.
>
> +config LEDS_MOTIONPRO
> + tristate "Motion-PRO LEDs Support"
> + depends on LEDS_CLASS && PPC_MPC5200
> + help
> + This option enables support for status and ready LEDs connected
> + to GPIO lines on Motion-PRO board.
> +
> config LEDS_S3C24XX
> tristate "LED Support for Samsung S3C24XX GPIO LEDs"
> depends on LEDS_CLASS && ARCH_S3C2410
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index a60de1b..a56d399 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -18,7 +18,8 @@ obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
> obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o
> obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
> obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
> -obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
> +obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
> +obj-$(CONFIG_LEDS_MOTIONPRO) += leds-motionpro.o
>
> # LED Triggers
> obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
> diff --git a/drivers/leds/leds-motionpro.c b/drivers/leds/leds-motionpro.c
> new file mode 100644
> index 0000000..d4b872c
> --- /dev/null
> +++ b/drivers/leds/leds-motionpro.c
> @@ -0,0 +1,222 @@
> +/*
> + * LEDs driver for the Motionpro board.
> + *
> + * Copyright (C) 2007 Semihalf
> + *
> + * Author: Jan Wrobel <wrr@semihalf.com>
> + *
> + * 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, Inc., 51
> + * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> + *
> + *
> + * This driver enables control over Motionpro's status and ready LEDs through
> + * sysfs. LEDs can be controlled by writing to sysfs files:
> + * class/leds/motionpro-(ready|status)led/(brightness|delay_off|delay_on).
> + * See Documentation/leds-class.txt for more details
> + *
> + * Before user issues first control command via sysfs, LED blinking is
> + * controlled by the kernel. By default status LED is blinking fast and ready
> + * LED is turned off.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/leds.h>
> +
> +#include <asm/mpc52xx.h>
> +#include <asm/io.h>
> +
> +/* Led status */
> +#define LED_NOT_REGISTERED 0
> +#define LED_KERNEL_CONTROLLED 1
> +#define LED_USER_CONTROLLED 2
> +
> +/* Led control bits */
> +#define LED_ON MPC52xx_GPT_OUTPUT_1
> +
> +static void mpled_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness);
> +
> +struct motionpro_led{
> + /* Protects the led data */
> + spinlock_t led_lock;
> +
> + /* Path to led's control register DTS node */
> + char *reg_compat;
> +
> + /* Address to access led's register */
> + void __iomem *reg_addr;
> +
> + int status;
> +
> + /* Blinking timer used when led is controlled by the kernel */
> + struct timer_list kernel_mode_timer;
> +
> + /*
> + * Delay between blinks when led is controlled by the kernel.
> + * If set to 0 led blinking is off.
> + */
> + int kernel_mode_delay;
> +
> + struct led_classdev classdev;
> +};
> +
> +static struct motionpro_led led[] = {
> + {
> + .reg_compat = "promess,motionpro-statusled",
> + .reg_addr = 0,
> + .led_lock = SPIN_LOCK_UNLOCKED,
> + .status = LED_NOT_REGISTERED,
> + .kernel_mode_delay = HZ / 10,
> + .classdev = {
> + .name = "motionpro-statusled",
> + .brightness_set = mpled_set,
> + .default_trigger = "timer",
> + },
> + },
> + {
> + .reg_compat = "promess,motionpro-readyled",
> + .reg_addr = 0,
> + .led_lock = SPIN_LOCK_UNLOCKED,
> + .status = LED_NOT_REGISTERED,
> + .kernel_mode_delay = 0,
> + .classdev = {
> + .name = "motionpro-readyled",
> + .brightness_set = mpled_set,
> + .default_trigger = "timer",
> + }
> + }
> +};
> +
> +/* Timer event - blinks led before user takes control over it */
> +static void mpled_timer_toggle(unsigned long ptr)
> +{
> + struct motionpro_led *mled = (struct motionpro_led *) ptr;
> +
> + spin_lock_bh(&mled->led_lock);
> + if (mled->status == LED_KERNEL_CONTROLLED){
> + u32 reg = in_be32(mled->reg_addr);
> + reg ^= LED_ON;
> + out_be32(mled->reg_addr, reg);
> + led->kernel_mode_timer.expires = jiffies +
> + led->kernel_mode_delay;
> + add_timer(&led->kernel_mode_timer);
> + }
> + spin_unlock_bh(&mled->led_lock);
> +}
> +
> +
> +/*
> + * Turn on/off led according to user settings in sysfs.
> + * First call to this function disables kernel blinking.
> + */
> +static void mpled_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
> +{
> + struct motionpro_led *mled;
> + u32 reg;
> +
> + mled = container_of(led_cdev, struct motionpro_led, classdev);
> +
> + spin_lock_bh(&mled->led_lock);
> + mled->status = LED_USER_CONTROLLED;
> +
> + reg = in_be32(mled->reg_addr);
> + if (brightness)
> + reg |= LED_ON;
> + else
> + reg &= ~LED_ON;
> + out_be32(mled->reg_addr, reg);
> +
> + spin_unlock_bh(&mled->led_lock);
> +}
> +
> +static void mpled_init_led(void __iomem *reg_addr)
> +{
> + u32 reg = in_be32(reg_addr);
> + reg |= MPC52xx_GPT_ENABLE_OUTPUT;
> + reg &= ~LED_ON;
> + out_be32(reg_addr, reg);
> +}
> +
> +static void mpled_clean(void)
> +{
> + int i;
> + for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
> + if (led[i].status != LED_NOT_REGISTERED){
> + spin_lock_bh(&led[i].led_lock);
> + led[i].status = LED_NOT_REGISTERED;
> + spin_unlock_bh(&led[i].led_lock);
> + led_classdev_unregister(&led[i].classdev);
> + }
> + if (led[i].reg_addr){
> + iounmap(led[i].reg_addr);
> + led[i].reg_addr = 0;
> + }
> + }
> +}
> +
> +static int __init mpled_init(void)
> +{
> + int i, error;
> +
> + for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
> + led[i].reg_addr = mpc52xx_find_and_map(led[i].reg_compat);
Please use of-platform-bus bindings instead. Let the of-platform bus
take care of scanning the tree for you. Don't do it manually.
> + if (!led[i].reg_addr){
> + printk(KERN_ERR __FILE__ ": "
> + "Error while mapping GPIO register for LED %s\n",
> + led[i].classdev.name);
> + error = -EIO;
> + goto err;
> + }
> +
> + mpled_init_led(led[i].reg_addr);
> + led[i].status = LED_KERNEL_CONTROLLED;
> + if (led[i].kernel_mode_delay){
> + init_timer(&led[i].kernel_mode_timer);
> + led[i].kernel_mode_timer.function = mpled_timer_toggle;
> + led[i].kernel_mode_timer.data = (unsigned long)&led[i];
> + led[i].kernel_mode_timer.expires =
> + jiffies + led[i].kernel_mode_delay;
> + add_timer(&led[i].kernel_mode_timer);
> + }
> +
> + if ((error = led_classdev_register(NULL, &led[i].classdev)) < 0){
> + printk(KERN_ERR __FILE__ ": "
> + "Error while registering class device for LED "
> + "%s\n",
> + led[i].classdev.name);
> + goto err;
> + }
> + }
> +
> + printk("Motionpro LEDs driver initialized\n");
> + return 0;
> +err:
> + mpled_clean();
> + return error;
> +}
> +
> +static void __exit mpled_exit(void)
> +{
> + mpled_clean();
> +}
> +
> +module_init(mpled_init);
> +module_exit(mpled_exit);
> +
> +MODULE_LICENSE("GPL")
> +MODULE_DESCRIPTION("LEDs support for Motionpro");
> +MODULE_AUTHOR("Jan Wrobel <wrr@semihalf.com>");
> diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
> index 859ffb0..7e20f54 100644
> --- a/include/asm-powerpc/mpc52xx.h
> +++ b/include/asm-powerpc/mpc52xx.h
> @@ -140,6 +140,11 @@ struct mpc52xx_gpio {
> #define MPC52xx_GPIO_PSC_CONFIG_UART_WITH_CD 5
> #define MPC52xx_GPIO_PCI_DIS (1<<15)
>
> +/* Enables GPT register to operate as simple GPIO output register */
> +#define MPC52xx_GPT_ENABLE_OUTPUT 0x00000024
> +/* Puts 1 on GPT output pin */
> +#define MPC52xx_GPT_OUTPUT_1 0x00000010
> +
> /* GPIO with WakeUp*/
> struct mpc52xx_gpio_wkup {
> u8 wkup_gpioe; /* GPIO_WKUP + 0x00 */
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 14:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710231529h1089eacdy888306f20af92555@mail.gmail.com>
Jon Smirl wrote:
> Is this consensus on how the tree should look?
>
> There is no attempt to describe the codec connections inside the
> device tree.
I don't think I agree with that. The device tree should indicate which codec is
connected to which I2S/AC97 device.
I see that you do that for the AC97 node, but not the I2S node. Why?
> I'm still not clear on how to trigger the load of the fabric driver.
> Right now I have a single kernel that works on Efika and my target
> hardware. This gets sorted out by define_machine(xxxx). I'll write
> some code tonight to figure out how to load drivers and match on
> codec0, codec1, etc. But how do I probe for the fabric driver I need
> to figure out whether to load the Efika one or my target one.
I've been struggling with that one, too. To keep it simple, I have the fabric
driver just search for all the I2S nodes in my tree, and create ASoC objects for
each one it finds. There's some hackery there, but I don't think we need to
solve all the problems at once. The only thing that *has* to be right the first
time is the device tree.
> i2s@2200 { // PSC2
> compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
> cell-index = <1>;
> reg = <2200 100>;
> interrupts = <2 2 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> i2c@3d00 {
> compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
> reg = <3d00 40>;
> interrupts = <2 f 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
>
> codec0: i2s-codec@0 {
> compatible = "ti,tas5508";
> reg = <0>;
> i2s-handle = <&i2s@2000>;
> };
I'd do this the other way around -- that is:
i2s@2200 { // PSC2
compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
...
i2c-handle = <&codec0>; /* Or something like that */
};
The reason is because I think the I2S driver will be instantiated *first* as an
I2S driver and then it will create the I2C instantiation.
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Dale Farnsworth @ 2007-10-24 14:10 UTC (permalink / raw)
To: Valentine Barshak; +Cc: Linuxppc-dev
In-Reply-To: <471F4C53.1070506@ru.mvista.com>
On Wed, Oct 24, 2007 at 05:44:51PM +0400, Valentine Barshak wrote:
> Dale Farnsworth wrote:
> >On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote:
> >>Dale Farnsworth wrote:
> >>>Valentine wrote:
> >>>>Actually I also don't see much reason for the
> >>>>USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
> >>>>Is this really needed?
> >>>I think so. The SOC host controllers are BE and the PCI
> >>>host controllers are LE. Or, do you have an alternative
> >>>method of handling both types?
> >>Yes, PCI controllers are LE, but do we really need user-selectable
> >>USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected
> >>by default for USB_OHCI_HCD_PCI?
> >>The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
> >>I think it's useless. We should always enable
> >>USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
> >>and the real LE/BE implementation should be selected by the
> >>corresponding properties in the device tree.
> >
> >I agree that they don't need to be user selectable. It is far preferable
> >to deduce their values from existing information, if possible.
> >
> >-Dale
>
> This is the original thread:
> http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025054.html
>
> I think the USB_OHCI_HCD_PPC_OF_LE/BE should be removed.
> We can't avoid the slight overhead even using these options, since
> USB_OHCI_BIG_ENDIAN_MMIO/DESC should always be anabled for PPC OF and we
> we still enable USB_OHCI_LITTLE_ENDIAN for USB_OHCI_HCD_PCI even if
> USB_OHCI_HCD_PPC_OF_LE is not set.
I believe you are saying that we can select any valid combination
of USB_OHCI_BIG_ENDIAN_DESC, USB_OHCI_BIG_ENDIAN_MMIO, and
USB_OHCI_LITTLE_ENDIAN, without using USB_OHCI_HCD_PPC_OF_BE and
USB_OHCI_HCD_PPC_OF_LE. I agree. It looks like we can get rid of
these last two with zero loss in performance or functionality.
Do you have a patch?
-Dale
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: Grant Likely @ 2007-10-24 14:09 UTC (permalink / raw)
To: Marian Balakowicz, linuxppc-dev
In-Reply-To: <20071024015115.GK10595@localhost.localdomain>
On 10/23/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Wed, Oct 24, 2007 at 01:13:33AM +0200, Marian Balakowicz wrote:
> > Add device tree source file for TQM5200 board.
> >
> > Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> > ---
> >
> > arch/powerpc/boot/dts/tqm5200.dts | 236 +++++++++++++++++++++++++++++++++++++
> > 1 files changed, 236 insertions(+), 0 deletions(-)
> > create mode 100644 arch/powerpc/boot/dts/tqm5200.dts
> >
> >
> > diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
> > new file mode 100644
> > index 0000000..01c7778
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/tqm5200.dts
> > @@ -0,0 +1,236 @@
> > +/*
> > + * TQM5200 board Device Tree Source
> [snip]
> > + soc5200@f0000000 {
>
> I thought we were moving towards calling these just /soc@address?
The only reason this is still like this is that u-boot does a path
based lookup for the soc5200 node on the TQM board. We need to change
u-boot too before the 5200 can be dropped.
>
> > + model = "fsl,mpc5200";
> > + compatible = "mpc5200";
>
> That should have a vendor prefix.
>
> [snip]
> > + serial@2000 { // PSC1
> > + device_type = "serial";
> > + compatible = "mpc5200-psc-uart";
> > + port-number = <0>; // Logical port assignment
>
> How are these port-number things used? The device tree shouldn't
> generally contain information that isn't inherent to the hardware.
> There can be reasons for hacks like this, but we should avoid them if
> possible.
This was an approach I was taking a while back to assign logical ports
(ttyPSC0) to a PSC. I'm working on eliminating this. As you
suggested, I'm looking into using aliases for this.
>
> > + cell-index = <0>;
>
> cell-index should only be used if the index number is used when
> manipulating the hardware (e.g. if there's a global control register
> which takes this number).
And there is in this case.
>
> [snip]
> > + ata@3a00 {
> > + device_type = "ata";
>
> No such thing as device_type = "ata", drop it. In general, never
> include a device_type unless a binding explicitly says to do so.
Again, my fault from the lite5200.
>
> [snip]
> > + lpb@fc000000 {
> > + model = "fsl,lpb";
> > + compatible = "lpb";
>
> Not nearly specific enough. Must include a vendor prefix at least,
> and should have a lot more revision information. You should always be
> able to pick the right driver with compatible alone, "model" should
> generally be for human consumption, the driver shouldn't need it.
>
> > + device_type = "lpb";
>
> Drop this. Again, presence of a device_type property is the
> exception, not the rule.
>
> > + ranges = <0 fc000000 02000000>;
>
> You need #address-cells and #size-cells properties, too.
>
> [snip]
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 04/11] [POWERPC] Add generic support for MPC5200 based boards
From: Grant Likely @ 2007-10-24 14:03 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071023231327.29359.28666.stgit@hekate.izotz.org>
On 10/23/07, Marian Balakowicz <m8@semihalf.com> wrote:
> This patch adds support for 'generic-mpc5200' compatible
> boards which do not need a platform specific setup.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
I like this patch and I think it will make it easier to support
multiple 5200 based boards. However, we must be very clear here what
'generic-mpc5200' is (in fact, my suggestion of the name
"generic-mpc5200" might be a bad one. "mpc5200-simple-platform" might
be a better name).
Please add documentation to both the Kconfig and the generic_mpc5200.c
files describing exactly the assumptions which are made for this
platform. For example:
- port_config and clocking are setup correctly by firmware,
- if the fsl,has-wdt property is present in one of the gpt nodes, then
it is safe to use it to reset the board
etc.
Cheers,
g.
> ---
>
> arch/powerpc/platforms/52xx/Kconfig | 8 ++-
> arch/powerpc/platforms/52xx/Makefile | 1
> arch/powerpc/platforms/52xx/generic_mpc5200.c | 63 +++++++++++++++++++++++++
> 3 files changed, 70 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/platforms/52xx/generic_mpc5200.c
>
>
> diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
> index 2938d49..59c67b5 100644
> --- a/arch/powerpc/platforms/52xx/Kconfig
> +++ b/arch/powerpc/platforms/52xx/Kconfig
> @@ -19,6 +19,12 @@ config PPC_MPC5200_BUGFIX
>
> It is safe to say 'Y' here
>
> +config PPC_GENERIC_MPC5200
> + bool "Generic support for MPC5200 based boards"
> + depends on PPC_MULTIPLATFORM && PPC32
> + select PPC_MPC5200
> + default n
> +
> config PPC_EFIKA
> bool "bPlan Efika 5k2. MPC5200B based computer"
> depends on PPC_MULTIPLATFORM && PPC32
> @@ -34,5 +40,3 @@ config PPC_LITE5200
> select WANT_DEVICE_TREE
> select PPC_MPC5200
> default n
> -
> -
> diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
> index 307dbc1..bea05df 100644
> --- a/arch/powerpc/platforms/52xx/Makefile
> +++ b/arch/powerpc/platforms/52xx/Makefile
> @@ -6,6 +6,7 @@ obj-y += mpc52xx_pic.o mpc52xx_common.o
> obj-$(CONFIG_PCI) += mpc52xx_pci.o
> endif
>
> +obj-$(CONFIG_PPC_GENERIC_MPC5200) += generic_mpc5200.o
> obj-$(CONFIG_PPC_EFIKA) += efika.o
> obj-$(CONFIG_PPC_LITE5200) += lite5200.o
>
> diff --git a/arch/powerpc/platforms/52xx/generic_mpc5200.c b/arch/powerpc/platforms/52xx/generic_mpc5200.c
> new file mode 100644
> index 0000000..a4ec899
> --- /dev/null
> +++ b/arch/powerpc/platforms/52xx/generic_mpc5200.c
> @@ -0,0 +1,63 @@
> +/*
> + * Support for 'generic-mpc5200' compatible platforms.
> + *
> + * Written by Marian Balakowicz <m8@semihalf.com>
> + * Copyright (C) 2007 Semihalf
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#undef DEBUG
> +#include <linux/init.h>
> +#include <linux/pci.h>
> +#include <linux/of.h>
> +#include <asm/time.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/mpc52xx.h>
> +
> +/*
> + * Setup the architecture
> + */
> +static void __init generic_mpc5200_setup_arch(void)
> +{
> + if (ppc_md.progress)
> + ppc_md.progress("generic_mpc5200_setup_arch()", 0);
> +
> + /* Some mpc5200 & mpc5200b related configuration */
> + mpc5200_setup_xlb_arbiter();
> +
> + /* Map wdt for mpc52xx_restart() */
> + mpc52xx_map_wdt();
> +
> +#ifdef CONFIG_PCI
> + mpc52xx_setup_pci();
> +#endif
> +}
> +
> +/*
> + * Called very early, MMU is off, device-tree isn't unflattened
> + */
> +static int __init generic_mpc5200_probe(void)
> +{
> + unsigned long node = of_get_flat_dt_root();
> +
> + if (!of_flat_dt_is_compatible(node, "generic-mpc5200"))
> + return 0;
> + return 1;
> +}
> +
> +define_machine(generic_mpc5200) {
> + .name = "generic-mpc5200",
> + .probe = generic_mpc5200_probe,
> + .setup_arch = generic_mpc5200_setup_arch,
> + .init = mpc52xx_declare_of_platform_devices,
> + .init_IRQ = mpc52xx_init_irq,
> + .get_irq = mpc52xx_get_irq,
> + .restart = mpc52xx_restart,
> + .calibrate_decr = generic_calibrate_decr,
> +};
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: libfdt: Add some documenting comments in libfdt.h
From: Jon Loeliger @ 2007-10-24 13:45 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071024071058.GC17853@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch adds some internal documentation in libfdt.h, in the form
> of comments on the error codes and some functions. Only a couple of
> functions are covered so far, leaving the documentation still woefully
> inadequate, but hey, it's a start.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Dave,
Sorry, I can't get this patch to apply either before or after
the previous patch. Did I miss one?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Valentine Barshak @ 2007-10-24 13:44 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071024120804.GA1180@xyzzy.farnsworth.org>
Dale Farnsworth wrote:
> On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote:
>> Dale Farnsworth wrote:
>>> Valentine wrote:
>>>> Actually I also don't see much reason for the
>>>> USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
>>>> Is this really needed?
>>> I think so. The SOC host controllers are BE and the PCI
>>> host controllers are LE. Or, do you have an alternative
>>> method of handling both types?
>> Yes, PCI controllers are LE, but do we really need user-selectable
>> USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected
>> by default for USB_OHCI_HCD_PCI?
>> The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
>> I think it's useless. We should always enable
>> USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
>> and the real LE/BE implementation should be selected by the
>> corresponding properties in the device tree.
>
> I agree that they don't need to be user selectable. It is far preferable
> to deduce their values from existing information, if possible.
>
> -Dale
This is the original thread:
http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025054.html
I think the USB_OHCI_HCD_PPC_OF_LE/BE should be removed.
We can't avoid the slight overhead even using these options, since
USB_OHCI_BIG_ENDIAN_MMIO/DESC should always be anabled for PPC OF and we
we still enable USB_OHCI_LITTLE_ENDIAN for USB_OHCI_HCD_PCI even if
USB_OHCI_HCD_PPC_OF_LE is not set.
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-24 13:36 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <d120d5000710240634j21d2b660t267ace56bd9d6af6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 389 bytes --]
On Wed, 2007-10-24 at 09:34 -0400, Dmitry Torokhov wrote:
> Well, but what about fountains then? Regardless of the model, if there
> is a way to stop "empty" meaurements, we should do it.
There is no way on fountains though. We could check the measurement
ourselves and if no finger is detected decrease the polling frequency or
something, but there's no hw support.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Dmitry Torokhov @ 2007-10-24 13:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <1193231110.4510.42.camel@johannes.berg>
On 10/24/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> Hi,
>
> > My fault, sorry.
>
> No, actually, I was wrong about Geyser 1, mine is a fountain.
>
> > Is there a way to "plug" these Geysers? Waking up the kernel
> > continuously is not nice.
>
> Not sure really, maybe checking for is_geyser instead of is_geyser_3?
>
Well, but what about fountains then? Regardless of the model, if there
is a way to stop "empty" meaurements, we should do it.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-24 13:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <d120d5000710240555m545a4f95v8bfc1ac790273001@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
Hi,
> My fault, sorry.
No, actually, I was wrong about Geyser 1, mine is a fountain.
> Is there a way to "plug" these Geysers? Waking up the kernel
> continuously is not nice.
Not sure really, maybe checking for is_geyser instead of is_geyser_3?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* ioctl32 unknown cmds with 2.6.24-rc1
From: Johannes Berg @ 2007-10-24 12:30 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
I've been getting these warnings (many more of them but this is a list
of unique ones) on my quad G5 with 32-bit userspace:
ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(0000030d){t:03;sz:0} arg(ff863970) on /dev/.tmp-3-0
ioctl32(smartd:3563): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(ffeb5480) on /dev/sda
ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(00005320){t:'S';sz:0} arg(00000004) on /dev/hda
ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(0fd8e400) on /dev/pts/0
Does anybody know whether this is expected?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH v2] appletouch: fix fountain touchpad breakage
From: Johannes Berg @ 2007-10-24 11:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linuxppc-dev list, Anton Ekblad, Sven Anders, Soeren Sonnenburg
In-Reply-To: <1193222676.4510.5.camel@johannes.berg>
The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
without testing on a fountain touchpad. It causes appletouch to
continuously printk:
drivers/input/mouse/appletouch.c: Could not do mode read request from device (Geyser 3 mode)
because the fountain touchpad doesn't respond to that. The patch description
also states:
> if we see 10 empty packets the touchpad needs to be reset; good
> touchpads should not send empty packets anyway.
which is *TOTALLY* bogus since fountain touchpads have no notion of
empty packets, the simply continuously send measurements. One look at
the specification would have confirmed that.
This reverts the clueless commit, a better solution for geyser 1
touchpads must be found.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
What I'd advocate for 2.6.25 is to split appletouch into two drivers:
"appletouch" for fountain touchpads and maybe "appletouch2" for geyser
touchpads, this will get rid of many of the huge if statements in the
packet processing path and make sure that the macbook crowd will no
longer have to workaround the powerbook touchpads seeing that we seem to
hardly talk to each other.
Or maybe Soeren Sonnenburg's rewrite could be used for Geyser touchpads.
drivers/input/mouse/appletouch.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
--- linux-2.6.orig/drivers/input/mouse/appletouch.c 2007-10-24 12:37:39.140210069 +0200
+++ linux-2.6/drivers/input/mouse/appletouch.c 2007-10-24 12:37:50.000215820 +0200
@@ -504,22 +504,25 @@ static void atp_complete(struct urb* urb
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, key);
- input_sync(dev->input);
-
- /* Many Geysers will continue to send packets continually after
+ /* Geyser 3 will continue to send packets continually after
the first touch unless reinitialised. Do so if it's been
idle for a while in order to avoid waking the kernel up
several hundred times a second */
- if (!x && !y && !key) {
- dev->idlecount++;
- if (dev->idlecount == 10) {
- dev->valid = 0;
- schedule_work(&dev->work);
+ if (atp_is_geyser_3(dev)) {
+ if (!x && !y && !key) {
+ dev->idlecount++;
+ if (dev->idlecount == 10) {
+ dev->valid = 0;
+ schedule_work(&dev->work);
+ }
}
- } else
- dev->idlecount = 0;
+ else
+ dev->idlecount = 0;
+ }
+
+ input_report_key(dev->input, BTN_LEFT, key);
+ input_sync(dev->input);
exit:
retval = usb_submit_urb(dev->urb, GFP_ATOMIC);
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-24 11:22 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <1193222676.4510.5.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
On Wed, 2007-10-24 at 12:44 +0200, Johannes Berg wrote:
> The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
> without testing on a Geyser 1, and I'm a very annoyed that it was
> applied. It causes appletouch to continuously printk:
I spoke too soon, I don't have a Geyser 1 but rather a Fountain touchpad
on my powerbook.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* strataflash size and partitioning problem
From: Amin Farajian @ 2007-10-24 13:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 5317 bytes --]
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 11:21 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <20071024092334.GM14671@kernel.dk>
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
On Wed, 2007-10-24 at 11:23 +0200, Jens Axboe wrote:
> On Wed, Oct 24 2007, Johannes Berg wrote:
> > On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote:
> >
> > > I lost track - which kernel are you booting? This looks like something
> > > that should be fixed, did you try 2.6.24-rc1?
> >
> > No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
> > give it a try, but I don't think I can confirm it works before tomorrow.
> > I see the build failure got fixed with commit
> > 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
>
> 0895e91d60ef9bdef426d1ce14bb94bd5875870d is definitely too old, so it
> will break on IDE. I'm confident that a newer kernel will solve this
> issue.
It does indeed, 2.6.24-rc1 runs fine. Thanks.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: libfdt: Rename and publish _fdt_check_header()
From: Jon Loeliger @ 2007-10-24 13:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071024002852.GG10595@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> It's potentially useful for users of libfdt to sanity check a device
> tree (or, rather, a blob of data which may or may not be a device
> tree) before processing it in more detail with libfdt.
>
> This patch renames the libfdt internal function _fdt_check_header() to
> fdt_check_header() and makes it a published function, so it can now be
> used for this purpose.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Dmitry Torokhov @ 2007-10-24 12:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <1193222676.4510.5.camel@johannes.berg>
Hi Johannes,
On 10/24/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
> without testing on a Geyser 1,
My fault, sorry. However Anton's device has product ID of 90x30B which
is Geyser 1 as far as I understand... But yes, we should not expect
other geysers respond to Geyser 3-specific commands.
> and I'm a very annoyed that it was
> applied. It causes appletouch to continuously printk:
>
> drivers/input/mouse/appletouch.c: Could not do mode read request from device (Geyser 3 mode)
>
> because the Geyser 1 doesn't respond to that. The patch description also
> states:
>
> > if we see 10 empty packets the touchpad needs to be reset; good
> > touchpads should not send empty packets anyway.
>
> which is *TOTALLY* bogus since Geyser 1 touchpads have no notion of
> empty packets, the simply continuously send measurements. One look at
> the specification would have confirmed that.
>
Is there a way to "plug" these Geysers? Waking up the kernel
continuously is not nice.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Dale Farnsworth @ 2007-10-24 12:08 UTC (permalink / raw)
To: Valentine Barshak; +Cc: Linuxppc-dev
In-Reply-To: <471F2A32.8030202@ru.mvista.com>
On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote:
> Dale Farnsworth wrote:
> >Valentine wrote:
> >>Actually I also don't see much reason for the
> >>USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
> >>Is this really needed?
> >
> >I think so. The SOC host controllers are BE and the PCI
> >host controllers are LE. Or, do you have an alternative
> >method of handling both types?
>
> Yes, PCI controllers are LE, but do we really need user-selectable
> USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected
> by default for USB_OHCI_HCD_PCI?
> The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
> I think it's useless. We should always enable
> USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
> and the real LE/BE implementation should be selected by the
> corresponding properties in the device tree.
I agree that they don't need to be user selectable. It is far preferable
to deduce their values from existing information, if possible.
-Dale
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-24 12:07 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <4718B287.20306@ru.mvista.com>
Hello, I wrote:
>>> The only thing I'm still unusre about is that deterministic accounting.
>>>Could you point me at the patch which deals with this (at least for System 390
>>See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look
> Wait, how this is related to the hrtimer's event handlers not being able
> to call account_process_time() from arch/powerpc/kernel/time.c instead of
> update_process_timess()?
I've just realized that I've missed the call to account_process_time() in
the new timer_interrupt(). :-<
Anyway, this leads to each tick being accounted twice if the deterministic
accounting is not enabled -- first by timer_interrupt() and then by the
hrtimers core, doesn't it?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Valentine Barshak @ 2007-10-24 11:19 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071023214000.424.qmail@farnsworth.org>
Dale Farnsworth wrote:
> Valentine wrote:
>> Actually I also don't see much reason for the
>> USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
>> Is this really needed?
>
> I think so. The SOC host controllers are BE and the PCI
> host controllers are LE. Or, do you have an alternative
> method of handling both types?
>
> -Dale
Yes, PCI controllers are LE, but do we really need user-selectable
USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected
by default for USB_OHCI_HCD_PCI?
The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
I think it's useless. We should always enable
USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
and the real LE/BE implementation should be selected by the
corresponding properties in the device tree.
Thanks,
Valentine.
^ permalink raw reply
* [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-24 10:44 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Anton Ekblad
The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
without testing on a Geyser 1, and I'm a very annoyed that it was
applied. It causes appletouch to continuously printk:
drivers/input/mouse/appletouch.c: Could not do mode read request from device (Geyser 3 mode)
because the Geyser 1 doesn't respond to that. The patch description also
states:
> if we see 10 empty packets the touchpad needs to be reset; good
> touchpads should not send empty packets anyway.
which is *TOTALLY* bogus since Geyser 1 touchpads have no notion of
empty packets, the simply continuously send measurements. One look at
the specification would have confirmed that.
This reverts the clueless commit.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
--- linux-2.6.orig/drivers/input/mouse/appletouch.c 2007-10-24 12:37:39.140210069 +0200
+++ linux-2.6/drivers/input/mouse/appletouch.c 2007-10-24 12:37:50.000215820 +0200
@@ -504,22 +504,25 @@ static void atp_complete(struct urb* urb
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, key);
- input_sync(dev->input);
-
- /* Many Geysers will continue to send packets continually after
+ /* Geyser 3 will continue to send packets continually after
the first touch unless reinitialised. Do so if it's been
idle for a while in order to avoid waking the kernel up
several hundred times a second */
- if (!x && !y && !key) {
- dev->idlecount++;
- if (dev->idlecount == 10) {
- dev->valid = 0;
- schedule_work(&dev->work);
+ if (atp_is_geyser_3(dev)) {
+ if (!x && !y && !key) {
+ dev->idlecount++;
+ if (dev->idlecount == 10) {
+ dev->valid = 0;
+ schedule_work(&dev->work);
+ }
}
- } else
- dev->idlecount = 0;
+ else
+ dev->idlecount = 0;
+ }
+
+ input_report_key(dev->input, BTN_LEFT, key);
+ input_sync(dev->input);
exit:
retval = usb_submit_urb(dev->urb, GFP_ATOMIC);
^ permalink raw reply
* [PATCH] ehea: fix port_napi_disable/enable
From: Jan-Bernd Themann @ 2007-10-24 9:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
napi_disable / napi_enable must be applied on all ehea queues.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 7 +++----
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index b557bb4..4b4b74e 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0078"
+#define DRV_VERSION "EHEA_0079"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index fe5ffac..a8b05d2 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2329,7 +2329,7 @@ static void port_napi_disable(struct ehea_port *port)
{
int i;
- for (i = 0; i < port->num_def_qps; i++)
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++)
napi_disable(&port->port_res[i].napi);
}
@@ -2337,7 +2337,7 @@ static void port_napi_enable(struct ehea_port *port)
{
int i;
- for (i = 0; i < port->num_def_qps; i++)
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++)
napi_enable(&port->port_res[i].napi);
}
@@ -2373,8 +2373,6 @@ static int ehea_down(struct net_device *dev)
ehea_drop_multicast_list(dev);
ehea_free_interrupts(dev);
- port_napi_disable(port);
-
port->state = EHEA_PORT_DOWN;
ret = ehea_clean_all_portres(port);
@@ -2396,6 +2394,7 @@ static int ehea_stop(struct net_device *dev)
flush_scheduled_work();
down(&port->port_lock);
netif_stop_queue(dev);
+ port_napi_disable(port);
ret = ehea_down(dev);
up(&port->port_lock);
return ret;
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] taskstats scaled time cleanup
From: Balbir Singh @ 2007-10-24 9:52 UTC (permalink / raw)
To: Michael Neuling
Cc: linux-s390, linux-kernel, linuxppc-dev, paulus, linux390, akpm
In-Reply-To: <8789.1193208897@neuling.org>
Michael Neuling wrote:
> This moves the ability to scale cputime into generic code. This
> allows us to fix the issue in kernel/timer.c (noticed by Balbir) where
> we could only add an unscaled value to the scaled utime/stime.
>
> This adds a cputime_to_scaled function. As before, the POWERPC
> version does the scaling based on the last SPURR/PURR ratio
> calculated. The generic and s390 (only other arch to implement
> asm/cputime.h) versions are both NOPs.
>
> Also moves the SPURR and PURR snapshots closer.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Looks good to me
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Jens Axboe @ 2007-10-24 9:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193217742.5715.6.camel@johannes.berg>
On Wed, Oct 24 2007, Johannes Berg wrote:
> On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote:
>
> > I lost track - which kernel are you booting? This looks like something
> > that should be fixed, did you try 2.6.24-rc1?
>
> No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
> give it a try, but I don't think I can confirm it works before tomorrow.
> I see the build failure got fixed with commit
> 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
0895e91d60ef9bdef426d1ce14bb94bd5875870d is definitely too old, so it
will break on IDE. I'm confident that a newer kernel will solve this
issue.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 9:24 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193217816.5715.8.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Wed, 2007-10-24 at 11:23 +0200, Johannes Berg wrote:
> On Wed, 2007-10-24 at 11:22 +0200, Johannes Berg wrote:
>
> > No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
> > give it a try, but I don't think I can confirm it works before tomorrow.
> > I see the build failure got fixed with commit
> > 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
>
> Wait, now I lost track. This patch is identical to that commit 5edad...,
> what I was thinking of was the oops I got.
Nah, never mind. Apologies to everybody. I'm confused, Jens says the
oops was fixed. I'll verify that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox