October 2022 - Alsa-devel - mailman.alsa-project.org

[PATCH 0/2] sound: dice: Firestudio Mobile
by George Hilliard 16 Oct '22

16 Oct '22

This short series adds a configuration block for the Firestudio Mobile I just acquired. Very similar to the Firestudio, but a lower port count. My understanding is that the Low, Medium, and High speeds refer to 48kHz, 96kHz, and 192kHz sample rates, of which only the first two are supported by this hardware line. Please correct me if this is not correct. Thanks!

2 4

[PATCH v2] ASoC: qcom: lpass-cpu: mark HDMI TX registers as volatile
by Srinivasa Rao Mandadapu 15 Oct '22

15 Oct '22

Update HDMI volatile registers list as DMA, Channel Selection registers, vbit control registers are being reflected by hardware DP port disconnection. This update is required to fix no display and no sound issue observed after reconnecting TAMA/SANWA DP cables. Once DP cable is unplugged, DMA control registers are being reset by hardware, however at second plugin, new dma control values does not updated to the dma hardware registers since new register value and cached values at the time of first plugin are same. Fixes: 7cb37b7bd0d3 ("ASoC: qcom: Add support for lpass hdmi driver") Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> Reported-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com> --- sound/soc/qcom/lpass-cpu.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index 8a56f38..99a3b44 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -782,10 +782,18 @@ static bool lpass_hdmi_regmap_volatile(struct device *dev, unsigned int reg) return true; if (reg == LPASS_HDMI_TX_LEGACY_ADDR(v)) return true; + if (reg == LPASS_HDMI_TX_VBIT_CTL_ADDR(v)) + return true; for (i = 0; i < v->hdmi_rdma_channels; ++i) { if (reg == LPAIF_HDMI_RDMACURR_REG(v, i)) return true; + if (reg == LPASS_HDMI_TX_DMA_ADDR(v, i)) + return true; + if (reg == LPASS_HDMI_TX_CH_LSB_ADDR(v, i)) + return true; + if (reg == LPASS_HDMI_TX_CH_MSB_ADDR(v, i)) + return true; } return false; } -- 2.7.4

3 3

[RESEND] dt-bindings: soundwire: Convert text file to yaml format
by Srinivasa Rao Mandadapu 15 Oct '22

15 Oct '22

Update soundwire bindings with yaml formats. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> Co-developed-by: Ratna Deepthi Kudaravalli <quic_rkudarv(a)quicinc.com> Signed-off-by: Ratna Deepthi Kudaravalli <quic_rkudarv(a)quicinc.com> --- .../devicetree/bindings/soundwire/qcom,sdw.txt | 214 --------------------- .../devicetree/bindings/soundwire/qcom,sdw.yaml | 185 ++++++++++++++++++ 2 files changed, 185 insertions(+), 214 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soundwire/qcom,sdw.txt create mode 100644 Documentation/devicetree/bindings/soundwire/qcom,sdw.yaml diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt deleted file mode 100644 index c85c257..0000000 --- a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt +++ /dev/null @@ -1,214 +0,0 @@ -Qualcomm SoundWire Controller Bindings - - -This binding describes the Qualcomm SoundWire Controller along with its -board specific bus parameters. - -- compatible: - Usage: required - Value type: <stringlist> - Definition: must be "qcom,soundwire-v<MAJOR>.<MINOR>.<STEP>", - Example: - "qcom,soundwire-v1.3.0" - "qcom,soundwire-v1.5.0" - "qcom,soundwire-v1.5.1" - "qcom,soundwire-v1.6.0" -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: the base address and size of SoundWire controller - address space. - -- interrupts: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify the SoundWire Controller core and optional - wake IRQ - -- interrupt-names: - Usage: Optional - Value type: boolean - Value type: <stringlist> - Definition: should be "core" for core and "wakeup" for wake interrupt. - -- wakeup-source: - Usage: Optional - Value type: boolean - Definition: should specify if SoundWire Controller is wake up capable. - -- clock-names: - Usage: required - Value type: <stringlist> - Definition: should be "iface" for SoundWire Controller interface clock - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify the SoundWire Controller interface clock - -- #sound-dai-cells: - Usage: required - Value type: <u32> - Definition: must be 1 for digital audio interfaces on the controller. - -- qcom,dout-ports: - Usage: required - Value type: <u32> - Definition: must be count of data out ports - -- qcom,din-ports: - Usage: required - Value type: <u32> - Definition: must be count of data in ports - -- qcom,ports-offset1: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify payload transport window offset1 of each - data port. Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-offset2: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify payload transport window offset2 of each - data port. Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-sinterval-low: - Usage: required - Value type: <prop-encoded-array> - Definition: should be sample interval low of each data port. - Out ports followed by In ports. Used for Sample Interval - calculation. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-word-length: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be size of payload channel sample. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-block-pack-mode: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be 0 or 1 to indicate the block packing mode. - 0 to indicate Blocks are per Channel - 1 to indicate Blocks are per Port. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-block-group-count: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be in range 1 to 4 to indicate how many sample - intervals are combined into a payload. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-lane-control: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be in range 0 to 7 to identify which data lane - the data port uses. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-hstart: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be number identifying lowerst numbered coloum in - SoundWire Frame, i.e. left edge of the Transport sub-frame - for each port. Values between 0 and 15 are valid. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-hstop: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be number identifying highest numbered coloum in - SoundWire Frame, i.e. the right edge of the Transport - sub-frame for each port. Values between 0 and 15 are valid. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,dports-type: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be one of the following types - 0 for reduced port - 1 for simple ports - 2 for full port - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- reset: - Usage: optional - Value type: <prop-encoded-array> - Definition: Should specify the SoundWire audio CSR reset controller interface, - which is required for SoundWire version 1.6.0 and above. - -- reset-names: - Usage: optional - Value type: <stringlist> - Definition: should be "swr_audio_cgcr" for SoundWire audio CSR reset - controller interface. - -Note: - More Information on detail of encoding of these fields can be -found in MIPI Alliance SoundWire 1.0 Specifications. - -= SoundWire devices -Each subnode of the bus represents SoundWire device attached to it. -The properties of these nodes are defined by the individual bindings. - -= EXAMPLE -The following example represents a SoundWire controller on DB845c board -which has controller integrated inside WCD934x codec on SDM845 SoC. - -soundwire: soundwire@c85 { - compatible = "qcom,soundwire-v1.3.0"; - reg = <0xc85 0x20>; - interrupts = <20 IRQ_TYPE_EDGE_RISING>; - clocks = <&wcc>; - clock-names = "iface"; - resets = <&lpass_audiocc LPASS_AUDIO_SWR_TX_CGCR>; - reset-names = "swr_audio_cgcr"; - #sound-dai-cells = <1>; - qcom,dports-type = <0>; - qcom,dout-ports = <6>; - qcom,din-ports = <2>; - qcom,ports-sinterval-low = /bits/ 8 <0x07 0x1F 0x3F 0x7 0x1F 0x3F 0x0F 0x0F>; - qcom,ports-offset1 = /bits/ 8 <0x01 0x02 0x0C 0x6 0x12 0x0D 0x07 0x0A >; - qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x1F 0x00 0x00 0x1F 0x00 0x00>; - - /* Left Speaker */ - left{ - .... - }; - - /* Right Speaker */ - right{ - .... - }; -}; diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.yaml b/Documentation/devicetree/bindings/soundwire/qcom,sdw.yaml new file mode 100644 index 0000000..bf8f6c1 --- /dev/null +++ b/Documentation/devicetree/bindings/soundwire/qcom,sdw.yaml @@ -0,0 +1,185 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soundwire/qcom,sdw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SoundWire Controller + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> + - Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> + +description: + This binding describes the Qualcomm SoundWire controller along with its + board specific bus parameters. + +properties: + compatible: + enum: + - qcom,soundwire-v1.3.0 + - qcom,soundwire-v1.5.0 + - qcom,soundwire-v1.5.1 + - qcom,soundwire-v1.6.0 + + reg: + items: + - description: the base address and size of SoundWire controller + address space. + + interrupts: + items: + - description: specify the SoundWire controller core and optional + wake IRQ. + + interrupt-names: + items: + - const: wakeup + + clocks: + items: + - description: iface clock + + clock-names: + items: + - const: iface + + resets: + items: + - description: SWR_AUDIO_CGCR RESET + + reset-names: + items: + - const: swr_audio_cgcr + + '#sound-dai-cells': + const: 1 + + '#address-cells': + const: 2 + + '#size-cells': + const: 0 + + qcom,din-ports: + $ref: /schemas/types.yaml#/definitions/uint32 + description: count of data in ports + + qcom,dout-ports: + $ref: /schemas/types.yaml#/definitions/uint32 + description: count of data out ports + + qcom,ports-word-length: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: size of payload channel sample. + minItems: 5 + maxItems: 5 + + qcom,ports-sinterval-low: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: sample interval low of each data port. + minItems: 5 + maxItems: 5 + + qcom,ports-offset1: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: payload transport window offset1 of each data port. + minItems: 5 + maxItems: 5 + + qcom,ports-offset2: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: payload transport window offset2 of each data port. + minItems: 5 + maxItems: 5 + + qcom,ports-lane-control: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: identify which data lane the data port uses. + minItems: 5 + maxItems: 5 + + qcom,ports-block-pack-mode: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: indicate the block packing mode. + minItems: 5 + maxItems: 5 + + qcom,ports-hstart: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: identifying lowerst numbered coloum in SoundWire frame. + minItems: 5 + maxItems: 5 + + qcom,ports-hstop: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: identifying highest numbered coloum in SoundWire frame. + minItems: 5 + maxItems: 5 + + qcom,ports-block-group-count: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: indicate how many sample intervals are combined into a payload. + minItems: 5 + maxItems: 5 + +required: + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - resets + - reset-names + - '#sound-dai-cells' + - '#address-cells' + - '#size-cells' + - qcom,dout-ports + - qcom,din-ports + - qcom,ports-word-length + - qcom,ports-sinterval-low + - qcom,ports-offset1 + - qcom,ports-offset2 + - qcom,ports-lane-control + - qcom,ports-block-pack-mode + - qcom,ports-hstart + - qcom,ports-block-group-count + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h> + + soundwire@3210000 { + compatible = "qcom,soundwire-v1.6.0"; + reg = <0x03210000 0x2000>; + + interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&lpass_rx_macro>; + clock-names = "iface"; + + qcom,din-ports = <0>; + qcom,dout-ports = <5>; + + resets = <&lpass_audiocc LPASS_AUDIO_SWR_RX_CGCR>; + reset-names = "swr_audio_cgcr"; + + qcom,ports-word-length = /bits/ 8 <0x01 0x07 0x04 0xff 0xff>; + qcom,ports-sinterval-low = /bits/ 8 <0x03 0x3f 0x1f 0x03 0x03>; + qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x0b 0x01 0x01>; + qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x0b 0x00 0x00>; + qcom,ports-lane-control = /bits/ 8 <0x01 0x00 0x00 0x00 0x00>; + qcom,ports-block-pack-mode = /bits/ 8 <0xff 0x00 0x01 0xff 0xff>; + qcom,ports-hstart = /bits/ 8 <0xff 0x03 0xff 0xff 0xff>; + qcom,ports-hstop = /bits/ 8 <0xff 0x06 0xff 0xff 0xff>; + qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0x00>; + + #sound-dai-cells = <1>; + #address-cells = <2>; + #size-cells = <0>; + + status = "disabled"; + }; -- 2.7.4

