[U-Boot] [PATCH 1/3] arm: socfpga: Convert reset manager from struct to defines

[Ley Foon Tan]

On Fri, Aug 23, 2019 at 5:56 PM Marek Vasut <marex at denx.de> wrote:
>
> On 8/23/19 11:52 AM, Ley Foon Tan wrote:
> > On Fri, Aug 23, 2019 at 5:23 PM Marek Vasut <marex at denx.de> wrote:
> >>
> >> On 8/23/19 10:57 AM, Ley Foon Tan wrote:
> >>> On Wed, Aug 21, 2019 at 9:50 AM Ley Foon Tan <lftan.linux at gmail.com> wrote:
> >>>>
> >>>> On Tue, Aug 20, 2019 at 5:50 PM Marek Vasut <marex at denx.de> wrote:
> >>>>>
> >>>>> On 8/20/19 4:35 AM, Ley Foon Tan wrote:
> >>>>>> Convert reset manager for Gen5, Arria 10 and Stratix 10 from struct
> >>>>>> to defines.
> >>>>>> No functional change.
> >>>>>>
> >>>>>> Signed-off-by: Ley Foon Tan <ley.foon.tan at intel.com>
> >>>>>> ---
> >>>>>>  .../mach-socfpga/include/mach/reset_manager.h | 12 +++++
> >>>>>>  .../include/mach/reset_manager_arria10.h      | 41 +++-------------
> >>>>>>  .../include/mach/reset_manager_gen5.h         | 20 +++-----
> >>>>>>  .../include/mach/reset_manager_s10.h          | 33 ++-----------
> >>>>>>  arch/arm/mach-socfpga/misc_gen5.c             |  6 +--
> >>>>>>  arch/arm/mach-socfpga/reset_manager_arria10.c | 49 +++++++++----------
> >>>>>>  arch/arm/mach-socfpga/reset_manager_gen5.c    | 26 +++++-----
> >>>>>>  arch/arm/mach-socfpga/reset_manager_s10.c     | 35 ++++++-------
> >>>>>>  drivers/sysreset/sysreset_socfpga.c           |  6 +--
> >>>>>>  9 files changed, 86 insertions(+), 142 deletions(-)
> >>>>>>
> >>>>>> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> >>>>>> index 6ad037e325..c460e89d22 100644
> >>>>>> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> >>>>>> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> >>>>>> @@ -6,6 +6,18 @@
> >>>>>>  #ifndef _RESET_MANAGER_H_
> >>>>>>  #define _RESET_MANAGER_H_
> >>>>>>
> >>>>>> +#define RSTMGR_READL(reg)                    \
> >>>>>> +     readl(SOCFPGA_RSTMGR_ADDRESS + (reg))
> >>>>>> +
> >>>>>> +#define RSTMGR_WRITEL(data, reg)             \
> >>>>>> +     writel(data, SOCFPGA_RSTMGR_ADDRESS + (reg))
> >>>>>> +
> >>>>>> +#define RSTMGR_CLRBITS(reg, mask)            \
> >>>>>> +     clrbits_le32(SOCFPGA_RSTMGR_ADDRESS + (reg), mask)
> >>>>>> +
> >>>>>> +#define RSTMGR_SETBITS(reg, mask)            \
> >>>>>> +     setbits_le32(SOCFPGA_RSTMGR_ADDRESS + (reg), mask)
> >>
> >> btw. mask is missing parenthesis, but see below.
> >>
> >>>>>> +
> >>>>>
> >>>>> No, don't introduce such macros. Use readl()/writel()/... in the driver.
> >>>>> The address should come from DT. Besides, there is no type checking in
> >>>>> such macros.
> >>>> These macros call to writel() and readl() underlying, it just add base
> >>>> address to it.
> >>
> >> Right, it just makes the code hardware to read and understand.
> > Okay, will change it.
>
> It should be easy to do:
> $ sed "s at RSTMGR_SETBITS(\([^,]\+\),
> \([^)]\+\))@setbits_le32(SOCFPGA_RSTMGR_ADDRESS + \1, \1)@"
> $ git add -u ; git commit -sm part1
> $ checkpatch -f --fix --fix-inplace <file>
> $ git diff # review the fixes
> $ git add -u ; git commit --amend #
>
> >>>> So, it should have type checking as call writel()/readl() directly?
> >>
> >> The functions in the macro get typechecked. But unlike function
> >> arguments, macro arguments are not checked.
> > Noted.
> >>
> >>>> If want to use address from DT, we need get address every time need to
> >>>> use the address.
> >>>> For non-DM, it is easier to use constant address. Let me know if you
> >>>> still prefer to use address from DT.
> >>
> >> Surely you can cache the address or even better, convert to DM/DT ?
> > Will try to cache the address for now.  But, we need get address from
> > DT twice, one in SPL, one in Uboot. They not sharing global data.
>
> I don't think there's much we can do about that, unless we can somehow
> share parsed live DT from SPL to U-Boot, but that's for another
> discussion/patchset/etc.
I am working on this now and found there are 2 challenges if we get
base address from DT.
1. We can only get the address from DT after gd->fdt_blob is
initialized in spl_early_init(). So, spl_early_init() need move to
beginning of board_init_f().
   Tested this on Agilex, look okay. But, pending test on other device
families, like Gen5 or A10. Not sure any side effect with this change.
2. Secure (for PSCI) and non-secure functions share same functions,
these functions can't use global data (for base address). Secure
functions have its own secure data region.
#2 is more difficult to overcome. Do you have strong opinion to get
base address from DT? Otherwise, can we use constant define for these
base addresses?

Thanks.

Regards
Ley Foon