Hello,
I'm sorry for the late reply, I've been very busy lately.
On Wed, Feb 08, 2023 at 03:56:15PM +0000, RRademacher@xxxxxxxxx wrote:
> Hello Mr. Pinchart,
>
> following on from our previous conversation, I have since observed the
> following.
>
> The first call of handle_nested_interrupt() during startup was a
> result of another driver and had nothing to do with the problem. i
> used dump_stack() to find the callee.
OK, that makes sense.
> For the problem, the current debug output reduces to the following:
>
> [ 28.830817] [DBGMSG] pca954x_irq_handler :entering pca954x_irq_handler
> [ 28.831363] [DBGMSG] pca954x_irq_handler :i2c_smbus_read::retval=14
> [ 28.837918] [DBGMSG] pca954x_irq_handler :i=0 | bit: 4 isset in register = true
> [ 28.837921] [DBGMSG] pca954x_irq_handler :irq= 0x65 // child_irq =0xe7
> [ 28.851527] [DBGMSG] handle_nested_irq :entering handle_nested_irq
> [ 28.851542] Call trace:
> [ 28.851555] dump_backtrace+0x0/0x178
> [ 28.851561] show_stack+0x24/0x30
> [ 28.889839] dump_stack+0xb4/0x114
> [ 28.893245] handle_nested_irq+0x44/0x23c
> [ 28.897258] pca954x_irq_handler+0xf4/0x138 [i2c_mux_pca954x]
> [ 28.903006] irq_thread_fn+0x30/0xa0
> [ 28.906581] irq_thread+0x150/0x248
> [ 28.910068] kthread+0x140/0x160
> [ 28.913297] ret_from_fork+0x10/0x1c
> [ 28.916901] [DBGMSG] handle_nested_irq :irq: 0xe7
> [ 28.916905] [DBGMSG] handle_nested_irq :irq_desc->name: (null)
> [ 28.921447] [DBGMSG] handle_nested_irq :irq_desc->parent_irq: 0x0
>
> Do you have any idea what the problem could be?
> I have no idea about, why the interrupt is disabled and why the action of the threaded interrupt is null
> Is it possible that I have forgotten something in the DeviceTree entry?
Nothing immediately strikes me as wrong in your device tree.
Could you share the output of `cat /proc/interrupts` ? If the IRQ
numbers listed in the log above (0x65 and 0xe7) have changed, please
also share the new log, I want to correlate those numbers to
/proc/interrupt entries.
> On Donnerstag, 26. Januar 2023 21:33, Rademacher Ralf wrote:
> >
> > Mr. Pinchart,
> >
> > i have to correct myself:
> > the first call of handle_nested_interrupt happens already before
> > pca954x_probe. i added some more DBGMSGs
> >
> > [ 2.869856] [DBGMSG] handle_nested_irq :irq = 0xdf
> > [ 2.869858] [DBGMSG] handle_nested_irq :action = 0x7ba41100
> > [ 2.874477] [DBGMSG] handle_nested_irq :irqd_irq_disabled(&desc->irq_data): false
> > [ 2.874479] [DBGMSG] handle_nested_irq :(unlikely(!action || irqd_irq_disabled(&desc->irq_data))): false
> > [ 2.874501] [DBGMSG] handle_nested_irq :action->irq:df | action->dev_id:0x7ba64810
> > [ 6.373737] [DBGMSG] pca954x_probe :enter fxn
> > [ 6.973918] [DBGMSG] pca954x_probe :leave fxn
> >
> > On Donnerstag, 26. Januar 2023 21:18, Rademacher Ralf wrote:
> > > On Donnerstag, 26. Januar 2023 19:06, Laurent Pinchart wrote:
> > > > On Thu, Jan 26, 2023 at 05:05:47PM +0000, RRademacher@xxxxxxxxx wrote:
> > > > > Hello Mr. Pinchart,
> > > > >
> > > > > you are listed as maintainer in the i2c-mux-pca954x.yaml file.
> > > > >
> > > > > May I ask if you could take a few minutes and have a look at the following
> > > > > problem, if you can spot a bug in the second DT snippet?
> > > > >
> > > > > Because on the internet you can only find examples where devices are used
> > > > > behind the pca954x which do not use an interrupt.
> > > > >
> > > > > Let me tell you about the problem.
> > > > >
> > > > > At our old device we had implemented this, which worked perfect:
> > > > >
> > > > >
> > > > > &i2c4 {
> > > > > pinctrl-names = "default","gpio";
> > > > > pinctrl-0 = <&pinctrl_i2c4>;
> > > > > pinctrl-1 = <&pinctrl_i2c4_gpio>;
> > > > > sda-gpios = <&gpio5 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > > > > scl-gpios = <&gpio5 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > > > > clock-frequency = <400000>;
> > > > > status = "okay";
> > > > >
> > > > > touchscreen@26 {
> > > > > compatible = "ilitek,ili2117";
> > > > > reg = <0x26>;
> > > > > pinctrl-names = "default";
> > > > > pinctrl-0 = <&pinctrl_ili2117_62>;
> > > > > interrupt-parent = <&gpio2>;
> > > > > interrupts = <7 IRQ_TYPE_EDGE_RISING>;
> > > > > reset-gpios = <&pca9554_interface 0 GPIO_ACTIVE_LOW>;
> > > > > };
> > > > >
> > > > > proximity@39 {
> > > > > compatible = "avago,apds9960";
> > > > > reg = <0x39>;
> > > > > pinctrl-names = "default";
> > > > > pinctrl-0 = <&pinctrl_apds9960_39>;
> > > > > interrupt-parent = <&gpio2>;
> > > > > interrupts = <6 IRQ_TYPE_EDGE_RISING>;
> > > > > };
> > > > > .....
> > > > >
> > > > >
> > > > > Then we want more proximity sensors in this device, that we decided to add the
> > > > > PCA9544A.
> > > > >
> > > > > &i2c4 {
> > > > > .....
> > > > >
> > > > > i2c4_mux_apds: i2c4-mux-pca9544@70 {
> > > > > compatible = "nxp,pca9544";
> > > > > #address-cells = <1>;
> > > > > #size-cells = <0>;
> > > > > reg = <0x70>;
> > > > > interrupt-parent = <&gpio2>;
> > > > > interrupt-controller;
> > > > > pinctrl-names = "default";
> > > > > pinctrl-0 = <&pinctrl_pca9544a_70>;
> > > > > interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
> > > > >
> > > > > i2c@0 {
> > > > > #address-cells = <1>;
> > > > > #size-cells = <0>;
> > > > > reg = <0>;
> > > > >
> > > > > proximity@39 {
> > > > > compatible = "avago,apds9960";
> > > > > reg = <0x39>;
> > > > > interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
> > > > > interrupt-parent = <&i2c4_mux_apds>;
> > > > > };
> > > > > };
> > > > >
> > > > >
> > > > >
> > > > > Both drivers (pca954x and apds9960) request threaded irqs in their probe
> > > > > function, but it does not work together. Although the apds9960 also gets one
> > > > > assigned, when the handle_nested_irq function is called (After everything has
> > > > > been initialized. However, this seems to be the second call to this function!
> > > > > First call seems to be inside the initialization phase.) the irq seems to be
> > > > > disabled. And thus the processing does not start.
> > > > >
> > > > > I think that the problem is in my devicetree entry, that the soc doesn't really
> > > > > know how to handle the interrupt of the apds9960.
> > > >
> > > > How are interrupts connected at the hardware level ? Is the APDS9960
> > > > interrupt connected to the INT0 pin of the PCA9544 ?
> > >
> > > Yes, it is.
> > >
> > > > You have switched from IRQ_TYPE_EDGE_RISING to IRQ_TYPE_EDGE_FALLING for
> > > > the APDS9960, is that intentional ?
> > >
> > > Yes, I assumed this is correct, because APDS9960 datasheet tells me
> > > that: "Interrupt open drain (active low)". So i thought i have to
> > > detect the falling edge, not the rising edge. The same in the
> > > datasheet of PCA9544A, there are 4 active low interrupt inputs.
> > >
> > > > Is there any message printed to the kernel log around the time where
> > > > either driver is probed, or when the APDS9960 interrupt is supposed to
> > > > occur, that may indicate a problem ?
> > >
> > > I have inserted some DBGMSGs into the functions handle_nested_irq
> > > and in the pca954x_probe. during pca954x driver probe, there is the
> > > following output:
> > >
> > > [ 2.869856] [DBGMSG] handle_nested_irq :irq = 0xdf
> > > [ 2.869858] [DBGMSG] handle_nested_irq :action = 0x7ba41100
> > > [ 2.874477] [DBGMSG] handle_nested_irq :irqd_irq_disabled(&desc->irq_data): false
> > > [ 2.874479] [DBGMSG] handle_nested_irq :(unlikely(!action || irqd_irq_disabled(&desc->irq_data))): false
> > > [ 2.874501] [DBGMSG] handle_nested_irq :action->irq:df | action->dev_id:0x7ba64810
> > >
> > > when a apds sends the interrupt signal to the pca954x, this happens:
> > >
> > > [ 9336.607055] [DBGMSG] pca954x_irq_handler :pca954x_irq_handler starts
> > > [ 9336.607908] [DBGMSG] pca954x_irq_handler :i2c_smbus_read::retval=14
> > > [ 9336.613255] [DBGMSG] pca954x_irq_handler :i=0 | bit: 4 is set in register
> > > [ 9336.619539] [DBGMSG] pca954x_irq_handler :irq= 0x65 // child_irq =0xe7
> > > [ 9336.619542] [DBGMSG] handle_nested_irq :irq = 0xe7
> > > [ 9336.632516] [DBGMSG] handle_nested_irq :action = 0x0
> > > [ 9336.632519] [DBGMSG] handle_nested_irq :irqd_irq_disabled(&desc->irq_data):true
> > > [ 9336.632521] [DBGMSG] handle_nested_irq :(unlikely(!action || irqd_irq_disabled(&desc->irq_data))):true
> > > [ 9336.632523] [DBGMSG] handle_nested_irq :goto out_unlock
--
Regards,
Laurent Pinchart