1 0

[PATCH] dt-bindings: soundwire: Convert text file to yaml format
by Srinivasa Rao Mandadapu 15 Oct '22

15 Oct '22

Update soundwire bindings with yaml formats. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> Co-developed-by: Ratna Deepthi Kudaravalli <quic_rkudarv(a)quicinc.com> Signed-off-by: Ratna Deepthi Kudaravalli <quic_rkudarv(a)quicinc.com> --- .../devicetree/bindings/soundwire/qcom,sdw.txt | 214 --------------------- .../devicetree/bindings/soundwire/qcom,sdw.yaml | 185 ++++++++++++++++++ 2 files changed, 185 insertions(+), 214 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soundwire/qcom,sdw.txt create mode 100644 Documentation/devicetree/bindings/soundwire/qcom,sdw.yaml diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt deleted file mode 100644 index c85c257..0000000 --- a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt +++ /dev/null @@ -1,214 +0,0 @@ -Qualcomm SoundWire Controller Bindings - - -This binding describes the Qualcomm SoundWire Controller along with its -board specific bus parameters. - -- compatible: - Usage: required - Value type: <stringlist> - Definition: must be "qcom,soundwire-v<MAJOR>.<MINOR>.<STEP>", - Example: - "qcom,soundwire-v1.3.0" - "qcom,soundwire-v1.5.0" - "qcom,soundwire-v1.5.1" - "qcom,soundwire-v1.6.0" -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: the base address and size of SoundWire controller - address space. - -- interrupts: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify the SoundWire Controller core and optional - wake IRQ - -- interrupt-names: - Usage: Optional - Value type: boolean - Value type: <stringlist> - Definition: should be "core" for core and "wakeup" for wake interrupt. - -- wakeup-source: - Usage: Optional - Value type: boolean - Definition: should specify if SoundWire Controller is wake up capable. - -- clock-names: - Usage: required - Value type: <stringlist> - Definition: should be "iface" for SoundWire Controller interface clock - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify the SoundWire Controller interface clock - -- #sound-dai-cells: - Usage: required - Value type: <u32> - Definition: must be 1 for digital audio interfaces on the controller. - -- qcom,dout-ports: - Usage: required - Value type: <u32> - Definition: must be count of data out ports - -- qcom,din-ports: - Usage: required - Value type: <u32> - Definition: must be count of data in ports - -- qcom,ports-offset1: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify payload transport window offset1 of each - data port. Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-offset2: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify payload transport window offset2 of each - data port. Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-sinterval-low: - Usage: required - Value type: <prop-encoded-array> - Definition: should be sample interval low of each data port. - Out ports followed by In ports. Used for Sample Interval - calculation. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-word-length: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be size of payload channel sample. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-block-pack-mode: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be 0 or 1 to indicate the block packing mode. - 0 to indicate Blocks are per Channel - 1 to indicate Blocks are per Port. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-block-group-count: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be in range 1 to 4 to indicate how many sample - intervals are combined into a payload. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-lane-control: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be in range 0 to 7 to identify which data lane - the data port uses. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-hstart: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be number identifying lowerst numbered coloum in - SoundWire Frame, i.e. left edge of the Transport sub-frame - for each port. Values between 0 and 15 are valid. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,ports-hstop: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be number identifying highest numbered coloum in - SoundWire Frame, i.e. the right edge of the Transport - sub-frame for each port. Values between 0 and 15 are valid. - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- qcom,dports-type: - Usage: optional - Value type: <prop-encoded-array> - Definition: should be one of the following types - 0 for reduced port - 1 for simple ports - 2 for full port - Out ports followed by In ports. - Value of 0xFF indicates that this option is not implemented - or applicable for the respective data port. - More info in MIPI Alliance SoundWire 1.0 Specifications. - -- reset: - Usage: optional - Value type: <prop-encoded-array> - Definition: Should specify the SoundWire audio CSR reset controller interface, - which is required for SoundWire version 1.6.0 and above. - -- reset-names: - Usage: optional - Value type: <stringlist> - Definition: should be "swr_audio_cgcr" for SoundWire audio CSR reset - controller interface. - -Note: - More Information on detail of encoding of these fields can be -found in MIPI Alliance SoundWire 1.0 Specifications. - -= SoundWire devices -Each subnode of the bus represents SoundWire device attached to it. -The properties of these nodes are defined by the individual bindings. - -= EXAMPLE -The following example represents a SoundWire controller on DB845c board -which has controller integrated inside WCD934x codec on SDM845 SoC. - -soundwire: soundwire@c85 { - compatible = "qcom,soundwire-v1.3.0"; - reg = <0xc85 0x20>; - interrupts = <20 IRQ_TYPE_EDGE_RISING>; - clocks = <&wcc>; - clock-names = "iface"; - resets = <&lpass_audiocc LPASS_AUDIO_SWR_TX_CGCR>; - reset-names = "swr_audio_cgcr"; - #sound-dai-cells = <1>; - qcom,dports-type = <0>; - qcom,dout-ports = <6>; - qcom,din-ports = <2>; - qcom,ports-sinterval-low = /bits/ 8 <0x07 0x1F 0x3F 0x7 0x1F 0x3F 0x0F 0x0F>; - qcom,ports-offset1 = /bits/ 8 <0x01 0x02 0x0C 0x6 0x12 0x0D 0x07 0x0A >; - qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x1F 0x00 0x00 0x1F 0x00 0x00>; - - /* Left Speaker */ - left{ - .... - }; - - /* Right Speaker */ - right{ - .... - }; -}; diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.yaml b/Documentation/devicetree/bindings/soundwire/qcom,sdw.yaml new file mode 100644 index 0000000..bf8f6c1 --- /dev/null +++ b/Documentation/devicetree/bindings/soundwire/qcom,sdw.yaml @@ -0,0 +1,185 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soundwire/qcom,sdw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SoundWire Controller + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> + - Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> + +description: + This binding describes the Qualcomm SoundWire controller along with its + board specific bus parameters. + +properties: + compatible: + enum: + - qcom,soundwire-v1.3.0 + - qcom,soundwire-v1.5.0 + - qcom,soundwire-v1.5.1 + - qcom,soundwire-v1.6.0 + + reg: + items: + - description: the base address and size of SoundWire controller + address space. + + interrupts: + items: + - description: specify the SoundWire controller core and optional + wake IRQ. + + interrupt-names: + items: + - const: wakeup + + clocks: + items: + - description: iface clock + + clock-names: + items: + - const: iface + + resets: + items: + - description: SWR_AUDIO_CGCR RESET + + reset-names: + items: + - const: swr_audio_cgcr + + '#sound-dai-cells': + const: 1 + + '#address-cells': + const: 2 + + '#size-cells': + const: 0 + + qcom,din-ports: + $ref: /schemas/types.yaml#/definitions/uint32 + description: count of data in ports + + qcom,dout-ports: + $ref: /schemas/types.yaml#/definitions/uint32 + description: count of data out ports + + qcom,ports-word-length: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: size of payload channel sample. + minItems: 5 + maxItems: 5 + + qcom,ports-sinterval-low: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: sample interval low of each data port. + minItems: 5 + maxItems: 5 + + qcom,ports-offset1: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: payload transport window offset1 of each data port. + minItems: 5 + maxItems: 5 + + qcom,ports-offset2: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: payload transport window offset2 of each data port. + minItems: 5 + maxItems: 5 + + qcom,ports-lane-control: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: identify which data lane the data port uses. + minItems: 5 + maxItems: 5 + + qcom,ports-block-pack-mode: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: indicate the block packing mode. + minItems: 5 + maxItems: 5 + + qcom,ports-hstart: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: identifying lowerst numbered coloum in SoundWire frame. + minItems: 5 + maxItems: 5 + + qcom,ports-hstop: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: identifying highest numbered coloum in SoundWire frame. + minItems: 5 + maxItems: 5 + + qcom,ports-block-group-count: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: indicate how many sample intervals are combined into a payload. + minItems: 5 + maxItems: 5 + +required: + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - resets + - reset-names + - '#sound-dai-cells' + - '#address-cells' + - '#size-cells' + - qcom,dout-ports + - qcom,din-ports + - qcom,ports-word-length + - qcom,ports-sinterval-low + - qcom,ports-offset1 + - qcom,ports-offset2 + - qcom,ports-lane-control + - qcom,ports-block-pack-mode + - qcom,ports-hstart + - qcom,ports-block-group-count + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h> + + soundwire@3210000 { + compatible = "qcom,soundwire-v1.6.0"; + reg = <0x03210000 0x2000>; + + interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&lpass_rx_macro>; + clock-names = "iface"; + + qcom,din-ports = <0>; + qcom,dout-ports = <5>; + + resets = <&lpass_audiocc LPASS_AUDIO_SWR_RX_CGCR>; + reset-names = "swr_audio_cgcr"; + + qcom,ports-word-length = /bits/ 8 <0x01 0x07 0x04 0xff 0xff>; + qcom,ports-sinterval-low = /bits/ 8 <0x03 0x3f 0x1f 0x03 0x03>; + qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x0b 0x01 0x01>; + qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x0b 0x00 0x00>; + qcom,ports-lane-control = /bits/ 8 <0x01 0x00 0x00 0x00 0x00>; + qcom,ports-block-pack-mode = /bits/ 8 <0xff 0x00 0x01 0xff 0xff>; + qcom,ports-hstart = /bits/ 8 <0xff 0x03 0xff 0xff 0xff>; + qcom,ports-hstop = /bits/ 8 <0xff 0x06 0xff 0xff 0xff>; + qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0x00>; + + #sound-dai-cells = <1>; + #address-cells = <2>; + #size-cells = <0>; + + status = "disabled"; + }; -- 2.7.4

