On Wed, Oct 22, 2008 at 02:46:06PM +0400, Anton Vorontsov wrote:
[...]
Like what I suggested: chip-aware OF glue drivers. The relevant
bus code being the of_platform_bus_type infrastructure.
Example: instead of Anton's patch #6 modifying the existing pca953x
driver, an
On Tue, Oct 28, 2008 at 11:45 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Wed, Oct 22, 2008 at 02:46:06PM +0400, Anton Vorontsov wrote:
[...]
Like what I suggested: chip-aware OF glue drivers. The relevant
bus code being the of_platform_bus_type infrastructure.
Example:
On Wednesday 22 October 2008, Benjamin Herrenschmidt wrote:
On Wed, 2008-10-22 at 14:04 -0700, David Brownell wrote:
So if we register the board infos after
the controller registered, then nobody will probe the board infos.
See above. If you're doing it right, there's no problem.
On Wednesday 22 October 2008, Anton Vorontsov wrote:
--- a/drivers/gpio/pcf857x.c
+++ b/drivers/gpio/pcf857x.c
@@ -187,7 +187,7 @@ static int pcf857x_probe(struct i2c_client *client,
struct pcf857x *gpio;
int status;
-
On Wed, Oct 22, 2008 at 02:36:41PM +0400, Anton Vorontsov wrote:
On Tue, Oct 21, 2008 at 09:22:48PM -0700, David Brownell wrote:
On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
The notifier can be registered before the devices, though it's a little
bit fishy and fragile.
On Wed, Oct 22, 2008 at 02:46:06PM +0400, Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 02:36:41PM +0400, Anton Vorontsov wrote:
On Tue, Oct 21, 2008 at 09:22:48PM -0700, David Brownell wrote:
On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
The notifier can be registered
On Wednesday 22 October 2008, Anton Vorontsov wrote:
The board info has another problem though. We can't remove it, thus
we can't implement module_exit() for the 'OF glue'.
That's not a problem. Why would you want to remove it?
And try to solve this problem... maybe then things will
On Wed, Oct 22, 2008 at 02:04:52PM -0700, David Brownell wrote:
On Wednesday 22 October 2008, Anton Vorontsov wrote:
The board info has another problem though. We can't remove it, thus
we can't implement module_exit() for the 'OF glue'.
That's not a problem. Why would you want to
On Wednesday 22 October 2008, Anton Vorontsov wrote:
So if we register the board infos after
the controller registered, then nobody will probe the board infos.
See above. If you're doing it right, there's no problem.
That is, scan the OF tables early. Just like PNP tables
get
On Wed, Oct 22, 2008 at 02:52:46PM -0700, David Brownell wrote:
On Wednesday 22 October 2008, Anton Vorontsov wrote:
So if we register the board infos after
the controller registered, then nobody will probe the board infos.
See above. If you're doing it right, there's no
On Wed, 2008-10-22 at 14:04 -0700, David Brownell wrote:
So if we register the board infos after
the controller registered, then nobody will probe the board infos.
See above. If you're doing it right, there's no problem.
That is, scan the OF tables early. Just like PNP tables
get
On Wednesday 22 October 2008, Anton Vorontsov wrote:
So have it live in the __init text section...
Won't work, unfortunately. I2C devices are created by the
i2c controllers, via drivers/of_i2c.c of_register_i2c_devices().
And I'm pointing out a way to have the normal I2C core code
flow
But it doesn't work as a module (i.e. OF-specific bits should be
always in-kernel).
Why not ?
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wed, Oct 22, 2008 at 11:29:20AM +1100, Benjamin Herrenschmidt wrote:
But it doesn't work as a module (i.e. OF-specific bits should be
always in-kernel).
Why not ?
If say X driver loads prior to bus-notifier module (where we fill
the platform data), then X.0 device will try to probe
On Wed, Oct 22, 2008 at 05:03:47AM +0400, Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 11:29:20AM +1100, Benjamin Herrenschmidt wrote:
But it doesn't work as a module (i.e. OF-specific bits should be
always in-kernel).
Why not ?
If say X driver loads prior to bus-notifier
On Wed, 2008-10-22 at 05:03 +0400, Anton Vorontsov wrote:
If say X driver loads prior to bus-notifier module (where we fill
the platform data), then X.0 device will try to probe w/o platform
data and will fail. The only way to re-probe things is to rmmod X
insmod of_pdata_filler_X insmod X.
On Wed, 2008-10-22 at 05:42 +0400, Anton Vorontsov wrote:
Thinking about it more, I started recalling other issues. The bus
notifier chain doesn't replay previous events, so we also have to
register the notifier before the _devices_ are registered. And this
ruins the whole approach. :-/
On Wed, Oct 22, 2008 at 01:28:17PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2008-10-22 at 05:42 +0400, Anton Vorontsov wrote:
Thinking about it more, I started recalling other issues. The bus
notifier chain doesn't replay previous events, so we also have to
register the notifier
On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
The notifier can be registered before the devices, though it's a little
bit fishy and fragile.
Easier I suppose to just have OF specific hooks in the bus code.
Like what I suggested: chip-aware OF glue drivers. The relevant
bus code
On Friday 17 October 2008, Anton Vorontsov wrote:
On Fri, Oct 17, 2008 at 01:24:42PM -0700, David Brownell wrote:
On Thursday 16 October 2008, Anton Vorontsov wrote:
+/*
+ * Platforms can define their own __dev_ versions to glue gpio_chips
with the
+ * architecture-specific code.
On Mon, Oct 20, 2008 at 12:29:57AM -0700, David Brownell wrote:
[...]
Anyway most of them need some modifications to work with OF...
The changes I saw were just to cope with not having
the system-specific platform_data provided: don't
fail if that pointer is NULL, and arrange for dynamic
On Thursday 16 October 2008, Anton Vorontsov wrote:
+/*
+ * Platforms can define their own __dev_ versions to glue gpio_chips with the
+ * architecture-specific code.
+ */
+#ifndef __dev_gpiochip_add
+#define __dev_gpiochip_add __dev_gpiochip_add
+static inline int __dev_gpiochip_add(struct
On Fri, Oct 17, 2008 at 01:24:42PM -0700, David Brownell wrote:
On Thursday 16 October 2008, Anton Vorontsov wrote:
+/*
+ * Platforms can define their own __dev_ versions to glue gpio_chips with
the
+ * architecture-specific code.
+ */
+#ifndef __dev_gpiochip_add
+#define
Any GPIO controller that have a device associated with it is encouraged to
register/unregister the gpiochips with dev_gpiochip_*() calls.
Platform may redefine these calls to glue the gpiochips with the
architecture-specific code.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
24 matches
Mail list logo
