Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <2f7610dc-ab57-ddbf-277f-e84680da71bd@redhat.com>
Date:   Thu, 20 Jan 2022 12:15:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Subject: Re: [PATCH 0/2] i2c-designware: Add support for AMD PSP semaphore
Content-Language: en-US
To:     Jan Dabros <jsd@semihalf.com>, linux-kernel@vger.kernel.org,
        linux-i2c@vger.kernel.org, jarkko.nikula@linux.intel.com
Cc:     andriy.shevchenko@linux.intel.com, mika.westerberg@linux.intel.com,
        wsa@kernel.org, rrangel@chromium.org, mw@semihalf.com,
        jaz@semihalf.com, upstream@semihalf.com
References: <20220120001621.705352-1-jsd@semihalf.com>
From:   Hans de Goede <hdegoede@redhat.com>
In-Reply-To: <20220120001621.705352-1-jsd@semihalf.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Jan,

On 1/20/22 01:16, Jan Dabros 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.
> 
> This patchset is a follow-up to the RFC sent earlier on LKML [1], with review
> comments applied.
> 
> Looking forward to some feedback.
> 
> [1] https://lkml.org/lkml/2021/12/22/219


Thank you for your patch series.

As you may have seen I've done a lot of work on the Bay Trail semaphore
thing. I also own several Bay Trail and Cherry Trail based devices which
use this setup.

I'll add your patches to my personal WIP tree which I regularly run
on these devices and I'll report back if I notice any issues.

One remark, I notice that there are no AMD people in the Cc, it
would be good if you can find someone from AMD to look at this,
also see my remarks to the 2nd patch in my reply to that patch.

Regards,

Hans


> 
> 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                   |  10 +
>  drivers/i2c/busses/Makefile                  |   1 +
>  drivers/i2c/busses/i2c-designware-amdpsp.c   | 357 +++++++++++++++++++
>  drivers/i2c/busses/i2c-designware-baytrail.c |  10 +-
>  drivers/i2c/busses/i2c-designware-common.c   |  12 +
>  drivers/i2c/busses/i2c-designware-core.h     |  18 +-
>  drivers/i2c/busses/i2c-designware-master.c   |   6 +
>  drivers/i2c/busses/i2c-designware-platdrv.c  |  61 ++++
>  10 files changed, 469 insertions(+), 8 deletions(-)
>  create mode 100644 drivers/i2c/busses/i2c-designware-amdpsp.c
>