* Re: GPIO drivers, other patches?
From: Anton Vorontsov @ 2008-07-15 16:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <AB4393B8-8578-4AFA-B23A-048F86A9A24D@kernel.crashing.org>
On Tue, Jul 15, 2008 at 10:10:21AM -0500, Kumar Gala wrote:
> Anton,
>
> I think I've gotten most of the patches from you,
Yes, much thanks!
> but I know there are
> few I've lost. Can you just repost any patches that aren't in my
> powerpc-next tree.
Only this minor patch is missing:
[PATCH v3] powerpc/83xx: update mpc83xx_defconfig to support MPC8360E-RDK
http://patchwork.ozlabs.org/linuxppc/patch?id=18903
There are also last two patches I need to rework a bit (to be in
compliance with latest power management work done by Scott Wood):
[PATCH 1/2] [POWERPC] 86xx: suspend support
http://patchwork.ozlabs.org/linuxppc/patch?id=18836
[PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add wakeup-on-sw9 support
http://patchwork.ozlabs.org/linuxppc/patch?id=18837
I'll resubmit them today or tomorrow. (Though, I'll appreciate if you
will look into these two, maybe you'll have any comments I can fix
before resubmitting).
Thanks again,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: 82xx performance
From: Milton Miller @ 2008-07-15 15:57 UTC (permalink / raw)
To: Rune Torgersen; +Cc: ppcdev, Arnd Bergmann
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04AE61BC@ismail.innsys.innovsys.com>
On Tue Jul 15 02:34:03 EST 2008, Rune Togersen wrote:
> We are looking into switching kernels from 2.6.18 (ppc) to 2.6.25
> (powerpc).
> I have been trying to run some benchmarks to see how the new kernel
> compares to the old one.
>
> So far it is performing worse.
>
> One test I ran was just compiling a 2.6.18 kernel on the system.
> The .25 performed 5 to 7 % slower:
>
> 2.6.18, make vmlinux
> real 74m1.328s
> user 68m48.196s
> sys 4m35.961s
>
> 2.6.25, make vmlinux
> real 79m13.361s
> user 72m41.318s
> sys 5m46.744s
>
> I also ran lmbench3. (slightly outdated, but still works)
> Most (if not all) results are worse on .25, especially context
> switching.
>
> Is this expected behaviour or is there anything I need to look at in my
> config?
> (I'll send config if anybody is interested)
>
>
> L M B E N C H 3 . 0 S U M M A R Y
> ------------------------------------
> (Alpha software, do not distribute)
>
> Basic system parameters
> -----------------------------------------------------------------------
> -
> ------
> Host OS Description Mhz tlb cache mem
> scal
> pages line par
> load
> bytes
> --------- ------------- ----------------------- ---- ----- -----
> ------ ----
> 9919_unit Linux 2.6.25 powerpc-linux-gnu 434 32 32
> 1.0000 1
> 9919_unit Linux 2.6.18 powerpc-linux-gnu 445 32 32
> 1.0100 1
Hmm, processor MHz is off by 11/445
>
> Processor, Processes - times in microseconds - smaller is better
> -----------------------------------------------------------------------
> - ------
> Host OS Mhz null null open slct sig sig fork
> exec sh
> call I/O stat clos TCP inst hndl proc
> proc proc
> --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ----
> ---- ----
> 9919_unit Linux 2.6.25 434 0.47 1.26 10.7 35.6 34.1 1.76 14.3 2646
> 9964 33.K
> 9919_unit Linux 2.6.18 445 0.35 1.24 9.27 22.9 32.7 1.87 13.8 2157
> 7825 26.K
>
> Basic integer operations - times in nanoseconds - smaller is better
> -------------------------------------------------------------------
> Host OS intgr intgr intgr intgr intgr
> bit add mul div mod
> --------- ------------- ------ ------ ------ ------ ------
> 9919_unit Linux 2.6.25 2.3300 0.0100 10.7 46.2 56.0
> 9919_unit Linux 2.6.18 2.2300 0.0100 10.3 45.4 54.1
>
> Basic float operations - times in nanoseconds - smaller is better
> -----------------------------------------------------------------
> Host OS float float float float
> add mul div bogo
> --------- ------------- ------ ------ ------ ------
> 9919_unit Linux 2.6.25 9.9500 10.1 46.2 66.2
> 9919_unit Linux 2.6.18 9.1100 9.0800 45.8 67.1
>
> Basic double operations - times in nanoseconds - smaller is better
> ------------------------------------------------------------------
> Host OS double double double double
> add mul div bogo
> --------- ------------- ------ ------ ------ ------
> 9919_unit Linux 2.6.25 9.3400 11.6 78.6 100.2
> 9919_unit Linux 2.6.18 9.1600 11.1 77.2 97.8
>
Integer and float operations are also off ...
> Context switching - times in microseconds - smaller is better
> -----------------------------------------------------------------------
> -
> -
> Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K
> 16p/64K
> ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
> --------- ------------- ------ ------ ------ ------ ------ -------
> -------
> 9919_unit Linux 2.6.25 20.6 86.2 28.5 103.8 38.7 111.8 57.4
> 9919_unit Linux 2.6.18 5.3300 63.2 17.9 73.4 23.1 74.9 26.2
>
> *Local* Communication latencies in microseconds - smaller is better
> ---------------------------------------------------------------------
> Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
> ctxsw UNIX UDP TCP conn
> --------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
> 9919_unit Linux 2.6.25 20.6 68.8 131. 353.1 533.4 461.7 1269
> 9919_unit Linux 2.6.18 5.330 36.1 87.8 225.3 402.7 331.8 520.1 970.
>
> File & VM system latencies in microseconds - smaller is better
> -----------------------------------------------------------------------
> --------
> Host OS 0K File 10K File Mmap Prot Page
> 100fd
> Create Delete Create Delete Latency Fault
> Fault
> selct
> --------- ------------- ------ ------ ------ ------ ------- -----
> ------- -----
> 9919_unit Linux 2.6.25 222.3 172.4 1003.0 350.5 41.5K 1.734
> 10.5 18.0
> 9919_unit Linux 2.6.18 181.5 144.3 789.3 293.9 23.9K 7.09560
> 19.3
>
> *Local* Communication bandwidths in MB/s - bigger is better
> -----------------------------------------------------------------------
> ------
> Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem
> Mem
> UNIX reread reread (libc) (hand) read
> write
> --------- ------------- ---- ---- ---- ------ ------ ------ ------
> ---- -----
> 9919_unit Linux 2.6.25 34.2 34.7 21.5 55.5 161.8 79.9 79.2
> 160. 116.1
> 9919_unit Linux 2.6.18 40.1 37.4 29.7 60.0 165.8 80.6 81.1
> 165. 117.8
>
> Memory latencies in nanoseconds - smaller is better
> (WARNING - may not be correct, check graphs)
> -----------------------------------------------------------------------
> -------
> Host OS Mhz L1 $ L2 $ Main mem Rand mem
> Guesses
> --------- ------------- --- ---- ---- -------- --------
> -------
> 9919_unit Linux 2.6.25 434 4.8150 174.6 183.3 511.8 No
> L2 cache?
> 9919_unit Linux 2.6.18 445 4.6880 174.1 175.4 497.5 No
> L2 cache?
And memory latency is off 13/500.
That sounds like it will be 16/666.
Are you using the same board and the same firmware?
If so, look at /proc/cpuinfo and/or the boot log to see what
frequency linux thinks the processor is running at. It sounds
like someone introduced or fixed a rounding error error calculating
the timebase frequency for your board.
Please try the sleep test: sleep for 100 seconds, and time with
either a stopwatch or another system. I think you will find they
take different amounts of time, and all the results need to be scaled.
You might be able to see it reading the hardware clock.
Actually, once you track that down, rerun and see what you find.
milton
^ permalink raw reply
* Re: [PATCH] of: i2c: improve last resort compatible entry selection
From: Jean Delvare @ 2008-07-15 15:39 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <487CB991.9000301@scram.de>
On Tue, 15 Jul 2008 16:52:01 +0200, Jochen Friedrich wrote:
> Hi Jean,
>
> > Eeeek. The patch you mention here is only the conversion of ONE driver.
> > It is absolutely not relevant as to what the general rule is.
>
> Sorry, i must have misunderstood you then.
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=af294867a52bf718df835a688e8c786d550bee26#patch9
> is the same, my original patch listed all four supported chips in there
> (saa7126, saa7127, saa7128 and saa7129) while only one made it into the driver...
As I recall, your patch was done quickly and without knowledge of the
chips in question. I did mine in close collaboration with Hans Verkuil
who knows these chips very well, to make sure I wouldn't break
anything. With success, as far as I can tell.
Honestly, I can't remember why we decided to have a single chip name
for all 4 variants. It might have been a shortcut to complete the
conversion in time. Or, more likely, I didn't notice the other types
because the driver was originally using the same name "saa7127" for all
devices. If that is the case I'll update the driver to behave more in
compliance with the new i2c device/driver matching scheme. I'll discuss
this with Hans to make sure it's OK.
So, again, please don't take this (nor any other) media driver
conversion patch as an example of what should be done. The proper
conversion of all media drivers will take a lot of time because of the
history behind these drivers.
--
Jean Delvare
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: David Hubbard @ 2008-07-15 15:31 UTC (permalink / raw)
To: Jean Delvare
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Hans de Goede
In-Reply-To: <20080715103613.4fbbf01f@hyperion.delvare>
Hi Jean,
On Tue, Jul 15, 2008 at 2:36 AM, Jean Delvare <khali@linux-fr.org> wrote:
>> Is there any way to use lspci and start at the LPC bridge, then find
>> the SuperIO chip's IO address? What about ACPI tables? Perhaps probing
>> logic could look for an LPC bridge before probing certain IO addresses
>> even if the addresses are not in the LPC bridge config.
>
> I always assumed that there was no way to know in advance if a
> Super-I/O (LPC) chip was present or not, let alone the exact model of
> the chip. The I/O addresses are decoded by the Super-I/O chip itself,
> and in general it has no relation to PCI. And I've never seen ports
> 0x2e/0x2f nor 0x4e/0x4f listed in /proc/ioports.
>
> But of course if there is a way to know, we should use it. Avoiding
> random access to I/O ports, even if they are relatively standard in
> this case, is always good.
I looked at my lspci output and did a little researching, and I think
the only thing we can deduce is that there is an LPC bridge, so
looking for a SuperIO is a good idea. If there is no LPC bridge
listed, I can't say whether probing the ports is a good idea or not.
David
^ permalink raw reply
* Re: 2.6.26 does not boot on Pegasos
From: Matt Sealey @ 2008-07-15 15:27 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev list
In-Reply-To: <20080715100033.GA5147@iram.es>
If you built this kernel yourself, you need to do it from a system with
an up-to-date binutils (2.18) otherwise, it does this.
If you got it from somewhere (like a distribution) then please tell us
where, as there are some other troubles with load-base location for
Fedora and so on...
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Gabriel Paubert wrote:
> Hi,
>
> I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot.
> The last message I have is:
> gunzip (0xffffffff <----- some more hex digits)
>
> The configuration has been created from a working 2.6.25 one with
> make oldconfig and answering N to new config options.
>
> Anybody has seen this or do I have to start digging deeper?
>
> Regards,
> Gabriel
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-15 15:19 UTC (permalink / raw)
To: Richard Purdie; +Cc: linuxppc-dev, Stephen Rothwell, linux-kernel
In-Reply-To: <1216133032.5345.73.camel@dax.rpnet.com>
Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
is not much code can be shared between the two drivers (both are mostly
driver bindings anyway).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
- dropped Documentation/powerpc/ changes, since Kumar applied them via
powerpc tree.
- renamed leds-of-gpio to leds-openfirmware-gpio
drivers/leds/Kconfig | 8 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-openfirmware-gpio.c | 194 +++++++++++++++++++++++++++++++++
3 files changed, 203 insertions(+), 0 deletions(-)
create mode 100644 drivers/leds/leds-openfirmware-gpio.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1c35dfa..a645e8d 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -119,6 +119,14 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_OPENFIRMWARE_GPIO
+ tristate "OpenFirmware bindings for GPIO connected LEDs"
+ depends on LEDS_CLASS && OF_GPIO
+ help
+ This option enables support for the LEDs connected to GPIO
+ outputs. To be useful the particular board must have LEDs
+ and they must be connected to the GPIO lines.
+
config LEDS_CM_X270
tristate "LED Support for the CM-X270 LEDs"
depends on LEDS_CLASS && MACH_ARMCORE
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 7156f99..0258ab7 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
+obj-$(CONFIG_LEDS_OPENFIRMWARE_GPIO) += leds-openfirmware-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
diff --git a/drivers/leds/leds-openfirmware-gpio.c b/drivers/leds/leds-openfirmware-gpio.c
new file mode 100644
index 0000000..ce2c3cd
--- /dev/null
+++ b/drivers/leds/leds-openfirmware-gpio.c
@@ -0,0 +1,194 @@
+/*
+ * OpenFirmware bindings for GPIO connected LEDs
+ *
+ * Copyright (C) 2007 8D Technologies inc.
+ * Raphael Assenat <raph@8d.com>
+ * Copyright (C) 2008 MontaVista Software, Inc.
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/of_platform.h>
+#include <linux/leds.h>
+#include <linux/workqueue.h>
+#include <asm/prom.h>
+
+struct of_gpio_led {
+ struct device_node *np;
+ struct led_classdev cdev;
+ unsigned int gpio;
+ struct work_struct work;
+ u8 new_level;
+ u8 can_sleep;
+};
+
+static void gpio_led_work(struct work_struct *work)
+{
+ struct of_gpio_led *led = container_of(work, struct of_gpio_led, work);
+
+ gpio_set_value_cansleep(led->gpio, led->new_level);
+}
+
+static void gpio_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ struct of_gpio_led *led = container_of(led_cdev, struct of_gpio_led,
+ cdev);
+ int level;
+
+ if (value == LED_OFF)
+ level = 0;
+ else
+ level = 1;
+
+ /* Setting GPIOs with I2C/etc requires a task context, and we don't
+ * seem to have a reliable way to know if we're already in one; so
+ * let's just assume the worst.
+ */
+ if (led->can_sleep) {
+ led->new_level = level;
+ schedule_work(&led->work);
+ } else {
+ gpio_set_value(led->gpio, level);
+ }
+}
+
+static int __devinit of_gpio_leds_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct of_gpio_led *led;
+ struct device_node *np = ofdev->node;
+
+ led = kzalloc(sizeof(*led), GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ led->np = of_node_get(np);
+
+ ret = of_get_gpio(np, 0);
+ if (!gpio_is_valid(ret)) {
+ dev_err(&ofdev->dev, "gpio is invalid\n");
+ goto err_get_gpio;
+ }
+ led->gpio = ret;
+ led->can_sleep = gpio_cansleep(led->gpio);
+
+ led->cdev.name = of_get_property(np, "label", NULL);
+ if (!led->cdev.name)
+ led->cdev.name = dev_name(&ofdev->dev);
+ led->cdev.brightness_set = gpio_led_set;
+
+ ret = gpio_request(led->gpio, dev_name(&ofdev->dev));
+ if (ret < 0) {
+ dev_err(&ofdev->dev, "could not request gpio, status is %d\n",
+ ret);
+ goto err_gpio;
+ }
+
+ ret = gpio_direction_output(led->gpio, 0);
+ if (ret) {
+ dev_err(&ofdev->dev, "gpio could not be an output, "
+ "status is %d\n", ret);
+ goto err_gpio;
+ }
+
+ INIT_WORK(&led->work, gpio_led_work);
+ dev_set_drvdata(&ofdev->dev, led);
+
+ ret = led_classdev_register(&ofdev->dev, &led->cdev);
+ if (ret < 0) {
+ dev_err(&ofdev->dev, "could register led cdev, status is %d\n",
+ ret);
+ gpio_free(led->gpio);
+ goto err_reg_cdev;
+ }
+
+ return 0;
+
+err_reg_cdev:
+ cancel_work_sync(&led->work);
+err_gpio:
+ gpio_free(led->gpio);
+err_get_gpio:
+ of_node_put(led->np);
+ kfree(led);
+ return ret;
+}
+
+static int __devexit of_gpio_leds_remove(struct of_device *ofdev)
+{
+ struct of_gpio_led *led = dev_get_drvdata(&ofdev->dev);
+
+ led_classdev_unregister(&led->cdev);
+ cancel_work_sync(&led->work);
+ gpio_free(led->gpio);
+ of_node_put(led->np);
+ kfree(led);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int of_gpio_led_suspend(struct of_device *ofdev, pm_message_t state)
+{
+ struct of_gpio_led *led = dev_get_drvdata(&ofdev->dev);
+
+ led_classdev_suspend(&led->cdev);
+ return 0;
+}
+
+static int of_gpio_led_resume(struct of_device *ofdev)
+{
+ struct of_gpio_led *led = dev_get_drvdata(&ofdev->dev);
+
+ led_classdev_resume(&led->cdev);
+ return 0;
+}
+#else
+#define of_gpio_led_suspend NULL
+#define of_gpio_led_resume NULL
+#endif /* CONFIG_PM */
+
+static const struct of_device_id of_gpio_leds_match[] = {
+ { .compatible = "gpio-led", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_gpio_leds_match);
+
+static struct of_platform_driver of_gpio_leds_driver = {
+ .driver = {
+ .name = "of_gpio_leds",
+ .owner = THIS_MODULE,
+ },
+ .match_table = of_gpio_leds_match,
+ .probe = of_gpio_leds_probe,
+ .remove = __devexit_p(of_gpio_leds_remove),
+ .suspend = of_gpio_led_suspend,
+ .resume = of_gpio_led_resume,
+};
+
+static int __init of_gpio_leds_init(void)
+{
+ return of_register_platform_driver(&of_gpio_leds_driver);
+}
+module_init(of_gpio_leds_init);
+
+static void __exit of_gpio_leds_exit(void)
+{
+ of_unregister_platform_driver(&of_gpio_leds_driver);
+}
+module_exit(of_gpio_leds_exit);
+
+MODULE_DESCRIPTION("OpenFirmware bindings for GPIO connected LEDs");
+MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
+MODULE_LICENSE("GPL");
--
1.5.5.4
^ permalink raw reply related
* Re: [Cbe-oss-dev] [patch 2/2] cell: add support for power button of future IBM cell blades
From: Arnd Bergmann @ 2008-07-15 15:18 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: krafft, lohausen, willeke, linuxppc-dev
In-Reply-To: <20080715162755.453c9b52@de.ibm.com>
On Tuesday 15 July 2008, krafft@de.ibm.com wrote:
> From: Christian Krafft <krafft@de.ibm.com>
>
> This patch adds support for the power button on future IBM cell blades.
> It actually doesn't shut down the machine. Instead it exposes an
> input device /dev/input/event0 to userspace which sends KEY_POWER
> if power button has been pressed.
> haldaemon actually recognizes the button, so a plattform independent acpid
> replacement should handle it correctly.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
>
Thanks, applied.
Note: this patch is line-wrapped, but I'll fix it up for you one more time ;-)
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 1/2] cell: cleanup sysreset_hack for IBM cell blades
From: Arnd Bergmann @ 2008-07-15 15:17 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: krafft, lohausen, willeke, linuxppc-dev
In-Reply-To: <20080715162757.75f06cf5@de.ibm.com>
On Tuesday 15 July 2008, krafft@de.ibm.com wrote:
> From: Christian Krafft <krafft@de.ibm.com>
>
> This patch adds a config option for the sysreset_hack used for
> IBM Cell blades. The code is moves from pervasive.c into ras.c and
> gets it's own init method.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
>
thanks, applied
^ permalink raw reply
* GPIO drivers, other patches?
From: Kumar Gala @ 2008-07-15 15:10 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev list
Anton,
I think I've gotten most of the patches from you, but I know there are
few I've lost. Can you just repost any patches that aren't in my
powerpc-next tree.
- k
^ permalink raw reply
* Re: [PATCH] of: i2c: improve last resort compatible entry selection
From: Jochen Friedrich @ 2008-07-15 14:52 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev
In-Reply-To: <20080715160510.0f57dd0e@hyperion.delvare>
Hi Jean,
> Eeeek. The patch you mention here is only the conversion of ONE driver.
> It is absolutely not relevant as to what the general rule is.
Sorry, i must have misunderstood you then.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=af294867a52bf718df835a688e8c786d550bee26#patch9
is the same, my original patch listed all four supported chips in there
(saa7126, saa7127, saa7128 and saa7129) while only one made it into the driver...
> Jochen, I am very surprised that you dare drawing conclusions based on
> one random patch of mine. And I am unhappy that you even claim that I
> took some decision when I definitely did not.
Maybe I draw wrong conclusions from the discussion with Jon Smirl then.
> I can't comment on the specific issue at hand as I am not familiar with
> it, but overall Jon appears to be right. Listing individual chips in
> id_table is the standard way to go. That's even the very reason why we
> decided to add this id_table to i2c_driver, instead of matching on the
> driver name as we were doing before.
I definitely agree here.
Thanks,
Jochen
^ permalink raw reply
* [PATCH 4/4] powerpc: Convert the MPIC MSI code to use msi_bitmap
From: Michael Ellerman @ 2008-07-15 14:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johannsson, linuxppc-dev, Kumar Gala, Jason.jin
In-Reply-To: <378edcf6ad114d35166364c5df03a8c422f757a1.1216133084.git.michael@ellerman.id.au>
This effects the U3 MSI code as well as the PASEMI MSI code. We keep
some of the MPIC routines as helpers, and also the U3 best-guess
reservation logic. The rest is replaced by the generic code.
And a few printk format changes due to hwirq type change.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/sysdev/mpic.h | 2 -
arch/powerpc/sysdev/mpic_msi.c | 123 +++++----------------------------
arch/powerpc/sysdev/mpic_pasemi_msi.c | 24 ++++---
arch/powerpc/sysdev/mpic_u3msi.c | 22 +++---
include/asm-powerpc/mpic.h | 4 +-
5 files changed, 44 insertions(+), 131 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.h b/arch/powerpc/sysdev/mpic.h
index fbf8a26..6209c62 100644
--- a/arch/powerpc/sysdev/mpic.h
+++ b/arch/powerpc/sysdev/mpic.h
@@ -14,8 +14,6 @@
#ifdef CONFIG_PCI_MSI
extern void mpic_msi_reserve_hwirq(struct mpic *mpic, irq_hw_number_t hwirq);
extern int mpic_msi_init_allocator(struct mpic *mpic);
-extern irq_hw_number_t mpic_msi_alloc_hwirqs(struct mpic *mpic, int num);
-extern void mpic_msi_free_hwirqs(struct mpic *mpic, int offset, int num);
extern int mpic_u3msi_init(struct mpic *mpic);
extern int mpic_pasemi_msi_init(struct mpic *mpic);
#else
diff --git a/arch/powerpc/sysdev/mpic_msi.c b/arch/powerpc/sysdev/mpic_msi.c
index de3e5e8..1d44eee 100644
--- a/arch/powerpc/sysdev/mpic_msi.c
+++ b/arch/powerpc/sysdev/mpic_msi.c
@@ -15,59 +15,17 @@
#include <asm/prom.h>
#include <asm/hw_irq.h>
#include <asm/ppc-pci.h>
+#include <asm/msi_bitmap.h>
#include <sysdev/mpic.h>
-static void __mpic_msi_reserve_hwirq(struct mpic *mpic, irq_hw_number_t hwirq)
-{
- pr_debug("mpic: reserving hwirq 0x%lx\n", hwirq);
- bitmap_allocate_region(mpic->hwirq_bitmap, hwirq, 0);
-}
-
void mpic_msi_reserve_hwirq(struct mpic *mpic, irq_hw_number_t hwirq)
{
- unsigned long flags;
-
/* The mpic calls this even when there is no allocator setup */
- if (!mpic->hwirq_bitmap)
+ if (!mpic->msi_bitmap.bitmap)
return;
- spin_lock_irqsave(&mpic->bitmap_lock, flags);
- __mpic_msi_reserve_hwirq(mpic, hwirq);
- spin_unlock_irqrestore(&mpic->bitmap_lock, flags);
-}
-
-irq_hw_number_t mpic_msi_alloc_hwirqs(struct mpic *mpic, int num)
-{
- unsigned long flags;
- int offset, order = get_count_order(num);
-
- spin_lock_irqsave(&mpic->bitmap_lock, flags);
- /*
- * This is fast, but stricter than we need. We might want to add
- * a fallback routine which does a linear search with no alignment.
- */
- offset = bitmap_find_free_region(mpic->hwirq_bitmap, mpic->irq_count,
- order);
- spin_unlock_irqrestore(&mpic->bitmap_lock, flags);
-
- pr_debug("mpic: allocated 0x%x (2^%d) at offset 0x%x\n",
- num, order, offset);
-
- return offset;
-}
-
-void mpic_msi_free_hwirqs(struct mpic *mpic, int offset, int num)
-{
- unsigned long flags;
- int order = get_count_order(num);
-
- pr_debug("mpic: freeing 0x%x (2^%d) at offset 0x%x\n",
- num, order, offset);
-
- spin_lock_irqsave(&mpic->bitmap_lock, flags);
- bitmap_release_region(mpic->hwirq_bitmap, offset, order);
- spin_unlock_irqrestore(&mpic->bitmap_lock, flags);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, hwirq);
}
#ifdef CONFIG_MPIC_U3_HT_IRQS
@@ -83,13 +41,13 @@ static int mpic_msi_reserve_u3_hwirqs(struct mpic *mpic)
/* Reserve source numbers we know are reserved in the HW */
for (i = 0; i < 8; i++)
- __mpic_msi_reserve_hwirq(mpic, i);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, i);
for (i = 42; i < 46; i++)
- __mpic_msi_reserve_hwirq(mpic, i);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, i);
for (i = 100; i < 105; i++)
- __mpic_msi_reserve_hwirq(mpic, i);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, i);
np = NULL;
while ((np = of_find_all_nodes(np))) {
@@ -99,7 +57,7 @@ static int mpic_msi_reserve_u3_hwirqs(struct mpic *mpic)
while (of_irq_map_one(np, index++, &oirq) == 0) {
ops->xlate(mpic->irqhost, NULL, oirq.specifier,
oirq.size, &hwirq, &flags);
- __mpic_msi_reserve_hwirq(mpic, hwirq);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, hwirq);
}
}
@@ -112,70 +70,25 @@ static int mpic_msi_reserve_u3_hwirqs(struct mpic *mpic)
}
#endif
-static int mpic_msi_reserve_dt_hwirqs(struct mpic *mpic)
-{
- int i, len;
- const u32 *p;
-
- p = of_get_property(mpic->irqhost->of_node,
- "msi-available-ranges", &len);
- if (!p) {
- pr_debug("mpic: no msi-available-ranges property found on %s\n",
- mpic->irqhost->of_node->full_name);
- return -ENODEV;
- }
-
- if (len % 8 != 0) {
- printk(KERN_WARNING "mpic: Malformed msi-available-ranges "
- "property on %s\n", mpic->irqhost->of_node->full_name);
- return -EINVAL;
- }
-
- bitmap_allocate_region(mpic->hwirq_bitmap, 0,
- get_count_order(mpic->irq_count));
-
- /* Format is: (<u32 start> <u32 count>)+ */
- len /= sizeof(u32);
- for (i = 0; i < len / 2; i++, p += 2)
- mpic_msi_free_hwirqs(mpic, *p, *(p + 1));
-
- return 0;
-}
-
int mpic_msi_init_allocator(struct mpic *mpic)
{
- int rc, size;
-
- BUG_ON(mpic->hwirq_bitmap);
- spin_lock_init(&mpic->bitmap_lock);
+ int rc;
- size = BITS_TO_LONGS(mpic->irq_count) * sizeof(long);
- pr_debug("mpic: allocator bitmap size is 0x%x bytes\n", size);
+ rc = msi_bitmap_alloc(&mpic->msi_bitmap, mpic->irq_count,
+ mpic->irqhost->of_node);
+ if (rc)
+ return rc;
- mpic->hwirq_bitmap = alloc_maybe_bootmem(size, GFP_KERNEL);
-
- if (!mpic->hwirq_bitmap) {
- pr_debug("mpic: ENOMEM allocating allocator bitmap!\n");
- return -ENOMEM;
- }
-
- memset(mpic->hwirq_bitmap, 0, size);
-
- rc = mpic_msi_reserve_dt_hwirqs(mpic);
- if (rc) {
+ rc = msi_bitmap_reserve_dt_hwirqs(&mpic->msi_bitmap);
+ if (rc > 0) {
if (mpic->flags & MPIC_U3_HT_IRQS)
rc = mpic_msi_reserve_u3_hwirqs(mpic);
- if (rc)
- goto out_free;
+ if (rc) {
+ msi_bitmap_free(&mpic->msi_bitmap);
+ return rc;
+ }
}
return 0;
-
- out_free:
- if (mem_init_done)
- kfree(mpic->hwirq_bitmap);
-
- mpic->hwirq_bitmap = NULL;
- return rc;
}
diff --git a/arch/powerpc/sysdev/mpic_pasemi_msi.c b/arch/powerpc/sysdev/mpic_pasemi_msi.c
index 68aff60..656cb77 100644
--- a/arch/powerpc/sysdev/mpic_pasemi_msi.c
+++ b/arch/powerpc/sysdev/mpic_pasemi_msi.c
@@ -22,6 +22,7 @@
#include <asm/prom.h>
#include <asm/hw_irq.h>
#include <asm/ppc-pci.h>
+#include <asm/msi_bitmap.h>
#include "mpic.h"
@@ -81,8 +82,8 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
continue;
set_irq_msi(entry->irq, NULL);
- mpic_msi_free_hwirqs(msi_mpic, virq_to_hw(entry->irq),
- ALLOC_CHUNK);
+ msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap,
+ virq_to_hw(entry->irq), ALLOC_CHUNK);
irq_dispose_mapping(entry->irq);
}
@@ -91,11 +92,10 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
static int pasemi_msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
- irq_hw_number_t hwirq;
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
- int ret;
+ int hwirq;
pr_debug("pasemi_msi_setup_msi_irqs, pdev %p nvec %d type %d\n",
pdev, nvec, type);
@@ -109,17 +109,19 @@ static int pasemi_msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
* few MSIs for someone, but restrictions will apply to how the
* sources can be changed independently.
*/
- ret = mpic_msi_alloc_hwirqs(msi_mpic, ALLOC_CHUNK);
- hwirq = ret;
- if (ret < 0) {
+ hwirq = msi_bitmap_alloc_hwirqs(&msi_mpic->msi_bitmap,
+ ALLOC_CHUNK);
+ if (hwirq < 0) {
pr_debug("pasemi_msi: failed allocating hwirq\n");
return hwirq;
}
virq = irq_create_mapping(msi_mpic->irqhost, hwirq);
if (virq == NO_IRQ) {
- pr_debug("pasemi_msi: failed mapping hwirq 0x%lx\n", hwirq);
- mpic_msi_free_hwirqs(msi_mpic, hwirq, ALLOC_CHUNK);
+ pr_debug("pasemi_msi: failed mapping hwirq 0x%x\n",
+ hwirq);
+ msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap, hwirq,
+ ALLOC_CHUNK);
return -ENOSPC;
}
@@ -133,8 +135,8 @@ static int pasemi_msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
set_irq_chip(virq, &mpic_pasemi_msi_chip);
set_irq_type(virq, IRQ_TYPE_EDGE_RISING);
- pr_debug("pasemi_msi: allocated virq 0x%x (hw 0x%lx) addr 0x%x\n",
- virq, hwirq, msg.address_lo);
+ pr_debug("pasemi_msi: allocated virq 0x%x (hw 0x%x) " \
+ "addr 0x%x\n", virq, hwirq, msg.address_lo);
/* Likewise, the device writes [0...511] into the target
* register to generate MSI [512...1023]
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 6e2f868..0a8f5a9 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -16,6 +16,7 @@
#include <asm/prom.h>
#include <asm/hw_irq.h>
#include <asm/ppc-pci.h>
+#include <asm/msi_bitmap.h>
#include "mpic.h"
@@ -101,7 +102,8 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
continue;
set_irq_msi(entry->irq, NULL);
- mpic_msi_free_hwirqs(msi_mpic, virq_to_hw(entry->irq), 1);
+ msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap,
+ virq_to_hw(entry->irq), 1);
irq_dispose_mapping(entry->irq);
}
@@ -110,29 +112,27 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
static int u3msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
- irq_hw_number_t hwirq;
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
u64 addr;
- int ret;
+ int hwirq;
addr = find_ht_magic_addr(pdev);
msg.address_lo = addr & 0xFFFFFFFF;
msg.address_hi = addr >> 32;
list_for_each_entry(entry, &pdev->msi_list, list) {
- ret = mpic_msi_alloc_hwirqs(msi_mpic, 1);
- if (ret < 0) {
+ hwirq = msi_bitmap_alloc_hwirqs(&msi_mpic->msi_bitmap, 1);
+ if (hwirq < 0) {
pr_debug("u3msi: failed allocating hwirq\n");
- return ret;
+ return hwirq;
}
- hwirq = ret;
virq = irq_create_mapping(msi_mpic->irqhost, hwirq);
if (virq == NO_IRQ) {
- pr_debug("u3msi: failed mapping hwirq 0x%lx\n", hwirq);
- mpic_msi_free_hwirqs(msi_mpic, hwirq, 1);
+ pr_debug("u3msi: failed mapping hwirq 0x%x\n", hwirq);
+ msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap, hwirq, 1);
return -ENOSPC;
}
@@ -140,8 +140,8 @@ static int u3msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
set_irq_chip(virq, &mpic_u3msi_chip);
set_irq_type(virq, IRQ_TYPE_EDGE_RISING);
- pr_debug("u3msi: allocated virq 0x%x (hw 0x%lx) addr 0x%lx\n",
- virq, hwirq, addr);
+ pr_debug("u3msi: allocated virq 0x%x (hw 0x%x) addr 0x%lx\n",
+ virq, hwirq, (unsigned long)addr);
msg.data = hwirq;
write_msi_msg(virq, &msg);
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index fe566a3..34d9ac4 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -5,6 +5,7 @@
#include <linux/irq.h>
#include <linux/sysdev.h>
#include <asm/dcr.h>
+#include <asm/msi_bitmap.h>
/*
* Global registers
@@ -301,8 +302,7 @@ struct mpic
#endif
#ifdef CONFIG_PCI_MSI
- spinlock_t bitmap_lock;
- unsigned long *hwirq_bitmap;
+ struct msi_bitmap msi_bitmap;
#endif
#ifdef CONFIG_MPIC_BROKEN_REGREAD
--
1.5.5
^ permalink raw reply related
* [PATCH 3/4] powerpc: Convert the FSL MSI code to use msi_bitmap
From: Michael Ellerman @ 2008-07-15 14:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johannsson, linuxppc-dev, Kumar Gala, Jason.jin
In-Reply-To: <378edcf6ad114d35166364c5df03a8c422f757a1.1216133084.git.michael@ellerman.id.au>
This is 90% straight forward, although we have to change a few
printk format strings as well because of the change in type of hwirq.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/sysdev/fsl_msi.c | 103 ++++++-----------------------------------
arch/powerpc/sysdev/fsl_msi.h | 5 +-
2 files changed, 17 insertions(+), 91 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index d49fa99..f25ce81 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -14,7 +14,6 @@
*/
#include <linux/irq.h>
#include <linux/bootmem.h>
-#include <linux/bitmap.h>
#include <linux/msi.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
@@ -67,96 +66,22 @@ static struct irq_host_ops fsl_msi_host_ops = {
.map = fsl_msi_host_map,
};
-static irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
-{
- unsigned long flags;
- int order = get_count_order(num);
- int offset;
-
- spin_lock_irqsave(&msi->bitmap_lock, flags);
-
- offset = bitmap_find_free_region(msi->fsl_msi_bitmap,
- NR_MSI_IRQS, order);
-
- spin_unlock_irqrestore(&msi->bitmap_lock, flags);
-
- pr_debug("%s: allocated 0x%x (2^%d) at offset 0x%x\n",
- __func__, num, order, offset);
-
- return offset;
-}
-
-static void fsl_msi_free_hwirqs(struct fsl_msi *msi, int offset, int num)
-{
- unsigned long flags;
- int order = get_count_order(num);
-
- pr_debug("%s: freeing 0x%x (2^%d) at offset 0x%x\n",
- __func__, num, order, offset);
-
- spin_lock_irqsave(&msi->bitmap_lock, flags);
- bitmap_release_region(msi->fsl_msi_bitmap, offset, order);
- spin_unlock_irqrestore(&msi->bitmap_lock, flags);
-}
-
-static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
-{
- int i;
- int len;
- const u32 *p;
-
- bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
- get_count_order(NR_MSI_IRQS));
-
- p = of_get_property(msi->irqhost->of_node, "msi-available-ranges",
- &len);
-
- if (!p) {
- /* No msi-available-ranges property,
- * All the 256 MSI interrupts can be used
- */
- fsl_msi_free_hwirqs(msi, 0, 0x100);
- return 0;
- }
-
- if ((len % (2 * sizeof(u32))) != 0) {
- printk(KERN_WARNING "fsl_msi: Malformed msi-available-ranges "
- "property on %s\n", msi->irqhost->of_node->full_name);
- return -EINVAL;
- }
-
- /* Format is: (<u32 start> <u32 count>)+ */
- len /= 2 * sizeof(u32);
- for (i = 0; i < len; i++, p += 2)
- fsl_msi_free_hwirqs(msi, *p, *(p + 1));
-
- return 0;
-}
-
static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
{
int rc;
- int size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(u32);
- msi_data->fsl_msi_bitmap = kzalloc(size, GFP_KERNEL);
+ rc = msi_bitmap_alloc(&msi_data->bitmap, NR_MSI_IRQS,
+ msi_data->irqhost->of_node);
+ if (rc)
+ return rc;
- if (msi_data->fsl_msi_bitmap == NULL) {
- pr_debug("%s: ENOMEM allocating allocator bitmap!\n",
- __func__);
- return -ENOMEM;
+ rc = msi_bitmap_reserve_dt_hwirqs(&msi_data->bitmap);
+ if (rc < 0) {
+ msi_bitmap_free(&msi_data->bitmap);
+ return rc;
}
- rc = fsl_msi_free_dt_hwirqs(msi_data);
- if (rc)
- goto out_free;
-
return 0;
-out_free:
- kfree(msi_data->fsl_msi_bitmap);
-
- msi_data->fsl_msi_bitmap = NULL;
- return rc;
-
}
static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
@@ -176,7 +101,8 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
if (entry->irq == NO_IRQ)
continue;
set_irq_msi(entry->irq, NULL);
- fsl_msi_free_hwirqs(msi_data, virq_to_hw(entry->irq), 1);
+ msi_bitmap_free_hwirqs(&msi_data->bitmap,
+ virq_to_hw(entry->irq), 1);
irq_dispose_mapping(entry->irq);
}
@@ -198,15 +124,14 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
- irq_hw_number_t hwirq;
- int rc;
+ int rc, hwirq;
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
struct fsl_msi *msi_data = fsl_msi;
list_for_each_entry(entry, &pdev->msi_list, list) {
- hwirq = fsl_msi_alloc_hwirqs(msi_data, 1);
+ hwirq = msi_bitmap_alloc_hwirqs(&msi_data->bitmap, 1);
if (hwirq < 0) {
rc = hwirq;
pr_debug("%s: fail allocating msi interrupt\n",
@@ -217,9 +142,9 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
virq = irq_create_mapping(msi_data->irqhost, hwirq);
if (virq == NO_IRQ) {
- pr_debug("%s: fail mapping hwirq 0x%lx\n",
+ pr_debug("%s: fail mapping hwirq 0x%x\n",
__func__, hwirq);
- fsl_msi_free_hwirqs(msi_data, hwirq, 1);
+ msi_bitmap_free_hwirqs(&msi_data->bitmap, hwirq, 1);
rc = -ENOSPC;
goto out_free;
}
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index 6574550..331c7e7 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -13,6 +13,8 @@
#ifndef _POWERPC_SYSDEV_FSL_MSI_H
#define _POWERPC_SYSDEV_FSL_MSI_H
+#include <asm/msi_bitmap.h>
+
#define NR_MSI_REG 8
#define IRQS_PER_MSI_REG 32
#define NR_MSI_IRQS (NR_MSI_REG * IRQS_PER_MSI_REG)
@@ -31,8 +33,7 @@ struct fsl_msi {
void __iomem *msi_regs;
u32 feature;
- unsigned long *fsl_msi_bitmap;
- spinlock_t bitmap_lock;
+ struct msi_bitmap bitmap;
};
#endif /* _POWERPC_SYSDEV_FSL_MSI_H */
--
1.5.5
^ permalink raw reply related
* [PATCH 2/4] powerpc: Split-out common MSI bitmap logic into msi_bitmap.c
From: Michael Ellerman @ 2008-07-15 14:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johannsson, linuxppc-dev, Kumar Gala, Jason.jin
In-Reply-To: <378edcf6ad114d35166364c5df03a8c422f757a1.1216133084.git.michael@ellerman.id.au>
There are now two almost identical implementations of an MSI bitmap
allocator, one in mpic_msi.c and the other in fsl_msi.c.
Merge them together and put the result in msi_bitmap.c. Some of the
MPIC bits will remain to provide a nicer interface for the MPIC users.
In the process we fix two buglets. The first is that the allocation
routines, now msi_bitmap_alloc_hwirqs(), returned an unsigned result,
even though they use -1 to indicate allocation failure. Although all
the callers were checking correctly, it is much better for the routine
to just return an int. At least until someone wants > ~2 billion MSIs.
The second buglet is that the device tree reservation logic only
allowed power-of-two reservations. AFAICT that didn't effect any existing
code but it's nicer if we can reserve arbitrary irqs from MSI use.
We also add some selftests, which exposed the two buglets and now test
for them, as well as some basic sanity tests. The tests are only built
when CONFIG_DEBUG_KERNEL=y.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig.debug | 5 +
arch/powerpc/sysdev/Kconfig | 6 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/msi_bitmap.c | 247 ++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/msi_bitmap.h | 35 ++++++
5 files changed, 294 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 2840ab6..03804a8 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -67,6 +67,11 @@ config FTR_FIXUP_SELFTEST
depends on DEBUG_KERNEL
default n
+config MSI_BITMAP_SELFTEST
+ bool "Run self-tests of the MSI bitmap code."
+ depends on DEBUG_KERNEL
+ default n
+
choice
prompt "Serial Port"
depends on KGDB
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 72fb35b..3965828 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -6,3 +6,9 @@ config PPC4xx_PCI_EXPRESS
bool
depends on PCI && 4xx
default n
+
+config PPC_MSI_BITMAP
+ bool
+ depends on PCI_MSI
+ default y if MPIC
+ default y if FSL_PCI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 16a0ed2..bf8278d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -5,6 +5,7 @@ endif
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
fsl-msi-obj-$(CONFIG_PCI_MSI) += fsl_msi.o
+obj-$(CONFIG_PPC_MSI_BITMAP) += msi_bitmap.o
obj-$(CONFIG_PPC_MPC106) += grackle.o
obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
new file mode 100644
index 0000000..f84217b
--- /dev/null
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -0,0 +1,247 @@
+/*
+ * Copyright 2006-2008, Michael Ellerman, IBM Corporation.
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/bitmap.h>
+#include <asm/msi_bitmap.h>
+
+int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int num)
+{
+ unsigned long flags;
+ int offset, order = get_count_order(num);
+
+ spin_lock_irqsave(&bmp->lock, flags);
+ /*
+ * This is fast, but stricter than we need. We might want to add
+ * a fallback routine which does a linear search with no alignment.
+ */
+ offset = bitmap_find_free_region(bmp->bitmap, bmp->irq_count, order);
+ spin_unlock_irqrestore(&bmp->lock, flags);
+
+ pr_debug("msi_bitmap: allocated 0x%x (2^%d) at offset 0x%x\n",
+ num, order, offset);
+
+ return offset;
+}
+
+void msi_bitmap_free_hwirqs(struct msi_bitmap *bmp, unsigned int offset,
+ unsigned int num)
+{
+ unsigned long flags;
+ int order = get_count_order(num);
+
+ pr_debug("msi_bitmap: freeing 0x%x (2^%d) at offset 0x%x\n",
+ num, order, offset);
+
+ spin_lock_irqsave(&bmp->lock, flags);
+ bitmap_release_region(bmp->bitmap, offset, order);
+ spin_unlock_irqrestore(&bmp->lock, flags);
+}
+
+void msi_bitmap_reserve_hwirq(struct msi_bitmap *bmp, unsigned int hwirq)
+{
+ unsigned long flags;
+
+ pr_debug("msi_bitmap: reserving hwirq 0x%x\n", hwirq);
+
+ spin_lock_irqsave(&bmp->lock, flags);
+ bitmap_allocate_region(bmp->bitmap, hwirq, 0);
+ spin_unlock_irqrestore(&bmp->lock, flags);
+}
+
+/**
+ * msi_bitmap_reserve_dt_hwirqs - Reserve irqs specified in the device tree.
+ * @bmp: pointer to the MSI bitmap.
+ *
+ * Looks in the device tree to see if there is a property specifying which
+ * irqs can be used for MSI. If found those irqs reserved in the device tree
+ * are reserved in the bitmap.
+ *
+ * Returns 0 for success, < 0 if there was an error, and > 0 if no property
+ * was found in the device tree.
+ **/
+int msi_bitmap_reserve_dt_hwirqs(struct msi_bitmap *bmp)
+{
+ int i, j, len;
+ const u32 *p;
+
+ if (!bmp->of_node)
+ return 1;
+
+ p = of_get_property(bmp->of_node, "msi-available-ranges", &len);
+ if (!p) {
+ pr_debug("msi_bitmap: no msi-available-ranges property " \
+ "found on %s\n", bmp->of_node->full_name);
+ return 1;
+ }
+
+ if (len % (2 * sizeof(u32)) != 0) {
+ printk(KERN_WARNING "msi_bitmap: Malformed msi-available-ranges"
+ " property on %s\n", bmp->of_node->full_name);
+ return -EINVAL;
+ }
+
+ bitmap_allocate_region(bmp->bitmap, 0, get_count_order(bmp->irq_count));
+
+ spin_lock(&bmp->lock);
+
+ /* Format is: (<u32 start> <u32 count>)+ */
+ len /= 2 * sizeof(u32);
+ for (i = 0; i < len; i++, p += 2) {
+ for (j = 0; j < *(p + 1); j++)
+ bitmap_release_region(bmp->bitmap, *p + j, 0);
+ }
+
+ spin_unlock(&bmp->lock);
+
+ return 0;
+}
+
+int msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
+ struct device_node *of_node)
+{
+ int size;
+
+ if (!irq_count)
+ return -EINVAL;
+
+ size = BITS_TO_LONGS(irq_count) * sizeof(long);
+ pr_debug("msi_bitmap: allocator bitmap size is 0x%x bytes\n", size);
+
+ bmp->bitmap = zalloc_maybe_bootmem(size, GFP_KERNEL);
+ if (!bmp->bitmap) {
+ pr_debug("msi_bitmap: ENOMEM allocating allocator bitmap!\n");
+ return -ENOMEM;
+ }
+
+ /* We zalloc'ed the bitmap, so all irqs are free by default */
+ spin_lock_init(&bmp->lock);
+ bmp->of_node = of_node_get(of_node);
+ bmp->irq_count = irq_count;
+
+ return 0;
+}
+
+void msi_bitmap_free(struct msi_bitmap *bmp)
+{
+ /* we can't free the bitmap we don't know if it's bootmem etc. */
+ of_node_put(bmp->of_node);
+ bmp->bitmap = NULL;
+}
+
+#ifdef CONFIG_MSI_BITMAP_SELFTEST
+
+#define check(x) \
+ if (!(x)) printk("msi_bitmap: test failed at line %d\n", __LINE__);
+
+void test_basics(void)
+{
+ struct msi_bitmap bmp;
+ int i, size = 512;
+
+ /* Can't allocate a bitmap of 0 irqs */
+ check(msi_bitmap_alloc(&bmp, 0, NULL) != 0);
+
+ /* of_node may be NULL */
+ check(0 == msi_bitmap_alloc(&bmp, size, NULL));
+
+ /* Should all be free by default */
+ check(0 == bitmap_find_free_region(bmp.bitmap, size,
+ get_count_order(size)));
+ bitmap_release_region(bmp.bitmap, 0, get_count_order(size));
+
+ /* With no node, there's no msi-available-ranges, so expect > 0 */
+ check(msi_bitmap_reserve_dt_hwirqs(&bmp) > 0);
+
+ /* Should all still be free */
+ check(0 == bitmap_find_free_region(bmp.bitmap, size,
+ get_count_order(size)));
+ bitmap_release_region(bmp.bitmap, 0, get_count_order(size));
+
+ /* Check we can fill it up and then no more */
+ for (i = 0; i < size; i++)
+ check(msi_bitmap_alloc_hwirqs(&bmp, 1) >= 0);
+
+ check(msi_bitmap_alloc_hwirqs(&bmp, 1) < 0);
+
+ /* Should all be allocated */
+ check(bitmap_find_free_region(bmp.bitmap, size, 0) < 0);
+
+ /* And if we free one we can then allocate another */
+ msi_bitmap_free_hwirqs(&bmp, size / 2, 1);
+ check(msi_bitmap_alloc_hwirqs(&bmp, 1) == size / 2);
+
+ msi_bitmap_free(&bmp);
+
+ /* Clients may check bitmap == NULL for "not-allocated" */
+ check(bmp.bitmap == NULL);
+
+ kfree(bmp.bitmap);
+}
+
+void test_of_node(void)
+{
+ u32 prop_data[] = { 10, 10, 25, 3, 40, 1, 100, 100, 200, 20 };
+ const char *expected_str = "0-9,20-24,28-39,41-99,220-255";
+ char *prop_name = "msi-available-ranges";
+ char *node_name = "/fakenode";
+ struct device_node of_node;
+ struct property prop;
+ struct msi_bitmap bmp;
+ int size = 256;
+ DECLARE_BITMAP(expected, size);
+
+ /* There should really be a struct device_node allocator */
+ memset(&of_node, 0, sizeof(of_node));
+ kref_init(&of_node.kref);
+ of_node.full_name = node_name;
+
+ check(0 == msi_bitmap_alloc(&bmp, size, &of_node));
+
+ /* No msi-available-ranges, so expect > 0 */
+ check(msi_bitmap_reserve_dt_hwirqs(&bmp) > 0);
+
+ /* Should all still be free */
+ check(0 == bitmap_find_free_region(bmp.bitmap, size,
+ get_count_order(size)));
+ bitmap_release_region(bmp.bitmap, 0, get_count_order(size));
+
+ /* Now create a fake msi-available-ranges property */
+
+ /* There should really .. oh whatever */
+ memset(&prop, 0, sizeof(prop));
+ prop.name = prop_name;
+ prop.value = &prop_data;
+ prop.length = sizeof(prop_data);
+
+ of_node.properties = ∝
+
+ /* msi-available-ranges, so expect == 0 */
+ check(msi_bitmap_reserve_dt_hwirqs(&bmp) == 0);
+
+ /* Check we got the expected result */
+ check(0 == bitmap_parselist(expected_str, expected, size));
+ check(bitmap_equal(expected, bmp.bitmap, size));
+
+ msi_bitmap_free(&bmp);
+ kfree(bmp.bitmap);
+}
+
+int msi_bitmap_selftest(void)
+{
+ printk(KERN_DEBUG "Running MSI bitmap self-tests ...\n");
+
+ test_basics();
+ test_of_node();
+
+ return 0;
+}
+late_initcall(msi_bitmap_selftest);
+#endif /* CONFIG_MSI_BITMAP_SELFTEST */
diff --git a/include/asm-powerpc/msi_bitmap.h b/include/asm-powerpc/msi_bitmap.h
new file mode 100644
index 0000000..97ac3f4
--- /dev/null
+++ b/include/asm-powerpc/msi_bitmap.h
@@ -0,0 +1,35 @@
+#ifndef _POWERPC_SYSDEV_MSI_BITMAP_H
+#define _POWERPC_SYSDEV_MSI_BITMAP_H
+
+/*
+ * Copyright 2008, Michael Ellerman, IBM Corporation.
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/of.h>
+#include <asm/irq.h>
+
+struct msi_bitmap {
+ struct device_node *of_node;
+ unsigned long *bitmap;
+ spinlock_t lock;
+ unsigned int irq_count;
+};
+
+int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int num);
+void msi_bitmap_free_hwirqs(struct msi_bitmap *bmp, unsigned int offset,
+ unsigned int num);
+void msi_bitmap_reserve_hwirq(struct msi_bitmap *bmp, unsigned int hwirq);
+
+int msi_bitmap_reserve_dt_hwirqs(struct msi_bitmap *bmp);
+
+int msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
+ struct device_node *of_node);
+void msi_bitmap_free(struct msi_bitmap *bmp);
+
+#endif /* _POWERPC_SYSDEV_MSI_BITMAP_H */
--
1.5.5
^ permalink raw reply related
* [PATCH 1/4] powerpc: fsl_msi doesn't need it's own of_node
From: Michael Ellerman @ 2008-07-15 14:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johannsson, linuxppc-dev, Kumar Gala, Jason.jin
The FSL MSI code keeps a pointer to the of_node from the device
it represents. However it also has an irq_host, which contains
a pointer to the of_node, so use that one instead.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/sysdev/fsl_msi.c | 12 +++++-------
arch/powerpc/sysdev/fsl_msi.h | 3 ---
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 2c5187c..d49fa99 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -108,7 +108,8 @@ static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
get_count_order(NR_MSI_IRQS));
- p = of_get_property(msi->of_node, "msi-available-ranges", &len);
+ p = of_get_property(msi->irqhost->of_node, "msi-available-ranges",
+ &len);
if (!p) {
/* No msi-available-ranges property,
@@ -120,7 +121,7 @@ static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
if ((len % (2 * sizeof(u32))) != 0) {
printk(KERN_WARNING "fsl_msi: Malformed msi-available-ranges "
- "property on %s\n", msi->of_node->full_name);
+ "property on %s\n", msi->irqhost->of_node->full_name);
return -EINVAL;
}
@@ -317,14 +318,11 @@ static int __devinit fsl_of_msi_probe(struct of_device *dev,
goto error_out;
}
- msi->of_node = of_node_get(dev->node);
+ msi->irqhost = irq_alloc_host(dev->node, IRQ_HOST_MAP_LINEAR,
+ NR_MSI_IRQS, &fsl_msi_host_ops, 0);
- msi->irqhost = irq_alloc_host(of_node_get(dev->node),
- IRQ_HOST_MAP_LINEAR,
- NR_MSI_IRQS, &fsl_msi_host_ops, 0);
if (msi->irqhost == NULL) {
dev_err(&dev->dev, "No memory for MSI irqhost\n");
- of_node_put(dev->node);
err = -ENOMEM;
goto error_out;
}
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index a653468..6574550 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -22,9 +22,6 @@
#define FSL_PIC_IP_IPIC 0x00000002
struct fsl_msi {
- /* Device node of the MSI interrupt*/
- struct device_node *of_node;
-
struct irq_host *irqhost;
unsigned long cascade_irq;
--
1.5.5
^ permalink raw reply related
* Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
From: Richard Purdie @ 2008-07-15 14:43 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Stephen Rothwell, linux-kernel
In-Reply-To: <20080715142354.GA3296@polina.dev.rtsoft.ru>
On Tue, 2008-07-15 at 18:23 +0400, Anton Vorontsov wrote:
> > Spell out openfirmware :). I initially had no idea "of == openfirmware"
> > and I suspect others won't either...
>
> This would be unusually long name, that is
>
> $ find . -iname '*openfirmware*' | wc -l
> 0
>
> And in contrast:
>
> drivers/video/offb.c
> drivers/video/nvidia/nv_of.c
> drivers/usb/host/ohci-ppc-of.c
> drivers/usb/host/ehci-ppc-of.c
> drivers/serial/of_serial.c
> drivers/mtd/maps/physmap_of.c
> ...
>
> So, I think we should stick with the "of" for consistency, while
> confused users may consult with Kconfig for disambiguation.
The other cases don't have a gpio driver to confuse this new driver
with. Lets spell it out please, the filesystems can handle the extra
letters :).
Cheers,
Richard
^ permalink raw reply
* [patch 0/2] support buttons on IBM cell blades
From: krafft @ 2008-07-15 14:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: lohausen, cbe-oss-dev, arnd, willeke
These patches add support for the buttons on IBM cell blades.
Support for pinhole reset button was already in, the code just moved to ras.c
and got it's own config option.
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
Linux Kernel Development
IBM Systems & Technology Group
Phone: +49-07031-16-2032
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaetsfuehung: Herbert Kircher
Sitz der Gesellschaft: Boelingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* [patch 1/2] cell: cleanup sysreset_hack for IBM cell blades
From: krafft @ 2008-07-15 14:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: arnd, willeke, lohausen, Christian Krafft, cbe-oss-dev
In-Reply-To: <20080715142529.837984547@de.ibm.com>
From: Christian Krafft <krafft@de.ibm.com>
This patch adds a config option for the sysreset_hack used for
IBM Cell blades. The code is moves from pervasive.c into ras.c and
gets it's own init method.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux.git/arch/powerpc/platforms/cell/pervasive.c
===================================================================
--- linux.git.orig/arch/powerpc/platforms/cell/pervasive.c
+++ linux.git/arch/powerpc/platforms/cell/pervasive.c
@@ -38,8 +38,6 @@
#include "pervasive.h"
-static int sysreset_hack;
-
static void cbe_power_save(void)
{
unsigned long ctrl, thread_switch_control;
@@ -87,9 +85,6 @@ static void cbe_power_save(void)
static int cbe_system_reset_exception(struct pt_regs *regs)
{
- int cpu;
- struct cbe_pmd_regs __iomem *pmd;
-
switch (regs->msr & SRR1_WAKEMASK) {
case SRR1_WAKEEE:
do_IRQ(regs);
@@ -98,19 +93,7 @@ static int cbe_system_reset_exception(st
timer_interrupt(regs);
break;
case SRR1_WAKEMT:
- /*
- * The BMC can inject user triggered system reset exceptions,
- * but cannot set the system reset reason in srr1,
- * so check an extra register here.
- */
- if (sysreset_hack && (cpu = smp_processor_id()) == 0) {
- pmd = cbe_get_cpu_pmd_regs(cpu);
- if (in_be64(&pmd->ras_esc_0) & 0xffff) {
- out_be64(&pmd->ras_esc_0, 0);
- return 0;
- }
- }
- break;
+ return cbe_sysreset_hack();
#ifdef CONFIG_CBE_RAS
case SRR1_WAKESYSERR:
cbe_system_error_exception(regs);
@@ -134,8 +117,6 @@ void __init cbe_pervasive_init(void)
if (!cpu_has_feature(CPU_FTR_PAUSE_ZERO))
return;
- sysreset_hack = machine_is_compatible("IBM,CBPLUS-1.0");
-
for_each_possible_cpu(cpu) {
struct cbe_pmd_regs __iomem *regs = cbe_get_cpu_pmd_regs(cpu);
if (!regs)
@@ -144,12 +125,6 @@ void __init cbe_pervasive_init(void)
/* Enable Pause(0) control bit */
out_be64(®s->pmcr, in_be64(®s->pmcr) |
CBE_PMD_PAUSE_ZERO_CONTROL);
-
- /* Enable JTAG system-reset hack */
- if (sysreset_hack)
- out_be32(®s->fir_mode_reg,
- in_be32(®s->fir_mode_reg) |
- CBE_PMD_FIR_MODE_M8);
}
ppc_md.power_save = cbe_power_save;
Index: linux.git/arch/powerpc/platforms/cell/Kconfig
===================================================================
--- linux.git.orig/arch/powerpc/platforms/cell/Kconfig
+++ linux.git/arch/powerpc/platforms/cell/Kconfig
@@ -83,6 +83,14 @@ config CBE_RAS
depends on PPC_CELL_NATIVE
default y
+config PPC_IBM_CELL_RESETBUTTON
+ bool "IBM Cell Blade Pinhole reset button"
+ depends on CBE_RAS && PPC_IBM_CELL_BLADE
+ default y
+ help
+ Support Pinhole Resetbutton on IBM Cell blades.
+ This adds a method to trigger system reset via front panel pinhole
button. +
config CBE_THERM
tristate "CBE thermal support"
default m
Index: linux.git/arch/powerpc/platforms/cell/pervasive.h
===================================================================
--- linux.git.orig/arch/powerpc/platforms/cell/pervasive.h
+++ linux.git/arch/powerpc/platforms/cell/pervasive.h
@@ -30,4 +30,13 @@ extern void cbe_system_error_exception(s
extern void cbe_maintenance_exception(struct pt_regs *regs);
extern void cbe_thermal_exception(struct pt_regs *regs);
+#ifdef CONFIG_PPC_IBM_CELL_RESETBUTTON
+extern int cbe_sysreset_hack(void);
+#else
+static inline int cbe_sysreset_hack(void)
+{
+ return 1;
+}
+#endif /* CONFIG_PPC_IBM_CELL_RESETBUTTON */
+
#endif
Index: linux.git/arch/powerpc/platforms/cell/ras.c
===================================================================
--- linux.git.orig/arch/powerpc/platforms/cell/ras.c
+++ linux.git/arch/powerpc/platforms/cell/ras.c
@@ -230,6 +230,52 @@ static struct notifier_block cbe_ptcal_r
.notifier_call = cbe_ptcal_notify_reboot
};
+#ifdef CONFIG_PPC_IBM_CELL_RESETBUTTON
+static int sysreset_hack;
+
+static int __init cbe_sysreset_init(void)
+{
+ struct cbe_pmd_regs __iomem *regs;
+
+ sysreset_hack = machine_is_compatible("IBM,CBPLUS-1.0");
+ if (!sysreset_hack)
+ return 0;
+
+ regs = cbe_get_cpu_pmd_regs(0);
+ if (!regs)
+ return 0;
+
+ /* Enable JTAG system-reset hack */
+ out_be32(®s->fir_mode_reg,
+ in_be32(®s->fir_mode_reg) |
+ CBE_PMD_FIR_MODE_M8);
+
+ return 0;
+}
+device_initcall(cbe_sysreset_init);
+
+int cbe_sysreset_hack(void)
+{
+ struct cbe_pmd_regs __iomem *regs;
+
+ /*
+ * The BMC can inject user triggered system reset exceptions,
+ * but cannot set the system reset reason in srr1,
+ * so check an extra register here.
+ */
+ if (sysreset_hack && (smp_processor_id() == 0)) {
+ regs = cbe_get_cpu_pmd_regs(0);
+ if (!regs)
+ return 0;
+ if (in_be64(®s->ras_esc_0) & 0x0000ffff) {
+ out_be64(®s->ras_esc_0, 0);
+ return 0;
+ }
+ }
+ return 1;
+}
+#endif /* CONFIG_PPC_IBM_CELL_RESETBUTTON */
+
int __init cbe_ptcal_init(void)
{
int ret;
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
Linux Kernel Development
IBM Systems & Technology Group
Phone: +49-07031-16-2032
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaetsfuehung: Herbert Kircher
Sitz der Gesellschaft: Boelingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* [patch 2/2] cell: add support for power button of future IBM cell blades
From: krafft @ 2008-07-15 14:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: arnd, willeke, lohausen, Christian Krafft, cbe-oss-dev
In-Reply-To: <20080715142529.837984547@de.ibm.com>
From: Christian Krafft <krafft@de.ibm.com>
This patch adds support for the power button on future IBM cell blades.
It actually doesn't shut down the machine. Instead it exposes an
input device /dev/input/event0 to userspace which sends KEY_POWER
if power button has been pressed.
haldaemon actually recognizes the button, so a plattform independent acpid
replacement should handle it correctly.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux.git/arch/powerpc/platforms/cell/Kconfig
===================================================================
--- linux.git.orig/arch/powerpc/platforms/cell/Kconfig
+++ linux.git/arch/powerpc/platforms/cell/Kconfig
@@ -91,6 +91,14 @@ config PPC_IBM_CELL_RESETBUTTON
Support Pinhole Resetbutton on IBM Cell blades.
This adds a method to trigger system reset via front panel pinhole
button.
+config PPC_IBM_CELL_POWERBUTTON
+ tristate "IBM Cell Blade power button"
+ depends on PPC_IBM_CELL_BLADE && PPC_PMI && INPUT_EVDEV
+ default y
+ help
+ Support Powerbutton on IBM Cell blades.
+ This will enable the powerbutton as an input device.
+
config CBE_THERM
tristate "CBE thermal support"
default m
Index: linux.git/arch/powerpc/platforms/cell/cbe_powerbutton.c
===================================================================
--- /dev/null
+++ linux.git/arch/powerpc/platforms/cell/cbe_powerbutton.c
@@ -0,0 +1,117 @@
+/*
+ * driver for powerbutton on IBM cell blades
+ *
+ * (C) Copyright IBM Corp. 2005-2008
+ *
+ * Author: Christian Krafft <krafft@de.ibm.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, or (at your option)
+ * any later version.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/input.h>
+#include <linux/platform_device.h>
+#include <asm/pmi.h>
+#include <asm/prom.h>
+
+static struct input_dev *button_dev;
+static struct platform_device *button_pdev;
+
+static void cbe_powerbutton_handle_pmi(pmi_message_t pmi_msg)
+{
+ BUG_ON(pmi_msg.type != PMI_TYPE_POWER_BUTTON);
+
+ input_report_key(button_dev, KEY_POWER, 1);
+ input_sync(button_dev);
+ input_report_key(button_dev, KEY_POWER, 0);
+ input_sync(button_dev);
+}
+
+static struct pmi_handler cbe_pmi_handler = {
+ .type = PMI_TYPE_POWER_BUTTON,
+ .handle_pmi_message = cbe_powerbutton_handle_pmi,
+};
+
+static int __init cbe_powerbutton_init(void)
+{
+ int ret = 0;
+ struct input_dev *dev;
+
+ if (!machine_is_compatible("IBM,CBPLUS-1.0")) {
+ printk(KERN_ERR "%s: Not a cell blade.\n", __func__);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ dev = input_allocate_device();
+ if (!dev) {
+ ret = -ENOMEM;
+ printk(KERN_ERR "%s: Not enough memory.\n", __func__);
+ goto out;
+ }
+
+ set_bit(EV_KEY, dev->evbit);
+ set_bit(KEY_POWER, dev->keybit);
+
+ dev->name = "Power Button";
+ dev->id.bustype = BUS_HOST;
+
+ /* this makes the button look like an acpi power button
+ * no clue whether anyone relies on that though */
+ dev->id.product = 0x02;
+ dev->phys = "LNXPWRBN/button/input0";
+
+ button_pdev = platform_device_register_simple("power_button", 0, NULL,
0);
+ if (IS_ERR(button_pdev)) {
+ ret = PTR_ERR(button_pdev);
+ goto out_free_input;
+ }
+
+ dev->dev.parent = &button_pdev->dev;
+ ret = input_register_device(dev);
+ if (ret) {
+ printk(KERN_ERR "%s: Failed to register device\n", __func__);
+ goto out_free_pdev;
+ }
+
+ button_dev = dev;
+
+ ret = pmi_register_handler(&cbe_pmi_handler);
+ if (ret) {
+ printk(KERN_ERR "%s: Failed to register with pmi.\n",
__func__);
+ goto out_free_pdev;
+ }
+
+ goto out;
+
+out_free_pdev:
+ platform_device_unregister(button_pdev);
+out_free_input:
+ input_free_device(dev);
+out:
+ return ret;
+}
+
+static void __exit cbe_powerbutton_exit(void)
+{
+ pmi_unregister_handler(&cbe_pmi_handler);
+ platform_device_unregister(button_pdev);
+ input_free_device(button_dev);
+}
+
+module_init(cbe_powerbutton_init);
+module_exit(cbe_powerbutton_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Christian Krafft <krafft@de.ibm.com>");
Index: linux.git/arch/powerpc/platforms/cell/Makefile
===================================================================
--- linux.git.orig/arch/powerpc/platforms/cell/Makefile
+++ linux.git/arch/powerpc/platforms/cell/Makefile
@@ -9,6 +9,8 @@ obj-$(CONFIG_CBE_CPUFREQ_PMI) += cbe_cp
obj-$(CONFIG_CBE_CPUFREQ) += cbe-cpufreq.o
cbe-cpufreq-y += cbe_cpufreq_pervasive.o
cbe_cpufreq.o
+obj-$(CONFIG_PPC_IBM_CELL_POWERBUTTON) += cbe_powerbutton.o
+
ifeq ($(CONFIG_SMP),y)
obj-$(CONFIG_PPC_CELL_NATIVE) += smp.o
endif
Index: linux.git/include/asm-powerpc/pmi.h
===================================================================
--- linux.git.orig/include/asm-powerpc/pmi.h
+++ linux.git/include/asm-powerpc/pmi.h
@@ -30,6 +30,7 @@
#ifdef __KERNEL__
#define PMI_TYPE_FREQ_CHANGE 0x01
+#define PMI_TYPE_POWER_BUTTON 0x02
#define PMI_READ_TYPE 0
#define PMI_READ_DATA0 1
#define PMI_READ_DATA1 2
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
Linux Kernel Development
IBM Systems & Technology Group
Phone: +49-07031-16-2032
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaetsfuehung: Herbert Kircher
Sitz der Gesellschaft: Boelingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-15 14:23 UTC (permalink / raw)
To: Richard Purdie; +Cc: linuxppc-dev, Stephen Rothwell, linux-kernel
In-Reply-To: <1216128687.5345.61.camel@dax.rpnet.com>
On Tue, Jul 15, 2008 at 02:31:27PM +0100, Richard Purdie wrote:
> On Tue, 2008-07-15 at 17:24 +0400, Anton Vorontsov wrote:
> > On Tue, Jul 15, 2008 at 01:54:30PM +0100, Richard Purdie wrote:
> > > I don't have any issue with the driver itself, just the name which is
> > > going to confuse people no end.
> > >
> > > Can we come up with a better name for this driver please?
> [...]
> > > "openfirmware-led"?
> >
> > And this would be wrong, since this driver is for GPIO LEDs only, not
> > for all LEDs that OF can describe. In future there could be OF PWM LEDs
> > or something like this.
>
> Ok, will these be a separate driver or combined into the gpio driver?
I believe this must be a separate driver. The two drivers would have
nothing in common except prologue registration stuff.
> > > I'm mainly concerned with the more user visible bits like the name of
> > > the .c file, the wording of the Kconfig option and the module
> > > description. We need to play down the GPIO bit and play up the
> > > openfirmware bindings bit.
> >
> > Hm... file name is leds-of-gpio.c, how could I play up the "of" bit more
> > than this? ;-)
>
> Spell out openfirmware :). I initially had no idea "of == openfirmware"
> and I suspect others won't either...
This would be unusually long name, that is
$ find . -iname '*openfirmware*' | wc -l
0
And in contrast:
drivers/video/offb.c
drivers/video/nvidia/nv_of.c
drivers/usb/host/ohci-ppc-of.c
drivers/usb/host/ehci-ppc-of.c
drivers/serial/of_serial.c
drivers/mtd/maps/physmap_of.c
...
So, I think we should stick with the "of" for consistency, while
confused users may consult with Kconfig for disambiguation.
But if you really want the expanded name.. just repeat it, and I'll
change the name.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: 2.6.26 does not boot on Pegasos
From: David Woodhouse @ 2008-07-15 14:17 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1216116349.7740.101.camel@pasglop>
On Tue, 2008-07-15 at 20:05 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-15 at 12:00 +0200, Gabriel Paubert wrote:
> > Hi,
> >
> > I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot.
> > The last message I have is:
> > gunzip (0xffffffff <----- some more hex digits)
> >
> > The configuration has been created from a working 2.6.25 one with
> > make oldconfig and answering N to new config options.
> >
> > Anybody has seen this or do I have to start digging deeper?
>
> Unfortunately, I don't have a pegasos anymore. David, did you get a
> chance to test anything recent on yours ? Matt ?
I'm away from home for the next couple of weeks, but can test when I get
home after OLS. I've run relatively recent kernels on Pegasos within the
last 2-3 weeks.
--
dwmw2
^ permalink raw reply
* RE: 82xx performance
From: Rune Torgersen @ 2008-07-15 14:16 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
In-Reply-To: <200807142244.07450.arnd@arndb.de>
> This is certainly significant, but a lot has happened between the two
> versions. I few ideas:
>=20
> * compare some of the key configuration options:
> # CONFIG_DEBUG_*
> # CONFIG_PREEMPT*
> # CONFIG_NO_HZ
> # CONFIG_HZ
2.6.25:
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_DEBUG_FS is not set
CONFIG_DEBUG_KERNEL=3Dy
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=3Dy
CONFIG_DEBUG_INFO=3Dy
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUGGER is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=3Dy
# CONFIG_PREEMPT_RCU is not set
# CONFIG_NO_HZ is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=3Dy
CONFIG_HZ=3D1000
2.6.18:
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_KERNEL=3Dy
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_INFO=3Dy
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=3Dy
CONFIG_PREEMPT_BKL=3Dy
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=3Dy
CONFIG_HZ=3D1000
>=20
> * Try looking at where the time is spent, using oprofile or=20
> readprofile
Doing this now.
>=20
> * Try setting /proc/sys/kernel/compat/sched_yield to 1, to=20
> get the legacy
> behaviour of the scheduler.
Made perfromance on .25 a few percent worse. (84 minutes on kernel
compile instead of 81 minutes)
=20
> * Maybe there is a kernel version that supports your hardware in both
> arch/ppc/ and arch/powerpc. In that case, you could see if=20
> the platform
> change had an impact.
Will try. Last port in ppc branch was 2.6.18 and first in powerpc was
2.6.24.
I should be able to port ppc to .25 also I think.
Thanks!
^ permalink raw reply
* Re: [PATCH] of: i2c: improve last resort compatible entry selection
From: Jean Delvare @ 2008-07-15 14:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910807150640x52cca982jf4f1ccfe7fd506cf@mail.gmail.com>
On Tue, 15 Jul 2008 09:40:08 -0400, Jon Smirl wrote:
> On 7/15/08, Jochen Friedrich <jochen@scram.de> wrote:
> > Hi Anton,
> >
> >
> > > Since no sane driver will ever match specific devices, what we want is
> > > to select most generic option (last). Then driver may call
> > > of_device_is_compatible() if it is really interested in details.
> >
> >
> > My original intention was to have alias entries for specific devices in the
> > i2c device drivers. Later, Jean decided to only have the most generic names
> > in there (like in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/media/video/tvaudio.c;h=c77914d99d15c5972c94e9763a08b5789098e90a;hp=6f9945b04e1f2bcd676f0ed8dc910994b29ed300;hb=ae429083efe996ca2c569c44fd6fea440676dc33;hpb=60b129d7bfa3e20450816983bd52c49bb0bc1c21)
> > So your patch is correct.
Eeeek. The patch you mention here is only the conversion of ONE driver.
It is absolutely not relevant as to what the general rule is.
Background:
Some media drivers have been relying on autodetection for years. We
will convert them to the new model as much as possible, however the
knowledge of what chip is present on each board has sometimes been
lost, so switching to the new i2c model isn't that easy. So, as a
transition step, for a few media drivers, we decided to not enumerate
all the supported chips (nobody would be able to instantiate any of
them specifically anyway). This might change in the future, as
developers gain knowledge about the hardware again.
Jochen, I am very surprised that you dare drawing conclusions based on
one random patch of mine. And I am unhappy that you even claim that I
took some decision when I definitely did not.
> Why aren't we listing the chip names in the driver's id section? Large
> chip id tables are not unusual in the kernel, the e1000 driver has
> about 70 entries.
>
> Taking the chip id table out of the driver just means we have to build
> it somewhere else. It doesn't save space, the tables just get moved.
> Device firmware has the chip names in it so there has to be code in
> the kernel somewhere to do the mapping from chip id to linux driver
> name.
>
> Pushing the linux driver name down into the firmware is even crazier.
> + /* 2. search for linux,<i2c-type> entry */
> Now if the linux driver gets renamed everyone on the planet needs a
> firmware update.
I can't comment on the specific issue at hand as I am not familiar with
it, but overall Jon appears to be right. Listing individual chips in
id_table is the standard way to go. That's even the very reason why we
decided to add this id_table to i2c_driver, instead of matching on the
driver name as we were doing before.
--
Jean Delvare
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Mark Brown @ 2008-07-15 14:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi, liam.girdwood
In-Reply-To: <9e4733910807150608o41f932c7r7a2321c56b410913@mail.gmail.com>
On Tue, Jul 15, 2008 at 09:08:28AM -0400, Jon Smirl wrote:
> On 7/15/08, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > Binding isn't the issue here - it's loading the driver in the first
> > place. Once the drivers are loaded they can (hopefully) figure out if
> > they are running on appropriate hardware.
> In this case we would end up with two core PowerPC machine drivers
> bound, not ALSA ones. We have machine drivers in the PowerPC core,
> that's one reason why it is confusing to call the ALSA drivers machine
> drivers too.
Again, I'm not talking about binding anything.
> > This is what I'm suggesting, modulo the fact that I'm suggesting *not*
> > creating virtual devices but rather providing a mechanism for drivers to
> > load without binding to anything. It strikes me that you're going to
> If you have drivers for four different hardware releases compiled into
> your kernel, the only kernel mechanism I know of to trigger only one
> of these to initialize is to create a device and then let the probe
> mechanism sort it out. This is even more true when the drivers are on
> initrd and need to be dynamically loaded. The module load code will
> search through the alias lists in the module .ko files.
This can be handled in the module initialisation (rather than driver
probe) - providing something can arrange for the driver to get loaded
then the drivers can check the system they're running on when that
happens and fail if it's inappropriate. The ARM ASoC drivers and x86
DMI based stuff do things this way, for example (ARM doesn't have the
automatic module load stuff implemented, though).
The infrastructure for automatically loading modules is usable
separately from device registration, though normally the two do go hand
in hand.
> It has been pointed out that a lite5200b-fabric device isn't really a
> virtual devices. It's a device that represents the traces on the PCB
> wiring the generic chip drivers together.
This was brought up very early on when you guys first started working on
it. :/
^ permalink raw reply
* Re: [PATCH] of: i2c: improve last resort compatible entry selection
From: Jon Smirl @ 2008-07-15 13:40 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev
In-Reply-To: <487C7F9A.7030201@scram.de>
On 7/15/08, Jochen Friedrich <jochen@scram.de> wrote:
> Hi Anton,
>
>
> > Since no sane driver will ever match specific devices, what we want is
> > to select most generic option (last). Then driver may call
> > of_device_is_compatible() if it is really interested in details.
>
>
> My original intention was to have alias entries for specific devices in the
> i2c device drivers. Later, Jean decided to only have the most generic names
> in there (like in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/media/video/tvaudio.c;h=c77914d99d15c5972c94e9763a08b5789098e90a;hp=6f9945b04e1f2bcd676f0ed8dc910994b29ed300;hb=ae429083efe996ca2c569c44fd6fea440676dc33;hpb=60b129d7bfa3e20450816983bd52c49bb0bc1c21)
> So your patch is correct.
Why aren't we listing the chip names in the driver's id section? Large
chip id tables are not unusual in the kernel, the e1000 driver has
about 70 entries.
Taking the chip id table out of the driver just means we have to build
it somewhere else. It doesn't save space, the tables just get moved.
Device firmware has the chip names in it so there has to be code in
the kernel somewhere to do the mapping from chip id to linux driver
name.
Pushing the linux driver name down into the firmware is even crazier.
+ /* 2. search for linux,<i2c-type> entry */
Now if the linux driver gets renamed everyone on the planet needs a
firmware update.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/86xx: mpc8610_hpcd: add support for ULI RTC
From: Kumar Gala @ 2008-07-15 13:31 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080611230437.GD21351@polina.dev.rtsoft.ru>
On Jun 11, 2008, at 6:04 PM, Anton Vorontsov wrote:
> The ULI "Super South Bridge" contains ISA bridge to the legacy
> devices, such as Super IO mouse/keyboard/floppy disk controllers,
> parallel port, i8259 interrupt controller and so on.
>
> i8259 is disabled on the MPC8610HPCD, and other peripherals are not
> traced out. So we use only RTC.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8610_hpcd.dts | 14 +++++++
> arch/powerpc/configs/mpc8610_hpcd_defconfig | 51 ++++++++++++++++++
> ++++++--
> 2 files changed, 61 insertions(+), 4 deletions(-)
applied.
- k
^ 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