Re: [PATCH v3 3/4] hwmon: (lm90) add support to handle IRQ

[Jean Delvare <khali@linux-fr.org>]

Hi Wei,

Sorry for the late reply, catching up with the discussions from before
my vacation...

On Tue, 30 Jul 2013 16:18:35 +0800, Wei Ni wrote:
> On 07/29/2013 11:58 PM, Jean Delvare wrote:
> > On Mon, 29 Jul 2013 18:14:56 +0800, Wei Ni wrote:
> >> Yes, we had met this problems, to fix this issue, we enabled one-shot
> >> mode in the bottom half handler of nct interrupts to force a
> >> conversion/comparison. This effectively stops repeated nct interrupts.
> >> We will do following things in the IRQ thread:
> >> 1. stand by the nct1008. (set configure register bit 6)
> >> 2. update the limit value if needed.
> >> 3. write to one-shot resister.
> >> 4. give hardware necessary time to finish conversion
> >> 5. run the nct1008 (clear configure register bit 6)
> > 
> > Doh, this is so ugly :(
> > 
> > Why don't you configure the pin as THERM2 instead of ALERT then? I'd
> > expect this to make things easier.
> 
> If configure as THERM2, only the high temperature limits are relevant,
> so when the temperature reduced, it will not trigger interrupt, and we
> can't update the cooling state.

Ah, indeed, I had not noticed this restriction.

> Or do you mean that we can configure the pin to THERM2 in the irq_thread
> to avoid the repeated interrupt ? I tried it, but no help, the nct1008
> will not run the conversion/comparison immediately, so the status
> register will not be cleared.

No, I didn't mean to suggest anything like that.

> >> (...)
> >> These trip-temps are not critical temperature, we used these temps to
> >> update cooling states. For the critical-temp, we handle it like my
> >> mentioned in #1.
> > 
> > I understand. But even if these interrupts are only used for managing
> > cooling states, a misbehavior could still have annoying consequences,
> > such as causing the thermal shutdown to trigger when this could have
> > been avoided, or throttling to stay enabled even though the system has
> > cooled down enough.
> 
> I think our driver are trying best to avoid these troubles. As I know in
> our downstream codes, we didn't met these things.
> I think since the lm90 support interrupt mode, then the driver should
> have related interface to handle it, and it can call the callback
> function to do what the platform driver want.

Yes, fair enough. I do not object to it, I was only trying to
understand how you were using it.

-- 
Jean Delvare