BBB IIO ADC access not working

BBB IIO ADC access not working

[Greg Wilson-Lindberg]

Hi Jonathan, 
To recap my current problems, we are using all 3 of the ADC channels that are unused by the BBB for our system. One channel has an analog mux on it to allow selecting between 2 input pots. The other two channels are hooked up to pressure transducers.
 
I'm processing the channels in a routine that gets called from a timer every 100ms. I enable the IIO buffer to collect data and 100ms later read the samples and turn the buffer off again. I leave the buffer off for 400 ms and then go through the process again.  I do this enable, read, disable cycle to allow the touch screen enough time to gather data to properly handle touch screen events.
 
With this setup the system will work properly for a few seconds, and then the buffer/adc read process slows down so that it takes more than 2 seconds to process the two enable, read, disable cycles in my read state machine. When the slow down happens, the touch screen stops responding, and even mouse presses stop working, although the mouse pointer did continue to follow mouse movements and the screen continued to update properly.

Because of the size of the code I've posted it on pastebin: http://pastebin.com/TDRS1nu7
instead of including it here.

This is running on a Jessie debian system build from Robert C. Nelson, based on the 3.18 kernel.

I hope that you or someone else on the list can help me understand what is going on.
 
Greg Wilson-Lindberg
Sakura Finetek
310-783-5075

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 
Hi Jonathan,
I modified my code to only read the ADC channels once a second, and it is still
locking up the touch screen, although if takes longer now.

Again, any insight on what might be happening would be appreciated.

Regards,
Greg

> -----Original Message-----
> From: linux-iio-owner@vger.kernel.org 
> [mailto:linux-iio-owner@vger.kernel.org] On Behalf Of Greg 
> Wilson-Lindberg
> Sent: Friday, July 31, 2015 2:16 PM
> To: linux-iio@vger.kernel.org
> Subject: BBB IIO ADC access not working
> 
> Hi Jonathan,
> To recap my current problems, we are using all 3 of the ADC 
> channels that are unused by the BBB for our system. One 
> channel has an analog mux on it to allow selecting between 2 
> input pots. The other two channels are hooked up to pressure 
> transducers.
>  
> I'm processing the channels in a routine that gets called 
> from a timer every 100ms. I enable the IIO buffer to collect 
> data and 100ms later read the samples and turn the buffer off 
> again. I leave the buffer off for 400 ms and then go through 
> the process again.  I do this enable, read, disable cycle to 
> allow the touch screen enough time to gather data to properly 
> handle touch screen events.
>  
> With this setup the system will work properly for a few 
> seconds, and then the buffer/adc read process slows down so 
> that it takes more than 2 seconds to process the two enable, 
> read, disable cycles in my read state machine. When the slow 
> down happens, the touch screen stops responding, and even 
> mouse presses stop working, although the mouse pointer did 
> continue to follow mouse movements and the screen continued 
> to update properly.
> 
> Because of the size of the code I've posted it on pastebin: 
> http://pastebin.com/TDRS1nu7 instead of including it here.
> 
> This is running on a Jessie debian system build from Robert 
> C. Nelson, based on the 3.18 kernel.
> 
> I hope that you or someone else on the list can help me 
> understand what is going on.
>  
> Greg Wilson-Lindberg
> Sakura Finetek
> 310-783-5075
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-iio" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

Re: BBB IIO ADC access not working

[Daniel Baluta]

Hi Greg,

On Sat, Aug 1, 2015 at 12:15 AM, Greg Wilson-Lindberg
<GWilson@sakuraus.com> wrote:
> Hi Jonathan,
> To recap my current problems, we are using all 3 of the ADC channels that are unused by the BBB for our system. One channel has an analog mux on it to allow selecting between 2 input pots. The other two channels are hooked up to pressure transducers.

What devices and drivers are you exactly using?

>
> I'm processing the channels in a routine that gets called from a timer every 100ms. I enable the IIO buffer to collect data and 100ms later read the samples and turn the buffer off again. I leave the buffer off for 400 ms and then go through the process again.  I do this enable, read, disable cycle to allow the touch screen enough time to gather data to properly handle touch screen events.
>
> With this setup the system will work properly for a few seconds, and then the buffer/adc read process slows down so that it takes more than 2 seconds to process the two enable, read, disable cycles in my read state machine. When the slow down happens, the touch screen stops responding, and even mouse presses stop working, although the mouse pointer did continue to follow mouse movements and the screen continued to update properly.
>
> Because of the size of the code I've posted it on pastebin: http://pastebin.com/TDRS1nu7
> instead of including it here.
>
> This is running on a Jessie debian system build from Robert C. Nelson, based on the 3.18 kernel.
>
> I hope that you or someone else on the list can help me understand what is going on.

Could you provide your dmesg output and also cat /proc/interrupts.

thanks,
Daniel.

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

Hello Daniel,
See my comments in, line 

> -----Original Message-----
> From: Daniel Baluta [mailto:daniel.baluta@gmail.com] 
> Sent: Thursday, August 06, 2015 12:36 AM
> To: Greg Wilson-Lindberg
> Cc: linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> Hi Greg,
> 
> On Sat, Aug 1, 2015 at 12:15 AM, Greg Wilson-Lindberg 
> <GWilson@sakuraus.com> wrote:
> > Hi Jonathan,
> > To recap my current problems, we are using all 3 of the ADC 
> channels that are unused by the BBB for our system. One 
> channel has an analog mux on it to allow selecting between 2 
> input pots. The other two channels are hooked up to pressure 
> transducers.
> 
> What devices and drivers are you exactly using?

The pressure transducers are a MPXV7007GP and a MPXV7002GP. I'm 
not using any driver, just reading that analog input and processing
in my application.

> 
> >
> > I'm processing the channels in a routine that gets called 
> from a timer every 100ms. I enable the IIO buffer to collect 
> data and 100ms later read the samples and turn the buffer off 
> again. I leave the buffer off for 400 ms and then go through 
> the process again.  I do this enable, read, disable cycle to 
> allow the touch screen enough time to gather data to properly 
> handle touch screen events.
> >
> > With this setup the system will work properly for a few 
> seconds, and then the buffer/adc read process slows down so 
> that it takes more than 2 seconds to process the two enable, 
> read, disable cycles in my read state machine. When the slow 
> down happens, the touch screen stops responding, and even 
> mouse presses stop working, although the mouse pointer did 
> continue to follow mouse movements and the screen continued 
> to update properly.
> >
> > Because of the size of the code I've posted it on pastebin: 
> > http://pastebin.com/TDRS1nu7 instead of including it here.
> >
> > This is running on a Jessie debian system build from Robert 
> C. Nelson, based on the 3.18 kernel.
> >
> > I hope that you or someone else on the list can help me 
> understand what is going on.
> 
> Could you provide your dmesg output and also cat /proc/interrupts.

Because of the length I've posted the dmesg to: http://pastebin.com/v8kSbSAw
There aren't any new messages at the end of the dmesg output after the 
touch screen lockup.

cat /proc/interrupts:
            CPU0       
 23:          0      INTC   7  tps65217
 28:       7149      INTC  12  edma
 30:        155      INTC  14  edma_error
 32:      35030      INTC  16  TI-am335x-tsc, TI-am335x-adc
 33:        348      INTC  17  47400000.dma-controller
 34:          0      INTC  18  musb-hdrc.0.auto
 35:        203      INTC  19  musb-hdrc.1.auto
 36:          0      INTC  20  4a300000.pruss
 37:          0      INTC  21  4a300000.pruss
 38:          0      INTC  22  4a300000.pruss
 39:          0      INTC  23  4a300000.pruss
 40:          0      INTC  24  4a300000.pruss
 41:          0      INTC  25  4a300000.pruss
 42:          0      INTC  26  4a300000.pruss
 43:          0      INTC  27  4a300000.pruss
 44:       1790      INTC  28  mmc1
 46:          0      INTC  30  4819c000.i2c
 52:    3600215      INTC  36  tilcdc
 56:          0      INTC  40  4a100000.ethernet
 57:    1750286      INTC  41  4a100000.ethernet
 58:       1114      INTC  42  4a100000.ethernet
 59:          0      INTC  43  4a100000.ethernet
 80:      21331      INTC  64  mmc0
 84:   11923739      INTC  68  gp_timer
 86:    4399997      INTC  70  44e0b000.i2c
 88:        453      INTC  72  serial
 90:        951      INTC  74  serial
 91:          0      INTC  75  rtc0
 92:          0      INTC  76  rtc0
 93:          0      INTC  77  wkup_m3
 94:          1      INTC  78  wkup_m3_txev
125:          0      INTC 109  53100000.sham
127:          0      INTC 111  48310000.rng
150:          0  44e07000.gpio   6  mmc0
IPI0:          0  CPU wakeup interrupts
IPI1:          0  Timer broadcast interrupts
IPI2:          0  Rescheduling interrupts
IPI3:          0  Function call interrupts
IPI4:          0  Single function call interrupts
IPI5:          0  CPU stop interrupts
IPI6:          0  IRQ work interrupts
IPI7:          0  completion interrupts
Err:          0 

Please let me know if there is any thing else that I can provide.
Regards,
Greg

> 
> thanks,
> Daniel.
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Thu, Aug 06, 2015 at 08:42:21AM -0700, Greg Wilson-Lindberg wrote:
> Hello Daniel,
> See my comments in, line 
> 
> > -----Original Message-----
> > From: Daniel Baluta [mailto:daniel.baluta@gmail.com] 
> > Sent: Thursday, August 06, 2015 12:36 AM
> > To: Greg Wilson-Lindberg
> > Cc: linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > Hi Greg,
> > 
> > On Sat, Aug 1, 2015 at 12:15 AM, Greg Wilson-Lindberg 
> > <GWilson@sakuraus.com> wrote:
> > > Hi Jonathan,
> > > To recap my current problems, we are using all 3 of the ADC 
> > channels that are unused by the BBB for our system. One 
> > channel has an analog mux on it to allow selecting between 2 
> > input pots. The other two channels are hooked up to pressure 
> > transducers.
> > 
> > What devices and drivers are you exactly using?
> 
> The pressure transducers are a MPXV7007GP and a MPXV7002GP. I'm 
> not using any driver, just reading that analog input and processing
> in my application.
> 
> > 
> > >
> > > I'm processing the channels in a routine that gets called 
> > from a timer every 100ms. I enable the IIO buffer to collect 
> > data and 100ms later read the samples and turn the buffer off 
> > again. I leave the buffer off for 400 ms and then go through 
> > the process again.  I do this enable, read, disable cycle to 
> > allow the touch screen enough time to gather data to properly 
> > handle touch screen events.
> > >
> > > With this setup the system will work properly for a few 
> > seconds, and then the buffer/adc read process slows down so 
> > that it takes more than 2 seconds to process the two enable, 
> > read, disable cycles in my read state machine. When the slow 
> > down happens, the touch screen stops responding, and even 
> > mouse presses stop working, although the mouse pointer did 
> > continue to follow mouse movements and the screen continued 
> > to update properly.
> > >
> > > Because of the size of the code I've posted it on pastebin: 
> > > http://pastebin.com/TDRS1nu7 instead of including it here.
> > >
> > > This is running on a Jessie debian system build from Robert 
> > C. Nelson, based on the 3.18 kernel.

The kernel messages say otherwise:
[    0.000000] Linux version 3.14.40-ti-r62 (root@a4-imx6q-wandboard-2gb) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT Thu Apr 30 18:28:06 UTC 2015

Here are a few messages that I noticed that are related to the tsadc:
[    2.838041] TI-am335x-tsc TI-am335x-tsc: ti,charge-delay not specified
[    2.838401] input: ti-tsc as /devices/ocp.3/44e0d000.tscadc/TI-am335x-tsc/input/input0

Something to try is specifying the ti,charge-delay in the appropriate
device tree file.

IE:
ti,charge-delay = <0xB000>;

Increasing this delay slows the touchscreen response time but may help in
this situation.

> > > I hope that you or someone else on the list can help me 
> > understand what is going on.
> > 
> > Could you provide your dmesg output and also cat /proc/interrupts.
> 
> Because of the length I've posted the dmesg to: http://pastebin.com/v8kSbSAw
> There aren't any new messages at the end of the dmesg output after the 
> touch screen lockup.
> 
> cat /proc/interrupts:
>             CPU0       
>  23:          0      INTC   7  tps65217
>  28:       7149      INTC  12  edma
>  30:        155      INTC  14  edma_error
>  32:      35030      INTC  16  TI-am335x-tsc, TI-am335x-adc
>  33:        348      INTC  17  47400000.dma-controller
>  34:          0      INTC  18  musb-hdrc.0.auto
>  35:        203      INTC  19  musb-hdrc.1.auto
>  36:          0      INTC  20  4a300000.pruss
>  37:          0      INTC  21  4a300000.pruss
>  38:          0      INTC  22  4a300000.pruss
>  39:          0      INTC  23  4a300000.pruss
>  40:          0      INTC  24  4a300000.pruss
>  41:          0      INTC  25  4a300000.pruss
>  42:          0      INTC  26  4a300000.pruss
>  43:          0      INTC  27  4a300000.pruss
>  44:       1790      INTC  28  mmc1
>  46:          0      INTC  30  4819c000.i2c
>  52:    3600215      INTC  36  tilcdc
>  56:          0      INTC  40  4a100000.ethernet
>  57:    1750286      INTC  41  4a100000.ethernet
>  58:       1114      INTC  42  4a100000.ethernet
>  59:          0      INTC  43  4a100000.ethernet
>  80:      21331      INTC  64  mmc0
>  84:   11923739      INTC  68  gp_timer
>  86:    4399997      INTC  70  44e0b000.i2c
>  88:        453      INTC  72  serial
>  90:        951      INTC  74  serial
>  91:          0      INTC  75  rtc0
>  92:          0      INTC  76  rtc0
>  93:          0      INTC  77  wkup_m3
>  94:          1      INTC  78  wkup_m3_txev
> 125:          0      INTC 109  53100000.sham
> 127:          0      INTC 111  48310000.rng
> 150:          0  44e07000.gpio   6  mmc0
> IPI0:          0  CPU wakeup interrupts
> IPI1:          0  Timer broadcast interrupts
> IPI2:          0  Rescheduling interrupts
> IPI3:          0  Function call interrupts
> IPI4:          0  Single function call interrupts
> IPI5:          0  CPU stop interrupts
> IPI6:          0  IRQ work interrupts
> IPI7:          0  completion interrupts
> Err:          0 
> 
> Please let me know if there is any thing else that I can provide.
> Regards,
> Greg
> 
> > 
> > thanks,
> > Daniel.
> > --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

Hello Michael,  

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Thursday, August 06, 2015 11:08 AM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Thu, Aug 06, 2015 at 08:42:21AM -0700, Greg Wilson-Lindberg wrote:
> > Hello Daniel,
> > See my comments in, line
> > 
> > > -----Original Message-----
> > > From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> > > Sent: Thursday, August 06, 2015 12:36 AM
> > > To: Greg Wilson-Lindberg
> > > Cc: linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > Hi Greg,
> > > 
> > > On Sat, Aug 1, 2015 at 12:15 AM, Greg Wilson-Lindberg 
> > > <GWilson@sakuraus.com> wrote:
> > > > Hi Jonathan,
> > > > To recap my current problems, we are using all 3 of the ADC
> > > channels that are unused by the BBB for our system. One 
> channel has 
> > > an analog mux on it to allow selecting between 2 input pots. The 
> > > other two channels are hooked up to pressure transducers.
> > > 
> > > What devices and drivers are you exactly using?
> > 
> > The pressure transducers are a MPXV7007GP and a MPXV7002GP. I'm not 
> > using any driver, just reading that analog input and 
> processing in my 
> > application.
> > 
> > > 
> > > >
> > > > I'm processing the channels in a routine that gets called
> > > from a timer every 100ms. I enable the IIO buffer to collect data 
> > > and 100ms later read the samples and turn the buffer off again. I 
> > > leave the buffer off for 400 ms and then go through the process 
> > > again.  I do this enable, read, disable cycle to allow the touch 
> > > screen enough time to gather data to properly handle touch screen 
> > > events.
> > > >
> > > > With this setup the system will work properly for a few
> > > seconds, and then the buffer/adc read process slows down 
> so that it 
> > > takes more than 2 seconds to process the two enable, 
> read, disable 
> > > cycles in my read state machine. When the slow down happens, the 
> > > touch screen stops responding, and even mouse presses 
> stop working, 
> > > although the mouse pointer did continue to follow mouse movements 
> > > and the screen continued to update properly.
> > > >
> > > > Because of the size of the code I've posted it on pastebin: 
> > > > http://pastebin.com/TDRS1nu7 instead of including it here.
> > > >
> > > > This is running on a Jessie debian system build from Robert
> > > C. Nelson, based on the 3.18 kernel.
> 
> The kernel messages say otherwise:
> [    0.000000] Linux version 3.14.40-ti-r62 
> (root@a4-imx6q-wandboard-2gb) (gcc version 4.9.2 (Debian 
> 4.9.2-10) ) #1 SMP PREEMPT Thu Apr 30 18:28:06 UTC 2015

