This series adds support for LPASS low-power resource (LPR) voting
through PRM and introduces LPASS LPI TLMM pinctrl support for newer
platforms such as Hawi.

On such platforms, LPASS requires LPR resource voting via PRM to keep
the subsystem active. This is handled by adding a new clock ID and
support for PARAM_ID_RSC_CPU_LPR in q6prm.

Additionally, a new LPASS LPI TLMM block is introduced, requiring a
dedicated DT binding and pinctrl driver.

Chanes in v4:
	- Addressed Krzysztof comments, Drop Q6AFE_MAX_CLK_ID from the bindings
	  since it is not used in-tree.
	- Link to v3: https://lore.kernel.org/linux-arm-msm/20260715133243.3170821-1-prasad.kumpatla@oss.qualcomm.com/

Changes in v3:
	- Drop the mutex cleanup patch from this series. Since this change
	  is not required for Hawi enablement, keep the current series 
	  focused on LPASS LPR voting and LPASS LPI TLMM support, and 
	  address the cleanup in a dedicated follow-up series.
	 - As Srini suggested changed LPR_CPU_SS_SLEEP_DISABLED to LPR_CPU_SS_SLEEP_DISABLE in patch#2.
	 - Link to v2: https://lore.kernel.org/all/20260713184549.929569-1-prasad.kumpatla@oss.qualcomm.com/

Changes in v2:
	- Add mutex cleanup devm-managed in LPASS LPI Pinctrl. 
	- Addressed Bart Comments related to newline and readability.
	- Link to v1: https://lore.kernel.org/linux-arm-msm/20260708114924.1069239-1-prasad.kumpatla@oss.qualcomm.com/

Prasad Kumpatla (4):
  ASoC: dt-bindings: qcom: add LPASS LPR vote clock ID
  ASoC: qcom: q6prm: add support for LPASS LPR resource voting
  dt-bindings: pinctrl: qcom,hawi-lpass-lpi-pinctrl: Add Hawi LPI
    pinctrl
  pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM

 .../pinctrl/qcom,hawi-lpass-lpi-pinctrl.yaml  | 109 ++++++++
 drivers/pinctrl/qcom/Kconfig                  |  10 +
 drivers/pinctrl/qcom/Makefile                 |   1 +
 drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c | 244 ++++++++++++++++++
 drivers/pinctrl/qcom/pinctrl-lpass-lpi.h      |  17 ++
 .../sound/qcom,q6dsp-lpass-ports.h            |   2 +-
 sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.c     |   2 +-
 sound/soc/qcom/qdsp6/q6prm-clocks.c           |   2 +
 sound/soc/qcom/qdsp6/q6prm.c                  |  16 +-
 sound/soc/qcom/qdsp6/q6prm.h                  |   1 +
 10 files changed, 399 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,hawi-lpass-lpi-pinctrl.yaml
 create mode 100644 drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c

-- 
2.34.1

On Mon, 20 Jul 2026 15:05:07 +0200, Prasad Kumpatla
<prasad.kumpatla@oss.qualcomm.com> said:
> This series adds support for LPASS low-power resource (LPR) voting
> through PRM and introduces LPASS LPI TLMM pinctrl support for newer
> platforms such as Hawi.
>
> On such platforms, LPASS requires LPR resource voting via PRM to keep
> the subsystem active. This is handled by adding a new clock ID and
> support for PARAM_ID_RSC_CPU_LPR in q6prm.
>
> Additionally, a new LPASS LPI TLMM block is introduced, requiring a
> dedicated DT binding and pinctrl driver.

What is the merging strategy? Is an Ack from Mark required and the series
should go together through the pinctrl tree?

Bart

On 7/20/2026 7:12 PM, Bartosz Golaszewski wrote:
> On Mon, 20 Jul 2026 15:05:07 +0200, Prasad Kumpatla
> <prasad.kumpatla@oss.qualcomm.com> said:
>> This series adds support for LPASS low-power resource (LPR) voting
>> through PRM and introduces LPASS LPI TLMM pinctrl support for newer
>> platforms such as Hawi.
>>
>> On such platforms, LPASS requires LPR resource voting via PRM to keep
>> the subsystem active. This is handled by adding a new clock ID and
>> support for PARAM_ID_RSC_CPU_LPR in q6prm.
>>
>> Additionally, a new LPASS LPI TLMM block is introduced, requiring a
>> dedicated DT binding and pinctrl driver.
> What is the merging strategy? Is an Ack from Mark required and the series
> should go together through the pinctrl tree?

Hi Bart,

Thanks for the question. The only cross-subsystem dependency is the
addition of LPASS_HW_LPR_VOTE in qcom,q6dsp-lpass-ports.h, which is
consumed by the Hawi LPASS LPI DT binding. My expectation was that
the shared clock ID definition would be merged first, after which
the ASoC and pinctrl changes could proceed through their respective
trees. I'll clarify this dependency and the intended merge strategy
in the next revision's cover letter.

Thanks,
Prasad

>
> Bart

On 20/07/2026 15:42, Bartosz Golaszewski wrote:
> On Mon, 20 Jul 2026 15:05:07 +0200, Prasad Kumpatla
> <prasad.kumpatla@oss.qualcomm.com> said:
>> This series adds support for LPASS low-power resource (LPR) voting
>> through PRM and introduces LPASS LPI TLMM pinctrl support for newer
>> platforms such as Hawi.
>>
>> On such platforms, LPASS requires LPR resource voting via PRM to keep
>> the subsystem active. This is handled by adding a new clock ID and
>> support for PARAM_ID_RSC_CPU_LPR in q6prm.
>>
>> Additionally, a new LPASS LPI TLMM block is introduced, requiring a
>> dedicated DT binding and pinctrl driver.
> 
> What is the merging strategy? Is an Ack from Mark required and the series
> should go together through the pinctrl tree?

Why would an ack be needed? Cover letter is very explicit on that
through complete silence that there is no dependency (except that it is
not true) so why would you take ASoC bits?

Best regards,
Krzysztof

On Mon, 20 Jul 2026 15:54:41 +0200, Krzysztof Kozlowski <krzk@kernel.org> said:
> On 20/07/2026 15:42, Bartosz Golaszewski wrote:
>> On Mon, 20 Jul 2026 15:05:07 +0200, Prasad Kumpatla
>> <prasad.kumpatla@oss.qualcomm.com> said:
>>> This series adds support for LPASS low-power resource (LPR) voting
>>> through PRM and introduces LPASS LPI TLMM pinctrl support for newer
>>> platforms such as Hawi.
>>>
>>> On such platforms, LPASS requires LPR resource voting via PRM to keep
>>> the subsystem active. This is handled by adding a new clock ID and
>>> support for PARAM_ID_RSC_CPU_LPR in q6prm.
>>>
>>> Additionally, a new LPASS LPI TLMM block is introduced, requiring a
>>> dedicated DT binding and pinctrl driver.
>>
>> What is the merging strategy? Is an Ack from Mark required and the series
>> should go together through the pinctrl tree?
>
> Why would an ack be needed? Cover letter is very explicit on that
> through complete silence that there is no dependency (except that it is
> not true) so why would you take ASoC bits?
>

I don't think the cover letter is very explicit on there being no build-time
dependencies, hence my question.

Bart