From: thor F. <tho...@ya...> - 2011-11-06 16:52:53
|
Hi all. I recently started dabbling with the ADC stuff on my Overo Air and a Tobi board. I installed the latest kernel/software from Steve Sakoman's site (thanks!): Gnome -r13. I can apply a voltage to ADCIN2 and ADCIN7 and get expected readings from sysfs files (/sys/class/hwmon/hwmon0/device/in?_input). When I apply a voltage (or ground) to ADCIN3-6 the value is the 70-90 milivolt float that is seen on ADCIN2 (ADCIN7 floats to 1.4v). Way back (kernel 2.6.34?) there was a bug that Steve had a patch for (setting the clocks correctly), but I thought that was merged and pushed upstream 2 years ago. Is there some way to determine if the clock settings are wrong? Or reason out why I can't read 66% of the ADC channels brought out to the 40-pin header? tks! |
From: mathineau <mat...@po...> - 2012-08-22 15:30:17
|
I'm having the same problem here. Saw posts where there was a bug in initialization for these pins in kernel 3.0, but I thought it was corrected in Steve's image. Just downloaded the current console image this morning as I use Gumstix's official image usually, but I'm having the same problem. When I apply 1.25V on ADC2 or ADC7, I'm reading the correct voltage, but when I apply the same on ADC3, I'm just reading around 500 mV. And I'm seeing the voltage increasing on ADC4. Can it be something regarding the impedances ? -- View this message in context: http://gumstix.8.n6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4965189.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Steve S. <sa...@gm...> - 2012-08-22 15:39:50
|
On Sun, Nov 6, 2011 at 8:52 AM, thor Farrish <tho...@ya...> wrote: > I can apply a voltage to ADCIN2 and ADCIN7 and get expected readings > from sysfs files (/sys/class/hwmon/hwmon0/device/in?_input). > > When I apply a voltage (or ground) to ADCIN3-6 the value is the 70-90 > milivolt float that is seen on ADCIN2 (ADCIN7 floats to 1.4v). > You want to be sure your kernel build has this patch: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=8e69860734d81494e5b14b00fecb8b2af598ba32 If you are using a recent GNOME r13 build it should have this patch. Steve > Hi all. > > I recently started dabbling with the ADC stuff on my Overo Air and > a Tobi board. I installed the latest kernel/software from Steve > Sakoman's site (thanks!): Gnome -r13. > > I can apply a voltage to ADCIN2 and ADCIN7 and get expected readings > from sysfs files (/sys/class/hwmon/hwmon0/device/in?_input). > > When I apply a voltage (or ground) to ADCIN3-6 the value is the 70-90 > milivolt float that is seen on ADCIN2 (ADCIN7 floats to 1.4v). > > Way back (kernel 2.6.34?) there was a bug that Steve had a patch > for (setting the clocks correctly), but I thought that was merged > and pushed upstream 2 years ago. > > Is there some way to determine if the clock settings are wrong? Or > reason out why I can't read 66% of the ADC channels brought > out to the 40-pin header? > > tks! > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: mathineau <mat...@po...> - 2012-08-23 17:56:49
|
I'm using the last Sakoman's console image, so the patch should be in it, isn't it ? I also tried with others images and with the Gumstix connected to either Pinto or Tobi. In every case, I can read the good values on ADC2 and ADC7, but they seems to have some crosstalk between ADC3 and ADC4, same thing with ADC5 and ADC6 as when I put 1.8V on ADC4, I can't read more than 1600 mV on the Gumstix and reads 1500 mV on ADC3. If I keep ADC4 connected to 1.8V and connects ADC3 to GND, I then read respectively 1.5V and 0.13V. -- View this message in context: http://gumstix.8.n6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4965202.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Keane, B. (STRX) <ben...@ka...> - 2012-08-23 23:00:29
Attachments:
madc-adcin3-6.patch
|
I'm not sure if that patch is in the Sakoman console image - I don't use the Sakoman console image... If it is applied, keep reading ... I had the same problem with the ADC's in the 3.3.0 Kernel, and that patch/solution did not fix it. Attached to this email is a messy patch which is my solution around the problem. It needs to be cleaned up, but I haven't had time. I would like to submit it to the maintainers for comment, but I also haven't had time. It is a massive hack with lots of printing out registers I needed to work out the problem. So the final solution would probably look a lot different... But you are welcome to try it. Depending on your kernel version you may not be able to apply the patch directly to the source. Basically from what I can understand from reading the Kernel source and what my patch tries to work around is that in the twl4030-usb sub-system, i2c access gets turned off when the physical layer goes to sleep on init. The twl4030-usb sub-system is loaded before the madc driver, and therefore the Steve Sakamon patch won't work because those registers can't be changed. Therefore I turn i2c_access on, then set the same registers Steve sets in his patch and then turn i2c_access off. In the older kernels like 2.6.32 - the twl4030 usb sub-system doesn't turn off i2c_access during its initialization, and therefore Steve Sakoman's patch can work. I hope this helps. I welcome any feedback or offers to help make a decent patch that can be submitted up-stream if it is proven to be useful for other people? Or even help on who I can submit it too ;) This is my first attempt at a public kernel patch/issue. On my system - once I changed this code, it allowed me to read the correct voltages instead of an offset of up to 400mV as the voltage got closer to 2.5V. Before this patch, your ADC pin would be drawing up to 7mA at 2V and the ADC value might be only only 1.6V - with this patch that problem is fixed and it should draw 1.5uA instead. I don't believe it fixes the leakage between the pins - i.e. if you put a voltage on ADCIN4 you can see a voltage on ADCIN3 - but I added external 100k pull-down resistors to each ADC input, which drains the leaked voltage away - but I have a custom PCB and am not using one of the Gumstix supporting boards. Ben -----Original Message----- From: mathineau [mailto:mat...@po...] Sent: Friday, 24 August 2012 3:57 AM To: gum...@li... Subject: Re: [Gumstix-users] using ADCIN on 3.0 kernel - no readings for ADC3-6 I'm using the last Sakoman's console image, so the patch should be in it, isn't it ? I also tried with others images and with the Gumstix connected to either Pinto or Tobi. In every case, I can read the good values on ADC2 and ADC7, but they seems to have some crosstalk between ADC3 and ADC4, same thing with ADC5 and ADC6 as when I put 1.8V on ADC4, I can't read more than 1600 mV on the Gumstix and reads 1500 mV on ADC3. If I keep ADC4 connected to 1.8V and connects ADC3 to GND, I then read respectively 1.5V and 0.13V. -- View this message in context: http://gumstix.8.n6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4965202.html Sent from the Gumstix mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ______________________________________________________________________ CAUTION: This message was sent via the Public Internet and its authenticity cannot be guaranteed. PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. |
From: Steve S. <sa...@gm...> - 2012-08-23 23:30:13
|
On Thu, Aug 23, 2012 at 10:56 AM, mathineau <mat...@po...> wrote: > I'm using the last Sakoman's console image, so the patch should be in it, > isn't it ? I also tried with others images and with the Gumstix connected to > either Pinto or Tobi. > > In every case, I can read the good values on ADC2 and ADC7, but they seems > to have some crosstalk between ADC3 and ADC4, same thing with ADC5 and ADC6 > as when I put 1.8V on ADC4, I can't read more than 1600 mV on the Gumstix > and reads 1500 mV on ADC3. If I keep ADC4 connected to 1.8V and connects > ADC3 to GND, I then read respectively 1.5V and 0.13V. I just tried an r13 image with all of the adc inputs connected to 1.8V Every channel reads within a 2 mV range: root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in2_input 1808 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in3_input 1810 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in4_input 1808 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in5_input 1810 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in6_input 1810 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in7_input 1810 root@omap3-multi:~# uname -a Linux omap3-multi 3.0.0 #1 Tue Jul 24 08:58:09 PDT 2012 armv7l GNU/Linux I honestly have no clue why it isn't working for you! Steve |
From: Steve S. <sa...@gm...> - 2012-08-23 23:43:00
|
On Thu, Aug 23, 2012 at 4:00 PM, Keane, Ben (STRX) <ben...@ka...> wrote: > I had the same problem with the ADC's in the 3.3.0 Kernel, and that patch/solution did not fix it. Hmmm . . . I have the patch applied to my 3.5 kernel build: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=ab98828cd9b85c104e5e31ef440bbfff5c7422c6 And with 1.8V connected to all madc inputs I get results in the same range that I did on the 3.0 kernel: root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in2_input 1808 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in3_input 1810 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in4_input 1810 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in5_input 1808 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in6_input 1808 root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in7_input 1808 root@omap3-multi:~# uname -a Linux omap3-multi 3.5.0 #1 PREEMPT Sun Aug 19 20:48:24 PDT 2012 armv7l GNU/Linux I'm very puzzled that you are getting different results! Do you build madc into the kernel or as a module? How about musb? Steve > Attached to this email is a messy patch which is my solution around the problem. It needs to be cleaned up, but I haven't had time. I would like to submit it to the maintainers for comment, but I also haven't had time. It is a massive hack with lots of printing out registers I needed to work out the problem. So the final solution would probably look a lot different... But you are welcome to try it. Depending on your kernel version you may not be able to apply the patch directly to the source. > > Basically from what I can understand from reading the Kernel source and what my patch tries to work around is that in the twl4030-usb sub-system, i2c access gets turned off when the physical layer goes to sleep on init. The twl4030-usb sub-system is loaded before the madc driver, and therefore the Steve Sakamon patch won't work because those registers can't be changed. Therefore I turn i2c_access on, then set the same registers Steve sets in his patch and then turn i2c_access off. In the older kernels like 2.6.32 - the twl4030 usb sub-system doesn't turn off i2c_access during its initialization, and therefore Steve Sakoman's patch can work. > > I hope this helps. I welcome any feedback or offers to help make a decent patch that can be submitted up-stream if it is proven to be useful for other people? Or even help on who I can submit it too ;) This is my first attempt at a public kernel patch/issue. > > On my system - once I changed this code, it allowed me to read the correct voltages instead of an offset of up to 400mV as the voltage got closer to 2.5V. Before this patch, your ADC pin would be drawing up to 7mA at 2V and the ADC value might be only only 1.6V - with this patch that problem is fixed and it should draw 1.5uA instead. > > I don't believe it fixes the leakage between the pins - i.e. if you put a voltage on ADCIN4 you can see a voltage on ADCIN3 - but I added external 100k pull-down resistors to each ADC input, which drains the leaked voltage away - but I have a custom PCB and am not using one of the Gumstix supporting boards. > > Ben > > -----Original Message----- > From: mathineau [mailto:mat...@po...] > Sent: Friday, 24 August 2012 3:57 AM > To: gum...@li... > Subject: Re: [Gumstix-users] using ADCIN on 3.0 kernel - no readings for ADC3-6 > > I'm using the last Sakoman's console image, so the patch should be in it, isn't it ? I also tried with others images and with the Gumstix connected to either Pinto or Tobi. > > In every case, I can read the good values on ADC2 and ADC7, but they seems to have some crosstalk between ADC3 and ADC4, same thing with ADC5 and ADC6 as when I put 1.8V on ADC4, I can't read more than 1600 mV on the Gumstix and reads 1500 mV on ADC3. If I keep ADC4 connected to 1.8V and connects > ADC3 to GND, I then read respectively 1.5V and 0.13V. > > > > -- > View this message in context: http://gumstix.8.n6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4965202.html > Sent from the Gumstix mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > ______________________________________________________________________ > CAUTION: This message was sent via the Public Internet and its authenticity cannot be guaranteed. > > PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Keane, B. (STRX) <ben...@ka...> - 2012-08-24 00:25:20
|
Hi Steve, > -----Original Message----- > From: Steve Sakoman [mailto:sa...@gm...] > Sent: Friday, 24 August 2012 9:43 AM > To: General mailing list for gumstix users. > Cc: Keane, Ben (STRX) > Subject: Re: [Gumstix-users] using ADCIN on 3.0 kernel - no readings > for > ADC3-6 > > On Thu, Aug 23, 2012 at 4:00 PM, Keane, Ben (STRX) > <ben...@ka...> wrote: > > > I had the same problem with the ADC's in the 3.3.0 Kernel, and that > patch/solution did not fix it. > > Hmmm . . . I have the patch applied to my 3.5 kernel build: > > http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap- > 2.6.git;a=commitdiff;h=ab98828cd9b85c104e5e31ef440bbfff5c7422c6 > > And with 1.8V connected to all madc inputs I get results in the same > range that I did on the 3.0 kernel: > > root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in2_input > 1808 > root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in3_input > 1810 > root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in4_input > 1810 > root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in5_input > 1808 > root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in6_input > 1808 > root@omap3-multi:~# cat /sys/class/hwmon/hwmon0/device/in7_input > 1808 > root@omap3-multi:~# uname -a > Linux omap3-multi 3.5.0 #1 PREEMPT Sun Aug 19 20:48:24 PDT 2012 armv7l > GNU/Linux > > I'm very puzzled that you are getting different results! > > Do you build madc into the kernel or as a module? How about musb? They are both compiled into the kernel - not as a module. I have wondered in the past if it is because I don't have anything plugged in when the musb module is initializing and then puts the i2c access to sleep - for want of a better word. It may have something to do with drivers/usb/otg/twl4030-usb.c ... I had to comment out the call to __twl4030_phy_resume() in the twl4030_usb_probe() function.. I think because in to __twl4030_phy_resume() it thinks my usb system is in T2_USB_MODE_ULPI mode. if (twl->usb_mode == T2_USB_MODE_ULPI) twl4030_i2c_access(twl, 0); Doesn't ULPI mode have something to do with the ADCIN3-6 pins and them used for handsfree? # uname -a Linux localhost 3.3.0+ #40 PREEMPT Mon Aug 13 10:54:27 EST 2012 armv7l unknown Ben > > Steve > > > Attached to this email is a messy patch which is my solution around > > the > problem. It needs to be cleaned up, but I haven't had time. I would > like to submit it to the maintainers for comment, but I also haven't > had time. It is a massive hack with lots of printing out registers I > needed to work out the problem. So the final solution would probably > look a lot different... But you are welcome to try it. Depending on > your kernel version you may not be able to apply the patch directly to the source. > > > > Basically from what I can understand from reading the Kernel source > > and > what my patch tries to work around is that in the twl4030-usb > sub-system, i2c access gets turned off when the physical layer goes to > sleep on init. The twl4030-usb sub-system is loaded before the madc > driver, and therefore the Steve Sakamon patch won't work because those registers can't be changed. > Therefore I turn i2c_access on, then set the same registers Steve sets > in his patch and then turn i2c_access off. In the older kernels like > 2.6.32 - the > twl4030 usb sub-system doesn't turn off i2c_access during its > initialization, and therefore Steve Sakoman's patch can work. > > > > I hope this helps. I welcome any feedback or offers to help make a > > decent > patch that can be submitted up-stream if it is proven to be useful for > other people? Or even help on who I can submit it too ;) This is my > first attempt at a public kernel patch/issue. > > > > On my system - once I changed this code, it allowed me to read the > > correct > voltages instead of an offset of up to 400mV as the voltage got closer to 2.5V. > Before this patch, your ADC pin would be drawing up to 7mA at 2V and > the ADC value might be only only 1.6V - with this patch that problem > is fixed and it should draw 1.5uA instead. > > > > I don't believe it fixes the leakage between the pins - i.e. if you > > put a > voltage on ADCIN4 you can see a voltage on ADCIN3 - but I added > external 100k pull-down resistors to each ADC input, which drains the > leaked voltage away - but I have a custom PCB and am not using one of > the Gumstix supporting boards. > > > > Ben > > > > -----Original Message----- > > From: mathineau [mailto:mat...@po...] > > Sent: Friday, 24 August 2012 3:57 AM > > To: gum...@li... > > Subject: Re: [Gumstix-users] using ADCIN on 3.0 kernel - no readings > > for ADC3-6 > > > > I'm using the last Sakoman's console image, so the patch should be > > in it, > isn't it ? I also tried with others images and with the Gumstix > connected to either Pinto or Tobi. > > > > In every case, I can read the good values on ADC2 and ADC7, but they > > seems to have some crosstalk between ADC3 and ADC4, same thing with > > ADC5 and ADC6 as when I put 1.8V on ADC4, I can't read more than > > 1600 mV on the Gumstix and reads 1500 mV on ADC3. If I keep ADC4 > > connected to 1.8V and connects > > ADC3 to GND, I then read respectively 1.5V and 0.13V. > > > > > > PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. |
From: mathineau <mat...@po...> - 2012-08-24 19:34:01
|
I'm using console image (and also tried GNOME image) that was created with the mksdcard.sh script, so I'm not compiling my own image, but as I understand the patch should be applied in these image. Applying 1.8V to ADC3 and ADC4 gives me : root@omap3-multi:/sys/class/hwmon/hwmon0/device# cat in3_input 1373 root@omap3-multi:/sys/class/hwmon/hwmon0/device# cat in4_input 1356 root@omap3-multi:/sys/class/hwmon/hwmon0/device# uname -a Linux omap3-multi 3.0.0 #1 Fri Jul 27 07:10:27 PDT 2012 armv7l GNU/Linux If I apply 0V to ADC3 and 1.8V to ADC4 gives me : root@omap3-multi:/sys/class/hwmon/hwmon0/device# cat in3_input 237 root@omap3-multi:/sys/class/hwmon/hwmon0/device# cat in4_input 1187 I'll get the necessary files to compile my own image and I'll give a try to Ben's patch. -- View this message in context: http://gumstix.8.n6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4965215.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Steve S. <sa...@gm...> - 2012-08-24 20:01:36
|
Did you have anything plugged into the musb socket when you did these measurements? If not, could you retry the measurements with something plugged into the musb socket? Steve On Fri, Aug 24, 2012 at 12:33 PM, mathineau <mat...@po...> wrote: > I'm using console image (and also tried GNOME image) that was created with > the mksdcard.sh script, so I'm not compiling my own image, but as I > understand the patch should be applied in these image. > > Applying 1.8V to ADC3 and ADC4 gives me : > root@omap3-multi:/sys/class/hwmon/hwmon0/device# cat in3_input > 1373 > root@omap3-multi:/sys/class/hwmon/hwmon0/device# cat in4_input > 1356 > root@omap3-multi:/sys/class/hwmon/hwmon0/device# uname -a > Linux omap3-multi 3.0.0 #1 Fri Jul 27 07:10:27 PDT 2012 armv7l GNU/Linux > > If I apply 0V to ADC3 and 1.8V to ADC4 gives me : > root@omap3-multi:/sys/class/hwmon/hwmon0/device# cat in3_input > 237 > root@omap3-multi:/sys/class/hwmon/hwmon0/device# cat in4_input > 1187 > > I'll get the necessary files to compile my own image and I'll give a try to > Ben's patch. > > > > -- > View this message in context: http://gumstix.8.n6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4965215.html > Sent from the Gumstix mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: mathineau <mat...@po...> - 2012-08-27 15:51:15
|
I'm reading the correct measurements when I'm using Sakoman's GNOME image on the Tobi board which I guess has the Ethernet plugged on the MUSB socket. But with the Pinto with nothing plugged on it, I'm still having the issue. I'm using the Pinto in my design so I need to find a way to make it work with it. -- View this message in context: http://gumstix.8.n6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4965223.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Steve S. <sa...@gm...> - 2012-08-27 16:10:16
|
On Mon, Aug 27, 2012 at 8:51 AM, mathineau <mat...@po...> wrote: > I'm reading the correct measurements when I'm using Sakoman's GNOME image on > the Tobi board which I guess has the Ethernet plugged on the MUSB socket. No, the Tobi ethernet is on the GPMC bus, not musb. > But with the Pinto with nothing plugged on it, I'm still having the issue. > I'm using the Pinto in my design so I need to find a way to make it work > with it. Do you get correct readings if you connect your Pinto to your dev machine with a usb cable? I'm wondering if there might be some connection to whether there is power on VBUS. Steve |
From: Mathieu M. <mat...@po...> - 2012-08-27 17:32:38
|
Indeed, if I boot the Gumstix with USB cable connected on the Pinto, I'm getting the correct readings. Le 2012-08-27 à 12:10, Steve Sakoman <sa...@gm...> a écrit : > On Mon, Aug 27, 2012 at 8:51 AM, mathineau <mat...@po...> wrote: >> I'm reading the correct measurements when I'm using Sakoman's GNOME image on >> the Tobi board which I guess has the Ethernet plugged on the MUSB socket. > > No, the Tobi ethernet is on the GPMC bus, not musb. > >> But with the Pinto with nothing plugged on it, I'm still having the issue. >> I'm using the Pinto in my design so I need to find a way to make it work >> with it. > > Do you get correct readings if you connect your Pinto to your dev > machine with a usb cable? > > I'm wondering if there might be some connection to whether there is > power on VBUS. > > Steve > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Keane, B. (STRX) <ben...@ka...> - 2012-08-27 23:34:46
|
Mathieu, Sweet. Thanks for confirming that. It only took me 4-5 days to work that out and make my hack-patch - it's great its confirmed! Steve, Do you have any ideas of how to correct this / make my patch nicer? What would you do in this situation normally? Ben > -----Original Message----- > From: Mathieu Mérineau [mailto:mat...@po...] > Sent: Tuesday, 28 August 2012 3:33 AM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] using ADCIN on 3.0 kernel - no readings for > ADC3-6 > > Indeed, if I boot the Gumstix with USB cable connected on the Pinto, I'm > getting the correct readings. > > Le 2012-08-27 à 12:10, Steve Sakoman <sa...@gm...> a écrit : > > > On Mon, Aug 27, 2012 at 8:51 AM, mathineau > <mat...@po...> wrote: > >> I'm reading the correct measurements when I'm using Sakoman's GNOME > >> image on the Tobi board which I guess has the Ethernet plugged on the > MUSB socket. > > > > No, the Tobi ethernet is on the GPMC bus, not musb. > > > >> But with the Pinto with nothing plugged on it, I'm still having the issue. > >> I'm using the Pinto in my design so I need to find a way to make it > >> work with it. > > > > Do you get correct readings if you connect your Pinto to your dev > > machine with a usb cable? > > > > I'm wondering if there might be some connection to whether there is > > power on VBUS. > > > > Steve > > > > ---------------------------------------------------------------------- > > -------- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > > Discussions will include endpoint security, mobile security and the > > latest in malware threats. > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > __________________________________________________________ > ____________ > CAUTION: This message was sent via the Public Internet and its authenticity > cannot be guaranteed. PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. |
From: Steve S. <sa...@gm...> - 2012-09-04 17:36:21
|
On Mon, Aug 27, 2012 at 4:34 PM, Keane, Ben (STRX) <ben...@ka...> wrote: > Do you have any ideas of how to correct this / make my patch nicer? What would you do in this situation normally? On my setup (with musb in OTG mode) all I do is load a gadget driver at boot time and the madc readings seem to be correct with or without a USB cable connected to the musb port. I typically load g_serial and start a getty on it so that if desired I can run a console session over USB. Steve >> -----Original Message----- >> From: Mathieu Mérineau [mailto:mat...@po...] >> Sent: Tuesday, 28 August 2012 3:33 AM >> To: General mailing list for gumstix users. >> Subject: Re: [Gumstix-users] using ADCIN on 3.0 kernel - no readings for >> ADC3-6 >> >> Indeed, if I boot the Gumstix with USB cable connected on the Pinto, I'm >> getting the correct readings. >> >> Le 2012-08-27 à 12:10, Steve Sakoman <sa...@gm...> a écrit : >> >> > On Mon, Aug 27, 2012 at 8:51 AM, mathineau >> <mat...@po...> wrote: >> >> I'm reading the correct measurements when I'm using Sakoman's GNOME >> >> image on the Tobi board which I guess has the Ethernet plugged on the >> MUSB socket. >> > >> > No, the Tobi ethernet is on the GPMC bus, not musb. >> > >> >> But with the Pinto with nothing plugged on it, I'm still having the issue. >> >> I'm using the Pinto in my design so I need to find a way to make it >> >> work with it. >> > >> > Do you get correct readings if you connect your Pinto to your dev >> > machine with a usb cable? >> > >> > I'm wondering if there might be some connection to whether there is >> > power on VBUS. >> > >> > Steve >> > >> > ---------------------------------------------------------------------- >> > -------- >> > Live Security Virtual Conference >> > Exclusive live event will cover all the ways today's security and >> > threat landscape has changed and how IT managers can respond. >> > Discussions will include endpoint security, mobile security and the >> > latest in malware threats. >> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> > _______________________________________________ >> > gumstix-users mailing list >> > gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and threat >> landscape has changed and how IT managers can respond. Discussions will >> include endpoint security, mobile security and the latest in malware threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> __________________________________________________________ >> ____________ >> CAUTION: This message was sent via the Public Internet and its authenticity >> cannot be guaranteed. > > PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Frank A. <ft...@ya...> - 2012-09-06 19:08:36
|
On 8/23/2012 8:25 PM, Keane, Ben (STRX) wrote: > > I have wondered in the past if it is because I don't have anything plugged in when the musb module is initializing and then puts the i2c access to sleep - for want of a better word. > > It may have something to do with drivers/usb/otg/twl4030-usb.c ... I had to comment out the call to __twl4030_phy_resume() in the twl4030_usb_probe() function.. > > I think because in to __twl4030_phy_resume() it thinks my usb system is in T2_USB_MODE_ULPI mode. > if (twl->usb_mode == T2_USB_MODE_ULPI) > twl4030_i2c_access(twl, 0); > > Doesn't ULPI mode have something to do with the ADCIN3-6 pins and them used for handsfree? You are in the right file, but you did not go far enough. If nothing is connected to the USB OTG port, the phy suspension code is called. In the chain of calls that follows, the vusb3v1 regulator is disabled. However, according to the OMAP power management manual, vusb3v1 is used "to bias the analog multiplexers on the four MCPC pins between the carkit and the MADC". I've seen if there is no bias on this mux, the MADC driver returns incorrect counts on these 4 pins that should be in A/D mode. If I plug something into the USB OTG port, the MADC driver returns the expected counts. I also created a debug version of the twl4030-usb driver, with the disabling of the vusb3v1 commented out and the MADC returns the correct counts regardless of the state of the USB OTG port. Since the vusb3v1 regulator is required for the proper operation of the mux and by extension the MADC and carkit mode, I believe that the vusb3v1 regulator should never be disabled. frank |
From: Chenbo <291...@qq...> - 2012-12-19 09:51:54
|
hi all: I have almost got it that there is a problem with ADC in the sakoman prebuilt image(3.0.0,I am using in my overo+tobi) .But I want to use ADCIN3-6, what should I do. Could you give me some advice? thanks Chenbo -- View this message in context: http://gumstix.8.n6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4966283.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: pg0h <ps...@gm...> - 2013-03-08 01:46:25
|
Following up on previous post - I have tried the following change in drivers/usb/otg/twl4030-usb.c based on/taken from code found in drivers/mfd/twl4030-madc.c static void twl4030_phy_power(struct twl4030_usb *twl, int on) { int ret; u8 regval; if (on) { regulator_enable(twl->usb3v1); regulator_enable(twl->usb1v8); /* * Disabling usb3v1 regulator (= writing 0 to VUSB3V1_DEV_GRP * in twl4030) resets the VUSB_DEDICATED2 register. This reset * enables VUSB3V1_SLEEP bit that remaps usb3v1 ACTIVE state to * SLEEP. We work around this by clearing the bit after usv3v1 * is re-activated. This ensures that VUSB3V1 is really active. */ twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB_DEDICATED2); regulator_enable(twl->usb1v5); __twl4030_phy_power(twl, 1); twl4030_usb_write(twl, PHY_CLK_CTRL, twl4030_usb_read(twl, PHY_CLK_CTRL) | (PHY_CLK_CTRL_CLOCKGATING_EN | PHY_CLK_CTRL_CLK32K_EN)); /* Enable ADCIN3 through 6 */ ret = twl_i2c_read_u8(TWL4030_MODULE_USB, ®val, TWL4030_USB_CARKIT_ANA_CTRL); if (ret) { dev_err(twl->dev, "unable to read reg CARKIT_ANA_CTRL 0x%X\n", TWL4030_USB_CARKIT_ANA_CTRL); } regval |= TWL4030_USB_SEL_MADC_MCPC; ret = twl_i2c_write_u8(TWL4030_MODULE_USB, regval, TWL4030_USB_CARKIT_ANA_CTRL); if (ret) { dev_err(twl->dev, "unable to write reg CARKIT_ANA_CTRL 0x%X\n", TWL4030_USB_CARKIT_ANA_CTRL); } } else { __twl4030_phy_power(twl, 0); regulator_disable(twl->usb1v5); regulator_disable(twl->usb1v8); regulator_disable(twl->usb3v1); } } This seems to have fixed my problem. Ethernet via USB-OTG working, and ADCIN3-6 reporting correct values via twl4030_madc_hwmon driver. I'm pretty new to the environment and working on kernel code, so I'm not sure if this is the best solution - or what other implications this change might have. Going to keep doing some tests - but otherwise looking promising. -- View this message in context: http://gumstix.8.n6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4966968.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: pg0h <ps...@gm...> - 2013-07-04 06:45:33
|
I had a look at this change, and I tried something similar initially. It works, however I found that while I was getting expected readings from ADC3-6 using this approach, I was no longer able to use USB OTG port for Ethernet-over-USB, or as serial gadget, etc. This was something I needed for the project I was workign on. For your application it may not be necessary for both of these functions to work, which may be fine. The fix I suggested, and subsequently tried by other posters, should allow ADCIN3-6 to work as well as allow you to use USB OTG port. -- View this message in context: http://gumstix.8.x6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4967502.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: pg0h <ps...@gm...> - 2013-07-04 06:50:38
|
Sorry, I got mixed with a different thread related to this problem which I also responded to a while ago: http://gumstix.8.x6.nabble.com/twl4030-madc-low-read-value-td4967139.html#none You might find some helpful info that is helpful for you in that thread. -- View this message in context: http://gumstix.8.x6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4967503.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Akram H. <ak...@aq...> - 2013-07-05 02:49:36
|
Thanks for the heads up, mate! On Thu, Jul 4, 2013 at 4:50 PM, pg0h <ps...@gm...> wrote: > Sorry, I got mixed with a different thread related to this problem which I > also responded to a while ago: > > > http://gumstix.8.x6.nabble.com/twl4030-madc-low-read-value-td4967139.html#none > > You might find some helpful info that is helpful for you in that thread. > > > > > > > > > > -- > View this message in context: > http://gumstix.8.x6.nabble.com/using-ADCIN-on-3-0-kernel-no-readings-for-ADC3-6-tp640585p4967503.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |