lkml.org 
[lkml]   [2023]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v7 09/26] PM / devfreq: rockchip-dfi: Clean up DDR type register defines
    From
    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

    \
     
     \ /
      Last update: 2023-10-17 10:34    [W:4.878 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site