[U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Simon Goldschmidt]

On Mon, Jan 14, 2019 at 11:26 PM Dinh Nguyen <dinguyen at kernel.org> wrote:
>
>
>
> On 1/14/19 10:05 AM, Simon Goldschmidt wrote:
> > Hi Dinh,
> >
> > Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
> >> Hi Simon,
> >>
> >> On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> >>> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
> >>>> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> >>>>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
> >>>>>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>>>>>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> >>>>>>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
> >>>>>>> disabled
> >>>>>>> via defconfig.
> >>>>>>>
> >>>>>>> This also seems to be required to use OF_PLATDATA, as the reset
> >>>>>>> drivers
> >>>>>>> don't seem to work with it.
> >>>>>>
> >>>>>> How do you un-reset IP blocks if you disable the reset controller ?
> >>>>>
> >>>>> I found that out just now: there's the function
> >>>>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
> >>>>> "De-assert reset for peripherals and bridges based on handoff".
> >>>>> However,
> >>>>> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
> >>>>> that, it enables *ALL* peripherals on the SoC (except for some DMA
> >>>>> channels that aren't really used) :-)
> >>>>>
> >>>>> I guess that needs some cleaning up as well ;-)
> >>>>
> >>>> Yes
> >>>>
> >>>>> I think the proper thing to do here would be to remove this
> >>>>> function and
> >>>>> convert all drivers to provide appropriate 'resets' properties in the
> >>>>> dts?
> >>>>
> >>>> Indeed
> >>>
> >>> So I just did that and it works nice for SPL and U-Boot: By adding some
> >>> "resets" properties the the main dtsi and adding reset bulk code to the
> >>> cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
> >>> code from arch/mach_socfpga.
> >>>
> >>> The problem would be that now Linux cannot use peripherals that aren't
> >>> enabled by U-Boot because it relies on them being enabled. How are such
> >>> dependencies solved? Because even if I would add reset support in the
> >>> corresponding Linux drivers, we probably could not bootolder Kernels
> >>> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
> >>>
> >>
> >> I added an early reset driver for SoCFPGA that should take care of this.
> >> The patch is in v5.0-rc2[1].
> >
> > OK, it's good to know that this work is already done, I haven't
> > monitored this close enough.
> >
> > But am I correct that my above problem remains even in v5.0 as not all
> > peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
> > qspi) and would thuse not be taken out of reset by Linux?
> >
>
> Yes, I see that. I will send a patch for those.

OK, great! I don't know the driver structure in Linux as well, will that be a
dts change only or does it require changing the mmc/qspi drivers to deassert
those resets?

The reset handles are also missing for yet more peripherals, I have prepared
this as a patch for U-Boot, but I guess the devicetree is still in sync, so I
could send this patch for Linux as well?

Regards,
Simon