| 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: <20231016120351.GA3359458@pengutronix.de>
Date: Mon, 16 Oct 2023 14:03:51 +0200
From: Sascha Hauer <s.hauer@...gutronix.de>
To: Chanwoo Choi <chanwoo@...nel.org>
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 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
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Powered by blists - more mailing lists