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:

-- 
2.34.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

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 ?

-- 
viresh

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.

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

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
>

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

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>

-- 
viresh