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 <ma...@denx.de> wrote: > >> > >> On 1/8/19 1:09 PM, Simon Goldschmidt wrote: > >>> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut <ma...@denx.de> wrote: > >>>> > >>>> On 1/8/19 7:24 AM, Simon Goldschmidt wrote: > >>>>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut <ma...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot