* I2C node in device tree breaks old-style drivers
@ 2008-07-29 19:43 Timur Tabi
2008-07-30 10:54 ` Jochen Friedrich
0 siblings, 1 reply; 3+ messages in thread
From: Timur Tabi @ 2008-07-29 19:43 UTC (permalink / raw)
To: linuxppc-dev, Grant Likely
I'm trying to debug an I2C problem I've found in my old-style driver:
sound/soc/codecs/cs4270.c. My I2C probe function is working, but the I2C
subsystem cannot find my device. I know it's there, because U-Boot can probe it
just fine.
At first, I thought my problem was this:
static struct i2c_driver cs4270_i2c_driver = {
.driver = {
.name = "CS4270 I2C",
.owner = THIS_MODULE,
},
.id = I2C_DRIVERID_CS4270,
.attach_adapter = cs4270_i2c_attach,
.detach_client = cs4270_i2c_detach,
};
In a slightly older kernel (still 2.6.27), I had to change "CS4270 I2C" to
"cs4270" to get it to work. However, that change no longer makes a difference.
I turned on debugging and this is what I see:
i2c-core: driver [CS4270 I2C] registered
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x48
i2c-adapter i2c-0: master_xfer[0] W, addr=0x48, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x49
i2c-adapter i2c-0: master_xfer[0] W, addr=0x49, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4a
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4a, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4b
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4b, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4c
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4c, len=0
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4c, len=1
i2c-adapter i2c-0: master_xfer[1] R, addr=0x4c, len=1
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4d
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4d, len=0
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4d, len=1
i2c-adapter i2c-0: master_xfer[1] R, addr=0x4d, len=1
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4e
i2c-adapter i2c-0: master_xfer[0] W, addr=0x4e, len=0
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4f
My device is at address 4F. The device tree defines a node for this device.
You can see it in arch/powerpc/boot/dts/mpc8610_hpcd.dts.
When I change the device tree so that it lists the device at an address other
than 4F, (e.g. "reg = <0x48>"), then my driver works.
So my conclusion is that specifying an I2C node in the device tree *requires*
that the driver be new-style. Is there any way we can fix this? I'm not going
to have time to update the CS4270 driver to a new-style interface before the
2.6.27 window closes.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: I2C node in device tree breaks old-style drivers
2008-07-29 19:43 I2C node in device tree breaks old-style drivers Timur Tabi
@ 2008-07-30 10:54 ` Jochen Friedrich
2008-07-30 13:00 ` Timur Tabi
0 siblings, 1 reply; 3+ messages in thread
From: Jochen Friedrich @ 2008-07-30 10:54 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
Hi Timur,
> So my conclusion is that specifying an I2C node in the device tree *requires*
> that the driver be new-style. Is there any way we can fix this? I'm not going
> to have time to update the CS4270 driver to a new-style interface before the
> 2.6.27 window closes.
This conclusion is correct. One possible way to fix this is to add support for
blacklisting to drivers/of/base.c (untested):
[RFC] of: Support blacklisting and blacklist cs4270.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
drivers/of/base.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..8c53b2c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -404,13 +404,16 @@ EXPORT_SYMBOL(of_find_matching_node);
* assumed that the data size is small and that the compatible values
* should already be distinct enough to differentiate between SPI, I2C
* and other devices.
+ *
+ * Blacklisting devices is supported by using NULL as modalias.
*/
struct of_modalias_table {
char *of_device;
char *modalias;
};
static struct of_modalias_table of_modalias_table[] = {
- /* Empty for now; add entries as needed */
+ /* Blacklisting cs4270 as this driver is currently old-style. */
+ { "cirrus,cs4270", NULL }
};
/**
@@ -441,6 +444,9 @@ int of_modalias_node(struct device_node *node, char *modalias, int len)
compatible = of_modalias_table[i].of_device;
if (!of_device_is_compatible(node, compatible))
continue;
+ /* Check for blacklisting */
+ if (!of_modalias_table[i].modalias)
+ return -ENODEV;
strlcpy(modalias, of_modalias_table[i].modalias, len);
return 0;
}
--
1.5.6.3
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: I2C node in device tree breaks old-style drivers
2008-07-30 10:54 ` Jochen Friedrich
@ 2008-07-30 13:00 ` Timur Tabi
0 siblings, 0 replies; 3+ messages in thread
From: Timur Tabi @ 2008-07-30 13:00 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
On Wed, Jul 30, 2008 at 5:54 AM, Jochen Friedrich <jochen@scram.de> wrote:
> Hi Timur,
>
>> So my conclusion is that specifying an I2C node in the device tree *requires*
>> that the driver be new-style. Is there any way we can fix this? I'm not going
>> to have time to update the CS4270 driver to a new-style interface before the
>> 2.6.27 window closes.
>
> This conclusion is correct. One possible way to fix this is to add support for
> blacklisting to drivers/of/base.c (untested):
No need. I posted a patch to alsa-devel that makes the CS4270 a
new-style I2C driver. I'd hate to think that my driver is the only
I2C driver used on PowerPC systems that was outdated. :-)
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-07-30 13:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-29 19:43 I2C node in device tree breaks old-style drivers Timur Tabi
2008-07-30 10:54 ` Jochen Friedrich
2008-07-30 13:00 ` Timur Tabi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).