Re: [PATCH v2 4/4] i2c: i2c-qcom-geni: Enable i2c controller sharing between two subsystems

From: Mukesh Kumar Savaliya
Date: Tue Sep 10 2024 - 09:39:57 EST


Hi Andi,

On 9/9/2024 6:23 PM, Andi Shyti wrote:
Thank you guys for your reviews,

On Mon, Sep 09, 2024 at 01:37:00PM GMT, Konrad Dybcio wrote:
On 9.09.2024 11:18 AM, Mukesh Kumar Savaliya wrote:
Hi Neil,

On 9/9/2024 2:24 PM, neil.armstrong@xxxxxxxxxx wrote:
Hi,

On 06/09/2024 21:14, Mukesh Kumar Savaliya wrote:
Add support to share I2C SE by two Subsystems in a mutually exclusive way.
Use  "qcom,shared-se" flag in a particular i2c instance node if the
usecase requires i2c controller to be shared.

I2C driver just need to mark first_msg and last_msg flag to help indicate
GPI driver to  take lock and unlock TRE there by protecting from concurrent
access from other EE or Subsystem.

gpi_create_i2c_tre() function at gpi.c will take care of adding Lock and
Unlock TRE for the respective transfer operations.

Since the GPIOs are also shared for the i2c bus between two SS, do not
touch GPIO configuration during runtime suspend and only turn off the
clocks. This will allow other SS to continue to transfer the data
without any disturbance over the IO lines.

This doesn't answer my question about what would be the behavior if one
use uses, for example, GPI DMA, and the Linux kernel FIFO mode or SE DMA ?

Shared usecase is not supported for non GSI mode (FIFO and DMA), it should be static usecase. Dynamic sharing from two clients of two subsystems is only for GSI mode. Hope this helps ?

This should very much be explained in commit message and perhaps in code

And since it can't work with FIFO mode, there should be checks in code
to disallow such invalid configurations

it would be nice if, along with all these open questions and
clarifications on the commit message, we could add some good
comments to the code as well.

Agree, i realized it's good to add comment around code changes too.
In V3 i am incorporating all the suggestions and comments.
Thanks,
Andi