Hi,
Am 28.03.2018 um 18:50 schrieb H. Nikolaus Schaller hns@goldelico.com:
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.
I have solved this issue.
I had assumed that it is sufficient to refer to the pcal6524 phandle as interrupt-parent.
But it turns out that the chip has to be marked in the DT as an interrupt-controller.
The result without this seems to have been that the omap-gpio irq was delivered to the ts3a227 driver which is not able to remove the irq at the gpio.
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:
/* 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>;
interrupt-controller; #interrupt-cells = <2>;
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";}; };
And what could make the ts3a227e handler being called without interrupt.
Now this seems to work, the ts3a227e interrupt flooding has stopped and pca953x_irq_bus_sync_unlock() is called as expected.
I think I'll include a patch for the pca953x bindings documentation to better point this out, maybe with example.
Another issue I have fixed is that the pcal6524 has 4 registers per bank while the pcal9555a has only 2. This is encoded in the address constants for the new "L"-registers and has to be taken care of in pca953x_read_regs_24() and pca953x_write_regs_24().
But I still have another problem:
[ 4.808823] pca953x 4-0022: irq 186: unsupported type 8 [ 4.814303] genirq: Setting trigger mode 8 for irq 186 failed (pca953x_irq_set_type+0x0/0xa8)
This comes from https://elixir.bootlin.com/linux/v4.16-rc7/source/sound/soc/codecs/ts3a227e....
It appears that the pca953x driver/interrupt-controller can't handle IRQF_TRIGGER_LOW, but that is hard coded into the ts3a227 driver.
Anyone with knowledge and help about this issue?
BR and thanks, Nikolaus