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

matt_hsu matt_hsu at openmoko.org
Thu Nov 13 17:02:42 CET 2008


Werner Almesberger wrote:
> 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 ?
>   
Nice, actually, I think my patches seem to be a re-work solution.
Although I found the root cause of this issue. But I'm not sure these 
patches are perfect solution.
That's why I have the term *RFC*.

But your description explains the part I'm not sure. :)

Matt
> 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