I guess I got messed up, I had been messaging RCN referring to 3.8/3.14, and I must have put them together.

> 
> Here are a few messages that I noticed that are related to the tsadc:
> [    2.838041] TI-am335x-tsc TI-am335x-tsc: ti,charge-delay 
> not specified
> [    2.838401] input: ti-tsc as 
> /devices/ocp.3/44e0d000.tscadc/TI-am335x-tsc/input/input0
> 
> Something to try is specifying the ti,charge-delay in the appropriate
> device tree file.
> 
> IE:
> ti,charge-delay = <0xB000>;
> 
> Increasing this delay slows the touchscreen response time but 
> may help in
> this situation.

I added the charge-delay, it does make the system last longer before the touch screen locks up, but it does still lock up.  The program that I'm testing this from is written in qt, the main GUI loop is still running, even though the touch screen has locked up, so the calls to the IIO lib are still being made, although I don't know if I'm getting back the same data as the last time it worked, or I'm not getting back any data at all.

I tested it with the sampling set to twice a second, and the touch screen locked up more quickly than when set to only sample once a second.

Regards,
Greg

> 
> > > > I hope that you or someone else on the list can help me 
> > > understand what is going on.
> > > 
> > > Could you provide your dmesg output and also cat /proc/interrupts.
> > 
> > Because of the length I've posted the dmesg to: 
> http://pastebin.com/v8kSbSAw
> > There aren't any new messages at the end of the dmesg 
> output after the 
> > touch screen lockup.
> > 
> > cat /proc/interrupts:
> >             CPU0       
> >  23:          0      INTC   7  tps65217
> >  28:       7149      INTC  12  edma
> >  30:        155      INTC  14  edma_error
> >  32:      35030      INTC  16  TI-am335x-tsc, TI-am335x-adc
> >  33:        348      INTC  17  47400000.dma-controller
> >  34:          0      INTC  18  musb-hdrc.0.auto
> >  35:        203      INTC  19  musb-hdrc.1.auto
> >  36:          0      INTC  20  4a300000.pruss
> >  37:          0      INTC  21  4a300000.pruss
> >  38:          0      INTC  22  4a300000.pruss
> >  39:          0      INTC  23  4a300000.pruss
> >  40:          0      INTC  24  4a300000.pruss
> >  41:          0      INTC  25  4a300000.pruss
> >  42:          0      INTC  26  4a300000.pruss
> >  43:          0      INTC  27  4a300000.pruss
> >  44:       1790      INTC  28  mmc1
> >  46:          0      INTC  30  4819c000.i2c
> >  52:    3600215      INTC  36  tilcdc
> >  56:          0      INTC  40  4a100000.ethernet
> >  57:    1750286      INTC  41  4a100000.ethernet
> >  58:       1114      INTC  42  4a100000.ethernet
> >  59:          0      INTC  43  4a100000.ethernet
> >  80:      21331      INTC  64  mmc0
> >  84:   11923739      INTC  68  gp_timer
> >  86:    4399997      INTC  70  44e0b000.i2c
> >  88:        453      INTC  72  serial
> >  90:        951      INTC  74  serial
> >  91:          0      INTC  75  rtc0
> >  92:          0      INTC  76  rtc0
> >  93:          0      INTC  77  wkup_m3
> >  94:          1      INTC  78  wkup_m3_txev
> > 125:          0      INTC 109  53100000.sham
> > 127:          0      INTC 111  48310000.rng
> > 150:          0  44e07000.gpio   6  mmc0
> > IPI0:          0  CPU wakeup interrupts
> > IPI1:          0  Timer broadcast interrupts
> > IPI2:          0  Rescheduling interrupts
> > IPI3:          0  Function call interrupts
> > IPI4:          0  Single function call interrupts
> > IPI5:          0  CPU stop interrupts
> > IPI6:          0  IRQ work interrupts
> > IPI7:          0  completion interrupts
> > Err:          0 
> > 
> > Please let me know if there is any thing else that I can provide.
> > Regards,
> > Greg
> > 
> > > 
> > > thanks,
> > > Daniel.
> > > --
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-iio" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Mon, Aug 10, 2015 at 03:22:58PM -0700, Greg Wilson-Lindberg wrote:
> I added the charge-delay, it does make the system last longer before the touch screen locks up, but it does still lock up.  The program that I'm testing this from is written in qt, the main GUI loop is still running, even though the touch screen has locked up, so the calls to the IIO lib are still being made, although I don't know if I'm getting back the same data as the last time it worked, or I'm not getting back any data at all.
> 
> I tested it with the sampling set to twice a second, and the touch screen locked up more quickly than when set to only sample once a second.
>

Odd.

Try increasing the charge-delay and see if you can find a value where it stops happening.

Something tells me that it won't fix the issue.

Where is the source tree for this kernel?
Which dtb are you using?
 
> Regards,
> Greg
> 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

Hello Michael,

.....
> Try increasing the charge-delay and see if you can find a 
> value where it stops happening.
> 
> Something tells me that it won't fix the issue.
> 
> Where is the source tree for this kernel?
> Which dtb are you using?
>  

I increased the charge-delay to 0x10000 and left the system over night with no user
interaction and it was locked up this morning, I think I'm going to have to agree 
that changing that to a larger number will not fix the problem.

Here is a link to the dts that we use:
http://pastebin.com/5nU27sML
I did not include the standard dtsi files that we include from the linux source tree,
just the files that we built ourselves or that we modified.

RCN replied thusly to my request for the source tree:
   Here's the kernel source, the config we use is "bb.org_defconfig"
   https://github.com/beagleboard/linux/tree/3.14.40-ti-r62

Thanks for your help in tracking down this problem.

Regards,
Greg

Re: BBB IIO ADC access not working

[Michael Welling]

On Tue, Aug 11, 2015 at 09:00:21AM -0700, Greg Wilson-Lindberg wrote:
> Hello Michael,
> 
> .....
> > Try increasing the charge-delay and see if you can find a 
> > value where it stops happening.
> > 
> > Something tells me that it won't fix the issue.
> > 
> > Where is the source tree for this kernel?
> > Which dtb are you using?
> >  
> 
> I increased the charge-delay to 0x10000 and left the system over night with no user
> interaction and it was locked up this morning, I think I'm going to have to agree 
> that changing that to a larger number will not fix the problem.
> 
> Here is a link to the dts that we use:
> http://pastebin.com/5nU27sML
> I did not include the standard dtsi files that we include from the linux source tree,
> just the files that we built ourselves or that we modified.

I do not see the modification that you made to the touchscreen registration.

Guessing you modified this file for the charge-delay:
https://github.com/beagleboard/linux/blob/3.14.40-ti-r62/arch/arm/boot/dts/am335x-bone-ti-tscadc-4-wire.dtsi

> 
> RCN replied thusly to my request for the source tree:
>    Here's the kernel source, the config we use is "bb.org_defconfig"
>    https://github.com/beagleboard/linux/tree/3.14.40-ti-r62
> 
> Thanks for your help in tracking down this problem.

I will compare the drivers in this kernel to the latest work in the mainline.

> 
> Regards,
> Greg

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

Hi Michael, 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Tuesday, August 11, 2015 10:03 AM
> To: Greg Wilson-Lindberg
> Cc: Michael Welling; Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Tue, Aug 11, 2015 at 09:00:21AM -0700, Greg Wilson-Lindberg wrote:
> > Hello Michael,
> > 
> > .....
> > > Try increasing the charge-delay and see if you can find a value 
> > > where it stops happening.
> > > 
> > > Something tells me that it won't fix the issue.
> > > 
> > > Where is the source tree for this kernel?
> > > Which dtb are you using?
> > >  
> > 
> > I increased the charge-delay to 0x10000 and left the system 
> over night 
> > with no user interaction and it was locked up this morning, I think 
> > I'm going to have to agree that changing that to a larger 
> number will not fix the problem.
> > 
> > Here is a link to the dts that we use:
> > http://pastebin.com/5nU27sML
> > I did not include the standard dtsi files that we include from the 
> > linux source tree, just the files that we built ourselves 
> or that we modified.
> 
> I do not see the modification that you made to the 
> touchscreen registration.

We haven't modified the touch screen registration, we use xinput_calibrator for the calibration.
> 
> Guessing you modified this file for the charge-delay:
> https://github.com/beagleboard/linux/blob/3.14.40-ti-r62/arch/
> arm/boot/dts/am335x-bone-ti-tscadc-4-wire.dtsi

And you are correct, I forgot that I had added the charge-delay parameter to the 
am335x-bone-ti-tscadc-4-wire.dtsi file, sorry.

> 
> > 
> > RCN replied thusly to my request for the source tree:
> >    Here's the kernel source, the config we use is "bb.org_defconfig"
> >    https://github.com/beagleboard/linux/tree/3.14.40-ti-r62
> > 
> > Thanks for your help in tracking down this problem.
> 
> I will compare the drivers in this kernel to the latest work 
> in the mainline.
> 
> > 
> > Regards,
> > Greg
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Tue, Aug 11, 2015 at 10:08:39AM -0700, Greg Wilson-Lindberg wrote:
> Hi Michael, 
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Tuesday, August 11, 2015 10:03 AM
> > To: Greg Wilson-Lindberg
> > Cc: Michael Welling; Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Tue, Aug 11, 2015 at 09:00:21AM -0700, Greg Wilson-Lindberg wrote:
> > > Hello Michael,
> > > 
> > > .....
> > > > Try increasing the charge-delay and see if you can find a value 
> > > > where it stops happening.
> > > > 
> > > > Something tells me that it won't fix the issue.
> > > > 
> > > > Where is the source tree for this kernel?
> > > > Which dtb are you using?
> > > >  
> > > 
> > > I increased the charge-delay to 0x10000 and left the system 
> > over night 
> > > with no user interaction and it was locked up this morning, I think 
> > > I'm going to have to agree that changing that to a larger 
> > number will not fix the problem.
> > > 
> > > Here is a link to the dts that we use:
> > > http://pastebin.com/5nU27sML
> > > I did not include the standard dtsi files that we include from the 
> > > linux source tree, just the files that we built ourselves 
> > or that we modified.
> > 
> > I do not see the modification that you made to the 
> > touchscreen registration.
> 
> We haven't modified the touch screen registration, we use xinput_calibrator for the calibration.
> > 
> > Guessing you modified this file for the charge-delay:
> > https://github.com/beagleboard/linux/blob/3.14.40-ti-r62/arch/
> > arm/boot/dts/am335x-bone-ti-tscadc-4-wire.dtsi
> 
> And you are correct, I forgot that I had added the charge-delay parameter to the 
> am335x-bone-ti-tscadc-4-wire.dtsi file, sorry.
> 
> > 
> > > 
> > > RCN replied thusly to my request for the source tree:
> > >    Here's the kernel source, the config we use is "bb.org_defconfig"
> > >    https://github.com/beagleboard/linux/tree/3.14.40-ti-r62
> > > 
> > > Thanks for your help in tracking down this problem.
> > 
> > I will compare the drivers in this kernel to the latest work 
> > in the mainline.

Looking at the commit logs, I see no mention of this type of behavior in either
kernel.


Here is something that never landed in the mainline kernel:
https://github.com/beagleboard/linux/commit/e655e2f723a4e78a47868f766e4c141deca5e234

Have you tried a more recent kernel release to see if this behavior is still
occurring?

> > 
> > > 
> > > Regards,
> > > Greg
> > 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

Hello Michael, 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Tuesday, August 11, 2015 10:44 AM
> To: Greg Wilson-Lindberg
> Cc: Michael Welling; Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Tue, Aug 11, 2015 at 10:08:39AM -0700, Greg Wilson-Lindberg wrote:
> > Hi Michael,
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Tuesday, August 11, 2015 10:03 AM
> > > To: Greg Wilson-Lindberg
> > > Cc: Michael Welling; Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > On Tue, Aug 11, 2015 at 09:00:21AM -0700, Greg 
> Wilson-Lindberg wrote:
> > > > Hello Michael,
> > > > 
> > > > .....
> > > > > Try increasing the charge-delay and see if you can 
> find a value 
> > > > > where it stops happening.
> > > > > 
> > > > > Something tells me that it won't fix the issue.
> > > > > 
> > > > > Where is the source tree for this kernel?
> > > > > Which dtb are you using?
> > > > >  
> > > > 
> > > > I increased the charge-delay to 0x10000 and left the system
> > > over night
> > > > with no user interaction and it was locked up this morning, I 
> > > > think I'm going to have to agree that changing that to a larger
> > > number will not fix the problem.
> > > > 
> > > > Here is a link to the dts that we use:
> > > > http://pastebin.com/5nU27sML
> > > > I did not include the standard dtsi files that we 
> include from the 
> > > > linux source tree, just the files that we built ourselves
> > > or that we modified.
> > > 
> > > I do not see the modification that you made to the touchscreen 
> > > registration.
> > 
> > We haven't modified the touch screen registration, we use 
> xinput_calibrator for the calibration.
> > > 
> > > Guessing you modified this file for the charge-delay:
> > > https://github.com/beagleboard/linux/blob/3.14.40-ti-r62/arch/
> > > arm/boot/dts/am335x-bone-ti-tscadc-4-wire.dtsi
> > 
> > And you are correct, I forgot that I had added the charge-delay 
> > parameter to the am335x-bone-ti-tscadc-4-wire.dtsi file, sorry.
> > 
> > > 
> > > > 
> > > > RCN replied thusly to my request for the source tree:
> > > >    Here's the kernel source, the config we use is 
> "bb.org_defconfig"
> > > >    https://github.com/beagleboard/linux/tree/3.14.40-ti-r62
> > > > 
> > > > Thanks for your help in tracking down this problem.
> > > 
> > > I will compare the drivers in this kernel to the latest 
> work in the 
> > > mainline.
> 
> Looking at the commit logs, I see no mention of this type of 
> behavior in either kernel.
> 
> 
> Here is something that never landed in the mainline kernel:
> https://github.com/beagleboard/linux/commit/e655e2f723a4e78a47
> 868f766e4c141deca5e234
> 
> Have you tried a more recent kernel release to see if this 
> behavior is still occurring?

I tried a current debian release from RCN with kernel 4.1, touch screen
and mouse still locked up.

Regards,
Greg

> 
> > > 
> > > > 
> > > > Regards,
> > > > Greg
> > > 
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Thu, Aug 13, 2015 at 04:00:08PM -0700, Greg Wilson-Lindberg wrote:
> Hello Michael, 
> 
> I tried a current debian release from RCN with kernel 4.1, touch screen
> and mouse still locked up.
>

I will do my best to replicate the issue on a target here.
 
> Regards,
> Greg
> 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

Thank you very much,
Regards, Greg 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Friday, August 14, 2015 11:40 AM
> To: Greg Wilson-Lindberg
> Cc: Michael Welling; Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Thu, Aug 13, 2015 at 04:00:08PM -0700, Greg Wilson-Lindberg wrote:
> > Hello Michael,
> > 
> > I tried a current debian release from RCN with kernel 4.1, touch 
> > screen and mouse still locked up.
> >
> 
> I will do my best to replicate the issue on a target here.
>  
> > Regards,
> > Greg
> > 
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg Wilson-Lindberg wrote:
> Thank you very much,
> Regards, Greg 
>

To replicate the issue I did the following:

- Started a touchscreen enabled application
ts_test

- In another terminal started a dump of /dev/iio:device0
hexdump -C /dev/iio\:device0

- In yet another terminal enable the buffer
cd /sys/bus/iio/devices/iio\:device0
echo 1 > scan_elements/in_voltage4_en
echo 1 > buffer/enable

Once the buffer is enabled the hexdump window starts spewing out readings as
expected. The touchscreen is unresponsive as expected.

Then I started occassionally enabling and disabling the buffer and noticed
something very off. When enabling the buffer sometimes the readings from
the hexdump would start and abruptly stop. In this state the entire system
is nonresponsive. None of the terminals are excepting input and the system is
in complete deadlock. Then I touched the screen and the deadlock is lifted
and readings started again.

As if the behavior was not weird enough, occassionally after the buffer is
disabled, the touchscreen readings are mangled.

Next step, figure out what is going wrong.

> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Friday, August 14, 2015 11:40 AM
> > To: Greg Wilson-Lindberg
> > Cc: Michael Welling; Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Thu, Aug 13, 2015 at 04:00:08PM -0700, Greg Wilson-Lindberg wrote:
> > > Hello Michael,
> > > 
> > > I tried a current debian release from RCN with kernel 4.1, touch 
> > > screen and mouse still locked up.
> > >
> > 
> > I will do my best to replicate the issue on a target here.
> >  
> > > Regards,
> > > Greg
> > > 
> > 

Re: BBB IIO ADC access not working

[Michael Welling]

