Stephen Lyall | 1 Dec 18:28 2004
Picon

delayed interrupt on ep7312

Hi,
I'm running 2.4.26 on an ep7312 on a custom board.  I have a problem with a delay in calling the interrupt
service routine associated with the external interrupts (EINT1 and EINT2).  I am finding that after the
interrupt has gone off there is a significant wait before the ISR is called.  This wait is between 1/100 and
1/20 second.

By putting a series of interrupts in a loop and taking timings, I can see the operation of the interrupt is
synchronised in multiples of 1/100 second.  The first time through the loop is not a multiple of 1/100, but
all subsequent are.  As the system interval timer goes off every 1/100 second, I'm guessing the actual
calling of the ISR is synchronised with this.

Any help in explain what's going on would be greatly appreciated

Stephen Lyall

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

Richard Purdie | 1 Dec 01:21 2004
Picon

Re: RFC on Corgi Machine patches

Russell King:
> Looking solely at this patch, I question whether it's really necessary
> for there to even be three different MACH_* symbols, especially as they
> are mutually exclusive.  I'd also question whether they should even be
> mutually exclusive.  Surely it'd be better to build just one "Corgi"
> kernel which worked on all PXA2xx Corgi variants.

I agree and I'd like to see one kernel working on all Corgi variants. This 
isn't straight forward though.

There are effectively three hardware variants. The differences are the 
amounts of RAM, the amounts of flash and some of the of GPIO interrupts 
change around a bit (also, one uses the PXA250, the rest, the PXA255). There 
may be other differences I'm not aware of yet as I haven't gone through all 
the code but I think these are the main ones.

The bootloader can't be easily changed and doesn't give up any machine type 
which presents a problem and means at least some code will have to be added 
to head-xscale.S.

If I go with one machine type I will need to add some zaurus_is_xxx() 
functions. Even then, I'm not sure I can run code early enough to be able to 
set the memory size correctly in this case? If I use three machine types, I 
can use the machine_is_xxx functions instead and the memory problem can be 
solved by having three machine definitions.

I can tell the difference between the models and set r7 correctly, but I 
need 40ish lines of assembler to do so (see the end of 
http://www.rpsys.net/openzaurus/head-xscale.S ).

(Continue reading)

Paul Wilcox-Baker | 1 Dec 01:46 2004

Re: RFC on Corgi Machine patches

On Wed, 1 Dec 2004, Richard Purdie wrote:

> There are effectively three hardware variants. The differences are the
> amounts of RAM, the amounts of flash and some of the of GPIO interrupts
> change around a bit (also, one uses the PXA250, the rest, the PXA255). There
> may be other differences I'm not aware of yet as I haven't gone through all
> the code but I think these are the main ones.

> The bootloader can't be easily changed and doesn't give up any machine type
> which presents a problem and means at least some code will have to be added
> to head-xscale.S.
>
> If I go with one machine type I will need to add some zaurus_is_xxx()
> functions. Even then, I'm not sure I can run code early enough to be able to
> set the memory size correctly in this case? If I use three machine types, I
> can use the machine_is_xxx functions instead and the memory problem can be
> solved by having three machine definitions.

> I can tell the difference between the models and set r7 correctly, but I
> need 40ish lines of assembler to do so (see the end of
> http://www.rpsys.net/openzaurus/head-xscale.S ).

> Personally, I'd prefer the three machine types in one kernel and the code in
> head-xscale. I'm not sure if this solution will be acceptable however? If
> anyone can see a way forward I haven't please tell me!

> I'm open to advice and suggestions...

If you can probe memory to determine the the three different RAM
sizes your problems would seem to be solved.  In most machines
(Continue reading)

Todd Poynor | 1 Dec 03:25 2004

Re: HowTo XIP on arm?

On Mon, Nov 22, 2004 at 10:23:05PM +0100, Wolfgang Denk wrote:
> U-Boot expects (and verifies) that the entry point is  equal  to  the
> load address plus the size of the U-Boot header.

If I've followed this correctly then U-Boot currently does not boot a
ARM XIP Linux kernel built using Nicolas' code in kernel.org.  If so,
I've heard that U-Boot patches are floating about to setup the ARM Linux
calling sequence for arbitrary images without a U-Boot header and perhaps
that's a good way to handle it.

Another option is to add a kernel make target that creates a uImage with
the needed entry-load==64.  Doing the math automatically would be nice
but I haven't so far found a pretty way of producing the needed result
(and doubt the portability of each method I've tried).  One try appears
below, comments appreciated.  If we assume the U-Boot header will always
be on a page boundary and the entry point will be +0x40 from that then
even a simple text substitution via sed will get the job done...

Thanks -- Todd

diff -ruN linux-2.6.10-rc2-orig/arch/arm/boot/Makefile linux-2.6.10-rc2-xip/arch/arm/boot/Makefile
--- linux-2.6.10-rc2-orig/arch/arm/boot/Makefile	2004-11-17 14:02:00.000000000 -0800
+++ linux-2.6.10-rc2-xip/arch/arm/boot/Makefile	2004-11-30 13:36:05.666740952 -0800
 <at>  <at>  -24,7 +24,7  <at>  <at> 

 export ZRELADDR INITRD_PHYS PARAMS_PHYS

-targets := Image zImage xipImage bootpImage uImage
+targets := Image zImage xipImage bootpImage uImage xipuImage

(Continue reading)

Nicolas Pitre | 1 Dec 04:09 2004

Re: RFC on Corgi Machine patches

On Wed, 1 Dec 2004, Richard Purdie wrote:

> If I go with one machine type I will need to add some zaurus_is_xxx()
> functions. Even then, I'm not sure I can run code early enough to be able to
> set the memory size correctly in this case?

You could have a .fixup entry in your machine desc structure which is a 
hook for a function called before the full memory map is set up.  You 
could use that to autodetect your particular device and provide a 
suitable memory default.  See for example fixup_assabet() in 
arch/arm/mach-sa1100/assabet.c.

> If I use three machine types, I
> can use the machine_is_xxx functions instead and the memory problem can be
> solved by having three machine definitions.
> 
> I can tell the difference between the models and set r7 correctly, but I need
> 40ish lines of assembler to do so (see the end of
> http://www.rpsys.net/openzaurus/head-xscale.S ).
> 
> Personally, I'd prefer the three machine types in one kernel and the code in
> head-xscale. I'm not sure if this solution will be acceptable however? If
> anyone can see a way forward I haven't please tell me!

If you go with the head-xscale.S route, please at least make it a 
separate file from head-xscale.S.  Keep the .section ".start","ax" at 
the top and ensure it is added to OBJS in the Makefile after 
head-xscale.o.  Given the number of lines you need it certainly warrants 
a separate file.

(Continue reading)

Nicolas Pitre | 1 Dec 04:42 2004

Re: HowTo XIP on arm?

On Tue, 30 Nov 2004, Todd Poynor wrote:

> On Mon, Nov 22, 2004 at 10:23:05PM +0100, Wolfgang Denk wrote:
> > U-Boot expects (and verifies) that the entry point is  equal  to  the
> > load address plus the size of the U-Boot header.
> 
> If I've followed this correctly then U-Boot currently does not boot a
> ARM XIP Linux kernel built using Nicolas' code in kernel.org.  If so,
> I've heard that U-Boot patches are floating about to setup the ARM Linux
> calling sequence for arbitrary images without a U-Boot header and perhaps
> that's a good way to handle it.

That would be nice indeed.

> Another option is to add a kernel make target that creates a uImage with
> the needed entry-load==64.  Doing the math automatically would be nice
> but I haven't so far found a pretty way of producing the needed result
> (and doubt the portability of each method I've tried).  One try appears
> below, comments appreciated.

You have:

XIPUIMAGE_LOAD_ADDR = "$(shell let x=$(CONFIG_XIP_PHYS_ADDR)-64; echo "obase=16;$$x" | bc)"

Instead of relying on bc, you probably should use awk since the generic 
XIP address processing already uses it so it makes for one less 
dependency on external tools:

XIPUIMAGE_LOAD_ADDR := $(shell echo $(CONFIG_XIP_PHYS_ADDR) | \
                               awk --non-decimal-data '/[:xdigit:]/ \
(Continue reading)

Manav Gautam | 1 Dec 05:19 2004
Picon

Re: touchscreens

tslib attaches itself to the Xfbdev and provides user space
calibration using loadable stackable modules like variation, dejitter
and linear . You dont really require gpm running for touchscreens.

On Tue, 30 Nov 2004 17:21:47 -0600, Chris Larson <kergoth <at> handhelds.org> wrote:
> * David Meggy (dmeggy <at> techsol.ca) wrote:
> > I was just using gpm as a test program, I don't actually need gpm.
> > Taking a look at tslib, what programs use tslib?  Any toolkits?  QT in
> > particular.  I didn't find very many references.
> 
> Kdrive can use it.  Qt/embedded can use it with a patch.  For testing,
> use tslib's test apps (ts_print_raw, ts_print, ts_test, ts_calibrate).
> --
> Chris Larson - kergoth at handhelds dot org
> Linux Software Systems Engineer - clarson at ti dot com
> OpenZaurus Project Maintainer - http://openzaurus.org/
> 
> 
> 
> -------------------------------------------------------------------
> Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
> Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
>

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

(Continue reading)

Russell King - ARM Linux | 1 Dec 08:00 2004
Picon

Mailing List FAQ

This message is sent to this mailing list once a week.

This can also be found (with html links) at:
   http://www.arm.linux.org.uk/armlinux/mlfaq.php

   Lists
    1. How do I compile a kernel for ARM?
    2. Can I use Intel IXP425 AccessLibrary with 2.6 kernels?
    3. What are the available solutions for floating point support?
    4. Can  I  use  the  both  hard & soft float at the same time or only
       choose one of them?
    5. When  I compile my 2.6.x kernel for ARM I get a compiler/assembler
       error. Any idea ?
    6. When  I trace kernel in head.S I found problems that may be caused
       by __turn_mmu_on. Any idea ?
    7. I'm  working  on  a  bootloader, where can I find ARM Linux kernel
       booting requirements ?
    8. How can I access /dev/mem ? - How can I map memory in user space ?
    9. I  see  '$a',  '$d'  and  '$t'  symbols  in the backtrace/ksymoops
       output/System.map/linker error messages. What are they and how can
       I get rid of them ?

   1. How do I compile a kernel for ARM?
          [rmk]
          Please see the kernel compilation instructions.

   2. I am trying to run a Linux kernel 2.6 on my Intel IXP42x. I am
          using the kernel 2.6.x. This kernel does not include support
          for the integrated ethernet controllers of the IXP425. I have
          downloaded the AccessLibrary 1.x from Intel, but i have seen it
(Continue reading)

Russell King - ARM Linux | 1 Dec 08:00 2004
Picon

Mailing List Etiquette

This message is sent to this mailing list once a week.

This can also be found (with html links) at:
   http://www.arm.linux.org.uk/armlinux/mletiquette.php

   Lists
   In  order  for  the  linux-arm  lists  to  provide  a high quality and
   effective  forum  for  finding  answers  to  problems,  the  following
   etiquette  is  highly  recommended.  Here  is a list of the ettiquette
   points:
    1. Subscription requirements.
    2. Sending a new message to the list.
    3. Replying to a message from the list.
    4. Sending a message to multiple linux-arm* lists.
    5. HTML encoded messages.
    6. Email attachments.
    7. Commercial email.
    8. Searching the archives.
    9. Support for commercial products.
   10. Cross-posting between linux-arm* lists and other lists.
   11. Automatic replies.
   12. Virus scanners and email sanitisers.

   1. Subscription requirements. [rmk]
          Recently,  we  have  had to impose a restriction on the mailing
          lists.  You  must be subscribed to the mailing list in order to
          post  messages  to that mailing list. This is because of the UK
          Data  Protection  laws.  Only  subscribe  to these lists if you
          accept  the  legal  notice  displayed on the relevant pages; by
          subscribing,  you  accept  the  terms  layed  out  in the legal
(Continue reading)

Stephen Lyall | 1 Dec 11:04 2004
Picon

Re: delayed interrupt on ep7312

On 30/11/2004 12:29 Mike wrote

>> By putting a series of interrupts in a loop and taking timings, I
>> can see the operation of the interrupt is synchronised in
>> multiples of 1/100 second. The first time through the loop is
>> not a multiple of 1/100, but all subsequent are. As the system
>> interval timer goes off every 1/100 second, I'm guessing the
>> actual calling of the ISR is synchronised with this.

>Please forgive me, I don't quite understand how you're doing this
>test. What if you trigger a GPIO in the interrupt routine, and
>measure (with an oscilloscope or similar) the response time of the
>GPIO transition from the Interrupt transition?

>I would assume that the interrupt would do its thing as soon as it
>was triggered, if they were enabled. Or, could your test code be
>someplace that is called _indirectly_ from the ISR?

I'm probably not being very clear.   I am writing a driver for the ep7312 to communicate with a PIC. I have
included the code for the interrupt routine, and for the write operation.  I hope this makes things a bit
clearer.  The interrupt on the ARM is level-triggered, not edge-triggered.  When not writing to the PIC, the
PIC is asserting the interrupt.  After writing a byte, the PIC unasserts the interrupt for about 1/500
second while it is busy and cannot read another byte, then asserts the interrupt again.

In the code below there are 2 calls to do_gettimeofday, one in the ISR, and the other in the write operation. 
The call in the write operation happens just before it puts itself on the wait queue, and in the ISR as soon as
it is called.  The delay between these 2 is between 1/100 second and 1/5 second - far greater than I would
expect.  I know the interrupt is going off faster than this.  Also I have included a tight loop that waits
until the interrupt is asserted before the write operation sleeps on the wait queue.  As I see it, this means
the interrupt has already been asserted when the write operation sleeps, and so the ISR should be called
(Continue reading)


Gmane