On 12/5/2024 9:29 PM, Konrad Dybcio wrote:
On 4.12.2024 4:03 PM, Viken Dadhaniya wrote:
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.
I think this is a great opportunity to rethink the SE node in general.
Currently, for each supported protocol, we create a new node that
differs in (possibly) interconnects and pinctrl states. These are really
defined per-SE however and we can programmatically determine which ones
are relevant.
With the growing number of protocols supported, we would have to add
20+ nodes in some cases for each one of them. I think a good one would
look like:
geni_se10: serial-engine@abcdef {
compatible = "qcom,geni-se";
reg
clocks
power-domains
interconnects
...
status
geni_se10_i2c: i2c {
// i2c-controller.yaml
};
geni_se10_spi: spi {
// spi-controller.yaml
};
...
}
Or maybe even get rid of the subnodes and restrict that to a single
se-protocol = <SE_PROTOCOL_xyz> property, if the bindings folks agree.
We could extend the DMA APIs to dynamically determine the protocol
ID and get rid of hardcoding it.
And then we could spawn an instance of the spi, i2c, etc. driver from
the GENI SE driver.
Konrad
Thanks for the advice.
The above design suggested by you may add more code change into protocol
driver as well as common driver.
I am really interested to discuss more options and come to better
design. let me discuss with you on this.
Also do you think we can push the re-design of DTSI nodes as separate
change instead of clubbing with this FW load change ?
