mbox series

[RFC,0/2] i2c-designware: Add support for AMD PSP semaphore

Message ID 20211222094558.2098791-1-jsd@semihalf.com
Headers show
Series i2c-designware: Add support for AMD PSP semaphore | expand

Message

Jan Dąbroś Dec. 22, 2021, 9:45 a.m. UTC
This patchset comprises support for new i2c-designware controller setup on some
AMD Cezanne SoCs, where x86 is sharing i2c bus with PSP. PSP uses the same
controller and acts as an i2c arbitrator there (x86 is leasing bus from it).

First commit aims to improve generic i2c-designware code by adding extra locking
on probe() and disable() paths. I would like to ask someone with access to
boards which use Intel BayTrail(CONFIG_I2C_DESIGNWARE_BAYTRAIL) to verify
behavior of my changes on such setup.

Second commit adds support for new PSP semaphore arbitration mechanism.
Implementation is similar to the one from i2c-designware-baytrail.c however
there are two main differences:
1) Add new ACPI ID in order to protect against silent binding of the old driver
to the setup with PSP semaphore. Extra flag ARBITRATION_SEMAPHORE added to this
new _HID allows to recognize setup with PSP.
2) Beside acquire_lock() and release_lock() methods we are also applying quirks
to the lock_bus() and unlock_bus() global adapter methods. With this in place
all i2c clients drivers may lock i2c bus for a desired number of i2c
transactions (e.g. write-wait-read) without being aware of that such bus is
shared with another entity.

Mark this patchset as RFC, since waiting for new ACPI ID value. As a temporary
measure use "AMDI9999". Once proper one will be ready, will re-send this CL for
review & merge.

Looking forward to some feedback.

Jan Dabros (2):
  i2c: designware: Add missing locks
  i2c: designware: Add AMD PSP I2C bus support

 MAINTAINERS                                 |   1 +
 drivers/acpi/acpi_apd.c                     |   1 +
 drivers/i2c/busses/Kconfig                  |  20 ++
 drivers/i2c/busses/Makefile                 |   1 +
 drivers/i2c/busses/i2c-designware-amdpsp.c  | 359 ++++++++++++++++++++
 drivers/i2c/busses/i2c-designware-common.c  |  12 +
 drivers/i2c/busses/i2c-designware-core.h    |   9 +-
 drivers/i2c/busses/i2c-designware-master.c  |   6 +
 drivers/i2c/busses/i2c-designware-platdrv.c |   3 +
 9 files changed, 411 insertions(+), 1 deletion(-)
 create mode 100644 drivers/i2c/busses/i2c-designware-amdpsp.c

Comments

Andy Shevchenko Dec. 25, 2021, 3:58 p.m. UTC | #1
On Thu, Dec 23, 2021 at 4:43 PM Jan Dabros <jsd@semihalf.com> wrote:
>
> This patchset comprises support for new i2c-designware controller setup on some
> AMD Cezanne SoCs, where x86 is sharing i2c bus with PSP. PSP uses the same
> controller and acts as an i2c arbitrator there (x86 is leasing bus from it).
>
> First commit aims to improve generic i2c-designware code by adding extra locking
> on probe() and disable() paths. I would like to ask someone with access to
> boards which use Intel BayTrail(CONFIG_I2C_DESIGNWARE_BAYTRAIL) to verify
> behavior of my changes on such setup.
>
> Second commit adds support for new PSP semaphore arbitration mechanism.
> Implementation is similar to the one from i2c-designware-baytrail.c however
> there are two main differences:
> 1) Add new ACPI ID in order to protect against silent binding of the old driver
> to the setup with PSP semaphore. Extra flag ARBITRATION_SEMAPHORE added to this
> new _HID allows to recognize setup with PSP.
> 2) Beside acquire_lock() and release_lock() methods we are also applying quirks
> to the lock_bus() and unlock_bus() global adapter methods. With this in place
> all i2c clients drivers may lock i2c bus for a desired number of i2c
> transactions (e.g. write-wait-read) without being aware of that such bus is
> shared with another entity.
>
> Mark this patchset as RFC, since waiting for new ACPI ID value. As a temporary
> measure use "AMDI9999". Once proper one will be ready, will re-send this CL for
> review & merge.
>
> Looking forward to some feedback.

When you will be ready, CC a new version also to Hans, he may look at
it from the Baytrail functionality perspective.
Jan Dąbroś Dec. 27, 2021, 7 a.m. UTC | #2
sob., 25 gru 2021 o 16:59 Andy Shevchenko <andy.shevchenko@gmail.com>
napisał(a):
>
> On Thu, Dec 23, 2021 at 4:43 PM Jan Dabros <jsd@semihalf.com> wrote:
> >
> > This patchset comprises support for new i2c-designware controller setup on some
> > AMD Cezanne SoCs, where x86 is sharing i2c bus with PSP. PSP uses the same
> > controller and acts as an i2c arbitrator there (x86 is leasing bus from it).
> >
> > First commit aims to improve generic i2c-designware code by adding extra locking
> > on probe() and disable() paths. I would like to ask someone with access to
> > boards which use Intel BayTrail(CONFIG_I2C_DESIGNWARE_BAYTRAIL) to verify
> > behavior of my changes on such setup.
> >
> > Second commit adds support for new PSP semaphore arbitration mechanism.
> > Implementation is similar to the one from i2c-designware-baytrail.c however
> > there are two main differences:
> > 1) Add new ACPI ID in order to protect against silent binding of the old driver
> > to the setup with PSP semaphore. Extra flag ARBITRATION_SEMAPHORE added to this
> > new _HID allows to recognize setup with PSP.
> > 2) Beside acquire_lock() and release_lock() methods we are also applying quirks
> > to the lock_bus() and unlock_bus() global adapter methods. With this in place
> > all i2c clients drivers may lock i2c bus for a desired number of i2c
> > transactions (e.g. write-wait-read) without being aware of that such bus is
> > shared with another entity.
> >
> > Mark this patchset as RFC, since waiting for new ACPI ID value. As a temporary
> > measure use "AMDI9999". Once proper one will be ready, will re-send this CL for
> > review & merge.
> >
> > Looking forward to some feedback.
>
> When you will be ready, CC a new version also to Hans, he may look at
> it from the Baytrail functionality perspective.

Thanks for the hint, it will be very helpful to have this tested on
Baytrail. From other comments on this RFC it seems that I would need
to affect Baytrail-semaphore path even more than initially thought.

Best Regards,
Jan