mbox series

[0/4] i2c: core: add generic GPIO bus recovery

Message ID 20200804095926.205643-1-codrin.ciubotariu@microchip.com (mailing list archive)
Headers show
Series i2c: core: add generic GPIO bus recovery | expand

Message

Codrin Ciubotariu Aug. 4, 2020, 9:59 a.m. UTC 
GPIO recovery has been added already for some I2C bus drivers, such as
imx, pxa and at91. These drivers use similar bindings and have more or
less the same code for recovery. For this reason, we aim to move the
GPIO bus recovery implementation to the I2C core so that other drivers
can benefit from it, with small modifications.
This implementation initializes the pinctrl states and the SDA/SCL
GPIOs based on common bindings. The I2C bus drivers can still use
different bindings or other particular recovery steps if needed.
The ugly part with this patch series is the handle of PROBE_DEFER
which could be returned by devm_gpiod_get(). This changes things a
little for i2c_register_adapter() and for this reason this step is
implemented in a sperate patch.
The at91 Microchip driver is the first to use this implementation,
with an AI to move the rest of the drivers in the following steps.

This patch series was previously sent as a RFC. Significant changes
since RFC:
- "recovery" pinctrl state marked as deprecared in bindings;
- move to "gpio" pinctrl state done after the call to prepare_recovery()
  callback;
- glitch protection when SDA gpio is taken at initialization;

Codrin Ciubotariu (4):
  dt-binding: i2c: add generic properties for GPIO bus recovery
  i2c: core: add generic I2C GPIO recovery
  i2c: core: treat EPROBE_DEFER when acquiring SCL/SDA GPIOs
  i2c: at91: Move to generic GPIO bus recovery

 Documentation/devicetree/bindings/i2c/i2c.txt |  10 ++
 drivers/i2c/busses/i2c-at91-master.c          |  69 +-------
 drivers/i2c/busses/i2c-at91.h                 |   3 -
 drivers/i2c/i2c-core-base.c                   | 150 ++++++++++++++++--
 include/linux/i2c.h                           |  11 ++
 5 files changed, 163 insertions(+), 80 deletions(-)

Comments

Wolfram Sang Aug. 5, 2020, 8:52 a.m. UTC | #1 
Codrin, everyone

> This patch series was previously sent as a RFC. Significant changes
> since RFC:
> - "recovery" pinctrl state marked as deprecared in bindings;
> - move to "gpio" pinctrl state done after the call to prepare_recovery()
>   callback;
> - glitch protection when SDA gpio is taken at initialization;

Thanks for the fast update, now all merged for inclusion into 5.9. I
think it is really good, but to verify and double check, I think two
things would be even better..

One thing, I'll definately be doing is to add this feature to
i2c-sh_mobile.c and scope the results.

The other thing would be to convert the PXA driver and see if our
generic support can help their advanced use case or if we are missing
something. Codrin, do you have maybe time and interest to do that? That
would be awesome!

Happy hacking and kind regards,

   Wolfram
Codrin Ciubotariu Aug. 5, 2020, 10:29 a.m. UTC | #2 
On 05.08.2020 11:52, wsa@kernel.org wrote:
> Codrin, everyone
> 
>> This patch series was previously sent as a RFC. Significant changes
>> since RFC:
>> - "recovery" pinctrl state marked as deprecared in bindings;
>> - move to "gpio" pinctrl state done after the call to prepare_recovery()
>>    callback;
>> - glitch protection when SDA gpio is taken at initialization;
> 
> Thanks for the fast update, now all merged for inclusion into 5.9. I
> think it is really good, but to verify and double check, I think two
> things would be even better..

Happy to help.

> 
> One thing, I'll definately be doing is to add this feature to
> i2c-sh_mobile.c and scope the results.
> 
> The other thing would be to convert the PXA driver and see if our
> generic support can help their advanced use case or if we are missing
> something. Codrin, do you have maybe time and interest to do that? That
> would be awesome!

Naturally, these would be the next steps. I can do this, sure, but I 
don't have the HW. I'll look for some development kits. If you have any 
recommendations, please let me know.

Best regards,
Codrin
Wolfram Sang Aug. 5, 2020, 11:17 a.m. UTC | #3 
> > The other thing would be to convert the PXA driver and see if our
> > generic support can help their advanced use case or if we are missing
> > something. Codrin, do you have maybe time and interest to do that? That
> > would be awesome!
> 
> Naturally, these would be the next steps. I can do this, sure, but I 
> don't have the HW. I'll look for some development kits. If you have any 
> recommendations, please let me know.

No need for HW, I think. Just do a best effort conversion, double or
triple check it, and CC the patches also to Russell King. If he accepts
them, we are good.

Thanks for doing it!