All of lore.kernel.org
 help / color / mirror / Atom feed
* [lm-sensors] Output problem with adcxx  on at91
@ 2012-08-01 15:59 John Rippetoe
  2012-08-01 16:52 ` Guenter Roeck
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: John Rippetoe @ 2012-08-01 15:59 UTC (permalink / raw)
  To: lm-sensors

I am attempting to setup lm-sensors on an embedded platform, more 
specifically the Micromint Electrum 100.  I'm experiencing an issue with 
the output of the sensors program where the output is obviously bogus, 
especially given that all the values are identical.  Some basic details 
about the system:

- 6.04 Debian squeeze
- Atmel AT91SAM9G20 cpu (armv5)
- ADC128S052 SPI ADC
- atmel_spi driver built in to pre-compiled kernel
- hwmon, and adcxx loaded as modules later

The adcxx kernel module successfully loads and binds to the device. 
Reading the sysfs files it creates for each input, the same value of 
52799 is seen on each.  I know the device works because I have tested it 
with some userland example code provided by the manufacturer and get 
expected values for various inputs.

I initially had an issue with getting the adcxx module to bind with the 
device, but found that the problem was because of an alias problem.  In 
./arch/arm/mach-at91/board-electrum-100.c the ADC was declared with an 
alias as shown in the code segment below:

/static struct spi_board_info ek_spi_devices[] = {
/  .....
/    {    /* ADC128S052 analog inputs */
/        .modalias    = "adc128s052",
/        .chip_select    = 2,
/        .max_speed_hz    = 8 * 1000 * 1000,
/        .bus_num    = 1,
/    },
/  .....

Rather than change the alias in board-electrum-100.c and have to 
recompile and install a new kernel, I opted to add the alias as shown 
above to adcxx_ids[] in adcxx.c

/static const struct spi_device_id adcxx_ids[] = {
/    { "adcxx1s", 1 },
/    { "adcxx2s", 2 },
/    { "adcxx4s", 4 },
/    { "adcxx8s", 8 },
/    { "adc128s052", 8},   <-- added here
/    { },
/};

With that done, sensors starting giving me output, just not anything 
worth reading.  At this point I'm a little baffled as to what is causing 
this and crawling the internet has turned up nothing. Here is my output 
for sensors:

electrum100:~# sensors
adcxx8s-spi-1-2
Adapter: SPI adapter
in0:         +52.80 V
in1:         +52.80 V
in2:         +52.80 V
in3:         +52.80 V
in4:         +52.80 V
in5:         +52.80 V
in6:         +52.80 V
in7:         +52.80 V


Any help would be greatly appreciated.  Thank you.

     - John

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [lm-sensors] Output problem with adcxx  on at91
  2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
@ 2012-08-01 16:52 ` Guenter Roeck
  2012-08-01 20:12 ` John Rippetoe
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2012-08-01 16:52 UTC (permalink / raw)
  To: lm-sensors

On Wed, Aug 01, 2012 at 11:59:40AM -0400, John Rippetoe wrote:
> I am attempting to setup lm-sensors on an embedded platform, more
> specifically the Micromint Electrum 100.  I'm experiencing an issue
> with the output of the sensors program where the output is obviously
> bogus, especially given that all the values are identical.  Some
> basic details about the system:
> 
> - 6.04 Debian squeeze
> - Atmel AT91SAM9G20 cpu (armv5)
> - ADC128S052 SPI ADC
> - atmel_spi driver built in to pre-compiled kernel
> - hwmon, and adcxx loaded as modules later
> 
> The adcxx kernel module successfully loads and binds to the device.
> Reading the sysfs files it creates for each input, the same value of
> 52799 is seen on each.  I know the device works because I have
> tested it with some userland example code provided by the
> manufacturer and get expected values for various inputs.
> 
> I initially had an issue with getting the adcxx module to bind with
> the device, but found that the problem was because of an alias
> problem.  In ./arch/arm/mach-at91/board-electrum-100.c the ADC was
> declared with an alias as shown in the code segment below:
> 
> /static struct spi_board_info ek_spi_devices[] = {
> /  .....
> /    {    /* ADC128S052 analog inputs */
> /        .modalias    = "adc128s052",
> /        .chip_select    = 2,
> /        .max_speed_hz    = 8 * 1000 * 1000,
> /        .bus_num    = 1,
> /    },
> /  .....
> 
./arch/arm/mach-at91/board-electrum-100.c is not in mainline, so this is a bit
difficult. Given the above, it may even be that there is a separate driver for
the chip somewhere in your tree (ok, I think I found the patch, there isn't,
but that means this never worked).

Other than that, there could be many things wrong. Chip select, bus number,
clock speed, chip access mode. There is no example for a working instantiation
in the upstream kernel, so I have no idea what the valid parameters might be.
You mentioned user mode access worked - maybe you can compare it with the kernel
settings.

Guenter

> Rather than change the alias in board-electrum-100.c and have to
> recompile and install a new kernel, I opted to add the alias as
> shown above to adcxx_ids[] in adcxx.c
> 
> /static const struct spi_device_id adcxx_ids[] = {
> /    { "adcxx1s", 1 },
> /    { "adcxx2s", 2 },
> /    { "adcxx4s", 4 },
> /    { "adcxx8s", 8 },
> /    { "adc128s052", 8},   <-- added here
> /    { },
> /};
> 
> With that done, sensors starting giving me output, just not anything
> worth reading.  At this point I'm a little baffled as to what is
> causing this and crawling the internet has turned up nothing. Here
> is my output for sensors:
> 
> electrum100:~# sensors
> adcxx8s-spi-1-2
> Adapter: SPI adapter
> in0:         +52.80 V
> in1:         +52.80 V
> in2:         +52.80 V
> in3:         +52.80 V
> in4:         +52.80 V
> in5:         +52.80 V
> in6:         +52.80 V
> in7:         +52.80 V
> 
> 
> Any help would be greatly appreciated.  Thank you.
> 
>     - John
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> 

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [lm-sensors] Output problem with adcxx  on at91
  2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
  2012-08-01 16:52 ` Guenter Roeck
@ 2012-08-01 20:12 ` John Rippetoe
  2012-08-01 21:56 ` Guenter Roeck
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: John Rippetoe @ 2012-08-01 20:12 UTC (permalink / raw)
  To: lm-sensors

On 08/01/2012 12:52 PM, Guenter Roeck wrote:
> On Wed, Aug 01, 2012 at 11:59:40AM -0400, John Rippetoe wrote:
>> I am attempting to setup lm-sensors on an embedded platform, more
>> specifically the Micromint Electrum 100.  I'm experiencing an issue
>> with the output of the sensors program where the output is obviously
>> bogus, especially given that all the values are identical.  Some
>> basic details about the system:
>>
>> - 6.04 Debian squeeze
>> - Atmel AT91SAM9G20 cpu (armv5)
>> - ADC128S052 SPI ADC
>> - atmel_spi driver built in to pre-compiled kernel
>> - hwmon, and adcxx loaded as modules later
>>
>> The adcxx kernel module successfully loads and binds to the device.
>> Reading the sysfs files it creates for each input, the same value of
>> 52799 is seen on each.  I know the device works because I have
>> tested it with some userland example code provided by the
>> manufacturer and get expected values for various inputs.
>>
>> I initially had an issue with getting the adcxx module to bind with
>> the device, but found that the problem was because of an alias
>> problem.  In ./arch/arm/mach-at91/board-electrum-100.c the ADC was
>> declared with an alias as shown in the code segment below:
>>
>> /static struct spi_board_info ek_spi_devices[] = {
>> /  .....
>> /    {    /* ADC128S052 analog inputs */
>> /        .modalias    = "adc128s052",
>> /        .chip_select    = 2,
>> /        .max_speed_hz    = 8 * 1000 * 1000,
>> /        .bus_num    = 1,
>> /    },
>> /  .....
>>
> ./arch/arm/mach-at91/board-electrum-100.c is not in mainline, so this is a bit
> difficult. Given the above, it may even be that there is a separate driver for
> the chip somewhere in your tree (ok, I think I found the patch, there isn't,
> but that means this never worked).
I could have sworn that I saw it in mainline, but now that I check I see 
it is not there.  Sorry about that! I am not sure what you mean as far 
as the driver never working and exactly what patch you are talking 
about.  Could you clarify?
> Other than that, there could be many things wrong. Chip select, bus number,
> clock speed, chip access mode. There is no example for a working instantiation
> in the upstream kernel, so I have no idea what the valid parameters might be.
> You mentioned user mode access worked - maybe you can compare it with the kernel
> settings.
As far as I can tell (and I may be wrong here, this is all still pretty 
new to me) the bus and chip select are all correct.  Clock speed could 
be an issue I suppose.  I just did the reverse math on the value that 
the driver is reporting and realized that before it is converted, the 
raw value is 2 bytes worth of 1's.  I am going to trace through the 
spi_write_then_read() function in the adcxx driver and compare its 
method to that used by the user mode program and the atmel_spi driver.  
I'm not sure how far I am going to get though.

John
> Guenter
>
>> Rather than change the alias in board-electrum-100.c and have to
>> recompile and install a new kernel, I opted to add the alias as
>> shown above to adcxx_ids[] in adcxx.c
>>
>> /static const struct spi_device_id adcxx_ids[] = {
>> /    { "adcxx1s", 1 },
>> /    { "adcxx2s", 2 },
>> /    { "adcxx4s", 4 },
>> /    { "adcxx8s", 8 },
>> /    { "adc128s052", 8},   <-- added here
>> /    { },
>> /};
>>
>> With that done, sensors starting giving me output, just not anything
>> worth reading.  At this point I'm a little baffled as to what is
>> causing this and crawling the internet has turned up nothing. Here
>> is my output for sensors:
>>
>> electrum100:~# sensors
>> adcxx8s-spi-1-2
>> Adapter: SPI adapter
>> in0:         +52.80 V
>> in1:         +52.80 V
>> in2:         +52.80 V
>> in3:         +52.80 V
>> in4:         +52.80 V
>> in5:         +52.80 V
>> in6:         +52.80 V
>> in7:         +52.80 V
>>
>>
>> Any help would be greatly appreciated.  Thank you.
>>
>>      - John
>>
>> _______________________________________________
>> lm-sensors mailing list
>> lm-sensors@lm-sensors.org
>> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>>


-- 
Respectfully,

John Rippetoe
Communication Concepts
813-888-6611


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [lm-sensors] Output problem with adcxx  on at91
  2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
  2012-08-01 16:52 ` Guenter Roeck
  2012-08-01 20:12 ` John Rippetoe
@ 2012-08-01 21:56 ` Guenter Roeck
  2012-08-02  3:07 ` John
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2012-08-01 21:56 UTC (permalink / raw)
  To: lm-sensors

On Wed, Aug 01, 2012 at 04:12:23PM -0400, John Rippetoe wrote:
> On 08/01/2012 12:52 PM, Guenter Roeck wrote:
> >On Wed, Aug 01, 2012 at 11:59:40AM -0400, John Rippetoe wrote:
> >>I am attempting to setup lm-sensors on an embedded platform, more
> >>specifically the Micromint Electrum 100.  I'm experiencing an issue
> >>with the output of the sensors program where the output is obviously
> >>bogus, especially given that all the values are identical.  Some
> >>basic details about the system:
> >>
> >>- 6.04 Debian squeeze
> >>- Atmel AT91SAM9G20 cpu (armv5)
> >>- ADC128S052 SPI ADC
> >>- atmel_spi driver built in to pre-compiled kernel
> >>- hwmon, and adcxx loaded as modules later
> >>
> >>The adcxx kernel module successfully loads and binds to the device.
> >>Reading the sysfs files it creates for each input, the same value of
> >>52799 is seen on each.  I know the device works because I have
> >>tested it with some userland example code provided by the
> >>manufacturer and get expected values for various inputs.
> >>
> >>I initially had an issue with getting the adcxx module to bind with
> >>the device, but found that the problem was because of an alias
> >>problem.  In ./arch/arm/mach-at91/board-electrum-100.c the ADC was
> >>declared with an alias as shown in the code segment below:
> >>
> >>/static struct spi_board_info ek_spi_devices[] = {
> >>/  .....
> >>/    {    /* ADC128S052 analog inputs */
> >>/        .modalias    = "adc128s052",
> >>/        .chip_select    = 2,
> >>/        .max_speed_hz    = 8 * 1000 * 1000,
> >>/        .bus_num    = 1,
> >>/    },
> >>/  .....
> >>
> >./arch/arm/mach-at91/board-electrum-100.c is not in mainline, so this is a bit
> >difficult. Given the above, it may even be that there is a separate driver for
> >the chip somewhere in your tree (ok, I think I found the patch, there isn't,
> >but that means this never worked).
> I could have sworn that I saw it in mainline, but now that I check I
> see it is not there.  Sorry about that! I am not sure what you mean
> as far as the driver never working and exactly what patch you are
> talking about.  Could you clarify?

http://stoian.us/misc/files/linux-3.3.0-micromint.patch

Since the patch sets modalias to "adc128s052", and a driver with that name does
not exist in the kernel, it can not have worked, at least not with this
configuration.

> >Other than that, there could be many things wrong. Chip select, bus number,
> >clock speed, chip access mode. There is no example for a working instantiation
> >in the upstream kernel, so I have no idea what the valid parameters might be.
> >You mentioned user mode access worked - maybe you can compare it with the kernel
> >settings.
> As far as I can tell (and I may be wrong here, this is all still
> pretty new to me) the bus and chip select are all correct.  Clock
> speed could be an issue I suppose.  I just did the reverse math on
> the value that the driver is reporting and realized that before it
> is converted, the raw value is 2 bytes worth of 1's.  I am going to
> trace through the spi_write_then_read() function in the adcxx driver
> and compare its method to that used by the user mode program and the
> atmel_spi driver.  I'm not sure how far I am going to get though.
> 

Doesn't sound good, and I am not entirely sure if using spi_write_then_read() is
correct for this chip. You might try the access in single-channel mode to see if
it makes a difference.

Guenter

> John
> >Guenter
> >
> >>Rather than change the alias in board-electrum-100.c and have to
> >>recompile and install a new kernel, I opted to add the alias as
> >>shown above to adcxx_ids[] in adcxx.c
> >>
> >>/static const struct spi_device_id adcxx_ids[] = {
> >>/    { "adcxx1s", 1 },
> >>/    { "adcxx2s", 2 },
> >>/    { "adcxx4s", 4 },
> >>/    { "adcxx8s", 8 },
> >>/    { "adc128s052", 8},   <-- added here
> >>/    { },
> >>/};
> >>
> >>With that done, sensors starting giving me output, just not anything
> >>worth reading.  At this point I'm a little baffled as to what is
> >>causing this and crawling the internet has turned up nothing. Here
> >>is my output for sensors:
> >>
> >>electrum100:~# sensors
> >>adcxx8s-spi-1-2
> >>Adapter: SPI adapter
> >>in0:         +52.80 V
> >>in1:         +52.80 V
> >>in2:         +52.80 V
> >>in3:         +52.80 V
> >>in4:         +52.80 V
> >>in5:         +52.80 V
> >>in6:         +52.80 V
> >>in7:         +52.80 V
> >>
> >>
> >>Any help would be greatly appreciated.  Thank you.
> >>
> >>     - John
> >>
> >>_______________________________________________
> >>lm-sensors mailing list
> >>lm-sensors@lm-sensors.org
> >>http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> >>
> 
> 
> -- 
> Respectfully,
> 
> John Rippetoe
> Communication Concepts
> 813-888-6611
> 
> 

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [lm-sensors] Output problem with adcxx  on at91
  2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
                   ` (2 preceding siblings ...)
  2012-08-01 21:56 ` Guenter Roeck
@ 2012-08-02  3:07 ` John
  2012-08-10  6:46 ` Marc Pignat
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: John @ 2012-08-02  3:07 UTC (permalink / raw)
  To: lm-sensors

Guenter Roeck <linux <at> roeck-us.net> writes:
> 
> > >./arch/arm/mach-at91/board-electrum-100.c is not in mainline, so this is 
a bit
> > >difficult. Given the above, it may even be that there is a separate 
driver for
> > >the chip somewhere in your tree (ok, I think I found the patch, there 
isn't,
> > >but that means this never worked).
> > I could have sworn that I saw it in mainline, but now that I check I
> > see it is not there.  Sorry about that! I am not sure what you mean
> > as far as the driver never working and exactly what patch you are
> > talking about.  Could you clarify?
> 
> http://stoian.us/misc/files/linux-3.3.0-micromint.patch
> 
> Since the patch sets modalias to "adc128s052", and a driver with that name 
does
> not exist in the kernel, it can not have worked, at least not with this
> configuration.
> 

Oh, I see what you are referring to now.  That specicif modalias "adc128s052" 
is what I added to the adcxx driver in order to get it to bind to the device 
lsited there in that board configuration.  

> > >Other than that, there could be many things wrong. Chip select, bus 
number,
> > >clock speed, chip access mode. There is no example for a working 
instantiation
> > >in the upstream kernel, so I have no idea what the valid parameters might 
be.
> > >You mentioned user mode access worked - maybe you can compare it with the 
kernel
> > >settings.
> > As far as I can tell (and I may be wrong here, this is all still
> > pretty new to me) the bus and chip select are all correct.  Clock
> > speed could be an issue I suppose.  I just did the reverse math on
> > the value that the driver is reporting and realized that before it
> > is converted, the raw value is 2 bytes worth of 1's.  I am going to
> > trace through the spi_write_then_read() function in the adcxx driver
> > and compare its method to that used by the user mode program and the
> > atmel_spi driver.  I'm not sure how far I am going to get though.
> > 
> 
> Doesn't sound good, and I am not entirely sure if using spi_write_then_read
() is
> correct for this chip. You might try the access in single-channel mode to 
see if
> it makes a difference.


You are most definitely right.  After doing a little reading, I realize that I 
am going to be doing a little bit of driver 'rewriting' tomorrow.  More 
specifically, I am going to adapt the adcxx protocol driver to use the 
functions from the atmel_spi controller driver.  I will report back with 
results when finished, though I will more likely be back with more questions 
before than.  

Thanks again for the guidance.

John 


> 
> Guenter
> 



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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [lm-sensors] Output problem with adcxx  on at91
  2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
                   ` (3 preceding siblings ...)
  2012-08-02  3:07 ` John
@ 2012-08-10  6:46 ` Marc Pignat
  2012-08-10 12:31 ` John Rippetoe
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: Marc Pignat @ 2012-08-10  6:46 UTC (permalink / raw)
  To: lm-sensors

Hi John,

(You asked me in private, but I prefer to respond on the mailing list).

This driver was working, I wrote (and tested it) in 2008 ;)
The hardware it was running on was a custom at91rm9200 based board with
a adc084s051.
The last time a checked it, it was on 2.6.28, and it was still working fine.

I just had a look to the adc128s052 datasheet, and it looks compatible
with this driver.

Guenter, the spi_write_then_read() function is really the good one.
In brief, the write selects the channel, then the read reads the data.

I think the problem you're facing is either in the spi driver or in the
hardware.


Best regards


Marc

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [lm-sensors] Output problem with adcxx  on at91
  2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
                   ` (4 preceding siblings ...)
  2012-08-10  6:46 ` Marc Pignat
@ 2012-08-10 12:31 ` John Rippetoe
  2012-08-10 13:12 ` John Rippetoe
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: John Rippetoe @ 2012-08-10 12:31 UTC (permalink / raw)
  To: lm-sensors

Marc,

No problem at all, better for it to be accessible to others in case they run across similar issues. 

No kidding? As far as I know the at91rm9200 is essentially the grandfather of the at91sam9g20 I am using now; similar design but two revisions older. 

As of yesterday afternoon I myself have begun to suspect there could be a problem with the spi controller hardware within the mcu. I have also been working with the board manufacturer in solving this problem as well. In an attempt to troubleshoot  your driver I was comparing it with a different kernel driver recommended by my board manufacturer (Micromint) that was written by another customer. This particular driver has apparently been well received, however, I have yet to have any luck getting it to work. Even when a representative from the company sent it to me precompiled and tested, I still had no lluck getting it to work in an identical environment. 

Now I know the ADC works because I have userland code which directly accesses the ADC and I get correct output.  Note that this code completely bypasses the atmel spi controller and operates directly on the ADC128S052s registers. Suspicious right? 

I assume you are using the atmel-spi driver as the master controller driver correct? If so, did you make any modifications to it at all? 

Thanks for your help guys.

John

Marc Pignat <marc.pignat@hevs.ch> wrote:

>Hi John,
>
>(You asked me in private, but I prefer to respond on the mailing list).
>
>This driver was working, I wrote (and tested it) in 2008 ;)
>The hardware it was running on was a custom at91rm9200 based board with
>a adc084s051.
>The last time a checked it, it was on 2.6.28, and it was still working fine.
>
>I just had a look to the adc128s052 datasheet, and it looks compatible
>with this driver.
>
>Guenter, the spi_write_then_read() function is really the good one.
>In brief, the write selects the channel, then the read reads the data.
>
>I think the problem you're facing is either in the spi driver or in the
>hardware.
>
>
>Best regards
>
>
>Marc
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [lm-sensors] Output problem with adcxx  on at91
  2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
                   ` (5 preceding siblings ...)
  2012-08-10 12:31 ` John Rippetoe
@ 2012-08-10 13:12 ` John Rippetoe
  2012-08-10 16:34 ` Guenter Roeck
  2012-08-13  6:09 ` Marc Pignat
  8 siblings, 0 replies; 10+ messages in thread
From: John Rippetoe @ 2012-08-10 13:12 UTC (permalink / raw)
  To: lm-sensors

On 08/10/2012 08:31 AM, John Rippetoe wrote:
> Marc,
>
> No problem at all, better for it to be accessible to others in case they run across similar issues.
>
> No kidding? As far as I know the at91rm9200 is essentially the grandfather of the at91sam9g20 I am using now; similar design but two revisions older.
>
> As of yesterday afternoon I myself have begun to suspect there could be a problem with the spi controller hardware within the mcu. I have also been working with the board manufacturer in solving this problem as well. In an attempt to troubleshoot  your driver I was comparing it with a different kernel driver recommended by my board manufacturer (Micromint) that was written by another customer. This particular driver has apparently been well received, however, I have yet to have any luck getting it to work. Even when a representative from the company sent it to me precompiled and tested, I still had no lluck getting it to work in an identical environment.
>
> Now I know the ADC works because I have userland code which directly accesses the ADC and I get correct output.  Note that this code completely bypasses the atmel spi controller and operates directly on the ADC128S052s registers. Suspicious right?

Strike that, the userland example doesn't access the ADC directly. It 
actually accesses the spi controller directly.  I didn't have a copy of 
the code on hand when I wrote that and was mistaken.  Sorry about that.

>
> I assume you are using the atmel-spi driver as the master controller driver correct? If so, did you make any modifications to it at all?
>
> Thanks for your help guys.
>
> John
>
> Marc Pignat <marc.pignat@hevs.ch> wrote:
>
>> Hi John,
>>
>> (You asked me in private, but I prefer to respond on the mailing list).
>>
>> This driver was working, I wrote (and tested it) in 2008 ;)
>> The hardware it was running on was a custom at91rm9200 based board with
>> a adc084s051.
>> The last time a checked it, it was on 2.6.28, and it was still working fine.
>>
>> I just had a look to the adc128s052 datasheet, and it looks compatible
>> with this driver.
>>
>> Guenter, the spi_write_then_read() function is really the good one.
>> In brief, the write selects the channel, then the read reads the data.
>>
>> I think the problem you're facing is either in the spi driver or in the
>> hardware.
>>
>>
>> Best regards
>>
>>
>> Marc
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors


-- 
Respectfully,

John Rippetoe
Communication Concepts
813-888-6611


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [lm-sensors] Output problem with adcxx  on at91
  2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
                   ` (6 preceding siblings ...)
  2012-08-10 13:12 ` John Rippetoe
@ 2012-08-10 16:34 ` Guenter Roeck
  2012-08-13  6:09 ` Marc Pignat
  8 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2012-08-10 16:34 UTC (permalink / raw)
  To: lm-sensors

On Fri, Aug 10, 2012 at 08:46:20AM +0200, Marc Pignat wrote:
> Hi John,
> 
> (You asked me in private, but I prefer to respond on the mailing list).
> 
> This driver was working, I wrote (and tested it) in 2008 ;)
> The hardware it was running on was a custom at91rm9200 based board with
> a adc084s051.
> The last time a checked it, it was on 2.6.28, and it was still working fine.
> 
> I just had a look to the adc128s052 datasheet, and it looks compatible
> with this driver.
> 
> Guenter, the spi_write_then_read() function is really the good one.
> In brief, the write selects the channel, then the read reads the data.
> 
Yes, I noticed that this must be the idea. I _think_ it assumes that the first
access initiates the conversion, and the second access reads the data (while
providing a dummy ADC index). The data sheet seems to confirm that. In other
words, the read data obtained with the first write is the ADC result from the
_previous_ conversion. The data sheet seems to confirm that: "The first
conversion result after power-up will be that of IN0".

I think I am going to order a couple of those chips and check what is happening
on the bus with a Logic Analyzer.

Thanks,
Guenter

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [lm-sensors] Output problem with adcxx  on at91
  2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
                   ` (7 preceding siblings ...)
  2012-08-10 16:34 ` Guenter Roeck
@ 2012-08-13  6:09 ` Marc Pignat
  8 siblings, 0 replies; 10+ messages in thread
From: Marc Pignat @ 2012-08-13  6:09 UTC (permalink / raw)
  To: lm-sensors

John,

On 08/10/2012 03:12 PM, John Rippetoe wrote:
> On 08/10/2012 08:31 AM, John Rippetoe wrote:
>> Marc,
>>
>> No problem at all, better for it to be accessible to others in case
>> they run across similar issues.
>>
>> No kidding? As far as I know the at91rm9200 is essentially the
>> grandfather of the at91sam9g20 I am using now; similar design but two
>> revisions older.

If I good remember, the at91sam family has a newer spi controller.
...
>> I assume you are using the atmel-spi driver as the master controller
>> driver correct? If so, did you make any modifications to it at all?

I was using the one comming with the kernel ;)

Best regards

Marc

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2012-08-13  6:09 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-01 15:59 [lm-sensors] Output problem with adcxx on at91 John Rippetoe
2012-08-01 16:52 ` Guenter Roeck
2012-08-01 20:12 ` John Rippetoe
2012-08-01 21:56 ` Guenter Roeck
2012-08-02  3:07 ` John
2012-08-10  6:46 ` Marc Pignat
2012-08-10 12:31 ` John Rippetoe
2012-08-10 13:12 ` John Rippetoe
2012-08-10 16:34 ` Guenter Roeck
2012-08-13  6:09 ` Marc Pignat

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.