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

[Mukesh Kumar Savaliya]

Thanks Konrad !

On 9/9/2024 5:07 PM, 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
Noted,  will add in commit message and cover letter.
> And since it can't work with FIFO mode, there should be checks in code
> to disallow such invalid configurations
Agree, will add in next patch.
> Konrad