[PATCH 0/3] RFC: fix bug http://docs.openmoko.org/trac/ticket/1884

Werner Almesberger werner at openmoko.org
Thu Nov 13 16:30:19 CET 2008


matt_hsu wrote:
> These patches are trying to fix the issue of

Congratulations on getting this to work !

One question, though: how do you explain that just handling the
interrupt wasn't enough to prevent the interrupt storm ? I.e.,
suppose there is the pending interrupt from the PMU, it should
just go through the general interrupt handling code and get acked
[1] and temporarily masked, and then to pcf50633_irq, which
disables it [1] until properly handled.

[1] This one is a little complicated:

    kernel/irq/chip.c:handle_level_irq
      kernel/irq/chip.c:mask_ack_irq (EINT9)
	chip->mask() = arch/arm/plat-s3c24xx/irq.c:s3c_irqext_chip.mask
	  = arch/arm/plat-s3c24xx/irq.c:s3c_irqext_mask
	    [ clears S3C24XX_EINTMASK ]
	chip->ack() = arch/arm/plat-s3c24xx/irq.c:s3c_irqext_chip.ack
	  = arch/arm/plat-s3c24xx/irq.c:s3c_irqext_ack
	      [ clears S3C24XX_EINTPEND ]
	    arch/arm/plat-s3c24xx/irq.c:s3c_irq_ack
	      [ clears S3C2410_SRCPND and S3C2410_INTPND ]
       ...
       handle_IRQ_event
       ...

[2] By setting IRQ_DISABLED, ...

    kernel/irq/manage.c:disable_irq
        kernel/irq/manage.c:disable_irq_nosync
	  chip->disable() = kernel/irq/chip.c:default_disable

    ... so the next interrupt will go through mask_ack_irq.

Now, looking at arch/arm/plat-s3c24xx/irq.c:s3c24xx_init_irq, I see
that IRQ_EINT4 through IRQ_EINT23 are set to handle_edge_irq, not
handle_level_irq. I wonder if this could explain the problem ?

I also don't see anything in the 

kernel/irq/manage.c:request_irq
  kernel/irq/manage.c:__setup_irq
    kernel/irq/manage.c:__irq_set_trigger
      chip->set_type() = arch/arm/plat-s3c24xx/irq.c:s3c_irqext_chip.set_type
        = arch/arm/plat-s3c24xx/irq.c:s3c_irqext_type

path call set_irq_handler, so I think what you're getting is indeed
the edge handler, which doesn't seem right.

To check, I applied your patch that changes the PMU to level interrupts,
and sure enough, I got:

con:~# poke 0x5600008c
0x00020000

but the descriptor still says it's edge:

(gdb) p irq_desc[53]
$3 = {irq = 0, handle_irq = 0xc007e868 <handle_edge_irq>, chip = 0xc044b588, 
  msi_desc = 0x0, handler_data = 0x0, chip_data = 0x0, action = 0xc79c0d00, 
  status = 1179656, depth = 0, wake_depth = 1, irq_count = 5, 
  irqs_unhandled = 0, last_unhandled = 0, lock = {raw_lock = {slock = 1}, 
    magic = 3735899821, owner_cpu = 4294967295, owner = 0xffffffff, dep_map = {
      key = 0xc04542b8, class_cache = 0xc04eb4d4, 
      name = 0xc03e66b4 "irq_desc->lock", cpu = 0}}, dir = 0xc783c140, 
  name = 0x0}

Just to check that I got the interrupt number right:

(gdb) p *irq_desc[53].action
$5 = {handler = 0xc0255334 <pcf50633_irq>, flags = 40, mask = {bits = {0}}, 
  name = 0xc03dcc40 "pcf50633", dev_id = 0xc79c7800, next = 0x0, irq = 53, 
  dir = 0xc79c1460}

Ben, should s3c_irqext_type and friends call set_irq_handler ?

- Werner



More information about the openmoko-kernel mailing list