diff mbox series

[3/3] cpufreq: qcom-nvmem: add support for IPQ5321

Message ID 20240228-ipq5321-sku-support-v1-3-14e4d4715f4b@quicinc.com (mailing list archive)
State New
Delegated to: viresh kumar
Headers show
Series Add support for the IPQ5321 SoC | expand

Commit Message

Kathiravan Thirumoorthy Feb. 28, 2024, 2:51 p.m. UTC
Like all other SoCs in IPQ5332 family, cpufreq for IPQ5321 is also
determined by the eFuse, with the maximum limit of 1.1GHz. Add support
for the same.

Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
---
 drivers/cpufreq/qcom-cpufreq-nvmem.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Viresh Kumar March 4, 2024, 7:12 a.m. UTC | #1
On 28-02-24, 20:21, Kathiravan Thirumoorthy wrote:
> Like all other SoCs in IPQ5332 family, cpufreq for IPQ5321 is also
> determined by the eFuse, with the maximum limit of 1.1GHz. Add support
> for the same.
> 
> Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
> ---
>  drivers/cpufreq/qcom-cpufreq-nvmem.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> index ea05d9d67490..0a46b5d49d32 100644
> --- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> @@ -191,6 +191,7 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
>  	case QCOM_ID_IPQ5312:
>  	case QCOM_ID_IPQ5302:
>  	case QCOM_ID_IPQ5300:
> +	case QCOM_ID_IPQ5321:
>  	case QCOM_ID_IPQ9514:
>  	case QCOM_ID_IPQ9550:
>  	case QCOM_ID_IPQ9554:

Applied. Thanks.
Viresh Kumar March 5, 2024, 4:35 a.m. UTC | #2
On 04-03-24, 12:42, Viresh Kumar wrote:
> On 28-02-24, 20:21, Kathiravan Thirumoorthy wrote:
> > Like all other SoCs in IPQ5332 family, cpufreq for IPQ5321 is also
> > determined by the eFuse, with the maximum limit of 1.1GHz. Add support
> > for the same.
> > 
> > Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
> > ---
> >  drivers/cpufreq/qcom-cpufreq-nvmem.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> > index ea05d9d67490..0a46b5d49d32 100644
> > --- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
> > +++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> > @@ -191,6 +191,7 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
> >  	case QCOM_ID_IPQ5312:
> >  	case QCOM_ID_IPQ5302:
> >  	case QCOM_ID_IPQ5300:
> > +	case QCOM_ID_IPQ5321:
> >  	case QCOM_ID_IPQ9514:
> >  	case QCOM_ID_IPQ9550:
> >  	case QCOM_ID_IPQ9554:
> 
> Applied. Thanks.

Dropped since the previous commit it required too. Can we get the
necessary acks for me to pick those ?
Kathiravan Thirumoorthy March 6, 2024, 4:40 a.m. UTC | #3
On 3/5/2024 10:05 AM, Viresh Kumar wrote:
> On 04-03-24, 12:42, Viresh Kumar wrote:
>> On 28-02-24, 20:21, Kathiravan Thirumoorthy wrote:
>>> Like all other SoCs in IPQ5332 family, cpufreq for IPQ5321 is also
>>> determined by the eFuse, with the maximum limit of 1.1GHz. Add support
>>> for the same.
>>>
>>> Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
>>> ---
>>>   drivers/cpufreq/qcom-cpufreq-nvmem.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
>>> index ea05d9d67490..0a46b5d49d32 100644
>>> --- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
>>> +++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
>>> @@ -191,6 +191,7 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
>>>   	case QCOM_ID_IPQ5312:
>>>   	case QCOM_ID_IPQ5302:
>>>   	case QCOM_ID_IPQ5300:
>>> +	case QCOM_ID_IPQ5321:
>>>   	case QCOM_ID_IPQ9514:
>>>   	case QCOM_ID_IPQ9550:
>>>   	case QCOM_ID_IPQ9554:
>>
>> Applied. Thanks.
> 
> Dropped since the previous commit it required too. Can we get the
> necessary acks for me to pick those ?
> 

Sorry for not mentioning the dependencies.

patch 1/3 and 2/3 are already has the R-b and A-b tags. But typically 
those patches will go via qcom tree. Do you want to pick it via your 
tree? Sorry, I'm not sure on this...


Thanks,
Kathiravan T.
Viresh Kumar March 6, 2024, 5:18 a.m. UTC | #4
Bjorn,

On 06-03-24, 10:10, Kathiravan Thirumoorthy wrote:
> patch 1/3 and 2/3 are already has the R-b and A-b tags. But typically those
> patches will go via qcom tree. Do you want to pick it via your tree? Sorry,
> I'm not sure on this...

Should I pick all the patches ?
Viresh Kumar March 6, 2024, 5:32 a.m. UTC | #5
On 06-03-24, 10:48, Viresh Kumar wrote:
> Bjorn,
> 
> On 06-03-24, 10:10, Kathiravan Thirumoorthy wrote:
> > patch 1/3 and 2/3 are already has the R-b and A-b tags. But typically those
> > patches will go via qcom tree. Do you want to pick it via your tree? Sorry,
> > I'm not sure on this...
> 
> Should I pick all the patches ?

Okay, there are conflicts for the first patch itself. Bjorn you can
apply all the patches.

For this patch:

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Krzysztof Kozlowski March 6, 2024, 7:22 a.m. UTC | #6
On 06/03/2024 05:40, Kathiravan Thirumoorthy wrote:
>>>
>>> Applied. Thanks.
>>
>> Dropped since the previous commit it required too. Can we get the
>> necessary acks for me to pick those ?
>>
> 
> Sorry for not mentioning the dependencies.
> 
> patch 1/3 and 2/3 are already has the R-b and A-b tags. But typically 

From whom? Not from Qualcomm SoC maintainers.

> those patches will go via qcom tree. Do you want to pick it via your 
> tree? Sorry, I'm not sure on this...

Your cover letter or patch changelog should clearly document
dependencies, so maintainers could understand what to do with this patch.

Best regards,
Krzysztof
Kathiravan Thirumoorthy March 6, 2024, 8 a.m. UTC | #7
On 3/6/2024 12:52 PM, Krzysztof Kozlowski wrote:
> On 06/03/2024 05:40, Kathiravan Thirumoorthy wrote:
>>>>
>>>> Applied. Thanks.
>>>
>>> Dropped since the previous commit it required too. Can we get the
>>> necessary acks for me to pick those ?
>>>
>>
>> Sorry for not mentioning the dependencies.
>>
>> patch 1/3 and 2/3 are already has the R-b and A-b tags. But typically
> 
>  From whom? Not from Qualcomm SoC maintainers.


Does the "necessary acks" refers for to the acks from Qualcomm SoC 
maintainers? Sorry, I wasn't aware of that. That's why I mentioned 
"Sorry, I'm not sure on this..." couple of lines below.


> 
>> those patches will go via qcom tree. Do you want to pick it via your
>> tree? Sorry, I'm not sure on this...
> 
> Your cover letter or patch changelog should clearly document
> dependencies, so maintainers could understand what to do with this patch.


Understood. Will take care in future.


> 
> Best regards,
> Krzysztof
>
diff mbox series

Patch

diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
index ea05d9d67490..0a46b5d49d32 100644
--- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
+++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
@@ -191,6 +191,7 @@  static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
 	case QCOM_ID_IPQ5312:
 	case QCOM_ID_IPQ5302:
 	case QCOM_ID_IPQ5300:
+	case QCOM_ID_IPQ5321:
 	case QCOM_ID_IPQ9514:
 	case QCOM_ID_IPQ9550:
 	case QCOM_ID_IPQ9554: