Use the Linux I2C subsystem for a two wire interface protocol

Use the Linux I2C subsystem for a two wire interface protocol

[alfred steele]

Hi,
I was looking at  the implementation of the i2 dev interface and the
bitbanging interface supplied by kernel v 2.6.24.  What i intend to do
is use the i2c kernel subsystem to write a userspace driver(using the
dev - ioctl interface) for a sensor SHT11 which uses a two wire
interface and a protocol with a packet structure which is different
from traditional I2C.

>From the header files and the API's therein, it looks like the
bitbanging interface should allow any  protocol header to be passed
as a "payload"(void *data) to the linux kernel i2c bitbanging driver
using gpio api.  Please let me know if this is a correct approach if
we intend to write a sensore driver with a proprietary 2 wire
interface protocol.

This would allow us to write  a user-space driver which is more
generic for the sensor and that can be changed to a I2C driver if the
GPIOs are later or tied in hardware to a  dedicated I2C controller. We
are using the mx31 pdk

Please let me know.
-Alfred.

Re: Use the Linux I2C subsystem for a two wire interface protocol

[Jonathan Cameron]

alfred steele wrote:
> Hi,
> I was looking at  the implementation of the i2 dev interface and the
> bitbanging interface supplied by kernel v 2.6.24.  What i intend to do
> is use the i2c kernel subsystem to write a userspace driver(using the
> dev - ioctl interface) for a sensor SHT11 which uses a two wire
> interface and a protocol with a packet structure which is different
> from traditional I2C.
Worth noting at this point that there is already a driver for this chip
in mainline (sht15 under hwmon - I've copied this to the lm-sensors where
that driver has previously been discussed).
I can't recall exactly when it was merged, but it's not there in 2.6.29
and is in 2.6.30.


> 
>>From the header files and the API's therein, it looks like the
> bitbanging interface should allow any  protocol header to be passed
> as a "payload"(void *data) to the linux kernel i2c bitbanging driver
> using gpio api.  Please let me know if this is a correct approach if
> we intend to write a sensore driver with a proprietary 2 wire
> interface protocol.
> 
> This would allow us to write  a user-space driver which is more
> generic for the sensor and that can be changed to a I2C driver if the
> GPIOs are later or tied in hardware to a  dedicated I2C controller. We
> are using the mx31 pdk
 
First thing to note is that this device is in no way using an i2c type
comms protocol. I'd be somewhat surprised if any i2c controllers are
generic enough to talk to it.  The start condition is non standard,
it uses a 3 bit address (with only 000) supported, and it also has a
fairly hideous means of indicating that the sampling process
has finished.  Basically you'd have more luck using the gpio's directly
than through anything to do with i2c.

---
Jonathan Cameron

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[Jonathan Cameron]

alfred steele wrote:
> Hi,
> I was looking at  the implementation of the i2 dev interface and the
> bitbanging interface supplied by kernel v 2.6.24.  What i intend to do
> is use the i2c kernel subsystem to write a userspace driver(using the
> dev - ioctl interface) for a sensor SHT11 which uses a two wire
> interface and a protocol with a packet structure which is different
> from traditional I2C.
Worth noting at this point that there is already a driver for this chip
in mainline (sht15 under hwmon - I've copied this to the lm-sensors where
that driver has previously been discussed).
I can't recall exactly when it was merged, but it's not there in 2.6.29
and is in 2.6.30.


> 
>>From the header files and the API's therein, it looks like the
> bitbanging interface should allow any  protocol header to be passed
> as a "payload"(void *data) to the linux kernel i2c bitbanging driver
> using gpio api.  Please let me know if this is a correct approach if
> we intend to write a sensore driver with a proprietary 2 wire
> interface protocol.
> 
> This would allow us to write  a user-space driver which is more
> generic for the sensor and that can be changed to a I2C driver if the
> GPIOs are later or tied in hardware to a  dedicated I2C controller. We
> are using the mx31 pdk
 
First thing to note is that this device is in no way using an i2c type
comms protocol. I'd be somewhat surprised if any i2c controllers are
generic enough to talk to it.  The start condition is non standard,
it uses a 3 bit address (with only 000) supported, and it also has a
fairly hideous means of indicating that the sampling process
has finished.  Basically you'd have more luck using the gpio's directly
than through anything to do with i2c.

---
Jonathan Cameron

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: Use the Linux I2C subsystem for a two wire interface protocol

[alfred steele]

Hi Jonathan,
Thanks!
> Worth noting at this point that there is already a driver for this chip
> in mainline (sht15 under hwmon - I've copied this to the lm-sensors where
> that driver has previously been discussed).
Oh ok, so its only in 2.6.30.So i believe i just need to adapt it to
the GPIOs used on my platform. Would it be sufficient to just populate
the GPIO no.s in the platform dev structure as the probe and remove
routine would  still remain the same for SHT1x devices

> First thing to note is that this device is in no way using an i2c type
> comms protocol. I'd be somewhat surprised if any i2c controllers are
> generic enough to talk to it.  The start condition is non standard,
I understand that. I meant the gpio bitbanging interface.

> it uses a 3 bit address (with only 000) supported, and it also has a
> fairly hideous means of indicating that the sampling process
> has finished.  Basically you'd have more luck using the gpio's directly
> than through anything to do with i2c.
But i am just pondering over the fact that if they have a bitbanging
gpio interface in the i2c subsystem, why should i not be able to just
pass the protocol header as a payload(void *data) to the interface and
design the user space driver which implements SHT11 specific
start/stop transmission sequence. Please correct me if i am wrong. I
am not sure about the "end of sampling"  indication though. I am still
going through the data sheet. To sum it up, the intention is code
reusablity in the sense that if we move to a different part which sits
on the I2c bus, we need not have to modify the kernel driver, just
keep the complexity  in the userspace.

Thanks,
Alfred.

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[alfred steele]

Hi Jonathan,
Thanks!
> Worth noting at this point that there is already a driver for this chip
> in mainline (sht15 under hwmon - I've copied this to the lm-sensors where
> that driver has previously been discussed).
Oh ok, so its only in 2.6.30.So i believe i just need to adapt it to
the GPIOs used on my platform. Would it be sufficient to just populate
the GPIO no.s in the platform dev structure as the probe and remove
routine would  still remain the same for SHT1x devices

> First thing to note is that this device is in no way using an i2c type
> comms protocol. I'd be somewhat surprised if any i2c controllers are
> generic enough to talk to it.  The start condition is non standard,
I understand that. I meant the gpio bitbanging interface.

> it uses a 3 bit address (with only 000) supported, and it also has a
> fairly hideous means of indicating that the sampling process
> has finished.  Basically you'd have more luck using the gpio's directly
> than through anything to do with i2c.
But i am just pondering over the fact that if they have a bitbanging
gpio interface in the i2c subsystem, why should i not be able to just
pass the protocol header as a payload(void *data) to the interface and
design the user space driver which implements SHT11 specific
start/stop transmission sequence. Please correct me if i am wrong. I
am not sure about the "end of sampling"  indication though. I am still
going through the data sheet. To sum it up, the intention is code
reusablity in the sense that if we move to a different part which sits
on the I2c bus, we need not have to modify the kernel driver, just
keep the complexity  in the userspace.

Thanks,
Alfred.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[Michael Lawnick]

alfred steele said the following:
> To sum it up, the intention is code
> reusablity in the sense that if we move to a different part which sits
> on the I2c bus, we need not have to modify the kernel driver, just
> keep the complexity  in the userspace.

I'd say this is just the wrong way round:
Design goal should be to keep application as is and just load another
driver on H/W change + changing access path in some config file.

Just my 2 cents

Michael

Re: [lm-sensors] Use the Linux I2C subsystem for a two

[Michael Lawnick]

alfred steele said the following:
> To sum it up, the intention is code
> reusablity in the sense that if we move to a different part which sits
> on the I2c bus, we need not have to modify the kernel driver, just
> keep the complexity  in the userspace.

I'd say this is just the wrong way round:
Design goal should be to keep application as is and just load another
driver on H/W change + changing access path in some config file.

Just my 2 cents

Michael

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[alfred steele]

Hi Jonathan/Michael,
> I'd say this is just the wrong way round:
> Design goal should be to keep application as is and just load another
> driver on H/W change + changing access path in some config file.
I get that.
I am assuming that in order to get the sht15 driver working on my
platform, all i need to do is populate the correct GPIO's in the
platform device structure. Any idea as to how to do that , i mean
where(which file in the source) does the actual platform device
strucutre's pdata get populated. What would be the optimal method to
tie it to the userspace. Can i add an ioctl to the sht15 driver and
export it for the userspace driver to use.

Appreciate your comments.
Thanks,
Alfred.

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[alfred steele]

Hi Jonathan/Michael,
> I'd say this is just the wrong way round:
> Design goal should be to keep application as is and just load another
> driver on H/W change + changing access path in some config file.
I get that.
I am assuming that in order to get the sht15 driver working on my
platform, all i need to do is populate the correct GPIO's in the
platform device structure. Any idea as to how to do that , i mean
where(which file in the source) does the actual platform device
strucutre's pdata get populated. What would be the optimal method to
tie it to the userspace. Can i add an ioctl to the sht15 driver and
export it for the userspace driver to use.

Appreciate your comments.
Thanks,
Alfred.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[Jonathan Cameron]

alfred steele wrote:
> Hi Jonathan/Michael,
>> I'd say this is just the wrong way round:
>> Design goal should be to keep application as is and just load another
>> driver on H/W change + changing access path in some config file.
> I get that.
> I am assuming that in order to get the sht15 driver working on my
> platform, all i need to do is populate the correct GPIO's in the
> platform device structure. 
Yes and register it with the kernel
> Any idea as to how to do that , i mean
> where(which file in the source) does the actual platform device
> strucutre's pdata get populated.
On an embedded board this would typically be in the board config
file.  For example, see arch/arm/mach-pxa/imote2.c which has an sht15
attached.  The exact method of registration may be a bit architecture
specific but will look something like the relevant parts of that file.

> What would be the optimal method to
> tie it to the userspace. Can i add an ioctl to the sht15 driver and
> export it for the userspace driver to use.
No. Preferred way to access this sort of slow low bandwidth device
is via sysfs.

It'll create files for reading the various values under

/sys/class/hwmon/hwmon?/device/

from memory they are called

temp0 and humidity0 

Jonathan

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[Jonathan Cameron]

alfred steele wrote:
> Hi Jonathan/Michael,
>> I'd say this is just the wrong way round:
>> Design goal should be to keep application as is and just load another
>> driver on H/W change + changing access path in some config file.
> I get that.
> I am assuming that in order to get the sht15 driver working on my
> platform, all i need to do is populate the correct GPIO's in the
> platform device structure. 
Yes and register it with the kernel
> Any idea as to how to do that , i mean
> where(which file in the source) does the actual platform device
> strucutre's pdata get populated.
On an embedded board this would typically be in the board config
file.  For example, see arch/arm/mach-pxa/imote2.c which has an sht15
attached.  The exact method of registration may be a bit architecture
specific but will look something like the relevant parts of that file.

> What would be the optimal method to
> tie it to the userspace. Can i add an ioctl to the sht15 driver and
> export it for the userspace driver to use.
No. Preferred way to access this sort of slow low bandwidth device
is via sysfs.

It'll create files for reading the various values under

/sys/class/hwmon/hwmon?/device/

from memory they are called

temp0 and humidity0 

Jonathan

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[alfred steele]

Thanks Jonathan!

> On an embedded board this would typically be in the board config
> file.  For example, see arch/arm/mach-pxa/imote2.c which has an sht15
> attached.  The exact method of registration may be a bit architecture
> specific but will look something like the relevant parts of that file.
Yep, for e.g we have wrappers for api's like gpio_request etc.
The real problem, however, seems to be that we have been using a
distro which uses kernel 2.6.24.
It does not have the "<linux/gpio.h>" and  the "<regulater/consumer.h>
 which export
regulator_register_notifier()/regulator_unregister_notifier() functions.
So, i will have to look into how to backport this. THe gpio lib thing
may be straightforward but i am way ignorant on  the regulator/pmic
infrastructure. It would greatly help you can shed some light on the
regulator part and if there is any quick way to get around to backport
the regulator specific functions.
Thanks in advance for your help!
-Alfred.

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[alfred steele]

Thanks Jonathan!

> On an embedded board this would typically be in the board config
> file.  For example, see arch/arm/mach-pxa/imote2.c which has an sht15
> attached.  The exact method of registration may be a bit architecture
> specific but will look something like the relevant parts of that file.
Yep, for e.g we have wrappers for api's like gpio_request etc.
The real problem, however, seems to be that we have been using a
distro which uses kernel 2.6.24.
It does not have the "<linux/gpio.h>" and  the "<regulater/consumer.h>
 which export
regulator_register_notifier()/regulator_unregister_notifier() functions.
So, i will have to look into how to backport this. THe gpio lib thing
may be straightforward but i am way ignorant on  the regulator/pmic
infrastructure. It would greatly help you can shed some light on the
regulator part and if there is any quick way to get around to backport
the regulator specific functions.
Thanks in advance for your help!
-Alfred.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[Mark Brown]

On Wed, Jul 15, 2009 at 10:46:27AM -0500, alfred steele wrote:

> It does not have the "<linux/gpio.h>" and  the "<regulater/consumer.h>
>  which export
> regulator_register_notifier()/regulator_unregister_notifier() functions.
> So, i will have to look into how to backport this. THe gpio lib thing
> may be straightforward but i am way ignorant on  the regulator/pmic
> infrastructure. It would greatly help you can shed some light on the

The regulator API should backport simply by copying it over, all it uses
from the core kernel that I can recall is very basic stuff like mutexes
and lists.

> regulator part and if there is any quick way to get around to backport
> the regulator specific functions.
> Thanks in advance for your help!
> -Alfred.
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> 

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: [lm-sensors] Use the Linux I2C subsystem for a two

[Mark Brown]

On Wed, Jul 15, 2009 at 10:46:27AM -0500, alfred steele wrote:

> It does not have the "<linux/gpio.h>" and  the "<regulater/consumer.h>
>  which export
> regulator_register_notifier()/regulator_unregister_notifier() functions.
> So, i will have to look into how to backport this. THe gpio lib thing
> may be straightforward but i am way ignorant on  the regulator/pmic
> infrastructure. It would greatly help you can shed some light on the

The regulator API should backport simply by copying it over, all it uses
from the core kernel that I can recall is very basic stuff like mutexes
and lists.

> regulator part and if there is any quick way to get around to backport
> the regulator specific functions.
> Thanks in advance for your help!
> -Alfred.
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> 

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[alfred steele]

Hi

> On an embedded board this would typically be in the board config
> file.  For example, see arch/arm/mach-pxa/imote2.c which has an sht15
> attached.  The exact method of registration may be a bit architecture
> specific but will look something like the relevant parts of that file.
Was trying to look through the imote2.c but i did not get any exact
match, i am not sure if you are talking about the traditional method
of declaring the platform data/device and use sort of
platform_register(). Are you talking about the following chunk?

[vcc_sensor_1_8] = {
248                 .constraints = { /* default 1.8V */
249                         .name = "vcc_sensor_1_8",
250                         .min_uV = 1800000,
251                         .max_uV = 1800000,
252                 },
253         },

How does the structure in  sht15_platform_data in the sht15 code
relate to this?  I am a bit confused.
-Alfred.

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[Jonathan Cameron]

alfred steele wrote:
> Hi
> 
>> On an embedded board this would typically be in the board config
>> file.  For example, see arch/arm/mach-pxa/imote2.c which has an sht15
>> attached.  The exact method of registration may be a bit architecture
>> specific but will look something like the relevant parts of that file.
> Was trying to look through the imote2.c but i did not get any exact
> match, i am not sure if you are talking about the traditional method
> of declaring the platform data/device and use sort of
> platform_register(). Are you talking about the following chunk?
> 
> [vcc_sensor_1_8] = {
> 248                 .constraints = { /* default 1.8V */
> 249                         .name = "vcc_sensor_1_8",
> 250                         .min_uV = 1800000,
> 251                         .max_uV = 1800000,
> 252                 },
> 253         },
> 

Sorry, my mistake, the board support didn't merge until post 2.6.30 as
the driver merge occured well after the merge window for 2.6.30

Take a look at what is in the current tree.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-pxa/imote2.c

relevant bits are:


#include <linux/sht15.h>
...
couple of mfp defines to enable the gpios. (how you do this is platform dependent)
...
(note you will probably want to add the supply voltage in here)

120 static struct sht15_platform_data platform_data_sht15 = {
121         .gpio_data =  100,
122         .gpio_sck  =  98,
123 };
124
125 static struct platform_device sht15 = {
126         .name = "sht15",
127         .id = -1,
128         .dev = {
129                 .platform_data = &platform_data_sht15,
130         },
131 };
132 

 538 static struct platform_device *imote2_devices[] = {
...
541         &sht15,
542 };
...
 560         platform_add_devices(imote2_devices, ARRAY_SIZE(imote2_devices));

If you do back port the regulator framework there are some bits and bobs related
to that in there as well.

Jonathan

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[Jonathan Cameron]

alfred steele wrote:
> Hi
> 
>> On an embedded board this would typically be in the board config
>> file.  For example, see arch/arm/mach-pxa/imote2.c which has an sht15
>> attached.  The exact method of registration may be a bit architecture
>> specific but will look something like the relevant parts of that file.
> Was trying to look through the imote2.c but i did not get any exact
> match, i am not sure if you are talking about the traditional method
> of declaring the platform data/device and use sort of
> platform_register(). Are you talking about the following chunk?
> 
> [vcc_sensor_1_8] = {
> 248                 .constraints = { /* default 1.8V */
> 249                         .name = "vcc_sensor_1_8",
> 250                         .min_uV = 1800000,
> 251                         .max_uV = 1800000,
> 252                 },
> 253         },
> 

Sorry, my mistake, the board support didn't merge until post 2.6.30 as
the driver merge occured well after the merge window for 2.6.30

Take a look at what is in the current tree.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-pxa/imote2.c

relevant bits are:


#include <linux/sht15.h>
...
couple of mfp defines to enable the gpios. (how you do this is platform dependent)
...
(note you will probably want to add the supply voltage in here)

120 static struct sht15_platform_data platform_data_sht15 = {
121         .gpio_data =  100,
122         .gpio_sck  =  98,
123 };
124
125 static struct platform_device sht15 = {
126         .name = "sht15",
127         .id = -1,
128         .dev = {
129                 .platform_data = &platform_data_sht15,
130         },
131 };
132 

 538 static struct platform_device *imote2_devices[] = {
...
541         &sht15,
542 };
...
 560         platform_add_devices(imote2_devices, ARRAY_SIZE(imote2_devices));

If you do back port the regulator framework there are some bits and bobs related
to that in there as well.

Jonathan


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[alfred steele]

Hi Jonathan,
Thanks for the relentless help. I have adapted the driver to my
platform by changing the following:
gpio_request(), gpio_get/gpio_set() to thier counterparts on my platform.

> couple of mfp defines to enable the gpios. (how you do this is platform dependent)
By this i guess, you mean configuring the gpios, and defining the I/O
characteristics for each of the signals.

>mework there are some bits and bobs related

So after doing all the porting, i was able to compile it as an
loadable kernel module. I tried insmod and here;s what i get:

~$ insmod sht15.ko
regulator: Unable to get requested regulator: vcc
sht15 sht15: Command not acknowledged
 ~$
Do i have to play with any timings related to the part. I have a SHT11
, but i was assuming that there is no significant difference.
Although something may have gone wrong when i ported.
-Alfred.

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[alfred steele]

Hi Jonathan,
Thanks for the relentless help. I have adapted the driver to my
platform by changing the following:
gpio_request(), gpio_get/gpio_set() to thier counterparts on my platform.

> couple of mfp defines to enable the gpios. (how you do this is platform dependent)
By this i guess, you mean configuring the gpios, and defining the I/O
characteristics for each of the signals.

>mework there are some bits and bobs related

So after doing all the porting, i was able to compile it as an
loadable kernel module. I tried insmod and here;s what i get:

~$ insmod sht15.ko
regulator: Unable to get requested regulator: vcc
sht15 sht15: Command not acknowledged
 ~$
Do i have to play with any timings related to the part. I have a SHT11
, but i was assuming that there is no significant difference.
Although something may have gone wrong when i ported.
-Alfred.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[alfred steele]

