On 7/19/2023 3:39 AM, Sudeep Holla wrote:
On Tue, Jul 18, 2023 at 09:08:32AM -0700, Nikunj Kela wrote:
Introduce compatible "qcom,scmi-hvc-shmem" for SCMI
transport channel for Qualcomm virtual platforms.
The compatible mandates a shared memory channel.
Signed-off-by: Nikunj Kela <quic_nkela@xxxxxxxxxxx>
---
.../bindings/firmware/arm,scmi.yaml | 69 +++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index b138f3d23df8..605b1e997a85 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -45,6 +45,9 @@ properties:
- description: SCMI compliant firmware with OP-TEE transport
items:
- const: linaro,scmi-optee
+ - description: SCMI compliant firmware with Qualcomm hvc/shmem transport
+ items:
+ - const: qcom,scmi-hvc-shmem
interrupts:
description:
@@ -321,6 +324,16 @@ else:
required:
- linaro,optee-channel-id
+ else:
+ if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,scmi-hvc-shmem
+ then:
+ required:
+ - shmem
+
Since this was done after we merged the support recently for extension of
SMC/HVC, I need the reason(s) why this can't be used and based on the response
this is new change so it can't be because there is a product already
supporting this. So for now, NACK until I get the response for these.
Our hypervisor deals with objects and uses object-ids to identify them.
The hvc doorbell object is independent of the shmem object created by
hypervisor. Hypervisor treats them independently. With the patch you
mentioned, hypervisor need to create an association between the doorbell
object and shmem object which will make it SCMI specific change in
hypervisor. Hypervisor doesn't really care if doorbell is for SCMI or
for other purposes hence we are adding this new driver so it can work
with our hypervisor ABIs specification.
