| Message ID | 20241129144357.2008465-3-quic_msavaliy@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | Enable shared SE support over I2C | expand |
On 29-11-24, 20:13, Mukesh Kumar Savaliya wrote: > GSI DMA provides specific TREs(Transfer ring element) namely Lock and > Unlock TRE. It provides mutually exclusive access to I2C controller from > any of the processor(Apps,ADSP). Lock prevents other subsystems from > concurrently performing DMA transfers and avoids disturbance to data path. > Basically for shared I2C usecase, lock the SE(Serial Engine) for one of > the processor, complete the transfer, unlock the SE. > > Apply Lock TRE for the first transfer of shared SE and Apply Unlock > TRE for the last transfer. > > Also change MAX_TRE macro to 5 from 3 because of the two additional TREs. > ... > @@ -65,6 +65,9 @@ enum i2c_op { > * @rx_len: receive length for buffer > * @op: i2c cmd > * @muli-msg: is part of multi i2c r-w msgs > + * @shared_se: bus is shared between subsystems > + * @bool first_msg: use it for tracking multimessage xfer > + * @bool last_msg: use it for tracking multimessage xfer > */ > struct gpi_i2c_config { > u8 set_config; > @@ -78,6 +81,9 @@ struct gpi_i2c_config { > u32 rx_len; > enum i2c_op op; > bool multi_msg; > + bool shared_se; Looking at this why do you need this field? It can be internal to your i2c driver... Why not just set an enum for lock and use the values as lock/unlock/dont care and make the interface simpler. I see no reason to use three variables to communicate the info which can be handled in simpler way..? > + bool first_msg; > + bool last_msg;
Thanks for the review comments Vinod ! On 12/2/2024 12:17 PM, Vinod Koul wrote: > On 29-11-24, 20:13, Mukesh Kumar Savaliya wrote: >> GSI DMA provides specific TREs(Transfer ring element) namely Lock and >> Unlock TRE. It provides mutually exclusive access to I2C controller from >> any of the processor(Apps,ADSP). Lock prevents other subsystems from >> concurrently performing DMA transfers and avoids disturbance to data path. >> Basically for shared I2C usecase, lock the SE(Serial Engine) for one of >> the processor, complete the transfer, unlock the SE. >> >> Apply Lock TRE for the first transfer of shared SE and Apply Unlock >> TRE for the last transfer. >> >> Also change MAX_TRE macro to 5 from 3 because of the two additional TREs. >> > > ... > >> @@ -65,6 +65,9 @@ enum i2c_op { >> * @rx_len: receive length for buffer >> * @op: i2c cmd >> * @muli-msg: is part of multi i2c r-w msgs >> + * @shared_se: bus is shared between subsystems >> + * @bool first_msg: use it for tracking multimessage xfer >> + * @bool last_msg: use it for tracking multimessage xfer >> */ >> struct gpi_i2c_config { >> u8 set_config; >> @@ -78,6 +81,9 @@ struct gpi_i2c_config { >> u32 rx_len; >> enum i2c_op op; >> bool multi_msg; >> + bool shared_se; > > Looking at this why do you need this field? It can be internal to your > i2c driver... Why not just set an enum for lock and use the values as > lock/unlock/dont care and make the interface simpler. I see no reason to > use three variables to communicate the info which can be handled in > simpler way..? > Below was earlier reply to [PATCH V3, 2/4], please let me know if you have any additional comment and need further clarifications. -- > Looking at the usage in following patches, why cant this be handled > internally as part of prep call? > As per design, i2c driver iterates over each message and submits to GPI where it creates TRE. Since it's per transfer, we need to create Lock and Unlock TRE based on first or last message. -- >> + bool first_msg; >> + bool last_msg; >
Hi Vinod, Thanks ! I just saw your comments now as somehow it was going in some other folder and didn't realize. On 12/4/2024 5:51 PM, Vinod Koul wrote: > On 02-12-24, 16:13, Mukesh Kumar Savaliya wrote: >> Thanks for the review comments Vinod ! >> >> On 12/2/2024 12:17 PM, Vinod Koul wrote: >>> On 29-11-24, 20:13, Mukesh Kumar Savaliya wrote: >>>> GSI DMA provides specific TREs(Transfer ring element) namely Lock and >>>> Unlock TRE. It provides mutually exclusive access to I2C controller from >>>> any of the processor(Apps,ADSP). Lock prevents other subsystems from >>>> concurrently performing DMA transfers and avoids disturbance to data path. >>>> Basically for shared I2C usecase, lock the SE(Serial Engine) for one of >>>> the processor, complete the transfer, unlock the SE. >>>> >>>> Apply Lock TRE for the first transfer of shared SE and Apply Unlock >>>> TRE for the last transfer. >>>> >>>> Also change MAX_TRE macro to 5 from 3 because of the two additional TREs. >>>> >>> >>> ... >>> >>>> @@ -65,6 +65,9 @@ enum i2c_op { >>>> * @rx_len: receive length for buffer >>>> * @op: i2c cmd >>>> * @muli-msg: is part of multi i2c r-w msgs >>>> + * @shared_se: bus is shared between subsystems >>>> + * @bool first_msg: use it for tracking multimessage xfer >>>> + * @bool last_msg: use it for tracking multimessage xfer >>>> */ >>>> struct gpi_i2c_config { >>>> u8 set_config; >>>> @@ -78,6 +81,9 @@ struct gpi_i2c_config { >>>> u32 rx_len; >>>> enum i2c_op op; >>>> bool multi_msg; >>>> + bool shared_se; >>> >>> Looking at this why do you need this field? It can be internal to your >>> i2c driver... Why not just set an enum for lock and use the values as >>> lock/unlock/dont care and make the interface simpler. I see no reason to >>> use three variables to communicate the info which can be handled in >>> simpler way..? >>> >> Below was earlier reply to [PATCH V3, 2/4], please let me know if you have >> any additional comment and need further clarifications. > > Looks like you misunderstood, the question is why do you need three > variables to convey this info..? Use a single variable please Yes, I think so. Please let me clarify. First variable is a feature flag and it's required to be explicitly mentioned by client (i2c/spi/etc) to GSI driver. Second and third, can be optimized to boolean so either first or last can be passed. Please correct me or add simple change where you would like to make, i can add that. > >> -- >>> Looking at the usage in following patches, why cant this be handled >>> internally as part of prep call? >>> >> As per design, i2c driver iterates over each message and submits to GPI >> where it creates TRE. Since it's per transfer, we need to create Lock and >> Unlock TRE based on first or last message. >> -- >>>> + bool first_msg; >>>> + bool last_msg; >>> >
On 18-12-24, 18:04, Mukesh Kumar Savaliya wrote: > Hi Vinod, Thanks ! I just saw your comments now as somehow it was going in > some other folder and didn't realize. > > On 12/4/2024 5:51 PM, Vinod Koul wrote: > > On 02-12-24, 16:13, Mukesh Kumar Savaliya wrote: > > > Thanks for the review comments Vinod ! > > > > > > On 12/2/2024 12:17 PM, Vinod Koul wrote: > > > > On 29-11-24, 20:13, Mukesh Kumar Savaliya wrote: > > > > > GSI DMA provides specific TREs(Transfer ring element) namely Lock and > > > > > Unlock TRE. It provides mutually exclusive access to I2C controller from > > > > > any of the processor(Apps,ADSP). Lock prevents other subsystems from > > > > > concurrently performing DMA transfers and avoids disturbance to data path. > > > > > Basically for shared I2C usecase, lock the SE(Serial Engine) for one of > > > > > the processor, complete the transfer, unlock the SE. > > > > > > > > > > Apply Lock TRE for the first transfer of shared SE and Apply Unlock > > > > > TRE for the last transfer. > > > > > > > > > > Also change MAX_TRE macro to 5 from 3 because of the two additional TREs. > > > > > > > > > > > > > ... > > > > > > > > > @@ -65,6 +65,9 @@ enum i2c_op { > > > > > * @rx_len: receive length for buffer > > > > > * @op: i2c cmd > > > > > * @muli-msg: is part of multi i2c r-w msgs > > > > > + * @shared_se: bus is shared between subsystems > > > > > + * @bool first_msg: use it for tracking multimessage xfer > > > > > + * @bool last_msg: use it for tracking multimessage xfer > > > > > */ > > > > > struct gpi_i2c_config { > > > > > u8 set_config; > > > > > @@ -78,6 +81,9 @@ struct gpi_i2c_config { > > > > > u32 rx_len; > > > > > enum i2c_op op; > > > > > bool multi_msg; > > > > > + bool shared_se; > > > > > > > > Looking at this why do you need this field? It can be internal to your > > > > i2c driver... Why not just set an enum for lock and use the values as > > > > lock/unlock/dont care and make the interface simpler. I see no reason to > > > > use three variables to communicate the info which can be handled in > > > > simpler way..? > > > > > > > Below was earlier reply to [PATCH V3, 2/4], please let me know if you have > > > any additional comment and need further clarifications. > > > > Looks like you misunderstood, the question is why do you need three > > variables to convey this info..? Use a single variable please > Yes, I think so. Please let me clarify. > First variable is a feature flag and it's required to be explicitly > mentioned by client (i2c/spi/etc) to GSI driver. > > Second and third, can be optimized to boolean so either first or last can be > passed. > > Please correct me or add simple change where you would like to make, i can > add that. I though we could do with a single and derive Also, please see 20241212041639.4109039-3-quic_mdalam@quicinc.com, folks from same company should talk together on same solutions, please converge and come up with a single proposal which works for both drivers
On 12/24/2024 3:28 PM, Vinod Koul wrote: > On 18-12-24, 18:04, Mukesh Kumar Savaliya wrote: >> Hi Vinod, Thanks ! I just saw your comments now as somehow it was going in >> some other folder and didn't realize. >> >> On 12/4/2024 5:51 PM, Vinod Koul wrote: >>> On 02-12-24, 16:13, Mukesh Kumar Savaliya wrote: >>>> Thanks for the review comments Vinod ! >>>> >>>> On 12/2/2024 12:17 PM, Vinod Koul wrote: >>>>> On 29-11-24, 20:13, Mukesh Kumar Savaliya wrote: >>>>>> GSI DMA provides specific TREs(Transfer ring element) namely Lock and >>>>>> Unlock TRE. It provides mutually exclusive access to I2C controller from >>>>>> any of the processor(Apps,ADSP). Lock prevents other subsystems from >>>>>> concurrently performing DMA transfers and avoids disturbance to data path. >>>>>> Basically for shared I2C usecase, lock the SE(Serial Engine) for one of >>>>>> the processor, complete the transfer, unlock the SE. >>>>>> >>>>>> Apply Lock TRE for the first transfer of shared SE and Apply Unlock >>>>>> TRE for the last transfer. >>>>>> >>>>>> Also change MAX_TRE macro to 5 from 3 because of the two additional TREs. >>>>>> >>>>> >>>>> ... >>>>> >>>>>> @@ -65,6 +65,9 @@ enum i2c_op { >>>>>> * @rx_len: receive length for buffer >>>>>> * @op: i2c cmd >>>>>> * @muli-msg: is part of multi i2c r-w msgs >>>>>> + * @shared_se: bus is shared between subsystems >>>>>> + * @bool first_msg: use it for tracking multimessage xfer >>>>>> + * @bool last_msg: use it for tracking multimessage xfer >>>>>> */ >>>>>> struct gpi_i2c_config { >>>>>> u8 set_config; >>>>>> @@ -78,6 +81,9 @@ struct gpi_i2c_config { >>>>>> u32 rx_len; >>>>>> enum i2c_op op; >>>>>> bool multi_msg; >>>>>> + bool shared_se; >>>>> >>>>> Looking at this why do you need this field? It can be internal to your >>>>> i2c driver... Why not just set an enum for lock and use the values as >>>>> lock/unlock/dont care and make the interface simpler. I see no reason to >>>>> use three variables to communicate the info which can be handled in >>>>> simpler way..? >>>>> >>>> Below was earlier reply to [PATCH V3, 2/4], please let me know if you have >>>> any additional comment and need further clarifications. >>> >>> Looks like you misunderstood, the question is why do you need three >>> variables to convey this info..? Use a single variable please >> Yes, I think so. Please let me clarify. >> First variable is a feature flag and it's required to be explicitly >> mentioned by client (i2c/spi/etc) to GSI driver. >> >> Second and third, can be optimized to boolean so either first or last can be >> passed. >> >> Please correct me or add simple change where you would like to make, i can >> add that. > > I though we could do with a single and derive > Sure, so as mentioned in the other crypto BAM patch probably dmaengine.h can hold flag and that can add support for lock/unlock similar to that patch. I just realized it from your shared patch. let me work internally with Md sadre and review. Thanks for the comment. > Also, please see 20241212041639.4109039-3-quic_mdalam@quicinc.com, folks > from same company should talk together on same solutions, please > converge and come up with a single proposal which works for both drivers > Sure
diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c index 52a7c8f2498f..c74417240012 100644 --- a/drivers/dma/qcom/gpi.c +++ b/drivers/dma/qcom/gpi.c @@ -2,6 +2,7 @@ /* * Copyright (c) 2017-2020, The Linux Foundation. All rights reserved. * Copyright (c) 2020, Linaro Limited + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved. */ #include <dt-bindings/dma/qcom-gpi.h> @@ -65,6 +66,14 @@ /* DMA TRE */ #define TRE_DMA_LEN GENMASK(23, 0) +/* Lock TRE */ +#define TRE_LOCK BIT(0) +#define TRE_MINOR_TYPE GENMASK(19, 16) +#define TRE_MAJOR_TYPE GENMASK(23, 20) + +/* Unlock TRE */ +#define TRE_UNLOCK BIT(8) + /* Register offsets from gpi-top */ #define GPII_n_CH_k_CNTXT_0_OFFS(n, k) (0x20000 + (0x4000 * (n)) + (0x80 * (k))) #define GPII_n_CH_k_CNTXT_0_EL_SIZE GENMASK(31, 24) @@ -516,7 +525,7 @@ struct gpii { bool ieob_set; }; -#define MAX_TRE 3 +#define MAX_TRE 5 struct gpi_desc { struct virt_dma_desc vd; @@ -1637,6 +1646,19 @@ static int gpi_create_i2c_tre(struct gchan *chan, struct gpi_desc *desc, struct gpi_tre *tre; unsigned int i; + /* create lock tre for first tranfser */ + if (i2c->shared_se && i2c->first_msg) { + tre = &desc->tre[tre_idx]; + tre_idx++; + + tre->dword[0] = 0; + tre->dword[1] = 0; + tre->dword[2] = 0; + tre->dword[3] = u32_encode_bits(1, TRE_LOCK); + tre->dword[3] |= u32_encode_bits(0, TRE_MINOR_TYPE); + tre->dword[3] |= u32_encode_bits(3, TRE_MAJOR_TYPE); + } + /* first create config tre if applicable */ if (i2c->set_config) { tre = &desc->tre[tre_idx]; @@ -1695,6 +1717,19 @@ static int gpi_create_i2c_tre(struct gchan *chan, struct gpi_desc *desc, tre->dword[3] |= u32_encode_bits(1, TRE_FLAGS_IEOT); } + /* Unlock tre for last transfer */ + if (i2c->shared_se && i2c->last_msg && i2c->op != I2C_READ) { + tre = &desc->tre[tre_idx]; + tre_idx++; + + tre->dword[0] = 0; + tre->dword[1] = 0; + tre->dword[2] = 0; + tre->dword[3] = u32_encode_bits(1, TRE_UNLOCK); + tre->dword[3] |= u32_encode_bits(1, TRE_MINOR_TYPE); + tre->dword[3] |= u32_encode_bits(3, TRE_MAJOR_TYPE); + } + for (i = 0; i < tre_idx; i++) dev_dbg(dev, "TRE:%d %x:%x:%x:%x\n", i, desc->tre[i].dword[0], desc->tre[i].dword[1], desc->tre[i].dword[2], desc->tre[i].dword[3]); diff --git a/include/linux/dma/qcom-gpi-dma.h b/include/linux/dma/qcom-gpi-dma.h index 6680dd1a43c6..8589c711afae 100644 --- a/include/linux/dma/qcom-gpi-dma.h +++ b/include/linux/dma/qcom-gpi-dma.h @@ -65,6 +65,9 @@ enum i2c_op { * @rx_len: receive length for buffer * @op: i2c cmd * @muli-msg: is part of multi i2c r-w msgs + * @shared_se: bus is shared between subsystems + * @bool first_msg: use it for tracking multimessage xfer + * @bool last_msg: use it for tracking multimessage xfer */ struct gpi_i2c_config { u8 set_config; @@ -78,6 +81,9 @@ struct gpi_i2c_config { u32 rx_len; enum i2c_op op; bool multi_msg; + bool shared_se; + bool first_msg; + bool last_msg; }; #endif /* QCOM_GPI_DMA_H */
GSI DMA provides specific TREs(Transfer ring element) namely Lock and Unlock TRE. It provides mutually exclusive access to I2C controller from any of the processor(Apps,ADSP). Lock prevents other subsystems from concurrently performing DMA transfers and avoids disturbance to data path. Basically for shared I2C usecase, lock the SE(Serial Engine) for one of the processor, complete the transfer, unlock the SE. Apply Lock TRE for the first transfer of shared SE and Apply Unlock TRE for the last transfer. Also change MAX_TRE macro to 5 from 3 because of the two additional TREs. Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> --- drivers/dma/qcom/gpi.c | 37 +++++++++++++++++++++++++++++++- include/linux/dma/qcom-gpi-dma.h | 6 ++++++ 2 files changed, 42 insertions(+), 1 deletion(-)