Re: [PATCH v2 0/9] soc: qcom: geni: Derive SE clock configuration from OPP table on SA8255P
From: Praveen Talari
Date: Wed Sep 09 2026 - 02:34:15 EST
Hi Ulf,
Thank you for review.
On 04-09-2026 13:26, Ulf Hansson wrote:
On Tue, Sep 1, 2026 at 6:48 PM Praveen TalariI agree that protocol drivers should ideally rely on generic frameworks and
<praveen.talari@xxxxxxxxxxxxxxxx> wrote:
Hi Ulf,Right, the goal makes sense, but I am not sure the proposed solution
On 01-09-2026 20:22, Ulf Hansson wrote:
On Thu, Aug 27, 2026 at 7:59 PM Praveen TalariI agree that protocol drivers should not need to know whether GENI resources
<praveen.talari@xxxxxxxxxxxxxxxx> wrote:
On firmware-managed platforms such as SA8255P, there is no Linux clockHmm, this sounds like moving backwards when it comes to keeping
handler available to determine the appropriate SE source clock, source
clock index, and divider values for a requested protocol frequency.
However, these parameters are required when programming GSI TREs, where
the hardware expects an explicit clock source selection and divider
configuration for the serial engine.
In contrast, platforms using Linux-managed clocks derive these
parameters through geni_se_clk_freq_match() using the source clock
information stored in clk_perf_tbl. Since the firmware-managed path
lacks equivalent clock information, protocol drivers cannot reuse the
existing frequency matching logic and instead rely on a direct mapping
between protocol-requested frequencies and performance levels. This
creates a separate clock configuration flow and prevents
firmware-managed platforms from deriving the actual SE clock parameters
required for GSI TRE programming.
drivers as portable as possible.
I understand geni_se_clk_freq_match() has been around for a while, but
fortunately its use seems limited to only a few qcom specific drivers.
Rather than continue down this path, would it not be possible to find
a more generic solution for "geni_se_clk_freq_match()"? Can we replace
it with a common clock/OPP API? In this way, we would not need to
sprinkle drivers with calls to platform specific code.
are managed through the clock framework or a firmware-provided
performance domain.
The intent of this series is actually to move in that direction rather than
introduce a separate flow. Today firmware-managed platforms cannot use
geni_se_clk_freq_match() because clk_perf_tbl is only populated when a
Linux clock
is present. This series derives the same clock-performance
information(clk_perf_tbl) from the OPP
table and populates clk_perf_tbl during geni_se_domain_attach(),
allowing both
resource-management models to reuse the existing
geni_se_clk_freq_match() infrastructure.
is the way to get there.
We really want to avoid having generic drivers like (spi, uart, i2c,
etc) calling platform specific functions. This isn't just me, it's the
general way for how we do things for drivers. Of course, we have
exceptions, but I think you get my point.
In this case, why isn't it possible to use the clock and OPP
framework? Is there anything missing to make this work?
avoid platform-specific resource management logic.
The challenge here is that the OPP framework currently provides a mechanism
to select and apply an operating point, but it does not expose the GENI-specific
information required for GSI TRE programming. In addition to selecting an operating
point, the GSI path needs to derive the corresponding SE source clock frequency,
clock index and divider values, as these fields must be programmed explicitly into the
TRE descriptors consumed by the hardware.
Today geni_se_clk_freq_match() serves two purposes:
1. Match a requested protocol frequency against the set of supported SE source
clock frequencies.
2. Derive the GENI-specific parameters (source clock, clock index and divider) associated
with the selected frequency.
While OPP can manage clock and performance state selection, it does not currently provide
an interface to obtain these GENI-specific clock-configuration parameters. This is why the
existing GENI helper is still required.
The intent of this series is not to introduce another platform-specific
clock-selection path. Rather, it allows firmware-managed platforms to use the same
clock-matching infrastructure already used on clock-managed platforms by deriving the
clock-performance table from the OPP data.
I have removed platform specific set_rate callback in patches for SPI [1] and Serial [2]
[1]https://lore.kernel.org/all/20260827-derive_clk_perf_tbl_from_perf_domain_opp_table-v2-6-091697dbeb02@xxxxxxxxxxxxxxxx/
[2]https://lore.kernel.org/all/20260827-derive_clk_perf_tbl_from_perf_domain_opp_table-v2-5-091697dbeb02@xxxxxxxxxxxxxxxx/
Likewise, geni_se_set_rate() hides whether the underlying implementationThe OPP layer already has some capabilities for managing clocks. Can't
uses
dev_pm_opp_set_rate() on a perf-domain device or a regular clock-backed
device,
so protocol drivers no longer need platform-specific callbacks. The goal
is to
converge both paths behind common GENI helpers rather than maintain separate
clock-selection mechanisms.
we use devm_pm_opp_set_config() to prepare an OPP table with the
relevant clk data for the devices, as a way to abstract things?
devm_pm_opp_set_config() with a .clk_name lets dev_pm_opp_set_rate()
internally call clk_set_rate() on a named clk — but that requires an actual
clk provider backing the device. On SA8255P there is no Linux clk object for the
SE source clock at all: firmware only exposes a set of supported frequencies as OPP
levels on the performance-domain device, not as a rate-settable clock. So there's
nothing for devm_pm_opp_set_config()'s clk-integration to attach to — the OPP table
here isn't describing a DVFS operating point of an existing clock, it's standing in
for the clock itself.
So geni_se_clk_freq_match() is used by two consumer drivers today,I agree with the goal of using generic infrastructure. However,To address this limitation, the performance-domain OPP table is treatedRather than adding yet another platform specific method, would it be
as the representation of SE-supported source clock frequencies. During
geni_se_domain_attach(), the OPP entries are used to populate
clk_perf_tbl and related clock performance data, allowing
firmware-managed platforms to leverage the same clock frequency matching
infrastructure used by Linux-managed platforms.
With this change, protocol drivers can use geni_se_clk_freq_match() to
select the closest supported source clock frequency for a requested
protocol rate, derive the corresponding source clock index and divider
values required for GSI TRE programming, and apply the matched clock
through the OPP framework. This removes the dependency on direct
protocol-frequency-to-performance-level mappings and provides a common
clock selection and configuration mechanism across both firmware-managed
and Linux-managed GENI deployments.
possible to extend the generic OPP library with the pieces that are
missing to make this work in a generic way?
geni_se_clk_freq_match()
derives GENI-specific parameters such as the source clock, clock index,
and divider values
required for GSI TRE programming, which are not represented by the
generic OPP interface today.
This series does not introduce a new clock selection path; it reuses the
existing
geni_se_clk_freq_match() flow on firmware-managed platforms by populating
clk_perf_tbl from OPP data.
drivers/spi/spi-geni-qcom.c and drivers/tty/serial/qcom_geni_serial.c.
Beyond the $subject series, there will be even more consumer drivers
that call these platform specific functions. As I said above, I don't
think this is moving things in the right direction.
If this can't be solved with generic frameworks (clocks and OPP),
please clarify why so we can figure out a better way forward.
I believe above response can answered your query.
Thanks,
Praveen Talari
[...]
Kind regards
Uffe