| Message ID | 20250124105309.295769-1-quic_vdadhani@quicinc.com |
|---|---|
| Headers | show |
| Series | Add support to load QUP SE firmware from | expand |
On 24/01/2025 11:53, Viken Dadhaniya wrote: > Data transfer mode is fixed by TrustZone (TZ), which currently restricts > developers from modifying the transfer mode from the APPS side. > > Document the 'qcom,xfer-mode' properties to select the data transfer mode, > either GPI DMA (Generic Packet Interface) or non-GPI mode (PIO/CPU DMA). > > UART controller can operate in one of two modes based on the > 'qcom,xfer-mode' property, and the firmware is loaded accordingly. > > Co-developed-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> > Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> > Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com> > --- > > v1 -> v2: > > - Drop 'qcom,load-firmware' property and add 'firmware-name' property in > qup common driver. > - Update commit log. > > v1 Link: https://lore.kernel.org/linux-kernel/20241204150326.1470749-4-quic_vdadhani@quicinc.com/ > --- > --- > .../devicetree/bindings/serial/qcom,serial-geni-qcom.yaml | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml > index dd33794b3534..383773b32e47 100644 > --- a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml > +++ b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml > @@ -56,6 +56,13 @@ properties: > reg: > maxItems: 1 > > + qcom,xfer-mode: > + description: Set the value to 1 for non-GPI (FIFO/CPU DMA) mode and 3 for GPI DMA mode. > + The default mode is FIFO. > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [1, 3] > + > + Just one blank line, but anyway, this property should not be in three places. Do you really expect that each of serial engines within one GeniQUP will be configured differently by TZ? Best regards, Krzysztof
On 27.01.2025 5:24 PM, Krzysztof Kozlowski wrote: > On 27/01/2025 15:27, Dmitry Baryshkov wrote: >> On Mon, Jan 27, 2025 at 08:02:12AM +0100, Krzysztof Kozlowski wrote: >>> On 24/01/2025 11:53, Viken Dadhaniya wrote: >>>> Data transfer mode is fixed by TrustZone (TZ), which currently restricts >>>> developers from modifying the transfer mode from the APPS side. >>>> >>>> Document the 'qcom,xfer-mode' properties to select the data transfer mode, >>>> either GPI DMA (Generic Packet Interface) or non-GPI mode (PIO/CPU DMA). >>>> >>>> UART controller can operate in one of two modes based on the >>>> 'qcom,xfer-mode' property, and the firmware is loaded accordingly. >>>> >>>> Co-developed-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> >>>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> >>>> Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com> >>>> --- >>>> >>>> v1 -> v2: >>>> >>>> - Drop 'qcom,load-firmware' property and add 'firmware-name' property in >>>> qup common driver. >>>> - Update commit log. >>>> >>>> v1 Link: https://lore.kernel.org/linux-kernel/20241204150326.1470749-4-quic_vdadhani@quicinc.com/ >>>> --- >>>> --- >>>> .../devicetree/bindings/serial/qcom,serial-geni-qcom.yaml | 8 ++++++++ >>>> 1 file changed, 8 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml >>>> index dd33794b3534..383773b32e47 100644 >>>> --- a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml >>>> +++ b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml >>>> @@ -56,6 +56,13 @@ properties: >>>> reg: >>>> maxItems: 1 >>>> >>>> + qcom,xfer-mode: >>>> + description: Set the value to 1 for non-GPI (FIFO/CPU DMA) mode and 3 for GPI DMA mode. >>>> + The default mode is FIFO. >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + enum: [1, 3] >>>> + >>>> + >>> >>> Just one blank line, but anyway, this property should not be in three >>> places. Do you really expect that each of serial engines within one >>> GeniQUP will be configured differently by TZ? >> >> Yes, each SE is configured separately and it's quite frequent when >> different SEs have different DMA configuration. > > Well, I checked at sm8550 and sm8650 and each pair of SE - which shares > resources - has the same DMAs, so I would not call it frequent. Care to > bring an example where same serial engines have different DMAs and > different TZ? We do not talk about single QUP. > > Anyway, if you need property per node, this has to be shared schema. I'd rather ask a different question.. Is there *any* reason to not use DMA for protocols that support it? Konrad
On 27.01.2025 6:50 PM, Konrad Dybcio wrote: > On 27.01.2025 5:24 PM, Krzysztof Kozlowski wrote: >> On 27/01/2025 15:27, Dmitry Baryshkov wrote: >>> On Mon, Jan 27, 2025 at 08:02:12AM +0100, Krzysztof Kozlowski wrote: >>>> On 24/01/2025 11:53, Viken Dadhaniya wrote: >>>>> Data transfer mode is fixed by TrustZone (TZ), which currently restricts >>>>> developers from modifying the transfer mode from the APPS side. >>>>> >>>>> Document the 'qcom,xfer-mode' properties to select the data transfer mode, >>>>> either GPI DMA (Generic Packet Interface) or non-GPI mode (PIO/CPU DMA). >>>>> >>>>> UART controller can operate in one of two modes based on the >>>>> 'qcom,xfer-mode' property, and the firmware is loaded accordingly. >>>>> >>>>> Co-developed-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> >>>>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> >>>>> Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com> >>>>> --- >>>>> >>>>> v1 -> v2: >>>>> >>>>> - Drop 'qcom,load-firmware' property and add 'firmware-name' property in >>>>> qup common driver. >>>>> - Update commit log. >>>>> >>>>> v1 Link: https://lore.kernel.org/linux-kernel/20241204150326.1470749-4-quic_vdadhani@quicinc.com/ >>>>> --- >>>>> --- >>>>> .../devicetree/bindings/serial/qcom,serial-geni-qcom.yaml | 8 ++++++++ >>>>> 1 file changed, 8 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml >>>>> index dd33794b3534..383773b32e47 100644 >>>>> --- a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml >>>>> +++ b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml >>>>> @@ -56,6 +56,13 @@ properties: >>>>> reg: >>>>> maxItems: 1 >>>>> >>>>> + qcom,xfer-mode: >>>>> + description: Set the value to 1 for non-GPI (FIFO/CPU DMA) mode and 3 for GPI DMA mode. >>>>> + The default mode is FIFO. >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + enum: [1, 3] >>>>> + >>>>> + >>>> >>>> Just one blank line, but anyway, this property should not be in three >>>> places. Do you really expect that each of serial engines within one >>>> GeniQUP will be configured differently by TZ? >>> >>> Yes, each SE is configured separately and it's quite frequent when >>> different SEs have different DMA configuration. >> >> Well, I checked at sm8550 and sm8650 and each pair of SE - which shares >> resources - has the same DMAs, so I would not call it frequent. Care to >> bring an example where same serial engines have different DMAs and >> different TZ? We do not talk about single QUP. >> >> Anyway, if you need property per node, this has to be shared schema. > > I'd rather ask a different question.. Is there *any* reason to not use > DMA for protocols that support it? If not, we can simplify this to: xfer_mode = protocol == PROTOCOL_UART ? XFER_FIFO : XFER_DMA Konrad
On 29/01/2025 03:21, Dmitry Baryshkov wrote: > On Mon, Jan 27, 2025 at 05:24:21PM +0100, Krzysztof Kozlowski wrote: >> On 27/01/2025 15:27, Dmitry Baryshkov wrote: >>> On Mon, Jan 27, 2025 at 08:02:12AM +0100, Krzysztof Kozlowski wrote: >>>> On 24/01/2025 11:53, Viken Dadhaniya wrote: >>>>> Data transfer mode is fixed by TrustZone (TZ), which currently restricts >>>>> developers from modifying the transfer mode from the APPS side. >>>>> >>>>> Document the 'qcom,xfer-mode' properties to select the data transfer mode, >>>>> either GPI DMA (Generic Packet Interface) or non-GPI mode (PIO/CPU DMA). >>>>> >>>>> UART controller can operate in one of two modes based on the >>>>> 'qcom,xfer-mode' property, and the firmware is loaded accordingly. >>>>> >>>>> Co-developed-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> >>>>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> >>>>> Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com> >>>>> --- >>>>> >>>>> v1 -> v2: >>>>> >>>>> - Drop 'qcom,load-firmware' property and add 'firmware-name' property in >>>>> qup common driver. >>>>> - Update commit log. >>>>> >>>>> v1 Link: https://lore.kernel.org/linux-kernel/20241204150326.1470749-4-quic_vdadhani@quicinc.com/ >>>>> --- >>>>> --- >>>>> .../devicetree/bindings/serial/qcom,serial-geni-qcom.yaml | 8 ++++++++ >>>>> 1 file changed, 8 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml >>>>> index dd33794b3534..383773b32e47 100644 >>>>> --- a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml >>>>> +++ b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml >>>>> @@ -56,6 +56,13 @@ properties: >>>>> reg: >>>>> maxItems: 1 >>>>> >>>>> + qcom,xfer-mode: >>>>> + description: Set the value to 1 for non-GPI (FIFO/CPU DMA) mode and 3 for GPI DMA mode. >>>>> + The default mode is FIFO. >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + enum: [1, 3] >>>>> + >>>>> + >>>> >>>> Just one blank line, but anyway, this property should not be in three >>>> places. Do you really expect that each of serial engines within one >>>> GeniQUP will be configured differently by TZ? >>> >>> Yes, each SE is configured separately and it's quite frequent when >>> different SEs have different DMA configuration. >> >> Well, I checked at sm8550 and sm8650 and each pair of SE - which shares >> resources - has the same DMAs, so I would not call it frequent. Care to >> bring an example where same serial engines have different DMAs and >> different TZ? We do not talk about single QUP. > > Well, I don't have access to the latest sm8550 / sm8650 devcfg sources. > I checked the RB5 ones. As far as I understand out of 14 enabled SEs > only two are configured for the GSI DMA, others should use FIFO / SE > DMA. Same applies to the SM8250 MTP devices. Checking the RB1 / RB2 > setup also shows 3 out of 6 SEs being set for GSI. I think selecting GSI DMA is only for devices needs high speed streaming to the device, like the touch screen, using GSI DMA for random small access is a non-sense. But the thing is, in the TZ world the configuration was static so we had no choice of using GSI DMA when configured, but now we have the choice so we could totally reconfigure the SE with the transfer type (FIFO, SE DMA or GSI DMA) as runtime and drop this attribute. So instead of hardcoding this, add a way to dynamically select either of the 3 transfer types when firmware can be loaded from HLOS. Neil > >> >> Anyway, if you need property per node, this has to be shared schema. >> >> Best regards, >> Krzysztof >
On 09/02/2025 11:11, Viken Dadhaniya wrote: >>>>>> >>>>>> Just one blank line, but anyway, this property should not be in three >>>>>> places. Do you really expect that each of serial engines within one >>>>>> GeniQUP will be configured differently by TZ? >>>>> >>>>> Yes, each SE is configured separately and it's quite frequent when >>>>> different SEs have different DMA configuration. >>>> >>>> Well, I checked at sm8550 and sm8650 and each pair of SE - which shares >>>> resources - has the same DMAs, so I would not call it frequent. Care to >>>> bring an example where same serial engines have different DMAs and >>>> different TZ? We do not talk about single QUP. >>> >>> Well, I don't have access to the latest sm8550 / sm8650 devcfg sources. >>> I checked the RB5 ones. As far as I understand out of 14 enabled SEs >>> only two are configured for the GSI DMA, others should use FIFO / SE >>> DMA. Same applies to the SM8250 MTP devices. Checking the RB1 / RB2 >>> setup also shows 3 out of 6 SEs being set for GSI. >> >> I think selecting GSI DMA is only for devices needs high speed streaming >> to the >> device, like the touch screen, using GSI DMA for random small access is >> a non-sense. >> >> But the thing is, in the TZ world the configuration was static so we had >> no choice >> of using GSI DMA when configured, but now we have the choice so we could >> totally >> reconfigure the SE with the transfer type (FIFO, SE DMA or GSI DMA) as >> runtime and >> drop this attribute. >> >> So instead of hardcoding this, add a way to dynamically select either of >> the 3 >> transfer types when firmware can be loaded from HLOS. >> >> Neil >> > > Yes, GSI DMA mode is required for specific use cases only. > > Dynamically switching from GSI mode to non-GSI mode is neither possible > nor useful. For each SE, the use case is fixed, and based on the use > case, the developer can choose the mode via the device tree property. No, it cannot. Do not describe downstream as something set in stone. Best regards, Krzysztof
On 2/9/2025 3:49 PM, Krzysztof Kozlowski wrote: > On 09/02/2025 11:11, Viken Dadhaniya wrote: >>>>>>> >>>>>>> Just one blank line, but anyway, this property should not be in three >>>>>>> places. Do you really expect that each of serial engines within one >>>>>>> GeniQUP will be configured differently by TZ? >>>>>> >>>>>> Yes, each SE is configured separately and it's quite frequent when >>>>>> different SEs have different DMA configuration. >>>>> >>>>> Well, I checked at sm8550 and sm8650 and each pair of SE - which shares >>>>> resources - has the same DMAs, so I would not call it frequent. Care to >>>>> bring an example where same serial engines have different DMAs and >>>>> different TZ? We do not talk about single QUP. >>>> >>>> Well, I don't have access to the latest sm8550 / sm8650 devcfg sources. >>>> I checked the RB5 ones. As far as I understand out of 14 enabled SEs >>>> only two are configured for the GSI DMA, others should use FIFO / SE >>>> DMA. Same applies to the SM8250 MTP devices. Checking the RB1 / RB2 >>>> setup also shows 3 out of 6 SEs being set for GSI. >>> >>> I think selecting GSI DMA is only for devices needs high speed streaming >>> to the >>> device, like the touch screen, using GSI DMA for random small access is >>> a non-sense. >>> >>> But the thing is, in the TZ world the configuration was static so we had >>> no choice >>> of using GSI DMA when configured, but now we have the choice so we could >>> totally >>> reconfigure the SE with the transfer type (FIFO, SE DMA or GSI DMA) as >>> runtime and >>> drop this attribute. >>> >>> So instead of hardcoding this, add a way to dynamically select either of >>> the 3 >>> transfer types when firmware can be loaded from HLOS. >>> >>> Neil >>> >> To exactly summarize: GSI DMA and CPU DMA are mostly same performance unless we have multiprocessor systems queuing the transfers together. GSI DMA to be used when multiprocessor systems (Application processor/TZ/modem/ADSP subsystems) has use cases together. If only single subsystem or processor is using CPU DMA mode should be used. Hardware guidance and configuration suggest that CPU DMA and FIFO can be switched but GSI DMA. CPI DMA : Doesn't work with multiple subsystems. FIFO : same as CPU DMA but < 64 bytes (FIFO_SIZE) GSI_DMA: Work with multiple subsystems Overall, there will be GSI and non-GSI modes. Dynamic switching is only required in PIO mode (FIFO and CPU DMA). >> Yes, GSI DMA mode is required for specific use cases only. >> >> Dynamically switching from GSI mode to non-GSI mode is neither possible >> nor useful. For each SE, the use case is fixed, and based on the use >> case, the developer can choose the mode via the device tree property. > > No, it cannot. Do not describe downstream as something set in stone. Sorry, I am not referring to downstream but rather to the general process of mode selection. Please let us know if you need more clarity. > > Best regards, > Krzysztof
In Qualcomm SoCs, firmware loading for Serial Engines (SE) in the QUP hardware has traditionally been managed by TrustZone (TZ). This setup handled Serial Engines(SE) assignments and access control permissions, ensuring a high level of security but limiting flexibility and accessibility. This limitation poses a significant challenge for developers who need more flexibility to enable any protocol on any of the SEs within the QUP hardware. To address this, we are introducing a change that opens the firmware loading mechanism to the Linux environment. This enhancement increases flexibility and allows for more streamlined and efficient management. We can now handle SE assignments and access control permissions directly within Linux, eliminating the dependency on TZ. We propose an alternative method for firmware loading and SE ownership/transfer mode configuration based on device tree configuration. This method does not rely on other execution environments, making it accessible to all developers. For SEs used prior to the kernel, their firmware will be loaded by the respective image drivers (e.g., Debug UART, Secure or trusted SE). Additionally, the GSI firmware, which is common to all SEs per QUPV3 core, will not be loaded by Linux driver but TZ only. At the kernel level, only the SE protocol driver should load the respective protocol firmware. --- v1 -> v2: - Drop the qcom,load-firmware property. - Remove the fixed firmware path. - Add the 'firmware-name' property in the QUP common driver. - Add logic to read the firmware path from the device tree. - Resolve kernel test robot warnings. - Update the 'qcom,xfer-mode' property description. v1 Link: https://lore.kernel.org/linux-kernel/20241204150326.1470749-1-quic_vdadhani@quicinc.com/ --- Viken Dadhaniya (8): dt-bindings: qcom: geni-se: Add 'firmware-name' property for firmware loading dt-bindings: i2c: qcom,i2c-geni: Add support for selecting data transfer mode spi: dt-bindings: Add support for selecting data transfer mode dt-bindings: serial: Add support for selecting data transfer mode soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem i2c: qcom-geni: Load i2c qup Firmware from linux side spi: geni-qcom: Load spi qup Firmware from linux side serial: qcom-geni: Load UART qup Firmware from linux side .../bindings/i2c/qcom,i2c-geni-qcom.yaml | 7 + .../serial/qcom,serial-geni-qcom.yaml | 8 + .../bindings/soc/qcom/qcom,geni-se.yaml | 5 + .../bindings/spi/qcom,spi-geni-qcom.yaml | 7 + drivers/i2c/busses/i2c-qcom-geni.c | 7 +- drivers/soc/qcom/qcom-geni-se.c | 444 ++++++++++++++++++ drivers/spi/spi-geni-qcom.c | 7 +- drivers/tty/serial/qcom_geni_serial.c | 7 +- include/linux/soc/qcom/geni-se.h | 17 + include/linux/soc/qcom/qup-fw-load.h | 179 +++++++ 10 files changed, 682 insertions(+), 6 deletions(-) create mode 100644 include/linux/soc/qcom/qup-fw-load.h