> -----Original Message-----
> From: Steve Sakoman [mailto:sakoman@...]
> 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
> On Thu, Aug 23, 2012 at 4:00 PM, Keane, Ben (STRX)
> <ben.keane@...> 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:
> 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@...:~# cat /sys/class/hwmon/hwmon0/device/in2_input
> root@...:~# cat /sys/class/hwmon/hwmon0/device/in3_input
> root@...:~# cat /sys/class/hwmon/hwmon0/device/in4_input
> root@...:~# cat /sys/class/hwmon/hwmon0/device/in5_input
> root@...:~# cat /sys/class/hwmon/hwmon0/device/in6_input
> root@...:~# cat /sys/class/hwmon/hwmon0/device/in7_input
> root@...:~# uname -a
> Linux omap3-multi 3.5.0 #1 PREEMPT Sun Aug 19 20:48:24 PDT 2012 armv7l
> 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)
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
> > 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:mathieu.merineau@...]
> > Sent: Friday, 24 August 2012 3:57 AM
> > To: gumstix-users@...
> > 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.