Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1664359 > unrolled thread

Re: [PATCH V1 05/15] spmi: pmic-arb: cleanup unrequested irqs

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V1 05/15] spmi: pmic-arb: cleanup unrequested irqs Stephen Boyd <sboyd@codeaurora.org> - 2017-06-13 04:20 +0200
    Re: [PATCH V1 05/15] spmi: pmic-arb: cleanup unrequested irqs kgunda@codeaurora.org - 2017-06-14 17:10 +0200

#1664359 — Re: [PATCH V1 05/15] spmi: pmic-arb: cleanup unrequested irqs

On 06/06, kgunda@codeaurora.org wrote:
> On 2017-05-31 07:27, Stephen Boyd wrote:
> >On 05/30, Kiran Gunda wrote:
> >>From: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
> >>
> >>We see a unmapped irqs trigger right around bootup. This could
> >>likely be because the bootloader exited leaving the interrupts
> >>in an unknown or unhandled state.  Ack and mask the interrupt
> >>if one is found. A request_irq later will unmask it and also
> >>setup proper mapping structures.
> >
> >Do we have systems where this is causing an interrupt storm due
> >to a level high interrupt or something? Just plain acking and
> >masking irqs at boot if we don't have an irq descriptor created
> >yet doesn't sound like a good idea, because we'll lose all
> >interrupts that happen before this driver probes?
> >
> Yes. There were instances of an interrupt storm without this patch.
> There is an RT_STATUS register in the  peripheral address space which
> maintains the real time state and can be read by the client driver
> before it registers for the irq. Few client drivers such as charger
> already doing this.

So you're saying that drivers need to read RT_STATUS to know if
they have a pending interrupt before requesting it? That sounds
bogus.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [next] | [standalone]

#1665917

On 2017-06-13 07:41, Stephen Boyd wrote:
> On 06/06, kgunda@codeaurora.org wrote:
>> On 2017-05-31 07:27, Stephen Boyd wrote:
>> >On 05/30, Kiran Gunda wrote:
>> >>From: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
>> >>
>> >>We see a unmapped irqs trigger right around bootup. This could
>> >>likely be because the bootloader exited leaving the interrupts
>> >>in an unknown or unhandled state.  Ack and mask the interrupt
>> >>if one is found. A request_irq later will unmask it and also
>> >>setup proper mapping structures.
>> >
>> >Do we have systems where this is causing an interrupt storm due
>> >to a level high interrupt or something? Just plain acking and
>> >masking irqs at boot if we don't have an irq descriptor created
>> >yet doesn't sound like a good idea, because we'll lose all
>> >interrupts that happen before this driver probes?
>> >
>> Yes. There were instances of an interrupt storm without this patch.
>> There is an RT_STATUS register in the  peripheral address space which
>> maintains the real time state and can be read by the client driver
>> before it registers for the irq. Few client drivers such as charger
>> already doing this.
> 
> So you're saying that drivers need to read RT_STATUS to know if
> they have a pending interrupt before requesting it? That sounds
> bogus.
In  many cases a PMIC module driver does need to know the initial state 
of
the hardware during driver initialization and the RT_STATUS register 
indicates
this (irrespective of the IRQ_EN status).  The  reset value of IRQ_EN = 
0 and if
an event occurs before we request an IRQ, there is no way to know the 
initial state
even after we request this irq as there will be no pending interrupt 
because the
HW default value of IRQ_EN = 0. This can be known only through reading 
the RT_STATUS.

I understand your concern of clearing the IRQ before we request it does 
not seem
a clean way, do you have any other recommendation of this could be 
handled ?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web