* Re: Dynamic-ftrace not working in PlayStation3
From: Remis @ 2009-02-01 13:28 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, Steven Rostedt
In-Reply-To: <200901311125.34755.arnd@arndb.de>
Complementing what Arnd said, we got the dynamic ftrace to work. Just
changed 4 things in the *menuconfig*.
Before these were built as modules (this is the default I guess):
CONFIG_USB=m
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_USB_AUDIO=m
Then got them built into the kernel:
CONFIG_USB=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_USB_AUDIO=y
And everything worked just fine.
In my config when I also tried to build the *CONFIG_SND_PS3* into the
kernel, the kernel did not boot (probably another bug !? :-).
Cheers,
Remis
On Sat, Jan 31, 2009 at 11:25 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 31 January 2009, Geoff Levand wrote:
>> >
>> > So I take it that the above showed that the code worked for some?
>>
>> In my trials it blows up on the first load_module() call, and for my
>> config that was usbcore:
>
> I looked into it some more with Remis yesterday, and we got ftrace
> working by building usbcore and alsa into the kernel. Incidentally,
> usbcore is the largest module in this installation (~3MB), which
> indicates that it is in some way either related to the size of the
> module.
>
>> This ptr of 5f666f725f726573 seems bogus. I think this code is not
>> working correctly:
>
> This is an ascii string "_for_res", probably part of
> usb_lock_device_for_reset. We saw the same behaviour, but
> a different string.
>
> Arnd <><
^ permalink raw reply
* Re: [PATCH] gianfar: Fix sparse warnings
From: David Miller @ 2009-02-01 8:54 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, afleming, jgarzik, netdev
In-Reply-To: <20090128205220.GA25701@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed, 28 Jan 2009 23:52:20 +0300
> This patch fixes following sparse warnings:
...
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH -next 2/2] phylib: Rework suspend/resume code to check netdev wakeup capability
From: David Miller @ 2009-02-01 8:54 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, afleming, netdev, jgarzik, peppe.cavallaro
In-Reply-To: <20090128203914.GB14693@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed, 28 Jan 2009 23:39:14 +0300
> In most cases (e.g. PCI drivers) MDIO and MAC controllers are
> represented by the same device. But for SOC ethernets we have
> separate devices. So, in SOC case, checking whether MDIO
> controller may wakeup is not only makes little sense, but also
> prevents us from doing per-netdevice wakeup management.
>
> This patch reworks suspend/resume code so that now it checks
> for net device's wakeup flags, not MDIO controller's ones.
>
> Each netdevice should manage its wakeup flags, and phylib will
> decide whether suspend an attached PHY or not.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next 1/2] gianfar: Implement proper, per netdevice wakeup management
From: David Miller @ 2009-02-01 8:54 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, afleming, netdev, jgarzik, peppe.cavallaro
In-Reply-To: <20090128203854.GA14693@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed, 28 Jan 2009 23:38:54 +0300
> This patch implements wakeup management for the gianfar driver.
>
> The driver should set wakeup enable if WOL is enabled, so that
> phylib won't power off an attached PHY.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2] powerpc/5200: Rework GPT driver to also be an IRQ controller
From: Wolfram Sang @ 2009-01-31 20:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20090127163022.32583.85199.stgit@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 22423 bytes --]
Hi Grant,
this one had more issues. It feels a bit rushed... (and I added
linuxppc-dev to CC as it was mentioned below).
On Tue, Jan 27, 2009 at 09:30:22AM -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> This patch adds IRQ controller support to the MPC5200 General
> Purpose Timer (GPT) device driver. With this patch the mpc5200-gpt
> driver supports both GPIO and IRQ functions.
>
> The GPT driver was contained within the mpc52xx_gpio.c file, but this
> patch moves it out into a new file (mpc52xx_gpt.c) since it has more
> than just GPIO functionality now and it was only grouped with the
> mpc52xx-gpio drivers as a matter of convenience before. Also, this
> driver will most likely get extended again to also provide support
> for the timer function.
>
> Implementation note: Alternately, I could have tried to implement
> the IRQ support as a separate driver and left the GPIO portion alone.
> However, multiple functions of this device (ie. GPIO input+interrupt
> controller, or timer+GPIO) can be active at the same time and the
> registers are shared so it is safer to contain all functionality
> within a single driver.
>
> Changes since v1:
> - Removed magic numbers
> - Only set to GPIO mode if it has the gpio-controller property. Otherwise
> leave the configuration alone. Firmware may have already configured it.
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> CC: Wolfram Sang <w.sang@pengutronix.de>
> CC: linuxppc-dev@ozlabs.org
> ---
>
> arch/powerpc/platforms/52xx/Makefile | 2
> arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 85 -----
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 449 ++++++++++++++++++++++++++++
> 3 files changed, 450 insertions(+), 86 deletions(-)
> create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpt.c
>
>
> diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
> index 9dfbde2..bfd4f52 100644
> --- a/arch/powerpc/platforms/52xx/Makefile
> +++ b/arch/powerpc/platforms/52xx/Makefile
> @@ -1,7 +1,7 @@
> #
> # Makefile for 52xx based boards
> #
> -obj-y += mpc52xx_pic.o mpc52xx_common.o
> +obj-y += mpc52xx_pic.o mpc52xx_common.o mpc52xx_gpt.o
> obj-$(CONFIG_PCI) += mpc52xx_pci.o
>
> obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> index 07f89ae..2b8d8ef 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> @@ -354,88 +354,6 @@ static struct of_platform_driver mpc52xx_simple_gpiochip_driver = {
> .remove = mpc52xx_gpiochip_remove,
> };
>
> -/*
> - * GPIO LIB API implementation for gpt GPIOs.
> - *
> - * Each gpt only has a single GPIO.
> - */
> -static int mpc52xx_gpt_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> -{
> - struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> - struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
> -
> - return (in_be32(®s->status) & (1 << (31 - 23))) ? 1 : 0;
> -}
> -
> -static void
> -mpc52xx_gpt_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> -{
> - struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> - struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
> -
> - if (val)
> - out_be32(®s->mode, 0x34);
> - else
> - out_be32(®s->mode, 0x24);
> -
> - pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
> -}
> -
> -static int mpc52xx_gpt_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> -{
> - struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> - struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
> -
> - out_be32(®s->mode, 0x04);
> -
> - return 0;
> -}
> -
> -static int
> -mpc52xx_gpt_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> -{
> - mpc52xx_gpt_gpio_set(gc, gpio, val);
> - pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
> -
> - return 0;
> -}
> -
> -static int __devinit mpc52xx_gpt_gpiochip_probe(struct of_device *ofdev,
> - const struct of_device_id *match)
> -{
> - struct of_mm_gpio_chip *mmchip;
> - struct of_gpio_chip *chip;
> -
> - mmchip = kzalloc(sizeof(*mmchip), GFP_KERNEL);
> - if (!mmchip)
> - return -ENOMEM;
> -
> - chip = &mmchip->of_gc;
> -
> - chip->gpio_cells = 2;
> - chip->gc.ngpio = 1;
> - chip->gc.direction_input = mpc52xx_gpt_gpio_dir_in;
> - chip->gc.direction_output = mpc52xx_gpt_gpio_dir_out;
> - chip->gc.get = mpc52xx_gpt_gpio_get;
> - chip->gc.set = mpc52xx_gpt_gpio_set;
> -
> - return of_mm_gpiochip_add(ofdev->node, mmchip);
> -}
> -
> -static const struct of_device_id mpc52xx_gpt_gpiochip_match[] = {
> - {
> - .compatible = "fsl,mpc5200-gpt-gpio",
> - },
> - {}
> -};
> -
> -static struct of_platform_driver mpc52xx_gpt_gpiochip_driver = {
> - .name = "gpio_gpt",
> - .match_table = mpc52xx_gpt_gpiochip_match,
> - .probe = mpc52xx_gpt_gpiochip_probe,
> - .remove = mpc52xx_gpiochip_remove,
> -};
> -
> static int __init mpc52xx_gpio_init(void)
> {
> if (of_register_platform_driver(&mpc52xx_wkup_gpiochip_driver))
> @@ -444,9 +362,6 @@ static int __init mpc52xx_gpio_init(void)
> if (of_register_platform_driver(&mpc52xx_simple_gpiochip_driver))
> printk(KERN_ERR "Unable to register simple GPIO driver\n");
>
> - if (of_register_platform_driver(&mpc52xx_gpt_gpiochip_driver))
> - printk(KERN_ERR "Unable to register gpt GPIO driver\n");
> -
> return 0;
> }
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> new file mode 100644
> index 0000000..bc253a7
> --- /dev/null
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> @@ -0,0 +1,449 @@
> +/*
> + * MPC5200 General Purpose Timer device driver
> + *
> + * Copyright (c) 2009 Secret Lab Technologies Ltd.
> + * Copyright (c) 2008 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
> + *
> + * 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.
> + *
> + * This file is a driver for the the General Purpose Timer (gpt) devices
> + * found on the MPC5200 SoC. Each timer has an IO pin which can be used
> + * for GPIO or can be used to raise interrupts. The timer function can
> + * be used independently from the IO pin, or it can be used to control
> + * output signals or measure input signals.
> + *
> + * This driver supports the GPIO and IRQ controller functions of the GPT
> + * device. Timer functions are not yet supported, nor is the watchdog
> + * timer.
> + *
> + * To use the GPIO function, the following two properties must be added
> + * to the device tree node for the gpt device (typically in the .dts file
> + * for the board):
> + * gpio-controller;
> + * #gpio-cells = < 2 >;
> + * This driver will register the GPIO pin if it finds the gpio-controller
> + * property in the device tree.
> + *
> + * To use the IRQ controller function, the following two properties must
> + * be added to the device tree node for the gpt device:
> + * interrupt-controller;
> + * #interrupt-cells = < 1 >;
> + * The IRQ controller binding only uses one cell to specify the interrupt,
> + * and the IRQ flags are encoded in the cell. A cell is not used to encode
> + * the IRQ number because the GPT only has a single IRQ source. For flags,
> + * a value of '1' means rising edge sensitive and '2' means falling edge.
> + *
> + * The GPIO and the IRQ controller functions can be used at the same time,
> + * but in this use case the IO line will only work as an input. Trying to
> + * use it as a GPIO output will not work.
> + *
> + * When using the GPIO line as an output, it can either be driven as normal
> + * IO, or it can be an OC output. At the moment it is the responsibility
Not quite sure, but maybe OC can be written in its long form to ease
understanding.
> + * of the bootloader or the platform setup code to set the output mode.
> + * This driver does not change the output mode setting.
> + */
> +
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_gpio.h>
> +#include <linux/kernel.h>
> +
> +#include <asm/time.h>
checkpatch asks if linux/time.h will do?
> +#include <asm/prom.h>
> +#include <asm/machdep.h>
> +#include <asm/mpc52xx.h>
> +
> +MODULE_DESCRIPTION("Freescale MPC52xx gpt driver");
> +MODULE_AUTHOR("Sascha Hauer, Grant Likely");
> +MODULE_LICENSE("GPL");
> +
> +/**
> + * struct mpc52xx_gpt - Private data structure for MPC52xx GPT driver
> + * @dev: pointer to device structure
> + * @regs: virtual address of GPT registers
@lock is missing here.
> + * @of_gc: of_gpio_chip instance structure; used when GPIO is enabled
> + * @irqhost: Pointer to irq_host instance; used when IRQ mode is supported
> + */
> +struct mpc52xx_gpt_priv {
> + struct device *dev;
> + struct mpc52xx_gpt __iomem *regs;
> + spinlock_t lock;
> + struct of_gpio_chip of_gc;
> + struct irq_host *irqhost;
> +};
> +
> +#define MPC52xx_GPT_MODE_MS_MASK (0x07)
> +#define MPC52xx_GPT_MODE_MS_IC (0x01)
> +#define MPC52xx_GPT_MODE_MS_OC (0x02)
> +#define MPC52xx_GPT_MODE_MS_PWM (0x03)
> +#define MPC52xx_GPT_MODE_MS_GPIO (0x04)
> +
> +#define MPC52xx_GPT_MODE_GPIO_MASK (0x30)
> +#define MPC52xx_GPT_MODE_GPIO_OUT_LOW (0x20)
> +#define MPC52xx_GPT_MODE_GPIO_OUT_HIGH (0x30)
> +
> +#define MPC52xx_GPT_MODE_IRQ_EN (0x0100)
> +
> +#define MPC52xx_GPT_MODE_ICT_MASK (0x030000)
> +#define MPC52xx_GPT_MODE_ICT_RISING (0x010000)
> +#define MPC52xx_GPT_MODE_ICT_FALLING (0x020000)
> +#define MPC52xx_GPT_MODE_ICT_TOGGLE (0x030000)
> +
> +/* ---------------------------------------------------------------------
> + * Cascaded interrupt controller hooks
> + */
> +
> +static void mpc52xx_gpt_irq_unmask(unsigned int virq)
> +{
> + struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(virq);
> + unsigned long flags;
> + u32 val;
> +
> + spin_lock_irqsave(&gpt->lock, flags);
> + val = in_be32(&gpt->regs->mode) | MPC52xx_GPT_MODE_IRQ_EN;
> + out_be32(&gpt->regs->mode, val);
setbits32 (from <asm/io.h>)?
> + spin_unlock_irqrestore(&gpt->lock, flags);
> +}
> +
> +static void mpc52xx_gpt_irq_mask(unsigned int virq)
> +{
> + struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(virq);
> + unsigned long flags;
> + u32 val;
> +
> + spin_lock_irqsave(&gpt->lock, flags);
> + val = in_be32(&gpt->regs->mode) & ~MPC52xx_GPT_MODE_IRQ_EN;
> + out_be32(&gpt->regs->mode, val);
clrbits32?
> + spin_unlock_irqrestore(&gpt->lock, flags);
> +}
> +
> +static void mpc52xx_gpt_irq_ack(unsigned int virq)
> +{
> + struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(virq);
> +
> + out_be32(&gpt->regs->status, 0xf);
One magic value left.
> +}
> +
> +static int mpc52xx_gpt_irq_set_type(unsigned int virq, unsigned int flow_type)
> +{
> + struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(virq);
> + unsigned long flags;
> + u32 reg;
> +
> + dev_dbg(gpt->dev, "%s: virq=%i type=%x\n", __func__, virq, flow_type);
> +
> + spin_lock_irqsave(&gpt->lock, flags);
> + reg = in_be32(&gpt->regs->mode) & ~MPC52xx_GPT_MODE_ICT_MASK;
> + if (flow_type & IRQF_TRIGGER_RISING)
> + reg |= MPC52xx_GPT_MODE_ICT_RISING;
> + if (flow_type & IRQF_TRIGGER_FALLING)
> + reg |= MPC52xx_GPT_MODE_ICT_FALLING;
> + out_be32(&gpt->regs->mode, reg);
> + spin_unlock_irqrestore(&gpt->lock, flags);
> +
> + return 0;
> +}
> +
> +static struct irq_chip mpc52xx_gpt_irq_chip = {
> + .typename = "MPC52xx GPT",
> + .unmask = mpc52xx_gpt_irq_unmask,
> + .mask = mpc52xx_gpt_irq_mask,
> + .ack = mpc52xx_gpt_irq_ack,
> + .set_type = mpc52xx_gpt_irq_set_type,
> +};
> +
> +void mpc52xx_gpt_irq_cascade(unsigned int virq, struct irq_desc *desc)
> +{
> + struct mpc52xx_gpt_priv *gpt = get_irq_data(virq);
> + int sub_virq;
> + u32 status;
> +
> + /* Ask the FPGA for IRQ status. If 'val' is 0, then no irqs
> + * are pending. 'ffs()' is 1 based */
> + status = in_be32(&gpt->regs->status) | 0xF;
> + if (status) {
Which FPGA? Why ffs (not used here)? if is always true? Or do you mean
'& 0xF' above? Looks a bit like leftovers which makes it confusing to
follow the rest of the code.
> + sub_virq = irq_linear_revmap(gpt->irqhost, 0);
> + generic_handle_irq(sub_virq);
> + }
> +}
> +
> +static int mpc52xx_gpt_irq_map(struct irq_host *h, unsigned int virq,
> + irq_hw_number_t hw)
> +{
> + struct mpc52xx_gpt_priv *gpt = h->host_data;
> +
> + dev_dbg(gpt->dev, "%s: h=%p, virq=%i\n", __func__, h, virq);
> + set_irq_chip_data(virq, gpt);
> + set_irq_chip_and_handler(virq, &mpc52xx_gpt_irq_chip, handle_edge_irq);
> +
> + return 0;
> +}
> +
> +static int mpc52xx_gpt_irq_xlate(struct irq_host *h, struct device_node *ct,
> + u32 *intspec, unsigned int intsize,
> + irq_hw_number_t *out_hwirq,
> + unsigned int *out_flags)
> +{
> + struct mpc52xx_gpt_priv *gpt = h->host_data;
> +
> + dev_dbg(gpt->dev, "%s: flags=%i\n", __func__, intspec[0]);
> +
> + if ((intsize < 1) || (intspec[0] < 1) || (intspec[0] > 3)) {
> + dev_err(gpt->dev, "bad irq specifier in %s\n", ct->full_name);
> + return -ENODEV;
-EINVAL?
> + }
> +
> + *out_hwirq = 0; /* The GPT only has 1 IRQ line */
> + *out_flags = intspec[0];
> +
> + WARN_ON(*out_flags == 0);
Isn't this already covered by the if above?
> +
> + return 0;
> +}
> +
> +static struct irq_host_ops mpc52xx_gpt_irq_ops = {
> + .map = mpc52xx_gpt_irq_map,
> + .xlate = mpc52xx_gpt_irq_xlate,
> +};
> +
> +static void
> +mpc52xx_gpt_irq_setup(struct mpc52xx_gpt_priv *gpt, struct device_node *node)
> +{
> + int cascade_virq;
> + unsigned long flags;
> + u32 val;
> +
> + /* Only setup cascaded IRQ if device tree claims the GPT is
> + * an interrupt controller */
> + if (!of_find_property(node, "interrupt-controller", NULL))
> + return;
> +
> + cascade_virq = irq_of_parse_and_map(node, 0);
> +
> + gpt->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR, 1,
> + &mpc52xx_gpt_irq_ops, -1);
> + if (!gpt->irqhost) {
> + dev_err(gpt->dev, "irq_alloc_host() failed\n");
> + return;
> + }
> +
> + gpt->irqhost->host_data = gpt;
> +
> + set_irq_data(cascade_virq, gpt);
> + set_irq_chained_handler(cascade_virq, mpc52xx_gpt_irq_cascade);
> +
> + /* Set to Input Capture mode */
> + spin_lock_irqsave(&gpt->lock, flags);
> + val = in_be32(&gpt->regs->mode) & ~MPC52xx_GPT_MODE_MS_MASK;
> + out_be32(&gpt->regs->mode, val | MPC52xx_GPT_MODE_MS_IC);
clrsetbits_be32(&gpt->regs->mode, MPC52xx_GPT_MODE_MS_MASK,
MPC52xx_GPT_MODE_MS_IC);
> + spin_unlock_irqrestore(&gpt->lock, flags);
> +
> + dev_dbg(gpt->dev, "%s() complete. virq=%i\n", __func__, cascade_virq);
> +
> + return;
You didn't use return in the other void-functions.
> +}
> +
> +
> +/* ---------------------------------------------------------------------
> + * GPIOLIB hooks
> + */
> +#if defined(CONFIG_GPIOLIB)
> +static inline struct mpc52xx_gpt_priv *gc_to_mpc52xx_gpt(struct gpio_chip *gc)
> +{
> + return container_of(to_of_gpio_chip(gc), struct mpc52xx_gpt_priv,of_gc);
Space after ',' !
> +}
> +
> +static int mpc52xx_gpt_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct mpc52xx_gpt_priv *gpt = gc_to_mpc52xx_gpt(gc);
> +
> + return (in_be32(&gpt->regs->status) >> 8) & 1;
> +}
> +
> +static void
> +mpc52xx_gpt_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + struct mpc52xx_gpt_priv *gpt = gc_to_mpc52xx_gpt(gc);
> + unsigned long flags;
> + u32 r;
> +
> + dev_dbg(gpt->dev, "%s: gpio:%d val:%d\n", __func__, gpio, val);
> +
> + spin_lock_irqsave(&gpt->lock, flags);
> + r = in_be32(&gpt->regs->mode) & ~MPC52xx_GPT_MODE_GPIO_MASK;
> + if (val)
> + out_be32(&gpt->regs->mode, r | MPC52xx_GPT_MODE_GPIO_OUT_HIGH);
> + else
> + out_be32(&gpt->regs->mode, r | MPC52xx_GPT_MODE_GPIO_OUT_LOW);
What about this?
clrsetbits_be32(&gpt->regs->mode, MPC52xx_GPT_MODE_GPIO_MASK,
val ? MPC52xx_GPT_MODE_GPIO_OUT_HIGH : MPC52xx_GPT_MODE_GPIO_OUT_LOW);
(Possibly, it can be broken better to make it more readable)
> + spin_unlock_irqrestore(&gpt->lock, flags);
> +}
> +
> +static int mpc52xx_gpt_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct mpc52xx_gpt_priv *gpt = gc_to_mpc52xx_gpt(gc);
> + unsigned long flags;
> + u32 tmp;
> +
> + dev_dbg(gpt->dev, "%s: gpio:%d\n", __func__, gpio);
> +
> + spin_lock_irqsave(&gpt->lock, flags);
> + tmp = in_be32(&gpt->regs->mode) & ~MPC52xx_GPT_MODE_GPIO_MASK;
> + out_be32(&gpt->regs->mode, tmp);
clrbits32
> + spin_unlock_irqrestore(&gpt->lock, flags);
> +
> + return 0;
> +}
> +
> +static int
> +mpc52xx_gpt_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + mpc52xx_gpt_gpio_set(gc, gpio, val);
> + return 0;
> +}
> +
> +static void
> +mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *gpt, struct device_node *node)
> +{
> + int rc;
> + u32 val;
> +
> + /* Only setup GPIO if the device tree claims the GPT is
> + * a GPIO controller */
> + if (!of_find_property(node, "gpio-controller", NULL))
> + return;
> +
> + gpt->of_gc.gc.label = kstrdup(node->full_name, GFP_KERNEL);
> + if (!gpt->of_gc.gc.label) {
> + dev_err(gpt->dev, "out of memory\n");
> + return;
-ENOMEM would be nice here. And then check for it in the calling
function.
> + }
> +
> + gpt->of_gc.gpio_cells = 2;
> + gpt->of_gc.gc.ngpio = 1;
> + gpt->of_gc.gc.direction_input = mpc52xx_gpt_gpio_dir_in;
> + gpt->of_gc.gc.direction_output = mpc52xx_gpt_gpio_dir_out;
> + gpt->of_gc.gc.get = mpc52xx_gpt_gpio_get;
> + gpt->of_gc.gc.set = mpc52xx_gpt_gpio_set;
> + gpt->of_gc.gc.base = -1;
> + gpt->of_gc.xlate = of_gpio_simple_xlate;
> + node->data = &gpt->of_gc;
> + of_node_get(node);
> +
> + /* Setup external pin in GPIO mode */
> + val = in_be32(&gpt->regs->mode) & ~MPC52xx_GPT_MODE_MS_MASK;
> + out_be32(&gpt->regs->mode, val | MPC52xx_GPT_MODE_MS_GPIO);
clrsetbits_be32
> +
> + rc = gpiochip_add(&gpt->of_gc.gc);
> + if (rc)
> + dev_err(gpt->dev, "gpiochip_add() failed; rc=%i\n", rc);
return -Esomething?
> +
> + dev_dbg(gpt->dev, "%s() complete.\n", __func__);
> +}
> +#else /* defined(CONFIG_GPIOLIB) */
> +static void
> +mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *, struct device_node *) { }
> +#endif /* defined(CONFIG_GPIOLIB) */
> +
> +/***********************************************************************
> + * SYSFS attributes
> + */
> +#if defined(CONFIG_SYSFS)
> +static ssize_t mpc52xx_gpt_show_regs(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct mpc52xx_gpt_priv *gpt = dev_get_drvdata(dev);
> + int i, len = 0;
> + u32 __iomem *regs = (void __iomem *) gpt->regs;
> +
> + for (i = 0; i < 4; i++)
> + len += sprintf(buf + len, "%.8x ", in_be32(regs + i));
> + len += sprintf(buf + len, "\n");
> +
> + return len;
> +}
> +
> +static struct device_attribute mpc52xx_gpt_attrib[] = {
> + __ATTR(regs, S_IRUGO | S_IWUSR, mpc52xx_gpt_show_regs, NULL),
> +};
> +
> +static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *gpt)
> +{
> + int i, err = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(mpc52xx_gpt_attrib); i++)
> + err |= device_create_file(gpt->dev, &mpc52xx_gpt_attrib[i]);
I think it should give an error for every device that failed but...
> +
> + if (err)
> + dev_err(gpt->dev, "device_create_file() failed\n");
> +}
> +
> +#else /* defined(CONFIG_SYSFS) */
> +static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *) { return 0; }
> +#endif /* defined(CONFIG_SYSFS) */
...to me the whole sysfs stuff looks like developer-only information.
I'd rather drop it or make it at least DEBUG. Or you just check the
registers via memedit [1] and /dev/mem.
> +
> +/* ---------------------------------------------------------------------
> + * of_platform bus binding code
> + */
> +static int __devinit mpc52xx_gpt_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct mpc52xx_gpt_priv *gpt;
> +
> + gpt = kzalloc(sizeof *gpt, GFP_KERNEL);
> + if (!gpt)
> + return -ENOMEM;
> +
> + spin_lock_init(&gpt->lock);
> + gpt->dev = &ofdev->dev;
> + gpt->regs = of_iomap(ofdev->node, 0);
> + if (!gpt->regs) {
> + kfree(gpt);
> + return -ENOMEM;
> + }
> +
> + dev_set_drvdata(&ofdev->dev, gpt);
> +
> + mpc52xx_gpt_create_attribs(gpt);
> + mpc52xx_gpt_gpio_setup(gpt, ofdev->node);
> + mpc52xx_gpt_irq_setup(gpt, ofdev->node);
> +
> + return 0;
> +}
> +
> +static int mpc52xx_gpt_remove(struct of_device *ofdev)
> +{
> + return -EBUSY;
> +}
> +
> +static const struct of_device_id mpc52xx_gpt_match[] = {
> + { .compatible = "fsl,mpc5200-gpt", },
> +
> + /* Depreciated compatible values; don't use for new dts files */
> + { .compatible = "fsl,mpc5200-gpt-gpio", },
> + { .compatible = "mpc5200-gpt", },
> + {}
> +};
> +
> +static struct of_platform_driver mpc52xx_gpt_driver = {
> + .name = "mpc52xx-gpt",
> + .match_table = mpc52xx_gpt_match,
> + .probe = mpc52xx_gpt_probe,
> + .remove = mpc52xx_gpt_remove,
> +};
> +
> +static int __init mpc52xx_gpt_init(void)
> +{
> + if (of_register_platform_driver(&mpc52xx_gpt_driver))
> + pr_err("error registering MPC52xx GPT driver\n");
> +
> + return 0;
> +}
> +
> +/* Make sure GPIOs and IRQs get set up before anyone tries to use them */
> +subsys_initcall(mpc52xx_gpt_init);
>
[1] http://www.pengutronix.de/software/memedit/index_en.html
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5064 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH -rt] powerpc/tracing: Add support for "PREEMPT_TRACE" tracer
From: Anton Vorontsov @ 2009-01-31 19:14 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar
Cc: linux-rt-users, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <1233338221.3833.65.camel@localhost.localdomain>
The support is pretty straightforward: issue print_preempt_trace()
just after the call trace.
Without CONFIG_PREEMPT_TRACE=y the print_preempt_trace() call turns
into no-op.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Fri, Jan 30, 2009 at 12:57:01PM -0500, Steven Rostedt wrote:
[...]
> > > Turn on CONFIG_PREEMPT_TRACE (not TRACER) and it should show the
> > > location that left preemption disabled.
> >
> > Thank you Steven, PREEMPT_TRACE is a great tool indeed (though on
> > PowerPC it doesn't work out of the box, but easily fixable).
>
> Cool, I'd be interested in those fixes.
Here it is. "ftrace: On PowerPC we don't need frame pointers for
CALLER_ADDRs" patch (http://lkml.org/lkml/2009/1/31/141) is also
needed for this to work.
Thanks,
arch/powerpc/kernel/process.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 957bded..b8642bf 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1020,7 +1020,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
printk("Call Trace:\n");
do {
if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
- return;
+ goto out;
stack = (unsigned long *) sp;
newsp = stack[0];
@@ -1049,6 +1049,8 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
sp = newsp;
} while (count++ < kstack_depth_to_print);
+out:
+ print_preempt_trace(tsk);
}
void dump_stack(void)
--
1.5.6.5
^ permalink raw reply related
* [PATCH] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs
From: Anton Vorontsov @ 2009-01-31 19:06 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar; +Cc: Paul Mackerras, linux-kernel, linuxppc-dev
According to this discussion:
http://lkml.org/lkml/2008/7/25/338
http://lkml.org/lkml/2008/7/26/72
Frame pointers do nothing useful on PowerPC, so lib/Kconfig.debug
makes CONFIG_FRAME_POINTER unselectable on PPC targets. But ftrace.h
requires CONFIG_FRAME_POINTER for CALLER_ADDR macros. Therefore
tracing is completely useless on PowerPC:
[...]
<idle>-0 0X.h3 2us+: 0:140:R + [000] 1733:120:S mvtsd
<idle>-0 0X.h3 9us+: 0 (0)
<idle>-0 0X..3 72us : 0 (0)
<idle>-0 0X..3 73us : 0:140:R ==> [000] 1733:120:R mvtsd
On PPC we can safely use __builtin_return_address(1..6) w/o frame
pointers, and with this patch the trace output looks OK:
[...]
<idle>-0 0X.h3 2us+: 0:140:R + [000] 1740:120:S mvtsd
<idle>-0 0X.h3 9us+: hrtimer_wakeup (__run_hrtimer)
<idle>-0 0X..3 87us : cpu_idle (__got2_end)
<idle>-0 0X..3 89us : 0:140:R ==> [000] 1740:120:R mvtsd
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Btw, on PowerPC tracing is also broken w/o "ring-buffer: fix alignment
problem" patch (currently collecting dust in the -tip tree, commit
082605de5f82eb692cc90f7fda071cc01bb5ac34). Any chance the fix go into
Linus' tree, to not waste other people's time bisecting and debugging
the problem? ;-)
For google: tracing, regression, "ring-buffer: move some metadata
into buffer page", commit abc9b56d66fbd4d93302ef4bf6fa726e1b8255f9,
answer is here.
include/linux/ftrace.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 9c5bc6b..13eba02 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -146,7 +146,7 @@ static inline void __ftrace_enabled_restore(int enabled)
#endif
}
-#ifdef CONFIG_FRAME_POINTER
+#if defined(CONFIG_FRAME_POINTER) || defined(CONFIG_PPC)
/* TODO: need to fix this for ARM */
# define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0))
# define CALLER_ADDR1 ((unsigned long)__builtin_return_address(1))
--
1.5.6.5
^ permalink raw reply related
* Re: Dynamic-ftrace not working in PlayStation3
From: Arnd Bergmann @ 2009-01-31 10:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Steven Rostedt, Remis Lima Baima
In-Reply-To: <4983BFA2.9010703@am.sony.com>
On Saturday 31 January 2009, Geoff Levand wrote:
> >
> > So I take it that the above showed that the code worked for some?
>
> In my trials it blows up on the first load_module() call, and for my
> config that was usbcore:
I looked into it some more with Remis yesterday, and we got ftrace
working by building usbcore and alsa into the kernel. Incidentally,
usbcore is the largest module in this installation (~3MB), which
indicates that it is in some way either related to the size of the
module.
> This ptr of 5f666f725f726573 seems bogus. I think this code is not
> working correctly:
This is an ascii string "_for_res", probably part of
usb_lock_device_for_reset. We saw the same behaviour, but
a different string.
Arnd <><
^ permalink raw reply
* Re: [Patch] 2.6.29-rc3-git2 - Fix net/ipv6/ip6mr.o build break
From: David Miller @ 2009-01-31 8:50 UTC (permalink / raw)
To: sachinp; +Cc: yoshfuji, linuxppc-dev, mel, linux-kernel, kamalesh
In-Reply-To: <4983EEE3.3080208@in.ibm.com>
Thanks for the report, Dave Jones already posted this fix
(CC:'d to the correct location, netdev@vger.kernel.org)
^ permalink raw reply
* [Patch] 2.6.29-rc3-git2 - Fix net/ipv6/ip6mr.o build break
From: Sachin P. Sant @ 2009-01-31 6:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: yoshfuji, Mel Gorman, davem, linux-kernel, Kamalesh Babulal
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
allmodconfig build breaks with following error.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-powerpc
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
CALL arch/powerpc/kernel/systbl_chk.sh
CALL arch/powerpc/kernel/prom_init_check.sh
CC [M] net/ipv6/ip6mr.o
net/ipv6/ip6mr.c: In function pim6_rcv:
net/ipv6/ip6mr.c:366: error: implicit declaration of function csum_ipv6_magic
make[2]: *** [net/ipv6/ip6mr.o] Error 1
make[1]: *** [net/ipv6] Error 2
make: *** [net] Error 2
Following patch fixes this issue.
thanks
-Sachin
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
---
[-- Attachment #2: fix-ipv6-ip6mr-build-break.patch --]
[-- Type: text/x-patch, Size: 462 bytes --]
* Fix ip6mr build break (undefined csum_ipv6_magic symbol)
Signed-off-by : Sachin Sant (sachinp@in.ibm.com)
---
diff -Naurp a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
--- a/net/ipv6/ip6mr.c 2009-01-31 13:58:00.000000000 +0530
+++ b/net/ipv6/ip6mr.c 2009-01-31 13:59:16.000000000 +0530
@@ -43,6 +43,7 @@
#include <net/netlink.h>
#include <net/ipv6.h>
+#include <net/ip6_checksum.h>
#include <net/ip6_route.h>
#include <linux/mroute6.h>
#include <linux/pim.h>
^ permalink raw reply
* Re: Dynamic-ftrace not working in PlayStation3
From: Steven Rostedt @ 2009-01-31 6:20 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras, Remis Lima Baima
In-Reply-To: <4983BFA2.9010703@am.sony.com>
[ added Ben and Paul to Cc, since they helped me write the code ]
On Fri, 30 Jan 2009, Geoff Levand wrote:
> Hi,
>
> I did a bit of work on this today.
>
> Steven Rostedt wrote:
> >> > ip:d000000000045aec jumps to d000000000046340 r2: d000000000050c00
> >> > 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
> >> > ip:d0000000000458d0 jumps to d000000000046340 r2: d000000000050c00
> >> > 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
> >> > ip:d000000000045838 jumps to d000000000046340 r2: d000000000050c00
> >> > 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
> >> > ip:d0000000000456dc jumps to d000000000046340 r2: d000000000050c00
> >> > 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
> >> ...
> >
> > So I take it that the above showed that the code worked for some?
>
> In my trials it blows up on the first load_module() call, and for my
> config that was usbcore:
But does it blow up on the first instance? If it does not, then those
instances are working.
>
> ip:d000000000305298 jumps to d000000000306ad8 r2: d000000000329bb8 3d82fffe 398ccf20 fffecf20 toc: d000000000316af8 5f666f72 5f726573
> ptr 5f666f725f726573, addr c0000000005d0e40, GET_ADDR c000000000007cac
> <3>addr does not match 5f666f725f726573
> <0>------------[ cut here ]------------
> <3>Badness at /home/geoff/projects/cell/ps3-linux-dev/kernel/trace/ftrace.c:441
> NIP: c0000000000b3038 LR: c0000000000b46bc CTR: 0000000000000000
> REGS: c00000001d143780 TRAP: 0700 Not tainted (2.6.29-rc3-02162-gec97e82-dirty)
> MSR: 8000000000020032 <CE,IR,DR> CR: 42222442 XER: 00000000
> TASK = c000000006f64640[373] 'modprobe' THREAD: c00000001d140000 CPU: 1
> <6>GPR00: 0000000000000001 c00000001d143a00 c000000000625988 ffffffffffffffea
> <6>GPR04: d000000000305298 c0000000000628c0 0000000000000000 0000000000000002
> <6>GPR08: 0000000000000000 c000000000c6ce80 0000000000020000 c000000006f64640
> <6>GPR12: 0000000042222444 c000000000655500 d00000000031e9d0 c00000001d143c78
> <6>GPR16: d00000000018cbe0 0000000000000549 d00000000018c208 d00000000031e998
> <6>GPR20: d00000000031de00 d00000000031e980 00000001e48bc1f0 0000000000000001
> <6>GPR24: c0000000005d0e40 c00000001d47b2b8 c000000000576270 d000000000305298
> <6>GPR28: d000000000305298 c00000001d47b2e0 c0000000005c6960 c00000001d143a00
> NIP [c0000000000b3038] .ftrace_bug+0x98/0x210
> LR [c0000000000b46bc] .ftrace_convert_nops+0x23c/0x344
> Call Trace:
> [c00000001d143a00] [c0000000000628c0] .vprintk+0x394/0x42c (unreliable)
> [c00000001d143aa0] [c0000000000b46bc] .ftrace_convert_nops+0x23c/0x344
> [c00000001d143b70] [c0000000000b47fc] .ftrace_init_module+0x38/0x50
> [c00000001d143bf0] [c0000000000a1c70] .load_module+0x12e0/0x189c
> [c00000001d143d80] [c0000000000a23fc] .SyS_init_module+0x90/0x248
> [c00000001d143e30] [c0000000000074dc] syscall_exit+0x0/0x40
> Instruction dump:
> 41fe0010 e93e8010 38000001 9009002c e93e8000 e97e8008 e87e80b0 48000130
> 80090030 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41fe0010 e93e8010
> <6>ftrace failed to modify [<d000000000305298>] 0xd000000000305298
> actual: 48:00:18:41
> <6>usbcore: registered new interface driver usbfs
>
>
> This ptr of 5f666f725f726573 seems bogus. I think this code is not
> working correctly:
Well, obviously the code is not working correctly, if it is blowing up
;-)
>
> offset = (unsigned)((unsigned short)jmp[0]) << 16 |
> (unsigned)((unsigned short)jmp[1]);
>
> tramp = mod->arch.toc + offset + 32;
>
> if (probe_kernel_read(jmp, (void *)tramp, 8)) {
> printk(KERN_ERR "Failed to read %lx\n", tramp);
> return -EFAULT;
> }
>
> ptr = ((unsigned long)jmp[0] << 32) + jmp[1];
>
> addr and GET_ADDR(addr) seem OK, System.map shows both to be _mcount.
> If I force it to continue with this:
>
> if (ptr != GET_ADDR(addr)) {
> printk(KERN_ERR "addr does not match %lx\n", ptr);
> //return -EINVAL;
Please do not do that! You risk writing random stuff over random memory.
If the ptr does not equal what we want, then we can not guarantee that we
are writing what we want to where we want.
> }
>
> It loads a lot of modules, but eventually it fails with the
> following, which seems to mean a bad tramp value.
>
> ip:d0000000005f08cc jumps to d0000000005f1920 r2: d0000000006031c8 3d82ffff 398ce758 ffffe758 toc: d000000000601940<3>Failed to read d000000000601940
> <0>------------[ cut here ]------------
> <3>Badness at /home/geoff/projects/cell/ps3-linux-dev/kernel/trace/ftrace.c:436
> NIP: c0000000000b3000 LR: c0000000000b46dc CTR: 0000000000000001
> REGS: c00000001d5b7780 TRAP: 0700 Not tainted (2.6.29-rc3-02162-gec97e82-dirty)
> MSR: 8000000000020032 <CE,IR,DR> CR: 22222442 XER: 20000000
> TASK = c000000006fea7c0[712] 'modprobe' THREAD: c00000001d5b4000 CPU: 0
> <6>GPR00: 0000000000000001 c00000001d5b7a00 c000000000625998 fffffffffffffff2
> <6>GPR04: d0000000005f08cc c000000000062054 0000000000000000 0000000000000002
> <6>GPR08: 0000000000000000 c000000000c6ce80 000000000001ffff c000000006fea7c0
> <6>GPR12: 0000000022222444 c000000000655300 d0000000005f9fd0 c00000001d5b7c78
> <6>GPR16: d000000000565c58 0000000000000215 d0000000005653e5 d0000000005f9f98
> <6>GPR20: d0000000005f9860 d0000000005f9f80 00000002cfe82a50 0000000000000001
> <6>GPR24: c0000000005d0e50 c00000001d21e6f0 c000000000576270 d0000000005f08cc
> <6>GPR28: d0000000005f08cc c00000001d21e718 c0000000005c6960 c00000001d5b7a00
> NIP [c0000000000b3000] .ftrace_bug+0x60/0x210
> LR [c0000000000b46dc] .ftrace_convert_nops+0x25c/0x364
> Call Trace:
> [c00000001d5b7a00] [0000000000000004] 0x4 (unreliable)
> [c00000001d5b7aa0] [c0000000000b46dc] .ftrace_convert_nops+0x25c/0x364
> [c00000001d5b7b70] [c0000000000b481c] .ftrace_init_module+0x38/0x50
> [c00000001d5b7bf0] [c0000000000a1c70] .load_module+0x12e0/0x189c
> [c00000001d5b7d80] [c0000000000a23fc] .SyS_init_module+0x90/0x248
> [c00000001d5b7e30] [c0000000000074dc] syscall_exit+0x0/0x40
> Instruction dump:
> 419e001c 2f83ffff 419e010c 2f83ffea e93e8010 409e013c 48000040 e93e8010
> 8009002c 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41fe0010 e93e8010
> <6>ftrace faulted on modifying [<d0000000005f08cc>] 0xd0000000005f08cc
The following I snipped out of your previous email (and this goes with the
above).
> 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
> ip:d0000000000456dc jumps to d000000000046340 r2: d000000000050c00
> 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
Here the ptr == c0000000 00007cac, which looks like a legitimate address,
and everything worked fine and dandy.
...
> ps3_system_bus_match:362: dev=11.0(lpm_01), drv=11.0(ps3-lpm): match
> ps3_system_bus_match:362: dev=11.0(lpm_01), drv=11.0(ps3-lpm): match
> ps3-lpm lpm_01: <- ps3_lpm_probe:1245:
> ip:d0000000003fe280 jumps to d0000000003ffad8 r2: d000000000422c70
> 3d82fffe 398cce68 fffece68 toc: d00000000040faf8 6c656400 5f5f6b73
Here the pointer is bogus. We need to find out why. Is the r2 "toc" that
is used bogus? We may need to disassemble the module and look at it
deeper. I'm not an PPC expect, I just based my code off of the module_64.c
code.
-- Steve
> addr does not match
> ptr: 6c6564005f5f6b73
> addr: c0000000004ff128
> GET_ADDR(addr): c000000000007cac
^ permalink raw reply
* RE: Broken PCI on Sequoia
From: Benjamin Herrenschmidt @ 2009-01-31 4:42 UTC (permalink / raw)
To: Feng Kan; +Cc: Geert Uytterhoeven, Linux/PPC Development
In-Reply-To: <2B3B2AA816369A4E87D7BE63EC9D2F260674E7E3@SDCEXCHANGE01.ad.amcc.com>
On Fri, 2009-01-30 at 17:19 -0800, Feng Kan wrote:
> Hi:
> It looks like the top bit is hard coded to 1. There doesn't seem to
> be anyway
> Of changing it.
Thanks !
Would it be possible for you to check other 4xx parts using that PCI
controller as to whether the top bit is always hard-coded to 1 or it
changes from part to part ?
Thanks !
Cheers,
Ben.
> Feng Kan
> AMCC Engineering
>
> -----Original Message-----
> From: linuxppc-dev-bounces+fkan=amcc.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+fkan=amcc.com@ozlabs.org] On Behalf Of
> Benjamin Herrenschmidt
> Sent: Friday, January 30, 2009 1:30 PM
> To: Geert Uytterhoeven
> Cc: Linux/PPC Development
> Subject: Re: Broken PCI on Sequoia
>
>
> > For that sort of 4xx PHB (ie, the PCI 2.x ones, not the PCI-X nor the
> > PCI-E), we only know how to program 32-bit of PLB address. IE. The old
> > code would have cropped the plb_addr when writing to the register, the
> > new code complains.
> >
> > I suspect some implementation support a register to put the "high"
> part
> > of the PLB address, and that it already contains 1, so the old code
> > would have worked by chance, the new code doesn't because it bails
> out.
>
> Hrm... from the doco it's also one 32-bit register... I'm starting to
> think that those guys always assume the top 1 bit is set or something
> like that ...
>
> The doc is unclear. Maybe somebody form AMCC can confirm ?
>
> Cheers,
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Dynamic-ftrace not working in PlayStation3
From: Geoff Levand @ 2009-01-31 3:04 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, Remis Lima Baima
In-Reply-To: <alpine.DEB.1.10.0901292234520.6222@gandalf.stny.rr.com>
Hi,
I did a bit of work on this today.
Steven Rostedt wrote:
>> > ip:d000000000045aec jumps to d000000000046340 r2: d000000000050c00
>> > 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
>> > ip:d0000000000458d0 jumps to d000000000046340 r2: d000000000050c00
>> > 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
>> > ip:d000000000045838 jumps to d000000000046340 r2: d000000000050c00
>> > 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
>> > ip:d0000000000456dc jumps to d000000000046340 r2: d000000000050c00
>> > 3d82ffff 398c5740 ffff5740 toc: d000000000046360 c0000000 00007cac
>> ...
>
> So I take it that the above showed that the code worked for some?
In my trials it blows up on the first load_module() call, and for my
config that was usbcore:
ip:d000000000305298 jumps to d000000000306ad8 r2: d000000000329bb8 3d82fffe 398ccf20 fffecf20 toc: d000000000316af8 5f666f72 5f726573
ptr 5f666f725f726573, addr c0000000005d0e40, GET_ADDR c000000000007cac
<3>addr does not match 5f666f725f726573
<0>------------[ cut here ]------------
<3>Badness at /home/geoff/projects/cell/ps3-linux-dev/kernel/trace/ftrace.c:441
NIP: c0000000000b3038 LR: c0000000000b46bc CTR: 0000000000000000
REGS: c00000001d143780 TRAP: 0700 Not tainted (2.6.29-rc3-02162-gec97e82-dirty)
MSR: 8000000000020032 <CE,IR,DR> CR: 42222442 XER: 00000000
TASK = c000000006f64640[373] 'modprobe' THREAD: c00000001d140000 CPU: 1
<6>GPR00: 0000000000000001 c00000001d143a00 c000000000625988 ffffffffffffffea
<6>GPR04: d000000000305298 c0000000000628c0 0000000000000000 0000000000000002
<6>GPR08: 0000000000000000 c000000000c6ce80 0000000000020000 c000000006f64640
<6>GPR12: 0000000042222444 c000000000655500 d00000000031e9d0 c00000001d143c78
<6>GPR16: d00000000018cbe0 0000000000000549 d00000000018c208 d00000000031e998
<6>GPR20: d00000000031de00 d00000000031e980 00000001e48bc1f0 0000000000000001
<6>GPR24: c0000000005d0e40 c00000001d47b2b8 c000000000576270 d000000000305298
<6>GPR28: d000000000305298 c00000001d47b2e0 c0000000005c6960 c00000001d143a00
NIP [c0000000000b3038] .ftrace_bug+0x98/0x210
LR [c0000000000b46bc] .ftrace_convert_nops+0x23c/0x344
Call Trace:
[c00000001d143a00] [c0000000000628c0] .vprintk+0x394/0x42c (unreliable)
[c00000001d143aa0] [c0000000000b46bc] .ftrace_convert_nops+0x23c/0x344
[c00000001d143b70] [c0000000000b47fc] .ftrace_init_module+0x38/0x50
[c00000001d143bf0] [c0000000000a1c70] .load_module+0x12e0/0x189c
[c00000001d143d80] [c0000000000a23fc] .SyS_init_module+0x90/0x248
[c00000001d143e30] [c0000000000074dc] syscall_exit+0x0/0x40
Instruction dump:
41fe0010 e93e8010 38000001 9009002c e93e8000 e97e8008 e87e80b0 48000130
80090030 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41fe0010 e93e8010
<6>ftrace failed to modify [<d000000000305298>] 0xd000000000305298
actual: 48:00:18:41
<6>usbcore: registered new interface driver usbfs
This ptr of 5f666f725f726573 seems bogus. I think this code is not
working correctly:
offset = (unsigned)((unsigned short)jmp[0]) << 16 |
(unsigned)((unsigned short)jmp[1]);
tramp = mod->arch.toc + offset + 32;
if (probe_kernel_read(jmp, (void *)tramp, 8)) {
printk(KERN_ERR "Failed to read %lx\n", tramp);
return -EFAULT;
}
ptr = ((unsigned long)jmp[0] << 32) + jmp[1];
addr and GET_ADDR(addr) seem OK, System.map shows both to be _mcount.
If I force it to continue with this:
if (ptr != GET_ADDR(addr)) {
printk(KERN_ERR "addr does not match %lx\n", ptr);
//return -EINVAL;
}
It loads a lot of modules, but eventually it fails with the
following, which seems to mean a bad tramp value.
ip:d0000000005f08cc jumps to d0000000005f1920 r2: d0000000006031c8 3d82ffff 398ce758 ffffe758 toc: d000000000601940<3>Failed to read d000000000601940
<0>------------[ cut here ]------------
<3>Badness at /home/geoff/projects/cell/ps3-linux-dev/kernel/trace/ftrace.c:436
NIP: c0000000000b3000 LR: c0000000000b46dc CTR: 0000000000000001
REGS: c00000001d5b7780 TRAP: 0700 Not tainted (2.6.29-rc3-02162-gec97e82-dirty)
MSR: 8000000000020032 <CE,IR,DR> CR: 22222442 XER: 20000000
TASK = c000000006fea7c0[712] 'modprobe' THREAD: c00000001d5b4000 CPU: 0
<6>GPR00: 0000000000000001 c00000001d5b7a00 c000000000625998 fffffffffffffff2
<6>GPR04: d0000000005f08cc c000000000062054 0000000000000000 0000000000000002
<6>GPR08: 0000000000000000 c000000000c6ce80 000000000001ffff c000000006fea7c0
<6>GPR12: 0000000022222444 c000000000655300 d0000000005f9fd0 c00000001d5b7c78
<6>GPR16: d000000000565c58 0000000000000215 d0000000005653e5 d0000000005f9f98
<6>GPR20: d0000000005f9860 d0000000005f9f80 00000002cfe82a50 0000000000000001
<6>GPR24: c0000000005d0e50 c00000001d21e6f0 c000000000576270 d0000000005f08cc
<6>GPR28: d0000000005f08cc c00000001d21e718 c0000000005c6960 c00000001d5b7a00
NIP [c0000000000b3000] .ftrace_bug+0x60/0x210
LR [c0000000000b46dc] .ftrace_convert_nops+0x25c/0x364
Call Trace:
[c00000001d5b7a00] [0000000000000004] 0x4 (unreliable)
[c00000001d5b7aa0] [c0000000000b46dc] .ftrace_convert_nops+0x25c/0x364
[c00000001d5b7b70] [c0000000000b481c] .ftrace_init_module+0x38/0x50
[c00000001d5b7bf0] [c0000000000a1c70] .load_module+0x12e0/0x189c
[c00000001d5b7d80] [c0000000000a23fc] .SyS_init_module+0x90/0x248
[c00000001d5b7e30] [c0000000000074dc] syscall_exit+0x0/0x40
Instruction dump:
419e001c 2f83ffff 419e010c 2f83ffea e93e8010 409e013c 48000040 e93e8010
8009002c 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41fe0010 e93e8010
<6>ftrace faulted on modifying [<d0000000005f08cc>] 0xd0000000005f08cc
-Geoff
^ permalink raw reply
* RE: Broken PCI on Sequoia
From: Feng Kan @ 2009-01-31 1:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <1233351024.18767.32.camel@pasglop>
Hi:
It looks like the top bit is hard coded to 1. There doesn't seem to
be anyway
Of changing it.=20
Feng Kan
AMCC Engineering
-----Original Message-----
From: linuxppc-dev-bounces+fkan=3Damcc.com@ozlabs.org
[mailto:linuxppc-dev-bounces+fkan=3Damcc.com@ozlabs.org] On Behalf Of
Benjamin Herrenschmidt
Sent: Friday, January 30, 2009 1:30 PM
To: Geert Uytterhoeven
Cc: Linux/PPC Development
Subject: Re: Broken PCI on Sequoia
> For that sort of 4xx PHB (ie, the PCI 2.x ones, not the PCI-X nor the
> PCI-E), we only know how to program 32-bit of PLB address. IE. The old
> code would have cropped the plb_addr when writing to the register, the
> new code complains.
>=20
> I suspect some implementation support a register to put the "high"
part
> of the PLB address, and that it already contains 1, so the old code
> would have worked by chance, the new code doesn't because it bails
out.
Hrm... from the doco it's also one 32-bit register... I'm starting to
think that those guys always assume the top 1 bit is set or something
like that ...
The doc is unclear. Maybe somebody form AMCC can confirm ?
Cheers,
Ben.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: toolchain for building linux-2.6.27.8 or 2.6.28.1 ...
From: Robert Schwebel @ 2009-01-30 23:08 UTC (permalink / raw)
To: Mike Timmons; +Cc: linuxppc-dev
In-Reply-To: <498208E0.7000707@trimble.com>
Hi Mike,
On Thu, Jan 29, 2009 at 01:52:00PM -0600, Mike Timmons wrote:
> Questions:
> 1) if I want to cross-compile a kernel later than 2.6.24 to hopefully
> get better WAN device support (and clearer options for fw loading),
> which kernel should I try, and which toolchain?
OSELAS.Toolchain-1.99.2 is known to build working kernels for powerpc,
currently tested for 603e (MPC5200B). We have gcc-4.3.2 at the moment.
rsc
--
Pengutronix e.K. | |
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: 2.6.28-rt on PowerPC
From: Robert Schwebel @ 2009-01-30 23:06 UTC (permalink / raw)
To: Frank Rowand
Cc: linux-rt-users, Uwe Kleine-Koenig, linux-kernel, linuxppc-dev,
Steven Rostedt
In-Reply-To: <49823A13.50703@am.sony.com>
Frank,
On Thu, Jan 29, 2009 at 03:21:55PM -0800, Frank Rowand wrote:
> > Thanks! I have not yet had the chance to apply any arch patches yet. I
> > do plan on doing so after getting the code mostly working on x86.
>
> Your email can at an opportune time for me... I was starting to try
> 2.6.28-rt on ARM and quickly came to the conclusion that the arch
> patches weren't the focus yet. But I'm currently side-tracked with
> getting my board to even boot a vanilla 2.6.28 kernel first. Do
> you expect to get to the arches in the next week or two? If not,
> I may head down that path for ARM myself.
Uwe has collected some patches for ARM here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/52108/focus=787937
You might want to try them before starting, in order to avoid duplicate
work.
rsc
--
Pengutronix e.K. | |
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
* Can not get PATA to work for Compact Flash with 2.6.28 kernel
From: Lixin Yao @ 2009-01-30 22:23 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 4796 bytes --]
I use a San Disk compact flash (CF) card on a board with MPC8248
processor. The CF is connected to data and address bus of the processor
and operates in TRUE IDE mode. The registers are memory mapped. I can
read the file system on the CF in u-boot (1.3.4). U-boot can identify
the CF and mount file system correctly.
The hardware is known good hardware.
I use 2.6.28 kernel and configured support for PATA for the CF.
Here is the setup in DTS file:
localbus@f0010100 {
#address-cells = <2>;
#size-cells = <1>;
compatible = "fsl,mpc8248-localbus",
"fsl,pq2-localbus",
"simple-bus";
reg = <0xf0010100 0x40>;
ranges = <0x3 0x0 0x30000000 0x10000
0x4 0x0 0x40000000 0x10000>;
pata@3,0 {
compatible = "fsl,tr5000v2-pata", "ata-generic";
reg = <0x3 0x0 0x10 0x4 0x0 0x10>;
reg-shift = <1>;
pio-mode = <3>;
// interrupts = <23 0x8>;
// interrupt-parent = <&PIC>;
};
};
Here are some of the related CONFIG items:
#
# UBI - Unsorted block images
#
# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_SPI=y
CONFIG_OF_GPIO=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_MISC_DEVICES is not set
#CONFIG_HAVE_IDE=y
#CONFIG_IDE=y
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
CONFIG_ATA=y
CONFIG_ATA_SFF=y
CONFIG_PATA_PLATFORM=y
CONFIG_PATA_OF_PLATFORM=y
Here is the output at console:
Kernel command line: console=ttyCPM0,38400 root=/dev/nfs rw
nfsroot=10.15.34.196
:/home/lyao01/work/target_idu_nccv3
ip=172.20.16.150:10.15.34.196:172.20.16.1:25
5.255.255.0:tr5000v2:eth0ff
......
NET: Registered protocol family 16
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
NTFS driver 2.1.29 [Flags: R/O].
msgmni has been set to 119
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered (default)
f0011a80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq = 16) is a CPM UART
brd: module loaded
loop: module loaded
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
eth0: fs_enet: 00:00:c3:ff:7a:af
CPM2 Bitbanged MII: probed
ata_host_alloc: ENTER
ata_port_alloc: ENTER
__ata_port_freeze: ata4294967295 port frozen
scsi0 : pata_platform
ata1: PATA max PIO3 no IRQ, using PIO polling mmio cmd 0x30000000 ctl
0x40000000
ata_host_register: probe begin
ata_port_schedule_eh: port EH scheduled
ata_scsi_error: ENTER
ata_port_flush_task: ENTER
ata_eh_link_autopsy: ENTER
ata_eh_recover: ENTER
__ata_port_freeze: ata1 port frozen
ata_sff_softreset: ENTER
ata_sff_softreset: about to softreset, devmask=0
ata_bus_softreset: ata1: bus reset via SRST
ata_sff_softreset: EXIT, classes[0]=9 [1]=9
ata_eh_thaw_port: ata1 port thawed
ata_std_postreset: ENTER
ata_std_postreset: EXIT
ata_sff_postreset: EXIT, no device
ata_eh_revalidate_and_attach: ENTER
ata_eh_recover: EXIT, rc=0
ata_scsi_error: EXIT
ata_host_register: host probe begin
TCP cubic registered
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
ics1893_config_init() successful
ADDRCONF(NETDEV_UP): eth0: link is not ready
ics1893_config_init() successful
IP-Config: Complete:
device=eth0, addr=172.20.16.150, mask=255.255.255.0, gw=172.20.16.1,
host=tr5000v2, domain=, nis-domain=(none),
bootserver=10.15.34.196, rootserver=10.15.34.196, rootpath=
Looking up port of RPC 100003/2 on 10.15.34.196
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Looking up port of RPC 100005/1 on 10.15.34.196
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 164k init
### Application running ...
#
The San Disk Compact Flash is not discovered.
I appreciate any insights or suggestions.
Lixin Yao
Harris Stratex Networks Inc
RTP, North Carolina, USA
[-- Attachment #2: Type: text/html, Size: 10731 bytes --]
^ permalink raw reply
* Re: toolchain for building linux-2.6.27.8 or 2.6.28.1 AND USB wi fi SUCCESS...
From: Mike Timmons @ 2009-01-30 21:39 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-dev
In-Reply-To: <C5A7544F.14345%gerickson@nuovations.com>
Thank You! I obtained ELDK 4.1 from Denx and built 2.6.27.8 with it. A
couple host tool links were required but the build was pretty painless.
Ultimate goal I startedon early in the week was USB wi fi using the
Linksys WUSB54GC, which requires the ralink rt73 driver.
The 2.6.27.8 menuconfig offered the "firmware" loading options I was
looking for.
I now have a working USB wi fi device.
THANK YOU!
-Mike Timmons
Grant Erickson wrote:
> On 1/29/09 11:52 AM, Mike Timmons wrote:
>
>> Questions:
>> 1) if I want to cross-compile a kernel later than 2.6.24 to hopefully
>> get better WAN device support (and clearer options for fw loading),
>> which kernel should I try, and which toolchain?
>>
>> the ltib repository does not appear to have a toolchain newer than
>> gcc-3.4.3-glibc-2.3.6 (for 603e)
>>
>> Admissions, disclaimers, etc
>> 1) I'm using the same ltib script I have used for the 2.6.24 build with
>> toolchain gcc-3.4.3-glibc-2.3.6 (for 603e).
>> I'm simply modifying the kernel spec file to use 2.6.28.1 (and specifyin
>> a custom toolchain).
>> I've also tried to compile 2.6.27.8. I get the same error.
>>
>
> Mike:
>
> Denx's ELDK 4.1 or 4.2 make a great "It Just Works" solution. I've used 4.1
> running from 2.6.23 up to 2.6.27.11 and 4.2 from 2.6.26 to 2.6.27.11 with
> zero problems or issues.
>
> Regards,
>
> Grant Erickson
>
>
>
^ permalink raw reply
* Re: Broken PCI on Sequoia
From: Benjamin Herrenschmidt @ 2009-01-30 21:30 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <1233349323.18767.31.camel@pasglop>
> For that sort of 4xx PHB (ie, the PCI 2.x ones, not the PCI-X nor the
> PCI-E), we only know how to program 32-bit of PLB address. IE. The old
> code would have cropped the plb_addr when writing to the register, the
> new code complains.
>
> I suspect some implementation support a register to put the "high" part
> of the PLB address, and that it already contains 1, so the old code
> would have worked by chance, the new code doesn't because it bails out.
Hrm... from the doco it's also one 32-bit register... I'm starting to
think that those guys always assume the top 1 bit is set or something
like that ...
The doc is unclear. Maybe somebody form AMCC can confirm ?
Cheers,
Ben.
^ permalink raw reply
* Re: Broken PCI on Sequoia
From: Benjamin Herrenschmidt @ 2009-01-30 21:02 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <alpine.LRH.2.00.0901301334220.13283@vixen.sonytel.be>
> | PCI host bridge /plb/pci@1ec000000 (primary) ranges:
> | MEM 0x0000000180000000..0x00000001bfffffff -> 0x0000000080000000
> | IO 0x00000001e8000000..0x00000001e800ffff -> 0x0000000000000000
> | IO 0x00000001e8800000..0x00000001ebffffff -> 0x0000000000000000
> | \--> Skipped (too many) !
> | 4xx PCI DMA offset set to 0x00000000
> | ppc4xx_configure_pci_PMMs: i = 0, hose->pci_mem_offset = 0x100000000
> | ppc4xx_setup_one_pci_PMM: hose = 0xcf825000
> | ppc4xx_setup_one_pci_PMM: reg = 0xd1000000
> | ppc4xx_setup_one_pci_PMM: plb_addr = 0x180000000
> | ppc4xx_setup_one_pci_PMM: pci_addr = 0x80000000
> | ppc4xx_setup_one_pci_PMM: size = 0x40000000
> | ppc4xx_setup_one_pci_PMM: flags = 0x200
> | ppc4xx_setup_one_pci_PMM: index = 0
> | /plb/pci@1ec000000: Resource out of range
> ^^^^^^^^^^^^^^^^^^^^^
> because plb_addr + size lies outside 32-bit space.
Ok so the code was buggy already, the ISA hole patch just makes it
trigger...
For that sort of 4xx PHB (ie, the PCI 2.x ones, not the PCI-X nor the
PCI-E), we only know how to program 32-bit of PLB address. IE. The old
code would have cropped the plb_addr when writing to the register, the
new code complains.
I suspect some implementation support a register to put the "high" part
of the PLB address, and that it already contains 1, so the old code
would have worked by chance, the new code doesn't because it bails out.
I need to check the doco for your CPU or any other using that cell to
see who supports what regarding the location of the outbound windows in
PLB space. I think the original 440GP which I used as a basis for the
PCI 2.x host bridge only supports 32-bits here but maybe I'm just
confused.
I'll have a look next week.
Cheers,
Ben
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
From: Nathan Lynch @ 2009-01-30 20:25 UTC (permalink / raw)
To: Oren Laadan; +Cc: containers, linuxppc-dev
In-Reply-To: <49824599.5030503@cs.columbia.edu>
Oren Laadan wrote:
>
> Nathan Lynch wrote:
> >
> > Oren Laadan wrote:
> >> Nathan Lynch wrote:
> >>> + pr_debug("%s: unexpected thread_hdr contents: 0x%lx\n",
> >>> + __func__, (unsigned long)thread_hdr->unimplemented);
> >> Given the macro for 'pr_fmt' in include/linux/checkpoint.h, the use of
> >> __func__ is redunant.
> >
> > It seems to me that defining your own pr_fmt in a "public" header like
> > that is inappropriate, or at least unconventional. Any file that
> > happens to include linux/checkpoint.h will have any prior definitions
> > of pr_fmt overridden, no?
> >
>
> Hmmm.. didn't think of it this way. Using the pr_debug() there was yet
> another feedback from LKML, and it seemed reasonable to me. Can you
> think of a case where linux/checkpoint.h will happen to be included
> in checkpoint-related code ?
(Assume you meant "included in checkpoint-unrelated code")
I could see checkpoint.h being included by files that don't
exclusively deal with C/R. If you want a uniform debug statement
format for C/R-related code, that's fine, but this isn't the way to do
it. See the existing users (almost all in drivers/s390).
^ permalink raw reply
* Re: 2.6.28-rt on PowerPC
From: Steven Rostedt @ 2009-01-30 17:57 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-kernel, linux-rt-users
In-Reply-To: <20090130174545.GA846@oksana.dev.rtsoft.ru>
On Fri, 2009-01-30 at 20:45 +0300, Anton Vorontsov wrote:
> On Thu, Jan 29, 2009 at 06:00:43PM -0500, Steven Rostedt wrote:
> [...]
> > > BUG: sleeping function called from invalid context at kernel/rtmutex.c:683
> > > in_atomic(): 1 [00000100], irqs_disabled(): 0, pid: 7, name: sirq-net-rx/0
> > > Call Trace:
> > > [cf84bc20] [c0008be8] show_stack+0x4c/0x16c (unreliable)
> > > [cf84bc60] [c001c194] __might_sleep+0xd8/0xf8
> > > [cf84bc70] [c02b7768] rt_spin_lock+0x30/0x78
> > > [cf84bc80] [c00800e0] kmem_cache_alloc+0x50/0x17c
> > > [cf84bcb0] [c02568a4] ip_append_data+0x974/0x978
> > > [cf84bd30] [c027aa0c] icmp_push_reply+0x54/0x128
> > > [cf84bd50] [c027b59c] icmp_send+0x284/0x380
> > > [cf84be40] [c0277328] __udp4_lib_rcv+0x3d4/0x5a0
> > > [cf84bea0] [c0253208] ip_local_deliver_finish+0x74/0x128
> [...]
> > Turn on CONFIG_PREEMPT_TRACE (not TRACER) and it should show the
> > location that left preemption disabled.
>
> Thank you Steven, PREEMPT_TRACE is a great tool indeed (though on
> PowerPC it doesn't work out of the box, but easily fixable).
Cool, I'd be interested in those fixes.
>
> So, the result:
>
> ---------------------------
> | preempt count: 00000100 ]
> | 1-level deep critical section nesting:
> ----------------------------------------
> .. [<c002d9fc>] .... local_bh_disable+0x1c/0x34
> .....[<c02afef8>] .. ( <= icmp_send+0xac/0x388)
>
> icmp_send() calls icmp_xmit_lock() that disables bottom halves,
> then icmp_send() calls ip_append_data() that tries to allocate
> things with GFP_ATOMIC, which should be OK...
I'll have a look at that code. to find out what's up with it.
>
> I guess now this isn't true for -rt kernels, correct? A comment
> in slab.c ("which in turn implies that nobody does allocations
> from atomic contexts") seem to confirm this.
>
> (A bit unrelated question: If that's how things work now (i.e.
> GFP_ATOMIC is equal to GFP_KERNEL or vice-versa), how should we
> allocate things in IRQF_NODELAY/TIMER interrupts?)
Preallocate ;-) Actually, we could never really allocate from NODELAY
or TIMER interrupts in -rt. If we did, we were just lucky it worked.
>
> Anyway, this snippet fixes the issue:
>
> diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> index 6bccfbe..4a4862b 100644
> --- a/net/ipv4/icmp.c
> +++ b/net/ipv4/icmp.c
> @@ -222,6 +222,9 @@ static inline struct sock *icmp_xmit_lock(struct net *net)
> local_bh_enable();
> return NULL;
> }
> +#ifdef CONFIG_PREEMPT_RT
> + local_bh_enable();
> +#endif
That is definitely just a work around. I'll have to look at it to see
the main problem.
> return sk;
> }
>
> --
>
> Now the kernel is able to boot up to the login prompt, cool!
>
> But after a while this pops up:
>
> INFO: task sirq-high/0:4 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> sirq-high/0 D 00000000 0 4 2
> Call Trace:
> [cf839eb0] [60320800] 0x60320800 (unreliable)
> [cf839f70] [c0009b34] __switch_to+0x50/0x74
> [cf839f90] [c02ee48c] schedule+0x19c/0x380
> [cf839fd0] [c00427ac] kthread+0x34/0x8c
> [cf839ff0] [c001354c] kernel_thread+0x4c/0x68
> ---------------------------
> | preempt count: 00000002 ]
> | 2-level deep critical section nesting:
> ----------------------------------------
> .. [<c02ee340>] .... schedule+0x50/0x380
> .....[<c00427ac>] .. ( <= kthread+0x34/0x8c)
> .. [<c02f0700>] .... _spin_lock_irq+0x2c/0x4c
> .....[<c02ee388>] .. ( <= schedule+0x98/0x380)
>
>
> And keeps popping up every 120 seconds, though both kernel and
> userspace stay alive.
Hmm, that will also take more looking into to. That is probably specific
to PPC.
Again, my focus is currently on getting all the main pieces in. The
archs will still have to wait. But thanks for taking the time to look at
it. It gives me a preview to what I will need to deal with.
-- Steve
^ permalink raw reply
* Re: 2.6.28-rt on PowerPC
From: Anton Vorontsov @ 2009-01-30 17:45 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, linux-kernel, linux-rt-users
In-Reply-To: <1233270043.3833.57.camel@localhost.localdomain>
On Thu, Jan 29, 2009 at 06:00:43PM -0500, Steven Rostedt wrote:
[...]
> > BUG: sleeping function called from invalid context at kernel/rtmutex.c:683
> > in_atomic(): 1 [00000100], irqs_disabled(): 0, pid: 7, name: sirq-net-rx/0
> > Call Trace:
> > [cf84bc20] [c0008be8] show_stack+0x4c/0x16c (unreliable)
> > [cf84bc60] [c001c194] __might_sleep+0xd8/0xf8
> > [cf84bc70] [c02b7768] rt_spin_lock+0x30/0x78
> > [cf84bc80] [c00800e0] kmem_cache_alloc+0x50/0x17c
> > [cf84bcb0] [c02568a4] ip_append_data+0x974/0x978
> > [cf84bd30] [c027aa0c] icmp_push_reply+0x54/0x128
> > [cf84bd50] [c027b59c] icmp_send+0x284/0x380
> > [cf84be40] [c0277328] __udp4_lib_rcv+0x3d4/0x5a0
> > [cf84bea0] [c0253208] ip_local_deliver_finish+0x74/0x128
[...]
> Turn on CONFIG_PREEMPT_TRACE (not TRACER) and it should show the
> location that left preemption disabled.
Thank you Steven, PREEMPT_TRACE is a great tool indeed (though on
PowerPC it doesn't work out of the box, but easily fixable).
So, the result:
---------------------------
| preempt count: 00000100 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c002d9fc>] .... local_bh_disable+0x1c/0x34
.....[<c02afef8>] .. ( <= icmp_send+0xac/0x388)
icmp_send() calls icmp_xmit_lock() that disables bottom halves,
then icmp_send() calls ip_append_data() that tries to allocate
things with GFP_ATOMIC, which should be OK...
I guess now this isn't true for -rt kernels, correct? A comment
in slab.c ("which in turn implies that nobody does allocations
from atomic contexts") seem to confirm this.
(A bit unrelated question: If that's how things work now (i.e.
GFP_ATOMIC is equal to GFP_KERNEL or vice-versa), how should we
allocate things in IRQF_NODELAY/TIMER interrupts?)
Anyway, this snippet fixes the issue:
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 6bccfbe..4a4862b 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -222,6 +222,9 @@ static inline struct sock *icmp_xmit_lock(struct net *net)
local_bh_enable();
return NULL;
}
+#ifdef CONFIG_PREEMPT_RT
+ local_bh_enable();
+#endif
return sk;
}
--
Now the kernel is able to boot up to the login prompt, cool!
But after a while this pops up:
INFO: task sirq-high/0:4 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sirq-high/0 D 00000000 0 4 2
Call Trace:
[cf839eb0] [60320800] 0x60320800 (unreliable)
[cf839f70] [c0009b34] __switch_to+0x50/0x74
[cf839f90] [c02ee48c] schedule+0x19c/0x380
[cf839fd0] [c00427ac] kthread+0x34/0x8c
[cf839ff0] [c001354c] kernel_thread+0x4c/0x68
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c02ee340>] .... schedule+0x50/0x380
.....[<c00427ac>] .. ( <= kthread+0x34/0x8c)
.. [<c02f0700>] .... _spin_lock_irq+0x2c/0x4c
.....[<c02ee388>] .. ( <= schedule+0x98/0x380)
And keeps popping up every 120 seconds, though both kernel and
userspace stay alive.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply related
* Re: Please pull 'merge' branch of linux-2.6-mpc52xx.git
From: Grant Likely @ 2009-01-30 17:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Hey Ben,
Updating my pull request; I've added one more patch as can been seen
in the diffstat. The new one is a documentation-only change.
g.
The following changes since commit 18e352e4a73465349711a9324767e1b2453383e2:
Linus Torvalds (1):
Linux 2.6.29-rc3
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx merge
Grant Likely (3):
powerpc/5200: update defconfigs
powerpc/5200: Bugfix for PCI mapping of memory and IMMR
powerpc/5200: update device tree binding documentation
Documentation/powerpc/dts-bindings/fsl/mpc5200.txt | 180 +++++++++++++
.../powerpc/mpc52xx-device-tree-bindings.txt | 277 --------------------
arch/powerpc/configs/52xx/cm5200_defconfig | 83 +++++--
arch/powerpc/configs/52xx/lite5200b_defconfig | 86 +++++--
arch/powerpc/configs/52xx/motionpro_defconfig | 85 +++++--
arch/powerpc/configs/52xx/pcm030_defconfig | 82 ++++--
arch/powerpc/configs/52xx/tqm5200_defconfig | 89 +++++--
arch/powerpc/configs/mpc5200_defconfig | 104 ++++++--
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 24 +-
9 files changed, 576 insertions(+), 434 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
delete mode 100644 Documentation/powerpc/mpc52xx-device-tree-bindings.txt
On Thu, Jan 29, 2009 at 5:31 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Ummm, I'm batting 1000 today.... Please pull the **MERGE** branch of
> linux-2.6-mpc52xx.git tree (The URL below was correct though).
>
> g.
>
> On Thu, Jan 29, 2009 at 5:29 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> Oops, forgot to CC the mailing list.
>>
>> g.
>>
>> On Thu, Jan 29, 2009 at 5:28 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> Hi Ben,
>>>
>>> Here is the traditional defconfig update plus a bugfix for mpc5200
>>> PCI. Please pull into 2.6.29.
>>>
>>> Thanks,
>>> g.
>>>
>>> The following changes since commit 18e352e4a73465349711a9324767e1b2453383e2:
>>> Linus Torvalds (1):
>>> Linux 2.6.29-rc3
>>>
>>> are available in the git repository at:
>>>
>>> git://git.secretlab.ca/git/linux-2.6-mpc52xx merge
>>>
>>> Grant Likely (2):
>>> powerpc/5200: update defconfigs
>>> powerpc/5200: Bugfix for PCI mapping of memory and IMMR
>>>
>>> arch/powerpc/configs/52xx/cm5200_defconfig | 83 ++++++++++++++------
>>> arch/powerpc/configs/52xx/lite5200b_defconfig | 86 +++++++++++++++-----
>>> arch/powerpc/configs/52xx/motionpro_defconfig | 85 +++++++++++++++-----
>>> arch/powerpc/configs/52xx/pcm030_defconfig | 82 +++++++++++++------
>>> arch/powerpc/configs/52xx/tqm5200_defconfig | 89 +++++++++++++++------
>>> arch/powerpc/configs/mpc5200_defconfig | 104 ++++++++++++++++++-------
>>> arch/powerpc/platforms/52xx/mpc52xx_pci.c | 24 +++----
>>> 7 files changed, 396 insertions(+), 157 deletions(-)
>>>
>>>
>>> --
>>> Grant Likely, B.Sc., P.Eng.
>>> Secret Lab Technologies Ltd.
>>>
>>
>>
>>
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Add support for the digsy MTC board.
From: Grant Likely @ 2009-01-30 16:59 UTC (permalink / raw)
To: Grzegorz Bernacki; +Cc: linuxppc-dev
In-Reply-To: <1233329630876-git-send-email-gjb@semihalf.com>
On Fri, Jan 30, 2009 at 8:33 AM, Grzegorz Bernacki <gjb@semihalf.com> wrote:
> This is the InterControl custom device based on the MPC5200B chip.
>
> Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Hi Grzogorz,
Thanks for the patch. Comments below.
g.
>
> diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts b/arch/powerpc/boot/dts/digsy_mtc.dts
> new file mode 100644
> index 0000000..a92a6b7
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/digsy_mtc.dts
> @@ -0,0 +1,287 @@
> +/*
> + * Digsy MTC board Device Tree Source
> + *
> + * Copyright (C) 2009 Semihalf
> + *
> + * Based on the CM5200 by M. Balakowicz
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "mtc,digsy";
> + compatible = "mtc,digsy";
This should be something like: "intercontrol,digsy-mtc". Compatible
values should be in the form "<vendor>,<model>".
> + mpc5200_pic: interrupt-controller@500 {
> + // 5200 interrupts are encoded into two levels;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + device_type = "interrupt-controller";
Drop device_type here.
> + compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
> + reg = <0x500 0x80>;
> + };
> +
> + timer@600 { // General Purpose Timer
> + compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> + cell-index = <0>;
Drop cell-index on all the timer nodes. If you compare this file with
the current cm5200.dts in mainline then you'll see the properties that
you can drop.
Otherwise the device tree looks pretty good.
> diff --git a/arch/powerpc/configs/52xx/digsy_mtc_defconfig b/arch/powerpc/configs/52xx/digsy_mtc_defconfig
> new file mode 100644
> index 0000000..ad70d5b
> --- /dev/null
> +++ b/arch/powerpc/configs/52xx/digsy_mtc_defconfig
[...]
Do you *really* need your own defconfig for the digsy_mtc. I've
grudgingly accepted them for other boards under the argument that the
defconfig reflects a specific application of the board. However, I'd
much rather see the digsy added to the multiplatform
mpc5200_defconfig, especially considering that the MTC looks like it's
supposed to be a general purpose platform.
> diff --git a/arch/powerpc/platforms/52xx/digsy_mtc.c b/arch/powerpc/platforms/52xx/digsy_mtc.c
> new file mode 100644
> index 0000000..8cd8cae
> --- /dev/null
> +++ b/arch/powerpc/platforms/52xx/digsy_mtc.c
> @@ -0,0 +1,157 @@
> +/*
> + * Digsy MTC board support
> + *
> + * Based on Lite5200 support by Grant Likely <grant.likely@secretlab.ca>
> + *
> + * Copyright (C) Secret Lab Technologies Ltd. 2006.
> + * Copyright (C) Freescale Semicondutor, Inc. 2006.
> + * Copyright (C) Semihalf 2009.
> + * All rights reserved.
I don't think "All rights reserved" is appropriate here.
> +/*
> + * Fix setting of port_config register.
> + */
> +static void __init
> +digsy_fix_port_config(void)
[...]
> +static void __init
> +digsy_fix_clock_config(void)
[...]
There is a lot of direct copy/paste from the lite5200.c board file,
but the big scary warning comment about not duplicating this code was
deleted in the copy (so I know you saw it). Is Semihalf responsible
for the U-Boot port to the digsy-mtc? If so then please fix the
port_config and clock settings in u-boot.
If it is not possible to update the u-boot image, or if there are
already to many deployed systems to rely on getting the firmware fix,
then calling these functions is okay, but I don't like the verbatim
copy/paste. I think it would be better to factor out and rename the
lite5200_fix_*() functions to mpc5200_fix_*() functions in
mpc52xx_common.c and have the lite5200 and digsy support code call the
common code. the fix_port_config function should take to arguments; a
mask and a value that can be applied to the current port_config
setting. Clock config can probably be copied over as-is. Split the
refactoring of lite5200_fix_*() changes into a separate patch when you
resubmit. If you don't have a lite5200, then don't worry about
testing it, just make sure it compiles. I'll test it before I merge
it into my tree.
Also digsy_fix_port_config() has the lines:
>+ port_config &= ~0x00007000; /* USB port : Differential mode */
>+ port_config |= 0x00002000; /* USB 1 only */
These lines were modified from lite5200.c to select 2 UARTs instead of
USB, but the comment was left the same.
> +static void __init digsy_setup_arch(void)
> +{
> + if (ppc_md.progress)
> + ppc_md.progress("digsy_setup_arch()", 0);
> +
> + /* Map important registers from the internal memory map */
> + mpc52xx_map_common_devices();
> +
> + /* Some mpc5200 & mpc5200b related configuration */
> + mpc5200_setup_xlb_arbiter();
> +
> + /* Fix things that firmware should have done. */
> + digsy_fix_clock_config();
> + digsy_fix_port_config();
> +
> + mpc52xx_setup_pci();
> +}
> +
> +define_machine(digsy) {
> + .name = "digsy",
would 'digsy-mts' be better here?
^ 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