[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