| Message ID | 20241113161413.3821858-5-quic_msavaliy@quicinc.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Enable shared SE support over I2C | expand |
On 13.11.2024 5:14 PM, Mukesh Kumar Savaliya wrote: > Add support to share I2C controller in multiprocessor system 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. Can we read back some value from the registers to know whether such sharing takes place? > Sharing of I2C SE(Serial engine) is possible only for GSI mode as client > from each processor can queue transfers over its own GPII Channel. For > non GSI mode, we should force disable this feature even if set by user > from DT by mistake. The DT is to be taken authoritatively > > 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 between two SS, do not unconfigure them > during runtime suspend. This will allow other SS to continue to transfer > the data without any disturbance over the IO lines. > > For example, Assume an I2C EEPROM device connected with an I2C controller. > Each client from ADSP and APPS processor can perform i2c transactions > without any disturbance from each other. > > Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> > --- [...] > } else { > gi2c->gpi_mode = false; > + > + /* Force disable shared SE case for non GSI mode */ > + gi2c->se.shared_geni_se = false; Doing this silently sounds rather odd.. Konrad
Thanks for the review konrad ! On 11/16/2024 12:58 AM, Konrad Dybcio wrote: > On 13.11.2024 5:14 PM, Mukesh Kumar Savaliya wrote: >> Add support to share I2C controller in multiprocessor system 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. > > Can we read back some value from the registers to know whether such sharing > takes place? Actually, HW register doesn't provide such mechanism, it's add on feature if SE is programmed for GSI mode. > >> Sharing of I2C SE(Serial engine) is possible only for GSI mode as client >> from each processor can queue transfers over its own GPII Channel. For >> non GSI mode, we should force disable this feature even if set by user >> from DT by mistake. > > The DT is to be taken authoritatively > To clarify - Does it mean i should not have SW disable this feature OR override ? And let it continue in non GSI mode even it's not going to work ? >> >> 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 between two SS, do not unconfigure them >> during runtime suspend. This will allow other SS to continue to transfer >> the data without any disturbance over the IO lines. >> >> For example, Assume an I2C EEPROM device connected with an I2C controller. >> Each client from ADSP and APPS processor can perform i2c transactions >> without any disturbance from each other. >> >> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> >> --- > > [...] > >> } else { >> gi2c->gpi_mode = false; >> + >> + /* Force disable shared SE case for non GSI mode */ >> + gi2c->se.shared_geni_se = false; > > Doing this silently sounds rather odd.. we can have Some SW logging added ? > > Konrad
On 18.11.2024 6:45 AM, Mukesh Kumar Savaliya wrote: > Thanks for the review konrad ! > > On 11/16/2024 12:58 AM, Konrad Dybcio wrote: >> On 13.11.2024 5:14 PM, Mukesh Kumar Savaliya wrote: >>> Add support to share I2C controller in multiprocessor system 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. >> >> Can we read back some value from the registers to know whether such sharing >> takes place? > Actually, HW register doesn't provide such mechanism, it's add on feature if SE is programmed for GSI mode. So it's more of an unwritten contract between subsystems.. okay >> >>> Sharing of I2C SE(Serial engine) is possible only for GSI mode as client >>> from each processor can queue transfers over its own GPII Channel. For >>> non GSI mode, we should force disable this feature even if set by user >>> from DT by mistake. >> >> The DT is to be taken authoritatively >> > To clarify - Does it mean i should not have SW disable this feature OR override ? And let it continue in non GSI mode even it's not going to work ? If a configuration is invalid, you should return -EINVAL from probe, with an appropriate error message. >>> >>> 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 between two SS, do not unconfigure them >>> during runtime suspend. This will allow other SS to continue to transfer >>> the data without any disturbance over the IO lines. >>> >>> For example, Assume an I2C EEPROM device connected with an I2C controller. >>> Each client from ADSP and APPS processor can perform i2c transactions >>> without any disturbance from each other. >>> >>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> >>> --- >> >> [...] >> >>> } else { >>> gi2c->gpi_mode = false; >>> + >>> + /* Force disable shared SE case for non GSI mode */ >>> + gi2c->se.shared_geni_se = false; >> >> Doing this silently sounds rather odd.. > we can have Some SW logging added ? Normally such overrides mandate a warning/notice, but as I said above, we should disallow such combinations altogether for sanity Konrad
Thanks Konrad ! On 11/22/2024 7:12 PM, Konrad Dybcio wrote: > On 18.11.2024 6:45 AM, Mukesh Kumar Savaliya wrote: >> Thanks for the review konrad ! >> >> On 11/16/2024 12:58 AM, Konrad Dybcio wrote: >>> On 13.11.2024 5:14 PM, Mukesh Kumar Savaliya wrote: >>>> Add support to share I2C controller in multiprocessor system 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. >>> >>> Can we read back some value from the registers to know whether such sharing >>> takes place? >> Actually, HW register doesn't provide such mechanism, it's add on feature if SE is programmed for GSI mode. > > So it's more of an unwritten contract between subsystems.. okay > yes, purely SW flag based decision. >>> >>>> Sharing of I2C SE(Serial engine) is possible only for GSI mode as client >>>> from each processor can queue transfers over its own GPII Channel. For >>>> non GSI mode, we should force disable this feature even if set by user >>>> from DT by mistake. >>> >>> The DT is to be taken authoritatively >>> >> To clarify - Does it mean i should not have SW disable this feature OR override ? And let it continue in non GSI mode even it's not going to work ? > > If a configuration is invalid, you should return -EINVAL from probe, > with an appropriate error message. > Sure, i agree. I will make a change here and will bail out with an error and print logs if (gi2c->se.shared_geni_se == true). Thanks for this suggestion. >>>> >>>> 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 between two SS, do not unconfigure them >>>> during runtime suspend. This will allow other SS to continue to transfer >>>> the data without any disturbance over the IO lines. >>>> >>>> For example, Assume an I2C EEPROM device connected with an I2C controller. >>>> Each client from ADSP and APPS processor can perform i2c transactions >>>> without any disturbance from each other. >>>> >>>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> >>>> --- >>> >>> [...] >>> >>>> } else { >>>> gi2c->gpi_mode = false; >>>> + >>>> + /* Force disable shared SE case for non GSI mode */ >>>> + gi2c->se.shared_geni_se = false; >>> >>> Doing this silently sounds rather odd.. >> we can have Some SW logging added ? > > Normally such overrides mandate a warning/notice, but as I said above, > we should disallow such combinations altogether for sanity > Sure, taken cared with above suggestion. > Konrad
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 7a22e1f46e60..4bc5a5ea47f7 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 // Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. +// Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved. #include <linux/acpi.h> #include <linux/clk.h> @@ -617,6 +618,7 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i peripheral.clk_div = itr->clk_div; peripheral.set_config = 1; peripheral.multi_msg = false; + peripheral.shared_se = gi2c->se.shared_geni_se; for (i = 0; i < num; i++) { gi2c->cur = &msgs[i]; @@ -627,6 +629,8 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i if (i < num - 1) peripheral.stretch = 1; + peripheral.first_msg = (i == 0); + peripheral.last_msg = (i == num - 1); peripheral.addr = msgs[i].addr; ret = geni_i2c_gpi(gi2c, &msgs[i], &config, @@ -815,6 +819,11 @@ static int geni_i2c_probe(struct platform_device *pdev) gi2c->clk_freq_out = KHZ(100); } + if (of_property_read_bool(pdev->dev.of_node, "qcom,shared-se")) { + gi2c->se.shared_geni_se = true; + dev_dbg(&pdev->dev, "I2C is shared between subsystems\n"); + } + if (has_acpi_companion(dev)) ACPI_COMPANION_SET(&gi2c->adap.dev, ACPI_COMPANION(dev)); @@ -887,8 +896,10 @@ static int geni_i2c_probe(struct platform_device *pdev) else fifo_disable = readl_relaxed(gi2c->se.base + GENI_IF_DISABLE_RO) & FIFO_IF_DISABLE; - if (fifo_disable) { - /* FIFO is disabled, so we can only use GPI DMA */ + if (fifo_disable || gi2c->se.shared_geni_se) { + /* FIFO is disabled, so we can only use GPI DMA. + * SE can be shared in GSI mode between subsystems, each SS owns a GPII. + **/ gi2c->gpi_mode = true; ret = setup_gpi_dma(gi2c); if (ret) { @@ -900,6 +911,9 @@ static int geni_i2c_probe(struct platform_device *pdev) dev_dbg(dev, "Using GPI DMA mode for I2C\n"); } else { gi2c->gpi_mode = false; + + /* Force disable shared SE case for non GSI mode */ + gi2c->se.shared_geni_se = false; tx_depth = geni_se_get_tx_fifo_depth(&gi2c->se); /* I2C Master Hub Serial Elements doesn't have the HW_PARAM_0 register */ @@ -981,7 +995,6 @@ static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev) if (ret) { enable_irq(gi2c->irq); return ret; - } else { gi2c->suspended = 1; }
Add support to share I2C controller in multiprocessor system 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. Sharing of I2C SE(Serial engine) is possible only for GSI mode as client from each processor can queue transfers over its own GPII Channel. For non GSI mode, we should force disable this feature even if set by user from DT by mistake. 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 between two SS, do not unconfigure them during runtime suspend. This will allow other SS to continue to transfer the data without any disturbance over the IO lines. For example, Assume an I2C EEPROM device connected with an I2C controller. Each client from ADSP and APPS processor can perform i2c transactions without any disturbance from each other. Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> --- drivers/i2c/busses/i2c-qcom-geni.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-)