On 29/01/2018 21:38, Raphael Lisicki wrote:
Hallo Phil, thank you for your answer.
On 29.01.2018 02:21, Phil Reid wrote:
I've ran into this problem before myself. As far as I could determine there was no way to delay the enabling of the irq.
Did you solve the issue at that time? If so, how?
In a ound about way.
My hardware had the irqs connected to a pca9543 i2c mux that ANDs the irq together.
The device can tell you which irq is active but can not mask them.
The irq source was an SMBus alert on each i2c segment. So I modified the i2c core to register smb alert handlers.
And had the mux driver delay registering its irq until all bus segments had been created.
Had some other hardware using the pca gpio with irq tied together. Fortunately hardware was only at 1st prototype.
So I changed the hardware once I'd found this problem :) USed mcp23 series gpio's instead.
There's probably enough information in the dt to determine this by searching for all the devices using that irq.
An approach would be to create an intermediary irq chip device. (Something that models an AND /OR gate for example)
The driver for which could be setup to delay registering the irq until all irq sources have registered.
This would keep the code separate for the core irq library I think...
This proxy sounds like an interesting idea. I will try to see what can be done in this regard.
Something like this would solve a number of problems.
The was a previous discussion in regards one of my patches (around nov last year) for the mcp23s08 driver irq to
create something to model an inverter on the irq line.
Something configurable with X lines and possibility to invert inputs would be generic.
Just haven't got to it as yet.
--
Regards
Phil Reid
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
