[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d1d98ad5-73f0-e42d-70ef-804c945f70cc@quicinc.com>
Date: Wed, 19 Jul 2023 06:58:45 -0700
From: Nikunj Kela <quic_nkela@...cinc.com>
To: Sudeep Holla <sudeep.holla@....com>
CC: <cristian.marussi@....com>, <robh+dt@...nel.org>,
<krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
<agross@...nel.org>, <andersson@...nel.org>,
<konrad.dybcio@...aro.org>, <linux-arm-kernel@...ts.infradead.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: arm: Add qcom specific hvc transport for
SCMI
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@...cinc.com>
>> ---
>> .../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.
Powered by blists - more mailing lists