[alsa-devel] SSM2518 Device Tree support ?
We needed DT support in the SSM2518 codec driver, and I noticed that there is already a set of bindings specified in Documentation/devicetree, however, there doesn't seem to be any DT support in the driver itself. I don't know if this is the result of a missing commit ?
Documentation/devicetree/bindings/sound/ssm2518.c seems to have been added in May 2013.
I've added rudimentary support for at least the compatible property so that the driver can be used in a system with DT configuration (sent as a separate email).
/Ricard
On 08/13/2015 02:12 PM, Ricard Wanderlof wrote:
We needed DT support in the SSM2518 codec driver, and I noticed that there is already a set of bindings specified in Documentation/devicetree, however, there doesn't seem to be any DT support in the driver itself. I don't know if this is the result of a missing commit ?
There is DT support in the driver. E.g. see the of_get_gpio() call.
What's not in the driver is a explicit of match table. It will work without since the I2C subsystem supports matching based on the I2C ID table. But, yes, it is better to add a explicit OF table to indicate that this works.
Documentation/devicetree/bindings/sound/ssm2518.c seems to have been added in May 2013.
I've added rudimentary support for at least the compatible property so that the driver can be used in a system with DT configuration (sent as a separate email).
Bringing up an old thread becuase i have a similar issue with the adau1761-i2c.c driver which should be configurable in the same way - it links into the I2C driver framework too. I know my ssm2518.c patch was recently applied, but using this driver (prior to the patch) as an example as Lars-Peter mentioned that it should be able to work this way.
On Thu, 13 Aug 2015, Lars-Peter Clausen wrote:
[ ... device tree support in ssm2518.c ... ] What's not in the driver is a explicit of match table. It will work without since the I2C subsystem supports matching based on the I2C ID table.
How does this actually work? I've tried to figure it out but haven't gotten anywhere.
From:
http://wiki.analog.com/resources/tools-software/linux-drivers/sound/ssm2518 :
i2s: i2c@41600000 { compatible = "...; ...
#size-cells = <0>; #address-cells = <1>;
ssm2518: ssm2518@34 { compatible = "adi,ssm2518"; reg = <0x34>; gpios = <&gpio 5 0>; }; };
In codecs/ssm2518.c:
static const struct i2c_device_id ssm2518_i2c_ids[] = { { "ssm2518", 0 }, { } }; MODULE_DEVICE_TABLE(i2c, ssm2518_i2c_ids);
static struct i2c_driver ssm2518_driver = { .driver = { .name = "ssm2518", .owner = THIS_MODULE, }, .probe = ssm2518_i2c_probe, .remove = ssm2518_i2c_remove, .id_table = ssm2518_i2c_ids, }; module_i2c_driver(ssm2518_driver);
So how does the i2c framework ultimately get the ssm2518 probe function to be called? The only real ID here are the strings "ssm2518" but they don't show up in the DT entry, except as part of the ssm2518 compatible string.
/Ricard
On 09/01/2015 09:06 AM, Ricard Wanderlof wrote:
Bringing up an old thread becuase i have a similar issue with the adau1761-i2c.c driver which should be configurable in the same way - it links into the I2C driver framework too. I know my ssm2518.c patch was recently applied, but using this driver (prior to the patch) as an example as Lars-Peter mentioned that it should be able to work this way.
On Thu, 13 Aug 2015, Lars-Peter Clausen wrote:
[ ... device tree support in ssm2518.c ... ] What's not in the driver is a explicit of match table. It will work without since the I2C subsystem supports matching based on the I2C ID table.
How does this actually work? I've tried to figure it out but haven't gotten anywhere.
From:
http://wiki.analog.com/resources/tools-software/linux-drivers/sound/ssm2518 :
i2s: i2c@41600000 { compatible = "...; ...
#size-cells = <0>; #address-cells = <1>;
ssm2518: ssm2518@34 { compatible = "adi,ssm2518"; reg = <0x34>; gpios = <&gpio 5 0>; }; };
In codecs/ssm2518.c:
static const struct i2c_device_id ssm2518_i2c_ids[] = { { "ssm2518", 0 }, { } }; MODULE_DEVICE_TABLE(i2c, ssm2518_i2c_ids);
static struct i2c_driver ssm2518_driver = { .driver = { .name = "ssm2518", .owner = THIS_MODULE, }, .probe = ssm2518_i2c_probe, .remove = ssm2518_i2c_remove, .id_table = ssm2518_i2c_ids, }; module_i2c_driver(ssm2518_driver);
So how does the i2c framework ultimately get the ssm2518 probe function to be called? The only real ID here are the strings "ssm2518" but they don't show up in the DT entry, except as part of the ssm2518 compatible string.
It splits the compatible string at the comma and then looks for a driver that matches the later part. Have a look at of_modalias_node().
- Lars
On Tue, 1 Sep 2015, Lars-Peter Clausen wrote:
So how does the i2c framework ultimately get the ssm2518 probe function to be called? The only real ID here are the strings "ssm2518" but they don't show up in the DT entry, except as part of the ssm2518 compatible string.
It splits the compatible string at the comma and then looks for a driver that matches the later part. Have a look at of_modalias_node().
Thanks Lars-Peter, that put be on the right track! (In my case it turns out the I2C driver was not properly enabled, so it's probe function never got called and consequently not the corresponding devices on the corresponding I2C bus).
/Ricard
participants (2)
-
Lars-Peter Clausen -
Ricard Wanderlof