On 17/01/2017 16:57, Peter Rosin wrote:
On 2017-01-17 09:00, Phil Reid wrote:
Unfortunately some hardware device will assert their irq line immediately
on power on and provide no mechanism to mask the irq. As the i2c muxes
provide no method to mask irq line this provides a work around by keeping
the parent irq masked until enough device drivers have loaded to service
all pending interrupts.
For example the the ltc1760 assert its SMBALERT irq immediately on power
on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
device is registered irq are enabled and fire continuously as the second
device driver has not yet loaded. Setting this parameter to <1 1> will
delay the irq being enabled until both devices are ready.
G'day Peter,
Hang on, does this suggestion I made make any sense at all? Maybe it does,
but does the pca954x driver even get notified of any but the first irq client
that unmasks interrupts on a mux segment? How can it count the number of
active irq clients if not?
Good question.
So what I did to test is setup my 2 ltc1760s to use the same irq on the pca954x.
Using the latest patch series.
Adding a log message into the irq_unmask function got the following.
dev_err(&data->client->dev, "irq_unmask %d %x %d", pos, data->irq_mask, data->irq_enabled);
dmesg | grep irq_unmask
[ 4.392098] pca954x 4-0070: irq_unmask 0 1 1
But Looks like both got registered ok to the same irq.
cat /proc/interrupts
161: 0 0 i2c-mux-pca954x 0 Level 15-000a, 16-000a
So from this testing, it doesn't look like it gets called multiple times.
So back to the bitmask for the dt do you think.
I think the interrupt enablelogic is correct now.
I'm truly sorry for the trouble I'm causing by not just saying how it should
be done from the start, but I feel like I've been thrown in at the deep end
when it comes to interrupt controllers...
No problem. I'm learning a couple things as we go.
Should help me out on other drivers :)
--
Regards
Phil Reid
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
