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@xxxxxxxxxxxxx> > > Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > > --- > > 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 |
