Re: [PATCH v2 17/20] media: venus: pm_helpers: Commonize getting clocks and GenPDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4.03.2024 8:13 AM, Dikshita Agarwal wrote:
> 
> 
> On 2/10/2024 2:40 AM, Konrad Dybcio wrote:
>> As has been the story with the past few commits, much of the resource
>> acquisition logic is totally identical between different generations
>> and there's no good reason to invent a new function for each one.
>>
>> Commonize core_get() and rename it to venus_get_resources() to be more
>> meaningful.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
>> ---
>>  drivers/media/platform/qcom/venus/core.c       | 8 +++-----
>>  drivers/media/platform/qcom/venus/pm_helpers.c | 5 +----
>>  drivers/media/platform/qcom/venus/pm_helpers.h | 3 +--
>>  3 files changed, 5 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
>> index 680674dd0d68..873affe17537 100644
>> --- a/drivers/media/platform/qcom/venus/core.c
>> +++ b/drivers/media/platform/qcom/venus/core.c
>> @@ -334,11 +334,9 @@ static int venus_probe(struct platform_device *pdev)
>>  			return PTR_ERR(core->resets[i]);
>>  	}
>>  
>> -	if (core->pm_ops->core_get) {
>> -		ret = core->pm_ops->core_get(core);
>> -		if (ret)
>> -			return ret;
>> -	}
>> +	ret = venus_get_resources(core);
>> +	if (ret)
>> +		return ret;
>>  
>>  	ret = dma_set_mask_and_coherent(dev, res->dma_mask);
>>  	if (ret)
>> diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
>> index a292c788ffba..1cbcffbc29af 100644
>> --- a/drivers/media/platform/qcom/venus/pm_helpers.c
>> +++ b/drivers/media/platform/qcom/venus/pm_helpers.c
>> @@ -326,7 +326,6 @@ static int load_scale_v1(struct venus_inst *inst)
>>  }
>>  
>>  static const struct venus_pm_ops pm_ops_v1 = {
>> -	.core_get = venus_clks_get,
> core_get is initialized with venus_clks_get in patch 4 and then being
> removed here. It would be better to combine both patches.

Generally I'd agree, but this series is rather big and both patch 4 and
this one are logically separated well enough, so I'd rather not waste time
moving things around and fighting merge conflicts for no functional change

Konrad




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux