On Monday, 26 August 2024 10:39:58 EDT Dragan Simic wrote:
> Hello Detlev,
>
> On 2024-08-23 15:34, Detlev Casanova wrote:
> > On Friday, 23 August 2024 01:41:44 EDT Dragan Simic wrote:
> >> Hello Detlev,
> >>
> >> Please see a comment below.
> >>
> >> On 2024-08-22 23:15, Detlev Casanova wrote:
> >> > From: Shawn Lin <shawn.lin@xxxxxxxxxxxxxx>
> >> >
> >> > Some Rockchip devices put the phase settings into the dw_mmc
> >> > controller.
> >> >
> >> > When the feature is present, the ciu-drive and ciu-sample clocks are
> >> > not used and the phase configuration is done directly through the mmc
> >> > controller.
> >> >
> >> > Signed-off-by: Shawn Lin <shawn.lin@xxxxxxxxxxxxxx>
> >> > Signed-off-by: Detlev Casanova <detlev.casanova@xxxxxxxxxxxxx>
> >> > Acked-by: Shawn Lin <shawn.lin@xxxxxxxxxxxxxx>
> >> > ---
> >> >
> >> > drivers/mmc/host/dw_mmc-rockchip.c | 171 +++++++++++++++++++++++++++--
> >> > 1 file changed, 160 insertions(+), 11 deletions(-)
> >> >
> >> > diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
> >> > b/drivers/mmc/host/dw_mmc-rockchip.c
> >> > index b07190ba4b7a..2748f9bf2691 100644
> >> > --- a/drivers/mmc/host/dw_mmc-rockchip.c
> >> > +++ b/drivers/mmc/host/dw_mmc-rockchip.c
> >> > @@ -15,7 +15,17 @@
> >> >
> >> > #include "dw_mmc.h"
> >> > #include "dw_mmc-pltfm.h"
> >> >
> >> > -#define RK3288_CLKGEN_DIV 2
> >> > +#define RK3288_CLKGEN_DIV 2
> >> > +#define SDMMC_TIMING_CON0 0x130
> >> > +#define SDMMC_TIMING_CON1 0x134
> >> > +#define ROCKCHIP_MMC_DELAY_SEL BIT(10)
> >> > +#define ROCKCHIP_MMC_DEGREE_MASK 0x3
> >> > +#define ROCKCHIP_MMC_DEGREE_OFFSET 1
> >> > +#define ROCKCHIP_MMC_DELAYNUM_OFFSET 2
> >> > +#define ROCKCHIP_MMC_DELAYNUM_MASK (0xff <<
> >> > ROCKCHIP_MMC_DELAYNUM_OFFSET)
> >> > +#define ROCKCHIP_MMC_DELAY_ELEMENT_PSEC 60
> >> > +#define HIWORD_UPDATE(val, mask, shift) \
> >> > + ((val) << (shift) | (mask) << ((shift) + 16))
> >> >
> >> > static const unsigned int freqs[] = { 100000, 200000, 300000, 400000
> >> >
> >> > };
> >> >
> >> > @@ -24,8 +34,143 @@ struct dw_mci_rockchip_priv_data {
> >> >
> >> > struct clk *sample_clk;
> >> > int default_sample_phase;
> >> > int num_phases;
> >> >
> >> > + int internal_phase;
> >> >
> >> > };
> >>
> >> It might be good to declare internal_phase as "unsigned int
> >> internal_phase:1",
> >> i.e. as a bit field, which isn't going to save some memory in this
> >> particular
> >> case, but it would show additional attention to detail.
> >
> > In that case, I would go with a bool instead of int, that makes things
> > even clearer.
>
> My suggestion to use "unsigned int internal_phase:1" actually takes
> inspiration from the ASoC code, in which such bit fields are used
> quite a lot, even when using them actually doesn't save space.
>
> In this particular case, using plain bool would make sense, but I
> still think that using an "unsigned int internal_phase:1" bit field
> would fit better, because it would show the intention to possibly
> save a bit of RAM at some point. OTOH, I don't think that using
> bool with such bit fields would actually work cleanly, because bool
> actually resolves to int that's a signed type.
I wouldn't use bool with a bit field of course. I've always considered using
bit fileds only for structs that must have a certain format, like a header
format definition.
For me, it is better to use "bool internal_phase" so that it is obvious that
the feature can be on or off when reading the code.
When using bit fields with a struct that is not marked as "__packed", I
immediately think that there could be a bug there and wonder why the bit field
is used, not really thinking "the dev wanted to show they cared about memory
usage".
But I guess that is all about preferences. In the end, it won't change how it
works.
Detlev.
