Hi Fabio,
On Thu, Aug 22, 2024 at 08:07:44AM -0300, Fabio Estevam wrote:
> Hi Stefan and Oleksij,
>
> On Wed, Aug 21, 2024 at 8:01 AM Fabio Estevam <festevam@xxxxxxxxx> wrote:
>
> > This fixes a pca953x probe error on an imx8mp board running linux-stable 6.6:
> >
> > [ 1.893260] pca953x 2-0020: failed writing register
> > [ 1.898258] pca953x 2-0020: probe with driver pca953x failed with error -11
> >
> > Could you please add a Fixes tag and Cc stable so that this can reach
> > the stable kernels?
> >
> > Tested-by: Fabio Estevam <festevam@xxxxxxx>
>
> I am sorry, but I have to withdraw my Tested-by tag.
>
> For debugging purposes, I kept 'fw_devlink=off' in the kernel command
> line and that's what made it work.
>
> Removing 'fw_devlink=off' I still get the probe failure, even with all
> the series from Stefan applied:
>
> [ 1.849097] pca953x 2-0020: supply vcc not found, using dummy regulator
> [ 1.855857] pca953x 2-0020: using no AI
> [ 1.859965] i2c i2c-2: <i2c_imx_write> write failed with -6
> [ 1.865578] pca953x 2-0020: failed writing register: -6
>
> In my case, I can get the pca953x driver to probe successfully in one
> of the following cases:
>
> 1. Select pca953x as a module instead of built-in
>
> or
>
> 2. Pass 'fw_devlink=off' in the kernel command line
>
> or
>
> 3. Register the i2c-imx driver as module_platform_driver():
>
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1586,17 +1586,7 @@ static struct platform_driver i2c_imx_driver = {
> .id_table = imx_i2c_devtype,
> };
>
> -static int __init i2c_adap_imx_init(void)
> -{
> - return platform_driver_register(&i2c_imx_driver);
> -}
> -subsys_initcall(i2c_adap_imx_init);
> -
> -static void __exit i2c_adap_imx_exit(void)
> -{
> - platform_driver_unregister(&i2c_imx_driver);
> -}
> -module_exit(i2c_adap_imx_exit);
> +module_platform_driver(i2c_imx_driver);
>
> or
>
> 4. Use the NXP vendor kernel imx_6.1.22_2.0.0 kernel
>
> Stefan, do you get the arbitration errors if you try methods 2 or 3 above?
I will try to test this on my end tomorrow. In our test case however one
problem was that when the schedule was called the ADC (TI ADS1015) may
timeout if it is not processed within 25ms which sometimes happened.
However, it also requires the other change because even if we have not
set multi-master, the wakeup of the sender/receiver thread can take too
much time, so we still end up in this 25ms timeout. This only happens
when the system is under heavy load.
In your setup, do you know what mode (atomic, interrupt, dma) the driver
uses when it works and when it fails?
