[PATCH v3 01/25] dt-bindings: soc: qcom: Add bindings for APR bus
Srinivas Kandagatla
srinivas.kandagatla at linaro.org
Wed Feb 14 01:13:23 PST 2018
Thanks for the review,
On 13/02/18 23:12, Rob Herring wrote:
> On Tue, Feb 13, 2018 at 04:58:13PM +0000, srinivas.kandagatla at linaro.org wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
>>
>> This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router)
>> bus driver. This bus is used for communicating with DSP which provides
>> audio and various other services to cpu.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
>> ---
>> .../devicetree/bindings/soc/qcom/qcom,apr.txt | 83 ++++++++++++++++++++++
>> 1 file changed, 83 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
>>
>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
>> new file mode 100644
>> index 000000000000..1b95fbfed348
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
>> @@ -0,0 +1,83 @@
>> +Qualcomm APR (Asynchronous Packet Router) binding
>> +
>> +This binding describes the Qualcomm APR. APR is a IPC protocol for
>> +communication between Application processor and QDSP. APR is mainly
>> +used for audio/voice services on the QDSP.
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: must be "qcom,apr-v<VERSION-NUMBER>", example "qcom,apr-v2"
>> +
>> +- qcom,apr-dest-domain-id
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: Destination processor ID.
>> + Possible values are :
>> + 1 - APR simulator
>> + 2 - PC
>> + 3 - MODEM
>> + 4 - ADSP
>> + 5 - APPS
>> + 6 - MODEM2
>> + 7 - APPS2
>> +
>> += APR SERVICES
>> +Each subnode of the APR node can represent service tied to this apr. The name
>> +of the nodes are not important. The properties of these nodes are defined
>> +by the individual bindings for the specific service
>> +- but must contain the following property:
>> +
...
>> += APR DEVICES:
>> +Each subnode of the APR node can represent devices tied to this apr, like
>> +sound-card. The properties of these nodes are defined by the individual
>> +bindings for the specific device.
>
> It's not a good design generally to mix different types of nodes at one
> level.
I agree, may be I can split the services and devices into different
subnodes like below, which should avoid mixing different types of nodes.
Does this sound good to you?
apr {
compatible = "qcom,apr-v2";
qcom,smd-channels = "apr_audio_svc";
qcom,apr-dest-domain-id = <APR_DOMAIN_ADSP>;
apr-services {
q6core {
qcom,apr-svc-name = "CORE";
qcom,apr-svc-id = <APR_SVC_ADSP_CORE>;
compatible = "qcom,q6core";
};
q6afe: q6afe {
compatible = "qcom,q6afe";
qcom,apr-svc-name = "AFE";
qcom,apr-svc-id = <APR_SVC_AFE>;
#sound-dai-cells = <1>;
};
q6asm: q6asm {
compatible = "qcom,q6asm";
qcom,apr-svc-name = "ASM";
qcom,apr-svc-id = <APR_SVC_ASM>;
#sound-dai-cells = <1>;
};
q6adm: q6adm {
compatible = "qcom,q6adm";
qcom,apr-svc-name = "ADM";
qcom,apr-svc-id = <APR_SVC_ADM>;
#sound-dai-cells = <0>;
};
};
apr-devices {
audio {
compatible = "qcom,msm8996-snd-card";
...
};
};
};
>
>> +
>> += EXAMPLE
>> +The following example represents a QDSP based sound card on a MSM8996 device
>> +which uses apr as communication between Apps and QDSP.
>> +
>> + apr {
>> + compatible = "qcom,apr-v2";
>> + qcom,smd-channels = "apr_audio_svc";
>> + qcom,apr-dest-domain-id = <APR_DOMAIN_ADSP>;
>> +
>> + q6core {
>> + compatible = "qcom,q6core";
>> + qcom,apr-svc-name = "CORE";
>> + qcom,apr-svc-id = <APR_SVC_ADSP_CORE>;
>> + };
>> +
>> + q6afe {
>> + compatible = "qcom,q6afe";
>> + qcom,apr-svc-name = "AFE";
>> + qcom,apr-svc-id = <APR_SVC_AFE>;
>> + };
>> +
>> + audio {
>> + compatible = "qcom,msm8996-snd-card";
>> + ...
>> + };
>> + };
>> --
>> 2.15.1
>>
More information about the linux-arm-kernel
mailing list