Re: [PATCH v2 5/5] soc: qcom: llcc: Add regmap for Broadcast_AND region

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

 



On 2/6/2024 10:42 AM, Konrad Dybcio wrote:
> On 6.02.2024 08:15, Unnathi Chalicheemala wrote:
>> Define new regmap structure for Broadcast_AND region and initialize
>> regmap for Broadcast_AND region when HW block version
>> is greater than 4.1 for backwards compatibility.
> 
> Are they actually separate regions and not a single contiguous one?
> 

Yes, they are separate regions.

>>
>> Switch from broadcast_OR to broadcast_AND region for checking
>> status bit 1 as Broadcast_OR region checks only for bit 0.
>>
>> Signed-off-by: Unnathi Chalicheemala <quic_uchalich@xxxxxxxxxxx>
>> ---
>>  drivers/soc/qcom/llcc-qcom.c       | 22 +++++++++++++++++++---
>>  include/linux/soc/qcom/llcc-qcom.h |  4 +++-
>>  2 files changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c
>> index 4ca88eaebf06..fbd2542cd4c5 100644
>> --- a/drivers/soc/qcom/llcc-qcom.c
>> +++ b/drivers/soc/qcom/llcc-qcom.c
>> @@ -849,9 +849,14 @@ static int llcc_update_act_ctrl(u32 sid,
>>  		return ret;
>>  
>>  	if (drv_data->version >= LLCC_VERSION_4_1_0_0) {
>> -		ret = regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg,
>> -				      slice_status, (slice_status & ACT_COMPLETE),
>> -				      0, LLCC_STATUS_READ_DELAY);
>> +		if (!drv_data->bcast_and_regmap)
>> +			ret = regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg,
>> +					slice_status, (slice_status & ACT_COMPLETE),
>> +					0, LLCC_STATUS_READ_DELAY);
>> +		else
>> +			ret = regmap_read_poll_timeout(drv_data->bcast_and_regmap, status_reg,
>> +					slice_status, (slice_status & ACT_COMPLETE),
>> +					0, LLCC_STATUS_READ_DELAY);
> 
> struct regmap *regmap = drv_data->bcast_and_regmap ?: bcast_regmap;
> 
> ?

Ack. Will minimize the redundancy.

> 
>> +	if (drv_data->version >= LLCC_VERSION_4_1_0_0) {
> 
> This check is rather redundant.. If there's no such region in hardware,
> it won't be described, and as such the _get()s will return some sort
> of an error.
> 

I see what you're saying.

> Might as well make it a comment that it's intended for >=v4.1 and
> definitely leave a comment for the next guy that there's a backwards
> compatibility quirk involved..

Ack.
Thanks for the review Konrad!

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