Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Message-ID: <d0bb9b15-991d-4b87-be42-4f183d560b5e@kernel.org>
Date:   Tue, 17 Oct 2023 17:34:02 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 09/26] PM / devfreq: rockchip-dfi: Clean up DDR type
 register defines
Content-Language: en-US
To:     Sascha Hauer <s.hauer@pengutronix.de>
Cc:     linux-rockchip@lists.infradead.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-pm@vger.kernel.org, Heiko Stuebner <heiko@sntech.de>,
        Kyungmin Park <kyungmin.park@samsung.com>,
        MyungJoo Ham <myungjoo.ham@samsung.com>,
        Will Deacon <will@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>, kernel@pengutronix.de,
        Michael Riesch <michael.riesch@wolfvision.net>,
        Robin Murphy <robin.murphy@arm.com>,
        Vincent Legoll <vincent.legoll@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>, devicetree@vger.kernel.org,
        Sebastian Reichel <sebastian.reichel@collabora.com>
References: <20230704093242.583575-1-s.hauer@pengutronix.de>
 <20230704093242.583575-10-s.hauer@pengutronix.de>
 <1eaa8d5b-af6b-71bb-df7a-d438b483f5bb@kernel.org>
 <20231016120351.GA3359458@pengutronix.de>
From:   Chanwoo Choi <chanwoo@kernel.org>
In-Reply-To: <20231016120351.GA3359458@pengutronix.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 23. 10. 16. 21:03, Sascha Hauer wrote:
> On Sat, Oct 07, 2023 at 04:11:22AM +0900, Chanwoo Choi wrote:
>> On 23. 7. 4. 18:32, Sascha Hauer wrote:
>>> Use the HIWORD_UPDATE() define known from other rockchip drivers to
>>> make the defines look less odd to the readers who've seen other
>>> rockchip drivers.
>>>
>>> The HIWORD registers have their functional bits in the lower 16 bits
>>> whereas the upper 16 bits contain a mask. Only the functional bits that
>>> have the corresponding mask bit set are modified during a write. Although
>>> the register writes look different, the end result should be the same,
>>> at least there's no functional change intended with this patch.
>>>
>>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>> ---
>>>  drivers/devfreq/event/rockchip-dfi.c | 33 ++++++++++++++++++----------
>>>  1 file changed, 21 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/event/rockchip-dfi.c b/drivers/devfreq/event/rockchip-dfi.c
>>> index 6bccb6fbcfc0c..6b3ef97b3be09 100644
>>> --- a/drivers/devfreq/event/rockchip-dfi.c
>>> +++ b/drivers/devfreq/event/rockchip-dfi.c
>>> @@ -26,15 +26,19 @@
>>>  
>>>  #define DMC_MAX_CHANNELS	2
>>>  
>>> +#define HIWORD_UPDATE(val, mask)	((val) | (mask) << 16)
>>> +
>>>  /* DDRMON_CTRL */
>>>  #define DDRMON_CTRL	0x04
>>> -#define CLR_DDRMON_CTRL	(0x1f0000 << 0)
>>> -#define LPDDR4_EN	(0x10001 << 4)
>>> -#define HARDWARE_EN	(0x10001 << 3)
>>> -#define LPDDR3_EN	(0x10001 << 2)
>>> -#define SOFTWARE_EN	(0x10001 << 1)
>>> -#define SOFTWARE_DIS	(0x10000 << 1)
>>> -#define TIME_CNT_EN	(0x10001 << 0)
>>> +#define DDRMON_CTRL_DDR4		BIT(5)
>>> +#define DDRMON_CTRL_LPDDR4		BIT(4)
>>> +#define DDRMON_CTRL_HARDWARE_EN		BIT(3)
>>> +#define DDRMON_CTRL_LPDDR23		BIT(2)
>>> +#define DDRMON_CTRL_SOFTWARE_EN		BIT(1)
>>> +#define DDRMON_CTRL_TIMER_CNT_EN	BIT(0)
>>> +#define DDRMON_CTRL_DDR_TYPE_MASK	(DDRMON_CTRL_DDR4 | \
>>> +					 DDRMON_CTRL_LPDDR4 | \
>>> +					 DDRMON_CTRL_LPDDR23)
>>>  
>>>  #define DDRMON_CH0_COUNT_NUM		0x28
>>>  #define DDRMON_CH0_DFI_ACCESS_NUM	0x2c
>>> @@ -73,16 +77,20 @@ static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
>>>  	void __iomem *dfi_regs = dfi->regs;
>>>  
>>>  	/* clear DDRMON_CTRL setting */
>>> -	writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
>>> +	writel_relaxed(HIWORD_UPDATE(0, DDRMON_CTRL_TIMER_CNT_EN | DDRMON_CTRL_SOFTWARE_EN |
>>> +		       DDRMON_CTRL_HARDWARE_EN), dfi_regs + DDRMON_CTRL);
>>
>> You mentioned that there are no behavior changes even if the different value is written.
>> But, it looks strange. Could you please explain more detailed about it?
> 
> Many registers on Rockchip SoCs are effectively only 16 bits wide. The
> lower 16 bits are the functional bits. The upper 16 bits contain a mask
> value. The lower 16 bits are only modified when the coresponding bit in
> the upper 16bits is set.
> 
> For example writing 0x0001dead has the same effect as writing
> 0x00010001: The lower bit is set, the remaining are unchanged due to the
> mask value being 0.
> 
>>
>>
>> CLR_DDRMON_CTRL is 0x1f0000
> 
> This clears the lower 5 bits.
> 
>> vs.
>> HIWORD_UPDATE(0, DDRMON_CTRL_TIMER_CNT_EN | DDRMON_CTRL_SOFTWARE_EN | DDRMON_CTRL_HARDWARE_EN) = (0 | (BIT(0)|BIT(1)|BIT(3))<<16) = 0xb0000
> 
> This clears BIT(0), BIT(1) and BIT(3), so it clears:
> 
> DDRMON_CTRL_TIMER_CNT_EN, DDRMON_CTRL_SOFTWARE_EN and DDRMON_CTRL_HARDWARE_EN.
> 
> In fact it doesn't clear DDRMON_CTRL_LPDDR23 and DDRMON_CTRL_LPDDR4 like
> the operation with CLR_DDRMON_CTRL does, but the LPDDR type bits are
> handled below:
> 
>> 			
>>>  
>>>  	/* set ddr type to dfi */
>>>  	if (dfi->ddr_type == ROCKCHIP_DDRTYPE_LPDDR3)
>>> -		writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
>>> +		writel_relaxed(HIWORD_UPDATE(DDRMON_CTRL_LPDDR23, DDRMON_CTRL_DDR_TYPE_MASK),
>>> +			       dfi_regs + DDRMON_CTRL);
>>
>> LPDDR3_EN	(0x10001 << 2) = 0x40004
> 
> This sets BIT(2) aka DDRMON_CTRL_LPDDR23
> 
>> vs.
>> HIWORD_UPDATE(DDRMON_CTRL_LPDDR23, DDRMON_CTRL_DDR_TYPE_MASK) = (BIT(2) | (BIT(5)|BIT(4)|BIT(2))<<16) = 0x340004
> 
> This sets BIT(2) and *clears* BIT(4) (DDRMON_CTRL_LPDDR4) and BIT(5)
> (DDRMON_CTRL_DDR4). So effectively we no longer clear BIT(4) in the
> first register access as we do with CLR_DDRMON_CTRL, but in the second
> register access instead.
> 
> This also clears BIT(5) which was untouched previously, but this bit had
> never been set by the driver, so should be 0 anyway.
> 
> Sascha
> 

Thanks for the detailed reply.

Acked-by: Chanwoo Choi <cw00.choi@samsung.com>

-- 
Best Regards,
Samsung Electronics
Chanwoo Choi