Re: missing current-speed property prevents autoconsole on pegasos
On Thu, Apr 24, Matt Sealey wrote: > Why not just have users who wish to use console serial port autodetection > add 3 lines to their nvramrc? The point of autodetection is that no userinteraction is required. I guess the serial driver does not probe the configured hardware port speed anymore (if it ever did that). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc copy_siginfo_from_user32
On Sat, Apr 19, 2008 at 03:19:24PM -0700, Roland McGrath wrote: > Hi. I posted this before, but I don't see it in any of your powerpc.git > trees. Can you push this upstream ASAP? It would make life easier for me > trying to merge some more generic changes (that would break powerpc builds > without this going in first). Any chance you could re-submit the patch to switch powerpc to the generic PTRACE_GETSIGINFO using this aswell? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32
On Thu, Apr 24, 2008 at 12:37:50AM -0500, Kumar Gala wrote: > config IRQSTACKS > bool "Use separate kernel stacks when processing interrupts" > - depends on PPC64 Why do we have this as a user-selectable option? It should be on by default on 32 or 64bit. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ML405 failed reboot
I'm posting a little more info 'cause no-one took the bait: # tail -f /tmp/messages & # reboot The system is going down NOW! Sending SIGTERM to all processes Requesting system reboot [ 2021.926957] Restarting system. [ 2021.9[ 2021.931063] Kernel stack overflow in process c7c52c10, r1=c01fc25b [ 2021.935935] NIP: c7503dc8 LR: 0001 CTR: [ 2021.940871] REGS: c7503d40 TRAP: c000b3b8 Not tainted (2.6.24-rc8-xlnx) [ 2021.947679] MSR: fee1dead CR: c01d XER: [ 2021.953996] TASK = c7c52c10[261] 'init' THREAD: c7502000 [ 2021.959084] GPR00: 1001 c01fc25b 0012 c7503d72 c7503db0 c0017020 07e5 [ 2021.967376] GPR08: 3c343e5b 20323032 312e3932 38373530 5d2000d0 c0017020 07e5 [ 2021.975669] GPR16: 3c303e5b 20323032 312e3932 36393537 5d2000b0 004d [ 2021.983963] GPR24: fee1dead 28121969 c7503df0 c00170a8 0200 c7503df8 [ 2021.992430] NIP [c7503dc8] 0xc7503dc8 [ 2021.996059] LR [0001] 0x1 [ 2021.998997] Call Trace: [ 2022.001423] Kernel panic - not syncing: kernel stack overflow [ 2022.007142] Rebooting in 180 seconds.. [ 2201.477426] Code: 30001 [ 2201.477437] Addr: c01e5f28 [ 2201.484367] Oops: Exception in kernel mode, sig: 4 [#1] [ 2201.489548] NIP: c01e5f28 LR: 01d6 CTR: [ 2201.494480] REGS: c01e5ea0 TRAP: c000b3b8 Not tainted (2.6.24-rc8-xlnx) [ 2201.501293] MSR: 20323032 CR: 01d6 XER: d07870f8 [ 2201.507609] TASK = c7c52c10[261] 'init' THREAD: c7502000 [ 2201.512698] GPR00: c01e5eb0 c01fc25b c01b1634 c01e5f18 c01e5f10 c0017020 0012 19e7 [ 2201.520990] GPR08: c01e5ee0 c0016820 0030 00021030 c01e5ee0 c01fc271 0012 c01e5f02 [ 2201.529284] GPR16: c01e5f40 c0017020 07e6 3c303e5b 20323032 322e3030 004d [ 2201.537578] GPR24: 0002bf20 0001 28121969 c01e5f50 c00170a8 0200 c01e5f58 [ 2201.546044] NIP [c01e5f28] 0xc01e5f28 [ 2201.549673] LR [01d6] 0x1d6 [ 2201.552783] Call Trace: [ 2201.555202] Instruction dump: [ 2201.558142] [ 2201.565826] And now it's truly well hung. Problem with init ? The wait reboot is compiled ? The reset vector ? -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpiolib support for mpc5200
Hi Sascha,
One small comment.
On Thu, 24 Apr 2008 17:36:59 +0200 Sascha Hauer <[EMAIL PROTECTED]> wrote:
>
> +#include
Never include , use
> +static struct of_device_id mpc52xx_wkup_gpiochip_match[] = {
const, please.
OK, I lied about only one comment :-)
> +static struct of_device_id mpc52xx_simple_gpiochip_match[] = {
const, again.
> +static struct of_device_id mpc52xx_gpt_gpiochip_match[] = {
Another one.
Also, I don't think you need to include
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp33FHfMuPwH.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
sysfs cpu entry
Hi, Can someone suggest where to add the code for a cpu (/sys/devices/system/cpu/cpu0) entry in sysfs? The 2.6.24 release has a sysfs.c file but it only seems to be used for 64-bit? Anyone know why? What kind of planetary disasters will I create if I allow it to be used in 32-bit as well? kevin P.S.: On an unrelated note, anyone know where to start looking for problems in pmac_zilog. My 8600 modem which worked fine in 2.4 is now essentially useless. Some problem with handshaking, I think. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH, RESEND] RTC class driver for ppc_md RTC functions
This hooks up the platform-specific [gs]et_rtc_time functions so that
kernels using CONFIG_RTC_CLASS have RTC support on most PowerPC
platforms.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 1e6715e..3e788b7 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -461,4 +461,12 @@ config RTC_DRV_RS5C313
help
If you say yes here you get support for the Ricoh RS5C313 RTC chips.
+config RTC_DRV_PPC
+ tristate "PowerPC machine dependent RTC support"
+ depends on PPC_MERGE
+ help
+ The PowerPC kernel has machine-specific functions for accessing
+the RTC. This exposes that functionality through the generic RTC
+class.
+
endif # RTC_CLASS
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 465db4d..e822e56 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -49,3 +49,4 @@ obj-$(CONFIG_RTC_DRV_TEST)+= rtc-test.o
obj-$(CONFIG_RTC_DRV_V3020)+= rtc-v3020.o
obj-$(CONFIG_RTC_DRV_VR41XX) += rtc-vr41xx.o
obj-$(CONFIG_RTC_DRV_X1205)+= rtc-x1205.o
+obj-$(CONFIG_RTC_DRV_PPC) += rtc-ppc.o
--- /dev/null 2007-12-03 03:08:41.854157978 +
+++ b/drivers/rtc/rtc-ppc.c 2007-12-03 16:56:15.0 +
@@ -0,0 +1,69 @@
+/*
+ * RTC driver for ppc_md RTC functions
+ *
+ * © 2007 Red Hat, Inc.
+ *
+ * Author: David Woodhouse <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+
+#include
+#include
+#include
+#include
+#include
+
+static int ppc_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ ppc_md.get_rtc_time(tm);
+ return 0;
+}
+
+static int ppc_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ return ppc_md.set_rtc_time(tm);
+}
+
+static const struct rtc_class_ops ppc_rtc_ops = {
+ .set_time = ppc_rtc_set_time,
+ .read_time = ppc_rtc_read_time,
+};
+
+static struct rtc_device *rtc;
+static struct platform_device *ppc_rtc_pdev;
+
+static int __init ppc_rtc_init(void)
+{
+ if (!ppc_md.get_rtc_time || !ppc_md.set_rtc_time)
+ return -ENODEV;
+
+ ppc_rtc_pdev = platform_device_register_simple("ppc-rtc", 0, NULL, 0);
+ if (IS_ERR(ppc_rtc_pdev))
+ return PTR_ERR(ppc_rtc_pdev);
+
+ rtc = rtc_device_register("ppc_md", &ppc_rtc_pdev->dev,
+ &ppc_rtc_ops, THIS_MODULE);
+ if (IS_ERR(rtc)) {
+ platform_device_unregister(ppc_rtc_pdev);
+ return PTR_ERR(rtc);
+ }
+
+ return 0;
+}
+
+static void __exit ppc_rtc_exit(void)
+{
+ rtc_device_unregister(rtc);
+ platform_device_unregister(ppc_rtc_pdev);
+}
+
+module_init(ppc_rtc_init);
+module_exit(ppc_rtc_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("David Woodhouse <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Generic RTC class driver for PowerPC");
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
Hi Jon,
On Tue, 19 Feb 2008 17:42:21 +0100, Jean Delvare wrote:
> On Mon, 21 Jan 2008 15:07:40 -0500, Jon Smirl wrote:
> > Alter the mpc i2c driver to use the NO_IRQ symbol instead of
> > the constant zero when checking for valid interrupts. NO_IRQ=-1
> > on ppc and NO_IRQ=0 on powerpc so the checks against zero are
> > not correct.
>
> Using NO_IRQ sounds good, just one question:
>
> >
> > Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
> > ---
> >
> > drivers/i2c/busses/i2c-mpc.c | 10 +-
> > 1 files changed, 5 insertions(+), 5 deletions(-)
> >
> >
> > diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> > index bbe787b..d20959d 100644
> > --- a/drivers/i2c/busses/i2c-mpc.c
> > +++ b/drivers/i2c/busses/i2c-mpc.c
> > @@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned
> > timeout, int writing)
> > u32 x;
> > int result = 0;
> >
> > - if (i2c->irq == 0)
> > + if (i2c->irq == NO_IRQ)
> > {
> > while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
> > schedule();
> > @@ -329,7 +329,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > return -ENOMEM;
> >
> > i2c->irq = platform_get_irq(pdev, 0);
> > - if (i2c->irq < 0) {
> > + if (i2c->irq < NO_IRQ) {
>
> I am skeptical about this one. Can platform_get_irq() really return
> NO_IRQ? I thought that the IRQ resource would be plain missing if the
> device has no IRQ, so I would expect:
>
> i2c->irq = platform_get_irq(pdev, 0);
> if (i2c->irq < 0)
> i2c->irq = NO_IRQ; /* Use polling */
>
> Testing against NO_IRQ suggests that devices with no IRQ would still
> have an IRQ resource defined and explicitly set to NO_IRQ. Sounds weird
> to me. Can you please clarify this point?
>
> For what it's worth, no other kernel driver checks for irq < NO_IRQ.
> They all check for irq < 0 after calling platform_get_irq().
>
> > result = -ENXIO;
> > goto fail_get_irq;
> > }
> > @@ -344,7 +344,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > goto fail_map;
> > }
> >
> > - if (i2c->irq != 0)
> > + if (i2c->irq != NO_IRQ)
> > if ((result = request_irq(i2c->irq, mpc_i2c_isr,
> > IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
> > printk(KERN_ERR
> > @@ -367,7 +367,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > return result;
> >
> >fail_add:
> > - if (i2c->irq != 0)
> > + if (i2c->irq != NO_IRQ)
> > free_irq(i2c->irq, i2c);
> >fail_irq:
> > iounmap(i2c->base);
> > @@ -384,7 +384,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> > i2c_del_adapter(&i2c->adap);
> > platform_set_drvdata(pdev, NULL);
> >
> > - if (i2c->irq != 0)
> > + if (i2c->irq != NO_IRQ)
> > free_irq(i2c->irq, i2c);
> >
> > iounmap(i2c->base);
>
> The rest looks good.
Any news about this patch? I had a question above which is left
unanswered. If you want this patch merged in 2.6.26 you'll have to be
quick.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpiolib support for mpc5200
On Thu, Apr 24, 2008 at 12:45:49PM -0600, Grant Likely wrote:
> On Thu, Apr 24, 2008 at 9:36 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > Feel free to comment on this.
> >
> > Sascha
> >
> >
> > This patch adds gpiolib support for mpc5200 SOCs. I'm not sure
> > whether it's a good idea to make this optional via kconfig.
> > The gpt devices only support a single gpio. In the current of_gpio
> > implementation each chip consumes 32 GPIOs which leads to huge
> > gaps.
> >
> > Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]>
>
> Looks pretty good. You've saved me the need to go write a driver
> myself. Comments below, but I'll pull it into my tree and give it a
> spin.
>
> I don't see any mechanism for setting the open drain state of the pin.
> That will either need to be done by platform code or encoded into the
> device tree. Does the OF gpio infrastructure provide any callback to
> the driver when something requests the pin? That would seem to be the
> ideal place to set the open drain state.
No, unfortunately not. The generic gpio stuff does not provide this
callback, so of gpio has no chance to do so.
This would also be a good place to catch the registration of reserved
pins, so maybe it's worth discussing this with the gpiolib maintainers.
>
> You'll also need to document the format of the gpio pin specifier for
> these devices (ie. first cell is GPIO number, second cell is ).
I've taken the two-cell approach from booting-without-of.txt. There the
second cell is for flags. We could encode the open drain state into
this.
>
> As for the wide spans caused by gpt gpios, it is probably okay for
> now, but we can rework it to do something clever (like have a single
> registration for all gpt gpios) at a later date.
I would rather teach the of gpio infrastructure not to reserve 32 gpios
for each chip. This will bite us once we want to support gpio chips with
more than 32 gpios anyway.
> > + *
> > + */
> > +static int mpc52xx_wkup_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> > +{
> > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > + struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
> > + unsigned int ret;
> > +
> > + ret = (in_8(®s->wkup_ival) >> (7 - gpio)) & 1;
> > +
> > + pr_debug("%s: gpio: %d ret: %d\n", __func__, gpio, ret);
>
> dev_dbg maybe?
We would have to carry the device from the probe function to this
function just for the debugging output. I'm not sure if it's worth it.
>
> > +
> > + return ret;
> > +}
> > +
> > +static void mpc52xx_wkup_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_gpio_wkup __iomem *regs = mm_gc->regs;
> > + unsigned int tmp;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&gpio_lock, flags);
> > +
> > + tmp = in_8(®s->wkup_dvo);
> > + if (val)
> > + tmp |= 1 << (7 - gpio);
> > + else
> > + tmp &= ~(1 << (7 - gpio));
> > + out_8(®s->wkup_dvo, tmp);
>
> Rather than read/modify/write of the device register; the function
> would probably be faster (one fewer barrier) if you used a shadow
> register of the pin state and the critical region would be
> shorter/simpler. Also, while this device doesn't have the side
> effects associated with shared input/output register, it might still
> be good form to use a shadow register just for the sake of clarity.
OK
>
> > +
> > + spin_unlock_irqrestore(&gpio_lock, flags);
> > +
> > + pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
> > +}
> > +
> > +static int mpc52xx_wkup_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_gpio_wkup *regs = mm_gc->regs;
> > + unsigned int tmp;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&gpio_lock, flags);
> > +
> > + tmp = in_8(®s->wkup_ddr);
> > + tmp &= ~(1 << (7 - gpio));
> > + out_8(®s->wkup_ddr, tmp);
> > +
> > + spin_unlock_irqrestore(&gpio_lock, flags);
> > +
> > + return 0;
> > +}
> > +
> > +static int mpc52xx_wkup_gpio_dir_out(struct gpio_chip *gc, unsigned int
> > gpio, int val)
> > +{
> > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > + struct mpc52xx_gpio_wkup *regs = mm_gc->regs;
> > + unsigned int tmp;
> > + unsigned long flags;
> > +
> > + /* First set initial value */
> > + mpc52xx_wkup_gpio_set(gc, gpio, val);
> > +
> > + spin_lock_irqsave(&gpio_lock, flags);
> > +
> > + /* Then set direction */
> > + tmp = in_8(®s->wkup_ddr);
> > + tmp |= 1 << (7 - gpio);
> > + out_8(®s->wkup_ddr, tmp);
> > +
> > + /* Finally enable the pin */
> > + tm
[PATCH] add gpiolib support for mpc5200
This patch adds gpiolib support for mpc5200 SOCs.
Changes since last submit:
- fixed checkpatch warnings
- use shadow variables for register accesses
- make match tables const
- Add documentation
Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]>
---
Documentation/powerpc/mpc52xx-device-tree-bindings.txt | 12
arch/powerpc/platforms/52xx/Kconfig|6
arch/powerpc/platforms/52xx/Makefile |2
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 465 +
4 files changed, 485 insertions(+)
Index: linux-2.6-powerpc/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
===
--- /dev/null
+++ linux-2.6-powerpc/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -0,0 +1,465 @@
+/*
+ * MPC52xx gpio driver
+ *
+ * Copyright (c) 2008 Sascha Hauer <[EMAIL PROTECTED]>, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static DEFINE_SPINLOCK(gpio_lock);
+
+struct mpc52xx_gpiochip {
+ struct of_mm_gpio_chip mmchip;
+ unsigned int shadow_dvo;
+ unsigned int shadow_gpioe;
+ unsigned int shadow_ddr;
+};
+
+/*
+ * GPIO LIB API implementation for wakeup GPIOs.
+ *
+ * There's a maximum of 8 wakeup GPIOs. Which of these are available
+ * for use depends on your board setup.
+ *
+ * 0 -> GPIO_WKUP_7
+ * 1 -> GPIO_WKUP_6
+ * 2 -> PSC6_1
+ * 3 -> PSC6_0
+ * 4 -> ETH_17
+ * 5 -> PSC3_9
+ * 6 -> PSC2_4
+ * 7 -> PSC1_4
+ *
+ */
+static int mpc52xx_wkup_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
+ unsigned int ret;
+
+ ret = (in_8(®s->wkup_ival) >> (7 - gpio)) & 1;
+
+ pr_debug("%s: gpio: %d ret: %d\n", __func__, gpio, ret);
+
+ return ret;
+}
+
+static inline void
+__mpc52xx_wkup_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_gpiochip *chip = container_of(mm_gc,
+ struct mpc52xx_gpiochip, mmchip);
+ struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
+
+ if (val)
+ chip->shadow_dvo |= 1 << (7 - gpio);
+ else
+ chip->shadow_dvo &= ~(1 << (7 - gpio));
+
+ out_8(®s->wkup_dvo, chip->shadow_dvo);
+}
+
+static void
+mpc52xx_wkup_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ __mpc52xx_wkup_gpio_set(gc, gpio, val);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+}
+
+static int mpc52xx_wkup_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_gpiochip *chip = container_of(mm_gc,
+ struct mpc52xx_gpiochip, mmchip);
+ struct mpc52xx_gpio_wkup *regs = mm_gc->regs;
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ /* set the direction */
+ chip->shadow_ddr &= ~(1 << (7 - gpio));
+ out_8(®s->wkup_ddr, chip->shadow_ddr);
+
+ /* and enable the pin */
+ chip->shadow_gpioe |= 1 << (7 - gpio);
+ out_8(®s->wkup_gpioe, chip->shadow_gpioe);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ return 0;
+}
+
+static int
+mpc52xx_wkup_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio_wkup *regs = mm_gc->regs;
+ struct mpc52xx_gpiochip *chip = container_of(mm_gc,
+ struct mpc52xx_gpiochip, mmchip);
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ __mpc52xx_wkup_gpio_set(gc, gpio, val);
+
+ /* Then set direction */
+ chip->shadow_ddr |= 1 << (7 - gpio);
+ out_8(®s->wkup_ddr, chip->shadow_ddr);
+
+ /* Finally enable the pin */
+ chip->shadow_gpioe |= 1 << (7 - gpio);
+ out_8(®s->wkup_gpioe, chip->shadow_gpioe);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n",
Re: [PATCH] Change the default link address for pSeries zImage kernels.
On Fri, 25 Apr 2008 16:12:50 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-04-25 at 15:39 +1000, Tony Breeds wrote: > > Currently we set the start of the .text section to be 4Mb for pSeries. > > In situations where the zImage is > 8Mb we'll fail to boot (due to > > overlapping with OF). Move .text in a pSeries zImage from 4MB to 64MB > > (well past OF). > > > > Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> > > --- > > - Compile tested for *_defconfig with only pSeries chaning it's link > >address. > > - Boot tested on POWER6 > > Considering how bad OF can be on some machines, I'd like this to be > boot-tested on a wider range of machines. Also, it might depend on the > OF real-base setting as well... > > At least, we should be able to test at ozlabs on cell blades, POWER4 > bare metal (ie "SMP mode"), POWER5 and POWER5+. And given that all the embedded boards use zImage.lds.S, we should probably test it there. I'll try to test on 4xx for both treeImage and U-Boot today. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Fri, 25 Apr 2008 16:24:01 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
> > This patch adds basic endpoint support to the 4xx PCIe driver.
> >
> > This is done by checking the device_type property of the PCIe
> > device node ("pci" for root-complex and "pci-endpoint" for endpoint
> > configuration).
> >
> > Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
> > This should probably be configurable via a dts property.
> >
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
>
> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
>
> Paul, I forgot to send that ack a while ago, this is .26 material, been
> around for some time.
I'll add it to my tree. And this version of the patch was only sent
out on Monday.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] MTD: fix partition scan control logic in physmap_ofand fsl_elbc_nand
> -Original Message- > From: David Woodhouse [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 23, 2008 2:49 AM > To: Li Yang > Cc: [EMAIL PROTECTED]; Stefan Roese; > linuxppc-dev@ozlabs.org > Subject: Re: [PATCH] MTD: fix partition scan control logic in > physmap_ofand fsl_elbc_nand > > On Thu, 2008-02-28 at 20:17 +0800, Li Yang wrote: > > The generic rule for partition scan is to try all supported > partition > > types before an usable partition table is found. > > However the original code returns unsuccessful when there > is an error > > in any of the partition types. > > > > Signed-off-by: Li Yang <[EMAIL PROTECTED]> > > Cc: Stefan Roese <[EMAIL PROTECTED]> > > Cc: Peter Korsgaard <[EMAIL PROTECTED]> > > --- > > I later found that Stefan has proposed a similar patch for > physmap_of > > and Peter proposed another patch to fix cmdlinepart instead. > > I'd say that even after cmdlinepart patch is applied the > scan control > > logic still needs to be fixed. > > I'm not convinced. I think the partition code should return > an error if it hits a hard error, like a failure to read from > the device. And return zero when it doesn't find anything. The error can also be soft error like a typo in the cmdline or device tree. I could be better to try other ways to see if we can find a sane partition table than just to fail. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/2] spi_mpc83xx: test below 0 on unsigned irq in mpc83xx_spi_probe()
On Wed, 2008-04-23 at 23:55 +0200, Joakim Tjernlund wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:linuxppc-dev-
> > [EMAIL PROTECTED] On Behalf Of Roel Kluin
> > Sent: den 23 april 2008 22:55
> > To: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; lkml
> > Subject: [PATCH 1/2] spi_mpc83xx: test below 0 on unsigned irq in
> > mpc83xx_spi_probe()
> >
> > mpc83xx_spi->irq is unsigned, so the test fails
> >
> > Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
>
> hmm, I got a pretty large 83xx spi patch queued at dbrownell. I hope
> that one can be applied first. Then you probably need to rediff this patch.
>
> David, any progress on my patch?
David, heard nothing from you in a while. Don't you get my mails?
Jocke
>
> Jocke
> > ---
> > diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
> > index be15a62..033fd51 100644
> > --- a/drivers/spi/spi_mpc83xx.c
> > +++ b/drivers/spi/spi_mpc83xx.c
> > @@ -454,12 +454,12 @@ static int __init mpc83xx_spi_probe(struct
> > platform_device *dev)
> > goto put_master;
> > }
> >
> > - mpc83xx_spi->irq = platform_get_irq(dev, 0);
> > -
> > - if (mpc83xx_spi->irq < 0) {
> > - ret = -ENXIO;
> > + ret = platform_get_irq(dev, 0);
> > + if (ret < 0)
> > goto unmap_io;
> > - }
> > +
> > + mpc83xx_spi->irq = ret;
> > + ret = 0;
> >
> > /* Register for SPI Interrupt */
> > ret = request_irq(mpc83xx_spi->irq, mpc83xx_spi_irq,
> >
> > ___
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.
On Wednesday 23 April 2008 13:12, Sergei Shtylyov wrote: > David Woodhouse wrote: > > Ok. I'll submit a new patch as soon as we agree on a compatible name. > > >>>Did we? > > >>IIRC, The latest agreement was that we don't need the "compatible" and > >>will match on node name. > > > Ok. Is there a current patch I should be merging? > > Looks like it was decided to revert to the platform device method, not > sure why -- so, no changes. Laurent? Last thing I heard was that the device tree should not encode a device's expected usage, so memory nodes should not have any compatible property that would automatically associated them to an MTD driver. I've been adviced to add platform-specific code to instantiate a platform device manually (possibly checking if the required memory node is present in the device tree). This arguably makes sense, but adds more platform-specific code. So, no need for a patch so far. -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgp3fLPlDnaxC.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpiolib support for mpc5200
On Fri, Apr 25, 2008 at 12:53:33PM +0200, Sascha Hauer wrote: [...] > > > > As for the wide spans caused by gpt gpios, it is probably okay for > > now, but we can rework it to do something clever (like have a single > > registration for all gpt gpios) at a later date. > > I would rather teach the of gpio infrastructure not to reserve 32 gpios > for each chip. This will bite us once we want to support gpio chips with > more than 32 gpios anyway. The patch already exists: http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052881.html It is waiting for few patches that are in the -mm tree (Andrew said that he'll push them into 2.6.26 at some point). -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
Paulus, is there any specific reason, why out of these 7 patches only the first one made it into the mainline? AFAICS, there has been only one comment, suggesting to replace printk with dev_err on two occasions in one of the patches... Thanks Guennadi --- Guennadi Liakhovetski ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Fri, 2008-04-25 at 05:37 -0500, Josh Boyer wrote:
> On Fri, 25 Apr 2008 16:24:01 +1000
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> >
> > On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
> > > This patch adds basic endpoint support to the 4xx PCIe driver.
> > >
> > > This is done by checking the device_type property of the PCIe
> > > device node ("pci" for root-complex and "pci-endpoint" for endpoint
> > > configuration).
> > >
> > > Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
> > > This should probably be configurable via a dts property.
> > >
> > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> >
> > Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > ---
> >
> > Paul, I forgot to send that ack a while ago, this is .26 material, been
> > around for some time.
>
> I'll add it to my tree. And this version of the patch was only sent
> out on Monday.
True but I'm to blame for waiting too long to review it...
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32
On Fri, 2008-04-25 at 09:23 +0200, Christoph Hellwig wrote: > On Thu, Apr 24, 2008 at 12:37:50AM -0500, Kumar Gala wrote: > > config IRQSTACKS > > bool "Use separate kernel stacks when processing interrupts" > > - depends on PPC64 > > Why do we have this as a user-selectable option? It should be on by > default on 32 or 64bit. History maybe ? In the early days it was a bit "experimental" (we had a couple of issues that popped up with some thread flags not being properly recovered etc...). Nowadays, I agree it should not be an option. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpiolib support for mpc5200
On Thu, Apr 24, 2008 at 05:36:59PM +0200, Sascha Hauer wrote: > +#include > +#include > +#include > +#include > +#include > +#include > +#include In the latest kernels the preferred way is to include , the patch introducing it was merged just recently, so few people know about it yet. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Fri, 25 Apr 2008 22:58:04 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-04-25 at 05:37 -0500, Josh Boyer wrote:
> > On Fri, 25 Apr 2008 16:24:01 +1000
> > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
> > > > This patch adds basic endpoint support to the 4xx PCIe driver.
> > > >
> > > > This is done by checking the device_type property of the PCIe
> > > > device node ("pci" for root-complex and "pci-endpoint" for endpoint
> > > > configuration).
> > > >
> > > > Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
> > > > This should probably be configurable via a dts property.
> > > >
> > > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > >
> > > Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > > ---
> > >
> > > Paul, I forgot to send that ack a while ago, this is .26 material, been
> > > around for some time.
> >
> > I'll add it to my tree. And this version of the patch was only sent
> > out on Monday.
>
> True but I'm to blame for waiting too long to review it...
Oh, for sure. We blame you for all kinds of things. It's just easier
that way ;)
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32
On Apr 25, 2008, at 8:03 AM, Benjamin Herrenschmidt wrote: On Fri, 2008-04-25 at 09:23 +0200, Christoph Hellwig wrote: On Thu, Apr 24, 2008 at 12:37:50AM -0500, Kumar Gala wrote: config IRQSTACKS bool "Use separate kernel stacks when processing interrupts" - depends on PPC64 Why do we have this as a user-selectable option? It should be on by default on 32 or 64bit. History maybe ? In the early days it was a bit "experimental" (we had a couple of issues that popped up with some thread flags not being properly recovered etc...). Nowadays, I agree it should not be an option. for some reason I felt that it was pretty much required on ppc64 when I did the port over to ppc32. Do we think we want to poke Paul to get this in for v2.6.26 so we can get it some more testing on all the ppc32 systems? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpiolib support for mpc5200
On Fri, Apr 25, 2008 at 05:07:37PM +0400, Anton Vorontsov wrote: > On Thu, Apr 24, 2008 at 05:36:59PM +0200, Sascha Hauer wrote: > > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > In the latest kernels the preferred way is to include , > the patch introducing it was merged just recently, so few people know > about it yet. Yes, checkpatch told me, but doing so resulted in a compilation error. This only showed that a "select GENERIC_GPIO" was missing in my patch. Will update. Sascha -- Pengutronix e.K. - Linux Solutions for Science and Industry --- Kontakt-Informationen finden Sie im Header dieser Mail oder auf der Webseite -> http://www.pengutronix.de/impressum/ <- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[MailServer Resend] Quarantined email -- use caution when opening.Re: [PATCH 3/3] Use __weak macro for smp_setup_processor_id
- Original Message Header -
Subject: Re: [PATCH 3/3] Use __weak macro for smp_setup_processor_id
From: [EMAIL PROTECTED];
To: [EMAIL PROTECTED];
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
---
Warning: Attachment contains virus code or meets the filtering/blocking
rules. Use caution when accessing the contents.
--- Begin Message ---
On Fri, 18 Apr 2008 18:19:07 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> On Fri, 2008-04-18 at 00:07 -0700, Andrew Morton wrote:
> > On Fri, 18 Apr 2008 16:56:18 +1000 Benjamin Herrenschmidt <[EMAIL
> > PROTECTED]> wrote:
> >
> > > Use the __weak macro instead of the longer __attribute__ ((weak)) form
> > >
> > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > > --
> > >
> > > init/main.c |2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > --- linux-work.orig/init/main.c 2008-04-18 16:44:32.0 +1000
> > > +++ linux-work/init/main.c2008-04-18 16:44:37.0 +1000
> > > @@ -500,7 +500,7 @@ static void __init boot_cpu_init(void)
> > > cpu_set(cpu, cpu_possible_map);
> > > }
> > >
> > > -void __init __attribute__((weak)) smp_setup_processor_id(void)
> > > +void __init __weak smp_setup_processor_id(void)
> > > {
> > > }
> >
> > ack on all three. Please fold #3 into #1 and add both to git-powerpc.
>
> Damn ! I took 5mn to actually split it out in order to not do two
> different things in one patch :-)
ah, I misread it. I thought this was changing the __attribute__((weak))
which patch #1 added. But it's changing a different one. I though that
was odd.
> Will do.
whatever ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--- End Message ---
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[MailServer Resend] Quarantined email -- use caution when opening.Re: [PATCH 3/3] Use __weak macro for smp_setup_processor_id
- Original Message Header -
Subject: Re: [PATCH 3/3] Use __weak macro for smp_setup_processor_id
From: [EMAIL PROTECTED];
To: [EMAIL PROTECTED];
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
---
Warning: Attachment contains virus code or meets the filtering/blocking
rules. Use caution when accessing the contents.
--- Begin Message ---
On Fri, 2008-04-18 at 00:07 -0700, Andrew Morton wrote:
> On Fri, 18 Apr 2008 16:56:18 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> wrote:
>
> > Use the __weak macro instead of the longer __attribute__ ((weak)) form
> >
> > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > --
> >
> > init/main.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- linux-work.orig/init/main.c 2008-04-18 16:44:32.0 +1000
> > +++ linux-work/init/main.c 2008-04-18 16:44:37.0 +1000
> > @@ -500,7 +500,7 @@ static void __init boot_cpu_init(void)
> > cpu_set(cpu, cpu_possible_map);
> > }
> >
> > -void __init __attribute__((weak)) smp_setup_processor_id(void)
> > +void __init __weak smp_setup_processor_id(void)
> > {
> > }
>
> ack on all three. Please fold #3 into #1 and add both to git-powerpc.
Damn ! I took 5mn to actually split it out in order to not do two
different things in one patch :-)
Will do.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--- End Message ---
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] add Phytec pcm030 board support
Add board support for the Phytec pcm030 mpc5200b based board. It
does not need any platform specific fixups and as such is handled
as a mpc5200 simple platform.
Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/pcm030.dts | 363
arch/powerpc/configs/52xx/pcm030_defconfig | 1109 +++
arch/powerpc/platforms/52xx/mpc5200_simple.c |1
3 files changed, 1473 insertions(+)
Index: linux-2.6-powerpc/arch/powerpc/boot/dts/pcm030.dts
===
--- /dev/null
+++ linux-2.6-powerpc/arch/powerpc/boot/dts/pcm030.dts
@@ -0,0 +1,363 @@
+/*
+ * phyCORE-MPC5200B-tiny (pcm030) board Device Tree Source
+ *
+ * Copyright 2006 Pengutronix
+ * Sascha Hauer <[EMAIL PROTECTED]>
+ * Copyright 2007 Pengutronix
+ * Juergen Beisert <[EMAIL PROTECTED]>
+ *
+ * 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 = "phytec,pcm030";
+ compatible = "phytec,pcm030";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <0x4000>;/* L1, 16K */
+ i-cache-size = <0x4000>;/* L1, 16K */
+ timebase-frequency = <0>; /* From Bootloader */
+ bus-frequency = <0>;/* From Bootloader */
+ clock-frequency = <0>; /* From Bootloader */
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x0400>; /* 64MB */
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc5200b-immr";
+ ranges = <0x0 0xf000 0xc000>;
+ bus-frequency = <0>;/* From bootloader */
+ system-frequency = <0>; /* From bootloader */
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5200b-cdm","fsl,mpc5200-cdm";
+ reg = <0x200 0x38>;
+ };
+
+ mpc5200_pic: [EMAIL PROTECTED] {
+ /* 5200 interrupts are encoded into two levels; */
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ device_type = "interrupt-controller";
+ compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
+ reg = <0x500 0x80>;
+ };
+
+ [EMAIL PROTECTED] { /* General Purpose Timer */
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <0>;
+ reg = <0x600 0x10>;
+ interrupts = <0x1 0x9 0x0>;
+ interrupt-parent = <&mpc5200_pic>;
+ fsl,has-wdt;
+ };
+
+ [EMAIL PROTECTED] { /* General Purpose Timer */
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <1>;
+ reg = <0x610 0x10>;
+ interrupts = <0x1 0xa 0x0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ gpt2: [EMAIL PROTECTED] { /* General Purpose Timer in GPIO mode
*/
+ compatible =
"fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
+ cell-index = <2>;
+ reg = <0x620 0x10>;
+ interrupts = <0x1 0xb 0x0>;
+ interrupt-parent = <&mpc5200_pic>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpt3: [EMAIL PROTECTED] { /* General Purpose Timer in GPIO mode
*/
+ compatible =
"fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
+ cell-index = <3>;
+ reg = <0x630 0x10>;
+ interrupts = <0x1 0xc 0x0>;
+ interrupt-parent = <&mpc5200_pic>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpt4: [EMAIL PROTECTED] { /* General Purpose Timer in GPIO mode
*/
+ compatible =
"fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
+
Re: [PATCH v2] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Apr 25, 2008, at 8:19 AM, Josh Boyer wrote:
On Fri, 25 Apr 2008 22:58:04 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
On Fri, 2008-04-25 at 05:37 -0500, Josh Boyer wrote:
On Fri, 25 Apr 2008 16:24:01 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking the device_type property of the PCIe
device node ("pci" for root-complex and "pci-endpoint" for
endpoint
configuration).
Note: Currently we map a fixed 64MByte window to PLB address 0
(SDRAM).
This should probably be configurable via a dts property.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
Paul, I forgot to send that ack a while ago, this is .26
material, been
around for some time.
I'll add it to my tree. And this version of the patch was only sent
out on Monday.
True but I'm to blame for waiting too long to review it...
Oh, for sure. We blame you for all kinds of things. It's just easier
that way ;)
Can we include an example of the device node in the commit message (or
some updates to docs/booting-with-of.txt)
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches pushed to powerpc.git master and powerpc-next branches
On Thu, 2008-04-24 at 22:11 +1000, Paul Mackerras wrote: > I have put the following patches in the powerpc.git repository on the > master & powerpc-next branches (this includes some pulled from Kumar's > tree). I plan to send a pull request to Linus tomorrow morning my > time, so if there are any others I've missed, or any that people don't > think should go in, let me know within the next 9 hours or so. windfarm_pm121? -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
HR timers on PowerPC 83xx
Trying to understand what is needed to make nanosleep() and friends to have better resolution than HZ on my 83xx CPU. Is this possible and what CONFIG options do I need to enable? Kernel is 2.6.25 Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: HR timers on PowerPC 83xx
Hello. Joakim Tjernlund wrote: Trying to understand what is needed to make nanosleep() and friends to have better resolution than HZ on my 83xx CPU. Is this possible and what CONFIG options do I need to enable? Kernel is 2.6.25 Should be possible with CONFIG_HIGH_RES_TIMERS=y. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: HR timers on PowerPC 83xx
On Fri, 2008-04-25 at 18:18 +0400, Sergei Shtylyov wrote: > Hello. > > Joakim Tjernlund wrote: > > > Trying to understand what is needed to make nanosleep() and friends to > > have better resolution than HZ on my 83xx CPU. Is this possible > > and what CONFIG options do I need to enable? Kernel is 2.6.25 > > Should be possible with CONFIG_HIGH_RES_TIMERS=y. What about NO_HZ? Does that setting change anything? > > WBR, Sergei > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpiolib support for mpc5200
Can I make a suggestion for this chip support?
On certain 5200 boards these devices are not usable since they are not
connected. My concern is the Efika where we only have 2 wakeup and 1 simple
GPIO available on the board and maybe a few others with a bit of tweaking
and messing around.
Instead of having a block for GPIO which has 32 pins, and the ability to
use all of them just by asking for it (get will return a pin regardless)
I implemented a silly hackish "gpio-mask" property in the efika.forth device
tree so the gpiolib "allocate" style functions can tell if a pin is
actually usable or not.
Can we put some small thought into defining a standard for this, and possibly
moving the "number of gpios in the chip" into the device tree? It doesn't
seem particularly complete to just allow blanket use (which may be unsafe and
may change per-board) of pins just because you can twiddle a bit.. (or use
a pin when another driver may be using it).
This will tie into Grant's comments about optimizing the enabling of the
GPIO on every direction change etc. (it should be enabled on allocation
and then you have to make sure you free up your use of the pin, resource
tracking in the kernel is important.. flipping bits here and there without
something in the way in the API is kind of clumsy)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Grant Likely wrote:
On Thu, Apr 24, 2008 at 9:36 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote:
Hi all,
Feel free to comment on this.
Sascha
This patch adds gpiolib support for mpc5200 SOCs. I'm not sure
whether it's a good idea to make this optional via kconfig.
The gpt devices only support a single gpio. In the current of_gpio
implementation each chip consumes 32 GPIOs which leads to huge
gaps.
Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]>
Looks pretty good. You've saved me the need to go write a driver
myself. Comments below, but I'll pull it into my tree and give it a
spin.
I don't see any mechanism for setting the open drain state of the pin.
That will either need to be done by platform code or encoded into the
device tree. Does the OF gpio infrastructure provide any callback to
the driver when something requests the pin? That would seem to be the
ideal place to set the open drain state.
You'll also need to document the format of the gpio pin specifier for
these devices (ie. first cell is GPIO number, second cell is ).
As for the wide spans caused by gpt gpios, it is probably okay for
now, but we can rework it to do something clever (like have a single
registration for all gpt gpios) at a later date.
Cheers,
g.
---
arch/powerpc/platforms/52xx/Kconfig|6
arch/powerpc/platforms/52xx/Makefile |2
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 408
+
3 files changed, 416 insertions(+)
Index: arch/powerpc/platforms/52xx/mpc52xx_gpio.c
===
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -0,0 +1,408 @@
+/*
+ * MPC52xx gpio driver
+ *
+ * Copyright (c) 2008 Sascha Hauer <[EMAIL PROTECTED]>, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static DEFINE_SPINLOCK(gpio_lock);
+
+/*
+ * GPIO LIB API implementation for wakeup GPIOs.
+ *
+ * There's a maximum of 8 wakeup GPIOs. Which of these are available
+ * for use depends on your board setup.
+ *
+ * 0 -> GPIO_WKUP_7
+ * 1 -> GPIO_WKUP_6
+ * 2 -> PSC6_1
+ * 3 -> PSC6_0
+ * 4 -> ETH_17
+ * 5 -> PSC3_9
+ * 6 -> PSC2_4
+ * 7 -> PSC1_4
+ *
+ */
+static int mpc52xx_wkup_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
+ unsigned int ret;
+
+ ret = (in_8(®s->wkup_ival) >> (7 - gpio)) & 1;
+
+ pr_debug("%s: gpio: %d ret: %d\n", __func__, gpio, ret);
dev_dbg maybe?
+
+ return ret;
+}
+
+static void mpc52xx_wkup_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_gpio_wkup __iomem *regs = mm_gc->regs;
+ unsi
Re: HR timers on PowerPC 83xx
Joakim Tjernlund wrote: Trying to understand what is needed to make nanosleep() and friends to have better resolution than HZ on my 83xx CPU. Is this possible and what CONFIG options do I need to enable? Kernel is 2.6.25 Should be possible with CONFIG_HIGH_RES_TIMERS=y. What about NO_HZ? Does that setting change anything? It is independent from HRT and selects the mode where the idle process stops timer HZ interrupts from occuring until it's scheduled off CPU. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/6 v3] Few more patches for Kumar's powerpc.git
Hi Kumar,
Here is the third try.
I've tried to address all the comments from the previous version.
The only comment I left out is merging mpc836x_rdk.c board file into some
existing board (as I explained, there are three QE boards: mpc832x_{rdb,mds}
and mpc836x_mds, and all have board-specific fixups either in the
machine_device_initcall()s or setup_arch()s, so I don't see an easy way to
merge RDK board into existing).
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/6] [POWERPC] sysdev: implement FSL GTM support
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts. These timers are used by the drivers that
need time precise interrupts (like for USB transactions scheduling for
the Freescale USB Host controller as found in some QE and CPM chips),
or these timers could be used as wakeup events from the CPU deep-sleep
mode.
Things unimplemented:
1. Cascaded (32 bit) timers (1-2, 3-4).
This is straightforward to implement when needed, two timers should
be marked as "requested" and configured as appropriate.
2. Super-cascaded (64 bit) timers (1-2-3-4).
This is also straightforward to implement when needed, all timers
should be marked as "requested" and configured as appropriate.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 34 ++-
arch/powerpc/Kconfig |5 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/fsl_gtm.c| 437 ++
include/asm-powerpc/fsl_gtm.h| 34 ++
5 files changed, 510 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_gtm.c
create mode 100644 include/asm-powerpc/fsl_gtm.h
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 4cc7800..0f3738e 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -57,7 +57,8 @@ Table of Contents
n) 4xx/Axon EMAC ethernet nodes
o) Xilinx IP cores
p) Freescale Synchronous Serial Interface
- q) USB EHCI controllers
+ q) USB EHCI controllers
+ r) Freescale General-purpose Timers Module
VII - Marvell Discovery mv64[345]6x System Controller chips
1) The /system-controller node
@@ -2825,6 +2826,37 @@ platforms are moved over to use the
flattened-device-tree model.
big-endian;
};
+r) Freescale General-purpose Timers Module
+
+Required properties:
+ - compatible : should be
+"fsl,-gtm", "fsl,gtm" for SOC GTMs
+"fsl,-qe-gtm", "fsl,qe-gtm", "fsl,gtm" for QE GTMs
+"fsl,-cpm2-gtm", "fsl,cpm2-gtm", "fsl,gtm" for CPM2 GTMs
+ - reg : should contain gtm registers location and length (0x40).
+ - interrupts : should contain four interrupts.
+ - interrupt-parent : interrupt source phandle.
+ - clock-frequency : specifies the frequency driving the timer.
+
+Example:
+
+[EMAIL PROTECTED] {
+ compatible = "fsl,mpc8360-gtm", "fsl,gtm";
+ reg = <0x500 0x40>;
+ interrupts = <90 8 78 8 84 8 72 8>;
+ interrupt-parent = <&ipic>;
+ /* filled by u-boot */
+ clock-frequency = <0>;
+};
+
+[EMAIL PROTECTED] {
+ compatible = "fsl,mpc8360-qe-gtm", "fsl,qe-gtm", "fsl,gtm";
+ reg = <0x440 0x40>;
+ interrupts = <12 13 14 15>;
+ interrupt-parent = <&qeic>;
+ /* filled by u-boot */
+ clock-frequency = <0>;
+};
VII - Marvell Discovery mv64[345]6x System Controller chips
===
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7f2f126..ad874e4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -525,6 +525,11 @@ config FSL_LBC
help
Freescale Localbus support
+config FSL_GTM
+ bool
+ help
+ Freescale General-purpose Timers support
+
# Yes MCA RS/6000s exist but Linux-PPC does not currently support any
config MCA
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 6d386d0..9d3ddd2 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
+obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
new file mode 100644
index 000..ada2b0e
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -0,0 +1,437 @@
+/*
+ * Freescale General-purpose Timers Module
+ *
+ * Copyright (c) Freescale Semicondutor, Inc. 2006.
+ * Shlomi Gridish <[EMAIL PROTECTED]>
+ * Jerry Huang <[EMAIL PROTECTED]>
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#includ
[PATCH 2/6] [POWERPC] QE: add support for QE USB clocks routing
This patch adds a function to the qe_lib to setup QE USB clocks routing.
To setup clocks safely, cmxgcr register needs locking, so I just reused
ucc_lock since it was used only to protect cmxgcr.
The idea behind placing clocks routing functions into the qe_lib is that
later we'll hopefully switch to the generic Linux Clock API, thus, for
example, FHCI driver may be used for QE and CPM chips without nasty #ifdefs.
This patch also fixes QE_USB_RESTART_TX command definition in the qe.h.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/qe_lib/Kconfig |4 ++
arch/powerpc/sysdev/qe_lib/Makefile |1 +
arch/powerpc/sysdev/qe_lib/ucc.c|7 ++--
arch/powerpc/sysdev/qe_lib/usb.c| 56 +++
include/asm-powerpc/qe.h| 23 +-
5 files changed, 87 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/sysdev/qe_lib/usb.c
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig
b/arch/powerpc/sysdev/qe_lib/Kconfig
index adc6621..76ffbc4 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -20,3 +20,7 @@ config UCC
bool
default y if UCC_FAST || UCC_SLOW
+config QE_USB
+ bool
+ help
+ QE USB Host Controller support
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile
b/arch/powerpc/sysdev/qe_lib/Makefile
index 874fe1a..e9ff888 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_ic.o qe_io.o
obj-$(CONFIG_UCC) += ucc.o
obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
obj-$(CONFIG_UCC_FAST) += ucc_fast.o
+obj-$(CONFIG_QE_USB) += usb.o
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/qe_lib/ucc.c
index 0e348d9..d3c7f5a 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -26,7 +26,8 @@
#include
#include
-static DEFINE_SPINLOCK(ucc_lock);
+DEFINE_SPINLOCK(cmxgcr_lock);
+EXPORT_SYMBOL(cmxgcr_lock);
int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
{
@@ -35,10 +36,10 @@ int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
if (ucc_num > UCC_MAX_NUM - 1)
return -EINVAL;
- spin_lock_irqsave(&ucc_lock, flags);
+ spin_lock_irqsave(&cmxgcr_lock, flags);
clrsetbits_be32(&qe_immr->qmx.cmxgcr, QE_CMXGCR_MII_ENET_MNG,
ucc_num << QE_CMXGCR_MII_ENET_MNG_SHIFT);
- spin_unlock_irqrestore(&ucc_lock, flags);
+ spin_unlock_irqrestore(&cmxgcr_lock, flags);
return 0;
}
diff --git a/arch/powerpc/sysdev/qe_lib/usb.c b/arch/powerpc/sysdev/qe_lib/usb.c
new file mode 100644
index 000..69ce78c
--- /dev/null
+++ b/arch/powerpc/sysdev/qe_lib/usb.c
@@ -0,0 +1,56 @@
+/*
+ * QE USB routines
+ *
+ * Copyright (c) Freescale Semicondutor, Inc. 2006.
+ * Shlomi Gridish <[EMAIL PROTECTED]>
+ * Jerry Huang <[EMAIL PROTECTED]>
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+int qe_usb_clock_set(enum qe_clock clk, int rate)
+{
+ struct qe_mux __iomem *mux = &qe_immr->qmx;
+ unsigned long flags;
+ u32 val;
+
+ switch (clk) {
+ case QE_CLK3: val = QE_CMXGCR_USBCS_CLK3; break;
+ case QE_CLK5: val = QE_CMXGCR_USBCS_CLK5; break;
+ case QE_CLK7: val = QE_CMXGCR_USBCS_CLK7; break;
+ case QE_CLK9: val = QE_CMXGCR_USBCS_CLK9; break;
+ case QE_CLK13: val = QE_CMXGCR_USBCS_CLK13; break;
+ case QE_CLK17: val = QE_CMXGCR_USBCS_CLK17; break;
+ case QE_CLK19: val = QE_CMXGCR_USBCS_CLK19; break;
+ case QE_CLK21: val = QE_CMXGCR_USBCS_CLK21; break;
+ case QE_BRG9: val = QE_CMXGCR_USBCS_BRG9; break;
+ case QE_BRG10: val = QE_CMXGCR_USBCS_BRG10; break;
+ default:
+ pr_err("%s: requested unknown clock %d\n", __func__, clk);
+ return -EINVAL;
+ }
+
+ if (qe_clock_is_brg(clk))
+ qe_setbrg(clk, rate, 1);
+
+ spin_lock_irqsave(&cmxgcr_lock, flags);
+
+ clrsetbits_be32(&mux->cmxgcr, QE_CMXGCR_USBCS, val);
+
+ spin_unlock_irqrestore(&cmxgcr_lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL(qe_usb_clock_set);
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index c3be6e2..d217288 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -16,6 +16,7 @@
#define _ASM_POWERPC_QE_H
#ifdef __KERNEL__
+#include
#include
#define QE_NUM_OF_SNUM 28
@@ -74,6 +75,13 @@ enum qe_clock {
QE_CLK_DUMMY
};
+static inline bool qe_clock_is_brg(enum qe_clock clk)
+{
[PATCH 3/6] [POWERPC] QE: prepare QE PIO code for GPIO LIB support
- split and export __par_io_config_pin() out of par_io_config_pin(), so we
could use the prefixed version with GPIO LIB API;
- rename struct port_regs to qe_pio_regs, and place it into qe.h;
- rename #define NUM_OF_PINS to QE_PIO_PINS, and place it into qe.h.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/qe_lib/qe_io.c | 94 +---
include/asm-powerpc/qe.h | 19 +++
2 files changed, 64 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c
b/arch/powerpc/sysdev/qe_lib/qe_io.c
index 93916a4..7c87460 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_io.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
@@ -28,21 +28,7 @@
#undef DEBUG
-#define NUM_OF_PINS32
-
-struct port_regs {
- __be32 cpodr; /* Open drain register */
- __be32 cpdata; /* Data register */
- __be32 cpdir1; /* Direction register */
- __be32 cpdir2; /* Direction register */
- __be32 cppar1; /* Pin assignment register */
- __be32 cppar2; /* Pin assignment register */
-#ifdef CONFIG_PPC_85xx
- u8 pad[8];
-#endif
-};
-
-static struct port_regs __iomem *par_io;
+static struct qe_pio_regs __iomem *par_io;
static int num_par_io_ports = 0;
int par_io_init(struct device_node *np)
@@ -64,69 +50,79 @@ int par_io_init(struct device_node *np)
return 0;
}
-int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
- int assignment, int has_irq)
+void __par_io_config_pin(struct qe_pio_regs __iomem *par_io, u8 pin, int dir,
+int open_drain, int assignment, int has_irq)
{
- u32 pin_mask1bit, pin_mask2bits, new_mask2bits, tmp_val;
-
- if (!par_io)
- return -1;
+ u32 pin_mask1bit;
+ u32 pin_mask2bits;
+ u32 new_mask2bits;
+ u32 tmp_val;
/* calculate pin location for single and 2 bits information */
- pin_mask1bit = (u32) (1 << (NUM_OF_PINS - (pin + 1)));
+ pin_mask1bit = (u32) (1 << (QE_PIO_PINS - (pin + 1)));
/* Set open drain, if required */
- tmp_val = in_be32(&par_io[port].cpodr);
+ tmp_val = in_be32(&par_io->cpodr);
if (open_drain)
- out_be32(&par_io[port].cpodr, pin_mask1bit | tmp_val);
+ out_be32(&par_io->cpodr, pin_mask1bit | tmp_val);
else
- out_be32(&par_io[port].cpodr, ~pin_mask1bit & tmp_val);
+ out_be32(&par_io->cpodr, ~pin_mask1bit & tmp_val);
/* define direction */
- tmp_val = (pin > (NUM_OF_PINS / 2) - 1) ?
- in_be32(&par_io[port].cpdir2) :
- in_be32(&par_io[port].cpdir1);
+ tmp_val = (pin > (QE_PIO_PINS / 2) - 1) ?
+ in_be32(&par_io->cpdir2) :
+ in_be32(&par_io->cpdir1);
/* get all bits mask for 2 bit per port */
- pin_mask2bits = (u32) (0x3 << (NUM_OF_PINS -
- (pin % (NUM_OF_PINS / 2) + 1) * 2));
+ pin_mask2bits = (u32) (0x3 << (QE_PIO_PINS -
+ (pin % (QE_PIO_PINS / 2) + 1) * 2));
/* Get the final mask we need for the right definition */
- new_mask2bits = (u32) (dir << (NUM_OF_PINS -
- (pin % (NUM_OF_PINS / 2) + 1) * 2));
+ new_mask2bits = (u32) (dir << (QE_PIO_PINS -
+ (pin % (QE_PIO_PINS / 2) + 1) * 2));
/* clear and set 2 bits mask */
- if (pin > (NUM_OF_PINS / 2) - 1) {
- out_be32(&par_io[port].cpdir2,
+ if (pin > (QE_PIO_PINS / 2) - 1) {
+ out_be32(&par_io->cpdir2,
~pin_mask2bits & tmp_val);
tmp_val &= ~pin_mask2bits;
- out_be32(&par_io[port].cpdir2, new_mask2bits | tmp_val);
+ out_be32(&par_io->cpdir2, new_mask2bits | tmp_val);
} else {
- out_be32(&par_io[port].cpdir1,
+ out_be32(&par_io->cpdir1,
~pin_mask2bits & tmp_val);
tmp_val &= ~pin_mask2bits;
- out_be32(&par_io[port].cpdir1, new_mask2bits | tmp_val);
+ out_be32(&par_io->cpdir1, new_mask2bits | tmp_val);
}
/* define pin assignment */
- tmp_val = (pin > (NUM_OF_PINS / 2) - 1) ?
- in_be32(&par_io[port].cppar2) :
- in_be32(&par_io[port].cppar1);
+ tmp_val = (pin > (QE_PIO_PINS / 2) - 1) ?
+ in_be32(&par_io->cppar2) :
+ in_be32(&par_io->cppar1);
- new_mask2bits = (u32) (assignment << (NUM_OF_PINS -
- (pin % (NUM_OF_PINS / 2) + 1) * 2));
+ new_mask2bits = (u32) (assignment << (QE_PIO_PINS -
+ (pin % (QE_PIO_PINS / 2) + 1) * 2));
/* clear and set 2 bits mask */
- if (pin > (NUM_OF_PINS / 2) - 1) {
- out_be32(&par_io[port].cppar2,
+ i
[PATCH 4/6] [POWERPC] QE: implement support for the GPIO LIB API
This is needed to access QE GPIOs via Linux GPIO API.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 37 ---
arch/powerpc/sysdev/qe_lib/Kconfig |8 ++
arch/powerpc/sysdev/qe_lib/Makefile |1 +
arch/powerpc/sysdev/qe_lib/gpio.c| 145 ++
include/asm-powerpc/qe.h |1 +
5 files changed, 179 insertions(+), 13 deletions(-)
create mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 0f3738e..098f456 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1721,24 +1721,35 @@ platforms are moved over to use the
flattened-device-tree model.
information.
Required properties:
- - device_type : should be "par_io".
+ - #gpio-cells : should be "2".
+ - compatible : should be "fsl,-qe-pario-bank",
+ "fsl,mpc8323-qe-pario-bank".
- reg : offset to the register set and its length.
- - num-ports : number of Parallel I/O ports
+ - gpio-controller : node to identify gpio controllers.
- Example:
- [EMAIL PROTECTED] {
- reg = <1400 100>;
- #address-cells = <1>;
- #size-cells = <0>;
- device_type = "par_io";
- num-ports = <7>;
- [EMAIL PROTECTED] {
- ..
- };
+ For example, two QE Par I/O banks:
+ qe_pio_a: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+"fsl,mpc8323-qe-pario-bank";
+ reg = <0x1400 0x18>;
+ gpio-controller;
+ };
+ qe_pio_e: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+"fsl,mpc8323-qe-pario-bank";
+ reg = <0x1460 0x18>;
+ gpio-controller;
+ };
vi) Pin configuration nodes
+ NOTE: pin configuration nodes are obsolete. Usually, their existance
+ is an evidence of the firmware shortcomings. Such fixups are
+ better handled by the Linux board file, not the device tree.
+
Required properties:
- linux,phandle : phandle of this node; likely referenced by a QE
device.
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig
b/arch/powerpc/sysdev/qe_lib/Kconfig
index 76ffbc4..4872fbb 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -24,3 +24,11 @@ config QE_USB
bool
help
QE USB Host Controller support
+
+config QE_GPIO
+ bool "QE GPIO support"
+ select GENERIC_GPIO
+ select HAVE_GPIO_LIB
+ help
+ Say Y here if you're going to use hardware that connects to the
+ QE GPIOs.
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile
b/arch/powerpc/sysdev/qe_lib/Makefile
index e9ff888..f1855c1 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_UCC) += ucc.o
obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
obj-$(CONFIG_UCC_FAST) += ucc_fast.o
obj-$(CONFIG_QE_USB) += usb.o
+obj-$(CONFIG_QE_GPIO) += gpio.o
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c
b/arch/powerpc/sysdev/qe_lib/gpio.c
new file mode 100644
index 000..ae9edea
--- /dev/null
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -0,0 +1,145 @@
+/*
+ * QUICC Engine GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct qe_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u32 cpdata;
+};
+
+static inline struct qe_gpio_chip *
+to_qe_gpio_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct qe_gpio_chip, mm_gc);
+}
+
+static void qe_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+ struct qe_pio_regs __iomem *regs = mm_gc->regs;
+
+ qe_gc->cpdata = in_be32(®s->cpdata);
+}
+
+static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct qe_pio_regs __iomem *regs = mm_gc->regs;
+ u32 pin_mask = 1 << (QE_PIO_PINS - 1 - gpio);
+
+ return !!(in_be32(®s->cpdata) & pin_mask);
+}
+
+static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int v
[PATCH 5/6] [POWERPC] 83xx: new board support: MPC8360E-RDK
This is patch adds board file, device tree, and defconfig for the new
board, made by Freescale Semiconductor Inc. and Logic Product Development.
Currently supported:
1. UEC{1,2,7,4};
2. I2C;
3. SPI;
4. NS16550 serial;
5. PCI and miniPCI;
6. Intel NOR StrataFlash X16 64Mbit PC28F640P30T85;
7. Graphics controller, Fujitsu MB86277.
Not supported in this patch:
1. StMICRO NAND512W3A2BN6E, 512 Mbit (supported with FSL UPM NAND driver);
2. FHCI USB (supported with FHCI driver).
3. QE Serial UCCs (tested to not work with ucc_uart driver, reason
unknown, yet);
4. ADC AD7843 (tested to work, but support via device tree depends on
major SPI rework, GPIO API, etc);
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc836x_rdk.dts | 397 +
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 1090 +++
arch/powerpc/platforms/83xx/Kconfig | 11 +
arch/powerpc/platforms/83xx/Makefile|1 +
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 111 +++
5 files changed, 1610 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc836x_rdk.dts
create mode 100644 arch/powerpc/configs/83xx/mpc836x_rdk_defconfig
create mode 100644 arch/powerpc/platforms/83xx/mpc836x_rdk.c
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts
b/arch/powerpc/boot/dts/mpc836x_rdk.dts
new file mode 100644
index 000..3402d26
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -0,0 +1,397 @@
+/*
+ * MPC8360E RDK Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2007-2008 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * 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/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8360rdk";
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ serial2 = &serial2;
+ serial3 = &serial3;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ ethernet3 = &enet3;
+ pci0 = &pci0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <32768>;
+ i-cache-size = <32768>;
+ /* filled by u-boot */
+ timebase-frequency = <0>;
+ bus-frequency = <0>;
+ clock-frequency = <0>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ /* filled by u-boot */
+ reg = <0 0>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,mpc8360-immr", "fsl,immr", "fsl,soc",
+"simple-bus";
+ ranges = <0 0xe000 0x20>;
+ reg = <0xe000 0x200>;
+ /* filled by u-boot */
+ bus-frequency = <0>;
+
+ [EMAIL PROTECTED] {
+ compatible = "mpc83xx_wdt";
+ reg = <0x200 0x100>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <14 8>;
+ interrupt-parent = <&ipic>;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <16 8>;
+ interrupt-parent = <&ipic>;
+ dfsrr;
+ };
+
+ serial0: [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ interrupts = <9 8>;
+ interrupt-parent = <&ipic>;
+ /* filled by u-boot */
+ clock-frequency = <0>;
+ };
+
[PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
This patch adds few bindings for the new drivers to be submitted through
appropriate maintainers.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 125 ++
1 files changed, 125 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 098f456..0b07bc7 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -59,6 +59,10 @@ Table of Contents
p) Freescale Synchronous Serial Interface
q) USB EHCI controllers
r) Freescale General-purpose Timers Module
+ s) Freescale QUICC Engine USB Controller
+ t) LEDs on GPIOs
+ u) Freescale MCU with MPC8349E-mITX compatible firmware
+ v) NAND on UPM-driven Freescale Localbus
VII - Marvell Discovery mv64[345]6x System Controller chips
1) The /system-controller node
@@ -2869,6 +2873,127 @@ platforms are moved over to use the
flattened-device-tree model.
clock-frequency = <0>;
};
+s) Freescale QUICC Engine USB Controller
+
+Required properties:
+ - compatible : should be "fsl,-qe-usb", "fsl,mpc8323-qe-usb";
+ - reg : the first two cells should contain gtm registers location and
+length, the next two two cells should contain PRAM location and
+length.
+ - interrupts : should contain USB interrupt.
+ - interrupt-parent : interrupt source phandle.
+ - fsl,fullspeed-clock : specifies the full speed USB clock source in
+"clk" or "brg" format.
+ - fsl,lowspeed-clock : specifies the low speed USB clock source in
+"clk" or "brg" format.
+ - fsl,usb-mode : should be "host".
+ - linux,hub-power-budget : optional, USB power budget for the root hub
+in mA.
+ - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
+USBRN, SPEED (optional), and POWER (optional).
+
+Example:
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8360-qe-usb", "fsl,mpc8323-qe-usb";
+ reg = <0x6c0 0x40 0x8b00 0x100>;
+ interrupts = <11>;
+ interrupt-parent = <&qeic>;
+ fsl,fullspeed-clock = "clk21";
+ fsl,usb-mode = "host";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+&qe_pio_b 3 0 /* USBTP */
+&qe_pio_b 8 0 /* USBTN */
+&qe_pio_b 9 0 /* USBRP */
+&qe_pio_b 11 0 /* USBRN */
+&qe_pio_e 20 0 /* SPEED */
+&qe_pio_e 21 0 /* POWER */>;
+ };
+
+t) LEDs on GPIOs
+
+Required properties:
+ - compatible : should be "linux,gpio-led".
+ - linux,name : LED name.
+ - linux,active-low : property should be present if LED wired as
+active-low.
+ - linux,default-trigger : Linux default trigger for this LED.
+ - linux,brightness : default brightness.
+ - gpios : should specify LED GPIO.
+
+Example:
+
+ [EMAIL PROTECTED] {
+ compatible = "linux,gpio-led";
+ linux,name = "pwr";
+ linux,brightness = <1>;
+ linux,active-low;
+ gpios = <&mcu_pio 0>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "linux,gpio-led";
+ linux,name = "hdd";
+ linux,default-trigger = "ide-disk";
+ linux,active-low;
+ gpios = <&mcu_pio 1>;
+ };
+
+u) Freescale MCU with MPC8349E-mITX compatible firmware
+
+Required properties:
+ - compatible : "fsl,-", "fsl,mcu-mpc8349emitx";
+ - reg : should specify I2C address (0x0a).
+ - #address-cells : should be 0.
+ - #size-cells : should be 0.
+ - #gpio-cells : should be 2.
+ - gpio-controller : should be present;
+
+Example:
+
+ mcu_pio: [EMAIL PROTECTED] {
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #gpio-cells = <2>;
+ compatible = "fsl,mc9s08qg8-mpc8349emitx",
+"fsl,mcu-mpc8349emitx";
+ reg = <0x0a>;
+ gpio-controller;
+ };
+
+v) Freescale Localbus UPM programmed to work with NAND flash
+
+ Required properties:
+ - #address-cells : should be 0;
+ - #size-cells : should be 0;
+ - compatible : "fsl,upm-nand".
+ - reg : should specify localbus chip select and size used for the chip.
+ - fsl,upm-addr-offset : UPM pattern offset for the address latch.
+ - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
+ - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
+
+ Example:
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = <0>;
+ #size-cells = <0>;
+ compatible = "fsl,upm-nand";
+
RE: HR timers on PowerPC 83xx
> -Original Message- > From: Sergei Shtylyov [mailto:[EMAIL PROTECTED] > Sent: den 25 april 2008 18:00 > To: [EMAIL PROTECTED] > Cc: 'linuxppc-dev Development' > Subject: Re: HR timers on PowerPC 83xx > > Joakim Tjernlund wrote: > > >>>Trying to understand what is needed to make nanosleep() and friends to > >>>have better resolution than HZ on my 83xx CPU. Is this possible > >>>and what CONFIG options do I need to enable? Kernel is 2.6.25 > > >>Should be possible with CONFIG_HIGH_RES_TIMERS=y. > > > What about NO_HZ? Does that setting change anything? > > It is independent from HRT and selects the mode where the idle process > stops timer HZ interrupts from occuring until it's scheduled off CPU. OK, Thanks One last question, do I need a current glibc to use the new resolution? I got 2.3.6 now Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpiolib support for mpc5200
On Fri, Apr 25, 2008 at 04:30:55PM +0100, Matt Sealey wrote: > Can I make a suggestion for this chip support? > > On certain 5200 boards these devices are not usable since they are not > connected. My concern is the Efika where we only have 2 wakeup and 1 simple > GPIO available on the board and maybe a few others with a bit of tweaking > and messing around. This is probably true for most boards. I haven't tested if this is true for all gpios, but the peripheral usage settings seem to take precedence over the gpio settings. So at least you can play with already for peripheral claimed gpios without bad things happening. But ok, seems to be a bad idea to rely on this. > > Instead of having a block for GPIO which has 32 pins, and the ability to > use all of them just by asking for it (get will return a pin regardless) > I implemented a silly hackish "gpio-mask" property in the efika.forth device > tree so the gpiolib "allocate" style functions can tell if a pin is > actually usable or not. I thought about the same thing, but we have to improve gpiolib first. Currently there is no hook for gpio_request(). > > Can we put some small thought into defining a standard for this, and possibly > moving the "number of gpios in the chip" into the device tree? How does the number of gpios help? the gpio-mask you mentioned above seems to do better. > It doesn't > seem particularly complete to just allow blanket use (which may be unsafe and > may change per-board) of pins just because you can twiddle a bit.. (or use > a pin when another driver may be using it). > > This will tie into Grant's comments about optimizing the enabling of the > GPIO on every direction change etc. (it should be enabled on allocation > and then you have to make sure you free up your use of the pin, resource > tracking in the kernel is important.. flipping bits here and there without > something in the way in the API is kind of clumsy) > > -- > Matt Sealey <[EMAIL PROTECTED]> > Genesi, Manager, Developer Relations > > Grant Likely wrote: >> On Thu, Apr 24, 2008 at 9:36 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote: >>> Hi all, >>> >>> Feel free to comment on this. >>> >>> Sascha >>> >>> >>> This patch adds gpiolib support for mpc5200 SOCs. I'm not sure >>> whether it's a good idea to make this optional via kconfig. >>> The gpt devices only support a single gpio. In the current of_gpio >>> implementation each chip consumes 32 GPIOs which leads to huge >>> gaps. >>> >>> Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]> >> >> Looks pretty good. You've saved me the need to go write a driver >> myself. Comments below, but I'll pull it into my tree and give it a >> spin. >> >> I don't see any mechanism for setting the open drain state of the pin. >> That will either need to be done by platform code or encoded into the >> device tree. Does the OF gpio infrastructure provide any callback to >> the driver when something requests the pin? That would seem to be the >> ideal place to set the open drain state. >> >> You'll also need to document the format of the gpio pin specifier for >> these devices (ie. first cell is GPIO number, second cell is ). >> >> As for the wide spans caused by gpt gpios, it is probably okay for >> now, but we can rework it to do something clever (like have a single >> registration for all gpt gpios) at a later date. >> >> Cheers, >> g. >> >>> --- >>> arch/powerpc/platforms/52xx/Kconfig|6 >>> arch/powerpc/platforms/52xx/Makefile |2 >>> arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 408 >>> + >>> 3 files changed, 416 insertions(+) >>> >>> Index: arch/powerpc/platforms/52xx/mpc52xx_gpio.c >>> === >>> --- /dev/null >>> +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c >>> @@ -0,0 +1,408 @@ >>> +/* >>> + * MPC52xx gpio driver >>> + * >>> + * Copyright (c) 2008 Sascha Hauer <[EMAIL PROTECTED]>, Pengutronix >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License version 2 >>> + * as published by the Free Software Foundation. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + * >>> + * You should have received a copy of the GNU General Public License >>> + * along with this program; if not, write to the Free Software >>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 >>> USA >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +static DEFINE_SPINLOCK(gpio_lock); >>> + >>> +/* >>> + * GPIO LIB API implementation for wakeu
Re: [PATCH] add gpiolib support for mpc5200
On Fri, Apr 25, 2008 at 12:51 PM, Sascha Hauer <[EMAIL PROTECTED]> wrote: > On Fri, Apr 25, 2008 at 04:30:55PM +0100, Matt Sealey wrote: > > Can I make a suggestion for this chip support? > > > > On certain 5200 boards these devices are not usable since they are not > > connected. My concern is the Efika where we only have 2 wakeup and 1 simple > > GPIO available on the board and maybe a few others with a bit of tweaking > > and messing around. > > This is probably true for most boards. > I haven't tested if this is true for all gpios, but the peripheral usage > settings seem to take precedence over the gpio settings. So at least you > can play with already for peripheral claimed gpios without bad things > happening. But ok, seems to be a bad idea to rely on this. There must also be some level of assumption that the device tree data is accurate. If a pin is specified that is not enabled as a GPIO pin, then it's not going to work. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase MDIO timeouts
On Wed, 23 Apr 2008, Benjamin Herrenschmidt wrote: > This patch doubles the MDIO timeouts in EMAC as there are field > cases where they are two short to communicate with some PHYs. I guess them being "two short" is why they needed to be doubled. :-) -Bill ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase MDIO timeouts
On Fri, 2008-04-25 at 16:57 -0400, Bill Fink wrote: > On Wed, 23 Apr 2008, Benjamin Herrenschmidt wrote: > > > This patch doubles the MDIO timeouts in EMAC as there are field > > cases where they are two short to communicate with some PHYs. > > I guess them being "two short" is why they needed to be doubled. :-) Well, in that case, it makes sense, it's still pretty short and better safe than sorry. On day I may look at actually measuring PHYs and see if it's worth trying to do sleeping waits in there. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32
Kumar Gala writes: > Do we think we want to poke Paul to get this in for v2.6.26 so we can > get it some more testing on all the ppc32 systems? It's not going in 2.6.26, since it's a pretty substantial change and it was first seen half-way through the merge window... Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase MDIO timeouts
On Sat, 26 Apr 2008 08:22:38 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-04-25 at 16:57 -0400, Bill Fink wrote: > > On Wed, 23 Apr 2008, Benjamin Herrenschmidt wrote: > > > > > This patch doubles the MDIO timeouts in EMAC as there are field > > > cases where they are two short to communicate with some PHYs. > > > > I guess them being "two short" is why they needed to be doubled. :-) > > Well, in that case, it makes sense, it's still pretty short and better > safe than sorry. On day I may look at actually measuring PHYs and see if > it's worth trying to do sleeping waits in there. I think you missed Bill's joke. Read your original email and spot the typo, then read Bill's pun. And stop emailing before you eat breakfast ;) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Enabling 64 bit data type for dma_addr_t on non PPC64 architecture
Hello, I'm working a new DMA hardware for PPC processors. The processor is a 32 bit architecture having 40 bit physical address space. So we need the 32 bit processor code base but we want the type dma_addr_t to represent 64 bit data, without enabling the CONFIG_PPC64 flag. We want to use the Linux generic DMA layer to offload DMA operations to the hw and the Linux code path goes through function dma_async_memcpy_buf_to_buf and then dma_map_single. Currently the dma_map_single function has 2 versions based upon CONFIG_PPC64 defined or not. Is it possible to reuse the CONFIG_PPC64 based code only pertaining to DMA by doing the following: Add a new flag called CONFIG_DMA64 along with CONFIG_PPC64 and __powerpc64__ flags, enabling our code to use the generic DMA layer with 64 bit data type for dma_addr_t. With the above modification, the function dma_map_single starts returning 64 bit data type instead of 32. Do you have any comments or suggestions ? -thanks TT ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase MDIO timeouts
On Fri, 2008-04-25 at 18:58 -0500, Josh Boyer wrote: > > > I guess them being "two short" is why they needed to be > doubled. :-) > > > > Well, in that case, it makes sense, it's still pretty short and > better > > safe than sorry. On day I may look at actually measuring PHYs and > see if > > it's worth trying to do sleeping waits in there. > > I think you missed Bill's joke. Read your original email and spot the > typo, then read Bill's pun. > > And stop emailing before you eat breakfast ;) Hrm ... yeah allright I missed my initial typo and I missed Bill joke :-) looks like another case of replying while still half asleep ... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Enabling 64 bit data type for dma_addr_t on non PPC64 architecture
On Fri, 2008-04-25 at 19:52 -0700, Tushar Tyagi wrote: > Hello, > I'm working a new DMA hardware for PPC processors. > The processor is a 32 bit architecture having 40 bit physical address > space. > So we need the 32 bit processor code base but we want the type > dma_addr_t to represent 64 bit data, without enabling the CONFIG_PPC64 > flag. That shouldn't be a big issue, we already support 64 bits resources, extending dma_addr_t shouldn't too hard. > We want to use the Linux generic DMA layer to offload DMA operations to > the hw and the Linux code path goes through function > dma_async_memcpy_buf_to_buf and then dma_map_single. > > Currently the dma_map_single function has 2 versions based upon > CONFIG_PPC64 defined or not. > > Is it possible to reuse the CONFIG_PPC64 based code only pertaining to > DMA by doing the following: It's possible, it might be a good idea even as it would allow to have different implementations for different busses, which is in fact needed for some things like 4xx if we start changing the mapping between different PCI bridges vs. SoCs. In fact, I think there's been some patches from Becky Bruce posted in februrary for doing just that, which I totally forgot to review... > Add a new flag called CONFIG_DMA64 along with CONFIG_PPC64 and > __powerpc64__ flags, enabling our code to use the generic DMA layer with > 64 bit data type for dma_addr_t. > > With the above modification, the function dma_map_single starts > returning 64 bit data type instead of 32. > > Do you have any comments or suggestions ? I'd suggest working with Becky on her initial patch and using that as the basis for your stuff. I'll try to give it a good review asap. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: sysfs cpu entry
Kumar Gala wrote: What 32-bit chip are you looking to enable this for? - k I am working on some stuff for the 750GX kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
