sob., 25 gru 2021 o 16:59 Andy Shevchenko <andy.shevchenko@xxxxxxxxx> napisał(a): > > On Thu, Dec 23, 2021 at 4:43 PM Jan Dabros <jsd@xxxxxxxxxxxx> 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
