The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM. The device
drivers request resources operations over SCMI using power and
performance protocols.

The SCMI power protocol enables or disables resources like clocks,
interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
such as resume/suspend, to control power states(on/off).

The SCMI performance protocol manages UART baud rates, with each baud
rate represented by a performance level. Drivers use the
dev_pm_opp_set_level() API to request the desired baud rate by
specifying the performance level.

The QUP drivers are SCMI clients, with clocks, interconnects, pinctrl
and power-domains abstracted by a SCMI server.

Nikunj Kela (3):
  opp: add new helper API dev_pm_opp_set_level()
  dt-bindings: serial: describe SA8255p
  dt-bindings: qcom: geni-se: describe SA8255p

Praveen Talari (6):
  soc: qcom: geni-se: Enable QUPs on SA8255p Qualcomm platforms
  serial: qcom-geni: move resource initialization to separate function
  serial: qcom-geni: move resource control logic to separate functions
  serial: qcom-geni: move clock-rate logic to separate function
  serial: qcom-geni: Enable PM runtime for serial driver
  serial: qcom-geni: Enable Serial on SA8255p Qualcomm platforms

 .../serial/qcom,sa8255p-geni-uart.yaml        |  66 ++++
 .../soc/qcom/qcom,sa8255p-geni-se-qup.yaml    | 107 ++++++
 drivers/opp/core.c                            |  22 ++
 drivers/soc/qcom/qcom-geni-se.c               |  77 ++--
 drivers/tty/serial/qcom_geni_serial.c         | 351 ++++++++++++++----
 include/linux/pm_opp.h                        |   6 +
 6 files changed, 528 insertions(+), 101 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml


base-commit: bc8aa6cdadcc00862f2b5720e5de2e17f696a081
-- 
2.17.1

On 4/18/25 5:12 PM, Praveen Talari wrote:
> The Qualcomm automotive SA8255p SoC relies on firmware to configure
> platform resources, including clocks, interconnects and TLMM. The device
> drivers request resources operations over SCMI using power and
> performance protocols.
> 
> The SCMI power protocol enables or disables resources like clocks,
> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
> such as resume/suspend, to control power states(on/off).
> 
> The SCMI performance protocol manages UART baud rates, with each baud
> rate represented by a performance level. Drivers use the
> dev_pm_opp_set_level() API to request the desired baud rate by
> specifying the performance level.
> 
> The QUP drivers are SCMI clients, with clocks, interconnects, pinctrl
> and power-domains abstracted by a SCMI server.

So I recently started working on abstracting away power controls from
the SE protocol drivers into a single place, among other improvements

A snapshot of this work is available here

https://github.com/quic-kdybcio/linux/commits/topic/single_node_genise/

(not yet 100% ready..)

I think it'd make sense to get it done first, so that we can condense
most of your changes in the common driver, where we'd swap out the clock
handling for perf level setting instead

Konrad

Hi

On 4/23/2025 6:31 PM, Konrad Dybcio wrote:
> On 4/18/25 5:12 PM, Praveen Talari wrote:
>> The Qualcomm automotive SA8255p SoC relies on firmware to configure
>> platform resources, including clocks, interconnects and TLMM. The device
>> drivers request resources operations over SCMI using power and
>> performance protocols.
>>
>> The SCMI power protocol enables or disables resources like clocks,
>> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
>> such as resume/suspend, to control power states(on/off).
>>
>> The SCMI performance protocol manages UART baud rates, with each baud
>> rate represented by a performance level. Drivers use the
>> dev_pm_opp_set_level() API to request the desired baud rate by
>> specifying the performance level.
>>
>> The QUP drivers are SCMI clients, with clocks, interconnects, pinctrl
>> and power-domains abstracted by a SCMI server.
> So I recently started working on abstracting away power controls from
> the SE protocol drivers into a single place, among other improvements
>
> A snapshot of this work is available here
>
> https://github.com/quic-kdybcio/linux/commits/topic/single_node_genise/
>
> (not yet 100% ready..)
>
> I think it'd make sense to get it done first, so that we can condense
> most of your changes in the common driver, where we'd swap out the clock
> handling for perf level setting instead
Thank you for the update and for sharing the snapshot of your work. The 
improvements you're working on sound promising, especially the 
abstraction of power controls into a single place.
While we appreciate the direction you're taking, our patch has already 
been pushed upstream with V2.
To maintain our momentum, we would prefer to continue with our current 
cleanups rather than waiting for your post if it's planned for a few 
weeks from now.

It would be greatly appreciated if you could take this patch and build 
your ongoing work on top of it, as it would be somewhat similar to 
optimize it from SE's protocol driver to the common geni driver for 
power management.

That being said, could you please provide an estimated completion date 
for your work?


Thanks,

Praveen

>
> Konrad