From: Praveen Talari <praveen.talari@oss.qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Andi Shyti <andi.shyti@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>,
Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
bryan.odonoghue@linaro.org, dmitry.baryshkov@oss.qualcomm.com,
bjorn.andersson@oss.qualcomm.com
Cc: prasad.sodagudi@oss.qualcomm.com, quic_vtanuku@quicinc.com,
aniket.randive@oss.qualcomm.com,
chandana.chiluveru@oss.qualcomm.com
Subject: Re: [PATCH v3 06/12] soc: qcom: geni-se: Introduce helper APIs for performance control
Date: Fri, 20 Feb 2026 10:53:11 +0530 [thread overview]
Message-ID: <85bb3a9f-d54a-4b4c-8dbb-6d5461ebb037@oss.qualcomm.com> (raw)
In-Reply-To: <ac490ba8-18d0-47fc-a662-5a202c5ba95d@oss.qualcomm.com>
Hi Konrad,
On 2/17/2026 5:55 PM, Konrad Dybcio wrote:
> On 2/4/26 6:42 AM, Praveen Talari wrote:
>> Hi Konrad,
>>
>> On 2/3/2026 4:44 PM, Konrad Dybcio wrote:
>>> On 1/30/26 5:54 PM, Praveen Talari wrote:
>>>> Hi Konrad
>>>>
>>>> On 1/30/2026 5:53 PM, Konrad Dybcio wrote:
>>>>> On 1/12/26 11:47 AM, Praveen Talari wrote:
>>>>>> The GENI Serial Engine (SE) drivers (I2C, SPI, and SERIAL) currently
>>>>>> manage performance levels and operating points directly. This resulting
>>>>>> in code duplication across drivers. such as configuring a specific level
>>>>>> or find and apply an OPP based on a clock frequency.
>>>>>>
>>>>>> Introduce two new helper APIs, geni_se_set_perf_level() and
>>>>>> geni_se_set_perf_opp(), addresses this issue by providing a streamlined
>>>>>> method for the GENI Serial Engine (SE) drivers to find and set the OPP
>>>>>> based on the desired performance level, thereby eliminating redundancy.
>>>>>>
>>>>>> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> +/**
>>>>>> + * geni_se_set_perf_level() - Set performance level for GENI SE.
>>>>>> + * @se: Pointer to the struct geni_se instance.
>>>>>> + * @level: The desired performance level.
>>>>>> + *
>>>>>> + * Sets the performance level by directly calling dev_pm_opp_set_level
>>>>>> + * on the performance device associated with the SE.
>>>>>> + *
>>>>>> + * Return: 0 on success, or a negative error code on failure.
>>>>>> + */
>>>>>> +int geni_se_set_perf_level(struct geni_se *se, unsigned long level)
>>>>>> +{
>>>>>> + return dev_pm_opp_set_level(se->pd_list->pd_devs[DOMAIN_IDX_PERF], level);
>>>>>> +}
>>>>>> +EXPORT_SYMBOL_GPL(geni_se_set_perf_level);
>>>>>
>>>>> This function is never used
>>>>
>>>> it will be used by UART driver, not for I2C/SPI.
>>>
>>> Adding unused exported symbols is "eeeh"..
>>
>> I keep in mind for UART, i have added this API.
>>>
>>>>>
>>>>>> +
>>>>>> +/**
>>>>>> + * geni_se_set_perf_opp() - Set performance OPP for GENI SE by frequency.
>>>>>> + * @se: Pointer to the struct geni_se instance.
>>>>>> + * @clk_freq: The requested clock frequency.
>>>>>> + *
>>>>>> + * Finds the nearest operating performance point (OPP) for the given
>>>>>> + * clock frequency and applies it to the SE's performance device.
>>>>>> + *
>>>>>> + * Return: 0 on success, or a negative error code on failure.
>>>>>> + */
>>>>>> +int geni_se_set_perf_opp(struct geni_se *se, unsigned long clk_freq)
>>>>>
>>>>> I think with the SPI driver in mind (which seems to do a simple rateset
>>>>
>>>> APIs were added as generic interfaces shared across I²C/SPI which is specific to firmware control, not Linux control.
>>>>
>>>>> for both backends) we could do:
>>>>>
>>>>>> +{
>>>>>> + struct device *perf_dev = se->pd_list->pd_devs[DOMAIN_IDX_PERF];
>>>>>
>>>>> Then, we can do struct device * perf_dev = se->dev;
>>>> I don't think, it is needed since this is specific to firmware control, not Linux control.
>>>
>>> My point is that it doesn't have to be specific to the auto usecase,
>>> further commonizing the code.
>>
>> This API will not useful for non-auto cases as well.
>
> This is only because you make it so, with the above suggestion we could
> do without the .set_rate abstraction in the SPI driver which only does
> an opp_set_rate in the generic case
For the generic .set_rate path (which is managed by Linux), we do more
than just call dev_pm_opp_set_rate(). The .set_rate callback also
performs additional hardware‑specific configuration as part of the rate
change.
SPI enablement on SA8255P follows this generic (non‑SCMI) path:
https://lore.kernel.org/all/20260112190134.1526646-5-praveen.talari@oss.qualcomm.com/
Below is the reference implementation of .set_rate used for the generic
(non‑SCMI) case:
+static const struct geni_spi_desc geni_spi = {
+ .resources_init = geni_se_resources_init,
+ .set_rate = geni_spi_set_clock_and_bw,
+ .power_on = geni_se_resources_activate,
+ .power_off = geni_se_resources_deactivate,
+};
static int geni_spi_set_clock_and_bw(struct spi_geni_master *mas,
unsigned long clk_hz)
{
u32 clk_sel, m_clk_cfg, idx, div;
struct geni_se *se = &mas->se;
int ret;
if (clk_hz == mas->cur_speed_hz)
return 0;
ret = get_spi_clk_cfg(clk_hz, mas, &idx, &div);
if (ret) {
dev_err(mas->dev, "Err setting clk to %lu: %d\n", clk_hz, ret);
return ret;
}
/*
* SPI core clock gets configured with the requested frequency
* or the frequency closer to the requested frequency.
* For that reason requested frequency is stored in the
* cur_speed_hz and referred in the consecutive transfer instead
* of calling clk_get_rate() API.
*/
mas->cur_speed_hz = clk_hz;
clk_sel = idx & CLK_SEL_MSK;
m_clk_cfg = (div << CLK_DIV_SHFT) | SER_CLK_EN;
writel(clk_sel, se->base + SE_GENI_CLK_SEL);
writel(m_clk_cfg, se->base + GENI_SER_M_CLK_CFG);
/* Set BW quota for CPU as driver supports FIFO mode only. */
se->icc_paths[CPU_TO_GENI].avg_bw = Bps_to_icc(mas->cur_speed_hz);
ret = geni_icc_set_bw(se);
if (ret)
return ret;
return 0;
}
In geni_spi_set_clock_and_bw(), the driver not only programs the SPI
clock, but also updates internal state and configures ICC bandwidth.
In particular, dev_pm_opp_set_rate() and dev_pm_opp_set_opp() serve
different purposes and are not interchangeable.
dev_pm_opp_set_rate() selects an OPP based on the requested frequency,
performs clock rounding, and programs both clocks and power supplies
accordingly.
On the other hand, dev_pm_opp_set_opp() assumes that the target OPP is
already known and applies it directly, without any frequency‑based
selection or rounding.
Given these differences, replacing dev_pm_opp_set_rate() with
geni_se_set_perf_opp() would not be equivalent in the generic .set_rate
flow.
/**
* dev_pm_opp_set_rate() - Configure new OPP based on frequency
* @dev: device for which we do this operation
* @target_freq: frequency to achieve
*
* This configures the power-supplies to the levels specified by the OPP
* corresponding to the target_freq, and programs the clock to a value <=
* target_freq, as rounded by clk_round_rate(). Device wanting to run
at fmax
* provided by the opp, should have already rounded to the target OPP's
* frequency.
*/
int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
{
struct opp_table *opp_table __free(put_opp_table);
struct dev_pm_opp *opp __free(put_opp) = NULL;
unsigned long freq = 0, temp_freq;
bool forced = false;
opp_table = _find_opp_table(dev);
if (IS_ERR(opp_table)) {
dev_err(dev, "%s: device's opp table doesn't exist\n", __func__);
return PTR_ERR(opp_table);
}
if (target_freq) {
/*
* For IO devices which require an OPP on some platforms/SoCs
* while just needing to scale the clock on some others
* we look for empty OPP tables with just a clock handle and
* scale only the clk. This makes dev_pm_opp_set_rate()
* equivalent to a clk_set_rate()
*/
if (!_get_opp_count(opp_table)) {
return opp_table->config_clks(dev, opp_table, NULL,
&target_freq, false);
}
freq = clk_round_rate(opp_table->clk, target_freq);
if ((long)freq <= 0)
freq = target_freq;
/*
* The clock driver may support finer resolution of the
* frequencies than the OPP table, don't update the frequency we
* pass to clk_set_rate() here.
*/
temp_freq = freq;
opp = _find_freq_ceil(opp_table, &temp_freq);
if (IS_ERR(opp)) {
dev_err(dev, "%s: failed to find OPP for freq %lu (%ld)\n",
__func__, freq, PTR_ERR(opp));
return PTR_ERR(opp);
}
/*
* An OPP entry specifies the highest frequency at which other
* properties of the OPP entry apply. Even if the new OPP is
* same as the old one, we may still reach here for a different
* value of the frequency. In such a case, do not abort but
* configure the hardware to the desired frequency forcefully.
*/
forced = opp_table->current_rate_single_clk != freq;
}
return _set_opp(dev, opp_table, opp, &freq, forced);
}
EXPORT_SYMBOL_GPL(dev_pm_opp_set_rate);
/**
* dev_pm_opp_set_opp() - Configure device for OPP
* @dev: device for which we do this operation
* @opp: OPP to set to
*
* This configures the device based on the properties of the OPP passed
to this
* routine.
*
* Return: 0 on success, a negative error number otherwise.
*/
int dev_pm_opp_set_opp(struct device *dev, struct dev_pm_opp *opp)
{
struct opp_table *opp_table __free(put_opp_table);
opp_table = _find_opp_table(dev);
if (IS_ERR(opp_table)) {
dev_err(dev, "%s: device opp doesn't exist\n", __func__);
return PTR_ERR(opp_table);
}
return _set_opp(dev, opp_table, opp, NULL, false);
}
Please correct me if my understanding is incorrect.
Thanks,
Praveen Talari
>
> Konrad
next prev parent reply other threads:[~2026-02-20 5:23 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 10:47 [PATCH v3 00/12] Enable I2C on SA8255p Qualcomm platforms Praveen Talari
2026-01-12 10:47 ` [PATCH v3 01/12] soc: qcom: geni-se: Refactor geni_icc_get() and make qup-memory ICC path optional Praveen Talari
2026-01-12 10:47 ` [PATCH v3 02/12] soc: qcom: geni-se: Add geni_icc_set_bw_ab() function Praveen Talari
2026-01-12 10:47 ` [PATCH v3 03/12] soc: qcom: geni-se: Introduce helper API for resource initialization Praveen Talari
2026-01-30 12:10 ` Konrad Dybcio
2026-01-30 17:00 ` Praveen Talari
2026-01-12 10:47 ` [PATCH v3 04/12] soc: qcom: geni-se: Add resources activation/deactivation helpers Praveen Talari
2026-01-30 12:11 ` Konrad Dybcio
2026-02-02 16:20 ` Praveen Talari
2026-01-12 10:47 ` [PATCH v3 05/12] soc: qcom: geni-se: Introduce helper API for attaching power domains Praveen Talari
2026-01-30 12:12 ` Konrad Dybcio
2026-01-30 16:55 ` Praveen Talari
2026-02-02 16:19 ` Praveen Talari
2026-01-12 10:47 ` [PATCH v3 06/12] soc: qcom: geni-se: Introduce helper APIs for performance control Praveen Talari
2026-01-30 12:23 ` Konrad Dybcio
2026-01-30 16:54 ` Praveen Talari
2026-02-03 11:14 ` Konrad Dybcio
2026-02-04 5:42 ` Praveen Talari
2026-02-17 12:25 ` Konrad Dybcio
2026-02-20 5:23 ` Praveen Talari [this message]
2026-02-23 13:43 ` Praveen Talari
2026-02-25 14:25 ` Konrad Dybcio
2026-01-12 10:47 ` [PATCH v3 07/12] dt-bindings: i2c: Describe SA8255p Praveen Talari
2026-01-12 10:47 ` [PATCH v3 08/12] i2c: qcom-geni: Isolate serial engine setup Praveen Talari
2026-01-21 7:47 ` Viken Dadhaniya
2026-01-12 10:47 ` [PATCH v3 09/12] i2c: qcom-geni: Move resource initialization to separate function Praveen Talari
2026-01-21 8:57 ` Viken Dadhaniya
2026-01-12 10:47 ` [PATCH v3 10/12] i2c: qcom-geni: Use resources helper APIs in runtime PM functions Praveen Talari
2026-01-21 8:58 ` Viken Dadhaniya
2026-01-30 12:05 ` Konrad Dybcio
2026-01-30 16:48 ` Praveen Talari
2026-02-03 11:13 ` Konrad Dybcio
2026-02-04 5:46 ` Praveen Talari
2026-01-12 10:47 ` [PATCH v3 11/12] i2c: qcom-geni: Store of_device_id data in driver private struct Praveen Talari
2026-01-21 8:59 ` Viken Dadhaniya
2026-01-30 12:29 ` Konrad Dybcio
2026-02-02 16:19 ` Praveen Talari
2026-01-12 10:47 ` [PATCH v3 12/12] i2c: qcom-geni: Enable I2C on SA8255p Qualcomm platforms Praveen Talari
2026-01-21 10:21 ` Viken Dadhaniya
2026-01-30 12:34 ` Konrad Dybcio
2026-01-30 16:44 ` Praveen Talari
2026-02-02 14:53 ` Konrad Dybcio
2026-02-04 5:43 ` Praveen Talari
2026-01-14 15:05 ` [PATCH v3 00/12] " Andi Shyti
2026-01-28 22:49 ` [SPAM] " Andi Shyti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85bb3a9f-d54a-4b4c-8dbb-6d5461ebb037@oss.qualcomm.com \
--to=praveen.talari@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=andi.shyti@kernel.org \
--cc=aniket.randive@oss.qualcomm.com \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=bryan.odonoghue@linaro.org \
--cc=chandana.chiluveru@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mukesh.savaliya@oss.qualcomm.com \
--cc=prasad.sodagudi@oss.qualcomm.com \
--cc=quic_vtanuku@quicinc.com \
--cc=robh@kernel.org \
--cc=viken.dadhaniya@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox