* Re: [PATCH 1/3] show_interrupts: use irq_chip::name if available
From: Peter Korsgaard @ 2009-12-09 7:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1259700494-17869-1-git-send-email-jacmet@sunsite.dk>
>>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
Peter> struct irq_chip::typename is going away (replaced by name). Use name if
Peter> set instead of typename in show_interrupt to make ease transition.
Comments?
Peter> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Peter> ---
Peter> arch/powerpc/kernel/irq.c | 3 ++-
Peter> 1 files changed, 2 insertions(+), 1 deletions(-)
Peter> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
Peter> index e5d1211..33e1130 100644
Peter> --- a/arch/powerpc/kernel/irq.c
Peter> +++ b/arch/powerpc/kernel/irq.c
Peter> @@ -203,7 +203,8 @@ int show_interrupts(struct seq_file *p, void *v)
Peter> seq_printf(p, "%10u ", kstat_irqs(i));
Peter> #endif /* CONFIG_SMP */
Peter> if (desc->chip)
Peter> - seq_printf(p, " %s ", desc->chip->typename);
Peter> + seq_printf(p, " %s ", desc->chip->name ?
Peter> + desc->chip->name : desc->chip->typename);
Peter> else
Peter> seq_puts(p, " None ");
Peter> seq_printf(p, "%s", (desc->status & IRQ_LEVEL) ? "Level " : "Edge ");
Peter> --
Peter> 1.6.5
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 2/3] asm/gpio.h: support gpio_to_irq()
From: Peter Korsgaard @ 2009-12-09 7:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1259700494-17869-2-git-send-email-jacmet@sunsite.dk>
>>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
Peter> gpiolib returns -ENXIO if struct gpio_chip::to_irq isn't set, so it's
Peter> safe to always call.
Comments?
Peter> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Peter> ---
Peter> arch/powerpc/include/asm/gpio.h | 5 +----
Peter> 1 files changed, 1 insertions(+), 4 deletions(-)
Peter> diff --git a/arch/powerpc/include/asm/gpio.h b/arch/powerpc/include/asm/gpio.h
Peter> index ea04632..38762ed 100644
Peter> --- a/arch/powerpc/include/asm/gpio.h
Peter> +++ b/arch/powerpc/include/asm/gpio.h
Peter> @@ -38,12 +38,9 @@ static inline int gpio_cansleep(unsigned int gpio)
Peter> return __gpio_cansleep(gpio);
Peter> }
Peter> -/*
Peter> - * Not implemented, yet.
Peter> - */
Peter> static inline int gpio_to_irq(unsigned int gpio)
Peter> {
Peter> - return -ENOSYS;
Peter> + return __gpio_to_irq(gpio);
Peter> }
Peter> static inline int irq_to_gpio(unsigned int irq)
Peter> --
Peter> 1.6.5
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 3/3] mpc8xxx_gpio: add interrupt support
From: Peter Korsgaard @ 2009-12-09 7:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1259700494-17869-3-git-send-email-jacmet@sunsite.dk>
>>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
Comments?
Peter> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Peter> ---
Peter> arch/powerpc/sysdev/mpc8xxx_gpio.c | 147 ++++++++++++++++++++++++++++++++++++
Peter> 1 files changed, 147 insertions(+), 0 deletions(-)
Peter> diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
Peter> index 103eace..b46f28b 100644
Peter> --- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
Peter> +++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
Peter> @@ -15,6 +15,7 @@
Peter> #include <linux/of.h>
Peter> #include <linux/of_gpio.h>
Peter> #include <linux/gpio.h>
Peter> +#include <linux/irq.h>
Peter> #define MPC8XXX_GPIO_PINS 32
Peter> @@ -34,6 +35,7 @@ struct mpc8xxx_gpio_chip {
Peter> * open drain mode safely
Peter> */
Peter> u32 data;
Peter> + struct irq_host *irq;
Peter> };
Peter> static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
Peter> @@ -111,12 +113,136 @@ static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val
Peter> return 0;
Peter> }
Peter> +static int mpc8xxx_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
Peter> +{
Peter> + struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
Peter> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
Peter> +
Peter> + if (mpc8xxx_gc->irq && offset < MPC8XXX_GPIO_PINS)
Peter> + return irq_create_mapping(mpc8xxx_gc->irq, offset);
Peter> + else
Peter> + return -ENXIO;
Peter> +}
Peter> +
Peter> +static void mpc8xxx_gpio_irq_cascade(unsigned int irq, struct irq_desc *desc)
Peter> +{
Peter> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_desc_data(desc);
Peter> + struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
Peter> + unsigned int mask;
Peter> +
Peter> + mask = in_be32(mm->regs + GPIO_IER) & in_be32(mm->regs + GPIO_IMR);
Peter> + if (mask)
Peter> + generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
Peter> + 32 - ffs(mask)));
Peter> +}
Peter> +
Peter> +static void mpc8xxx_irq_unmask(unsigned int virq)
Peter> +{
Peter> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
Peter> + struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
Peter> + unsigned long flags;
Peter> +
Peter> + spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
Peter> +
Peter> + setbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(virq)));
Peter> +
Peter> + spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
Peter> +}
Peter> +
Peter> +static void mpc8xxx_irq_mask(unsigned int virq)
Peter> +{
Peter> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
Peter> + struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
Peter> + unsigned long flags;
Peter> +
Peter> + spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
Peter> +
Peter> + clrbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(virq)));
Peter> +
Peter> + spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
Peter> +}
Peter> +
Peter> +static void mpc8xxx_irq_ack(unsigned int virq)
Peter> +{
Peter> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
Peter> + struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
Peter> +
Peter> + out_be32(mm->regs + GPIO_IER, mpc8xxx_gpio2mask(virq_to_hw(virq)));
Peter> +}
Peter> +
Peter> +static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
Peter> +{
Peter> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
Peter> + struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
Peter> + unsigned long flags;
Peter> +
Peter> + switch (flow_type) {
Peter> + case IRQ_TYPE_EDGE_FALLING:
Peter> + spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
Peter> + setbits32(mm->regs + GPIO_ICR,
Peter> + mpc8xxx_gpio2mask(virq_to_hw(virq)));
Peter> + spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
Peter> + break;
Peter> +
Peter> + case IRQ_TYPE_EDGE_BOTH:
Peter> + spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
Peter> + clrbits32(mm->regs + GPIO_ICR,
Peter> + mpc8xxx_gpio2mask(virq_to_hw(virq)));
Peter> + spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
Peter> + break;
Peter> +
Peter> + default:
Peter> + return -EINVAL;
Peter> + }
Peter> +
Peter> + return 0;
Peter> +}
Peter> +
Peter> +static struct irq_chip mpc8xxx_irq_chip = {
Peter> + .name = "mpc8xxx-gpio",
Peter> + .unmask = mpc8xxx_irq_unmask,
Peter> + .mask = mpc8xxx_irq_mask,
Peter> + .ack = mpc8xxx_irq_ack,
Peter> + .set_type = mpc8xxx_irq_set_type,
Peter> +};
Peter> +
Peter> +static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
Peter> + irq_hw_number_t hw)
Peter> +{
Peter> + set_irq_chip_data(virq, h->host_data);
Peter> + set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq);
Peter> + set_irq_type(virq, IRQ_TYPE_NONE);
Peter> +
Peter> + return 0;
Peter> +}
Peter> +
Peter> +static int mpc8xxx_gpio_irq_xlate(struct irq_host *h, struct device_node *ct,
Peter> + u32 *intspec, unsigned int intsize,
Peter> + irq_hw_number_t *out_hwirq,
Peter> + unsigned int *out_flags)
Peter> +
Peter> +{
Peter> + /* interrupt sense values coming from the device tree equal either
Peter> + * EDGE_FALLING or EDGE_BOTH
Peter> + */
Peter> + *out_hwirq = intspec[0];
Peter> + *out_flags = intspec[1];
Peter> +
Peter> + return 0;
Peter> +}
Peter> +
Peter> +static struct irq_host_ops mpc8xxx_gpio_irq_ops = {
Peter> + .map = mpc8xxx_gpio_irq_map,
Peter> + .xlate = mpc8xxx_gpio_irq_xlate,
Peter> +};
Peter> +
Peter> static void __init mpc8xxx_add_controller(struct device_node *np)
Peter> {
Peter> struct mpc8xxx_gpio_chip *mpc8xxx_gc;
Peter> struct of_mm_gpio_chip *mm_gc;
Peter> struct of_gpio_chip *of_gc;
Peter> struct gpio_chip *gc;
Peter> + unsigned hwirq;
Peter> int ret;
Peter> mpc8xxx_gc = kzalloc(sizeof(*mpc8xxx_gc), GFP_KERNEL);
Peter> @@ -138,11 +264,32 @@ static void __init mpc8xxx_add_controller(struct device_node *np)
gc-> direction_output = mpc8xxx_gpio_dir_out;
gc-> get = mpc8xxx_gpio_get;
gc-> set = mpc8xxx_gpio_set;
Peter> + gc->to_irq = mpc8xxx_gpio_to_irq;
Peter> ret = of_mm_gpiochip_add(np, mm_gc);
Peter> if (ret)
Peter> goto err;
Peter> + hwirq = irq_of_parse_and_map(np, 0);
Peter> + if (hwirq == NO_IRQ)
Peter> + goto skip_irq;
Peter> +
Peter> + mpc8xxx_gc->irq =
Peter> + irq_alloc_host(np, IRQ_HOST_MAP_LINEAR, MPC8XXX_GPIO_PINS,
Peter> + &mpc8xxx_gpio_irq_ops, MPC8XXX_GPIO_PINS);
Peter> + if (!mpc8xxx_gc->irq)
Peter> + goto skip_irq;
Peter> +
Peter> + mpc8xxx_gc->irq->host_data = mpc8xxx_gc;
Peter> +
Peter> + /* ack and mask all irqs */
Peter> + out_be32(mm_gc->regs + GPIO_IER, 0xffffffff);
Peter> + out_be32(mm_gc->regs + GPIO_IMR, 0);
Peter> +
Peter> + set_irq_data(hwirq, mpc8xxx_gc);
Peter> + set_irq_chained_handler(hwirq, mpc8xxx_gpio_irq_cascade);
Peter> +
Peter> +skip_irq:
Peter> return;
Peter> err:
Peter> --
Peter> 1.6.5
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB
From: Joakim Tjernlund @ 2009-12-09 7:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1260332399.16132.7.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 09/12/2009 05:19:59:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> To: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Cc: Scott Wood <scottwood@freescale.com>, "linuxppc-dev@ozlabs.org" <linuxppc-
> dev@ozlabs.org>, Rex Feany <RFeany@mrv.com>
> Date: 09/12/2009 05:20
> Subject: Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB
>
> On Fri, 2009-11-20 at 11:21 +0100, Joakim Tjernlund wrote:
> > Various kernel asm modifies SRR0/SRR1 just before executing
> > a rfi. If such code crosses a page boundary you risk a TLB miss
> > which will clobber SRR0/SRR1. Avoid this by always pinning
> > kernel instruction TLB space.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> > arch/powerpc/kernel/head_8xx.S | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
> > index a9f1ace..e70503d 100644
> > --- a/arch/powerpc/kernel/head_8xx.S
> > +++ b/arch/powerpc/kernel/head_8xx.S
> > @@ -705,7 +705,7 @@ start_here:
> > */
> > initial_mmu:
> > tlbia /* Invalidate all TLB entries */
> > -#ifdef CONFIG_PIN_TLB
> > +#if 1 /* CONFIG_PIN_TLB */
> > lis r8, MI_RSV4I@h
> > ori r8, r8, 0x1c00
> > #else
>
> Not nice. Either remove the config option or make sure all those code
> sequences are appropriately aligned so it doesn't happen. I recommend
> the later :-)
The later isn't as simple :) I believe the bulk of such code in entry_32.S.
Anyhow, the config option is still valid as if enabled
it will pin several DTLB's too. Scott had some concerns about removing the
config option completely so this was the next best thing.
>
> I'll apply the other patches.
OK, great.
^ permalink raw reply
* RE: gianfar breaking builds
From: Kumar Gopalpet-B05799 @ 2009-12-09 8:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260341804.16132.22.camel@pasglop>
Hi Ben,
Can you point to me from where you cloned the tree.
Also, net-next-2.6 tree was building for me.
--
Thanks
Sandeep
>-----Original Message-----
>From:=20
>linuxppc-dev-bounces+sandeep.kumar=3Dfreescale.com@lists.ozlabs.o
>rg=20
>[mailto:linuxppc-dev-bounces+sandeep.kumar=3Dfreescale.com@lists.
>ozlabs.org] On Behalf Of Benjamin Herrenschmidt
>Sent: Wednesday, December 09, 2009 12:27 PM
>To: Kumar Gala
>Cc: linuxppc-dev
>Subject: gianfar breaking builds
>
>In my next (not pushed out yet as I'm writing this but will be=20
>by the time you read it hopefully), I get a build failure:
>
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c: In=20
>function 'gfar_netpoll':
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2653:=20
>error: invalid storage class for function 'gfar_interrupt'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2652:=20
>warning: ISO C90 forbids mixed declarations and code
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2681:=20
>error: invalid storage class for function 'adjust_link'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2764:=20
>error: invalid storage class for function 'gfar_set_multi'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2855:=20
>error: invalid storage class for function 'gfar_clear_exact_match'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2877:=20
>error: invalid storage class for function 'gfar_set_hash_for_addr'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2898:=20
>error: invalid storage class for function 'gfar_set_mac_for_addr'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2922:=20
>error: invalid storage class for function 'gfar_error'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3017:=20
>warning: 'alias' attribute ignored
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3032:=20
>error: invalid storage class for function 'gfar_init'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3037:=20
>error: invalid storage class for function 'gfar_exit'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:=20
>error: invalid storage class for function '__inittest'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:=20
>warning: 'alias' attribute ignored
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:=20
>error: invalid storage class for function '__exittest'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:=20
>warning: ISO C90 forbids mixed declarations and code
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:=20
>warning: 'alias' attribute ignored
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:=20
>error: expected declaration or statement at end of input
>make[3]: *** [drivers/net/gianfar.o] Error 1
>
>Stephen says that breakage has been in -next for some time...
>
>Can you guys sort it out ?
>
>Cheers,
>Ben.
>
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB
From: Benjamin Herrenschmidt @ 2009-12-09 8:56 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OFB03B60EA.0352DA78-ONC1257687.002955A6-C1257687.002A145F@transmode.se>
On Wed, 2009-12-09 at 08:39 +0100, Joakim Tjernlund wrote:
> The later isn't as simple :) I believe the bulk of such code in
> entry_32.S.
Yeah but it would be useful for hash I suppose if one really wants to
boot with nobats. Though at least on hash most of the time we have ways
to recover by mean of MSR:RI being cleared, which your TLB miss code
doesn't check...
> Anyhow, the config option is still valid as if enabled
> it will pin several DTLB's too. Scott had some concerns about removing
> the config option completely so this was the next best thing.
Well, if you want to pin at least one entry, then just remove the #if
completely but don't leave a #if 1 :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/3] show_interrupts: use irq_chip::name if available
From: Benjamin Herrenschmidt @ 2009-12-09 8:59 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87y6lcmwkk.fsf@macbook.be.48ers.dk>
On Wed, 2009-12-09 at 08:32 +0100, Peter Korsgaard wrote:
> >>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
>
> Peter> struct irq_chip::typename is going away (replaced by name). Use name if
> Peter> set instead of typename in show_interrupt to make ease transition.
>
> Comments?
Hi Peter !
There's already a patch in my -next tree from Thomas Gleixner that fixes
that up along with a few others in arch/powerpc.
Cheers,
Ben.
> Peter> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> Peter> ---
> Peter> arch/powerpc/kernel/irq.c | 3 ++-
> Peter> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> Peter> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> Peter> index e5d1211..33e1130 100644
> Peter> --- a/arch/powerpc/kernel/irq.c
> Peter> +++ b/arch/powerpc/kernel/irq.c
> Peter> @@ -203,7 +203,8 @@ int show_interrupts(struct seq_file *p, void *v)
> Peter> seq_printf(p, "%10u ", kstat_irqs(i));
> Peter> #endif /* CONFIG_SMP */
> Peter> if (desc->chip)
> Peter> - seq_printf(p, " %s ", desc->chip->typename);
> Peter> + seq_printf(p, " %s ", desc->chip->name ?
> Peter> + desc->chip->name : desc->chip->typename);
> Peter> else
> Peter> seq_puts(p, " None ");
> Peter> seq_printf(p, "%s", (desc->status & IRQ_LEVEL) ? "Level " : "Edge ");
> Peter> --
> Peter> 1.6.5
>
>
^ permalink raw reply
* Re: [PATCH 1/3] show_interrupts: use irq_chip::name if available
From: Peter Korsgaard @ 2009-12-09 9:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260349142.16132.39.camel@pasglop>
>>>>> "Benjamin" == Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
Benjamin> On Wed, 2009-12-09 at 08:32 +0100, Peter Korsgaard wrote:
>> >>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
>>
Peter> struct irq_chip::typename is going away (replaced by name). Use name if
Peter> set instead of typename in show_interrupt to make ease transition.
>>
>> Comments?
Benjamin> Hi Peter !
Benjamin> There's already a patch in my -next tree from Thomas Gleixner
Benjamin> that fixes that up along with a few others in arch/powerpc.
Ahh, ok - Hadn't noticed - Sorry.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: 2.6.33 -next tree
From: Luotao Fu @ 2009-12-09 9:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911042210q5bbbca2fi82911b7245d17588@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> Hi Ben, Stephen.
>
> I just prepared my next branch for 2.6.33:
> git://git.secretlab.ca/git/linux-2.6 next
>
Just for curiosity: I noticed that you keep so far the further patches for the
dedicated spi controller on mpc5200 in the next-spi tree. Any plan when they
will be merged to the -next tree? Like mentioned before, some of them are
essential, without which the driver doesn't work (at least on my board)
sorry for nagging. ;-)
thanks
cheers
Luotao Fu
--
Pengutronix e.K. | Dipl.-Ing. Luotao Fu |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* RE: gianfar breaking builds
From: Benjamin Herrenschmidt @ 2009-12-09 9:26 UTC (permalink / raw)
To: Kumar Gopalpet-B05799; +Cc: linuxppc-dev
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81BA08A66@zin33exm22.fsl.freescale.net>
On Wed, 2009-12-09 at 14:20 +0530, Kumar Gopalpet-B05799 wrote:
> Hi Ben,
>
> Can you point to me from where you cloned the tree.
>
> Also, net-next-2.6 tree was building for me.
This is powerpc-next which contains the current Linus stuff plus the
pending powerpc stuff. If that's fixed in net-next then we shall wait
for Dave to merge it I suppose.
Cheers,
Ben.
> --
> Thanks
> Sandeep
>
> >-----Original Message-----
> >From:
> >linuxppc-dev-bounces+sandeep.kumar=freescale.com@lists.ozlabs.o
> >rg
> >[mailto:linuxppc-dev-bounces+sandeep.kumar=freescale.com@lists.
> >ozlabs.org] On Behalf Of Benjamin Herrenschmidt
> >Sent: Wednesday, December 09, 2009 12:27 PM
> >To: Kumar Gala
> >Cc: linuxppc-dev
> >Subject: gianfar breaking builds
> >
> >In my next (not pushed out yet as I'm writing this but will be
> >by the time you read it hopefully), I get a build failure:
> >
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c: In
> >function 'gfar_netpoll':
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2653:
> >error: invalid storage class for function 'gfar_interrupt'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2652:
> >warning: ISO C90 forbids mixed declarations and code
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2681:
> >error: invalid storage class for function 'adjust_link'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2764:
> >error: invalid storage class for function 'gfar_set_multi'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2855:
> >error: invalid storage class for function 'gfar_clear_exact_match'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2877:
> >error: invalid storage class for function 'gfar_set_hash_for_addr'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2898:
> >error: invalid storage class for function 'gfar_set_mac_for_addr'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2922:
> >error: invalid storage class for function 'gfar_error'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3017:
> >warning: 'alias' attribute ignored
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3032:
> >error: invalid storage class for function 'gfar_init'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3037:
> >error: invalid storage class for function 'gfar_exit'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:
> >error: invalid storage class for function '__inittest'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:
> >warning: 'alias' attribute ignored
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >error: invalid storage class for function '__exittest'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >warning: ISO C90 forbids mixed declarations and code
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >warning: 'alias' attribute ignored
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >error: expected declaration or statement at end of input
> >make[3]: *** [drivers/net/gianfar.o] Error 1
> >
> >Stephen says that breakage has been in -next for some time...
> >
> >Can you guys sort it out ?
> >
> >Cheers,
> >Ben.
> >
> >
> >_______________________________________________
> >Linuxppc-dev mailing list
> >Linuxppc-dev@lists.ozlabs.org
> >https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
^ permalink raw reply
* Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB
From: Joakim Tjernlund @ 2009-12-09 9:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1260348995.16132.37.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 09/12/2009 09:56:35:
>
> On Wed, 2009-12-09 at 08:39 +0100, Joakim Tjernlund wrote:
> > The later isn't as simple :) I believe the bulk of such code in
> > entry_32.S.
>
> Yeah but it would be useful for hash I suppose if one really wants to
> boot with nobats. Though at least on hash most of the time we have ways
> to recover by mean of MSR:RI being cleared, which your TLB miss code
> doesn't check...
Never looked at this so I cannot comment.
>
> > Anyhow, the config option is still valid as if enabled
> > it will pin several DTLB's too. Scott had some concerns about removing
> > the config option completely so this was the next best thing.
>
> Well, if you want to pin at least one entry, then just remove the #if
> completely but don't leave a #if 1 :-)
I could, but I wanted to have an easy way back to the old way if
the need arises.
Anyway, I am rather busy ATM with more pressing matters so I would
appreciate if you could take the patch as is.
Jocke
^ permalink raw reply
* RE: gianfar breaking builds
From: Kumar Gopalpet-B05799 @ 2009-12-09 9:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260350780.16132.40.camel@pasglop>
=20
>
>This is powerpc-next which contains the current Linus stuff=20
>plus the pending powerpc stuff. If that's fixed in net-next=20
>then we shall wait for Dave to merge it I suppose.
>
I din't notice that netpoll wa enabled in your compilation.
This is also not wotking on net-next tree.
Will send out a patch today in some time.
--
Thanks
Sandeep
^ permalink raw reply
* RE: gianfar breaking builds
From: Benjamin Herrenschmidt @ 2009-12-09 9:34 UTC (permalink / raw)
To: Kumar Gopalpet-B05799; +Cc: linuxppc-dev
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81BA08A6F@zin33exm22.fsl.freescale.net>
On Wed, 2009-12-09 at 15:02 +0530, Kumar Gopalpet-B05799 wrote:
>
> I din't notice that netpoll wa enabled in your compilation.
> This is also not wotking on net-next tree.
>
> Will send out a patch today in some time.
Ah yes, this is something close to a 6xx_defconfig. Thanks.
Cheers,
Ben.
^ permalink raw reply
* Problem in setting timeout from user space for MPC 83x watchdog timer
From: Aswathi C @ 2009-12-09 9:41 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
I am using MPC 8323E processor and linux-2.6.24 kernel.
I tried to set watchdog timer from user space using ioctl with the case
WDIOC_SETTIMEOUT.
I am getting timeout value as seconds and calculating corresponding modulus
for the WDT.
After that I am setting SWTC of SWCRR and writing service sequence to SWSRR.
But SWCNR is setting back to 0xffff after service sequence written into
SWSRR, means it is not setting with configured SWTC.
Can anyone tell what is the problem?
Please suggest solution..
Regards,
Aswathi
[-- Attachment #2: Type: text/html, Size: 561 bytes --]
^ permalink raw reply
* [PATCH] gianfar: Fix build with CONFIG_NET_POLL_CONTROLLER=y
From: Anton Vorontsov @ 2009-12-09 10:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Sandeep Gopalpet, netdev, linuxppc-dev, David Miller
In-Reply-To: <1260341804.16132.22.camel@pasglop>
commit 46ceb60ca80fa07703bc6eb8f4651f900dff5a82 ("gianfar: Add
Multiple group Support") introduced the following build error
with CONFIG_NET_POLL_CONTROLLER=y:
CC ggianfar.o
ggianfar.c: In function 'gfar_netpoll':
ggianfar.c:2653: error: invalid storage class for function 'gfar_interrupt'
ggianfar.c:2652: warning: ISO C90 forbids mixed declarations and code
ggianfar.c:2681: error: invalid storage class for function 'adjust_link'
ggianfar.c:2764: error: invalid storage class for function 'gfar_set_multi'
ggianfar.c:2855: error: invalid storage class for function 'gfar_clear_exact_match'
ggianfar.c:2877: error: invalid storage class for function 'gfar_set_hash_for_addr'
ggianfar.c:2898: error: invalid storage class for function 'gfar_set_mac_for_addr'
ggianfar.c:2922: error: invalid storage class for function 'gfar_error'
ggianfar.c:3020: warning: ISO C90 forbids mixed declarations and code
ggianfar.c:3032: error: invalid storage class for function 'gfar_init'
ggianfar.c:3037: error: invalid storage class for function 'gfar_exit'
ggianfar.c:3041: error: initializer element is not constant
ggianfar.c:3042: error: initializer element is not constant
ggianfar.c:3042: warning: ISO C90 forbids mixed declarations and code
ggianfar.c:3042: error: expected declaration or statement at end of input
make[1]: *** [ggianfar.o] Error 1
This patch fixes the issue.
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Wed, Dec 09, 2009 at 05:56:44PM +1100, Benjamin Herrenschmidt wrote:
> In my next (not pushed out yet as I'm writing this but will be by the
> time you read it hopefully), I get a build failure:
>
> /home/benh/linux-powerpc-test/drivers/net/gianfar.c: In function ‘gfar_netpoll’:
> /home/benh/linux-powerpc-test/drivers/net/gianfar.c:2653: error: invalid storage class for function ‘gfar_interrupt’
[...]
> make[3]: *** [drivers/net/gianfar.o] Error 1
>
> Stephen says that breakage has been in -next for some time...
>
> Can you guys sort it out ?
drivers/net/gianfar.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 16def13..6850dc0 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2644,6 +2644,7 @@ static void gfar_netpoll(struct net_device *dev)
gfar_interrupt(priv->gfargrp[i].interruptTransmit,
&priv->gfargrp[i]);
enable_irq(priv->gfargrp[i].interruptTransmit);
+ }
}
}
#endif
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] gianfar: Fix build with CONFIG_NET_POLL_CONTROLLER=y
From: David Miller @ 2009-12-09 10:52 UTC (permalink / raw)
To: avorontsov; +Cc: Sandeep.Kumar, linuxppc-dev, netdev
In-Reply-To: <20091209104427.GA25526@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed, 9 Dec 2009 13:44:27 +0300
> commit 46ceb60ca80fa07703bc6eb8f4651f900dff5a82 ("gianfar: Add
> Multiple group Support") introduced the following build error
> with CONFIG_NET_POLL_CONTROLLER=y:
...
> This patch fixes the issue.
>
> Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, but this shows that netconsole needs some serious
testing with this drive now :-/
Thanks.
^ permalink raw reply
* Re: 2.6.33 -next tree
From: Grant Likely @ 2009-12-09 13:40 UTC (permalink / raw)
To: Luotao Fu; +Cc: linuxppc-dev
In-Reply-To: <4B1F6D3A.3030500@pengutronix.de>
On Wed, Dec 9, 2009 at 2:26 AM, Luotao Fu <l.fu@pengutronix.de> wrote:
> Hi Grant,
>
> Grant Likely wrote:
>> Hi Ben, Stephen.
>>
>> I just prepared my next branch for 2.6.33:
>> git://git.secretlab.ca/git/linux-2.6 next
>>
>
> Just for curiosity: I noticed that you keep so far the further patches for the
> dedicated spi controller on mpc5200 in the next-spi tree. Any plan when they
> will be merged to the -next tree? Like mentioned before, some of them are
> essential, without which the driver doesn't work (at least on my board)
I based the next-spi tree on my regular next tree (which was
convenient, but lead to it looking like I had inappropriate stuff in
my spi tree). Once Ben asks Linus to pull his tree it will all look
correct. I'll ask Linux to pull my next-spi tree directly after Ben's
tree is in.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: [PATCH] gianfar: Fix build with CONFIG_NET_POLL_CONTROLLER=y
From: Kumar Gopalpet-B05799 @ 2009-12-09 13:55 UTC (permalink / raw)
To: avorontsov; +Cc: David Miller, linuxppc-dev, netdev
In-Reply-To: <20091209.025245.152622485.davem@davemloft.net>
=20
>From: Anton Vorontsov <avorontsov@ru.mvista.com>
>Date: Wed, 9 Dec 2009 13:44:27 +0300
>
>> commit 46ceb60ca80fa07703bc6eb8f4651f900dff5a82 ("gianfar: Add=20
>> Multiple group Support") introduced the following build error with=20
>> CONFIG_NET_POLL_CONTROLLER=3Dy:
> ...
>> This patch fixes the issue.
>>=20
>> Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
Thanks Anton !
^ permalink raw reply
* MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Roman Fietze @ 2009-12-09 14:29 UTC (permalink / raw)
To: linuxppc-dev
Hallo,
I had a discussion with some Freescale support people about the
constant RFIFO Event errors or PATA hard disk crashes when stressing a
board with (very) high loads, in my case even with some additional
traffic from an FPGA (or just the FLASH) via the SCLPC FIFO using the
BestComm.
The latest recommendation from Freescale was to set BSDIS and PLDIS
and to clear SE, resulting in a XLB config register value of
0x80012006, at least for my MPC5200B PVR/SVR of
0x80822014/0x80110022. If I am correct, the current XLB config setting
using the current U-Boot and kernel is 0x0000a006.
In order to get cache coherency I had to set
CONFIG_NOT_COHERENT_CACHE=3Dy for the MPC5200B boards. Please correct me
if I am wrong with this assumption.
With this setup, XLB config and kernel config, I do no longer have any
PATA crashes, I do no longer have any FEC RFIFO errors, and my SCLPC
driver runs w/o problems, too.
I would be interested in your opinion, maybe Wolfgang could make some
comments, because he is involved in the U-Boot a lot as well.
Here is the original text from the Freescale support person:
=2D- snippety snip --
Dear Roman Fietze,=20
In reply to your message regarding Service Request SR 1-597437219:
Disable pipelining also. Test your software using the following
setting of the XLB arbiter: 0x80012006.
We have request from a customer with similar problem. Problem
disappeared if XLB pipelining and BestComm snooping were disabled.
Should you need to contact us with regard to this message, please see
the notes below.
Best Regards,=20
Pavel=20
Technical Support
=46reescale Semiconductor
=2D- snappety snap --
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* Re: [PATCH] powerpc: Increase warp SD buffer
From: Josh Boyer @ 2009-12-09 14:40 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20091209000437.78794a8f@opus.seanm.ca>
On Wed, Dec 09, 2009 at 12:04:37AM -0500, Sean MacLennan wrote:
>Newer revs of the FPGA have a larger SD buffer.
How does that impact the older revisions? You're using a cuImage with Warp,
so the device tree is bundled with that. If you boot a new kernel with this
change to the DTS on a older board revision, will it do bad things?
josh
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Wolfram Sang @ 2009-12-09 14:57 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <200912091529.13913.roman.fietze@telemotive.de>
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hello Roman,
> I would be interested in your opinion, maybe Wolfgang could make some
> comments, because he is involved in the U-Boot a lot as well.
Do you have a way to measure performance penalties? I know that stability comes
before performance, still I am wondering as it looks to me that the most
interesting features are simply switched off.
Regrads,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Increase warp SD buffer
From: Sean MacLennan @ 2009-12-09 15:36 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
In-Reply-To: <20091209144055.GS2937@zod.rchland.ibm.com>
On Wed, 9 Dec 2009 09:40:55 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> How does that impact the older revisions? You're using a cuImage
> with Warp, so the device tree is bundled with that. If you boot a
> new kernel with this change to the DTS on a older board revision,
> will it do bad things?
The new SD driver takes care of that. If you use the new kernel with an
old FPGA you reserve more space than you need, but the driver will not
touch it.
And if you somehow end up with the new DTS on an older kernel, the old
SD driver will not use the space anyway since the buffer is limited to
one block.
The SD driver is not in the kernel proper because it was implemented in
the FPGA and has a non-standard interface. It requires a change to the
SD core to run. But it is GPLed, so if anybody wants to see it, just
ask.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] powerpc: Increase warp SD buffer
From: Josh Boyer @ 2009-12-09 15:47 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20091209103645.01058e79@opus.seanm.ca>
On Wed, Dec 09, 2009 at 10:36:45AM -0500, Sean MacLennan wrote:
>On Wed, 9 Dec 2009 09:40:55 -0500
>Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
>> How does that impact the older revisions? You're using a cuImage
>> with Warp, so the device tree is bundled with that. If you boot a
>> new kernel with this change to the DTS on a older board revision,
>> will it do bad things?
>
>The new SD driver takes care of that. If you use the new kernel with an
>old FPGA you reserve more space than you need, but the driver will not
>touch it.
>
>And if you somehow end up with the new DTS on an older kernel, the old
>SD driver will not use the space anyway since the buffer is limited to
>one block.
>
>The SD driver is not in the kernel proper because it was implemented in
>the FPGA and has a non-standard interface. It requires a change to the
>SD core to run. But it is GPLed, so if anybody wants to see it, just
>ask.
OK thanks. I figured something like that would be the case, but wanted to
verify first.
josh
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Torsten Fleischer @ 2009-12-09 15:49 UTC (permalink / raw)
To: Grant Likely; +Cc: avorontsov
In-Reply-To: <fa686aa40911261117y4744e56bmf4d1d8260c7a51d0@mail.gmail.com>
On Thu, Nov 26, 2009 at 20:17:35, Grant Likely wrote:
[...]
> spi-cs-high is definitely not a complete solution, but it isn't
> actively evil either. Plus it is documented and (presumably) in
> active use. so support for it should not be dropped.
>
> Regardless, there needs to be a library function for parsing all the
> SPI child nodes and returning the active state for each GPIO chip
> select. All the code for parsing the old spi-cs-high properties can
> be contained in the same place as a new yet-to-be-defined bus node cs
> polarity property. The rework to the driver itself is not ugly.
>
The following patch adds a function to get the active state of the chip select
of a SPI device by looking for the 'spi-cs-high' property in the associated device
tree node.
This function is used by the spi_mpc8xxx driver to set a proper initial value
to the associated GPIOs.
Signed-off-by: Torsten Fleischer <to-fleischer@t-online.de>
---
diff -ruN linux-2.6.32_orig//drivers/of/of_spi.c linux-2.6.32/drivers/of/of_spi.c
--- linux-2.6.32_orig//drivers/of/of_spi.c 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/drivers/of/of_spi.c 2009-12-09 12:37:01.000000000 +0100
@@ -10,6 +10,49 @@
#include <linux/device.h>
#include <linux/spi/spi.h>
#include <linux/of_spi.h>
+#include <linux/errno.h>
+
+/**
+ * of_get_spi_cs_active_state - Gets the chip select's active state of a SPI
+ * child devices.
+ * @np: parent node of the SPI device nodes
+ * @index: index/address of the SPI device (refers to the 'reg' property)
+ * @cs_active: pointer to return the chip select's active state
+ * (true = active high; false = active low)
+ *
+ * Returns 0 on success; negative errno on failure
+ */
+int of_get_spi_cs_active_state(struct device_node *np, int index, bool *cs_active)
+{
+ struct device_node *child;
+ const int *prop;
+ int len;
+ bool active = 0;
+
+ /* search for the matching SPI device */
+ for_each_child_of_node(np, child) {
+ prop = of_get_property(child, "reg", &len);
+ if (!prop || len < sizeof(*prop)) {
+ /* property 'reg' not available (not an error) */
+ continue;
+ }
+
+ if ( *prop == index ) {
+ /* matching device found */
+ if (of_find_property(child, "spi-cs-high", NULL))
+ active = 1;
+
+ if (cs_active)
+ *cs_active = active;
+
+ return 0;
+ }
+ }
+
+ return -ENODEV;
+}
+EXPORT_SYMBOL(of_get_spi_cs_active_state);
+
/**
* of_register_spi_devices - Register child devices onto the SPI bus
diff -ruN linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c linux-2.6.32/drivers/spi/spi_mpc8xxx.c
--- linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/drivers/spi/spi_mpc8xxx.c 2009-12-09 12:50:36.000000000 +0100
@@ -705,6 +705,7 @@
for (; i < ngpios; i++) {
int gpio;
enum of_gpio_flags flags;
+ bool astate;
gpio = of_get_gpio_flags(np, i, &flags);
if (!gpio_is_valid(gpio)) {
@@ -721,8 +722,15 @@
pinfo->gpios[i] = gpio;
pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+ ret = of_get_spi_cs_active_state(np, i, &astate);
+ if (ret) {
+ dev_err(dev, "can't get cs active state of device "
+ "#%d: %d\n", i, ret);
+ goto err_loop;
+ }
+
ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
+ pinfo->alow_flags[i] ^ !astate);
if (ret) {
dev_err(dev, "can't set output direction for gpio "
"#%d: %d\n", i, ret);
diff -ruN linux-2.6.32_orig//include/linux/of_spi.h linux-2.6.32/include/linux/of_spi.h
--- linux-2.6.32_orig//include/linux/of_spi.h 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/include/linux/of_spi.h 2009-12-09 12:36:48.000000000 +0100
@@ -15,4 +15,7 @@
extern void of_register_spi_devices(struct spi_master *master,
struct device_node *np);
+extern int of_get_spi_cs_active_state(struct device_node *np,
+ int index, bool *cs_active);
+
#endif /* __LINUX_OF_SPI */
^ permalink raw reply
* Re: [PATCH 6/8] Use proper types for do_div
From: Mark Wielaard @ 2009-12-09 15:56 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, systemtap
In-Reply-To: <20091127223347.GF21805@oksana.dev.rtsoft.ru>
Hi Anton,
On Sat, 2009-11-28 at 01:33 +0300, Anton Vorontsov wrote:
> do_div accepts unsigned 64-bit integer type for dividend, signed types
> would cause do_div's typecheck fail:
>
> stat-common.c: In function 'needed_space':
> stat-common.c:50: error: comparison of distinct pointer types lacks a cast
> ...same errors in time.c and tapset-timers.cxx's generated code...
>
> A fix for time.c is special, on ppc32 cycles_t is 32-bit, so technically
> we don't need do_div, but since the whole _stp_gettimeofday_ns() operates
> on 64-bit types we'd better be safe and use uint64_t for the math.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> runtime/stat-common.c | 8 ++++----
> runtime/time.c | 3 ++-
> tapset-timers.cxx | 2 +-
> 3 files changed, 7 insertions(+), 6 deletions(-)
I don't immediately see anything wrong with the code. But on x86_64 this
does cause some regression test failures in testsuite/systemtap.maps. In
particular the following tests now fail (they all pass with this one
patch reverted):
Running /home/mark/src/systemtap/testsuite/systemtap.maps/elision.exp ...
FAIL: elision-1
FAIL: elision0
FAIL: elision1
FAIL: elision2
FAIL: elision3
Running /home/mark/src/systemtap/testsuite/systemtap.maps/ix.exp ...
FAIL: systemtap.maps/ix.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/linear_large_neg.exp ...
FAIL: systemtap.maps/linear_large_neg.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/linear_overunder.exp ...
FAIL: systemtap.maps/linear_overunder.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/linear_under.exp ...
FAIL: systemtap.maps/linear_under.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/log.exp ...
FAIL: systemtap.maps/log.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/log_edge.exp ...
FAIL: systemtap.maps/log_edge.stp
Could you have a look?
Thanks,
Mark
^ 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