Re: question about devicetree entry pca954x

* Re: question about devicetree entry pca954x
       [not found] <6c4c41f6cac34573b2c5ab14cb0ba27e@heine.com>
@ 2023-01-26 18:06 ` Laurent Pinchart
  2023-01-26 20:18   ` AW: #Extern_Re: " RRademacher
  0 siblings, 1 reply; 6+ messages in thread
From: Laurent Pinchart @ 2023-01-26 18:06 UTC (permalink / raw)
  To: RRademacher; +Cc: linux-i2c

Hello,

On Thu, Jan 26, 2023 at 05:05:47PM +0000, RRademacher@heine.com 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 ?

You have switched from IRQ_TYPE_EDGE_RISING to IRQ_TYPE_EDGE_FALLING for
the APDS9960, is that intentional ?

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 ?

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 6+ messages in thread