Finding 'orphaned' i2c drivers

Finding 'orphaned' i2c drivers

[Daniel Mack]

Hi,

what's the suggested way of implementing an i2c drver which does not
have any other interfaces to the outside world than just the i2c device
it is communicating with? More specificly, I implemented a driver for a
Maxim clock generator and would like to use a proprietary interface with
it from a alsa-soc module. I just can't find a sane way to access the
driver's instance from there. It does exist somewhere in the linux
device tree, but is there a simple function that iterates over it and
returns it to me by name? Reading include/linux/device.h didn't point me
to anything that could fit.

Excuse me this is a stupid question, but I can't find any useful
information about that anywhere.

Thanks,
Daniel

Re: Finding 'orphaned' i2c drivers

[Jon Smirl]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

On Mon, Feb 23, 2009 at 6:00 AM, Daniel Mack <daniel-rDUAYElUppE@public.gmane.org> wrote:
> Hi,
>
> what's the suggested way of implementing an i2c drver which does not
> have any other interfaces to the outside world than just the i2c device
> it is communicating with? More specifically, I implemented a driver for a
> Maxim clock generator and would like to use a proprietary interface with
> it from a alsa-soc module. I just can't find a sane way to access the
> driver's instance from there. It does exist somewhere in the linux
> device tree, but is there a simple function that iterates over it and
> returns it to me by name? Reading include/linux/device.h didn't point me
> to anything that could fit.

The max9485? Which codec are you using it with? I tried submitting the
attached driver for the chip but Jean said it was too simple of a
driver.

I use it like this:

static int dspeak01_fabric_hw_params(struct snd_pcm_substream
*substream, struct snd_pcm_hw_params *params)
{
	uint rate, select;
	int ret;
	struct snd_soc_pcm_runtime *rtd = substream->private_data;
    struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;

	printk("dspeak01_fabric_hw_params\n");

	switch (params_rate(params)) {
	case 11025:
	case 22050:
	case 44100:
	case 88200:
	case 176400:
		rate = 22579200;
		select = MAX9485_225792;
		break;
	default:
		rate = 24576000;
		select = MAX9485_245760;
		break;
	}
	max9485_set(fabric.clock, select | MAX9485_CLK_OUT_2);

	ret = cpu_dai->ops.set_sysclk(cpu_dai, MPC52xx_CLK_CELLSLAVE, rate,
SND_SOC_CLOCK_OUT);
	if (ret < 0)
		return ret;

	return 0;
}


>
> Excuse me this is a stupid question, but I can't find any useful
> information about that anywhere.
>
> Thanks,
> Daniel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

[-- Attachment #2: max9485 --]
[-- Type: application/octet-stream, Size: 6152 bytes --]

i2c driver for Maxim max9485 audio clock generator chip

From: Jon Smirl <jonsmirl@gmail.com>

i2c driver for Maxim max9485 audio clock generator chip

Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
 drivers/misc/Kconfig        |    9 ++++
 drivers/misc/Makefile       |    2 +
 drivers/misc/max9485.c      |  105 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/i2c/max9485.h |   39 ++++++++++++++++
 4 files changed, 155 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/max9485.c
 create mode 100644 include/linux/i2c/max9485.h

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c64e679..320f359 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -150,6 +150,15 @@ config ATMEL_SSC
 
 	  If unsure, say N.
 
+config MAX9485
+	tristate "Maxim MAX9485 Programmable Audio Clock Generator"
+	help
+	  If you say yes here you get support for Maxim MAX9485 
+	  Programmable Audio Clock Generator.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called max9485.
+
 config ENCLOSURE_SERVICES
 	tristate "Enclosure Services"
 	default n
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index bc11998..7161709 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,6 +13,8 @@ obj-$(CONFIG_TIFM_CORE)       	+= tifm_core.o
 obj-$(CONFIG_TIFM_7XX1)       	+= tifm_7xx1.o
 obj-$(CONFIG_PHANTOM)		+= phantom.o
 obj-$(CONFIG_SGI_IOC4)		+= ioc4.o
+obj-$(CONFIG_EEPROM_93CX6)	+= eeprom_93cx6.o
+obj-$(CONFIG_MAX9485)		+= max9485.o
 obj-$(CONFIG_ENCLOSURE_SERVICES) += enclosure.o
 obj-$(CONFIG_KGDB_TESTS)	+= kgdbts.o
 obj-$(CONFIG_SGI_XP)		+= sgi-xp/
diff --git a/drivers/misc/max9485.c b/drivers/misc/max9485.c
new file mode 100644
index 0000000..c1316f2
--- /dev/null
+++ b/drivers/misc/max9485.c
@@ -0,0 +1,105 @@
+/*
+ * Maxim max9485 Programmable Audio Clock Generator driver
+ *
+ * Written by: Jon Smirl <jonsmirl@gmail.com>
+ *
+ * Copyright (C) 2008 Digispeaker.com
+ * Copyright (C) 2008 Jon Smirl <jonsmirl@gmail.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.
+ */
+
+/*
+ * This device is usually under the control of ALSA and should not be changed
+ * from userspace. The main purpose of this driver is to locate the i2c address
+ * of where the chip is located.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/sysfs.h>
+#include <linux/i2c/max9485.h>
+
+int max9485_set(struct i2c_client *max9485, u8 value)
+{
+	return i2c_smbus_write_byte(max9485, value);
+}
+EXPORT_SYMBOL_GPL(max9485_set);
+
+/*
+ * Display the only register
+ */
+static ssize_t max9485_show(struct device *dev, struct device_attribute *attr,
+			   char *buf)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	int rc;
+
+	rc = i2c_smbus_read_byte(client);
+	if (rc < 0)
+		return rc;
+
+	return sprintf(buf, "%s%s%s%s%s%s",
+			(rc & MAX9485_MCLK ? "MCLK+" : ""),
+			(rc & MAX9485_CLK_OUT_2 ? "CLK2+" : ""),
+			(rc & MAX9485_CLK_OUT_2 ? "CLK1+" : ""),
+			(rc & MAX9485_DOUBLED ? "DOUBLED+" : ""),
+			(rc & MAX9485_SCALE_768 ? "768x+" : (rc & MAX9485_SCALE_384 ? "384x+" : "256x+")),
+			((rc & 3) == MAX9485_FREQUENCY_48 ? "48Khz" :
+			((rc & 3) == MAX9485_FREQUENCY_441 ? "44.1Khz" :
+			((rc & 3) == MAX9485_FREQUENCY_32 ? "32Khz" : "12Khz"))));
+}
+static DEVICE_ATTR(max9485, S_IRUGO, max9485_show, NULL);
+
+/*
+ * Called when a max9485 device is matched with this driver
+ */
+static int max9485_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE)) {
+		dev_err(&client->dev, "i2c bus does not support the max9485\n");
+		return -ENODEV;
+	}
+	return sysfs_create_file(&client->dev.kobj, &dev_attr_max9485.attr);
+}
+
+static int max9485_remove(struct i2c_client *client)
+{
+	sysfs_remove_file(&client->dev.kobj, &dev_attr_max9485.attr);
+	return 0;
+}
+
+static const struct i2c_device_id max9485_id[] = {
+	{ "max9485", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, max9485_id);
+
+static struct i2c_driver max9485_driver = {
+	.driver = {
+		.name = "max9485",
+	},
+	.probe = max9485_probe,
+	.remove = max9485_remove,
+	.id_table = max9485_id,
+};
+
+static int __init max9485_init(void)
+{
+	return i2c_add_driver(&max9485_driver);
+}
+
+static void __exit max9485_exit(void)
+{
+	i2c_del_driver(&max9485_driver);
+}
+
+MODULE_AUTHOR("Jon Smirl <jonsmirl@gmail.com");
+MODULE_DESCRIPTION("Maxim MAX9485 Programmable Audio Clock Generator driver");
+MODULE_LICENSE("GPL");
+
+module_init(max9485_init);
+module_exit(max9485_exit);
diff --git a/include/linux/i2c/max9485.h b/include/linux/i2c/max9485.h
new file mode 100644
index 0000000..81543bb
--- /dev/null
+++ b/include/linux/i2c/max9485.h
@@ -0,0 +1,39 @@
+/*
+ * Maxim max9485 Programmable Audio Clock Generator driver
+ *
+ * Written by: Jon Smirl <jonsmirl@gmail.com>
+ *
+ * Copyright (C) 2008 Digispeaker.com
+ * Copyright (C) 2008 Jon Smirl <jonsmirl@gmail.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.
+ */
+
+#ifndef __LINUX_I2C_MAX9485_H
+#define __LINUX_I2C_MAX9485_H
+
+struct i2c_client;
+
+/* Defines for Maxim MAX9485 Audio Clock Generator */
+
+#define MAX9485_MCLK         (1 << 7)
+#define MAX9485_CLK_OUT_2    (1 << 6)
+#define MAX9485_CLK_OUT_1    (1 << 5)
+#define MAX9485_DOUBLED      (1 << 4)
+#define MAX9485_SCALE_256    (0 << 2)
+#define MAX9485_SCALE_384    (1 << 2)
+#define MAX9485_SCALE_768    (2 << 2)
+#define MAX9485_FREQUENCY_12  0
+#define MAX9485_FREQUENCY_32  1
+#define MAX9485_FREQUENCY_441 2
+#define MAX9485_FREQUENCY_48  3
+
+/* Combinations that minimize jitter */
+#define MAX9485_245760 (MAX9485_SCALE_256 | MAX9485_FREQUENCY_48 | MAX9485_DOUBLED)
+#define MAX9485_225792 (MAX9485_SCALE_256 | MAX9485_FREQUENCY_441 | MAX9485_DOUBLED)
+
+int max9485_set(struct i2c_client *max9485, u8 value);
+
+#endif /*  __LINUX_I2C_MAX9485_H */

Re: Finding 'orphaned' i2c drivers

[Daniel Mack]

Hi,

On Mon, Feb 23, 2009 at 09:38:45AM -0500, Jon Smirl wrote:
> On Mon, Feb 23, 2009 at 6:00 AM, Daniel Mack <daniel-rDUAYElUppE@public.gmane.org> wrote:
> > what's the suggested way of implementing an i2c drver which does not
> > have any other interfaces to the outside world than just the i2c device
> > it is communicating with? More specifically, I implemented a driver for a
> > Maxim clock generator and would like to use a proprietary interface with
> > it from a alsa-soc module. I just can't find a sane way to access the
> > driver's instance from there. It does exist somewhere in the linux
> > device tree, but is there a simple function that iterates over it and
> > returns it to me by name? Reading include/linux/device.h didn't point me
> > to anything that could fit.
> 
> The max9485? Which codec are you using it with? I tried submitting the
> attached driver for the chip but Jean said it was too simple of a
> driver.

Yes, it's the same one.

> I use it like this:
> 
> static int dspeak01_fabric_hw_params(struct snd_pcm_substream
> *substream, struct snd_pcm_hw_params *params)
> {
> 	uint rate, select;
> 	int ret;
> 	struct snd_soc_pcm_runtime *rtd = substream->private_data;
>     struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
> 
> 	printk("dspeak01_fabric_hw_params\n");
> 
> 	switch (params_rate(params)) {
> 	case 11025:
> 	case 22050:
> 	case 44100:
> 	case 88200:
> 	case 176400:
> 		rate = 22579200;
> 		select = MAX9485_225792;
> 		break;
> 	default:
> 		rate = 24576000;
> 		select = MAX9485_245760;
> 		break;
> 	}
> 	max9485_set(fabric.clock, select | MAX9485_CLK_OUT_2);

I still don't see where you got the pointer from you are using here, and
that's my whole question.

Your driver looks very much like the one I wrote, though ;)

Daniel

Re: Finding 'orphaned' i2c drivers

[Jon Smirl]

On Mon, Feb 23, 2009 at 9:43 AM, Daniel Mack <daniel-rDUAYElUppE@public.gmane.org> wrote:
> Hi,
>
> On Mon, Feb 23, 2009 at 09:38:45AM -0500, Jon Smirl wrote:
>> On Mon, Feb 23, 2009 at 6:00 AM, Daniel Mack <daniel-rDUAYElUppE@public.gmane.org> wrote:
>> > what's the suggested way of implementing an i2c drver which does not
>> > have any other interfaces to the outside world than just the i2c device
>> > it is communicating with? More specifically, I implemented a driver for a
>> > Maxim clock generator and would like to use a proprietary interface with
>> > it from a alsa-soc module. I just can't find a sane way to access the
>> > driver's instance from there. It does exist somewhere in the linux
>> > device tree, but is there a simple function that iterates over it and
>> > returns it to me by name? Reading include/linux/device.h didn't point me
>> > to anything that could fit.
>>
>> The max9485? Which codec are you using it with? I tried submitting the
>> attached driver for the chip but Jean said it was too simple of a
>> driver.
>
> Yes, it's the same one.
>
>> I use it like this:
>>
>> static int dspeak01_fabric_hw_params(struct snd_pcm_substream
>> *substream, struct snd_pcm_hw_params *params)
>> {
>>       uint rate, select;
>>       int ret;
>>       struct snd_soc_pcm_runtime *rtd = substream->private_data;
>>     struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
>>
>>       printk("dspeak01_fabric_hw_params\n");
>>
>>       switch (params_rate(params)) {
>>       case 11025:
>>       case 22050:
>>       case 44100:
>>       case 88200:
>>       case 176400:
>>               rate = 22579200;
>>               select = MAX9485_225792;
>>               break;
>>       default:
>>               rate = 24576000;
>>               select = MAX9485_245760;
>>               break;
>>       }
>>       max9485_set(fabric.clock, select | MAX9485_CLK_OUT_2);
>
> I still don't see where you got the pointer from you are using here, and
> that's my whole question.

I'm on PowerPC, we have device tree.

		i2c@3d00 {
			#address-cells = <1>;
			#size-cells = <0>;
			compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
			cell-index = <0>;
			reg = <0x3d00 0x40>;
			interrupts = <0x2 0xf 0x0>;
			interrupt-parent = <&mpc5200_pic>;
			fsl5200-clocking;

			tas0:codec@1b {
				compatible = "ti,tas5504";
				reg = <0x1b>;
			};
			clock0:clock@68 {
				compatible = "maxim,max9485";
				reg = <0x68>;
			};
		};

		fabric { /* audio fabric hardware */
			compatible = "dspeak01-fabric";
			clock-handle = <&clock0>;
		};


>
> Your driver looks very much like the one I wrote, though ;)
>
> Daniel
>
>



-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Finding 'orphaned' i2c drivers

[Jon Smirl]

On Mon, Feb 23, 2009 at 10:16 AM, Jon Smirl <jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Feb 23, 2009 at 9:43 AM, Daniel Mack <daniel-rDUAYElUppE@public.gmane.org> wrote:
>> Hi,
>>
>> On Mon, Feb 23, 2009 at 09:38:45AM -0500, Jon Smirl wrote:
>>> On Mon, Feb 23, 2009 at 6:00 AM, Daniel Mack <daniel-rDUAYElUppE@public.gmane.org> wrote:
>>> > what's the suggested way of implementing an i2c drver which does not
>>> > have any other interfaces to the outside world than just the i2c device
>>> > it is communicating with? More specifically, I implemented a driver for a
>>> > Maxim clock generator and would like to use a proprietary interface with
>>> > it from a alsa-soc module. I just can't find a sane way to access the
>>> > driver's instance from there. It does exist somewhere in the linux
>>> > device tree, but is there a simple function that iterates over it and
>>> > returns it to me by name? Reading include/linux/device.h didn't point me
>>> > to anything that could fit.
>>>
>>> The max9485? Which codec are you using it with? I tried submitting the
>>> attached driver for the chip but Jean said it was too simple of a
>>> driver.
>>
>> Yes, it's the same one.
>>
>>> I use it like this:
>>>
>>> static int dspeak01_fabric_hw_params(struct snd_pcm_substream
>>> *substream, struct snd_pcm_hw_params *params)
>>> {
>>>       uint rate, select;
>>>       int ret;
>>>       struct snd_soc_pcm_runtime *rtd = substream->private_data;
>>>     struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
>>>
>>>       printk("dspeak01_fabric_hw_params\n");
>>>
>>>       switch (params_rate(params)) {
>>>       case 11025:
>>>       case 22050:
>>>       case 44100:
>>>       case 88200:
>>>       case 176400:
>>>               rate = 22579200;
>>>               select = MAX9485_225792;
>>>               break;
>>>       default:
>>>               rate = 24576000;
>>>               select = MAX9485_245760;
>>>               break;
>>>       }
>>>       max9485_set(fabric.clock, select | MAX9485_CLK_OUT_2);
>>
>> I still don't see where you got the pointer from you are using here, and
>> that's my whole question.
>
> I'm on PowerPC, we have device tree.
>
>                i2c@3d00 {
>                        #address-cells = <1>;
>                        #size-cells = <0>;
>                        compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
>                        cell-index = <0>;
>                        reg = <0x3d00 0x40>;
>                        interrupts = <0x2 0xf 0x0>;
>                        interrupt-parent = <&mpc5200_pic>;
>                        fsl5200-clocking;
>
>                        tas0:codec@1b {
>                                compatible = "ti,tas5504";
>                                reg = <0x1b>;
>                        };
>                        clock0:clock@68 {
>                                compatible = "maxim,max9485";
>                                reg = <0x68>;
>                        };
>                };
>
>                fabric { /* audio fabric hardware */
>                        compatible = "dspeak01-fabric";
>                        clock-handle = <&clock0>;
>                };
>

In the fabric driver I use clock-handle and call
struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
{

To get the driver of the i2c device.

>
>>
>> Your driver looks very much like the one I wrote, though ;)
>>
>> Daniel
>>
>>
>
>
>
> --
> Jon Smirl
> jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>



-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Finding 'orphaned' i2c drivers

[Jon Smirl]

This is the last piece....

static int __devinit dspeak01_fabric_probe(struct of_device *op,
				      const struct of_device_id *match)
{
	const phandle *handle;
	struct device_node *clock_node;
	unsigned int len;

	handle = of_get_property(op->node, "clock-handle", &len);
	if (!handle || len < sizeof(handle))
		return -ENODEV;

	clock_node = of_find_node_by_phandle(*handle);
	if (!clock_node)
		return -ENODEV;

	fabric.clock = of_find_i2c_device_by_node(clock_node);
	if (!fabric.clock)
		return -ENODEV;

	of_snd_soc_register_machine("DSPEAK01", &dspeak01_fabric_ops);
	return 0;
}


-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Finding 'orphaned' i2c drivers

[Mark Brown]

On Mon, Feb 23, 2009 at 12:00:52PM +0100, Daniel Mack wrote:

> it is communicating with? More specificly, I implemented a driver for a
> Maxim clock generator and would like to use a proprietary interface with
> it from a alsa-soc module. I just can't find a sane way to access the
> driver's instance from there. It does exist somewhere in the linux
> device tree, but is there a simple function that iterates over it and
> returns it to me by name? Reading include/linux/device.h didn't point me
> to anything that could fit.

You probably want to either have the device register with the ASoC core
and discover it that way or have the driver be part of your machine
driver (as the neo1973 driver does for the external amplifier).

Re: Finding 'orphaned' i2c drivers

[Daniel Mack]

On Mon, Feb 23, 2009 at 02:43:44PM +0000, Mark Brown wrote:
> On Mon, Feb 23, 2009 at 12:00:52PM +0100, Daniel Mack wrote:
> 
> > it is communicating with? More specificly, I implemented a driver for a
> > Maxim clock generator and would like to use a proprietary interface with
> > it from a alsa-soc module. I just can't find a sane way to access the
> > driver's instance from there. It does exist somewhere in the linux
> > device tree, but is there a simple function that iterates over it and
> > returns it to me by name? Reading include/linux/device.h didn't point me
> > to anything that could fit.
> 
> You probably want to either have the device register with the ASoC core
> and discover it that way or have the driver be part of your machine
> driver (as the neo1973 driver does for the external amplifier).

Ok, I might miss a general thing here. All I do is add a driver which is
loaded via the module_init() mechanism and registers itself for that
specific device by name.

In the board support file, I add a list of i2c_board_infos by calling
i2s_register_board_info() and then the driver is magically instanciated
in some lower layer.

The question is: how do I access this instance at a later point? Without
messing around with static pointers, of course.

Daniel

Re: Finding 'orphaned' i2c drivers

[Mark Brown]

On Mon, Feb 23, 2009 at 03:51:42PM +0100, Daniel Mack wrote:

> The question is: how do I access this instance at a later point? Without
> messing around with static pointers, of course.

You're going to need to do something which is specific to your
application - it's not a problem for the I2C layer, all it's doing is
providing the lower level bus access for the device.  The upper level
API offered by your driver is something that depends on what services
your driver is implementing.

As I said in my previous e-mail you should probably either register with
ASoC core and get at the device that way or do something like what the
neo1973 driver is doing in your machine driver.