Getting alot of zero values from ads7846 using atmel_spi

Getting alot of zero values from ads7846 using atmel_spi

[Niclas Karlsson]

Hi,
I'm not sure this is the right mailinglist for my question, but I give
it a shot.

I'm working on a custom hardware running Linux kernel 2.6.32.3. The
hardware is based on the AT91SAM9263-ek evaluation board and have touch
screen attached to it. The touch screen controller is ads7846 and is
connected to SPI.

I'm in some trouble using the SPI (driver: atmel_spi).

ads7846 have two extra inputs that I want to use. The problem is that
when reading these inputs from sysfs I get a lot of zeroes when it
should read ( when no sensor is connected) ~3300 mV, e.g. 
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0
~# cat /sys/bus/spi/devices/spi0.1/in0_input
3299 <-- This one is correct.
~# cat /sys/bus/spi/devices/spi0.1/in0_input
0

I have measured the input and it's stable at 3.3V.

Do anyone know why I read so many zeroes?

I have made some printk in ads7846.c to trace the problem. It seemed to
read more correct values when I added the printks.

Thank you for the help,
Niclas

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d

Re: Getting alot of zero values from ads7846 using atmel_spi

[David Lamparter]

On Tue, Mar 08, 2011 at 10:44:56AM +0100, Niclas Karlsson wrote:
> Do anyone know why I read so many zeroes?

You're probably reading values faster than the chip supports. Check the
chip documentation for a maximum readout frequency or a ready flag.

> I have made some printk in ads7846.c to trace the problem. It seemed to
> read more correct values when I added the printks.

A printk takes quite some time on an ARM like yours. The throttle makes
it work...


David

P.S.: you're lucky to not get crap values - seems they got the chip
design right...


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: Getting alot of zero values from ads7846 using atmel_spi

[Niclas Karlsson]

tor 2011-03-10 klockan 15:41 +0100 skrev David Lamparter:
> On Tue, Mar 08, 2011 at 10:44:56AM +0100, Niclas Karlsson wrote:
> > Do anyone know why I read so many zeroes?
> 
> You're probably reading values faster than the chip supports. Check the
> chip documentation for a maximum readout frequency or a ready flag.
> > I have made some printk in ads7846.c to trace the problem. It seemed to
> > read more correct values when I added the printks.
> 
> A printk takes quite some time on an ARM like yours. The throttle makes
> it work...

I've made som further investigations. The atmel_spi.c driver utilize PDC
(Peripheral DMA Controller) and when I was tracing the problem I
discovered that the interrupt indicating the PDC has written the data to
memory is fired before the data actually is written to memory. If a
small delay is added after the interrupt (like a trace printk("The value
is\n")) the PDC have enough time to write the data to the memory and I
get correct values from the ADC connected to the SPI.
Thoughts how to solve this?
> 
> 
> David
> 
> P.S.: you're lucky to not get crap values - seems they got the chip
> design right...
> 
/Niclas
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev

Re: Getting alot of zero values from ads7846 using atmel_spi

[Kenneth Heitke]

On 04/18/2011 03:21 AM, Niclas Karlsson wrote:
> tor 2011-03-10 klockan 15:41 +0100 skrev David Lamparter:
>> On Tue, Mar 08, 2011 at 10:44:56AM +0100, Niclas Karlsson wrote:
>>> Do anyone know why I read so many zeroes?
>>
>> You're probably reading values faster than the chip supports. Check the
>> chip documentation for a maximum readout frequency or a ready flag.
>>> I have made some printk in ads7846.c to trace the problem. It seemed to
>>> read more correct values when I added the printks.
>>
>> A printk takes quite some time on an ARM like yours. The throttle makes
>> it work...
>
> I've made som further investigations. The atmel_spi.c driver utilize PDC
> (Peripheral DMA Controller) and when I was tracing the problem I
> discovered that the interrupt indicating the PDC has written the data to
> memory is fired before the data actually is written to memory. If a
> small delay is added after the interrupt (like a trace printk("The value
> is\n")) the PDC have enough time to write the data to the memory and I
> get correct values from the ADC connected to the SPI.
> Thoughts how to solve this?

Is it really the interrupt firing early or is it possible that you are 
still reading cached data.  I'm not familiar with the device or driver 
so I'm just throwing that out as a possibility.

>>
>>
>> David
>>
>> P.S.: you're lucky to not get crap values - seems they got the chip
>> design right...
>>
> /Niclas
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> spi-devel-general mailing list
> spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
>


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev

Re: Getting alot of zero values from ads7846 using atmel_spi

[Niclas Karlsson]

tis 2011-04-19 klockan 14:40 -0600 skrev Kenneth Heitke:
> On 04/18/2011 03:21 AM, Niclas Karlsson wrote:
> > tor 2011-03-10 klockan 15:41 +0100 skrev David Lamparter:
> >> On Tue, Mar 08, 2011 at 10:44:56AM +0100, Niclas Karlsson wrote:
> >>> Do anyone know why I read so many zeroes?
> >>
> >> You're probably reading values faster than the chip supports. Check the
> >> chip documentation for a maximum readout frequency or a ready flag.
> >>> I have made some printk in ads7846.c to trace the problem. It seemed to
> >>> read more correct values when I added the printks.
> >>
> >> A printk takes quite some time on an ARM like yours. The throttle makes
> >> it work...
> >
> > I've made som further investigations. The atmel_spi.c driver utilize PDC
> > (Peripheral DMA Controller) and when I was tracing the problem I
> > discovered that the interrupt indicating the PDC has written the data to
> > memory is fired before the data actually is written to memory. If a
> > small delay is added after the interrupt (like a trace printk("The value
> > is\n")) the PDC have enough time to write the data to the memory and I
> > get correct values from the ADC connected to the SPI.
> > Thoughts how to solve this?
> 
> Is it really the interrupt firing early or is it possible that you are 
> still reading cached data.  I'm not familiar with the device or driver 
> so I'm just throwing that out as a possibility.
I have thought about it but I don't know how to test it. I disabled the
 whole d-cache in the kernel configuration, but everything ran so slow
that I don't know if it was the disabled of d-cache or if the timing
became so much different.
If I want to bring the d-cache up to sync, how do I do that?
Is it possible to allocate memory which never will be stored in d-cache?
/Niclas
> >>
> >>
> >> David
> >>
> >> P.S.: you're lucky to not get crap values - seems they got the chip
> >> design right...
> >>
> > /Niclas
> > ------------------------------------------------------------------------------
> > Benefiting from Server Virtualization: Beyond Initial Workload
> > Consolidation -- Increasing the use of server virtualization is a top
> > priority.Virtualization can reduce costs, simplify management, and improve
> > application availability and disaster protection. Learn more about boosting
> > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> > _______________________________________________
> > spi-devel-general mailing list
> > spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/spi-devel-general
> >
> 
> 


------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev

Re: Getting alot of zero values from ads7846 using atmel_spi

[Kenneth Heitke]

On 04/20/2011 08:34 AM, Niclas Karlsson wrote:
> tis 2011-04-19 klockan 14:40 -0600 skrev Kenneth Heitke:
>> On 04/18/2011 03:21 AM, Niclas Karlsson wrote:
>>> tor 2011-03-10 klockan 15:41 +0100 skrev David Lamparter:
>>>> On Tue, Mar 08, 2011 at 10:44:56AM +0100, Niclas Karlsson wrote:
>>>>> Do anyone know why I read so many zeroes?
>>>>
>>>> You're probably reading values faster than the chip supports. Check the
>>>> chip documentation for a maximum readout frequency or a ready flag.
>>>>> I have made some printk in ads7846.c to trace the problem. It seemed to
>>>>> read more correct values when I added the printks.
>>>>
>>>> A printk takes quite some time on an ARM like yours. The throttle makes
>>>> it work...
>>>
>>> I've made som further investigations. The atmel_spi.c driver utilize PDC
>>> (Peripheral DMA Controller) and when I was tracing the problem I
>>> discovered that the interrupt indicating the PDC has written the data to
>>> memory is fired before the data actually is written to memory. If a
>>> small delay is added after the interrupt (like a trace printk("The value
>>> is\n")) the PDC have enough time to write the data to the memory and I
>>> get correct values from the ADC connected to the SPI.
>>> Thoughts how to solve this?
>>
>> Is it really the interrupt firing early or is it possible that you are
>> still reading cached data.  I'm not familiar with the device or driver
>> so I'm just throwing that out as a possibility.
> I have thought about it but I don't know how to test it. I disabled the
>   whole d-cache in the kernel configuration, but everything ran so slow
> that I don't know if it was the disabled of d-cache or if the timing
> became so much different.
> If I want to bring the d-cache up to sync, how do I do that?
> Is it possible to allocate memory which never will be stored in d-cache?
> /Niclas


You might want to take a look at dma_alloc_coherent()

>>>>
>>>>
>>>> David
>>>>
>>>> P.S.: you're lucky to not get crap values - seems they got the chip
>>>> design right...
>>>>
>>> /Niclas
>>> ------------------------------------------------------------------------------
>>> Benefiting from Server Virtualization: Beyond Initial Workload
>>> Consolidation -- Increasing the use of server virtualization is a top
>>> priority.Virtualization can reduce costs, simplify management, and improve
>>> application availability and disaster protection. Learn more about boosting
>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>>> _______________________________________________
>>> spi-devel-general mailing list
>>> spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
>>>
>>
>>
>
>


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev