Re: problems with spi interface & ads 784X under 2.6.23

Re: problems with spi interface & ads 784X under 2.6.23

[Andrew Morton]

On Sun, 11 Nov 2007 08:02:19 +0800 "dave chung" <ponstrip-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> on kernel 2.6.23 , with an  Arm AT91rm9200
> sometimes when i  "pen-down" on the touch screen,I'm seeing
> 
> ads7846 spi0.0: touchscreen, irq 75
> input: ADS784x Touchscreen as /devices/platform/atmel_spi.0/spi0.0/input/input0
> at91_rtc at91_rtc: rtc core: registered at91_rtc as rtc0
> 
> 
> 
> atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
> atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
> DEactivate 35, mr 000f0011
> atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
> atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
> DEactivate 35, mr 000f0011
> 
> 
> 
> it appears to be coming from /drivers/touchscreen/ads7846.c
> 
> also even stranger, a cat of  the TS when the pen is down produces:
> # cat /dev/ts |hexdump
> returns
> 0000000 ea9c 34aa 0d64 0007 0001 014a 0001 0000
> 0000010 ea9c 34aa 0dde 0007 0003 0018 1d4c 0000
> 0000020 ea9c 34aa 0e1b 0007 0000 0000 0000 0000
> 0000030 ea9c 34aa 8c84 0008 0001 014a 0000 0000
> 0000040 ea9c 34aa 8cdf 0008 0003 0018 0000 0000
> 0000050 ea9c 34aa 8d1c 0008 0000 0000 0000 0000
> 0000060 ea9d 34aa c9af 0004 0001 014a 0001 0000
> 0000070 ea9d 34aa ca29 0004 0003 0018 1d4c 0000
> 0000080 ea9d 34aa ca66 0004 0000 0000 0000 0000
> 
> when the pen is down , notice that the left column is a sequence of
> incrementing words, at "second" intervals , the value of which change
> when i turn off the "RTC" compillation in the kernel, but this may be
> down to the interrupts.
> After consulting the curcuit diagrams , the only "odd" thing i can see
> is that the "penirq" is tied to pin  PB11, but it is obviously working
> as i only get output when the pen is down
> 
> under kernel 2.6.13 the touchscreen actually works fine.
> and a cat of it's output is more reasonable.
> 
> 000000 0001 0c39 07e0 be98 0001 0c33 0801 be98
> 0000010 0001 0c35 07e2 be98 0001 0c41 07d4 be98
> 0000020 0001 0c40 07d0 be98 0001 0c08 0859 be98
> 0000030 0001 0c4c 07d1 be98 0001 0c5a 070f be98
> 0000040 0001 0c3f 074a be98 0001 0bf3 07e5 be98
> 0000050 0001 0c40 07e4 be98 0001 0c40 07f5 be98
> 0000060 0001 0c63 07e3 be98 0001 0c3c 07d2 be98
> 0000070 0001 0c44 07ce be98 0001 0c3e 07d2 be98
> 0000080 0001 0c40 07cf be98 0001 0c56 071f be98
> 
> which does actually seem to be representative of reasonalbe screen positions
> 

I suppose spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org would be the place for
this.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: problems with spi interface & ads 784X under 2.6.23

[Haavard Skinnemoen]

Hmm. I can swear I've seen David respond to this before, but I can't
seem to find the thread. Anyway...

On Thu, 22 Nov 2007 23:34:27 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Sun, 11 Nov 2007 08:02:19 +0800 "dave chung" <ponstrip@gmail.com> wrote:
> 
> > on kernel 2.6.23 , with an  Arm AT91rm9200
> > sometimes when i  "pen-down" on the touch screen,I'm seeing
> > 
> > ads7846 spi0.0: touchscreen, irq 75
> > input: ADS784x Touchscreen as /devices/platform/atmel_spi.0/spi0.0/input/input0
> > at91_rtc at91_rtc: rtc core: registered at91_rtc as rtc0
> > 
> > 
> > 
> > atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
> > atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
> > DEactivate 35, mr 000f0011
> > atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
> > atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
> > DEactivate 35, mr 000f0011

It seems like the AT91RM9200 has a few serious quirks that later AT91
and AVR32 chips don't have. This is especially problematic for things
connected to CS0. If it's not too late to modify your board design I
suggest you try a different chipselect.

However, several people have reported that
atmel_spi-chain-dma-transfers.patch (currently in -mm) makes the driver
behave a lot better on AT91RM9200, even on CS0. So if you haven't tried
that yet, I suggest you do.

Make sure you apply the fix too, or it will crash if you define DEBUG:

http://sourceforge.net/mailarchive/forum.php?thread_name=200711210250.46883.david-b%40pacbell.net&forum_name=spi-devel-general

If everything else fails, try reducing the SCK frequency.

> > it appears to be coming from /drivers/touchscreen/ads7846.c
> > 
> > also even stranger, a cat of  the TS when the pen is down produces:
> > # cat /dev/ts |hexdump
> > returns
> > 0000000 ea9c 34aa 0d64 0007 0001 014a 0001 0000
> > 0000010 ea9c 34aa 0dde 0007 0003 0018 1d4c 0000
> > 0000020 ea9c 34aa 0e1b 0007 0000 0000 0000 0000
> > 0000030 ea9c 34aa 8c84 0008 0001 014a 0000 0000
> > 0000040 ea9c 34aa 8cdf 0008 0003 0018 0000 0000
> > 0000050 ea9c 34aa 8d1c 0008 0000 0000 0000 0000
> > 0000060 ea9d 34aa c9af 0004 0001 014a 0001 0000
> > 0000070 ea9d 34aa ca29 0004 0003 0018 1d4c 0000
> > 0000080 ea9d 34aa ca66 0004 0000 0000 0000 0000
> > 
> > when the pen is down , notice that the left column is a sequence of
> > incrementing words, at "second" intervals , the value of which change
> > when i turn off the "RTC" compillation in the kernel, but this may be
> > down to the interrupts.

The left column is the offset printed by hexdump, so I take it you're
talking about the one after that, right?

Is the RTC chip connected to the same SPI bus? Perhaps it's not paying
attention to its chip select signal, or the chip select is set up with
the wrong polarity?

Håvard

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: problems with atmel_spi interface & ads under 2.6.23

[David Brownell]

On Friday 23 November 2007, Haavard Skinnemoen wrote:
> Hmm. I can swear I've seen David respond to this before, but I can't
> seem to find the thread. Anyway...

Yes, the linux-arm-kernel thread by "steve birtles" seems to have been
mangled for some reason.  And this exact message seems to have been
on that thread too ... but with different attribution.

I'm getting bounces from mail.mondialelectronic.{eu,com} for L-A-K
messages which don't always appear to have beeen delivered to that
list... and other messages seem to have been completely dropped.
Either of those might cause trouble finding that thread.


> > > atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
> > > atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
> > > DEactivate 35, mr 000f0011
> > > atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
> > > atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
> > > DEactivate 35, mr 000f0011
> 
> It seems like the AT91RM9200 has a few serious quirks

... as commented in the atmel_spi.c driver, with nCS0 issues
being the main unresolved issue.


> that later AT91 
> and AVR32 chips don't have. This is especially problematic for things
> connected to CS0. If it's not too late to modify your board design I
> suggest you try a different chipselect.

That's a short term workaround.  The canonical problem is an
rm9200 chip booting off DataFlash on nCS0, and with its root
filesystem living there.  We know this can work since the
legacy driver worked.  We even know what the current driver
does differently ... mostly, it doesn't do DMA chaining.

It'd be useful to have someone test with something simpler
than the ads784x code ... like DataFlash, which doesn't
have variables like user interaction causing different data.
(And where non-experts can detect bogus data.)

That said, there's nothing wrong with avoiding nCS0 except
when it's unavoidable (e.g. for booting from DataFlash).
And this *does* seem to be a newish board design, by some
of the other reports...


> However, several people have reported that
> atmel_spi-chain-dma-transfers.patch (currently in -mm) makes the driver
> behave a lot better on AT91RM9200, even on CS0. So if you haven't tried
> that yet, I suggest you do.

The nCS0 setup in arch/arm/mach-at91/at91rm9200_devices.c also
needs to be changed ... the "use GPIOs" workaround for one big
erratum doesn't work for nCS0 because of a different erratum.

ISTR that in the L-A-K thread, applying the nCS0 workaround
plus the dma chaining patch seemed to give good results.  As in,
those timeouts stopped, and the touchscreen event data looked
at least marginally plausible.


> Make sure you apply the fix too, or it will crash if you define DEBUG:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=200711210250.46883.david-b%40pacbell.net&forum_name=spi-devel-general
> 
> If everything else fails, try reducing the SCK frequency.
> 
> > > it appears to be coming from /drivers/touchscreen/ads7846.c
> > > 
> > > also even stranger, a cat of  the TS when the pen is down produces:
> > > # cat /dev/ts |hexdump
> > > returns
> > > 0000000 ea9c 34aa 0d64 0007 0001 014a 0001 0000
> > > 0000010 ea9c 34aa 0dde 0007 0003 0018 1d4c 0000
> > > 0000020 ea9c 34aa 0e1b 0007 0000 0000 0000 0000
> > > 0000030 ea9c 34aa 8c84 0008 0001 014a 0000 0000
> > > 0000040 ea9c 34aa 8cdf 0008 0003 0018 0000 0000
> > > 0000050 ea9c 34aa 8d1c 0008 0000 0000 0000 0000
> > > 0000060 ea9d 34aa c9af 0004 0001 014a 0001 0000
> > > 0000070 ea9d 34aa ca29 0004 0003 0018 1d4c 0000
> > > 0000080 ea9d 34aa ca66 0004 0000 0000 0000 0000
> > > 
> > > when the pen is down , notice that the left column is a sequence of
> > > incrementing words, at "second" intervals , the value of which change
> > > when i turn off the "RTC" compillation in the kernel, but this may be
> > > down to the interrupts.
> 
> The left column is the offset printed by hexdump, so I take it you're
> talking about the one after that, right?
> 
> Is the RTC chip connected to the same SPI bus? Perhaps it's not paying
> attention to its chip select signal, or the chip select is set up with
> the wrong polarity?

I'd have assumed it was the on-chip RTC, myself...

Given some other recent oddball reports -- like userspace
alignment faults causing drivers to get bus errors -- I'm
thinking it likely that some folk have been bringing up
some defective (or maybe misconfigured memory timings?)
rm9200 boards over the past few weeks.

- Dave

> 
> Håvard
> 
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: problems with spi interface & ads 784X under 2.6.23

[dave chung]

On Nov 23, 2007 9:10 PM, Haavard Skinnemoen <hskinnemoen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org> wrote:
> Hmm. I can swear I've seen David respond to this before, but I can't
> seem to find the thread. Anyway...
>
> On Thu, 22 Nov 2007 23:34:27 -0800
> Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
> > On Sun, 11 Nov 2007 08:02:19 +0800 "dave chung" <ponstrip-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > on kernel 2.6.23 , with an  Arm AT91rm9200
> > > sometimes when i  "pen-down" on the touch screen,I'm seeing
> > >
> > > ads7846 spi0.0: touchscreen, irq 75
> > > input: ADS784x Touchscreen as /devices/platform/atmel_spi.0/spi0.0/input/input0
> > > at91_rtc at91_rtc: rtc core: registered at91_rtc as rtc0
> > >
> > >
> > >
> > > atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
> > > atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
> > > DEactivate 35, mr 000f0011
> > > atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
> > > atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
> > > DEactivate 35, mr 000f0011
>
> It seems like the AT91RM9200 has a few serious quirks that later AT91
> and AVR32 chips don't have. This is especially problematic for things
> connected to CS0. If it's not too late to modify your board design I
> suggest you try a different chipselect.
>
> However, several people have reported that
> atmel_spi-chain-dma-transfers.patch (currently in -mm) makes the driver
> behave a lot better on AT91RM9200, even on CS0. So if you haven't tried
> that yet, I suggest you do.
>
> Make sure you apply the fix too, or it will crash if you define DEBUG:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=200711210250.46883.david-b%40pacbell.net&forum_name=spi-devel-general
>
> If everything else fails, try reducing the SCK frequency.
>
> > > it appears to be coming from /drivers/touchscreen/ads7846.c
> > >
> > > also even stranger, a cat of  the TS when the pen is down produces:
> > > # cat /dev/ts |hexdump
> > > returns
> > > 0000000 ea9c 34aa 0d64 0007 0001 014a 0001 0000
> > > 0000010 ea9c 34aa 0dde 0007 0003 0018 1d4c 0000
> > > 0000020 ea9c 34aa 0e1b 0007 0000 0000 0000 0000
> > > 0000030 ea9c 34aa 8c84 0008 0001 014a 0000 0000
> > > 0000040 ea9c 34aa 8cdf 0008 0003 0018 0000 0000
> > > 0000050 ea9c 34aa 8d1c 0008 0000 0000 0000 0000
> > > 0000060 ea9d 34aa c9af 0004 0001 014a 0001 0000
> > > 0000070 ea9d 34aa ca29 0004 0003 0018 1d4c 0000
> > > 0000080 ea9d 34aa ca66 0004 0000 0000 0000 0000
> > >
> > > when the pen is down , notice that the left column is a sequence of
> > > incrementing words, at "second" intervals , the value of which change
> > > when i turn off the "RTC" compillation in the kernel, but this may be
> > > down to the interrupts.
>
> The left column is the offset printed by hexdump, so I take it you're
> talking about the one after that, right?
>
> Is the RTC chip connected to the same SPI bus? Perhaps it's not paying
> attention to its chip select signal, or the chip select is set up with
> the wrong polarity?
>
> Håvard
>

Hi  Havard,

sorry not the absolute left col , but the actual hex dump data.
the RTC is actually built into the AT91RM9200 so it's not sitting on
the SPI bus ,that's why it's odd.

I'm beginning to suspect something with the interrupts , but i cannot
understand why reading the spi registers should be affected by the
internal RTC or indeed anything
I' using kernel 2.6.23  which means I just need to setup the spi
select line and the pin interrupt which i can do in "board-*"
as the driver is already written for ADS 7843/6 the polarity should be
correct, and that would be "active" low.
I.E the select should go from High "1" to low"0" to  select the chip.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/