1 0

[PATCH 1/2] ALSA: hda: Add Intel DG2 PCI ID and HDMI codec vid
by Kai Vehmanen 14 Oct '22

14 Oct '22

Add HD Audio PCI ID and HDMI codec vendor ID for Intel DG2. Reviewed-by: Uma Shankar <uma.shankar(a)intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/pci/hda/hda_intel.c | 12 +++++++++++- sound/pci/hda/patch_hdmi.c | 1 + 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 221afacbc7fd..b98d7975adea 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -335,7 +335,10 @@ enum { ((pci)->device == 0x0c0c) || \ ((pci)->device == 0x0d0c) || \ ((pci)->device == 0x160c) || \ - ((pci)->device == 0x490d)) + ((pci)->device == 0x490d) || \ + ((pci)->device == 0x4f90) || \ + ((pci)->device == 0x4f91) || \ + ((pci)->device == 0x4f92)) #define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98) @@ -2477,6 +2480,13 @@ static const struct pci_device_id azx_ids[] = { /* DG1 */ { PCI_DEVICE(0x8086, 0x490d), .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + /* DG2 */ + { PCI_DEVICE(0x8086, 0x4f90), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + { PCI_DEVICE(0x8086, 0x4f91), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + { PCI_DEVICE(0x8086, 0x4f92), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, /* Alderlake-S */ { PCI_DEVICE(0x8086, 0x7ad0), .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 65d2c5539919..98633d2684de 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -4382,6 +4382,7 @@ HDA_CODEC_ENTRY(0x80862814, "DG1 HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x80862815, "Alderlake HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x8086281c, "Alderlake-P HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x80862816, "Rocketlake HDMI", patch_i915_tgl_hdmi), +HDA_CODEC_ENTRY(0x80862819, "DG2 HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x8086281a, "Jasperlake HDMI", patch_i915_icl_hdmi), HDA_CODEC_ENTRY(0x8086281b, "Elkhartlake HDMI", patch_i915_icl_hdmi), HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI", patch_generic_hdmi), base-commit: d7aca8d8f548570f650d9b1dfedf6902f56f2bce -- 2.34.1

3 3

A2B codec chain implementation
by Théo Lebrun 14 Oct '22

14 Oct '22

Hi, Automotive Audio Bus (A2B) is a bus that carries a clock, I2S/TDM, I2C, GPIO and mailboxes over a two wire connection that carries power as well. It has a leader-follower (master-slave in the spec) structure, with no obligation to have all samples going from or to the leader. Analog Devices sells transceivers, that can also decode PDM inputs. Their configuration is register based, with ways of accessing follower registers from the leader. Here is their technical reference: https://www.analog.com/media/en/technical-documentation/user-guides/AD242x_… The goal is to implement support for those, when the host is connected to the leader. The implementation would be done by registering a new bus_type and device_type, with a device for each functionality (on each bus node) provided by the bus. Two issues were faced though: - At runtime, when an PCM stream is started, not only do the CPU and codec need to be configured, but also the leader and follower need some dynamic configuration based on hw_params. We have something resembling a chain, and all 4 devices need to be configured I2S-wise: CPU <-I2S-> leader node <-A2B-> follower node <-I2S-> codec. That does not fit the standard form of a DAI link that only has a CPU and a codec. Is there a way to have a sound card that contains multiple codecs, all actived? - Clocks will have to be handled at the bus level and not at the soundcard level, as the master clock is needed at all times for the bus to be functional. Sadly it's probably not doable to use the clocks provided by the I2S/TDM CPU codec (which would be ideal as they are audio rate, which is what the bus expects), because they only get enabled when a PCM stream is active. On the hardware used for testing (SAMA7G54), we can't use an external (relative to the CPU codec) clock as master clock and use the peripheral to generate the bitclock, it doesn't support it; therefore both have to be handled at the bus level using board specific clocks. So the first point is the main question: how could a codec chain be modeled? I was potentially thinking about a custom soundcard? That could surely help? Would it be the right solution? Any pointers would help. The clock aspect would have been an issue as a codec is either a clock provider or consumer but for this particular use it is not as we'll use the bus and not the soundcard to handle the clock management. Thanks! Théo -- Théo Lebrun, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

2 1

Re: [rft, PATCH v2 00/36] pinctrl: Clean up and add missed headers
by Andy Shevchenko 14 Oct '22

14 Oct '22

On Tue, Oct 11, 2022 at 11:56 PM Florian Fainelli <f.fainelli(a)gmail.com> wrote: > On 10/10/2022 1:14 PM, Andy Shevchenko wrote: > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > than logical. This series is basically out of two parts: > > - add missed headers to the pin control drivers / users > > - clean up the headers of pin control subsystem > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > pin control subsystems, so all new drivers will utilize cleaned up headers > > of the pin control. > > > > Please, review and comment. > > Did you really need to split this on a per-driver basis as opposed to > just a treewide drivers/pinctrl, drivers/media and drivers/gpiolib patch > set? > > 36 patches seems needlessly high when 4 patches could have achieve the > same outcome. I can combine them if maintainers ask for that, nevertheless for Intel pin control and GPIO drivers, which I care more about, I would like to leave as separate changes (easy to see in history what was done). -- With Best Regards, Andy Shevchenko

2 1

[PATCH v2] ASoC: nau8822: add spk boost and spk btl options
by Benjamin Marty 14 Oct '22

14 Oct '22

These two options are required to use the Speaker output on this codec to its full potential, when wiring up the Speaker in an BTL configuration. The Speaker Boost flag is explained in the Datasheet on page 80. The Speaker BTL flag is explained in the Datasheet on page 78. Signed-off-by: Benjamin Marty <info(a)benjaminmarty.ch> --- sound/soc/codecs/nau8822.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c index 1aef281a9972..812b8254f9a0 100644 --- a/sound/soc/codecs/nau8822.c +++ b/sound/soc/codecs/nau8822.c @@ -379,6 +379,12 @@ static const struct snd_kcontrol_new nau8822_snd_controls[] = { NAU8822_REG_DAC_CONTROL, 5, 1, 0), SOC_SINGLE("ADC 128x Oversampling Switch", NAU8822_REG_ADC_CONTROL, 5, 1, 0), + + SOC_SINGLE("Speaker Gain Boost Control", + NAU8822_REG_OUTPUT_CONTROL, 2, 1, 0), + + SOC_SINGLE("Speaker BTL Configuration", + NAU8822_REG_RIGHT_SPEAKER_CONTROL, 4, 1, 0), }; /* LMAIN and RMAIN Mixer */ -- 2.38.0

3 2

[PATCH] ASoC: nau8822: add spk boost and spk btl options
by Benjamin Marty 14 Oct '22

14 Oct '22

These two options are required to use the Speaker output on this codec to its full potential, when wiring up the Speaker in an BTL configuration. The Speaker Boost flag is explained in the Datasheet on page 80. The Speaker BTL flag is explained in the Datasheet on page 78. Signed-off-by: Benjamin Marty <info(a)benjaminmarty.ch> --- sound/soc/codecs/nau8822.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c index 1aef281a9972..812b8254f9a0 100644 --- a/sound/soc/codecs/nau8822.c +++ b/sound/soc/codecs/nau8822.c @@ -379,6 +379,12 @@ static const struct snd_kcontrol_new nau8822_snd_controls[] = { NAU8822_REG_DAC_CONTROL, 5, 1, 0), SOC_SINGLE("ADC 128x Oversampling Switch", NAU8822_REG_ADC_CONTROL, 5, 1, 0), + + SOC_SINGLE("Speaker Gain Boost Control", + NAU8822_REG_OUTPUT_CONTROL, 2, 1, 0), + + SOC_SINGLE("Speaker BTL Configuration", + NAU8822_REG_RIGHT_SPEAKER_CONTROL, 4, 1, 0), }; /* LMAIN and RMAIN Mixer */ -- 2.37.3