On Fri, Aug 14, 2015 at 03:40:18PM -0500, Michael Welling wrote:
> On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg Wilson-Lindberg wrote:
> > Thank you very much,
> > Regards, Greg 
> >
> 
> To replicate the issue I did the following:
> 
> - Started a touchscreen enabled application
> ts_test
> 
> - In another terminal started a dump of /dev/iio:device0
> hexdump -C /dev/iio\:device0
> 
> - In yet another terminal enable the buffer
> cd /sys/bus/iio/devices/iio\:device0
> echo 1 > scan_elements/in_voltage4_en
> echo 1 > buffer/enable
> 
> Once the buffer is enabled the hexdump window starts spewing out readings as
> expected. The touchscreen is unresponsive as expected.
> 
> Then I started occassionally enabling and disabling the buffer and noticed
> something very off. When enabling the buffer sometimes the readings from
> the hexdump would start and abruptly stop. In this state the entire system
> is nonresponsive. None of the terminals are excepting input and the system is
> in complete deadlock. Then I touched the screen and the deadlock is lifted
> and readings started again.
> 
> As if the behavior was not weird enough, occassionally after the buffer is
> disabled, the touchscreen readings are mangled.
> 
> Next step, figure out what is going wrong.
>

It seems the drivers are being flooded with IRQENB_EOS interrupts causing
the lockup.

By adding the following to the tiadc_irq_h function the lockup stops.

.
.
        if (status & IRQENB_EOS) {
                tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
                return IRQ_HANDLED;
        }
.
.

Now the IRQENB_EOS is also handled in the touchscreen driver so this is
may not be an appropriate fix but at least it fixes the lockup.

Try adding the snippet above to ti_am335x_adc.c and see if it makes
your program stop locking up.

Then we need to find a solution that makes the maintainers happy.

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> On Fri, Aug 14, 2015 at 03:40:18PM -0500, Michael Welling wrote:
> > On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg 
> Wilson-Lindberg wrote:
> > > Thank you very much,
> > > Regards, Greg
> > >
> > 
> > To replicate the issue I did the following:
> > 
> > - Started a touchscreen enabled application ts_test
> > 
> > - In another terminal started a dump of /dev/iio:device0 hexdump -C 
> > /dev/iio\:device0
> > 
> > - In yet another terminal enable the buffer cd 
> > /sys/bus/iio/devices/iio\:device0 echo 1 > 
> > scan_elements/in_voltage4_en echo 1 > buffer/enable
> > 
> > Once the buffer is enabled the hexdump window starts spewing out 
> > readings as expected. The touchscreen is unresponsive as expected.
> > 
> > Then I started occassionally enabling and disabling the buffer and 
> > noticed something very off. When enabling the buffer sometimes the 
> > readings from the hexdump would start and abruptly stop. In 
> this state 
> > the entire system is nonresponsive. None of the terminals are 
> > excepting input and the system is in complete deadlock. 
> Then I touched 
> > the screen and the deadlock is lifted and readings started again.
> > 
> > As if the behavior was not weird enough, occassionally after the 
> > buffer is disabled, the touchscreen readings are mangled.
> > 
> > Next step, figure out what is going wrong.
> >
> 
> It seems the drivers are being flooded with IRQENB_EOS 
> interrupts causing the lockup.
> 
> By adding the following to the tiadc_irq_h function the lockup stops.
> 
> .
> .
>         if (status & IRQENB_EOS) {
>                 tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
>                 return IRQ_HANDLED;
>         }
> .
> .
> 
> Now the IRQENB_EOS is also handled in the touchscreen driver 
> so this is may not be an appropriate fix but at least it 
> fixes the lockup.
> 
> Try adding the snippet above to ti_am335x_adc.c and see if it 
> makes your program stop locking up.
> 
> Then we need to find a solution that makes the maintainers happy.
> 
> 

I've applied this to the ti_am335x_adc.c driver in both the 3.14.49-ti-r62 & 3.14.49-ti-r73 kernels from RCN and they both suffered touch screen lockups over night.

Here is what I did:
static irqreturn_t tiadc_irq_h(int irq, void *private)
{
	struct iio_dev *indio_dev = private;
	struct tiadc_device *adc_dev = iio_priv(indio_dev);
	unsigned int status, config;
	status = tiadc_readl(adc_dev, REG_IRQSTATUS);

	/*
	 * ADC and touchscreen share the IRQ line.
	 * FIFO0 interrupts are used by TSC. Handle FIFO1 IRQs here only
	 */
	if (status & IRQENB_FIFO1OVRRUN) {
		/* FIFO Overrun. Clear flag. Disable/Enable ADC to recover */
		config = tiadc_readl(adc_dev, REG_CTRL);
		config &= ~(CNTRLREG_TSCSSENB);
		tiadc_writel(adc_dev, REG_CTRL, config);
		tiadc_writel(adc_dev, REG_IRQSTATUS, IRQENB_FIFO1OVRRUN
				| IRQENB_FIFO1UNDRFLW | IRQENB_FIFO1THRES);
		tiadc_writel(adc_dev, REG_CTRL, (config | CNTRLREG_TSCSSENB));
		return IRQ_HANDLED;
	} else if (status & IRQENB_FIFO1THRES) {
		/* Disable irq and wake worker thread */
		tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_FIFO1THRES);
		return IRQ_WAKE_THREAD;
	}

    if (status & IRQENB_EOS) {
        tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
        return IRQ_HANDLED;
    }

    return IRQ_NONE;
}

Regards,
Greg

Re: BBB IIO ADC access not working

[Michael Welling]

On Tue, Aug 18, 2015 at 09:06:20AM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > On Fri, Aug 14, 2015 at 03:40:18PM -0500, Michael Welling wrote:
> > > On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg 
> > Wilson-Lindberg wrote:
> > > > Thank you very much,
> > > > Regards, Greg
> > > >
> > > 
> > > To replicate the issue I did the following:
> > > 
> > > - Started a touchscreen enabled application ts_test
> > > 
> > > - In another terminal started a dump of /dev/iio:device0 hexdump -C 
> > > /dev/iio\:device0
> > > 
> > > - In yet another terminal enable the buffer cd 
> > > /sys/bus/iio/devices/iio\:device0 echo 1 > 
> > > scan_elements/in_voltage4_en echo 1 > buffer/enable
> > > 
> > > Once the buffer is enabled the hexdump window starts spewing out 
> > > readings as expected. The touchscreen is unresponsive as expected.
> > > 
> > > Then I started occassionally enabling and disabling the buffer and 
> > > noticed something very off. When enabling the buffer sometimes the 
> > > readings from the hexdump would start and abruptly stop. In 
> > this state 
> > > the entire system is nonresponsive. None of the terminals are 
> > > excepting input and the system is in complete deadlock. 
> > Then I touched 
> > > the screen and the deadlock is lifted and readings started again.
> > > 
> > > As if the behavior was not weird enough, occassionally after the 
> > > buffer is disabled, the touchscreen readings are mangled.
> > > 
> > > Next step, figure out what is going wrong.
> > >
> > 
> > It seems the drivers are being flooded with IRQENB_EOS 
> > interrupts causing the lockup.
> > 
> > By adding the following to the tiadc_irq_h function the lockup stops.
> > 
> > .
> > .
> >         if (status & IRQENB_EOS) {
> >                 tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> >                 return IRQ_HANDLED;
> >         }
> > .
> > .
> > 
> > Now the IRQENB_EOS is also handled in the touchscreen driver 
> > so this is may not be an appropriate fix but at least it 
> > fixes the lockup.
> > 
> > Try adding the snippet above to ti_am335x_adc.c and see if it 
> > makes your program stop locking up.
> > 
> > Then we need to find a solution that makes the maintainers happy.
> > 
> > 
> 
> I've applied this to the ti_am335x_adc.c driver in both the 3.14.49-ti-r62 & 3.14.49-ti-r73 kernels from RCN and they both suffered touch screen lockups over night.

This is disturbing. Do you have any idea how long it takes before the lockup occurs?

Previously it was in a few seconds so there is obviously some improvement.

Is the mouse locked as well after the overnight test?

> 
> Here is what I did:
> static irqreturn_t tiadc_irq_h(int irq, void *private)
> {
> 	struct iio_dev *indio_dev = private;
> 	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> 	unsigned int status, config;
> 	status = tiadc_readl(adc_dev, REG_IRQSTATUS);
> 
> 	/*
> 	 * ADC and touchscreen share the IRQ line.
> 	 * FIFO0 interrupts are used by TSC. Handle FIFO1 IRQs here only
> 	 */
> 	if (status & IRQENB_FIFO1OVRRUN) {
> 		/* FIFO Overrun. Clear flag. Disable/Enable ADC to recover */
> 		config = tiadc_readl(adc_dev, REG_CTRL);
> 		config &= ~(CNTRLREG_TSCSSENB);
> 		tiadc_writel(adc_dev, REG_CTRL, config);
> 		tiadc_writel(adc_dev, REG_IRQSTATUS, IRQENB_FIFO1OVRRUN
> 				| IRQENB_FIFO1UNDRFLW | IRQENB_FIFO1THRES);
> 		tiadc_writel(adc_dev, REG_CTRL, (config | CNTRLREG_TSCSSENB));
> 		return IRQ_HANDLED;
> 	} else if (status & IRQENB_FIFO1THRES) {
> 		/* Disable irq and wake worker thread */
> 		tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_FIFO1THRES);
> 		return IRQ_WAKE_THREAD;
> 	}
> 
>     if (status & IRQENB_EOS) {
>         tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
>         return IRQ_HANDLED;
>     }
> 
>     return IRQ_NONE;
> }
> 
> Regards,
> Greg

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Tuesday, August 18, 2015 9:29 AM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Tue, Aug 18, 2015 at 09:06:20AM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > On Fri, Aug 14, 2015 at 03:40:18PM -0500, Michael Welling wrote:
> > > > On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg
> > > Wilson-Lindberg wrote:
> > > > > Thank you very much,
> > > > > Regards, Greg
> > > > >
> > > > 
> > > > To replicate the issue I did the following:
> > > > 
> > > > - Started a touchscreen enabled application ts_test
> > > > 
> > > > - In another terminal started a dump of 
> /dev/iio:device0 hexdump 
> > > > -C /dev/iio\:device0
> > > > 
> > > > - In yet another terminal enable the buffer cd 
> > > > /sys/bus/iio/devices/iio\:device0 echo 1 > 
> > > > scan_elements/in_voltage4_en echo 1 > buffer/enable
> > > > 
> > > > Once the buffer is enabled the hexdump window starts 
> spewing out 
> > > > readings as expected. The touchscreen is unresponsive 
> as expected.
> > > > 
> > > > Then I started occassionally enabling and disabling the 
> buffer and 
> > > > noticed something very off. When enabling the buffer 
> sometimes the 
> > > > readings from the hexdump would start and abruptly stop. In
> > > this state
> > > > the entire system is nonresponsive. None of the terminals are 
> > > > excepting input and the system is in complete deadlock.
> > > Then I touched
> > > > the screen and the deadlock is lifted and readings 
> started again.
> > > > 
> > > > As if the behavior was not weird enough, occassionally 
> after the 
> > > > buffer is disabled, the touchscreen readings are mangled.
> > > > 
> > > > Next step, figure out what is going wrong.
> > > >
> > > 
> > > It seems the drivers are being flooded with IRQENB_EOS interrupts 
> > > causing the lockup.
> > > 
> > > By adding the following to the tiadc_irq_h function the 
> lockup stops.
> > > 
> > > .
> > > .
> > >         if (status & IRQENB_EOS) {
> > >                 tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > >                 return IRQ_HANDLED;
> > >         }
> > > .
> > > .
> > > 
> > > Now the IRQENB_EOS is also handled in the touchscreen 
> driver so this 
> > > is may not be an appropriate fix but at least it fixes the lockup.
> > > 
> > > Try adding the snippet above to ti_am335x_adc.c and see 
> if it makes 
> > > your program stop locking up.
> > > 
> > > Then we need to find a solution that makes the maintainers happy.
> > > 
> > > 
> > 
> > I've applied this to the ti_am335x_adc.c driver in both the 
> 3.14.49-ti-r62 & 3.14.49-ti-r73 kernels from RCN and they 
> both suffered touch screen lockups over night.
> 
> This is disturbing. Do you have any idea how long it takes 
> before the lockup occurs?

I don't know how long the system runs before lockup. The -r73 kernel locked up
Sometime over the weekend, I had run it for an hour or two before I left Saturday.
The -r62 kernel again, ran for a couple of hours yesterday afternoon before I went home, it was locked up this morning.

> 
> Previously it was in a few seconds so there is obviously some 
> improvement.

I've seen uptimes of a few hours before depending on the config-delay setting, which I think that I have set to <0xB000>.

> 
> Is the mouse locked as well after the overnight test?

Yes the mouse is locked up for touches, but it does still move. The GUI loop for the program is still running. I've got some indicators on the screen that are still updating.

> 
> > 
> > Here is what I did:
> > static irqreturn_t tiadc_irq_h(int irq, void *private) {
> > 	struct iio_dev *indio_dev = private;
> > 	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> > 	unsigned int status, config;
> > 	status = tiadc_readl(adc_dev, REG_IRQSTATUS);
> > 
> > 	/*
> > 	 * ADC and touchscreen share the IRQ line.
> > 	 * FIFO0 interrupts are used by TSC. Handle FIFO1 IRQs here only
> > 	 */
> > 	if (status & IRQENB_FIFO1OVRRUN) {
> > 		/* FIFO Overrun. Clear flag. Disable/Enable ADC 
> to recover */
> > 		config = tiadc_readl(adc_dev, REG_CTRL);
> > 		config &= ~(CNTRLREG_TSCSSENB);
> > 		tiadc_writel(adc_dev, REG_CTRL, config);
> > 		tiadc_writel(adc_dev, REG_IRQSTATUS, IRQENB_FIFO1OVRRUN
> > 				| IRQENB_FIFO1UNDRFLW | 
> IRQENB_FIFO1THRES);
> > 		tiadc_writel(adc_dev, REG_CTRL, (config | 
> CNTRLREG_TSCSSENB));
> > 		return IRQ_HANDLED;
> > 	} else if (status & IRQENB_FIFO1THRES) {
> > 		/* Disable irq and wake worker thread */
> > 		tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_FIFO1THRES);
> > 		return IRQ_WAKE_THREAD;
> > 	}
> > 
> >     if (status & IRQENB_EOS) {
> >         tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> >         return IRQ_HANDLED;
> >     }
> > 
> >     return IRQ_NONE;
> > }
> > 
> > Regards,
> > Greg
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Tue, Aug 18, 2015 at 09:54:47AM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Tuesday, August 18, 2015 9:29 AM
> > To: Greg Wilson-Lindberg
> > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Tue, Aug 18, 2015 at 09:06:20AM -0700, Greg Wilson-Lindberg wrote:
> > >  
> > > 
> > > > On Fri, Aug 14, 2015 at 03:40:18PM -0500, Michael Welling wrote:
> > > > > On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg
> > > > Wilson-Lindberg wrote:
> > > > > > Thank you very much,
> > > > > > Regards, Greg
> > > > > >
> > > > > 
> > > > > To replicate the issue I did the following:
> > > > > 
> > > > > - Started a touchscreen enabled application ts_test
> > > > > 
> > > > > - In another terminal started a dump of 
> > /dev/iio:device0 hexdump 
> > > > > -C /dev/iio\:device0
> > > > > 
> > > > > - In yet another terminal enable the buffer cd 
> > > > > /sys/bus/iio/devices/iio\:device0 echo 1 > 
> > > > > scan_elements/in_voltage4_en echo 1 > buffer/enable
> > > > > 
> > > > > Once the buffer is enabled the hexdump window starts 
> > spewing out 
> > > > > readings as expected. The touchscreen is unresponsive 
> > as expected.
> > > > > 
> > > > > Then I started occassionally enabling and disabling the 
> > buffer and 
> > > > > noticed something very off. When enabling the buffer 
> > sometimes the 
> > > > > readings from the hexdump would start and abruptly stop. In
> > > > this state
> > > > > the entire system is nonresponsive. None of the terminals are 
> > > > > excepting input and the system is in complete deadlock.
> > > > Then I touched
> > > > > the screen and the deadlock is lifted and readings 
> > started again.
> > > > > 
> > > > > As if the behavior was not weird enough, occassionally 
> > after the 
> > > > > buffer is disabled, the touchscreen readings are mangled.
> > > > > 
> > > > > Next step, figure out what is going wrong.
> > > > >
> > > > 
> > > > It seems the drivers are being flooded with IRQENB_EOS interrupts 
> > > > causing the lockup.
> > > > 
> > > > By adding the following to the tiadc_irq_h function the 
> > lockup stops.
> > > > 
> > > > .
> > > > .
> > > >         if (status & IRQENB_EOS) {
> > > >                 tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > > >                 return IRQ_HANDLED;
> > > >         }
> > > > .
> > > > .
> > > > 
> > > > Now the IRQENB_EOS is also handled in the touchscreen 
> > driver so this 
> > > > is may not be an appropriate fix but at least it fixes the lockup.
> > > > 
> > > > Try adding the snippet above to ti_am335x_adc.c and see 
> > if it makes 
> > > > your program stop locking up.
> > > > 
> > > > Then we need to find a solution that makes the maintainers happy.
> > > > 
> > > > 
> > > 
> > > I've applied this to the ti_am335x_adc.c driver in both the 
> > 3.14.49-ti-r62 & 3.14.49-ti-r73 kernels from RCN and they 
> > both suffered touch screen lockups over night.
> > 
> > This is disturbing. Do you have any idea how long it takes 
> > before the lockup occurs?
> 
> I don't know how long the system runs before lockup. The -r73 kernel locked up
> Sometime over the weekend, I had run it for an hour or two before I left Saturday.
> The -r62 kernel again, ran for a couple of hours yesterday afternoon before I went home, it was locked up this morning.
> 
> > 
> > Previously it was in a few seconds so there is obviously some 
> > improvement.
> 
> I've seen uptimes of a few hours before depending on the config-delay setting, which I think that I have set to <0xB000>.
> 
> > 
> > Is the mouse locked as well after the overnight test?
> 
> Yes the mouse is locked up for touches, but it does still move. The GUI loop for the program is still running. I've got some indicators on the screen that are still updating.
>

Does the cursor jump to a specific place on the screen when you stop moving the mouse? 

> > 
> > > 
> > > Here is what I did:
> > > static irqreturn_t tiadc_irq_h(int irq, void *private) {
> > > 	struct iio_dev *indio_dev = private;
> > > 	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> > > 	unsigned int status, config;
> > > 	status = tiadc_readl(adc_dev, REG_IRQSTATUS);
> > > 
> > > 	/*
> > > 	 * ADC and touchscreen share the IRQ line.
> > > 	 * FIFO0 interrupts are used by TSC. Handle FIFO1 IRQs here only
> > > 	 */
> > > 	if (status & IRQENB_FIFO1OVRRUN) {
> > > 		/* FIFO Overrun. Clear flag. Disable/Enable ADC 
> > to recover */
> > > 		config = tiadc_readl(adc_dev, REG_CTRL);
> > > 		config &= ~(CNTRLREG_TSCSSENB);
> > > 		tiadc_writel(adc_dev, REG_CTRL, config);
> > > 		tiadc_writel(adc_dev, REG_IRQSTATUS, IRQENB_FIFO1OVRRUN
> > > 				| IRQENB_FIFO1UNDRFLW | 
> > IRQENB_FIFO1THRES);
> > > 		tiadc_writel(adc_dev, REG_CTRL, (config | 
> > CNTRLREG_TSCSSENB));
> > > 		return IRQ_HANDLED;
> > > 	} else if (status & IRQENB_FIFO1THRES) {
> > > 		/* Disable irq and wake worker thread */
> > > 		tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_FIFO1THRES);
> > > 		return IRQ_WAKE_THREAD;
> > > 	}
> > > 
> > >     if (status & IRQENB_EOS) {
> > >         tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > >         return IRQ_HANDLED;
> > >     }
> > > 
> > >     return IRQ_NONE;
> > > }
> > > 
> > > Regards,
> > > Greg
> > 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Tuesday, August 18, 2015 10:37 AM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Tue, Aug 18, 2015 at 09:54:47AM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Tuesday, August 18, 2015 9:29 AM
> > > To: Greg Wilson-Lindberg
> > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > On Tue, Aug 18, 2015 at 09:06:20AM -0700, Greg 
> Wilson-Lindberg wrote:
> > > >  
> > > > 
> > > > > On Fri, Aug 14, 2015 at 03:40:18PM -0500, Michael 
> Welling wrote:
> > > > > > On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg
> > > > > Wilson-Lindberg wrote:
> > > > > > > Thank you very much,
> > > > > > > Regards, Greg
> > > > > > >
> > > > > > 
> > > > > > To replicate the issue I did the following:
> > > > > > 
> > > > > > - Started a touchscreen enabled application ts_test
> > > > > > 
> > > > > > - In another terminal started a dump of
> > > /dev/iio:device0 hexdump
> > > > > > -C /dev/iio\:device0
> > > > > > 
> > > > > > - In yet another terminal enable the buffer cd 
> > > > > > /sys/bus/iio/devices/iio\:device0 echo 1 > 
> > > > > > scan_elements/in_voltage4_en echo 1 > buffer/enable
> > > > > > 
> > > > > > Once the buffer is enabled the hexdump window starts
> > > spewing out
> > > > > > readings as expected. The touchscreen is unresponsive
> > > as expected.
> > > > > > 
> > > > > > Then I started occassionally enabling and disabling the
> > > buffer and
> > > > > > noticed something very off. When enabling the buffer
> > > sometimes the
> > > > > > readings from the hexdump would start and abruptly stop. In
> > > > > this state
> > > > > > the entire system is nonresponsive. None of the 
> terminals are 
> > > > > > excepting input and the system is in complete deadlock.
> > > > > Then I touched
> > > > > > the screen and the deadlock is lifted and readings
> > > started again.
> > > > > > 
> > > > > > As if the behavior was not weird enough, occassionally
> > > after the
> > > > > > buffer is disabled, the touchscreen readings are mangled.
> > > > > > 
> > > > > > Next step, figure out what is going wrong.
> > > > > >
> > > > > 
> > > > > It seems the drivers are being flooded with IRQENB_EOS 
> > > > > interrupts causing the lockup.
> > > > > 
> > > > > By adding the following to the tiadc_irq_h function the
> > > lockup stops.
> > > > > 
> > > > > .
> > > > > .
> > > > >         if (status & IRQENB_EOS) {
> > > > >                 tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > > > >                 return IRQ_HANDLED;
> > > > >         }
> > > > > .
> > > > > .
> > > > > 
> > > > > Now the IRQENB_EOS is also handled in the touchscreen
> > > driver so this
> > > > > is may not be an appropriate fix but at least it 
> fixes the lockup.
> > > > > 
> > > > > Try adding the snippet above to ti_am335x_adc.c and see
> > > if it makes
> > > > > your program stop locking up.
> > > > > 
> > > > > Then we need to find a solution that makes the 
> maintainers happy.
> > > > > 
> > > > > 
> > > > 
> > > > I've applied this to the ti_am335x_adc.c driver in both the
> > > 3.14.49-ti-r62 & 3.14.49-ti-r73 kernels from RCN and they both 
> > > suffered touch screen lockups over night.
> > > 
> > > This is disturbing. Do you have any idea how long it takes before 
> > > the lockup occurs?
> > 
> > I don't know how long the system runs before lockup. The 
> -r73 kernel 
> > locked up Sometime over the weekend, I had run it for an 
> hour or two before I left Saturday.
> > The -r62 kernel again, ran for a couple of hours yesterday 
> afternoon before I went home, it was locked up this morning.
> > 
> > > 
> > > Previously it was in a few seconds so there is obviously some 
> > > improvement.
> > 
> > I've seen uptimes of a few hours before depending on the 
> config-delay setting, which I think that I have set to <0xB000>.
> > 
> > > 
> > > Is the mouse locked as well after the overnight test?
> > 
> > Yes the mouse is locked up for touches, but it does still 
> move. The GUI loop for the program is still running. I've got 
> some indicators on the screen that are still updating.
> >
> 
> Does the cursor jump to a specific place on the screen when 
> you stop moving the mouse? 

No, it follows movement and stays at the last location it was moved to.

> 
> > > 
> > > > 
> > > > Here is what I did:
> > > > static irqreturn_t tiadc_irq_h(int irq, void *private) {
> > > > 	struct iio_dev *indio_dev = private;
> > > > 	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> > > > 	unsigned int status, config;
> > > > 	status = tiadc_readl(adc_dev, REG_IRQSTATUS);
> > > > 
> > > > 	/*
> > > > 	 * ADC and touchscreen share the IRQ line.
> > > > 	 * FIFO0 interrupts are used by TSC. Handle 
> FIFO1 IRQs here only
> > > > 	 */
> > > > 	if (status & IRQENB_FIFO1OVRRUN) {
> > > > 		/* FIFO Overrun. Clear flag. Disable/Enable ADC
> > > to recover */
> > > > 		config = tiadc_readl(adc_dev, REG_CTRL);
> > > > 		config &= ~(CNTRLREG_TSCSSENB);
> > > > 		tiadc_writel(adc_dev, REG_CTRL, config);
> > > > 		tiadc_writel(adc_dev, REG_IRQSTATUS, 
> IRQENB_FIFO1OVRRUN
> > > > 				| IRQENB_FIFO1UNDRFLW |
> > > IRQENB_FIFO1THRES);
> > > > 		tiadc_writel(adc_dev, REG_CTRL, (config |
> > > CNTRLREG_TSCSSENB));
> > > > 		return IRQ_HANDLED;
> > > > 	} else if (status & IRQENB_FIFO1THRES) {
> > > > 		/* Disable irq and wake worker thread */
> > > > 		tiadc_writel(adc_dev, REG_IRQCLR, 
> IRQENB_FIFO1THRES);
> > > > 		return IRQ_WAKE_THREAD;
> > > > 	}
> > > > 
> > > >     if (status & IRQENB_EOS) {
> > > >         tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > > >         return IRQ_HANDLED;
> > > >     }
> > > > 
> > > >     return IRQ_NONE;
> > > > }
> > > > 
> > > > Regards,
> > > > Greg
> > > 
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Tue, Aug 18, 2015 at 10:40:44AM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Tuesday, August 18, 2015 10:37 AM
> > To: Greg Wilson-Lindberg
> > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Tue, Aug 18, 2015 at 09:54:47AM -0700, Greg Wilson-Lindberg wrote:
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > > Michael Welling
> > > > Sent: Tuesday, August 18, 2015 9:29 AM
> > > > To: Greg Wilson-Lindberg
> > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > Subject: Re: BBB IIO ADC access not working
> > > > 
> > > > On Tue, Aug 18, 2015 at 09:06:20AM -0700, Greg 
> > Wilson-Lindberg wrote:
> > > > >  
> > > > > 
> > > > > > On Fri, Aug 14, 2015 at 03:40:18PM -0500, Michael 
> > Welling wrote:
> > > > > > > On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg
> > > > > > Wilson-Lindberg wrote:
> > > > > > > > Thank you very much,
> > > > > > > > Regards, Greg
> > > > > > > >
> > > > > > > 
> > > > > > > To replicate the issue I did the following:
> > > > > > > 
> > > > > > > - Started a touchscreen enabled application ts_test
> > > > > > > 
> > > > > > > - In another terminal started a dump of
> > > > /dev/iio:device0 hexdump
> > > > > > > -C /dev/iio\:device0
> > > > > > > 
> > > > > > > - In yet another terminal enable the buffer cd 
> > > > > > > /sys/bus/iio/devices/iio\:device0 echo 1 > 
> > > > > > > scan_elements/in_voltage4_en echo 1 > buffer/enable
> > > > > > > 
> > > > > > > Once the buffer is enabled the hexdump window starts
> > > > spewing out
> > > > > > > readings as expected. The touchscreen is unresponsive
> > > > as expected.
> > > > > > > 
> > > > > > > Then I started occassionally enabling and disabling the
> > > > buffer and
> > > > > > > noticed something very off. When enabling the buffer
> > > > sometimes the
> > > > > > > readings from the hexdump would start and abruptly stop. In
> > > > > > this state
> > > > > > > the entire system is nonresponsive. None of the 
> > terminals are 
> > > > > > > excepting input and the system is in complete deadlock.
> > > > > > Then I touched
> > > > > > > the screen and the deadlock is lifted and readings
> > > > started again.
> > > > > > > 
> > > > > > > As if the behavior was not weird enough, occassionally
> > > > after the
> > > > > > > buffer is disabled, the touchscreen readings are mangled.
> > > > > > > 
> > > > > > > Next step, figure out what is going wrong.
> > > > > > >
> > > > > > 
> > > > > > It seems the drivers are being flooded with IRQENB_EOS 
> > > > > > interrupts causing the lockup.
> > > > > > 
> > > > > > By adding the following to the tiadc_irq_h function the
> > > > lockup stops.
> > > > > > 
> > > > > > .
> > > > > > .
> > > > > >         if (status & IRQENB_EOS) {
> > > > > >                 tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > > > > >                 return IRQ_HANDLED;
> > > > > >         }
> > > > > > .
> > > > > > .
> > > > > > 
> > > > > > Now the IRQENB_EOS is also handled in the touchscreen
> > > > driver so this
> > > > > > is may not be an appropriate fix but at least it 
> > fixes the lockup.
> > > > > > 
> > > > > > Try adding the snippet above to ti_am335x_adc.c and see
> > > > if it makes
> > > > > > your program stop locking up.
> > > > > > 
> > > > > > Then we need to find a solution that makes the 
> > maintainers happy.
> > > > > > 
> > > > > > 
> > > > > 
> > > > > I've applied this to the ti_am335x_adc.c driver in both the
> > > > 3.14.49-ti-r62 & 3.14.49-ti-r73 kernels from RCN and they both 
> > > > suffered touch screen lockups over night.
> > > > 
> > > > This is disturbing. Do you have any idea how long it takes before 
> > > > the lockup occurs?
> > > 
> > > I don't know how long the system runs before lockup. The 
> > -r73 kernel 
> > > locked up Sometime over the weekend, I had run it for an 
> > hour or two before I left Saturday.
> > > The -r62 kernel again, ran for a couple of hours yesterday 
> > afternoon before I went home, it was locked up this morning.
> > > 
> > > > 
> > > > Previously it was in a few seconds so there is obviously some 
> > > > improvement.
> > > 
> > > I've seen uptimes of a few hours before depending on the 
> > config-delay setting, which I think that I have set to <0xB000>.
> > > 
> > > > 
> > > > Is the mouse locked as well after the overnight test?
> > > 
> > > Yes the mouse is locked up for touches, but it does still 
> > move. The GUI loop for the program is still running. I've got 
> > some indicators on the screen that are still updating.
> > >
> > 
> > Does the cursor jump to a specific place on the screen when 
> > you stop moving the mouse? 
> 
> No, it follows movement and stays at the last location it was moved to.
>

I found that handling the IRQENB_EOS interrupt in the ADC is causing an
undesired effect. After enabling the ADC buffer mode and disabling it the
coordinate readings work but the touch release is no longer detected.
 
> > 
> > > > 
> > > > > 
> > > > > Here is what I did:
> > > > > static irqreturn_t tiadc_irq_h(int irq, void *private) {
> > > > > 	struct iio_dev *indio_dev = private;
> > > > > 	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> > > > > 	unsigned int status, config;
> > > > > 	status = tiadc_readl(adc_dev, REG_IRQSTATUS);
> > > > > 
> > > > > 	/*
> > > > > 	 * ADC and touchscreen share the IRQ line.
> > > > > 	 * FIFO0 interrupts are used by TSC. Handle 
> > FIFO1 IRQs here only
> > > > > 	 */
> > > > > 	if (status & IRQENB_FIFO1OVRRUN) {
> > > > > 		/* FIFO Overrun. Clear flag. Disable/Enable ADC
> > > > to recover */
> > > > > 		config = tiadc_readl(adc_dev, REG_CTRL);
> > > > > 		config &= ~(CNTRLREG_TSCSSENB);
> > > > > 		tiadc_writel(adc_dev, REG_CTRL, config);
> > > > > 		tiadc_writel(adc_dev, REG_IRQSTATUS, 
> > IRQENB_FIFO1OVRRUN
> > > > > 				| IRQENB_FIFO1UNDRFLW |
> > > > IRQENB_FIFO1THRES);
> > > > > 		tiadc_writel(adc_dev, REG_CTRL, (config |
> > > > CNTRLREG_TSCSSENB));
> > > > > 		return IRQ_HANDLED;
> > > > > 	} else if (status & IRQENB_FIFO1THRES) {
> > > > > 		/* Disable irq and wake worker thread */
> > > > > 		tiadc_writel(adc_dev, REG_IRQCLR, 
> > IRQENB_FIFO1THRES);
> > > > > 		return IRQ_WAKE_THREAD;
> > > > > 	}
> > > > > 
> > > > >     if (status & IRQENB_EOS) {
> > > > >         tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > > > >         return IRQ_HANDLED;
> > > > >     }
> > > > > 
> > > > >     return IRQ_NONE;
> > > > > }
> > > > > 
> > > > > Regards,
> > > > > Greg
> > > > 
> > 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Tuesday, August 18, 2015 11:13 AM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Tue, Aug 18, 2015 at 10:40:44AM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Tuesday, August 18, 2015 10:37 AM
> > > To: Greg Wilson-Lindberg
> > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > On Tue, Aug 18, 2015 at 09:54:47AM -0700, Greg 
> Wilson-Lindberg wrote:
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Michael Welling [mailto:mwelling79@gmail.com] 
> On Behalf Of 
> > > > > Michael Welling
> > > > > Sent: Tuesday, August 18, 2015 9:29 AM
> > > > > To: Greg Wilson-Lindberg
> > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > Subject: Re: BBB IIO ADC access not working
> > > > > 
> > > > > On Tue, Aug 18, 2015 at 09:06:20AM -0700, Greg
> > > Wilson-Lindberg wrote:
> > > > > >  
> > > > > > 
> > > > > > > On Fri, Aug 14, 2015 at 03:40:18PM -0500, Michael
> > > Welling wrote:
> > > > > > > > On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg
> > > > > > > Wilson-Lindberg wrote:
> > > > > > > > > Thank you very much,
> > > > > > > > > Regards, Greg
> > > > > > > > >
> > > > > > > > 
> > > > > > > > To replicate the issue I did the following:
> > > > > > > > 
> > > > > > > > - Started a touchscreen enabled application ts_test
> > > > > > > > 
> > > > > > > > - In another terminal started a dump of
> > > > > /dev/iio:device0 hexdump
> > > > > > > > -C /dev/iio\:device0
> > > > > > > > 
> > > > > > > > - In yet another terminal enable the buffer cd 
> > > > > > > > /sys/bus/iio/devices/iio\:device0 echo 1 > 
> > > > > > > > scan_elements/in_voltage4_en echo 1 > buffer/enable
> > > > > > > > 
> > > > > > > > Once the buffer is enabled the hexdump window starts
> > > > > spewing out
> > > > > > > > readings as expected. The touchscreen is unresponsive
> > > > > as expected.
> > > > > > > > 
> > > > > > > > Then I started occassionally enabling and disabling the
> > > > > buffer and
> > > > > > > > noticed something very off. When enabling the buffer
> > > > > sometimes the
> > > > > > > > readings from the hexdump would start and 
> abruptly stop. 
> > > > > > > > In
> > > > > > > this state
> > > > > > > > the entire system is nonresponsive. None of the
> > > terminals are
> > > > > > > > excepting input and the system is in complete deadlock.
> > > > > > > Then I touched
> > > > > > > > the screen and the deadlock is lifted and readings
> > > > > started again.
> > > > > > > > 
> > > > > > > > As if the behavior was not weird enough, occassionally
> > > > > after the
> > > > > > > > buffer is disabled, the touchscreen readings 
> are mangled.
> > > > > > > > 
> > > > > > > > Next step, figure out what is going wrong.
> > > > > > > >
> > > > > > > 
> > > > > > > It seems the drivers are being flooded with IRQENB_EOS 
> > > > > > > interrupts causing the lockup.
> > > > > > > 
> > > > > > > By adding the following to the tiadc_irq_h function the
> > > > > lockup stops.
> > > > > > > 
> > > > > > > .
> > > > > > > .
> > > > > > >         if (status & IRQENB_EOS) {
> > > > > > >                 tiadc_writel(adc_dev, REG_IRQCLR, 
> IRQENB_EOS);
> > > > > > >                 return IRQ_HANDLED;
> > > > > > >         }
> > > > > > > .
> > > > > > > .
> > > > > > > 
> > > > > > > Now the IRQENB_EOS is also handled in the touchscreen
> > > > > driver so this
> > > > > > > is may not be an appropriate fix but at least it
> > > fixes the lockup.
> > > > > > > 
> > > > > > > Try adding the snippet above to ti_am335x_adc.c and see
> > > > > if it makes
> > > > > > > your program stop locking up.
> > > > > > > 
> > > > > > > Then we need to find a solution that makes the
> > > maintainers happy.
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > I've applied this to the ti_am335x_adc.c driver in both the
> > > > > 3.14.49-ti-r62 & 3.14.49-ti-r73 kernels from RCN and 
> they both 
> > > > > suffered touch screen lockups over night.
> > > > > 
> > > > > This is disturbing. Do you have any idea how long it takes 
> > > > > before the lockup occurs?
> > > > 
> > > > I don't know how long the system runs before lockup. The
> > > -r73 kernel
> > > > locked up Sometime over the weekend, I had run it for an
> > > hour or two before I left Saturday.
> > > > The -r62 kernel again, ran for a couple of hours yesterday
> > > afternoon before I went home, it was locked up this morning.
> > > > 
> > > > > 
> > > > > Previously it was in a few seconds so there is obviously some 
> > > > > improvement.
> > > > 
> > > > I've seen uptimes of a few hours before depending on the
> > > config-delay setting, which I think that I have set to <0xB000>.
> > > > 
> > > > > 
> > > > > Is the mouse locked as well after the overnight test?
> > > > 
> > > > Yes the mouse is locked up for touches, but it does still
> > > move. The GUI loop for the program is still running. I've 
> got some 
> > > indicators on the screen that are still updating.
> > > >
> > > 
> > > Does the cursor jump to a specific place on the screen 
> when you stop 
> > > moving the mouse?
> > 
> > No, it follows movement and stays at the last location it 
> was moved to.
> >
> 
> I found that handling the IRQENB_EOS interrupt in the ADC is 
> causing an undesired effect. After enabling the ADC buffer 
> mode and disabling it the coordinate readings work but the 
> touch release is no longer detected.

Can we put your code in the touch screen handler? The tsc code is writing to the IRQSTATUS register, not the IRQCLR register.

>  
> > > 
> > > > > 
> > > > > > 
> > > > > > Here is what I did:
> > > > > > static irqreturn_t tiadc_irq_h(int irq, void *private) {
> > > > > > 	struct iio_dev *indio_dev = private;
> > > > > > 	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> > > > > > 	unsigned int status, config;
> > > > > > 	status = tiadc_readl(adc_dev, REG_IRQSTATUS);
> > > > > > 
> > > > > > 	/*
> > > > > > 	 * ADC and touchscreen share the IRQ line.
> > > > > > 	 * FIFO0 interrupts are used by TSC. Handle
> > > FIFO1 IRQs here only
> > > > > > 	 */
> > > > > > 	if (status & IRQENB_FIFO1OVRRUN) {
> > > > > > 		/* FIFO Overrun. Clear flag. Disable/Enable ADC
> > > > > to recover */
> > > > > > 		config = tiadc_readl(adc_dev, REG_CTRL);
> > > > > > 		config &= ~(CNTRLREG_TSCSSENB);
> > > > > > 		tiadc_writel(adc_dev, REG_CTRL, config);
> > > > > > 		tiadc_writel(adc_dev, REG_IRQSTATUS,
> > > IRQENB_FIFO1OVRRUN
> > > > > > 				| IRQENB_FIFO1UNDRFLW |
> > > > > IRQENB_FIFO1THRES);
> > > > > > 		tiadc_writel(adc_dev, REG_CTRL, (config |
> > > > > CNTRLREG_TSCSSENB));
> > > > > > 		return IRQ_HANDLED;
> > > > > > 	} else if (status & IRQENB_FIFO1THRES) {
> > > > > > 		/* Disable irq and wake worker thread */
> > > > > > 		tiadc_writel(adc_dev, REG_IRQCLR,
> > > IRQENB_FIFO1THRES);
> > > > > > 		return IRQ_WAKE_THREAD;
> > > > > > 	}
> > > > > > 
> > > > > >     if (status & IRQENB_EOS) {
> > > > > >         tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > > > > >         return IRQ_HANDLED;
> > > > > >     }
> > > > > > 
> > > > > >     return IRQ_NONE;
> > > > > > }
> > > > > > 
> > > > > > Regards,
> > > > > > Greg
> > > > > 
> > > 
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Tue, Aug 18, 2015 at 03:11:13PM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > I found that handling the IRQENB_EOS interrupt in the ADC is 
> > causing an undesired effect. After enabling the ADC buffer 
> > mode and disabling it the coordinate readings work but the 
> > touch release is no longer detected.
> 
> Can we put your code in the touch screen handler? The tsc code is writing to the IRQSTATUS register, not the IRQCLR register.
> 

Actually using the IRQCLR disables the IRQ instead of clearing it and that
was not my intent. This is why the pen releases where not working, the tsc
driver relies on the EOS interrupt to write the step register because it is
using a one shot hardware mode.

Since the IRQENB_EOS is not used by the ADC driver it can be disabled when
in buffered mode which is triggering faster than the isr can handle it.

See patch below.

Though it allows for the repeated enabling and disabling of the buffer the touchscreen
gets a bunch of unexpected releases and the readings are very jittery.

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index a0e7161..9945e4a 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -177,6 +177,7 @@ static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
 				IRQENB_FIFO1OVRRUN |
 				IRQENB_FIFO1UNDRFLW));
 
+	tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
 	/* Flush FIFO. Needed in corner cases in simultaneous tsc/adc use */
 	fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
 	for (i = 0; i < fifo1count; i++)
@@ -213,6 +214,7 @@ static int tiadc_buffer_predisable(struct iio_dev *indio_dev)
 
 	tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
 				IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW));
+	tiadc_writel(adc_dev, REG_IRQENABLE, IRQENB_EOS);
 	am335x_tsc_se_clr(adc_dev->mfd_tscadc, adc_dev->buffer_en_ch_steps);
 	adc_dev->buffer_en_ch_steps = 0;
 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Tuesday, August 18, 2015 3:31 PM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Tue, Aug 18, 2015 at 03:11:13PM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > I found that handling the IRQENB_EOS interrupt in the ADC 
> is causing 
> > > an undesired effect. After enabling the ADC buffer mode and 
> > > disabling it the coordinate readings work but the touch 
> release is 
> > > no longer detected.
> > 
> > Can we put your code in the touch screen handler? The tsc 
> code is writing to the IRQSTATUS register, not the IRQCLR register.
> > 
> 
> Actually using the IRQCLR disables the IRQ instead of 
> clearing it and that was not my intent. This is why the pen 
> releases where not working, the tsc driver relies on the EOS 
> interrupt to write the step register because it is using a 
> one shot hardware mode.
> 
> Since the IRQENB_EOS is not used by the ADC driver it can be 
> disabled when in buffered mode which is triggering faster 
> than the isr can handle it.
> 
> See patch below.
> 
> Though it allows for the repeated enabling and disabling of 
> the buffer the touchscreen gets a bunch of unexpected 
> releases and the readings are very jittery.
> 
> diff --git a/drivers/iio/adc/ti_am335x_adc.c 
> b/drivers/iio/adc/ti_am335x_adc.c index a0e7161..9945e4a 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -177,6 +177,7 @@ static int tiadc_buffer_preenable(struct 
> iio_dev *indio_dev)
>  				IRQENB_FIFO1OVRRUN |
>  				IRQENB_FIFO1UNDRFLW));
>  
> +	tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
>  	/* Flush FIFO. Needed in corner cases in simultaneous 
> tsc/adc use */
>  	fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
>  	for (i = 0; i < fifo1count; i++)
> @@ -213,6 +214,7 @@ static int tiadc_buffer_predisable(struct 
> iio_dev *indio_dev)
>  
>  	tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
>  				IRQENB_FIFO1OVRRUN | 
> IRQENB_FIFO1UNDRFLW));
> +	tiadc_writel(adc_dev, REG_IRQENABLE, IRQENB_EOS);
>  	am335x_tsc_se_clr(adc_dev->mfd_tscadc, 
> adc_dev->buffer_en_ch_steps);
>  	adc_dev->buffer_en_ch_steps = 0;
>  
> 

I'm not sure that it's better, but it is different.  The touch screen still locks up, but mouse clicks work.

> 
> 
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Wed, Aug 19, 2015 at 09:27:02AM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Tuesday, August 18, 2015 3:31 PM
> > To: Greg Wilson-Lindberg
> > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Tue, Aug 18, 2015 at 03:11:13PM -0700, Greg Wilson-Lindberg wrote:
> > >  
> > > 
> > > > I found that handling the IRQENB_EOS interrupt in the ADC 
> > is causing 
> > > > an undesired effect. After enabling the ADC buffer mode and 
> > > > disabling it the coordinate readings work but the touch 
> > release is 
> > > > no longer detected.
> > > 
> > > Can we put your code in the touch screen handler? The tsc 
> > code is writing to the IRQSTATUS register, not the IRQCLR register.
> > > 
> > 
> > Actually using the IRQCLR disables the IRQ instead of 
> > clearing it and that was not my intent. This is why the pen 
> > releases where not working, the tsc driver relies on the EOS 
> > interrupt to write the step register because it is using a 
> > one shot hardware mode.
> > 
> > Since the IRQENB_EOS is not used by the ADC driver it can be 
> > disabled when in buffered mode which is triggering faster 
> > than the isr can handle it.
> > 
> > See patch below.
> > 
> > Though it allows for the repeated enabling and disabling of 
> > the buffer the touchscreen gets a bunch of unexpected 
> > releases and the readings are very jittery.
> > 
> > diff --git a/drivers/iio/adc/ti_am335x_adc.c 
> > b/drivers/iio/adc/ti_am335x_adc.c index a0e7161..9945e4a 100644
> > --- a/drivers/iio/adc/ti_am335x_adc.c
> > +++ b/drivers/iio/adc/ti_am335x_adc.c
> > @@ -177,6 +177,7 @@ static int tiadc_buffer_preenable(struct 
> > iio_dev *indio_dev)
> >  				IRQENB_FIFO1OVRRUN |
> >  				IRQENB_FIFO1UNDRFLW));
> >  
> > +	tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> >  	/* Flush FIFO. Needed in corner cases in simultaneous 
> > tsc/adc use */
> >  	fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
> >  	for (i = 0; i < fifo1count; i++)
> > @@ -213,6 +214,7 @@ static int tiadc_buffer_predisable(struct 
> > iio_dev *indio_dev)
> >  
> >  	tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
> >  				IRQENB_FIFO1OVRRUN | 
> > IRQENB_FIFO1UNDRFLW));
> > +	tiadc_writel(adc_dev, REG_IRQENABLE, IRQENB_EOS);
> >  	am335x_tsc_se_clr(adc_dev->mfd_tscadc, 
> > adc_dev->buffer_en_ch_steps);
> >  	adc_dev->buffer_en_ch_steps = 0;
> >  
> > 
> 
> I'm not sure that it's better, but it is different.  The touch screen still locks up, but mouse clicks work.

This is very disappointing.

Have you tried reading the ADCs using one shot mode recently?

IE cat /sys/bus/iio/devices/iio:device0/in_voltageX_raw

> 
> > 
> > 
> > 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Wednesday, August 19, 2015 10:53 AM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Wed, Aug 19, 2015 at 09:27:02AM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Tuesday, August 18, 2015 3:31 PM
> > > To: Greg Wilson-Lindberg
> > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > On Tue, Aug 18, 2015 at 03:11:13PM -0700, Greg 
> Wilson-Lindberg wrote:
> > > >  
> > > > 
> > > > > I found that handling the IRQENB_EOS interrupt in the ADC
> > > is causing
> > > > > an undesired effect. After enabling the ADC buffer mode and 
> > > > > disabling it the coordinate readings work but the touch
> > > release is
> > > > > no longer detected.
> > > > 
> > > > Can we put your code in the touch screen handler? The tsc
> > > code is writing to the IRQSTATUS register, not the IRQCLR 
> register.
> > > > 
> > > 
> > > Actually using the IRQCLR disables the IRQ instead of clearing it 
> > > and that was not my intent. This is why the pen releases 
> where not 
> > > working, the tsc driver relies on the EOS interrupt to write the 
> > > step register because it is using a one shot hardware mode.
> > > 
> > > Since the IRQENB_EOS is not used by the ADC driver it can be 
> > > disabled when in buffered mode which is triggering faster 
> than the 
> > > isr can handle it.
> > > 
> > > See patch below.
> > > 
> > > Though it allows for the repeated enabling and disabling of the 
> > > buffer the touchscreen gets a bunch of unexpected 
> releases and the 
> > > readings are very jittery.
> > > 
> > > diff --git a/drivers/iio/adc/ti_am335x_adc.c 
> > > b/drivers/iio/adc/ti_am335x_adc.c index a0e7161..9945e4a 100644
> > > --- a/drivers/iio/adc/ti_am335x_adc.c
> > > +++ b/drivers/iio/adc/ti_am335x_adc.c
> > > @@ -177,6 +177,7 @@ static int 
> tiadc_buffer_preenable(struct iio_dev 
> > > *indio_dev)
> > >  				IRQENB_FIFO1OVRRUN |
> > >  				IRQENB_FIFO1UNDRFLW));
> > >  
> > > +	tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > >  	/* Flush FIFO. Needed in corner cases in simultaneous 
> tsc/adc use 
> > > */
> > >  	fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
> > >  	for (i = 0; i < fifo1count; i++)
> > > @@ -213,6 +214,7 @@ static int tiadc_buffer_predisable(struct 
> > > iio_dev *indio_dev)
> > >  
> > >  	tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
> > >  				IRQENB_FIFO1OVRRUN |
> > > IRQENB_FIFO1UNDRFLW));
> > > +	tiadc_writel(adc_dev, REG_IRQENABLE, IRQENB_EOS);
> > >  	am335x_tsc_se_clr(adc_dev->mfd_tscadc,
> > > adc_dev->buffer_en_ch_steps);
> > >  	adc_dev->buffer_en_ch_steps = 0;
> > >  
> > > 
> > 
> > I'm not sure that it's better, but it is different.  The 
> touch screen still locks up, but mouse clicks work.
> 
> This is very disappointing.
> 
> Have you tried reading the ADCs using one shot mode recently?
> 
> IE cat /sys/bus/iio/devices/iio:device0/in_voltageX_raw

I tried that after the system had locked up and what I get back is the Device
or resource is busy.  I restarted the BBB and tried before starting my application
and it worked just fine. I started up the app and the touch screen was 
locked up immediately, mouse clicks delayed about 1/2 second. And I get Device or resource busy from the cat.

> 
> > 
> > > 
> > > 
> > > 
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Wed, Aug 19, 2015 at 01:35:10PM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Wednesday, August 19, 2015 10:53 AM
> > To: Greg Wilson-Lindberg
> > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Wed, Aug 19, 2015 at 09:27:02AM -0700, Greg Wilson-Lindberg wrote:
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > > Michael Welling
> > > > Sent: Tuesday, August 18, 2015 3:31 PM
> > > > To: Greg Wilson-Lindberg
> > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > Subject: Re: BBB IIO ADC access not working
> > > > 
> > > > On Tue, Aug 18, 2015 at 03:11:13PM -0700, Greg 
> > Wilson-Lindberg wrote:
> > > > >  
> > > > > 
> > > > > > I found that handling the IRQENB_EOS interrupt in the ADC
> > > > is causing
> > > > > > an undesired effect. After enabling the ADC buffer mode and 
> > > > > > disabling it the coordinate readings work but the touch
> > > > release is
> > > > > > no longer detected.
> > > > > 
> > > > > Can we put your code in the touch screen handler? The tsc
> > > > code is writing to the IRQSTATUS register, not the IRQCLR 
> > register.
> > > > > 
> > > > 
> > > > Actually using the IRQCLR disables the IRQ instead of clearing it 
> > > > and that was not my intent. This is why the pen releases 
> > where not 
> > > > working, the tsc driver relies on the EOS interrupt to write the 
> > > > step register because it is using a one shot hardware mode.
> > > > 
> > > > Since the IRQENB_EOS is not used by the ADC driver it can be 
> > > > disabled when in buffered mode which is triggering faster 
> > than the 
> > > > isr can handle it.
> > > > 
> > > > See patch below.
> > > > 
> > > > Though it allows for the repeated enabling and disabling of the 
> > > > buffer the touchscreen gets a bunch of unexpected 
> > releases and the 
> > > > readings are very jittery.
> > > > 
> > > > diff --git a/drivers/iio/adc/ti_am335x_adc.c 
> > > > b/drivers/iio/adc/ti_am335x_adc.c index a0e7161..9945e4a 100644
> > > > --- a/drivers/iio/adc/ti_am335x_adc.c
> > > > +++ b/drivers/iio/adc/ti_am335x_adc.c
> > > > @@ -177,6 +177,7 @@ static int 
> > tiadc_buffer_preenable(struct iio_dev 
> > > > *indio_dev)
> > > >  				IRQENB_FIFO1OVRRUN |
> > > >  				IRQENB_FIFO1UNDRFLW));
> > > >  
> > > > +	tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > > >  	/* Flush FIFO. Needed in corner cases in simultaneous 
> > tsc/adc use 
> > > > */
> > > >  	fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
> > > >  	for (i = 0; i < fifo1count; i++)
> > > > @@ -213,6 +214,7 @@ static int tiadc_buffer_predisable(struct 
> > > > iio_dev *indio_dev)
> > > >  
> > > >  	tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
> > > >  				IRQENB_FIFO1OVRRUN |
> > > > IRQENB_FIFO1UNDRFLW));
> > > > +	tiadc_writel(adc_dev, REG_IRQENABLE, IRQENB_EOS);
> > > >  	am335x_tsc_se_clr(adc_dev->mfd_tscadc,
> > > > adc_dev->buffer_en_ch_steps);
> > > >  	adc_dev->buffer_en_ch_steps = 0;
> > > >  
> > > > 
> > > 
> > > I'm not sure that it's better, but it is different.  The 
> > touch screen still locks up, but mouse clicks work.
> > 
> > This is very disappointing.
> > 
> > Have you tried reading the ADCs using one shot mode recently?
> > 
> > IE cat /sys/bus/iio/devices/iio:device0/in_voltageX_raw
> 
> I tried that after the system had locked up and what I get back is the Device
> or resource is busy.  I restarted the BBB and tried before starting my application
> and it worked just fine. I started up the app and the touch screen was 
> locked up immediately, mouse clicks delayed about 1/2 second. And I get Device or resource busy from the cat.
>

Is the using while using /sys/bus/iio/devices/iio:device0/in_voltageX_raw in your program?
 
> > 
> > > 
> > > > 
> > > > 
> > > > 
> > 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Wednesday, August 19, 2015 1:49 PM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Wed, Aug 19, 2015 at 01:35:10PM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Wednesday, August 19, 2015 10:53 AM
> > > To: Greg Wilson-Lindberg
> > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > On Wed, Aug 19, 2015 at 09:27:02AM -0700, Greg 
> Wilson-Lindberg wrote:
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Michael Welling [mailto:mwelling79@gmail.com] 
> On Behalf Of 
> > > > > Michael Welling
> > > > > Sent: Tuesday, August 18, 2015 3:31 PM
> > > > > To: Greg Wilson-Lindberg
> > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > Subject: Re: BBB IIO ADC access not working
> > > > > 
> > > > > On Tue, Aug 18, 2015 at 03:11:13PM -0700, Greg
> > > Wilson-Lindberg wrote:
> > > > > >  
> > > > > > 
> > > > > > > I found that handling the IRQENB_EOS interrupt in the ADC
> > > > > is causing
> > > > > > > an undesired effect. After enabling the ADC 
> buffer mode and 
> > > > > > > disabling it the coordinate readings work but the touch
> > > > > release is
> > > > > > > no longer detected.
> > > > > > 
> > > > > > Can we put your code in the touch screen handler? The tsc
> > > > > code is writing to the IRQSTATUS register, not the IRQCLR
> > > register.
> > > > > > 
> > > > > 
> > > > > Actually using the IRQCLR disables the IRQ instead of 
> clearing 
> > > > > it and that was not my intent. This is why the pen releases
> > > where not
> > > > > working, the tsc driver relies on the EOS interrupt 
> to write the 
> > > > > step register because it is using a one shot hardware mode.
> > > > > 
> > > > > Since the IRQENB_EOS is not used by the ADC driver it can be 
> > > > > disabled when in buffered mode which is triggering faster
> > > than the
> > > > > isr can handle it.
> > > > > 
> > > > > See patch below.
> > > > > 
> > > > > Though it allows for the repeated enabling and 
> disabling of the 
> > > > > buffer the touchscreen gets a bunch of unexpected
> > > releases and the
> > > > > readings are very jittery.
> > > > > 
> > > > > diff --git a/drivers/iio/adc/ti_am335x_adc.c 
> > > > > b/drivers/iio/adc/ti_am335x_adc.c index 
> a0e7161..9945e4a 100644
> > > > > --- a/drivers/iio/adc/ti_am335x_adc.c
> > > > > +++ b/drivers/iio/adc/ti_am335x_adc.c
> > > > > @@ -177,6 +177,7 @@ static int
> > > tiadc_buffer_preenable(struct iio_dev
> > > > > *indio_dev)
> > > > >  				IRQENB_FIFO1OVRRUN |
> > > > >  				IRQENB_FIFO1UNDRFLW));
> > > > >  
> > > > > +	tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> > > > >  	/* Flush FIFO. Needed in corner cases in simultaneous
> > > tsc/adc use
> > > > > */
> > > > >  	fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
> > > > >  	for (i = 0; i < fifo1count; i++) @@ -213,6 
> +214,7 @@ static 
> > > > > int tiadc_buffer_predisable(struct iio_dev *indio_dev)
> > > > >  
> > > > >  	tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
> > > > >  				IRQENB_FIFO1OVRRUN |
> > > > > IRQENB_FIFO1UNDRFLW));
> > > > > +	tiadc_writel(adc_dev, REG_IRQENABLE, IRQENB_EOS);
> > > > >  	am335x_tsc_se_clr(adc_dev->mfd_tscadc,
> > > > > adc_dev->buffer_en_ch_steps);
> > > > >  	adc_dev->buffer_en_ch_steps = 0;
> > > > >  
> > > > > 
> > > > 
> > > > I'm not sure that it's better, but it is different.  The
> > > touch screen still locks up, but mouse clicks work.
> > > 
> > > This is very disappointing.
> > > 
> > > Have you tried reading the ADCs using one shot mode recently?
> > > 
> > > IE cat /sys/bus/iio/devices/iio:device0/in_voltageX_raw
> > 
> > I tried that after the system had locked up and what I get 
> back is the 
> > Device or resource is busy.  I restarted the BBB and tried before 
> > starting my application and it worked just fine. I started 
> up the app 
> > and the touch screen was locked up immediately, mouse 
> clicks delayed about 1/2 second. And I get Device or resource 
> busy from the cat.
> >
> 
> Is the using while using 
> /sys/bus/iio/devices/iio:device0/in_voltageX_raw in your program?

I'm not using /sys/bus/iio/devices/iio:device0/in_voltageX_raw in my program, 
I'm using the iio buffer system.

I tried using cat /sys/bus/iio/devices/iio:device0/in_voltageX_raw while my
program was running and it worked a couple of times, and got busy a bit also,
then the touch screen locked up.

I have not tried to use /sys/bus/iio/devices/iio:device0/in_voltageX_raw from
in my program, I was hoping for a lighter weight access that didn't require 
so many opens & closes. I'm under the impression that I can only get one 
reading per open if I try to read /sys/bus/iio/devices/iio:device0/in_voltageX_raw.
Or can I get multiple readings if I do multiple reads.

>  
> > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > 
> 

Re: BBB IIO ADC access not working

[Michael Welling]

On Wed, Aug 19, 2015 at 02:13:10PM -0700, Greg Wilson-Lindberg wrote:
> 
> I'm not using /sys/bus/iio/devices/iio:device0/in_voltageX_raw in my program, 
> I'm using the iio buffer system.
> 
> I tried using cat /sys/bus/iio/devices/iio:device0/in_voltageX_raw while my
> program was running and it worked a couple of times, and got busy a bit also,
> then the touch screen locked up.

This is expected because when the buffer is enabled the device IS busy.
> 
> I have not tried to use /sys/bus/iio/devices/iio:device0/in_voltageX_raw from
> in my program, I was hoping for a lighter weight access that didn't require 
> so many opens & closes. I'm under the impression that I can only get one 
> reading per open if I try to read /sys/bus/iio/devices/iio:device0/in_voltageX_raw.
> Or can I get multiple readings if I do multiple reads.
>

You should be able to keep the file descriptor open and perform multiple reads.

It is necessary lseek before reading from the same channel again.

lseek(fd, 0, SEEK_SET);

You will need a separate file descriptor for each channel.
 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Wednesday, August 19, 2015 2:29 PM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Wed, Aug 19, 2015 at 02:13:10PM -0700, Greg Wilson-Lindberg wrote:
> > 
> > I'm not using 
> /sys/bus/iio/devices/iio:device0/in_voltageX_raw in my 
> > program, I'm using the iio buffer system.
> > 
> > I tried using cat /sys/bus/iio/devices/iio:device0/in_voltageX_raw 
> > while my program was running and it worked a couple of 
> times, and got 
> > busy a bit also, then the touch screen locked up.
> 
> This is expected because when the buffer is enabled the 
> device IS busy.
> > 
> > I have not tried to use 
> > /sys/bus/iio/devices/iio:device0/in_voltageX_raw from in my 
> program, I 
> > was hoping for a lighter weight access that didn't require so many 
> > opens & closes. I'm under the impression that I can only 
> get one reading per open if I try to read 
> /sys/bus/iio/devices/iio:device0/in_voltageX_raw.
> > Or can I get multiple readings if I do multiple reads.
> >
> 
> You should be able to keep the file descriptor open and 
> perform multiple reads.
> 
> It is necessary lseek before reading from the same channel again.
> 
> lseek(fd, 0, SEEK_SET);
> 
> You will need a separate file descriptor for each channel.
>  

So, in that case, can I just open it once and leave it open?
Is it reading from a buffer, or is it reading what is current in the ADC? 
Can I just set up a timer to get readings to average then?

Re: BBB IIO ADC access not working

[Michael Welling]

On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg Wilson-Lindberg wrote:
> 
> So, in that case, can I just open it once and leave it open?

Yes.

> Is it reading from a buffer, or is it reading what is current in the ADC? 

It is the current reading.

> Can I just set up a timer to get readings to average then?

Sure.

Here are some helper functions:

int iio_adc_open_channel(int dev_num, int chan_num)
{
	char filename[255];

	sprintf(filename, "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
			dev_num, chan_num);

	return open(filename, O_RDONLY);
}

int iio_adc_read_channel(int fd)
{
	int count;
	char buffer[255];
	int value = -1;

	lseek(fd,0,SEEK_SET);

	count = read(fd, buffer, 255);

	if (count > 0)
		value = strtoul(buffer, NULL, 10);

	return value;
}

Example usage:

int fd;
.
.

fd = iio_adc_open_channel(0, 4);
.
.

while (1)
{
	printf("ADC = %x\n", iio_adc_read_channel(fd));
}

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Wednesday, August 19, 2015 2:43 PM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg Wilson-Lindberg wrote:
> > 
> > So, in that case, can I just open it once and leave it open?
> 
> Yes.
> 
> > Is it reading from a buffer, or is it reading what is 
> current in the ADC? 
> 
> It is the current reading.
> 
> > Can I just set up a timer to get readings to average then?
> 
> Sure.
> 
> Here are some helper functions:
> 
> int iio_adc_open_channel(int dev_num, int chan_num) {
> 	char filename[255];
> 
> 	sprintf(filename, 
> "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> 			dev_num, chan_num);
> 
> 	return open(filename, O_RDONLY);
> }
> 
> int iio_adc_read_channel(int fd)
> {
> 	int count;
> 	char buffer[255];
> 	int value = -1;
> 
> 	lseek(fd,0,SEEK_SET);
> 
> 	count = read(fd, buffer, 255);
> 
> 	if (count > 0)
> 		value = strtoul(buffer, NULL, 10);
> 
> 	return value;
> }
> 
> Example usage:
> 
> int fd;
> .
> .
> 
> fd = iio_adc_open_channel(0, 4);
> .
> .
> 
> while (1)
> {
> 	printf("ADC = %x\n", iio_adc_read_channel(fd)); }
> 
> 

I converted to using this interface and left the system running overnight and 
the touch screen was locked up this morning.

Re: BBB IIO ADC access not working

[Michael Welling]

On Thu, Aug 20, 2015 at 08:50:28AM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Wednesday, August 19, 2015 2:43 PM
> > To: Greg Wilson-Lindberg
> > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg Wilson-Lindberg wrote:
> > > 
> > > So, in that case, can I just open it once and leave it open?
> > 
> > Yes.
> > 
> > > Is it reading from a buffer, or is it reading what is 
> > current in the ADC? 
> > 
> > It is the current reading.
> > 
> > > Can I just set up a timer to get readings to average then?
> > 
> > Sure.
> > 
> > Here are some helper functions:
> > 
> > int iio_adc_open_channel(int dev_num, int chan_num) {
> > 	char filename[255];
> > 
> > 	sprintf(filename, 
> > "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> > 			dev_num, chan_num);
> > 
> > 	return open(filename, O_RDONLY);
> > }
> > 
> > int iio_adc_read_channel(int fd)
> > {
> > 	int count;
> > 	char buffer[255];
> > 	int value = -1;
> > 
> > 	lseek(fd,0,SEEK_SET);
> > 
> > 	count = read(fd, buffer, 255);
> > 
> > 	if (count > 0)
> > 		value = strtoul(buffer, NULL, 10);
> > 
> > 	return value;
> > }
> > 
> > Example usage:
> > 
> > int fd;
> > .
> > .
> > 
> > fd = iio_adc_open_channel(0, 4);
> > .
> > .
> > 
> > while (1)
> > {
> > 	printf("ADC = %x\n", iio_adc_read_channel(fd)); }
> > 
> > 
> 
> I converted to using this interface and left the system running overnight and 
> the touch screen was locked up this morning.

This is without any modifications to the kernel?

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Thursday, August 20, 2015 9:14 AM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Thu, Aug 20, 2015 at 08:50:28AM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Wednesday, August 19, 2015 2:43 PM
> > > To: Greg Wilson-Lindberg
> > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg 
> Wilson-Lindberg wrote:
> > > > 
> > > > So, in that case, can I just open it once and leave it open?
> > > 
> > > Yes.
> > > 
> > > > Is it reading from a buffer, or is it reading what is
> > > current in the ADC? 
> > > 
> > > It is the current reading.
> > > 
> > > > Can I just set up a timer to get readings to average then?
> > > 
> > > Sure.
> > > 
> > > Here are some helper functions:
> > > 
> > > int iio_adc_open_channel(int dev_num, int chan_num) {
> > > 	char filename[255];
> > > 
> > > 	sprintf(filename,
> > > "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> > > 			dev_num, chan_num);
> > > 
> > > 	return open(filename, O_RDONLY);
> > > }
> > > 
> > > int iio_adc_read_channel(int fd)
> > > {
> > > 	int count;
> > > 	char buffer[255];
> > > 	int value = -1;
> > > 
> > > 	lseek(fd,0,SEEK_SET);
> > > 
> > > 	count = read(fd, buffer, 255);
> > > 
> > > 	if (count > 0)
> > > 		value = strtoul(buffer, NULL, 10);
> > > 
> > > 	return value;
> > > }
> > > 
> > > Example usage:
> > > 
> > > int fd;
> > > .
> > > .
> > > 
> > > fd = iio_adc_open_channel(0, 4);
> > > .
> > > .
> > > 
> > > while (1)
> > > {
> > > 	printf("ADC = %x\n", iio_adc_read_channel(fd)); }
> > > 
> > > 
> > 
> > I converted to using this interface and left the system running 
> > overnight and the touch screen was locked up this morning.
> 
> This is without any modifications to the kernel?
> 

This was still running the kernel modifications.  I've restarted it this morning 
without the kernel modifications.

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

> -----Original Message-----
> From: Greg Wilson-Lindberg 
> Sent: Thursday, August 20, 2015 9:19 AM
> To: 'Michael Welling'
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: RE: BBB IIO ADC access not working
> 
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > Michael Welling
> > Sent: Thursday, August 20, 2015 9:14 AM
> > To: Greg Wilson-Lindberg
> > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Thu, Aug 20, 2015 at 08:50:28AM -0700, Greg 
> Wilson-Lindberg wrote:
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Michael Welling [mailto:mwelling79@gmail.com] On 
> Behalf Of 
> > > > Michael Welling
> > > > Sent: Wednesday, August 19, 2015 2:43 PM
> > > > To: Greg Wilson-Lindberg
> > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > Subject: Re: BBB IIO ADC access not working
> > > > 
> > > > On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg
> > Wilson-Lindberg wrote:
> > > > > 
> > > > > So, in that case, can I just open it once and leave it open?
> > > > 
> > > > Yes.
> > > > 
> > > > > Is it reading from a buffer, or is it reading what is
> > > > current in the ADC? 
> > > > 
> > > > It is the current reading.
> > > > 
> > > > > Can I just set up a timer to get readings to average then?
> > > > 
> > > > Sure.
> > > > 
> > > > Here are some helper functions:
> > > > 
> > > > int iio_adc_open_channel(int dev_num, int chan_num) {
> > > > 	char filename[255];
> > > > 
> > > > 	sprintf(filename,
> > > > "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> > > > 			dev_num, chan_num);
> > > > 
> > > > 	return open(filename, O_RDONLY);
> > > > }
> > > > 
> > > > int iio_adc_read_channel(int fd)
> > > > {
> > > > 	int count;
> > > > 	char buffer[255];
> > > > 	int value = -1;
> > > > 
> > > > 	lseek(fd,0,SEEK_SET);
> > > > 
> > > > 	count = read(fd, buffer, 255);
> > > > 
> > > > 	if (count > 0)
> > > > 		value = strtoul(buffer, NULL, 10);
> > > > 
> > > > 	return value;
> > > > }
> > > > 
> > > > Example usage:
> > > > 
> > > > int fd;
> > > > .
> > > > .
> > > > 
> > > > fd = iio_adc_open_channel(0, 4);
> > > > .
> > > > .
> > > > 
> > > > while (1)
> > > > {
> > > > 	printf("ADC = %x\n", iio_adc_read_channel(fd)); }
> > > > 
> > > > 
> > > 
> > > I converted to using this interface and left the system running 
> > > overnight and the touch screen was locked up this morning.
> > 
> > This is without any modifications to the kernel?
> > 
> 
> This was still running the kernel modifications.  I've 
> restarted it this morning without the kernel modifications.

I just dumped what I'm reading from the sys fs and all I'm getting back is -1.

Re: BBB IIO ADC access not working

[Michael Welling]

On Thu, Aug 20, 2015 at 10:27:30AM -0700, Greg Wilson-Lindberg wrote:
> 
> 
> > -----Original Message-----
> > From: Greg Wilson-Lindberg 
> > Sent: Thursday, August 20, 2015 9:19 AM
> > To: 'Michael Welling'
> > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: RE: BBB IIO ADC access not working
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Thursday, August 20, 2015 9:14 AM
> > > To: Greg Wilson-Lindberg
> > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > On Thu, Aug 20, 2015 at 08:50:28AM -0700, Greg 
> > Wilson-Lindberg wrote:
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On 
> > Behalf Of 
> > > > > Michael Welling
> > > > > Sent: Wednesday, August 19, 2015 2:43 PM
> > > > > To: Greg Wilson-Lindberg
> > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > Subject: Re: BBB IIO ADC access not working
> > > > > 
> > > > > On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg
> > > Wilson-Lindberg wrote:
> > > > > > 
> > > > > > So, in that case, can I just open it once and leave it open?
> > > > > 
> > > > > Yes.
> > > > > 
> > > > > > Is it reading from a buffer, or is it reading what is
> > > > > current in the ADC? 
> > > > > 
> > > > > It is the current reading.
> > > > > 
> > > > > > Can I just set up a timer to get readings to average then?
> > > > > 
> > > > > Sure.
> > > > > 
> > > > > Here are some helper functions:
> > > > > 
> > > > > int iio_adc_open_channel(int dev_num, int chan_num) {
> > > > > 	char filename[255];
> > > > > 
> > > > > 	sprintf(filename,
> > > > > "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> > > > > 			dev_num, chan_num);
> > > > > 
> > > > > 	return open(filename, O_RDONLY);
> > > > > }
> > > > > 
> > > > > int iio_adc_read_channel(int fd)
> > > > > {
> > > > > 	int count;
> > > > > 	char buffer[255];
> > > > > 	int value = -1;
> > > > > 
> > > > > 	lseek(fd,0,SEEK_SET);
> > > > > 
> > > > > 	count = read(fd, buffer, 255);
> > > > > 
> > > > > 	if (count > 0)
> > > > > 		value = strtoul(buffer, NULL, 10);
> > > > > 
> > > > > 	return value;
> > > > > }
> > > > > 
> > > > > Example usage:
> > > > > 
> > > > > int fd;
> > > > > .
> > > > > .
> > > > > 
> > > > > fd = iio_adc_open_channel(0, 4);
> > > > > .
> > > > > .
> > > > > 
> > > > > while (1)
> > > > > {
> > > > > 	printf("ADC = %x\n", iio_adc_read_channel(fd)); }
> > > > > 
> > > > > 
> > > > 
> > > > I converted to using this interface and left the system running 
> > > > overnight and the touch screen was locked up this morning.
> > > 
> > > This is without any modifications to the kernel?
> > > 
> > 
> > This was still running the kernel modifications.  I've 
> > restarted it this morning without the kernel modifications.
> 
> I just dumped what I'm reading from the sys fs and all I'm getting back is -1.

Are you doing error checking on the file descriptor on open?
> 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Thursday, August 20, 2015 10:31 AM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Thu, Aug 20, 2015 at 10:27:30AM -0700, Greg Wilson-Lindberg wrote:
> > 
> > 
> > > -----Original Message-----
> > > From: Greg Wilson-Lindberg
> > > Sent: Thursday, August 20, 2015 9:19 AM
> > > To: 'Michael Welling'
> > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: RE: BBB IIO ADC access not working
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Michael Welling [mailto:mwelling79@gmail.com] On 
> Behalf Of 
> > > > Michael Welling
> > > > Sent: Thursday, August 20, 2015 9:14 AM
> > > > To: Greg Wilson-Lindberg
> > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > Subject: Re: BBB IIO ADC access not working
> > > > 
> > > > On Thu, Aug 20, 2015 at 08:50:28AM -0700, Greg
> > > Wilson-Lindberg wrote:
> > > > >  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On
> > > Behalf Of
> > > > > > Michael Welling
> > > > > > Sent: Wednesday, August 19, 2015 2:43 PM
> > > > > > To: Greg Wilson-Lindberg
> > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > Subject: Re: BBB IIO ADC access not working
> > > > > > 
> > > > > > On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg
> > > > Wilson-Lindberg wrote:
> > > > > > > 
> > > > > > > So, in that case, can I just open it once and 
> leave it open?
> > > > > > 
> > > > > > Yes.
> > > > > > 
> > > > > > > Is it reading from a buffer, or is it reading what is
> > > > > > current in the ADC? 
> > > > > > 
> > > > > > It is the current reading.
> > > > > > 
> > > > > > > Can I just set up a timer to get readings to average then?
> > > > > > 
> > > > > > Sure.
> > > > > > 
> > > > > > Here are some helper functions:
> > > > > > 
> > > > > > int iio_adc_open_channel(int dev_num, int chan_num) {
> > > > > > 	char filename[255];
> > > > > > 
> > > > > > 	sprintf(filename,
> > > > > > "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> > > > > > 			dev_num, chan_num);
> > > > > > 
> > > > > > 	return open(filename, O_RDONLY); }
> > > > > > 
> > > > > > int iio_adc_read_channel(int fd) {
> > > > > > 	int count;
> > > > > > 	char buffer[255];
> > > > > > 	int value = -1;
> > > > > > 
> > > > > > 	lseek(fd,0,SEEK_SET);
> > > > > > 
> > > > > > 	count = read(fd, buffer, 255);
> > > > > > 
> > > > > > 	if (count > 0)
> > > > > > 		value = strtoul(buffer, NULL, 10);
> > > > > > 
> > > > > > 	return value;
> > > > > > }
> > > > > > 
> > > > > > Example usage:
> > > > > > 
> > > > > > int fd;
> > > > > > .
> > > > > > .
> > > > > > 
> > > > > > fd = iio_adc_open_channel(0, 4); .
> > > > > > .
> > > > > > 
> > > > > > while (1)
> > > > > > {
> > > > > > 	printf("ADC = %x\n", iio_adc_read_channel(fd)); }
> > > > > > 
> > > > > > 
> > > > > 
> > > > > I converted to using this interface and left the 
> system running 
> > > > > overnight and the touch screen was locked up this morning.
> > > > 
> > > > This is without any modifications to the kernel?
> > > > 
> > > 
> > > This was still running the kernel modifications.  I've 
> restarted it 
> > > this morning without the kernel modifications.
> > 
> > I just dumped what I'm reading from the sys fs and all I'm 
> getting back is -1.
> 
> Are you doing error checking on the file descriptor on open?
> > 
> 

You were right, I had gone back to the original kernel that RCN shipped with 
the image and it doesn't export /sys/bus/iio.

I rebuilt the 3.14.49-ti-r62 kernel, which is the same release as the kernel in the image, but it does export /sys/bus/iio, so that much is working better.

But (there's always a but, isn't there), I'm reading three channels from the ADC, 4, 5, & 6. Channel 4 gets a good reading maybe 60% of the time I read it. Channel 5 
gets a good reading maybe every 40-50 tries. Channel 6 hardly ever gets a good
reading.

I guess I could just loop if I get a busy response, although I don't know how many 
times I will get that return before I get a good reading.

Re: BBB IIO ADC access not working

[Michael Welling]

On Thu, Aug 20, 2015 at 11:41:03AM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Thursday, August 20, 2015 10:31 AM
> > To: Greg Wilson-Lindberg
> > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Thu, Aug 20, 2015 at 10:27:30AM -0700, Greg Wilson-Lindberg wrote:
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Greg Wilson-Lindberg
> > > > Sent: Thursday, August 20, 2015 9:19 AM
> > > > To: 'Michael Welling'
> > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > Subject: RE: BBB IIO ADC access not working
> > > > 
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On 
> > Behalf Of 
> > > > > Michael Welling
> > > > > Sent: Thursday, August 20, 2015 9:14 AM
> > > > > To: Greg Wilson-Lindberg
> > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > Subject: Re: BBB IIO ADC access not working
> > > > > 
> > > > > On Thu, Aug 20, 2015 at 08:50:28AM -0700, Greg
> > > > Wilson-Lindberg wrote:
> > > > > >  
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On
> > > > Behalf Of
> > > > > > > Michael Welling
> > > > > > > Sent: Wednesday, August 19, 2015 2:43 PM
> > > > > > > To: Greg Wilson-Lindberg
> > > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > > Subject: Re: BBB IIO ADC access not working
> > > > > > > 
> > > > > > > On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg
> > > > > Wilson-Lindberg wrote:
> > > > > > > > 
> > > > > > > > So, in that case, can I just open it once and 
> > leave it open?
> > > > > > > 
> > > > > > > Yes.
> > > > > > > 
> > > > > > > > Is it reading from a buffer, or is it reading what is
> > > > > > > current in the ADC? 
> > > > > > > 
> > > > > > > It is the current reading.
> > > > > > > 
> > > > > > > > Can I just set up a timer to get readings to average then?
> > > > > > > 
> > > > > > > Sure.
> > > > > > > 
> > > > > > > Here are some helper functions:
> > > > > > > 
> > > > > > > int iio_adc_open_channel(int dev_num, int chan_num) {
> > > > > > > 	char filename[255];
> > > > > > > 
> > > > > > > 	sprintf(filename,
> > > > > > > "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> > > > > > > 			dev_num, chan_num);
> > > > > > > 
> > > > > > > 	return open(filename, O_RDONLY); }
> > > > > > > 
> > > > > > > int iio_adc_read_channel(int fd) {
> > > > > > > 	int count;
> > > > > > > 	char buffer[255];
> > > > > > > 	int value = -1;
> > > > > > > 
> > > > > > > 	lseek(fd,0,SEEK_SET);
> > > > > > > 
> > > > > > > 	count = read(fd, buffer, 255);
> > > > > > > 
> > > > > > > 	if (count > 0)
> > > > > > > 		value = strtoul(buffer, NULL, 10);
> > > > > > > 
> > > > > > > 	return value;
> > > > > > > }
> > > > > > > 
> > > > > > > Example usage:
> > > > > > > 
> > > > > > > int fd;
> > > > > > > .
> > > > > > > .
> > > > > > > 
> > > > > > > fd = iio_adc_open_channel(0, 4); .
> > > > > > > .
> > > > > > > 
> > > > > > > while (1)
> > > > > > > {
> > > > > > > 	printf("ADC = %x\n", iio_adc_read_channel(fd)); }
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > I converted to using this interface and left the 
> > system running 
> > > > > > overnight and the touch screen was locked up this morning.
> > > > > 
> > > > > This is without any modifications to the kernel?
> > > > > 
> > > > 
> > > > This was still running the kernel modifications.  I've 
> > restarted it 
> > > > this morning without the kernel modifications.
> > > 
> > > I just dumped what I'm reading from the sys fs and all I'm 
> > getting back is -1.
> > 
> > Are you doing error checking on the file descriptor on open?
> > > 
> > 
> 
> You were right, I had gone back to the original kernel that RCN shipped with 
> the image and it doesn't export /sys/bus/iio.
> 
> I rebuilt the 3.14.49-ti-r62 kernel, which is the same release as the kernel in the image, but it does export /sys/bus/iio, so that much is working better.
> 
> But (there's always a but, isn't there), I'm reading three channels from the ADC, 4, 5, & 6. Channel 4 gets a good reading maybe 60% of the time I read it. Channel 5 
> gets a good reading maybe every 40-50 tries. Channel 6 hardly ever gets a good
> reading.
> 
> I guess I could just loop if I get a busy response, although I don't know how many 
> times I will get that return before I get a good reading.
>

What is the indicator that the reading is bad?
 

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Thursday, August 20, 2015 12:23 PM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Thu, Aug 20, 2015 at 11:41:03AM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Thursday, August 20, 2015 10:31 AM
> > > To: Greg Wilson-Lindberg
> > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > On Thu, Aug 20, 2015 at 10:27:30AM -0700, Greg 
> Wilson-Lindberg wrote:
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Greg Wilson-Lindberg
> > > > > Sent: Thursday, August 20, 2015 9:19 AM
> > > > > To: 'Michael Welling'
> > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > Subject: RE: BBB IIO ADC access not working
> > > > > 
> > > > >  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On
> > > Behalf Of
> > > > > > Michael Welling
> > > > > > Sent: Thursday, August 20, 2015 9:14 AM
> > > > > > To: Greg Wilson-Lindberg
> > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > Subject: Re: BBB IIO ADC access not working
> > > > > > 
> > > > > > On Thu, Aug 20, 2015 at 08:50:28AM -0700, Greg
> > > > > Wilson-Lindberg wrote:
> > > > > > >  
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On
> > > > > Behalf Of
> > > > > > > > Michael Welling
> > > > > > > > Sent: Wednesday, August 19, 2015 2:43 PM
> > > > > > > > To: Greg Wilson-Lindberg
> > > > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > > > Subject: Re: BBB IIO ADC access not working
> > > > > > > > 
> > > > > > > > On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg
> > > > > > Wilson-Lindberg wrote:
> > > > > > > > > 
> > > > > > > > > So, in that case, can I just open it once and
> > > leave it open?
> > > > > > > > 
> > > > > > > > Yes.
> > > > > > > > 
> > > > > > > > > Is it reading from a buffer, or is it reading what is
> > > > > > > > current in the ADC? 
> > > > > > > > 
> > > > > > > > It is the current reading.
> > > > > > > > 
> > > > > > > > > Can I just set up a timer to get readings to 
> average then?
> > > > > > > > 
> > > > > > > > Sure.
> > > > > > > > 
> > > > > > > > Here are some helper functions:
> > > > > > > > 
> > > > > > > > int iio_adc_open_channel(int dev_num, int chan_num) {
> > > > > > > > 	char filename[255];
> > > > > > > > 
> > > > > > > > 	sprintf(filename,
> > > > > > > > "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> > > > > > > > 			dev_num, chan_num);
> > > > > > > > 
> > > > > > > > 	return open(filename, O_RDONLY); }
> > > > > > > > 
> > > > > > > > int iio_adc_read_channel(int fd) {
> > > > > > > > 	int count;
> > > > > > > > 	char buffer[255];
> > > > > > > > 	int value = -1;
> > > > > > > > 
> > > > > > > > 	lseek(fd,0,SEEK_SET);
> > > > > > > > 
> > > > > > > > 	count = read(fd, buffer, 255);
> > > > > > > > 
> > > > > > > > 	if (count > 0)
> > > > > > > > 		value = strtoul(buffer, NULL, 10);
> > > > > > > > 
> > > > > > > > 	return value;
> > > > > > > > }
> > > > > > > > 
> > > > > > > > Example usage:
> > > > > > > > 
> > > > > > > > int fd;
> > > > > > > > .
> > > > > > > > .
> > > > > > > > 
> > > > > > > > fd = iio_adc_open_channel(0, 4); .
> > > > > > > > .
> > > > > > > > 
> > > > > > > > while (1)
> > > > > > > > {
> > > > > > > > 	printf("ADC = %x\n", 
> iio_adc_read_channel(fd)); }
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > I converted to using this interface and left the
> > > system running
> > > > > > > overnight and the touch screen was locked up this morning.
> > > > > > 
> > > > > > This is without any modifications to the kernel?
> > > > > > 
> > > > > 
> > > > > This was still running the kernel modifications.  I've
> > > restarted it
> > > > > this morning without the kernel modifications.
> > > > 
> > > > I just dumped what I'm reading from the sys fs and all I'm
> > > getting back is -1.
> > > 
> > > Are you doing error checking on the file descriptor on open?
> > > > 
> > > 
> > 
> > You were right, I had gone back to the original kernel that RCN 
> > shipped with the image and it doesn't export /sys/bus/iio.
> > 
> > I rebuilt the 3.14.49-ti-r62 kernel, which is the same 
> release as the kernel in the image, but it does export 
> /sys/bus/iio, so that much is working better.
> > 
> > But (there's always a but, isn't there), I'm reading three channels 
> > from the ADC, 4, 5, & 6. Channel 4 gets a good reading maybe 60% of 
> > the time I read it. Channel 5 gets a good reading maybe 
> every 40-50 tries. Channel 6 hardly ever gets a good reading.
> > 
> > I guess I could just loop if I get a busy response, 
> although I don't 
> > know how many times I will get that return before I get a 
> good reading.
> >
> 
> What is the indicator that the reading is bad?
>  

I get back -1 if the channel is busy.
I just put in a loop and for channel 4 I get either 1 or 2 tries to get a good 
sample. Channels 5 & 6 are always returning a good sample on the second read.

I'll have to leave this on for overnight to see if the touch screen will lock up.

Re: BBB IIO ADC access not working

[Michael Welling]

On Thu, Aug 20, 2015 at 01:21:17PM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Thursday, August 20, 2015 12:23 PM
> > To: Greg Wilson-Lindberg
> > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > Subject: Re: BBB IIO ADC access not working
> > 
> > On Thu, Aug 20, 2015 at 11:41:03AM -0700, Greg Wilson-Lindberg wrote:
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > > Michael Welling
> > > > Sent: Thursday, August 20, 2015 10:31 AM
> > > > To: Greg Wilson-Lindberg
> > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > Subject: Re: BBB IIO ADC access not working
> > > > 
> > > > On Thu, Aug 20, 2015 at 10:27:30AM -0700, Greg 
> > Wilson-Lindberg wrote:
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Greg Wilson-Lindberg
> > > > > > Sent: Thursday, August 20, 2015 9:19 AM
> > > > > > To: 'Michael Welling'
> > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > Subject: RE: BBB IIO ADC access not working
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On
> > > > Behalf Of
> > > > > > > Michael Welling
> > > > > > > Sent: Thursday, August 20, 2015 9:14 AM
> > > > > > > To: Greg Wilson-Lindberg
> > > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > > Subject: Re: BBB IIO ADC access not working
> > > > > > > 
> > > > > > > On Thu, Aug 20, 2015 at 08:50:28AM -0700, Greg
> > > > > > Wilson-Lindberg wrote:
> > > > > > > >  
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On
> > > > > > Behalf Of
> > > > > > > > > Michael Welling
> > > > > > > > > Sent: Wednesday, August 19, 2015 2:43 PM
> > > > > > > > > To: Greg Wilson-Lindberg
> > > > > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > > > > Subject: Re: BBB IIO ADC access not working
> > > > > > > > > 
> > > > > > > > > On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg
> > > > > > > Wilson-Lindberg wrote:
> > > > > > > > > > 
> > > > > > > > > > So, in that case, can I just open it once and
> > > > leave it open?
> > > > > > > > > 
> > > > > > > > > Yes.
> > > > > > > > > 
> > > > > > > > > > Is it reading from a buffer, or is it reading what is
> > > > > > > > > current in the ADC? 
> > > > > > > > > 
> > > > > > > > > It is the current reading.
> > > > > > > > > 
> > > > > > > > > > Can I just set up a timer to get readings to 
> > average then?
> > > > > > > > > 
> > > > > > > > > Sure.
> > > > > > > > > 
> > > > > > > > > Here are some helper functions:
> > > > > > > > > 
> > > > > > > > > int iio_adc_open_channel(int dev_num, int chan_num) {
> > > > > > > > > 	char filename[255];
> > > > > > > > > 
> > > > > > > > > 	sprintf(filename,
> > > > > > > > > "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> > > > > > > > > 			dev_num, chan_num);
> > > > > > > > > 
> > > > > > > > > 	return open(filename, O_RDONLY); }
> > > > > > > > > 
> > > > > > > > > int iio_adc_read_channel(int fd) {
> > > > > > > > > 	int count;
> > > > > > > > > 	char buffer[255];
> > > > > > > > > 	int value = -1;
> > > > > > > > > 
> > > > > > > > > 	lseek(fd,0,SEEK_SET);
> > > > > > > > > 
> > > > > > > > > 	count = read(fd, buffer, 255);
> > > > > > > > > 
> > > > > > > > > 	if (count > 0)
> > > > > > > > > 		value = strtoul(buffer, NULL, 10);
> > > > > > > > > 
> > > > > > > > > 	return value;
> > > > > > > > > }
> > > > > > > > > 
> > > > > > > > > Example usage:
> > > > > > > > > 
> > > > > > > > > int fd;
> > > > > > > > > .
> > > > > > > > > .
> > > > > > > > > 
> > > > > > > > > fd = iio_adc_open_channel(0, 4); .
> > > > > > > > > .
> > > > > > > > > 
> > > > > > > > > while (1)
> > > > > > > > > {
> > > > > > > > > 	printf("ADC = %x\n", 
> > iio_adc_read_channel(fd)); }
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I converted to using this interface and left the
> > > > system running
> > > > > > > > overnight and the touch screen was locked up this morning.
> > > > > > > 
> > > > > > > This is without any modifications to the kernel?
> > > > > > > 
> > > > > > 
> > > > > > This was still running the kernel modifications.  I've
> > > > restarted it
> > > > > > this morning without the kernel modifications.
> > > > > 
> > > > > I just dumped what I'm reading from the sys fs and all I'm
> > > > getting back is -1.
> > > > 
> > > > Are you doing error checking on the file descriptor on open?
> > > > > 
> > > > 
> > > 
> > > You were right, I had gone back to the original kernel that RCN 
> > > shipped with the image and it doesn't export /sys/bus/iio.
> > > 
> > > I rebuilt the 3.14.49-ti-r62 kernel, which is the same 
> > release as the kernel in the image, but it does export 
> > /sys/bus/iio, so that much is working better.
> > > 
> > > But (there's always a but, isn't there), I'm reading three channels 
> > > from the ADC, 4, 5, & 6. Channel 4 gets a good reading maybe 60% of 
> > > the time I read it. Channel 5 gets a good reading maybe 
> > every 40-50 tries. Channel 6 hardly ever gets a good reading.
> > > 
> > > I guess I could just loop if I get a busy response, 
> > although I don't 
> > > know how many times I will get that return before I get a 
> > good reading.
> > >
> > 
> > What is the indicator that the reading is bad?
> >  
> 
> I get back -1 if the channel is busy.
> I just put in a loop and for channel 4 I get either 1 or 2 tries to get a good 
> sample. Channels 5 & 6 are always returning a good sample on the second read.
> 
> I'll have to leave this on for overnight to see if the touch screen will lock up.

You could try adding a poll to the read function to wait for readings to be ready.

int iio_adc_read_channel(int fd)
{
	int count;
	char buffer[255];
	int value = -1;
	struct pollfd pfd;

	pfd.fd = fd;
	pfd.events = POLLIN;
	pfd.revents = POLLIN;

	lseek(fd,0,SEEK_SET);
	poll(&pfd, 1, -1);
	count = read(fd, buffer, 255);

	if (count > 0)
		value = strtoul(buffer, NULL, 10);

	return value;
}

RE: BBB IIO ADC access not working

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Thursday, August 20, 2015 1:49 PM
> To: Greg Wilson-Lindberg
> Cc: Daniel Baluta; linux-iio@vger.kernel.org
> Subject: Re: BBB IIO ADC access not working
> 
> On Thu, Aug 20, 2015 at 01:21:17PM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Thursday, August 20, 2015 12:23 PM
> > > To: Greg Wilson-Lindberg
> > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > Subject: Re: BBB IIO ADC access not working
> > > 
> > > On Thu, Aug 20, 2015 at 11:41:03AM -0700, Greg 
> Wilson-Lindberg wrote:
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Michael Welling [mailto:mwelling79@gmail.com] 
> On Behalf Of 
> > > > > Michael Welling
> > > > > Sent: Thursday, August 20, 2015 10:31 AM
> > > > > To: Greg Wilson-Lindberg
> > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > Subject: Re: BBB IIO ADC access not working
> > > > > 
> > > > > On Thu, Aug 20, 2015 at 10:27:30AM -0700, Greg
> > > Wilson-Lindberg wrote:
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Greg Wilson-Lindberg
> > > > > > > Sent: Thursday, August 20, 2015 9:19 AM
> > > > > > > To: 'Michael Welling'
> > > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > > Subject: RE: BBB IIO ADC access not working
> > > > > > > 
> > > > > > >  
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On
> > > > > Behalf Of
> > > > > > > > Michael Welling
> > > > > > > > Sent: Thursday, August 20, 2015 9:14 AM
> > > > > > > > To: Greg Wilson-Lindberg
> > > > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > > > Subject: Re: BBB IIO ADC access not working
> > > > > > > > 
> > > > > > > > On Thu, Aug 20, 2015 at 08:50:28AM -0700, Greg
> > > > > > > Wilson-Lindberg wrote:
> > > > > > > > >  
> > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Michael Welling 
> [mailto:mwelling79@gmail.com] On
> > > > > > > Behalf Of
> > > > > > > > > > Michael Welling
> > > > > > > > > > Sent: Wednesday, August 19, 2015 2:43 PM
> > > > > > > > > > To: Greg Wilson-Lindberg
> > > > > > > > > > Cc: Daniel Baluta; linux-iio@vger.kernel.org
> > > > > > > > > > Subject: Re: BBB IIO ADC access not working
> > > > > > > > > > 
> > > > > > > > > > On Wed, Aug 19, 2015 at 02:34:39PM -0700, Greg
> > > > > > > > Wilson-Lindberg wrote:
> > > > > > > > > > > 
> > > > > > > > > > > So, in that case, can I just open it once and
> > > > > leave it open?
> > > > > > > > > > 
> > > > > > > > > > Yes.
> > > > > > > > > > 
> > > > > > > > > > > Is it reading from a buffer, or is it 
> reading what 
> > > > > > > > > > > is
> > > > > > > > > > current in the ADC? 
> > > > > > > > > > 
> > > > > > > > > > It is the current reading.
> > > > > > > > > > 
> > > > > > > > > > > Can I just set up a timer to get readings to
> > > average then?
> > > > > > > > > > 
> > > > > > > > > > Sure.
> > > > > > > > > > 
> > > > > > > > > > Here are some helper functions:
> > > > > > > > > > 
> > > > > > > > > > int iio_adc_open_channel(int dev_num, int 
> chan_num) {
> > > > > > > > > > 	char filename[255];
> > > > > > > > > > 
> > > > > > > > > > 	sprintf(filename,
> > > > > > > > > > 
> "/sys/bus/iio/devices/iio:device%d/in_voltage%d_raw",
> > > > > > > > > > 			dev_num, chan_num);
> > > > > > > > > > 
> > > > > > > > > > 	return open(filename, O_RDONLY); }
> > > > > > > > > > 
> > > > > > > > > > int iio_adc_read_channel(int fd) {
> > > > > > > > > > 	int count;
> > > > > > > > > > 	char buffer[255];
> > > > > > > > > > 	int value = -1;
> > > > > > > > > > 
> > > > > > > > > > 	lseek(fd,0,SEEK_SET);
> > > > > > > > > > 
> > > > > > > > > > 	count = read(fd, buffer, 255);
> > > > > > > > > > 
> > > > > > > > > > 	if (count > 0)
> > > > > > > > > > 		value = strtoul(buffer, NULL, 10);
> > > > > > > > > > 
> > > > > > > > > > 	return value;
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > Example usage:
> > > > > > > > > > 
> > > > > > > > > > int fd;
> > > > > > > > > > .
> > > > > > > > > > .
> > > > > > > > > > 
> > > > > > > > > > fd = iio_adc_open_channel(0, 4); .
> > > > > > > > > > .
> > > > > > > > > > 
> > > > > > > > > > while (1)
> > > > > > > > > > {
> > > > > > > > > > 	printf("ADC = %x\n",
> > > iio_adc_read_channel(fd)); }
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I converted to using this interface and left the
> > > > > system running
> > > > > > > > > overnight and the touch screen was locked up 
> this morning.
> > > > > > > > 
> > > > > > > > This is without any modifications to the kernel?
> > > > > > > > 
> > > > > > > 
> > > > > > > This was still running the kernel modifications.  I've
> > > > > restarted it
> > > > > > > this morning without the kernel modifications.
> > > > > > 
> > > > > > I just dumped what I'm reading from the sys fs and all I'm
> > > > > getting back is -1.
> > > > > 
> > > > > Are you doing error checking on the file descriptor on open?
> > > > > > 
> > > > > 
> > > > 
> > > > You were right, I had gone back to the original kernel that RCN 
> > > > shipped with the image and it doesn't export /sys/bus/iio.
> > > > 
> > > > I rebuilt the 3.14.49-ti-r62 kernel, which is the same
> > > release as the kernel in the image, but it does export 
> /sys/bus/iio, 
> > > so that much is working better.
> > > > 
> > > > But (there's always a but, isn't there), I'm reading three 
> > > > channels from the ADC, 4, 5, & 6. Channel 4 gets a good reading 
> > > > maybe 60% of the time I read it. Channel 5 gets a good reading 
> > > > maybe
> > > every 40-50 tries. Channel 6 hardly ever gets a good reading.
> > > > 
> > > > I guess I could just loop if I get a busy response,
> > > although I don't
> > > > know how many times I will get that return before I get a
> > > good reading.
> > > >
> > > 
> > > What is the indicator that the reading is bad?
> > >  
> > 
> > I get back -1 if the channel is busy.
> > I just put in a loop and for channel 4 I get either 1 or 2 tries to 
> > get a good sample. Channels 5 & 6 are always returning a 
> good sample on the second read.
> > 
> > I'll have to leave this on for overnight to see if the 
> touch screen will lock up.
> 
> You could try adding a poll to the read function to wait for 
> readings to be ready.
> 
> int iio_adc_read_channel(int fd)
> {
> 	int count;
> 	char buffer[255];
> 	int value = -1;
> 	struct pollfd pfd;
> 
> 	pfd.fd = fd;
> 	pfd.events = POLLIN;
> 	pfd.revents = POLLIN;
> 
> 	lseek(fd,0,SEEK_SET);
> 	poll(&pfd, 1, -1);
> 	count = read(fd, buffer, 255);
> 
> 	if (count > 0)
> 		value = strtoul(buffer, NULL, 10);
> 
> 	return value;
> }
> 
> 
I left my multiple read loop in. In the captures that I have done, I've not seen it take more than two reads to get a good result.
The touch screen was locked up this morning though.

I think that I'm going to have to recommend that we switch to an external ADC to solve these problems.