Has AM335x_ADC_Driver interface changed in linux 3.14?

Hi,
Able to see any kernel messages about ADC driver ?
Did you check the dts file that has ADC entry ?

Hi!
Only kernel message regarding ADC is:
[ 3.796382] input: ti-tsc as /devices/ocp/44e0d000.tscadc/TI-am335x-tsc/input/input0

Yes, I checked/modified it as my board has uses four ADC channels connected to channel 0-3. As I told in my previous message these work fine in oneshot mode. However, there is no chance switching to continuous mode as sysfs does not have iio:device0/mode node.

What I find different from the text in ADC Drive Guide is that It seems impossible to disable kfifo like it has been done in that document. There is not that choice available like listed below.

--- Industrial I/O support
-*- Enable buffer support within IIO
[*] IIO callback buffer used for push in-kernel interfaces
-*- Industrial I/O buffering based on kfifo
-*- Enable triggered sampling support
(2) Maximum number of consumers per trigger

If I remove it from defconfig, it will still be present in .config file to be used as source for kernel configuration. There seems to be some kind of sanity check/fix while feeding defconfig to .config

-Matti

Hi!
I tried using also channels 4..7. Same problem - Sysfs "mode" node did not appear. I also made more manual single shot reads and find out that there is distinct diffrence between the channels. It seems that channel 0, i.e. in_voltage0_raw works every time. Other channels work fine roughly every other or more seldomly. Instead of number they tend to return "cat: read error: Device or resource busy" or "cat: read error: Resource temporarily unavailable". Can anyone find any sense from these symptoms?
-Matti

Hi,

[*] IIO callback buffer used for push in-kernel interfaces
-*- Industrial I/O buffering based on kfifo

What I find different from the text in ADC Drive Guide is that It seems impossible to disable kfifo like it has been done in that document. There is not that choice available like listed below.

If you want to disable, check that "help" of option, it frozen because of dependencies got enabled that we need disable to disable "kfifo"

Thank you for your answer

It is not that I wanted disable kfifo option. I just did not find any other difference between my settings and those presented in ADC manual. I don't know it it helps getting mode structures available. Does it?

thanks,

Matti

Titus,

I checked kfifo help (below). It seems pretty impossible to disable. Virtually anything enables it.

CONFIG_IIO_KFIFO_BUF:  
A simple fifo based on kfifo.  Note that this currently provides
no buffer events so it is up to userspace to work out how
often to read from the buffer.
Symbol: IIO_KFIFO_BUF [=y];
Type  : tristate
Prompt: Industrial I/O buffering based on kfifo
 Location:
   -> Device Drivers
     -> Industrial I/O support (IIO [=y])
       -> Enable buffer support within IIO (IIO_BUFFER [=y])
 Defined at drivers/iio/Kconfig:28
 Depends on: IIO [=y] && IIO_BUFFER [=y]
 Selects: IIO_TRIGGER [=y]
 Selected by: AD5933 [=n] && STAGING [=n] && IIO [=y] && I2C [=y] || ADE7758 [=n] && STAGING [=n] && IIO [=y] && SPI [=y] && IIO_BUFFER [=y]  IIO_SIMPLE_DUMMY_BUFFER [=n] && STAGING [=n] && IIO [=y] && IIO_SIMPLE_DUMMY [=n] || IIO_TRIGGERED_BUFFER [=n] && IIO [=y] && IIO_BUFFER [=y] ||TI_AM335X_ADC [=y] && IIO [=y] && MFD_TI_AM335X_TSCADC [=y]

There must be some other reason why "mode" node does not exist in sysfs.

I tried also that "drivers/staging/iio/Documentation/generic_buffer.c". It has changed so much that patch presented in wiki did not work. However, I made the changes patch had to make genefic_buffer.c work without triggers. Well, it did not work. Application returned always -1 as return value (=read_size) from reading from /dev/iio:device0. Is there anything I could debug here more?

Regards,

Matti

Hi,
Please compare the kernel bootup logs of old and new and see if you get any hints from that.

However, I can't find /sys/bus/iio/devices/iio:device0/mode from sysfs for changing sampling mode. Do I miss something essential from the document or has interface changed? If so, could someone describe how to use it now?

Just "mode" entry alone not able to get or whole entry ?

I presume that you have enabled SYSFS and mounted it.

I do have:
---------------------------------------------------------
root@am335x-evm:~# ls -la /sys/bus/iio/devices/iio\:device0/
drwxr-xr-x 5 root root 0 Jun 25 13:30 .
drwxr-xr-x 4 root root 0 Jan 1 2000 ..
drwxr-xr-x 2 root root 0 Jun 25 15:28 buffer
-r--r--r-- 1 root root 4096 Jun 26 11:45 dev
-rw-r--r-- 1 root root 4096 Jun 26 11:45 in_voltage0_raw
-rw-r--r-- 1 root root 4096 Jun 26 11:45 in_voltage1_raw
-rw-r--r-- 1 root root 4096 Jun 26 11:45 in_voltage2_raw
-rw-r--r-- 1 root root 4096 Jun 26 11:45 in_voltage3_raw
-r--r--r-- 1 root root 4096 Jun 25 15:28 name
drwxr-xr-x 2 root root 0 Jun 26 11:45 power
drwxr-xr-x 2 root root 0 Jun 25 15:28 scan_elements
lrwxrwxrwx 1 root root 0 Jun 26 11:45 subsystem -> ../../../../../bus/iio
-rw-r--r-- 1 root root 4096 Jun 26 11:45 uevent
---------------------------------------------------------
Compared to wiki: only "mode" is missing.
If I have above, I suppose syfs is mounted (and in fact sysfs is listed in mount list as /sys). I do not quite get what you mean with "enabled" sysfs.
Thanks,
Matti

I think there is no point of verifying older boot log. That implementation was totally buggy. Raw reading hung after second read from any of these channels. I could have read twice from the same channel or once from, two different channels. This did not recover without booting. That was Silica/ArchiTech/Pengwyn implementation based on kernel 3.12 ( linux-ti-staging ). Actually that was the reason (last brick) dropping ArchiTech distro and trying to upgrade kernel. Well, it does not look that good either..

Titus,
I have not proceeded with this "continuous" mode - not tried it that much anymore. I noticed one problem that was in modified "generic_buffer.c" user space application while doing modifications for single shot mode. There was no space reserved for read buffer (variable called "data") nor in the patch. That was most likely the problem in continuous mode reading. At least it prevented single shot mode from working. In fact I would be quite fine working with single shot mode. However, there are major problems in adc driver (or iio bus driver). It does not matter whether I read in_voltage?_raw just from command line, using a script from command line or from application program. There are differences between them, though. I would say that script reading works the best.
For example running procedure:
cat in_voltage0..1_raw in continuous sequence having 250 ms between reads, I get
"cat: read error: Device or resource busy"
Error message pretty seldomly (as reported in wiki.tiprocessors.com/.../Processor_SDK_Linux_Kernel_Release_Notes) - approximately every 100th operation or more seldom.

However, if I re-produce same procedure in C program I will get this same error approximately every third operation, please, see listing below, where colon represents error reading. Note that this C application repeats reading at most 5 times in case of error. Otherwise timing is the same. This listing seems giving error rate 28/96, which looks pretty typical.
:::41.60, 24.02, :5.02, 3.32,
:::41.56, 24.00, 5.02, 3.32,
:41.60, 24.00, 5.02, 3.32,
::41.60, :24.01, 5.02, 3.32,
::41.60, :24.02, 5.02, 3.32,
41.60, :24.02, 5.01, 3.32,
:41.56, 24.02, 5.02, 3.31,
:41.60, 24.00, 5.02, 3.32,
:41.60, 24.00, 5.02, 3.32,
41.65, :24.02, 5.02, 3.32,
::41.65, :24.00, 5.02, 3.32,
:41.65, :24.01, 5.02, 3.32,
:41.69, :24.01, 5.01, 3.32,
41.56, 24.02, 5.02, 3.32,
::41.60, 24.02, 5.02, 3.32,
:41.60, 24.01, 5.02, 3.32,
:41.65, :24.01, 5.02, 3.32,

Although this is kind of annoying, I could work with it. However, something in this adc/tscadc driver has turned out very unstable. Kernel keeps going fine until I happen to read these raw registers - no matter how. I have never seen that first read hangs it, but after that, it can be just one isolated read after some minutes. Following is listing printed out when kernel panics after this hang. Note that I have note touched to drivers, just made device tree settings to map adc channels 0..3 for measurements and 4..7 for tsc (that I really don't have).

----------- kernel panic listing -----------
root@am335x-evm:/sys/devices/ocp/44e0d000.tscadc/TI-am335x-adc/iio:device0# cat in_voltage1_raw
[58197.968353] INFO: task cat:1629 blocked for more than 300 seconds.
[58197.974615] Not tainted 3.14.46 #1
[58197.978628] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[58197.986504] cat D c06107d4 0 1629 1618 0x00000000
[58197.993021] [<c06107d4>] (__schedule) from [<c03a2008>] (am335x_tsc_se_set_once+0xb0/0x100)
[58198.001491] [<c03a2008>] (am335x_tsc_se_set_once) from [<bf08653c>] (tiadc_read_raw+0xb8/0x18c [ti_am335x_adc])
[58198.011698] [<bf08653c>] (tiadc_read_raw [ti_am335x_adc]) from [<c0504b90>] (iio_read_channel_info+0x34/0x58)
[58198.021725] [<c0504b90>] (iio_read_channel_info) from [<c03814d8>] (dev_attr_show+0x1c/0x48)
[58198.030260] [<c03814d8>] (dev_attr_show) from [<c0141270>] (sysfs_kf_seq_show+0x80/0xf0)
[58198.038448] [<c0141270>] (sysfs_kf_seq_show) from [<c00ffb1c>] (seq_read+0x1f0/0x4a4)
[58198.046377] [<c00ffb1c>] (seq_read) from [<c00df924>] (do_readv_writev+0x1d4/0x214)
[58198.054124] [<c00df924>] (do_readv_writev) from [<c00df9a4>] (vfs_readv+0x40/0x64)
[58198.061780] [<c00df9a4>] (vfs_readv) from [<c0106e84>] (default_file_splice_read+0x204/0x308)
[58198.070391] [<c0106e84>] (default_file_splice_read) from [<c0105f98>] (splice_direct_to_actor+0x8c/0x1d4)
[58198.080047] [<c0105f98>] (splice_direct_to_actor) from [<c0107390>] (do_splice_direct+0x90/0xb8)
[58198.088919] [<c0107390>] (do_splice_direct) from [<c00df158>] (do_sendfile+0x194/0x31c)
[58198.096979] [<c00df158>] (do_sendfile) from [<c00dfe2c>] (SyS_sendfile64+0xd0/0xd4)
[58198.104727] [<c00dfe2c>] (SyS_sendfile64) from [<c000efe0>] (ret_fast_syscall+0x0/0x38)
[58198.112802] INFO: lockdep is turned off.
[58198.116753] Kernel panic - not syncing: hung_task: blocked tasks
[58198.122797] CPU: 0 PID: 498 Comm: khungtaskd Not tainted 3.14.46 #1
[58198.129126] [<c0014ce8>] (unwind_backtrace) from [<c001219c>] (show_stack+0x10/0x14)
[58198.136940] [<c001219c>] (show_stack) from [<c060b524>] (panic+0x9c/0x1f0)
[58198.143870] [<c060b524>] (panic) from [<c008fab4>] (watchdog+0x3a0/0x3f0)
[58198.150714] [<c008fab4>] (watchdog) from [<c00537a4>] (kthread+0xcc/0xe0)
[58198.157549] [<c00537a4>] (kthread) from [<c000f080>] (ret_from_fork+0x14/0x34)
[58797.599000] kmemleak: Cannot allocate a kmemleak_object structure

Is there anything I could check? Could the problem come from the fact that I have different channel mapping than in default settings? Or would it somehow be possible to switch off tsc and just have these adc measurements?

Thanks,
Matti

Even though that "mode" issue is not clear at all, I suppose, title is not covering my urgent problem any more. Title should be more like "Deadlock while reading from TI-am335x-adc in_voltageX_raw sources". Would this be more like business of Arago forum/linux-ti-staging 3.14? I'll try there.
Cheers,
Matti

Answer to my original question/title: Yes interface has changed. There is not mode node in sysfs for setting "single shot"/"continuous" modes. This appear from updated wiki: .processors.wiki.ti.com/.../Linux_Core_ADC_User%27s_Guide

I kindly got two patches from meta-arago forum that fixed dead-locking:

[1] patchwork.kernel.org/.../5582281

[2] attached /cfs-file/__key/communityserver-discussions-components-files/354/0081.v6_2D00_3_2D00_6_2D00_mfd_2D00_ti_5F00_am335x_5F00_tscadc_2D00_Remove_2D00_unwanted_2D00_reg_5F00_se_5F00_cache_2D00_save.patch.txt

Note that I had to change this attachment extension in order to get it attached.

Thanks,

Matti

As an answer to my original question/title: yes ADC interface has changed that can be verified from the up-to-date wiki: http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide

I kindly got two patches from meta-arago forum that fixed deadlocking issue:

[1] https://patchwork.kernel.org/patch/5582281/

[2] /cfs-file/__key/communityserver-discussions-components-files/354/3240.v6_2D00_3_2D00_6_2D00_mfd_2D00_ti_5F00_am335x_5F00_tscadc_2D00_Remove_2D00_unwanted_2D00_reg_5F00_se_5F00_cache_2D00_save.patch.txt

Thanks,

Matti

Hope this comes now through. I hope someone makes some kind of cleaning up with my verified answers.