is
in of_mdio.c and individual drivers call it. And there are a lot more
of these (9) than i2c drivers (3).
So I would let individual drivers call of_i2c_register_devices(), as it
used to be until 2.6.35. 2 extra functions calls doesn't seem a high
price to pay to keep the code logically se
r < __i2c_first_dynamic_bus_num)
> i2c_scan_static_board_info(adap);
>
> - /* Register devices from the device tree */
> - of_i2c_register_devices(adap);
> -
> /* Notify drivers */
> mutex_lock(&core_lock);
> bus_for_each_drv(&i2c_bus_type, NULL, adap, __process_new_adapter);
>
I've applied this variant, thanks.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
The ams driver isn't a hardware monitoring driver, so it shouldn't
live under driver/hwmon. drivers/macintosh seems much more
appropriate, as the driver is only useful on PowerBooks and iBooks.
Signed-off-by: Jean Delvare
Cc: Guenter Roeck
Cc: Stelian Pop
Cc: Michael Hanselmann
Cc
Hi Benjamin,
On Tue, 16 Nov 2010 15:33:25 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2010-10-05 at 12:10 +0200, Jean Delvare wrote:
> > The ams driver isn't a hardware monitoring driver, so it shouldn't
> > live under driver/hwmon. drivers/macintosh seems much mor
f_dev) {
device_remove_file(&of_dev->dev, &dev_attr_sensor1_temperature);
@@ -673,9 +682,14 @@ thermostat_exit(void)
device_remove_file(&of_dev->dev,
&dev_attr_sensor2_fan_speed);
- of_device_unregi
der initialization to better support device tree data
>
> drivers/gpio/pca953x.c | 168
> +---
> 1 files changed, 88 insertions(+), 80 deletions(-)
This is totally off-topic for the lm-sensors mailing list, sorry.
--
Jean Delvare
Ben, Christian,
On Thu, 7 Jan 2010 17:17:38 +0100, Jean Delvare wrote:
> On Wed, 6 Jan 2010 19:41:05 -0800 (PST), Christian Kujau wrote:
> > Hi Jean,
> >
> > On Wed, 6 Jan 2010 at 17:37, Jean Delvare wrote:
> > > I think that sysfs files creation
nt to go through my tree :-)
>
> Hopefully they should still be referened on patchwork, I'll dig there
> and pick them up.
Well, basically I pick patches that touch drivers/i2c/*, and I don't
pick patches that touch drivers/macintosh/*. When I can't build the
drivers, I don't r
es with proper comments and headers now.
> Thanks for the fixes, Jean!
You're welcome.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ave a lifetime longer than the data structure that is
backing it up.
I think that sysfs files creation should be moved to the end of
probe_thermostat() and sysfs files removal should be moved to the
beginning of remove_thermostat().
Signed-off-by: Jean Delvare
Tested-by: Christian Kujau
Cc: Ben
enough
with the ams driver code to tell for sure.
Signed-off-by: Jean Delvare
Tested-by: Christian Kujau
Cc: Benjamin Herrenschmidt
Cc: Stelian Pop
Cc: Michael Hanselmann
Cc: sta...@kernel.org
---
Christian tested the I2C variant of the chip, it would be nice if
someone could test the
the pieces they really have to
see and ack to each person, and provide a pointer to somewhere the full
series can be seen and downloaded for the interested.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
s there is no gpio
tree and no maintainer either AFAIK, I guess I shall pick it too?
Thanks,
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Mon, 28 Sep 2009 09:30:32 +0200, Joakim Tjernlund wrote:
> Jean Delvare wrote on 28/09/2009 09:28:09:
> >
> > On Mon, 28 Sep 2009 00:26:54 +0200, Joakim Tjernlund wrote:
> > > Jean, I just noticed you pull request for i2c on LKML but I didn't see
> > &g
ot, pay any attention to it.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
If i2c device probing fails, then there is no driver to dereference
after calling i2c_new_device(). Stop assuming that probing will always
succeed, to avoid NULL pointer dereferences. We have an easier access
to the driver anyway.
Signed-off-by: Jean Delvare
Tested-by: Tim Shepard
Cc: Colin
If i2c device probing fails, then there is no driver to dereference
after calling i2c_new_device(). Stop assuming that probing will always
succeed, to avoid NULL pointer dereferences. We have an easier access
to the driver anyway.
Reported-by: Tim Shepard
Signed-off-by: Jean Delvare
Cc
Hi Takashi,
Thanks for the swift reply.
On Wed, 30 Sep 2009 16:13:49 +0200, Takashi Iwai wrote:
> At Wed, 30 Sep 2009 15:25:42 +0200,
> Jean Delvare wrote:
> >
> > If i2c device probing fails, then there is no driver to dereference
> > after calling i2c_new_device(). St
On Wed, 30 Sep 2009 17:05:11 +0200, Johannes Berg wrote:
> On Wed, 2009-09-30 at 17:00 +0200, Jean Delvare wrote:
>
> > The NULL check of client->driver, if followed by a call to
> > i2c_unregister_device(), would indeed be enough. But unlike the onyx
> > driver whic
on driver removal.
This looks good to me. Please add the following comment before the
client->driver check in both drivers:
/*
* We know the driver is already loaded, so the device should be
* already bound. If not it me
the short transaction. Anyone wishing to issue multi-message
transactions should use the SMBus API instead of the raw I2C API.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
drivers/i2c/busses/i2c-powermac.c |6 ++
1 file changed, 6 insertions(+)
--- linux-2.6.3
Hi Takashi,
On Thu, 01 Oct 2009 08:52:59 +0200, Takashi Iwai wrote:
> At Wed, 30 Sep 2009 18:55:05 +0200,
> Jean Delvare wrote:
> >
> > On Wed, 30 Sep 2009 17:15:49 +0200, Takashi Iwai wrote:
> > > Yes, indeed I prefer NULL check because the user can know the error
&
at the problem can be and/or how to debug it further?
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, 13 Oct 2009 20:32:28 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2009-10-13 at 11:23 +0200, Jean Delvare wrote:
> > Hi Ben, Paul,
> >
> > I had a report by Tim Shepard (Cc'd) that the therm_adt746x driver
> > sometimes fails to initialize on his PowerB
The ADT746x don't have any register at sub-address 0, so better use an
existing register for the initial test read.
Signed-off-by: Jean Delvare
Cc: Colin Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
Tim, I don't really expect this to solve your problem, but who knows.
Hi all,
On Tue, 13 Oct 2009 11:49:48 +0200, Jean Delvare wrote:
> I2C bus being setup too fast sounds more likely. It might be worth
> adding an arbitrary delay after initialization, just to see if it
> helps. Not sure where though, as I'm not familiar with the Powermac
> ini
On Thu, 15 Oct 2009 08:26:15 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-14 at 23:02 +0200, Jean Delvare wrote:
> > Hi all,
> >
> > On Tue, 13 Oct 2009 11:49:48 +0200, Jean Delvare wrote:
> > > I2C bus being setup too fast sounds more likely. It might be w
On Thu, 15 Oct 2009 22:19:19 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-10-15 at 12:49 +0200, Jean Delvare wrote:
> > Oh. Well, if that was the case, we would see errors all the time, not
> > just during initialization, right? Or does the I2C clock frequency
> > cha
On Thu, 15 Oct 2009 16:05:13 +0200, Jean Delvare wrote:
> On Thu, 15 Oct 2009 22:19:19 +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-10-15 at 12:49 +0200, Jean Delvare wrote:
> > > Oh. Well, if that was the case, we would see errors all the time, not
> > > just d
e extra call to
of_i2c_register_devices(), then maybe the of_i2c implementation is
incorrect, and you should rework it to build on top of
i2c_register_board_info() rather than i2c_new_device().
> -reverse the order and leave i2c device registration broken for 1
> commit. Thinking some more abou
PROTECTED]
> +L: linuxppc-dev@ozlabs.org
> +L: [EMAIL PROTECTED]
> +S: Maintained
> +
> FREESCALE DMA DRIVER
> P: Li Yang
> M: [EMAIL PROTECTED]
Applied, thanks.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ly EEPROMs such as SPD or EDID
can be found on the i2c-ibm_iic adapters?
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
an be hot-plugged.
> >
> > That's how it used to work by default. It was decided to drop that and
> > enforce an index. The following is a quote from Jean Delvare from a
>
> I added Jean to CC now.
>
> > post from 8/2/16 4:31:
> > > I don'
Hi Ben,
On Fri, 06 Jun 2008 14:16:23 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2008-06-05 at 09:48 +0200, Jean Delvare wrote:
> > As far as I am concerned, it's really up to the maintainers and users
> > of this platform. All I am asking for is
e = "ibm,iic-405ex", },
> - { .compatible = "ibm,iic-405gp", },
> - { .compatible = "ibm,iic-440gp", },
> - { .compatible = "ibm,iic-440gpx", },
> - { .compatible = "ibm,iic-440grx", },
> + { .compatible = "ibm,iic&q
same patch.
Also, it would be a good idea to keep Jochen Friedrich in the loop
(Cc'd), as he proposed a similar patch based on a previous version of
yours back in April. I suppose he has some interest in it.
While mentioning Jochen's version o
= {
> + .match_table= mpc_i2c_of_match,
> + .probe = fsl_i2c_probe,
> + .remove = __devexit_p(fsl_i2c_remove),
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = DRV_NAME,
> },
> };
>
> s
Hi Jon, Grant,
On Sat, 28 Jun 2008 22:49:40 -0600, Grant Likely wrote:
> On Sat, Jun 28, 2008 at 10:05:28PM -0400, Jon Smirl wrote:
> > On 6/25/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > > >
> > > > i2c->adap = mpc_o
On Sun, 29 Jun 2008 00:58:12 -0600, Grant Likely wrote:
> On Sun, Jun 29, 2008 at 08:31:43AM +0200, Jean Delvare wrote:
> > Hi Jon, Grant,
> >
> > On Sat, 28 Jun 2008 22:49:40 -0600, Grant Likely wrote:
> > > On Sat, Jun 28, 2008 at 10:05:28PM -0400, Jon Smirl
On Sun, 29 Jun 2008 12:24:39 -0400, Sean MacLennan wrote:
> On Sun, 29 Jun 2008 09:17:25 +0200
> "Jean Delvare" <[EMAIL PROTECTED]> wrote:
>
> > Ah, OK. If you use i2c_new_device() then it's alright.
>
> Correct.
>
> I have done the same thing f
void of_register_i2c_devices(struct i2c_adapter *adap,
>struct device_node *adap_node);
> +struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
> +
>
> #endif /* __LINUX_OF_I2C_H */
I'm fine with this patc
2c);
> return 0;
> };
>
> -/* work with hotplug and coldplug */
> -MODULE_ALIAS("platform:fsl-i2c");
> +static const struct of_device_id mpc_i2c_of_match[] = {
> + {.compatible = "fsl-i2c",},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
> +
>
> /* Structure for a device driver */
> -static struct platform_driver fsl_i2c_driver = {
> - .probe = fsl_i2c_probe,
> - .remove = fsl_i2c_remove,
> - .driver = {
> - .owner = THIS_MODULE,
> - .name = "fsl-i2c",
> +static struct of_platform_driver mpc_i2c_driver = {
> + .match_table= mpc_i2c_of_match,
> + .probe = fsl_i2c_probe,
> + .remove = __devexit_p(fsl_i2c_remove),
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = DRV_NAME,
> },
> };
>
> static int __init fsl_i2c_init(void)
> {
> - return platform_driver_register(&fsl_i2c_driver);
> + int rv;
> +
> + rv = of_register_platform_driver(&mpc_i2c_driver);
> + if (rv)
> + printk(KERN_ERR DRV_NAME
> +" of_register_platform_driver failed (%i)\n", rv);
> + return rv;
> }
>
> static void __exit fsl_i2c_exit(void)
> {
> - platform_driver_unregister(&fsl_i2c_driver);
> + of_unregister_platform_driver(&mpc_i2c_driver);
> }
>
> module_init(fsl_i2c_init);
Applied, after fixing the patch so that it applies, fixing it again so
that it is correct in the polling case, and fixing it again to make it
pass checkpatch.pl.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
> > It was un-exported only because it had no user left, but it can be
> > export
On Tue, 1 Jul 2008 12:29:29 -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > Hi Jon,
> >
> >
> > On Mon, 30 Jun 2008 19:01:28 -0400, Jon Smirl wrote:
> > > Add the of_find_i2c_device_by_node function. This allows you to
On Tue, 1 Jul 2008 12:38:05 -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote:
> > > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > > > I'm fine with this pat
On Tue, 1 Jul 2008 10:45:18 -0600, Grant Likely wrote:
> On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote:
> > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote:
> > > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > > > I'm fine
x drivers shouldn't have to know whether they are used in
openfirmware trees and what device names are used there. And device
names as seen by user-space shouldn't vary depending on whether the
device comes from an openfirmware tree or not - otherwise all
user-space apps need to learn a
On Tue, 1 Jul 2008 13:06:37 -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > On Tue, 1 Jul 2008 10:45:18 -0600, Grant Likely wrote:
> > > But the other side of the coin is that each driver must have
> > > driver-specific OF cod
On Tue, 1 Jul 2008 13:27:57 -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote:
> > > On 7/1/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> >
> > > > My preference is
On Wed, 2 Jul 2008 15:33:43 +0200, Wolfram Sang wrote:
> Hi Jean,
>
> On Tue, Jul 01, 2008 at 06:14:44PM +0200, Jean Delvare wrote:
>
> > Applied, after fixing the patch so that it applies, fixing it again so
> > that it is correct in the polling case, and fixing it a
ne of the Freescale folks, but on a second reading
> I think it is pretty safe. I'll make sure any merge conflicts are
> resolved.
>
> Jean, is it okay with you to drop it from your tree and merge it through mine?
Sure, no problem. It's done now, the patch is yours.
--
Jea
np);
> +
> dev_info(&ofdev->dev, "using %s mode\n",
>dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
>
Looks OK. As I already have patches touching
drivers/i2c/busses/i2c-ibm_iic.c in my tree, I'm taking this patch
also. I will push it upstream during the 2.6.27 merge window.
Thanks,
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
agree that the hwmon drivers should do this, as long as no superio
subsystem exist. This should solve the problem at hand and might even
help spot bad drivers which use the configuration space for longer than
initialization time.
> Besides, one could argue the superio region should be requested while
On Fri, 11 Jul 2008 09:27:26 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > Hi Hans, hi Milton,
> >
>
>
>
> >> One could make a superio driver, and create sub-devices for the IR,
> >> I2C, floppy, parallel, etc
> >> nodes.
> >
quest 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?
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi Milton,
On Mon, 14 Jul 2008 12:09:03 -0500, Milton Miller wrote:
> On Jul 14, 2008, at 2:59 AM, Jean Delvare wrote:
> > 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
> > s
ip 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.
>
e 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ll media drivers will take a lot of time because of the
history behind these drivers.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi David,
On Tue, 15 Jul 2008 09:31:29 -0600, David Hubbard wrote:
> On Tue, Jul 15, 2008 at 2:36 AM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > 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
Hi Wolfgang,
On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > For hwmon chips, probing only occurs if the i2c adapter accepts to be
> > probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
> > you do not want a given
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > The problem is that at this point in time, only a couple hwmon drivers
> > have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> > would break most systems.
> >
_DFSRR 0x0001
> #define FSL_I2C_DEV_CLOCK_5200 0x0002
> +#define FSL_I2C_DEV_PROBE0x0004
>
> enum fsl_usb2_operating_modes {
> FSL_USB2_MPH_HOST,
As a side note: in general it is not a good idea to use a template for
struct i2c_adapter. This structure is relatively large compared to the
few fields you need to set. If you insist on having a template, it
should at least be marked either const or __initdata.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
> On 7/16/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
> > > On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> > > > Jean Del
.class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> >.timeout = 1,
> > };
Unless you intend to push this patch upstream yourself (through the ppc
tree), you should send it to Ben Dooks (who is in charge of this part
of the i2c subsystem) with Cc to the i2c list.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
nges. Thus it might make sense to
push these through their respective arch trees, rather than the i2c
tree.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
_H
> #define __SOUNDBUS_H
>
> -#include
> +#include
> #include
> #include
>
No objection from me, go ahead.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -379,7 +379,7 @@ struct virtio_device_id {
>
> /* i2c */
>
> -#define I2C_NAME_SIZE20
> +#define I2C_NAME_SIZE23
> #define I2C_MODULE_PREFIX "i2c:"
>
> struct i2c_device_
; > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> > ---
> > drivers/of/base.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Any issues with this or the second patch? Can we merge them?
I do not have the time to review
= &cpm_i2c_algo,
> - .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> };
>
> static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm)
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
I guess you do _not_ want me to push this patch upstream now and it
better goes thr
ored in i2c_client.irq
> *
> * I2C doesn't actually support hardware probing, although controllers and
> @@ -259,6 +260,7 @@ struct i2c_board_info {
> unsigned short flags;
> unsigned short addr;
> void*platform_data;
> + struct dev_arc
On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote:
> > Hi Anton,
> >
> > On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote:
> > > If present the info->archdata is copied i
On Wed, 22 Oct 2008 14:08:13 +0400, Anton Vorontsov wrote:
> On Wed, Oct 22, 2008 at 06:37:55PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote:
> > > On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote:
> > >
Hi Anton,
On Sun, 11 Jan 2009 19:51:36 +0300, Anton Vorontsov wrote:
> This patch is used to help Jean Delvare to get rid of drivers/i2c/chips/
> directory. The new location suggested by Kumar Gala: as the driver is
> 83xx specific it's placed into arch/powerpc/platforms/83xx/.
>
On Sun, 11 Jan 2009 20:24:10 +0300, Anton Vorontsov wrote:
> On Sun, Jan 11, 2009 at 06:10:55PM +0100, Jean Delvare wrote:
> > Hi Anton,
> >
> > On Sun, 11 Jan 2009 19:51:36 +0300, Anton Vorontsov wrote:
> > > This patch is used to help Jean Delvare t
On Tue, 13 Jan 2009 08:39:37 -0600, Kumar Gala wrote:
>
> On Jan 11, 2009, at 10:55 AM, Anton Vorontsov wrote:
>
> > This patch is used to help Jean Delvare to get rid of drivers/i2c/
> > chips/
> > directory. The new location suggested by Kumar Gala: as the drive
; : "standard (100 kHz)");
>
> + /* Now register all the child nodes */
> + of_register_i2c_devices(adap, np);
> +
> return 0;
>
> error_cleanup:
Indeed.
Acked-by: Jean Delvare
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi Ben,
On Wed, 04 Feb 2009 14:55:33 +1100, Benjamin Herrenschmidt wrote:
>
> > Acked-by: Jean Delvare
>
> Jean, you'll take that in your tree or should I take it in mine ?
No, I'm not taking it, i2c-ibm_iic is under Ben Dooks' jurisdiction. So
it's up to e
> Could you pick up this patch for 2.6.30?
No, that's something for either Ben Dooks (Cc'd) or the powerpc tree.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Tue, 10 Feb 2009 10:01:54 -0600, Timur Tabi wrote:
> Jean Delvare wrote:
>
> > No, that's something for either Ben Dooks (Cc'd) or the powerpc tree.
>
> This patch has nothing to do with ARM, so Kumar will pick it up, if you
> ACK it.
Why are you mentionin
ould
appreciate clarifications about this.
Thanks.
* * * * *
The legacy i2c binding model is going away soon, so convert the AOA
codec drivers to the new model or they'll break.
Signed-off-by: Jean Delvare
Cc: Johannes Berg
Cc: Benjamin Herrenschmidt
---
drivers/i2c/busses/i
; * aoa_codec_* is the module name, I see no reason to use that as the
>i2c name, that should be the codec's name instead (aka pcm3052 etc)
The names are totally arbitrary and we can change them if you like.
Keep in mind though that we should avoid using mere chip names for
non-generic drivers. The aoa drivers are powermac-specific, we don't
want the names we pick to collide with another driver, that's why I
chose to keep the aoa prefix.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
auto-load the aoa codec modules based on this anyway.
My new approach doesn't auto-load anything. Here we go, what you think?
This time there is no logic change, I'm really only turning legacy code
into new-style i2c code (basically calling i2c_new_device() instead of
i2c_attach_client
atic const struct i2c_device_id onyx_i2c_id[] = {
> > + { "aoa_codec_onyx", 0 },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, onyx_i2c_id);
>
> Should it really export the device table?
>
> (same comments for tas)
No, that's a leftover, I i
On Thu, 9 Apr 2009 14:19:45 +0200, Jean Delvare wrote:
> From: Jean Delvare
> Subject: AOA: Convert onyx and tas codecs to new-style i2c drivers
>
> The legacy i2c binding model is going away soon, so convert the AOA
> codec drivers to the new model or they'll break.
>
The legacy i2c binding model is going away soon, so convert the ppc
keywest sound driver to the new model or it will break.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
---
sound/ppc/keywest.c | 81 +--
1 file changed, 40 insertions
The i2c_device_name macro doesn't have much value, get rid of it.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
---
sound/ppc/keywest.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
--- linux-2.6.30-rc1.orig/sound/ppc/keywest.c 2009-04-10 16:22:08.0
On Fri, 10 Apr 2009 17:07:26 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the ppc
> keywest sound driver to the new model or it will break.
>
> Signed-off-by: Jean Delvare
> Cc: Benjamin Herrenschmidt
> ---
> sound
: Jean Delvare
Cc: Benjamin Herrenschmidt
---
Can anyone please run-test this patch? I could only build-test it.
drivers/macintosh/therm_pm72.c | 95 +++-
1 file changed, 47 insertions(+), 48 deletions(-)
--- linux-2.6.30-rc1.orig/drivers/macintosh/therm_pm72.c
On Mon, 13 Apr 2009 16:09:27 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the
> macintosh therm_pm72 driver to the new model or it will break.
>
> This is really a quick and dirty conversion, that should do the trick
> for now, bu
Hi Paul,
On Tue, 14 Apr 2009 09:07:35 +1000, Paul Mackerras wrote:
> Jean Delvare writes:
>
> > The legacy i2c binding model is going away soon, so convert the
> > macintosh therm_pm72 driver to the new model or it will break.
> >
> > This is really a quick and di
On Mon, 13 Apr 2009 16:51:00 +0200, Jean Delvare wrote:
> On Mon, 13 Apr 2009 16:09:27 +0200, Jean Delvare wrote:
> > The legacy i2c binding model is going away soon, so convert the
> > macintosh therm_pm72 driver to the new model or it will break.
> >
> > This
On Fri, 10 Apr 2009 17:09:51 +0200, Jean Delvare wrote:
> Ah, I forgot. You need the following patch applied before testing:
> ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-loosen-driver-check.patch
This patch is is Linus' tree now:
http://git.ke
On Fri, 10 Apr 2009 17:02:38 +0200, Jean Delvare wrote:
> On Thu, 9 Apr 2009 14:19:45 +0200, Jean Delvare wrote:
> > From: Jean Delvare
> > Subject: AOA: Convert onyx and tas codecs to new-style i2c drivers
> >
> > The legacy i2c binding model is going away soon, s
the other
patch first:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=935298696f469c0e07c73be687bd055878074ce0
Thanks,
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
0xb4/0x10c
> [ 10.268308] [c001e19a3990] [c037ecec]
> .i2c_register_driver+0xf0/0x128
> [ 10.268315] [c001e19a3a30] [d1291f20] .onyx_init+0x20/0x668
> [snd_aoa_codec_onyx]
> [ 10.268319] [c001e19a3ab0] [c0007f68]
> .do_one_initcall+0x9c/0x1dc
Hi Paul,
On Wed, 15 Apr 2009 14:57:30 +1000, Paul Mackerras wrote:
> Jean Delvare writes:
>
> > The legacy i2c binding model is going away soon,
>
> But not before 2.6.30, right?
Ideally, yes, before 2.6.30. This is what
Documentation/feature-removal
On Wed, 15 Apr 2009 00:48:08 +0200, Andreas Schwab wrote:
> Jean Delvare writes:
>
> > Hi Johannes,
> >
> > On Tue, 14 Apr 2009 19:41:55 +0200, Johannes Berg wrote:
> >> Alright, with the patch Andreas pointed out it loads, but segfaults, as
> >
karound, which I will apply for now, but...
ideally the layout factory should be revisited so that the codec check
happens earlier. Is this something you could help with?
That's something which isn't too clear to me: is there a physical
device at 2-0046 and 3-0046? The onyx codec is accepted for the latter,
however it seems that the test of a device presence at 2-0046 succeeds
as well...
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
The legacy i2c binding model is going away soon, so convert the AOA
codec drivers to the new model or they'll break.
Signed-off-by: Jean Delvare
Cc: Johannes Berg
Cc: Benjamin Herrenschmidt
Tested-by: Andreas Schwab
---
Johannes, this is a reworked patch which assumes that the onyx
1 - 100 of 230 matches
Mail list logo
