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

[Tom Rini <trini@konsulko.com>]

On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:
> On 1/8/19 1:46 PM, Simon Goldschmidt wrote:
> > On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
> >>> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut <marex@denx.de> wrote:
> >>>>
> >>>> On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> >>>>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut <marex@denx.de> wrote:
> >>>>>>
> >>>>>> 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 ?
> >>>>>
> >>>>> Here again, socfpga seems to be another bad example. Taking
> >>>>> peripherals out of reset
> >>>>> is cluttered throughout the mach-socfpga code at least in SPL. By now
> >>>>> I know socfpga is
> >>>>> lacking support for clock and reset management via devicetree. And
> >>>>> this is bad, I know,
> >>>>> but can we keep this a seperate issue from OF_PLATDATA?
> >>>>>
> >>>>> That being said, drivers/reset/reset-uclass.c fails to compile with
> >>>>> OF_PLATDATA, so I
> >>>>> guess this has not been used with OF_PLATDATA before. And given that I
> >>>>> don't seem
> >>>>> to need it for socfpga either, I don't think this would be the right
> >>>>> series to fix that.
> >>>>
> >>>> Don't you need it to unreset at least the DWMMC or CQSPI ?
> >>>
> >>> Reading the code, it seems like that's taken care of through another hack in
> >>> spl_boot_device() ;-)
> >>
> >> Sigh.
> >>
> >>>> Anyway, I'd much prefer to start cleaning up the horrorshow that
> >>>> arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
> >>>> Would that be possible ?
> >>>
> >>> I would be best, yes. I don't know when I will find the time to do that, though.
> >>> I don't know how much effort that would be, either. Is there maybe a patch
> >>> where A10 got converted from "as bad as gen5" to its current state? That
> >>> would help me to see if I can do it...
> >>
> >> A10 got switched to reset framework recently (in last 6 months or so),
> >> the reset driver is the same for Gen5 and A10 too, so it should be easy
> >> to recycle.
> > 
> > Hmm, ok, let me check that... it would indeed be nice to port this to gen5.
> > 
> > Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
> > to continue on this? I mean, I thought I heard people here saying "use
> > OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not too
> > keen on using it, either, but it does seem to give me some code space back...
> 
> OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
> This platform has a massive 60k of SRAM for SPL, so if we're running out
> of space, we're doing something wrong.

It's not for "30k or below" but "needs more space to enable all desired
features inside of SPL".

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190108/fa70070e/attachment.sig>