* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Timur Tabi @ 2008-07-14 15:51 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <9e4733910807140713r5739efedw81e65632006d101d@mail.gmail.com>
Jon Smirl wrote:
> Which are we going to call it, fabric or machine?
Fabric.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Is there anybody created the ML403 firmware in which XEMAC configured in "Scattered DMA" Mode
From: Naresh Bhat @ 2008-07-14 16:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
Hi All,
Is there anybody created the ML403 firmware in which XEMAC configured in
"Scattered DMA" Mode. Please provide me the .dts file and .bit file I am
not able to create it. Where can I get the "device tree" and "Reference
Design" (I think Xilinx) for the ML403 board?
--
Naresh Bhat
9845365362(M)
[-- Attachment #2: Type: text/html, Size: 374 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Timur Tabi @ 2008-07-14 16:14 UTC (permalink / raw)
To: Jon Smirl, Grant Likely, linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080714150527.GD25448@sirena.org.uk>
Mark Brown wrote:
>> The PowerPC side isn't without fault too. PowerPC still doesn't have a
>> good way to load the fabric/machine driver.
>
> I'm finding it difficult to square these two statements - from an ASoC
> point of view the main thing this patch is doing is adding a machine
> driver and that's not something that's going to go away.
Jon's concern is that there is no straightforward way to build a kernel with
multiple fabric drivers and have the right one chosen via the device tree. This
is just a limitation of the device tree model, and no one has come up with a
good solution yet.
The problem still exists in ASoC V2. However, it's not anything that ASoC
itself needs to be concerned with. It's purely a PowerPC problem.
>> Which are we going to call it, fabric or machine? I had been working
>> on the Apple code in sound/aoa. It is called fabric in that code. The
>> equivalent driver is called machine in ASoC v1.
>
> ASoC has always called it a machine driver.
Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, it
should be called a fabric driver because we already have machine drivers.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely @ 2008-07-14 16:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <487B7B71.9060606@freescale.com>
On Mon, Jul 14, 2008 at 10:14 AM, Timur Tabi <timur@freescale.com> wrote:
> Mark Brown wrote:
>
>>> The PowerPC side isn't without fault too. PowerPC still doesn't have a
>>> good way to load the fabric/machine driver.
>>
>> I'm finding it difficult to square these two statements - from an ASoC
>> point of view the main thing this patch is doing is adding a machine
>> driver and that's not something that's going to go away.
>
> Jon's concern is that there is no straightforward way to build a kernel with
> multiple fabric drivers and have the right one chosen via the device tree. This
> is just a limitation of the device tree model, and no one has come up with a
> good solution yet.
>
> The problem still exists in ASoC V2. However, it's not anything that ASoC
> itself needs to be concerned with. It's purely a PowerPC problem.
It's purely an *OF Device Tree* problem. PowerPC isn't the only
platform using the device tree. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc: mman.h export fixups
From: Dave Kleikamp @ 2008-07-14 16:34 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, ppc-dev
In-Reply-To: <20080714192557.331a50f5.sfr@canb.auug.org.au>
On Mon, 2008-07-14 at 19:25 +1000, Stephen Rothwell wrote:
> Commit ef3d3246a0d06be622867d21af25f997aeeb105f ("powerpc/mm: Add Strong
> Access Ordering support") in the powerpc/{next,master} tree caused the
> following in a powerpc allmodconfig build:
>
> usr/include/asm/mman.h requires linux/mm.h, which does not exist in exported headers
>
> We should not use CONFIG_PPC64 in an unprotected (by __KERNEL__)
> section of an exported include file and linux/mm.h is not exported. So
> protect the whole section that is CONFIG_PPC64 with __KERNEL__ and put
> the two introduced includes in there as well.
Agreed. None of the code in the CONFIG_PPC64 ifdef needs to be seen by
user space.
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> ---
> include/asm-powerpc/Kbuild | 2 +-
> include/asm-powerpc/mman.h | 8 ++++++--
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> I have included this patch in today's linux-next tree.
>
> diff --git a/include/asm-powerpc/Kbuild b/include/asm-powerpc/Kbuild
> index 34a0a8d..329ecfd 100644
> --- a/include/asm-powerpc/Kbuild
> +++ b/include/asm-powerpc/Kbuild
> @@ -2,7 +2,6 @@ include include/asm-generic/Kbuild.asm
>
> header-y += auxvec.h
> header-y += ioctls.h
> -header-y += mman.h
> header-y += sembuf.h
> header-y += siginfo.h
> header-y += stat.h
> @@ -28,6 +27,7 @@ unifdef-y += byteorder.h
> unifdef-y += cputable.h
> unifdef-y += elf.h
> unifdef-y += nvram.h
> +unifdef-y += mman.h
> unifdef-y += param.h
> unifdef-y += posix_types.h
> unifdef-y += ptrace.h
> diff --git a/include/asm-powerpc/mman.h b/include/asm-powerpc/mman.h
> index f8a32e2..9209f75 100644
> --- a/include/asm-powerpc/mman.h
> +++ b/include/asm-powerpc/mman.h
> @@ -1,9 +1,7 @@
> #ifndef _ASM_POWERPC_MMAN_H
> #define _ASM_POWERPC_MMAN_H
>
> -#include <asm/cputable.h>
> #include <asm-generic/mman.h>
> -#include <linux/mm.h>
>
> /*
> * This program is free software; you can redistribute it and/or
> @@ -28,7 +26,12 @@
> #define MAP_POPULATE 0x8000 /* populate (prefault) pagetables */
> #define MAP_NONBLOCK 0x10000 /* do not block on IO */
>
> +#ifdef __KERNEL__
> #ifdef CONFIG_PPC64
> +
> +#include <asm/cputable.h>
> +#include <linux/mm.h>
> +
> /*
> * This file is included by linux/mman.h, so we can't use cacl_vm_prot_bits()
> * here. How important is the optimization?
> @@ -56,4 +59,5 @@ static inline int arch_validate_prot(unsigned long prot)
> #define arch_validate_prot(prot) arch_validate_prot(prot)
>
> #endif /* CONFIG_PPC64 */
> +#endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_MMAN_H */
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-14 16:41 UTC (permalink / raw)
To: Richard Purdie; +Cc: linuxppc-dev, linux-kernel
Despite leds-gpio and leds-of-gpio similar names and 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>
---
Kumar, since the dts bindings are split now, please don't bother with
all-in-one documentation patch. I guess it would be better to do it
this way. I also hope "Documentation/powerpc/dts-bindings" is the final
location for the bindings and won't change.
Documentation/powerpc/dts-bindings/gpio/led.txt | 15 ++
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-of-gpio.c | 192 +++++++++++++++++++++++
4 files changed, 216 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/gpio/led.txt
create mode 100644 drivers/leds/leds-of-gpio.c
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt b/Documentation/powerpc/dts-bindings/gpio/led.txt
new file mode 100644
index 0000000..7e9ce81
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -0,0 +1,15 @@
+LED connected to GPIO
+
+Required properties:
+- compatible : should be "gpio-led".
+- label : (optional) the label for this LED. If omitted, the label is
+ taken from the node name (excluding the unit address).
+- gpios : should specify LED GPIO.
+
+Example:
+
+led@0 {
+ compatible = "gpio-led";
+ label = "hdd";
+ gpios = <&mcu_pio 0 0>;
+};
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1c35dfa..ad7eab3 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_OF_GPIO
+ tristate "LED Support for GPIO connected LEDs (OpenFirmware bindings)"
+ 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..593775c 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_OF_GPIO) += leds-of-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-of-gpio.c b/drivers/leds/leds-of-gpio.c
new file mode 100644
index 0000000..f8e2597
--- /dev/null
+++ b/drivers/leds/leds-of-gpio.c
@@ -0,0 +1,192 @@
+/*
+ * LEDs driver for GPIOs (OpenFirmware bindings)
+ *
+ * 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>
+
+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 = 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 = ofdev->dev.bus_id;
+ led->cdev.brightness_set = gpio_led_set;
+
+ ret = gpio_request(led->gpio, ofdev->dev.bus_id);
+ 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:
+ 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("OF GPIO LED driver");
+MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
+MODULE_LICENSE("GPL");
--
1.5.5.4
^ permalink raw reply related
* 82xx performance
From: Rune Torgersen @ 2008-07-14 16:34 UTC (permalink / raw)
To: linuxppc-dev
Hi
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
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
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?
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Milton Miller @ 2008-07-14 16:53 UTC (permalink / raw)
To: Roman Zippel
Cc: Stephen Rothwell, linux-kernel, ppcdev, Paul Mackerras,
Sam Ravnborg
In-Reply-To: <Pine.LNX.4.64.0807101654080.6791@localhost.localdomain>
Hi Roman.
I saw your reply on the list archives but can not find
it in my inbox.
On Sun Jul 13 at 09:21:08 EST 2008, Roman Zippel wrote:
> On Sat, 12 Jul 2008, Milton Miller wrote:
>
>> (1) #define PAGE_OFFSET (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
>>
>> It creates unreadable code, where two defines with almost the same
> name (the
>> only difference being
>> the CONFIG_ prefix, which is often ignored when scanning) contains
> radically
>> different values.
>>
>> (2) #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET)
>
> Giving it different names is not really difficult. Any objections to
> CONFIG_PAGE_HIGH_OFFSET?
Once you remove the symmetry and add the ifdef to page.h, we need to
reevaluate its presence in Kconfig. I can't think of a reason to
have a partial value, and therefore would instead say take out the
config variable on PPC64 as the PPC32 address split reason is moot.
>
>> On a seperate note,
>>>>>> config PINT3_ASSIGN
>>>>>> hex "PINT3_ASSIGN"
>>>>>> depends on PINTx_REASSIGN
>>>>>> - default 0x02020303
>>>>>> + default 0x2020303
>>
>> is harder to read. The value is a list of 4 1 byte values, but you
>> have hidden the first nibble making parsing the rest of the value
>> hard.
>
> Sam mentioned that already, but that's a situation where the warning
> can
> be relaxed.
The warning can be relaxed? What are you talking about?
I was trying to make a case for leading zeros without actually stating
what I was asking for.
You changes did s/(0x)?0*/0x/, y/A-F/a-f/ -- that is you made all hex
constants conform to "0x%x". I was arguing for 0x%8.8x, or just
leaving
them as formatted.
>
>> If you are worried about users tring to set values that are too high,
>> then make the types be hex8, hex16, hex32, and hex64.
>
> It's not this, I value consistency as much as you and the values are
> sometimes used as integers, so a working range is needed. Using simple
> integers keeps things much simpler and as the ASM_CONST example shows
> any
> bigger values are not necessarily directly usable anyway.
How many places want to range check hex numbers? Is it just setting
the number of digits input? If strtoull is to hard, can we just do
the check as strings of digits?
If we keep this new restriction on hex numbers, it needs to be in
the Documentation, even if its prefixed by "currently".
milton
^ 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-14 16:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <487B7B71.9060606@freescale.com>
On Mon, Jul 14, 2008 at 11:14:41AM -0500, Timur Tabi wrote:
> Mark Brown wrote:
> > I'm finding it difficult to square these two statements - from an ASoC
> > point of view the main thing this patch is doing is adding a machine
> > driver and that's not something that's going to go away.
> Jon's concern is that there is no straightforward way to build a kernel with
> multiple fabric drivers and have the right one chosen via the device tree. This
> is just a limitation of the device tree model, and no one has come up with a
> good solution yet.
Indeed - I understand what the problem you guys have is, I just want to
make sure that there is a reasonable consensus among the PowerPC people
that this approach is OK to go in and won't create ructions. The lack
of resolution on this issue makes me nervous about any proposed solution
where I haven't seen any explicit indication that the community is OK
with it.
Incidentally, nobody ever really commented on my suggestion to do
something DMI-like - you've already got the board type information
present in the device trees (in the model and compatible information in
the root nodes), all that's needed is an API to allow matching on it.
> The problem still exists in ASoC V2. However, it's not anything that ASoC
> itself needs to be concerned with. It's purely a PowerPC problem.
Right, I just want to be clear that you guys all understand what this
code does and that there won't be too many complaints after the fact.
> > ASoC has always called it a machine driver.
> Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, it
> should be called a fabric driver because we already have machine drivers.
I don't mind - you can call it what you like inside PowerPC-specific
code.
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely @ 2008-07-14 17:06 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, alsa-devel, liam.girdwood, jonsmirl
In-Reply-To: <20080714134930.GC25448@sirena.org.uk>
On Mon, Jul 14, 2008 at 7:49 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
>> +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
>> +{
>> + struct platform_device *pdev;
>> + int rc;
>> +
>> + /* Only register the device if both the codec and platform have
>> + * been registered */
>> + if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
>> + return;
>> +
>> + pr_info("platform<-->codec match achieved; registering machine\n");
>
> So what this does is add an extremely simple machine driver which
> matches up the first DAI on a single codec and platform with no facility
> for setting up any configurable clocking or anything? This is fine in
> so far as it goes but it's going to work for very few systems as it is -
> most codecs will need some additional configuration. This could be
> added later, though.
Yes, that is pretty much exactly what it is. When I wrote this my
goal was just to get something working that had some semblance of
cleanliness. Since it is now looking like something that could get
merged, I'll clean up the documentation describing exactly what it is
and what the limitations are. I fully expect that if others find it
useful then they will need to extend it to extract additional
configuration information out of the device tree.
That being said, I expect this code to be completely rewritten when
ASoC v2 hits mainline. Most of the code is devoted to matching
platforms with codecs. The mechanism will be completely different
when the ASoC layer handles making sure all devices are present before
setting up the machine driver. I expect that some machines can be
handled with some form of generic of-asoc driver, while more complex
ones will need custom code.
> Given this it might be worth renaming it to something less generic and
> perhaps pushing it down into an of directory below the main ASoC
> directory to parallel existing machine drivers. I'm happy with the code
> from an ASoC point of view.
I'm okay with that. How about fsl/mpc5200-of-machine.c for now?
(only the mpc5200 i2s driver uses it at the moment). It can always be
renamed if other folks want to use it for other chips.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Milton Miller @ 2008-07-14 17:09 UTC (permalink / raw)
To: Jean Delvare
Cc: Samuel Ortiz, linux-kernel, lm-sensors, linuxppc-dev,
Hans de Goede, David Hubbard
In-Reply-To: <20080714095914.0644ac5d@hyperion.delvare>
On Jul 14, 2008, at 2:59 AM, Jean Delvare wrote:
> On Sun, 13 Jul 2008 15:26:56 -0600, David Hubbard wrote:
>> Hi Hans,
>>
>>>> I propose writing a subsystem driver. (Is that properly called "The
>>>> SuperIO Bus Driver"?) If no one thinks it's a really bad idea I will
>>>> put together some code and submit it for review, and maintain it.
>>>>
>>>> Some hwmon chips have odd / unique probe sequences. IMHO this is
>>>> where
>>>> the design needs to be inspected. One of those is the w83627ehf,
>>>> which
>>>> Jean and Hans are familiar enough with to check my work.
>>>>
>>>> Thoughts?
>>>
>>> I'm afraid that making this a "bus" will be a bit overkill. Jim's
>>> patches
>>> are quite simple and seem todo the job.
>>>
>>> Also keep in mind that most users will be platform devices which
>>> just want
>>> to use the superio registers to find out the baseaddress of their
>>> logical
>>> device, a whole bus seems overkill for this, would the hwmon driver
>>> then
>>> need to be a superio_driver (as well as an platform_driver) or can
>>> the bus
>>> be queried / used
>>> without having to be a bustype-driver?
>>
>> I think that's a valid point. I am willing to keep it small, but I
>> would prefer to follow the pattern set in other subsystems. It may be
>> my lack of experience in designing a subsystem showing here! What are
>> some alternative ways to implement it?
>>
>> In other words, Jim's patches are a good start, but maybe I am
>> misunderstanding them. I see it as the superio-locks module, a driver
>> that other drivers would depend on / auto-load. Is that something
>> other subsystems also do?
>
> Well, there are two approaches to the problem. The first approach
> (which I think Jim took in his patches? I don't really remember) is to
> simply solve the problem of concurrent I/O access to the Super-I/O
> configuration ports (typically 0x2e/0x2f or 0x4e/0x4f). That would be a
> simple driver requesting the ports in question and exporting an API for
> other drivers to access them in a safe way.
>
> The second approach is to make it a whole subsystem, as David is
> suggesting. The Super-I/O driver would then not only request the I/O
> ports, it would also identify which Super-I/O is there, and it would
> create devices (in the Linux device driver model sense of the term) for
> every logical device we are interested in (amongst which the hwmon
> ones.) The hwmon drivers would have to be converted from platform
> drivers to superio drivers.
>
> Each approach has its advantages. The first one is rather simple and
> also very generic in nature. It could be reused for other purposes. The
> second one offers automatic loading of hwmon drivers, which would be
> nice to have.
>
> There's probably a middle way which would keep the simplicity of the
> first approach while still allowing for driver auto-loading, without
> changing the bus type of all drivers. It would probably take some
> research though.
I haven't done the research, but it might be keep superio as
a platform driver, and keep the clients as platform drivers. Only
have the superio driver probe and discover the subcomponent
addresses and then create the platform devices as children
instead of having each driver create its own platform device.
(This all assumes they are all platform devices in sysfs, I have
not looked).
This is all because in the platform bus the bus driver does not
discover the addresses but relies on drivers or platform setup code.
> Me, I don't really care which path we choose, given that I am not the
> one who will take care of it. All I have to say is that this has been
> discussed several times over the past 2 years and nothing came out of
> it (as far as the mainline kernel is concerned, at least) so whatever
> is done now, what really matters is that it makes it into the kernel
> quickly. We have some drivers missing features because of this (for
> example real-time reading of VID pin values.)
>
> This should also not prevent us from fixing the drivers now so that
> they temporarily request the Super-I/O ports they are using, as Milton
> suggested. Not only we don't know when we will have something better to
> offer, but it might also help us find conflicts between drivers, so
> that we know which drivers should make use of the future superio
> driver. This could also reveal conflicts with PNP BIOS reservations,
> etc. Milton, will you write a patch?
Well, that is the second time you asked me, so I guess I should respond.
While I it is possible for me to write this patch, my schedule and
priority list predict it would not be before the merge window closes.
In
fact, I'm not sure when it would come out. It might be argued it could
go in early -rc, but I would fear somebody's chip will not be detected
with the additional check. For example, the port may reserved as mother
board resources or something. Also, I have no hardware to test any
proposed patch, so it would be compile check only.
milton
^ permalink raw reply
* Re: [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely @ 2008-07-14 17:11 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080714141606.GA22478@polina.dev.rtsoft.ru>
On Mon, Jul 14, 2008 at 8:16 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
>> --- /dev/null
>> +++ b/sound/soc/soc-of.c
>
> It's quite inconvenient to spread the firmware-specific bits over the
> whole kernel source tree. So, can we place this in driver/of/, just as
> we did for i2c, spi and gpio?
This isn't any more specific than say how device drivers are specific
for particular devices. This is an ASoC machine driver and should
live with all the other ASoC machine drivers.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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-14 17:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <fa686aa40807141006k402b6a5fq8da1424081a20011@mail.gmail.com>
On Mon, Jul 14, 2008 at 11:06:34AM -0600, Grant Likely wrote:
> I'm okay with that. How about fsl/mpc5200-of-machine.c for now?
> (only the mpc5200 i2s driver uses it at the moment). It can always be
> renamed if other folks want to use it for other chips.
That seems reasonable so long as you're happy with it, though it does
seem to be going to the other extreme in terms of broadness :)
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely @ 2008-07-14 17:21 UTC (permalink / raw)
To: Timur Tabi, Jon Smirl, Grant Likely, linuxppc-dev, alsa-devel,
liam.girdwood
In-Reply-To: <20080714165302.GG25448@sirena.org.uk>
On Mon, Jul 14, 2008 at 10:53 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Jul 14, 2008 at 11:14:41AM -0500, Timur Tabi wrote:
>> Mark Brown wrote:
>
>> > I'm finding it difficult to square these two statements - from an ASoC
>> > point of view the main thing this patch is doing is adding a machine
>> > driver and that's not something that's going to go away.
>
>> Jon's concern is that there is no straightforward way to build a kernel with
>> multiple fabric drivers and have the right one chosen via the device tree. This
>> is just a limitation of the device tree model, and no one has come up with a
>> good solution yet.
>
> Indeed - I understand what the problem you guys have is, I just want to
> make sure that there is a reasonable consensus among the PowerPC people
> that this approach is OK to go in and won't create ructions. The lack
> of resolution on this issue makes me nervous about any proposed solution
> where I haven't seen any explicit indication that the community is OK
> with it.
>
> Incidentally, nobody ever really commented on my suggestion to do
> something DMI-like
I'm feeling stupid; what does "DMI" stand for?
> - you've already got the board type information
> present in the device trees (in the model and compatible information in
> the root nodes), all that's needed is an API to allow matching on it.
Yes, we have APIs for matching against device trees. Personally, I'm
leaning towards having the powerpc platform code
(arch/powerpc/platforms/* stuff; not ASoC platform stuff) register a
platform device for the machine driver and let as many machine drivers
as needed be written. Hopefully we'll be able to do at least one
generic machine driver that will be usable by most PowerPC boards, but
I don't think it is a requirement or even realistic to shoehorn all
powerpc sound circuits into a single driver.
>> The problem still exists in ASoC V2. However, it's not anything that ASoC
>> itself needs to be concerned with. It's purely a PowerPC problem.
>
> Right, I just want to be clear that you guys all understand what this
> code does and that there won't be too many complaints after the fact.
Shouldn't be. I'm certainly not pushing this as the end-all be-all
powerpc sound machine driver.
>> > ASoC has always called it a machine driver.
>
>> Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, it
>> should be called a fabric driver because we already have machine drivers.
>
> I don't mind - you can call it what you like inside PowerPC-specific
> code.
Oh help! Don't tell us that! Otherwise we'll always be talking
across purposes. When ambiguous, let's just be sure to always refer
to them as "ASoC machine drivers". :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely @ 2008-07-14 17:22 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, alsa-devel, liam.girdwood, jonsmirl
In-Reply-To: <20080714171632.GH25448@sirena.org.uk>
On Mon, Jul 14, 2008 at 11:16 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Jul 14, 2008 at 11:06:34AM -0600, Grant Likely wrote:
>
>> I'm okay with that. How about fsl/mpc5200-of-machine.c for now?
>> (only the mpc5200 i2s driver uses it at the moment). It can always be
>> renamed if other folks want to use it for other chips.
>
> That seems reasonable so long as you're happy with it, though it does
> seem to be going to the other extreme in terms of broadness :)
heh; I don't care. This stuff is all going to be in flux anyway, so
change is inevitable whatever is chosen now. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Hans de Goede @ 2008-07-14 17:30 UTC (permalink / raw)
To: Milton Miller
Cc: Jean Delvare, linuxppc-dev, Samuel Ortiz, linux-kernel,
lm-sensors
In-Reply-To: <88f5162604470179b3c6ebfe729a46f5@bga.com>
Milton Miller wrote:
> On Jul 14, 2008, at 2:59 AM, Jean Delvare wrote:
>> On Sun, 13 Jul 2008 15:26:56 -0600, David Hubbard wrote:
>>> Hi Hans,
>>>
>>>>> I propose writing a subsystem driver. (Is that properly called "The
>>>>> SuperIO Bus Driver"?) If no one thinks it's a really bad idea I will
>>>>> put together some code and submit it for review, and maintain it.
>>>>>
>>>>> Some hwmon chips have odd / unique probe sequences. IMHO this is
>>>>> where
>>>>> the design needs to be inspected. One of those is the w83627ehf,
>>>>> which
>>>>> Jean and Hans are familiar enough with to check my work.
>>>>>
>>>>> Thoughts?
>>>> I'm afraid that making this a "bus" will be a bit overkill. Jim's
>>>> patches
>>>> are quite simple and seem todo the job.
>>>>
>>>> Also keep in mind that most users will be platform devices which
>>>> just want
>>>> to use the superio registers to find out the baseaddress of their
>>>> logical
>>>> device, a whole bus seems overkill for this, would the hwmon driver
>>>> then
>>>> need to be a superio_driver (as well as an platform_driver) or can
>>>> the bus
>>>> be queried / used
>>>> without having to be a bustype-driver?
>>> I think that's a valid point. I am willing to keep it small, but I
>>> would prefer to follow the pattern set in other subsystems. It may be
>>> my lack of experience in designing a subsystem showing here! What are
>>> some alternative ways to implement it?
>>>
>>> In other words, Jim's patches are a good start, but maybe I am
>>> misunderstanding them. I see it as the superio-locks module, a driver
>>> that other drivers would depend on / auto-load. Is that something
>>> other subsystems also do?
>> Well, there are two approaches to the problem. The first approach
>> (which I think Jim took in his patches? I don't really remember) is to
>> simply solve the problem of concurrent I/O access to the Super-I/O
>> configuration ports (typically 0x2e/0x2f or 0x4e/0x4f). That would be a
>> simple driver requesting the ports in question and exporting an API for
>> other drivers to access them in a safe way.
>>
>> The second approach is to make it a whole subsystem, as David is
>> suggesting. The Super-I/O driver would then not only request the I/O
>> ports, it would also identify which Super-I/O is there, and it would
>> create devices (in the Linux device driver model sense of the term) for
>> every logical device we are interested in (amongst which the hwmon
>> ones.) The hwmon drivers would have to be converted from platform
>> drivers to superio drivers.
>>
>> Each approach has its advantages. The first one is rather simple and
>> also very generic in nature. It could be reused for other purposes. The
>> second one offers automatic loading of hwmon drivers, which would be
>> nice to have.
>>
>> There's probably a middle way which would keep the simplicity of the
>> first approach while still allowing for driver auto-loading, without
>> changing the bus type of all drivers. It would probably take some
>> research though.
>
> I haven't done the research, but it might be keep superio as
> a platform driver, and keep the clients as platform drivers. Only
> have the superio driver probe and discover the subcomponent
> addresses and then create the platform devices as children
> instead of having each driver create its own platform device.
> (This all assumes they are all platform devices in sysfs, I have
> not looked).
>
> This is all because in the platform bus the bus driver does not
> discover the addresses but relies on drivers or platform setup code.
>
This sounds like a good plan, rather then add a new bus type add a superio
platform driver which does superio probing and registering of platform devices
for discovered logical devices.
This superio platform driver then needs to also export some functions of those
few logical devices which need access to the superio registers for more then
just finding out their own base address.
I guess that it then would be best to load this superio driver by default on
most systems.
How does this all mix and match with isapnp, it feels to me we're doing
somewhat the same as isapnp here.
Regards,
Hans
^ permalink raw reply
* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Timur Tabi @ 2008-07-14 17:21 UTC (permalink / raw)
To: Srinivasa D S; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200807141401.26917.srinivasa@in.ibm.com>
Srinivasa D S wrote:
> +#define task_pt_regs(tsk) (tsk)->thread.regs
Shouldn't this be:
#define task_pt_regs(tsk) ((tsk)->thread.regs)
just to be safe?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Andreas Schwab @ 2008-07-14 17:36 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Srinivasa D S, Paul Mackerras
In-Reply-To: <487B8B22.6050701@freescale.com>
Timur Tabi <timur@freescale.com> writes:
> Srinivasa D S wrote:
>
>> +#define task_pt_regs(tsk) (tsk)->thread.regs
>
> Shouldn't this be:
>
> #define task_pt_regs(tsk) ((tsk)->thread.regs)
>
> just to be safe?
Both -> and . have already highest precedence as postfix operators.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] of: i2c: improve last resort compatible entry selection
From: Anton Vorontsov @ 2008-07-14 17:54 UTC (permalink / raw)
To: linuxppc-dev
Currently of_i2c will select first compatible property as a last resort
option. This isn't best choice though, because generic compatible entries
are listed last, not first. For example, two compatible entries given for
the MCU node:
"fsl,mc9s08qg8-mpc837xrdb", "fsl,mcu-mpc8349emitx";
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.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Other options are: start filling the exceptions list, or add "linux,..."
compatible entry to the device tree.
drivers/of/of_i2c.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..0d35a0a 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -29,6 +29,7 @@ static int of_find_i2c_driver(struct device_node *node,
int i, cplen;
const char *compatible;
const char *p;
+ const char *last_wcomma = NULL;
/* 1. search for exception list entry */
for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
@@ -45,7 +46,7 @@ static int of_find_i2c_driver(struct device_node *node,
if (!compatible)
return -ENODEV;
- /* 2. search for linux,<i2c-type> entry */
+ /* 2. search for linux,<i2c-type> entry, or remember last w/ comma */
p = compatible;
while (cplen > 0) {
if (!strncmp(p, "linux,", 6)) {
@@ -54,6 +55,12 @@ static int of_find_i2c_driver(struct device_node *node,
I2C_NAME_SIZE) >= I2C_NAME_SIZE)
return -ENOMEM;
return 0;
+ } else {
+ const char *comma;
+
+ comma = strchr(p, ',');
+ if (comma)
+ last_wcomma = comma + 1;
}
i = strlen(p) + 1;
@@ -61,12 +68,10 @@ static int of_find_i2c_driver(struct device_node *node,
cplen -= i;
}
- /* 3. take fist compatible entry and strip manufacturer */
- p = strchr(compatible, ',');
- if (!p)
+ /* 3. take last compatible entry w/ comma, manufacturer stripped */
+ if (!last_wcomma)
return -ENODEV;
- p++;
- if (strlcpy(info->type, p, I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ if (strlcpy(info->type, last_wcomma, I2C_NAME_SIZE) >= I2C_NAME_SIZE)
return -ENOMEM;
return 0;
}
--
1.5.5.4
^ permalink raw reply related
* Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: David Hubbard @ 2008-07-14 17:55 UTC (permalink / raw)
To: Hans de Goede
Cc: linuxppc-dev, Samuel Ortiz, linux-kernel, Milton Miller,
lm-sensors
In-Reply-To: <487B8D2C.1090208@hhs.nl>
Hi Hans,
On Mon, Jul 14, 2008 at 11:30 AM, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Milton Miller wrote:
>> I haven't done the research, but it might be keep superio as
>> a platform driver, and keep the clients as platform drivers. Only
>> have the superio driver probe and discover the subcomponent
>> addresses and then create the platform devices as children
>> instead of having each driver create its own platform device.
>> (This all assumes they are all platform devices in sysfs, I have
>> not looked).
>>
>> This is all because in the platform bus the bus driver does not
>> discover the addresses but relies on drivers or platform setup code.
>>
>
> This sounds like a good plan, rather then add a new bus type add a superio
> platform driver which does superio probing and registering of platform devices
> for discovered logical devices.
>
> This superio platform driver then needs to also export some functions of those
> few logical devices which need access to the superio registers for more then
> just finding out their own base address.
>
> I guess that it then would be best to load this superio driver by default on
> most systems.
>
> How does this all mix and match with isapnp, it feels to me we're doing
> somewhat the same as isapnp here.
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.
A superio platform driver is a good way to go -- it fits with the way
the platform bus does things. Also, Jim's patches are almost there
already.
Thanks,
David
^ 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-14 18:36 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Timur Tabi, liam.girdwood
In-Reply-To: <fa686aa40807141021ka4f84e9ycc4ac78db760726c@mail.gmail.com>
On Mon, Jul 14, 2008 at 11:21:12AM -0600, Grant Likely wrote:
> On Mon, Jul 14, 2008 at 10:53 AM, Mark Brown
> > Incidentally, nobody ever really commented on my suggestion to do
> > something DMI-like
> I'm feeling stupid; what does "DMI" stand for?
Desktop Management Interface, a standard BIOS interface for getting
system data on x86 class hardware. Of particular interest here is the
fact that it contains various ID strings for things like motherboard and
chassis - on Linux drivers can be automatically loaded based on these
strings. See drivers/misc/thinkpad_acpi.c for an example of a driver
that does this.
Note that it's *not* binding a driver, it just provides the hooks to
enable the modules to be automatically loaded and to let drivers query
information in DMI.
> Yes, we have APIs for matching against device trees. Personally, I'm
> leaning towards having the powerpc platform code
> (arch/powerpc/platforms/* stuff; not ASoC platform stuff) register a
> platform device for the machine driver and let as many machine drivers
> as needed be written. Hopefully we'll be able to do at least one
That would be what I'd expected initially - it is, after all, what other
platforms are doing here.
> generic machine driver that will be usable by most PowerPC boards, but
> I don't think it is a requirement or even realistic to shoehorn all
> powerpc sound circuits into a single driver.
Yes, that'd be completely unrealistic.
> > I don't mind - you can call it what you like inside PowerPC-specific
> > code.
> Oh help! Don't tell us that! Otherwise we'll always be talking
> across purposes. When ambiguous, let's just be sure to always refer
> to them as "ASoC machine drivers". :-)
Feh, from now on I shall me naming all new concepts with pwgen :) .
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Timur Tabi @ 2008-07-14 18:40 UTC (permalink / raw)
To: Grant Likely, Timur Tabi, Jon Smirl, linuxppc-dev, alsa-devel,
liam.girdwood
In-Reply-To: <20080714183632.GI25448@sirena.org.uk>
Mark Brown wrote:
> Desktop Management Interface, a standard BIOS interface for getting
> system data on x86 class hardware. Of particular interest here is the
> fact that it contains various ID strings for things like motherboard and
> chassis - on Linux drivers can be automatically loaded based on these
> strings. See drivers/misc/thinkpad_acpi.c for an example of a driver
> that does this.
The only problem with this is that the OF probing code in the kernel binds
drivers to device tree nodes. So when a driver claims a node, no other driver
will be probed with it.
So we can't have generic nodes that classify the motherboard and just let
everyone get probed on it.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: dtc: Testcase for /include/ directive
From: Jon Loeliger @ 2008-07-14 18:49 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080624012144.GB1236@yookeroo.seuss>
> This patch adds a testcase for the /include/ directive. It assembles
> a sample dts file with many /include/ directives at a variety of
> different lexical / grammatical contexts.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ 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-14 18:49 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <487B9D98.8010008@freescale.com>
On Mon, Jul 14, 2008 at 01:40:24PM -0500, Timur Tabi wrote:
> Mark Brown wrote:
> > Desktop Management Interface, a standard BIOS interface for getting
> > system data on x86 class hardware. Of particular interest here is the
> > fact that it contains various ID strings for things like motherboard and
> > chassis - on Linux drivers can be automatically loaded based on these
> > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver
> > that does this.
> The only problem with this is that the OF probing code in the kernel binds
> drivers to device tree nodes. So when a driver claims a node, no other driver
> will be probed with it.
> So we can't have generic nodes that classify the motherboard and just let
> everyone get probed on it.
My suggestion is that you change this for the root node. It's already
got the information required in there, it's just there's no way to use
it to load modules at the minute. You could presumably read the
information out of the device tree using existing APIs to check you're
running on the right board once code is loaded?
^ permalink raw reply
* Re: dtc: Use stdint.h types throughout dtc
From: Jon Loeliger @ 2008-07-14 18:49 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080625035307.GB8284@yookeroo.seuss>
> Currently, dtc defines Linux-like names for various fixed-size integer
> types. There's no good reason to do this; even Linux itself doesn't
> use these names for externally visible things any more. This patch
> replaces these with the C99 standardized type names from stdint.h.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ 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