| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <d0bb9b15-991d-4b87-be42-4f183d560b5e@kernel.org>
Date: Tue, 17 Oct 2023 17:34:02 +0900
From: Chanwoo Choi <chanwoo@...nel.org>
To: Sascha Hauer <s.hauer@...gutronix.de>
Cc: linux-rockchip@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, Heiko Stuebner <heiko@...ech.de>,
Kyungmin Park <kyungmin.park@...sung.com>,
MyungJoo Ham <myungjoo.ham@...sung.com>,
Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>, kernel@...gutronix.de,
Michael Riesch <michael.riesch@...fvision.net>,
Robin Murphy <robin.murphy@....com>,
Vincent Legoll <vincent.legoll@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
Sebastian Reichel <sebastian.reichel@...labora.com>
Subject: Re: [PATCH v7 09/26] PM / devfreq: rockchip-dfi: Clean up DDR type
register defines
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@...labora.com>
>>> Signed-off-by: Sascha Hauer <s.hauer@...gutronix.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@...sung.com>
--
Best Regards,
Samsung Electronics
Chanwoo Choi
Powered by blists - more mailing lists