2 3

Re: Buffer overflow in AVS driver
by CoolStar Organization 14 Oct '22

14 Oct '22

Hi Cezary and Alicja, Just chiming in a bit regarding Geminilake since I figured it out on my end. I have been able to get AVS (at least my port anyways) to run on a Geminilake chromebook after re-signing + re-packing the DSP firmware with the community keys and updating my driver's topology generation to look for the correct SSP's on the NHLT. I dug through the older SKL module in Linux and I noticed the topologies for that specify a "mixer" module (I'm noting it creates an output and an input mixer and binds them together in between the HDA and I2S copier modules). Do these mixer modules do any volume adjustment / volume limiting? as I didn't see any configuration for the mixers aside from the audio format. --CoolStar On Mon, Oct 3, 2022 at 9:09 AM <alicja.michalska(a)tutanota.com> wrote: > Hello Cezary, Amadeusz and CoolStar. > > I'm sure you're waiting for update from me, but unfortunately I got really > sick with tonsillitis. Hopefully it clears up a bit tomorrow. > > I did some preliminary testing as CoolStar mentioned, but I would like to > compare results with GeminiLake Refresh board (google/octopus) that should > be arriving tomorrow. It also uses DA7219 + 2x max98357a (max98357a is a > mono amplifier, so there are two amplifiers on the board - one per channel). > > Just from multimeter measurements there's nothing out of ordinary. 5.12v > (so basically 5v) driving max98357a, resulting with 2.7v on speaker output > which is within spec. I'm still learning how to use an oscilloscope, but > I've noticed that Vpp parameter goes up to 2.4v if you set the volume to > 100% (I'm testing on google/reef baseboard which is ApolloLake N3350 with > DA7219 + 2x max98357a). If you set volume to ~66% it stays around 2v and > speakers don't heat up. > > Here you can see that even without any audio playing, left speaker is > significantly warmer than right one. I began playback with volume set to > 25%, then increased it to 65% and then 100%. Once speaker reaches 60*C, > it's permanently damaged. Working speaker has 3.7Ohm resistance, while > damaged one has 3.9Ohm. > You can also see a pair of max98357a's heating up in the background while > playing with volume set to 100% - they reach 40*C. > > https://elly.rocks/tmp/avs_fryingpan.mp4 > Speaking of which, reading trough the code I've noticed that you intend on > supporting GLK platform. We don't have firmware signed with community keys > (GLK doesn't accept Intel-signed keys) so I've been wondering - would it be > possible for you to provide such FW? > > It is really baffling to me, because as far as we both (CoolStar and me) > see, max98357a is a very simple amplifier controlled by setting GPIO pin > low or high. Conclusion would be that the problem lies in how AVS is > driving ADAU7002 or DA7219, but I'm definitely not in shape right now to > read trough AVS code once again. > > > Best regards, > Alicja Michalska > -- > Sent from Tutanota Client for Linux x86_64 > > > > Oct 2, 2022, 00:09 by coolstarorganization(a)gmail.com: > > > Hi Cezary, > > I was able to get a capture streams working. Thanks for the guidance > on the order of operations for that. For the final iteration of my driver > port I'm going to be grabbing data from the NHLT to populate topologies it > generates so that should have less hardcoding. > > > > Regarding the volume problem, Alicja here ran some tests with AVS on > linux with a scope connected to the output pins of the max98357a (we're > testing on various Skylake, Kaby Lake and Apollo Lake chromebooks -- I > unfortunately blew the left speaker on pantheon here during testing (and > Alicja blew a left speaker on snappy). We're using topology files grabbed > from Chrome OS's Apollo Lake image (I edited the virtual bus id to get it > working on Kaby Lake here), and it seems there's nothing referencing DSM > inside either the alsa configs or topology. > > --CoolStar > > > > On Thu, Sep 29, 2022 at 9:41 AM Rojewski, Cezary <> > cezary.rojewski(a)intel.com> > wrote: > > > >> > >> Hello, > >> > >> > >> > >> > >> > >> Indeed, there are means on dealing with volume problem you describe. > Not all of them are free though and we cannot share such to the community > without client’s ACK. > >> > >> > >> Judging by the max98357a, platform of yours is a Chromebook device, > perhaps AML-based, e.g.: Atlas. Said configuration contains the DSM module > which addresses the problem. The DSM topology and the configuration should > be available to public, so filtering google’s public domain should yield > positive results. > >> > >> > >> > >> > >> > >> I advise against hardcoding anything within the driver. Within a week > or two, tools for compiling the topology as well as several dozens of > examples should be present on the upstream, that is on the >> > github.com/thesofproject <http://github.com/thesofproject>>> . > >> > >> > >> But yes, there is a requirement for certain ordering of operations. In > general, you should be creating stuff from input to output (precisely in > that direction). For capture, input stands at BE side while for playback > it’s FE instead. There’s also part about configuring the actual hardware > that is represented in ASoC as a BE. Files: avs/path.c and avs/pcm.c should > provide the pattern you seek. > >> > >> > >> > >> > >> > >> > >> > >> > >> Kind regards, > >> > >> > >> Czarek > >> > >> > >> > >> > >> > >> From:>> CoolStar Organization <>> coolstarorganization(a)gmail.com>> > > >> >> Sent:>> Wednesday, September 28, 2022 11:17 PM > >> >> To:>> Rojewski, Cezary <>> cezary.rojewski(a)intel.com>> > > >> >> Cc:>> >> amadeuszx.slawinski(a)linux.intel.com > >> >> Subject:>> Re: Buffer overflow in AVS driver > >> > >> > >> > >> > >> Hi Czarek, > >> > >> > >> You can mention CoolStar in the Reported-by tag, as that’s the > pseudonym I go by. > >> > >> > >> > >> > >> > >> Also I had 2 questions regarding AVS. > >> > >> > >> > >> > >> > >> A friend and I both noticed on max98357a that increasing the volume in > the OS past 70% can destroy the speakers. Is there a module or something > that could be bound on the speaker path to limit the volume as max98357a > itself just has an on/off switch? (I noticed catpt has volume controls. > Maybe AVS’s updown mix?). > >> > >> > >> > >> > >> > >> Also, I managed to get my AVS port to output sound on another OS (I’m > not using topology files and am hard coding the path). However I noticed > I’ve been unable to record sound. I noticed for output streams the > initialization sequence is: > >> > >> > >> 1. Create pipeline 0 > >> > >> > >> 2. Create i2s link output path on pipeline 0 > >> > >> > >> 3. Grab HDA render stream & program BDL > >> > >> > >> 4. Create pipeline 1 > >> > >> > >> 5. Create HDA output path on pipeline 1 with virtual link address > (HDA stream tag - 1) > >> > >> > >> 6. Bind pipeline 1 to 0 > >> > >> > >> 7. Set pipeline 0 and then 1 to reset & paused > >> > >> > >> 8. Start HDA stream playback > >> > >> > >> 9. Set pipelines 1 and then 0 to running > >> > >> > >> > >> > >> > >> I’ve been attempting to do a similar setup for input (except with i2s > link input path, an HDA capture stream, and HDA input path) but I don’t see > any input. Is there a particular order for input initialization for it to > work? (Similar to how for the output I had to set up the HDA stream before > creating the HDA pipeline before I could get any sound output?) > >> > >> > >> > >> > >> > >> —CoolStar > >> > >> > >> > >> > >> > >> On Wed, Sep 28, 2022 at 1:09 PM Rojewski, Cezary <>> > cezary.rojewski(a)intel.com>> > wrote: > >> > >> > >>> > >>> Hello, > >>> > >>> > >>> > >>> > >>> > >>> Please excuse my delay in response. We appreciate the input – in > future, please do not be afraid to email us with alsa-devel in CC. It’s > easier to not have the mail missed that way. > >>> > >>> > >>> > >>> > >>> > >>> In regard to the actual bug, highly unlikely but indeed you’re > correct. While my response is delayed, patch fixing the problem in our > internal tree was not. Said patch should soon appear on the alsa-devel > mailing list. Are there any names that you would like us to mention in the > relevant commit message (through “Reported-by:” tag)?. > >>> > >>> > >>> > >>> > >>> > >>> Kind regards, > >>> > >>> > >>> Czarek > >>> > >>> > >>> > >>> > >>> > >>> From:>>> CoolStar Organization <>>> coolstarorganization(a)gmail.com>>> > > > >>> >>> Sent:>>> Saturday, September 10, 2022 10:00 PM > >>> >>> To:>>> Rojewski, Cezary <>>> cezary.rojewski(a)intel.com>>> >; > >>> amadeuszx.slawinski(a)linux.intel.com > >>> >>> Subject:>>> Buffer overflow in AVS driver > >>> > >>> > >>> > >>> > >>> Hi, > >>> > >>> > >>> I've been looking at porting the avs driver you've written to another > OS. During the process I noticed a potential buffer overflow issue in ipc.c. > >>> > >>> > >>> > >>> > >>> > >>> I noticed that ipc->rx.data is allocated a buffer of > `AVS_MAILBOX_SIZE` (or 4096 bytes) in the init, and this buffer is not > allocated anywhere else. In avs_dsp_receive_rx, if the msg type is set to a > large config get, it sets the size to the arbitrary value from the msg > struct without any checks, and then immediately does a memcpy to the buffer. > >>> > >>> > >>> > >>> > >>> > >>> I'd highly suggest putting a check to ensure this doesn't go larger > than AVS_MAILBOX_SIZE to avoid a buffer overflow as that could crash the > system (or potentially be a vulnerability to take over the host system if > an attacker somehow gets code execution on the DSP?) > >>> > >>> > >>> --CoolStar > >>> > >>> > >

1 0