* Re: [PATCH 1/2] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
From: Josh Boyer @ 2008-04-12 20:47 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, netdev
In-Reply-To: <48011B70.1020102@garzik.org>
On Sat, 2008-04-12 at 16:28 -0400, Jeff Garzik wrote:
> Josh Boyer wrote:
> > On Fri, 28 Mar 2008 22:18:25 -0400
> > Jeff Garzik <jeff@garzik.org> wrote:
> >
> >> Valentine Barshak wrote:
> >>> The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
> >>> if there's no link. Because of that it fails to find PHY chip. The older ibm_emac
> >>> driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros,
> >>> which toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch
> >>> does the same for "ibm,emac-440gx" compatible chips. The workaround forces
> >>> clock on -all- EMACs, so we select clock under global emac_phy_map_lock.
> >>>
> >>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> >>> ---
> >>> drivers/net/ibm_newemac/core.c | 16 +++++++++++++++-
> >>> drivers/net/ibm_newemac/core.h | 8 ++++++--
> >>> 2 files changed, 21 insertions(+), 3 deletions(-)
> >> is this for 2.6.25-rc?
> >
> > Jeff, can I get an ack from you on this patch, and patch 2 in this
> > set? They depend on a patch in my tree and I'd like to include them in
> > my next push to Paul for 2.6.26.
>
> ACK
Many thanks.
> I had queried the status of these patches, and didn't receive any reply
> initially from my query...
Erm... you did.
http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053737.html
No worries though. I lose email all the time.
josh
^ permalink raw reply
* Re: [PATCH 1/2] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
From: Jeff Garzik @ 2008-04-12 21:13 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev, netdev
In-Reply-To: <1208033230.5869.18.camel@vader.jdub.homelinux.org>
Josh Boyer wrote:
> On Sat, 2008-04-12 at 16:28 -0400, Jeff Garzik wrote:
>> I had queried the status of these patches, and didn't receive any reply
>> initially from my query...
>
> Erm... you did.
>
> http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053737.html
>
> No worries though. I lose email all the time.
Whoops, sorry about that!
Jeff
^ permalink raw reply
* Re: [PATCH 5/5] WDT driver
From: Josh Boyer @ 2008-04-13 0:40 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412141146.3050e521@lappy.seanm.ca>
On Sat, 2008-04-12 at 14:11 -0400, Sean MacLennan wrote:
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
This should be sent to Wim as he maintains the watchdog drivers tree.
josh
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 254d115..e73a3ea 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -697,6 +697,14 @@ config BOOKE_WDT
> Please see Documentation/watchdog/watchdog-api.txt for
> more information.
>
> +config PIKA_WDT
> + tristate "PIKA FPGA Watchdog"
> + depends on WARP
> + default y
> + help
> + This enables the watchdog in the PIKA FPGA. Currently used on
> + the Warp platform.
> +
> # PPC64 Architecture
>
> config WATCHDOG_RTAS
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f3fb170..09758c5 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -105,6 +105,7 @@ obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
> obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
> obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
> obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
> +obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
>
> # PPC64 Architecture
> obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
> diff --git a/drivers/watchdog/pika_wdt.c b/drivers/watchdog/pika_wdt.c
> new file mode 100644
> index 0000000..b84ac07
> --- /dev/null
> +++ b/drivers/watchdog/pika_wdt.c
> @@ -0,0 +1,113 @@
> +/*
> + * PIKA FPGA based Watchdog Timer
> + *
> + * Copyright (c) 2008 PIKA Technologies
> + * Sean MacLennan <smaclennan at pikatech.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/fs.h>
> +#include <linux/miscdevice.h>
> +#include <linux/reboot.h>
> +#include <linux/uaccess.h>
> +#include <linux/io.h>
> +#include <linux/of_platform.h>
> +#include <linux/watchdog.h>
> +
> +
> +static void __iomem *pikawdt_fpga;
> +
> +
> +static inline void pikawdt_ping(void)
> +{
> + unsigned reset = in_be32(pikawdt_fpga + 0x14);
> + reset |= 0xf80; /* enable with max timeout - 15 seconds */
> + out_be32(pikawdt_fpga + 0x14, reset);
> +}
> +
> +static int pikawdt_open(struct inode *inode, struct file *file)
> +{
> + printk(KERN_INFO "PIKA WDT started...\n");
> +
> + pikawdt_ping();
> +
> + return 0;
> +}
> +
> +static int pikawdt_release(struct inode *inode, struct file *file)
> +{
> + pikawdt_ping(); /* one last time */
> + return 0;
> +}
> +
> +static ssize_t pikawdt_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + pikawdt_ping();
> + return count;
> +}
> +
> +/* We support the bare minimum to be conformant. */
> +static int pikawdt_ioctl(struct inode *inode, struct file *file,
> + unsigned int cmd, unsigned long arg)
> +{
> + if (cmd == WDIOC_KEEPALIVE) {
> + pikawdt_ping();
> + return 0;
> + } else
> + return -EINVAL;
> +}
> +
> +static const struct file_operations pikawdt_fops = {
> + .owner = THIS_MODULE,
> + .open = pikawdt_open,
> + .release = pikawdt_release,
> + .write = pikawdt_write,
> + .ioctl = pikawdt_ioctl,
> +};
> +
> +static struct miscdevice pikawdt_miscdev = {
> + .minor = WATCHDOG_MINOR,
> + .name = "watchdog",
> + .fops = &pikawdt_fops,
> +};
> +
> +static int __init pikawdt_init(void)
> +{
> + struct device_node *np;
> + int ret;
> +
> + np = of_find_compatible_node(NULL, NULL, "pika,fpga");
> + if (np == NULL) {
> + printk(KERN_ERR "pikawdt: Unable to find fpga.\n");
> + return -ENOENT;
> + }
> +
> + pikawdt_fpga = of_iomap(np, 0);
> +
> + of_node_put(np);
> +
> + if (pikawdt_fpga == NULL) {
> + printk(KERN_ERR "pikawdt: Unable to map fpga.\n");
> + return -ENOENT;
> + }
> +
> + ret = misc_register(&pikawdt_miscdev);
> + if (ret) {
> + iounmap(pikawdt_fpga);
> + printk(KERN_ERR "pikawdt: Unable to register miscdev.\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +module_init(pikawdt_init);
> +
> +
> +static void __exit pikawdt_exit(void)
> +{
> + misc_deregister(&pikawdt_miscdev);
> +
> + iounmap(pikawdt_fpga);
> +}
> +module_exit(pikawdt_exit);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 4/5] LED driver
From: Josh Boyer @ 2008-04-13 0:41 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412141039.25e14fae@lappy.seanm.ca>
On Sat, 2008-04-12 at 14:10 -0400, Sean MacLennan wrote:
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
This should be sent to Richard Purdie.
josh
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 859814f..31e1746 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -145,6 +145,12 @@ config LEDS_CLEVO_MAIL
> To compile this driver as a module, choose M here: the
> module will be called leds-clevo-mail.
>
> +config LEDS_WARP
> + tristate "LED Support for the PIKA Warp LEDs"
> + depends on LEDS_CLASS && WARP
> + help
> + This option enables support for the PIKA Warp LEDs.
> +
> comment "LED Triggers"
>
> config LEDS_TRIGGERS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 84ced3b..eb60fb1 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
> obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
> obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
> obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
> +obj-$(CONFIG_LEDS_WARP) += leds-warp.o
>
> # LED Triggers
> obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
> diff --git a/drivers/leds/leds-warp.c b/drivers/leds/leds-warp.c
> new file mode 100644
> index 0000000..0fbe0b7
> --- /dev/null
> +++ b/drivers/leds/leds-warp.c
> @@ -0,0 +1,148 @@
> +/*
> + * Copyright (c) 2008 PIKA Technologies
> + * Sean MacLennan <smaclennan at pikatech.com>
> + *
> + * This is just a temporary driver until the GPIO/GPIO_OF_LEDS drivers
> + * get sorted out.
> + */
> +#include <linux/module.h>
> +#include <linux/leds.h>
> +#include <linux/of_platform.h>
> +#include <asm/machdep.h>
> +
> +
> +#define LED_GREEN (0x80000000 >> 0)
> +#define LED_RED (0x80000000 >> 1)
> +
> +static void __iomem *gpio_base;
> +
> +
> +static void warp_green_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
> +{
> + unsigned leds = in_be32(gpio_base);
> +
> + if (brightness)
> + leds |= LED_GREEN;
> + else
> + leds &= ~LED_GREEN;
> +
> + out_be32(gpio_base, leds);
> +}
> +
> +static void warp_red_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
> +{
> + unsigned leds = in_be32(gpio_base);
> +
> + if (brightness)
> + leds |= LED_RED;
> + else
> + leds &= ~LED_RED;
> +
> + out_be32(gpio_base, leds);
> +}
> +
> +static struct led_classdev warp_green_led = {
> + .name = "warp-green",
> + .brightness_set = warp_green_set,
> +};
> +
> +static struct led_classdev warp_red_led = {
> + .name = "warp-red",
> + .brightness_set = warp_red_set,
> +};
> +
> +static int __devinit warp_led_probe(struct platform_device *pdev)
> +{
> + struct device_node *np;
> + int rc;
> +
> + /* Power LEDS are on the second GPIO controller */
> + np = of_find_compatible_node(NULL, NULL, "ibm,gpio-440EP");
> + if (np)
> + np = of_find_compatible_node(np, NULL, "ibm,gpio-440EP");
> + if (np == NULL) {
> + printk(KERN_ERR __FILE__ ": Unable to find gpio\n");
> + return -ENOENT;
> + }
> +
> + gpio_base = of_iomap(np, 0);
> + of_node_put(np);
> + if (gpio_base == NULL) {
> + printk(KERN_ERR __FILE__ ": Unable to map gpio");
> + return -ENOMEM;
> + }
> +
> + rc = led_classdev_register(&pdev->dev, &warp_green_led);
> + if (rc) {
> + iounmap(gpio_base);
> + return rc;
> + }
> +
> + rc = led_classdev_register(&pdev->dev, &warp_red_led);
> + if (rc) {
> + led_classdev_unregister(&warp_green_led);
> + iounmap(gpio_base);
> + return rc;
> + }
> +
> + return 0;
> +}
> +
> +static int __devexit warp_led_remove(struct platform_device *pdev)
> +{
> + led_classdev_unregister(&warp_green_led);
> + led_classdev_unregister(&warp_red_led);
> +
> + iounmap(gpio_base);
> +
> + return 0;
> +}
> +
> +/* We *must* have a release. */
> +static void warp_led_release(struct device *dev) {}
> +
> +static struct platform_driver warp_led_driver = {
> + .probe = warp_led_probe,
> + .remove = __devexit_p(warp_led_remove),
> + .driver = {
> + .name = "warp-led",
> + },
> +};
> +
> +static struct platform_device warp_led_device = {
> + .name = "warp-led",
> + .id = 0,
> + .dev = {
> + .release = warp_led_release,
> + },
> +};
> +
> +static int __init warp_led_init(void)
> +{
> + int rc;
> +
> + rc = platform_device_register(&warp_led_device);
> + if (rc)
> + return rc;
> + rc = platform_driver_register(&warp_led_driver);
> + if (rc) {
> + platform_device_unregister(&warp_led_device);
> + return rc;
> + }
> +
> + return 0;
> +}
> +
> +static void __exit warp_led_exit(void)
> +{
> + platform_driver_unregister(&warp_led_driver);
> + platform_device_unregister(&warp_led_device);
> +}
> +
> +module_init(warp_led_init);
> +module_exit(warp_led_exit);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Sean MacLennan <smaclennan@pikatech.com>");
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Stephen Rothwell @ 2008-04-13 0:44 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412134831.424480cf@lappy.seanm.ca>
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
Hi Sean,
First comment is that you need reasonable changelogs i.e. explain why you
are making changes as well as what they do. Also the first line of each
changelog (which becomes the subject of any mail generated from git)
should be a useful and relatively unique summary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] Boot code
From: Josh Boyer @ 2008-04-13 0:49 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412140140.6c75cee5@lappy.seanm.ca>
On Sat, 2008-04-12 at 14:01 -0400, Sean MacLennan wrote:
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
>
This patch is word wrapped.
> diff --git a/arch/powerpc/boot/cuboot-warp.c
> b/arch/powerpc/boot/cuboot-warp.c index eb108a8..43d7ad9 100644
> --- a/arch/powerpc/boot/cuboot-warp.c
> +++ b/arch/powerpc/boot/cuboot-warp.c
> @@ -10,6 +10,7 @@
> #include "ops.h"
> #include "4xx.h"
> #include "cuboot.h"
> +#include "stdio.h"
>
> #define TARGET_4xx
> #define TARGET_44x
> @@ -17,14 +18,54 @@
>
> static bd_t bd;
>
> -static void warp_fixups(void)
> +static void warp_fixup_one_nor(u32 from, u32 to)
> {
> - unsigned long sysclk = 66000000;
> + void *devp;
> + char name[40];
> + u32 v[2];
> +
> + sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x", from);
Unless I can't count (which could very well be the case), you have a
buffer overflow here. The fixed string is 37 characters, and the values
you are passing in for "from" will extend the string past the 40 bytes
you have allocated for "name".
josh
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Josh Boyer @ 2008-04-13 0:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Sean MacLennan, linuxppc-dev
In-Reply-To: <20080413104430.c98244d2.sfr@canb.auug.org.au>
On Sun, 2008-04-13 at 10:44 +1000, Stephen Rothwell wrote:
> Hi Sean,
>
> First comment is that you need reasonable changelogs i.e. explain why you
> are making changes as well as what they do. Also the first line of each
> changelog (which becomes the subject of any mail generated from git)
> should be a useful and relatively unique summary.
Yes, what Stephen said.
josh
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Paul Mackerras @ 2008-04-13 1:11 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412134831.424480cf@lappy.seanm.ca>
Sean MacLennan writes:
> I was going to hold off until the warp was officially released, but we
> might miss the merge window. So here they are. A lot of work has been
> done since 2.6.25 and I haven't been submitting patches to keep down on
> the churn.
<cracked record>
Your patches don't have any description at all. If they are to go in
they need a decent description of what they do and why they do it they
way they do. Putting stuff in a patch 0/5 doesn't really help since
that doesn't go into the git repository.
</cracked record>
Paul.
^ permalink raw reply
* Re: [PATCH] tg3: fix MMIO for PPC 44x platforms
From: David Miller @ 2008-04-13 1:31 UTC (permalink / raw)
To: sshtylyov; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <200804122101.22438.sshtylyov@ru.mvista.com>
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Sat, 12 Apr 2008 21:01:22 +0400
> The driver stores the PCI resource addresses into 'unsigned long' variable
> before calling ioremap_nocache() on them. This warrants kernel oops when the
> registers are accessed on PPC 44x platforms which (being 32-bit) have PCI
> memory space mapped beyond 4 GB.
>
> The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion that
> the PCI memory resource is mapped below 4 GB, but arch/powerpc/ code got rid
> of this trick, having instead CONFIG_RESOURCES_64BIT enabled.
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Applied, thanks.
I added a bump of the driver version and release date for
the changeset.
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Sean MacLennan @ 2008-04-13 1:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080413104430.c98244d2.sfr@canb.auug.org.au>
On Sun, 13 Apr 2008 10:44:30 +1000
"Stephen Rothwell" <sfr@canb.auug.org.au> wrote:
> Hi Sean,
>
> First comment is that you need reasonable changelogs i.e. explain why
> you are making changes as well as what they do. Also the first line
> of each changelog (which becomes the subject of any mail generated
> from git) should be a useful and relatively unique summary.
>
These patches are an amalgamation of a lot of commits. For
example, warp.c was changed 15 times since I last sent a patch to
linuxppc-dev. warp-nand.c was probably changed even more as we kept
shifting the design.
One of the advantages of an FPGA based design is you can work around a
lot of hardware problems. A disadvantage is that it is easy to change,
so it changes a lot. And the HW guys push the specs out to after they
actually get the feature going. There is no SW input into the FPGA
design.
So these patches are basically following the changes to the FPGA and
changes to the hardware. As new functionality was added, I updated the
code.
Is there a particular way I should word this to make it a changelog?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 1/5] Boot code
From: Sean MacLennan @ 2008-04-13 2:06 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev
In-Reply-To: <1208047783.5869.35.camel@vader.jdub.homelinux.org>
On Sat, 12 Apr 2008 19:49:43 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Sat, 2008-04-12 at 14:01 -0400, Sean MacLennan wrote:
> > Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> >
>
> This patch is word wrapped.
Yes, sorry about that. I have been trying out a new mail client and I
pasted the text wrong :( I caught it in the other patches though,
so they should be good.
> > + char name[40];
> > + u32 v[2];
> > +
> > + sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x",
> > from);
>
> Unless I can't count (which could very well be the case), you have a
> buffer overflow here. The fixed string is 37 characters, and the
> values you are passing in for "from" will extend the string past the
> 40 bytes you have allocated for "name".
No, you are right. Good catch. I will update that.
Cheers,
Sean
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Grant Likely @ 2008-04-13 2:09 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20080412215544.38fa2d0b@lappy.seanm.ca>
On Sat, Apr 12, 2008 at 7:55 PM, Sean MacLennan <seanm@seanm.ca> wrote:
> On Sun, 13 Apr 2008 10:44:30 +1000
> "Stephen Rothwell" <sfr@canb.auug.org.au> wrote:
>
> > Hi Sean,
> >
> > First comment is that you need reasonable changelogs i.e. explain why
> > you are making changes as well as what they do. Also the first line
> > of each changelog (which becomes the subject of any mail generated
> > from git) should be a useful and relatively unique summary.
> >
>
> These patches are an amalgamation of a lot of commits. For
> example, warp.c was changed 15 times since I last sent a patch to
> linuxppc-dev. warp-nand.c was probably changed even more as we kept
> shifting the design.
>
> One of the advantages of an FPGA based design is you can work around a
> lot of hardware problems. A disadvantage is that it is easy to change,
> so it changes a lot. And the HW guys push the specs out to after they
> actually get the feature going. There is no SW input into the FPGA
> design.
>
> So these patches are basically following the changes to the FPGA and
> changes to the hardware. As new functionality was added, I updated the
> code.
>
> Is there a particular way I should word this to make it a changelog?
You can still describe what the code changes; either by itemizing all
the changes; or if it now appears to be a whole new thing, but
describing what it does /now/. :-)
A changelog of "updates a bunch of stuff" is pretty much irrelevant in
all situations I can think of.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Josh Boyer @ 2008-04-13 2:24 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412134831.424480cf@lappy.seanm.ca>
On Sat, 2008-04-12 at 13:48 -0400, Sean MacLennan wrote:
> I was going to hold off until the warp was officially released, but we
> might miss the merge window. So here they are. A lot of work has been
> done since 2.6.25 and I haven't been submitting patches to keep down on
> the churn.
That's fair enough. And from what I can tell, your patches are fairly
localized to your platform. So once they get some initial review and
fixing, I don't foresee having too much trouble getting them merged.
One thing to keep in mind though, is that the closer we get to the merge
window, the tighter I get on what new stuff I'll bring in for the next
release. This may seem counter-intuitive, but I like to have the merge
window really be for testing out and fixing any issues that pop up
during the merge of all the various subsystem trees. You'll also want
to add in some lead time for patch review, etc.
That's a long winded way of saying "release early, release often" I
suppose :).
josh
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Sean MacLennan @ 2008-04-13 2:38 UTC (permalink / raw)
To: Grant Likely; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <fa686aa40804121909s4ee04731ua63afa76fe088828@mail.gmail.com>
> A changelog of "updates a bunch of stuff" is pretty much irrelevant in
> all situations I can think of.
Ok, I hope I got everything:
Changes to match new FPGA/HW functionality.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Moved/resized partitions to match the flash changes.
* Fixup code added for Rev A boards to handle flash changes.
* Added DTM critical temperature.
* Added DTM fan error - currently disable in FPGA.
* Added POST information.
* Removed LED function, moved to new LED driver.
* Moved ad7414 to new style I2C initialization.
Cheers,
Sean
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Dale Farnsworth @ 2008-04-13 3:13 UTC (permalink / raw)
To: seanm; +Cc: linuxppc-dev
In-Reply-To: <20080412223833.27ca5f23@lappy.seanm.ca>
In article <20080412223833.27ca5f23@lappy.seanm.ca> you write:
>
> > A changelog of "updates a bunch of stuff" is pretty much irrelevant in
> > all situations I can think of.
>
> Ok, I hope I got everything:
>
> Changes to match new FPGA/HW functionality.
> * Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
> * Moved/resized partitions to match the flash changes.
> * Fixup code added for Rev A boards to handle flash changes.
> * Added DTM critical temperature.
> * Added DTM fan error - currently disable in FPGA.
> * Added POST information.
> * Removed LED function, moved to new LED driver.
> * Moved ad7414 to new style I2C initialization.
Each patch needs to be standalone. you need to add a header describing
what the patch is intended to accomplish. Being more descriptive is
better than less. Also, as Stephen said, make sure that the subject
of each email containing a patch is descriptive and reasonably unique
within the entire kernel. For example, instead of "WDT driver", as a
minimum something like: "[POWERPC] warp: Add WDT driver".
-Dale
^ permalink raw reply
* Re: PATCH 2/5] Platform code
From: Sean MacLennan @ 2008-04-13 3:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080412140325.69e1df3b@lappy.seanm.ca>
Here is the complete warp.c. It is probably easier to read this then
the patch.
Cheers,
Sean
/*
* PIKA Warp(tm) board specific routines
*
* Copyright (c) 2008 PIKA Technologies
* Sean MacLennan <smaclennan at pikatech.com>
*
* 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 <linux/init.h>
#include <linux/of_platform.h>
#include <linux/kthread.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/pika.h>
#include <asm/machdep.h>
#include <asm/prom.h>
#include <asm/udbg.h>
#include <asm/time.h>
#include <asm/uic.h>
#include "44x.h"
static __initdata struct of_device_id warp_of_bus[] = {
{ .compatible = "ibm,plb4", },
{ .compatible = "ibm,opb", },
{ .compatible = "ibm,ebc", },
{},
};
static __initdata struct i2c_board_info warp_i2c_info[] = {
{ I2C_BOARD_INFO("ad7414", 0x4a) }
};
static int __init warp_arch_init(void)
{
/* This should go away once support is moved to the dts. */
i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
return 0;
}
machine_arch_initcall(warp, warp_arch_init);
static int __init warp_device_probe(void)
{
of_platform_bus_probe(NULL, warp_of_bus, NULL);
return 0;
}
machine_device_initcall(warp, warp_device_probe);
static int __init warp_probe(void)
{
unsigned long root = of_get_flat_dt_root();
return of_flat_dt_is_compatible(root, "pika,warp");
}
define_machine(warp) {
.name = "Warp",
.probe = warp_probe,
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
.restart = ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
/* I am not sure this is the best place for this... */
static int __init warp_post_info(void)
{
struct device_node *np;
void __iomem *fpga;
u32 post1, post2;
/* Sighhhh... POST information is in the sd area. */
np = of_find_compatible_node(NULL, NULL, "pika,fpga-sd");
if (np == NULL)
return -ENOENT;
fpga = of_iomap(np, 0);
of_node_put(np);
if (fpga == NULL)
return -ENOENT;
post1 = in_be32(fpga + 0x40);
post2 = in_be32(fpga + 0x44);
iounmap(fpga);
if (post1 || post2)
printk(KERN_INFO "Warp POST %08x %08x\n", post1, post2);
else
printk(KERN_INFO "Warp POST OK\n");
return 0;
}
machine_late_initcall(warp, warp_post_info);
#ifdef CONFIG_SENSORS_AD7414
static LIST_HEAD(dtm_shutdown_list);
static void __iomem *dtm_fpga;
struct dtm_shutdown {
struct list_head list;
void (*func)(void *arg);
void *arg;
};
int dtm_register_shutdown(void (*func)(void *arg), void *arg)
{
struct dtm_shutdown *shutdown;
shutdown = kmalloc(sizeof(struct dtm_shutdown), GFP_KERNEL);
if (shutdown == NULL)
return -ENOMEM;
shutdown->func = func;
shutdown->arg = arg;
list_add(&shutdown->list, &dtm_shutdown_list);
return 0;
}
EXPORT_SYMBOL(dtm_register_shutdown);
int dtm_unregister_shutdown(void (*func)(void *arg), void *arg)
{
struct dtm_shutdown *shutdown;
list_for_each_entry(shutdown, &dtm_shutdown_list, list)
if (shutdown->func == func && shutdown->arg == arg) {
list_del(&shutdown->list);
kfree(shutdown);
return 0;
}
return -EINVAL;
}
EXPORT_SYMBOL(dtm_unregister_shutdown);
static long wdt_keepalive(long time)
{
if (dtm_fpga) {
unsigned reset = in_be32(dtm_fpga + 0x14);
out_be32(dtm_fpga + 0x14, reset);
}
return 0;
}
static irqreturn_t temp_isr(int irq, void *context)
{
struct dtm_shutdown *shutdown;
/* Run through the shutdown list. */
list_for_each_entry(shutdown, &dtm_shutdown_list, list)
shutdown->func(shutdown->arg);
panic_timeout = 1800;
panic_blink = wdt_keepalive;
panic("Critical Temperature Shutdown");
return IRQ_HANDLED;
}
static void pika_setup_critical_temp(struct i2c_client *client)
{
struct device_node *np;
int irq, rc;
/* These registers are in 1 degree increments. */
i2c_smbus_write_byte_data(client, 2, 55); /* Thigh */
i2c_smbus_write_byte_data(client, 3, 50); /* Tlow */
np = of_find_compatible_node(NULL, NULL, "adi,ad7414");
if (np == NULL) {
printk(KERN_ERR __FILE__ ": Unable to find ad7414\n");
return;
}
irq = irq_of_parse_and_map(np, 0);
of_node_put(np);
if (irq == NO_IRQ) {
printk(KERN_ERR __FILE__ ": Unable to get ad7414 irq\n");
return;
}
rc = request_irq(irq, temp_isr, 0, "ad7414", NULL);
if (rc) {
printk(KERN_ERR __FILE__
": Unable to request ad7414 irq %d = %d\n", irq, rc);
return;
}
}
static inline void pika_dtm_check_fan(void __iomem *fpga)
{
static int fan_state;
u32 fan = in_be32(fpga + 0x34) & (1 << 14);
if (fan_state != fan) {
fan_state = fan;
if (fan)
printk(KERN_WARNING "Fan rotation error detected."
" Please check hardware.\n");
}
}
static int pika_dtm_thread(void __iomem *fpga)
{
struct i2c_adapter *adap;
struct i2c_client *client;
/* We loop in case either driver was compiled as a module and
* has not been insmoded yet.
*/
while (!(adap = i2c_get_adapter(0))) {
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
}
while (1) {
list_for_each_entry(client, &adap->clients, list)
if (client->addr == 0x4a)
goto found_it;
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
}
found_it:
i2c_put_adapter(adap);
pika_setup_critical_temp(client);
printk(KERN_INFO "PIKA DTM thread running.\n");
while (!kthread_should_stop()) {
u16 temp = swab16(i2c_smbus_read_word_data(client, 0));
out_be32(fpga + 0x20, temp);
pika_dtm_check_fan(fpga);
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
}
return 0;
}
static int __init pika_dtm_start(void)
{
struct task_struct *dtm_thread;
struct device_node *np;
np = of_find_compatible_node(NULL, NULL, "pika,fpga");
if (np == NULL)
return -ENOENT;
dtm_fpga = of_iomap(np, 0);
of_node_put(np);
if (dtm_fpga == NULL)
return -ENOENT;
dtm_thread = kthread_run(pika_dtm_thread, dtm_fpga, "pika-dtm");
if (IS_ERR(dtm_thread)) {
iounmap(dtm_fpga);
return PTR_ERR(dtm_thread);
}
return 0;
}
machine_late_initcall(warp, pika_dtm_start);
#endif
^ permalink raw reply
* Re: [PATCH 4/5] LED driver
From: Peter Korsgaard @ 2008-04-13 12:28 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412141039.25e14fae@lappy.seanm.ca>
>>>>> "Sean" == Sean MacLennan <smaclennan@pikatech.com> writes:
Hi,
Sean> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
Sean> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
Sean> index 859814f..31e1746 100644
Sean> --- a/drivers/leds/Kconfig
Sean> +++ b/drivers/leds/Kconfig
Sean> @@ -145,6 +145,12 @@ config LEDS_CLEVO_MAIL
Sean> To compile this driver as a module, choose M here: the
Sean> module will be called leds-clevo-mail.
Sean> +config LEDS_WARP
Sean> + tristate "LED Support for the PIKA Warp LEDs"
Sean> + depends on LEDS_CLASS && WARP
Sean> + help
Sean> + This option enables support for the PIKA Warp LEDs.
Sean> +
Sean> comment "LED Triggers"
How about getting gpiolib working and use leds-gpio.c instead?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [LMB][1/2] Fix some whitespace and other formatting issues, use pr_debug
From: Paul Mackerras @ 2008-04-13 12:31 UTC (permalink / raw)
To: Nick Andrew; +Cc: linuxppc-dev, linux-kernel, davem
In-Reply-To: <20080412162940.GB29599@tull.net>
Nick Andrew writes:
> On Sat, Apr 12, 2008 at 03:20:59PM +1000, Paul Mackerras wrote:
> > + pr_debug("\n reserved.cnt = 0x%lx\n", lmb.reserved.cnt);
>
> This will only output an empty line at KERN_DEBUG level and the rest
> will be at default_message_loglevel. Problem is fixed my my patch in msg
> <20080412161733.24882.30930.stgit@marcab.local.tull.net>
>
> However, is a blank line in the log necessary?
No, and in fact the whole routine is probably not necessary any more.
Paul.
^ permalink raw reply
* Re: [PATCH 1/8] [POWERPC] fsl_elbc_nand: factor out localbus defines
From: David Woodhouse @ 2008-04-13 12:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev@ozlabs.org list, linux-mtd
In-Reply-To: <C55A03A1-DDB4-4652-9758-2E78E38343B4@kernel.crashing.org>
On Fri, 2008-04-11 at 09:06 -0500, Kumar Gala wrote:
>
> David, can you ack this. It looks good to me but want a MTD
> maintainer ack before having it go through the powerpc tree.
Looks sane to me.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--
dwmw2
^ permalink raw reply
* Re: [PATCH 4/5] LED driver
From: Sean MacLennan @ 2008-04-13 16:51 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87r6daym53.fsf@macbook.be.48ers.dk>
On Sun, 13 Apr 2008 14:28:24 +0200
Peter Korsgaard <jacmet@sunsite.dk> wrote:
> How about getting gpiolib working and use leds-gpio.c instead?
Actually, I was going to just ask about that... how close is leds-gpio
to being working, and will it be in 2.6.26?
Cheers,
Sean
^ permalink raw reply
* [EFIKA] Really, don't pretend to be CHRP
From: David Woodhouse @ 2008-04-13 16:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Fedora 9 works on Efika without the separate 'device-tree supplement',
thanks to the kernel's own fixups. With one exception -- because 'CHRP'
still appears on the 'machine:' line in /proc/cpuinfo, the installer
misdetects the platform and misconfigures yaboot, putting it into a PReP
boot partition instead of in the /boot filesystem where the Efika's
firmware could find it.
The kernel's fixups for Efika already correct one instance of 'chrp', in
the 'device_type' property. This fixes it in the 'CODEGEN,description'
property too, since that's what's exposed to userspace in /proc/cpuinfo.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 5ab4c84..723422e 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2240,6 +2240,14 @@ static void __init fixup_device_tree_efika(void)
if (rv != PROM_ERROR && (strcmp(prop, "chrp") == 0))
prom_setprop(node, "/", "device_type", "efika", sizeof("efika"));
+ /* CODEGEN,description is exposed in /proc/cpuinfo so
+ fix that too */
+ rv = prom_getprop(node, "CODEGEN,description", prop, sizeof(prop));
+ if (rv != PROM_ERROR && (strstr(prop, "CHRP")))
+ prom_setprop(node, "/", "CODEGEN,description",
+ "Efika 5200B PowerPC System",
+ sizeof("Efika 5200B PowerPC System"));
+
/* Fixup bestcomm interrupts property */
node = call_prom("finddevice", 1, 1, ADDR("/builtin/bestcomm"));
if (PHANDLE_VALID(node)) {
--
dwmw2
^ permalink raw reply related
* Re: [PATCH 4/5] LED driver
From: Peter Korsgaard @ 2008-04-13 17:34 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080413125119.6bb54a29@lappy.seanm.ca>
>>>>> "Sean" == Sean MacLennan <smaclennan@pikatech.com> writes:
>> How about getting gpiolib working and use leds-gpio.c instead?
Sean> Actually, I was going to just ask about that... how close is leds-gpio
Sean> to being working, and will it be in 2.6.26?
I haven't actually used leds-gpio, but it looks so simple that I
cannot imagine it not working. There also seems to be quite some
platforms using it, E.G:
% git grep '"leds-gpio"' arch|wc -l
11
Or are you referring to the status of gpiolib support on powerpc?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 4/5] LED driver
From: Sean MacLennan @ 2008-04-13 17:51 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87hce5zmj5.fsf@macbook.be.48ers.dk>
On Sun, 13 Apr 2008 19:34:38 +0200
Peter Korsgaard <jacmet@sunsite.dk> wrote:
> I haven't actually used leds-gpio, but it looks so simple that I
> cannot imagine it not working. There also seems to be quite some
> platforms using it, E.G:
>
> % git grep '"leds-gpio"' arch|wc -l
> 11
>
> Or are you referring to the status of gpiolib support on powerpc?
Correct. It looks like the gpiolib will go in for 2.6.26 but not ppc44x
support. Which means I wouldn't be able to get warp support in for this
release.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
From: Andrew Morton @ 2008-04-14 0:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, linux-m32r, takata, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <20080410032354.90CB1DDF0F@ozlabs.org>
On Thu, 10 Apr 2008 13:22:56 +1000 Benjamin Herrenschmidt <benh@ozlabs.org> wrote:
> Some architecture need to maintain a kmem cache for thread info
> structures. (next patch adds that to powerpc to fix an alignment
> problem).
>
> There is no good arch callback to use to initialize that cache
> that I can find, so this adds a new one and adds an empty macro
> for when it's not implemented.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> So we have the choice here between:
>
> - the ifdef on the func name that I did, consistent with what
> I did before for iomap, which iirc Linus liked
>
> - add some more ARCH_HAS_* or HAVE_* (yuck)
>
> - add an empty definition to all archs .h (pain in the neck but I
> can do it, though it will be an annoying patch to keep around)
>
> - do a weak function (will slightly bloat everybody for no good reason)
>
> So unless there is strong complaints, I'd like to stick to my
> current approach.
>
> include/linux/sched.h | 4 ++++
> init/main.c | 1 +
> 2 files changed, 5 insertions(+)
>
> --- linux-work.orig/init/main.c 2008-04-10 13:11:06.000000000 +1000
> +++ linux-work/init/main.c 2008-04-10 13:11:19.000000000 +1000
> @@ -623,6 +623,7 @@ asmlinkage void __init start_kernel(void
> if (efi_enabled)
> efi_enter_virtual_mode();
> #endif
> + thread_info_cache_init();
> fork_init(num_physpages);
> proc_caches_init();
> buffer_init();
> Index: linux-work/include/linux/sched.h
> ===================================================================
> --- linux-work.orig/include/linux/sched.h 2008-04-10 13:11:44.000000000 +1000
> +++ linux-work/include/linux/sched.h 2008-04-10 13:12:05.000000000 +1000
> @@ -1893,6 +1893,10 @@ static inline unsigned long *end_of_stac
>
> #endif
>
> +#ifndef thread_info_cache_init
> +#define thread_info_cache_init do { } while(0)
> +#endif
This trick does cause a bit of a problem: it is undefined which arch header
file is to provide the alternative definition of thread_info_cache_init.
So we can (and have) ended up in the situation where the override appears
in different files on different architectures and various screwups ensue.
So I'd suggest that we have a bigfatcomment telling implementors which file
the override should be implemented in. And make sure that this arch file is
directly included from within sched.h.
I have a suspicion that we can still get in a mess if .c files include the
per-arch file and don't include sched.h, but I forget where this happened
and why it broke stuff.
Sigh. A nice, coded-in-C implementation within each and every architecture
remains the best implementation, and all the little tricks-to-save-typing
have failure modes.
otoh, if only one .c file will ever call this function then I think that
all problems are solved by
a) moving the above ifdeffery into the .c file
b) adding a comment explaining which arch file must provide the override
c) directly including that file from within the .c file.
^ permalink raw reply
* Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
From: Benjamin Herrenschmidt @ 2008-04-14 0:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux-Arch, linux-m32r, takata, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <20080413171953.bde5e9ac.akpm@linux-foundation.org>
> > +#ifndef thread_info_cache_init
> > +#define thread_info_cache_init do { } while(0)
> > +#endif
>
> This trick does cause a bit of a problem: it is undefined which arch header
> file is to provide the alternative definition of thread_info_cache_init.
I this case it's well defined: thread_info.h. Maybe I should add a
comment ?
> So we can (and have) ended up in the situation where the override appears
> in different files on different architectures and various screwups ensue.
Yup.
> So I'd suggest that we have a bigfatcomment telling implementors which file
> the override should be implemented in. And make sure that this arch file is
> directly included from within sched.h.
Will do.
> I have a suspicion that we can still get in a mess if .c files include the
> per-arch file and don't include sched.h, but I forget where this happened
> and why it broke stuff.
In this case, there's only one call site and will only every be one, so
that shouldn't be a problem. I don't see init/main.c not including
sched.h
> Sigh. A nice, coded-in-C implementation within each and every architecture
> remains the best implementation, and all the little tricks-to-save-typing
> have failure modes.
Well, I started doing it in all arch, and people around here told me
that was not a good idea , that it would be trouble if the prototype
ever had to change (adding an arg, etc... though very unlikely to happen
in that case, granted).
> otoh, if only one .c file will ever call this function then I think that
> all problems are solved by
>
> a) moving the above ifdeffery into the .c file
> b) adding a comment explaining which arch file must provide the override
> c) directly including that file from within the .c file.
I can definitely do that. I have no problem either way. I can add to all
archs too, it's just that whatever way I choose, some people won't be
happy with it :-)
Anyway, I'll move the ifdeferry to init/main.c then.
Cheers,
Ben.
^ 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