Hi Linus,
Am 27.03.2018 um 15:02 schrieb Linus Walleij linus.walleij@linaro.org:
On Sat, Mar 10, 2018 at 12:00 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
The Pyra-Handheld originally used the tca6424 but recently we have replaced it by the pin and package compatible pcal6524. So let's add this to the bindings and the driver.
And while we are at it, the pcal9555a does not have a compatible entry either but is already supported by the device id table.
Signed-off-by: H. Nikolaus Schaller hns@goldelico.com
Patch applied with Rob's review tag.
Thanks!
If there are any further concerns from the discussion with Andy, please follow up with additional patches if need be, thanks!
Yes, there will be something.
But before submitting, I want to try to get interrupt handling tested.
First of all I have found the board which I can use for testing. It has a ts3a227 as interrupt source connected to input 14 of the pcal6524 (instead of tca6424) which has the interrupt output connected to the gpio6_161 of an OMAP5.
To see what happens I have added some printk to
drivers/gpio/gpio-pca953x.c kernel/irq/manage.c sound/soc/codecs/ts3a227e.c
The result is a little puzzling. I see both drivers call request_threaded_irq() with flags = IRQF_ONESHOT | IRQF_SHARED and | IRQF_TRIGGER_LOW for the pcal. It seems as if the flags from DT are ignored here.
Then strange things happen. The ts3a227e.c handler is called permanently. Even before interrupts are enabled in the chip, although I don't see any pca953x interrupt to occur. And so far I could neither see pca953x_irq_mask() pca953x_irq_unmask() nor pca953x_irq_bus_sync_unlock() pca953x_irq_bus_sync_lock() being called.
So I'd suspect that something is wrong with setting up the chained interrupts and the thread is not sleeping. Maybe a bug in my DT but I don't know yet.
Here is a shortened version of the relevant DT setup which may be wrong:
&omap5_pmx_core { pinctrl-0 = <&pyra_other_pins>;
pyra_other_pins: pinmux_other_gpio_pins { pinctrl-single,pins = < OMAP5_IOPAD(0x12e, PIN_INPUT_PULLUP | MUX_MODE6) /* 0x12C:[31:16] gpio6_161 - TCA6424 active low interrupt */ >; }; };
&i2c5 { /* microphone detect */ ts3a227@3b { compatible = "ti,ts3a227e"; reg = <0x3b>; interrupt-parent = <&gpio99>; interrupts = <14 IRQ_TYPE_EDGE_RISING>; ti,micbias = <0>; /* 2.1V */ };
/* system-led and other controls */ gpio99: tca6424@22 { compatible = "nxp,pcal6524"; interrupt-parent = <&gpio6>; interrupts = <1 IRQ_TYPE_EDGE_FALLING>; /* gpio6_161 */ vcc-supply = <&vdds_1v8_main>;
reg = <0x22>; gpio-controller; #gpio-cells = <2>; gpio-line-names = "hdmi-ct-hpd", "hdmi.ls-oe", "p02", "p03", "vibra", "fault2", "p06", "p07", "en-usb", "en-host1", "en-host2", "chg-int", "p14", "p15", "mic-int", "en-modem", "shdn-hs-amp", "chg-status+red", "green", "blue", "en-esata", "fault1", "p26", "p27";
}; };
Any hints how to debug this?
Especially how pca953x_irq_bus_sync_unlock() should be called from the initialization of the ts3a227e driver?
And what could make the ts3a227e handler being called without interrupt.
BR and thanks, Nikolaus