> ~$ insmod sht15.ko
> regulator: Unable to get requested regulator: vcc
> sht15 sht15: Command not acknowledged
Please ignore the 1st line as i have bypassed the regulator framework.
Another quick question: The datasheet recommends 3.3V but the
voltage measured on my lines are ~2.8V. That could be another spoiler.

-Alfred.

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[alfred steele]

> ~$ insmod sht15.ko
> regulator: Unable to get requested regulator: vcc
> sht15 sht15: Command not acknowledged
Please ignore the 1st line as i have bypassed the regulator framework.
Another quick question: The datasheet recommends 3.3V but the
voltage measured on my lines are ~2.8V. That could be another spoiler.

-Alfred.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[Jonathan Cameron]

alfred steele wrote:
>> ~$ insmod sht15.ko
>> regulator: Unable to get requested regulator: vcc
>> sht15 sht15: Command not acknowledged
> Please ignore the 1st line as i have bypassed the regulator framework.
> Another quick question: The datasheet recommends 3.3V but the
> voltage measured on my lines are ~2.8V. That could be another spoiler.
It'll probably be fine.

I suggest sticking a scope on the signal lines and confirming things
that look about right are going down them.

Jonathan

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[Jonathan Cameron]

alfred steele wrote:
>> ~$ insmod sht15.ko
>> regulator: Unable to get requested regulator: vcc
>> sht15 sht15: Command not acknowledged
> Please ignore the 1st line as i have bypassed the regulator framework.
> Another quick question: The datasheet recommends 3.3V but the
> voltage measured on my lines are ~2.8V. That could be another spoiler.
It'll probably be fine.

I suggest sticking a scope on the signal lines and confirming things
that look about right are going down them.

Jonathan

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[alfred steele]

Hi Jonathan,

> that look about right are going down them.
I had some misconfiguration the way i had registered the interrupt handler.

A very naive question at this point. Wouldnt it be possible to "not"
use  a GPIO irq and bottom half and instead to simplify the driver to
start with, use a synchronous read routine.? I know this may violate
the kernel framework but...
This is what i get on the console now

$ cat /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi
ty1_input
sht15 sht15: Command not acknowledged
cat: read error: Input/output error
 ~$ cat /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi
ty1_input
cat: read error: Timer expired
root@freescale ~$ cat /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi
ty1_input
Unbalanced enable for IRQ 0
WARNING: at kernel/irq/manage.c:174 enable_irq()
[<c002dce0>] (dump_stack+0x0/0x14) from [<c0074050>] (enable_irq+0x74/0xdc)
[<c0073fdc>] (enable_irq+0x0/0xdc) from [<bf000408>] (sht15_update_vals+0x190/0x
2c8 [sht15])
 r6:00000010 r5:cfdbf420 r4:cfe331e0
[<bf000278>] (sht15_update_vals+0x0/0x2c8 [sht15]) from [<bf0007f4>] (sht15_show
_humidity+0x1c/0x130 [sht15])
[<bf0007d8>] (sht15_show_humidity+0x0/0x130 [sht15]) from [<c0175044>] (dev_attr
_show+0x24/0x30)
[<c0175020>] (dev_attr_show+0x0/0x30) from [<c00d99ac>] (sysfs_read_file+0xa8/0x
108)
[<c00d9904>] (sysfs_read_file+0x0/0x108) from [<c009ac40>] (vfs_read+0xb4/0x144)
[<c009ab8c>] (vfs_read+0x0/0x144) from [<c009b080>] (sys_read+0x44/0x70)
 r7:00000000 r6:00000000 r5:fffffff7 r4:cfea93c0
[<c009b03c>] (sys_read+0x0/0x70) from [<c0029ec0>] (ret_fast_syscall+0x0/0x2c)
 r7:00000003 r6:4001da30 r5:beaa9ae0 r4:00002000
cat: read error: Timer expired

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[alfred steele]

Hi Jonathan,

> that look about right are going down them.
I had some misconfiguration the way i had registered the interrupt handler.

A very naive question at this point. Wouldnt it be possible to "not"
use  a GPIO irq and bottom half and instead to simplify the driver to
start with, use a synchronous read routine.? I know this may violate
the kernel framework but...
This is what i get on the console now

$ cat /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi
ty1_input
sht15 sht15: Command not acknowledged
cat: read error: Input/output error
 ~$ cat /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi
ty1_input
cat: read error: Timer expired
root@freescale ~$ cat /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi
ty1_input
Unbalanced enable for IRQ 0
WARNING: at kernel/irq/manage.c:174 enable_irq()
[<c002dce0>] (dump_stack+0x0/0x14) from [<c0074050>] (enable_irq+0x74/0xdc)
[<c0073fdc>] (enable_irq+0x0/0xdc) from [<bf000408>] (sht15_update_vals+0x190/0x
2c8 [sht15])
 r6:00000010 r5:cfdbf420 r4:cfe331e0
[<bf000278>] (sht15_update_vals+0x0/0x2c8 [sht15]) from [<bf0007f4>] (sht15_show
_humidity+0x1c/0x130 [sht15])
[<bf0007d8>] (sht15_show_humidity+0x0/0x130 [sht15]) from [<c0175044>] (dev_attr
_show+0x24/0x30)
[<c0175020>] (dev_attr_show+0x0/0x30) from [<c00d99ac>] (sysfs_read_file+0xa8/0x
108)
[<c00d9904>] (sysfs_read_file+0x0/0x108) from [<c009ac40>] (vfs_read+0xb4/0x144)
[<c009ab8c>] (vfs_read+0x0/0x144) from [<c009b080>] (sys_read+0x44/0x70)
 r7:00000000 r6:00000000 r5:fffffff7 r4:cfea93c0
[<c009b03c>] (sys_read+0x0/0x70) from [<c0029ec0>] (ret_fast_syscall+0x0/0x2c)
 r7:00000003 r6:4001da30 r5:beaa9ae0 r4:00002000
cat: read error: Timer expired

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[alfred steele]

> A very naive question at this point. Wouldnt it be possible to "not"
> use  a GPIO irq and bottom half and instead to simplify the driver to
> start with, use a synchronous read routine.? I know this may violate
> the kernel framework
I  stuck a scope, i could see the lines wiggling, but no "AC" was sent
from the sensor.
-Alfred.

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[alfred steele]

> A very naive question at this point. Wouldnt it be possible to "not"
> use  a GPIO irq and bottom half and instead to simplify the driver to
> start with, use a synchronous read routine.? I know this may violate
> the kernel framework
I  stuck a scope, i could see the lines wiggling, but no "AC" was sent
from the sensor.
-Alfred.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire interface protocol

[J.I. Cameron]

On Jul 17 2009, alfred steele wrote:

>Hi Jonathan,
>
>> that look about right are going down them.
>I had some misconfiguration the way i had registered the interrupt handler.
>
>A very naive question at this point. Wouldnt it be possible to "not"
>use  a GPIO irq and bottom half and instead to simplify the driver to
>start with, use a synchronous read routine.? I know this may violate
>the kernel framework but...

It would indeed be possible but would come at the cost of having some 
pretty hideous hard coded delays. Seeing as the device tells you that it 
has new data available (and the delays in question are huge and probably 
not all that consistent - though I've never measured them on different 
chips) I'm personally of the view that the interrupt method is the nicest 
solution.


>This is what i get on the console now
>
> $ cat /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi 
> ty1_input sht15 sht15: Command not acknowledged cat: read error: 
> Input/output error ~$ cat 
> /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi ty1_input cat: 
> read error: Timer expired root@freescale ~$ cat 
> /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi ty1_input 
> Unbalanced enable for IRQ 0 WARNING: at kernel/irq/manage.c:174 
> enable_irq() [<c002dce0>] (dump_stack+0x0/0x14) from [<c0074050>] 
> (enable_irq+0x74/0xdc) [<c0073fdc>] (enable_irq+0x0/0xdc) from 
> [<bf000408>]
Hmm. The unbalanced irq certainly looks like an actual bug even if this
condition should never occur if things are working correctly.

I'm not sure where that timer expired message is coming from and
unfortunately don't have easy access to source code here to track
it down.  

> (sht15_update_vals+0x190/0x 2c8 [sht15]) r6:00000010 
> r5:cfdbf420 r4:cfe331e0 [<bf000278>] (sht15_update_vals+0x0/0x2c8 
> [sht15]) from [<bf0007f4>] (sht15_show _humidity+0x1c/0x130 [sht15]) 
> [<bf0007d8>] (sht15_show_humidity+0x0/0x130 [sht15]) from [<c0175044>] 
> (dev_attr _show+0x24/0x30) [<c0175020>] (dev_attr_show+0x0/0x30) from 
> [<c00d99ac>] (sysfs_read_file+0xa8/0x 108) [<c00d9904>] 
> (sysfs_read_file+0x0/0x108) from [<c009ac40>] (vfs_read+0xb4/0x144) 
> [<c009ab8c>] (vfs_read+0x0/0x144) from [<c009b080>] (sys_read+0x44/0x70) 
> r7:00000000 r6:00000000 r5:fffffff7 r4:cfea93c0 [<c009b03c>] 
> (sys_read+0x0/0x70) from [<c0029ec0>] (ret_fast_syscall+0x0/0x2c) 
> r7:00000003 r6:4001da30 r5:beaa9ae0 r4:00002000 cat: read error: Timer 
> expired
That looks nasty. I'm out of the office at the moment, so can't realy look
into this in any depth. Should be back in action on Thursday.

Re: [lm-sensors] Use the Linux I2C subsystem for a two wire

[J.I. Cameron]

On Jul 17 2009, alfred steele wrote:

>Hi Jonathan,
>
>> that look about right are going down them.
>I had some misconfiguration the way i had registered the interrupt handler.
>
>A very naive question at this point. Wouldnt it be possible to "not"
>use  a GPIO irq and bottom half and instead to simplify the driver to
>start with, use a synchronous read routine.? I know this may violate
>the kernel framework but...

It would indeed be possible but would come at the cost of having some 
pretty hideous hard coded delays. Seeing as the device tells you that it 
has new data available (and the delays in question are huge and probably 
not all that consistent - though I've never measured them on different 
chips) I'm personally of the view that the interrupt method is the nicest 
solution.


>This is what i get on the console now
>
> $ cat /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi 
> ty1_input sht15 sht15: Command not acknowledged cat: read error: 
> Input/output error ~$ cat 
> /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi ty1_input cat: 
> read error: Timer expired root@freescale ~$ cat 
> /sys/class/hwmon/hwmon0/device/hwmon\:hwmon0/device/humidi ty1_input 
> Unbalanced enable for IRQ 0 WARNING: at kernel/irq/manage.c:174 
> enable_irq() [<c002dce0>] (dump_stack+0x0/0x14) from [<c0074050>] 
> (enable_irq+0x74/0xdc) [<c0073fdc>] (enable_irq+0x0/0xdc) from 
> [<bf000408>]
Hmm. The unbalanced irq certainly looks like an actual bug even if this
condition should never occur if things are working correctly.

I'm not sure where that timer expired message is coming from and
unfortunately don't have easy access to source code here to track
it down.  

> (sht15_update_vals+0x190/0x 2c8 [sht15]) r6:00000010 
> r5:cfdbf420 r4:cfe331e0 [<bf000278>] (sht15_update_vals+0x0/0x2c8 
> [sht15]) from [<bf0007f4>] (sht15_show _humidity+0x1c/0x130 [sht15]) 
> [<bf0007d8>] (sht15_show_humidity+0x0/0x130 [sht15]) from [<c0175044>] 
> (dev_attr _show+0x24/0x30) [<c0175020>] (dev_attr_show+0x0/0x30) from 
> [<c00d99ac>] (sysfs_read_file+0xa8/0x 108) [<c00d9904>] 
> (sysfs_read_file+0x0/0x108) from [<c009ac40>] (vfs_read+0xb4/0x144) 
> [<c009ab8c>] (vfs_read+0x0/0x144) from [<c009b080>] (sys_read+0x44/0x70) 
> r7:00000000 r6:00000000 r5:fffffff7 r4:cfea93c0 [<c009b03c>] 
> (sys_read+0x0/0x70) from [<c0029ec0>] (ret_fast_syscall+0x0/0x2c) 
> r7:00000003 r6:4001da30 r5:beaa9ae0 r4:00002000 cat: read error: Timer 
> expired
That looks nasty. I'm out of the office at the moment, so can't realy look
into this in any depth. Should be back in action on Thursday.



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors