* [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.