[PATCH v1 0/2] soundwire: qcom: add support for EE-aware register layout

Mohammad Rafi Shaik posted 2 patches 2 weeks, 2 days ago
.../bindings/soundwire/qcom,soundwire.yaml    |  6 ++
drivers/soundwire/qcom.c                      | 78 +++++++++++++++----
2 files changed, 71 insertions(+), 13 deletions(-)
[PATCH v1 0/2] soundwire: qcom: add support for EE-aware register layout
Posted by Mohammad Rafi Shaik 2 weeks, 2 days ago
This series adds support for execution environment (EE) aware register
layouts in the Qualcomm SoundWire master controller driver.

On SoundWire v2.0+ hardware, some controllers bank the interrupt, FIFO, and
status registers in EE-specific windows separated by a stride of 0x1000.
Typically, the driver assumes EE1, but platforms like Shikra have the
controller routed on EE0.

To support platforms with varying EEs, we:
1. Introduce the `qcom,swr-master-ee-val` DT property to configure the
   target execution environment.
2. Add remapping logic to adjust the register layout offsets by the
   EE window stride on v2.0+ hardware.
   
The first patch adds DT binding documentation for the new property, and
the second implements the EE-aware layout selection in the soundwire
driver.

Mohammad Rafi Shaik (2):
  dt-bindings: soundwire: qcom: add qcom,swr-master-ee-val property
  soundwire: qcom: add EE-aware register layout and cpu selection

 .../bindings/soundwire/qcom,soundwire.yaml    |  6 ++
 drivers/soundwire/qcom.c                      | 78 +++++++++++++++----
 2 files changed, 71 insertions(+), 13 deletions(-)

-- 
2.34.1
Re: [PATCH v1 0/2] soundwire: qcom: add support for EE-aware register layout
Posted by Konrad Dybcio 2 weeks, 1 day ago
On 6/8/26 7:53 PM, Mohammad Rafi Shaik wrote:
> This series adds support for execution environment (EE) aware register
> layouts in the Qualcomm SoundWire master controller driver.
> 
> On SoundWire v2.0+ hardware, some controllers bank the interrupt, FIFO, and
> status registers in EE-specific windows separated by a stride of 0x1000.
> Typically, the driver assumes EE1, but platforms like Shikra have the
> controller routed on EE0.

Do these EEs have any names associated with them, that would help
explain why the change is needed?

Konrad