From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 14 Jan 2019 16:50:48 -0500 Subject: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select In-Reply-To: <9e679556-3e5c-07bf-1473-68a1b0263f35@denx.de> References: <20190107211423.10151-2-simon.k.r.goldschmidt@gmail.com> <033b301a-612d-3b80-7ecc-04530851c1ec@denx.de> <1dd165cd-2cad-013b-877c-78fe5780f9cf@gmail.com> <00f186a1-7aea-8d46-770d-b5e08f1f92c2@denx.de> <8d7142cb-5674-57d2-dce2-a4595b8a5538@gmail.com> <9bcf5990-df16-b10f-4f61-4f40bdcd5eb0@kernel.org> <28940ce1-aba0-6fcc-7dcb-8d6f4bc34ea1@gmail.com> <1c639b12-e963-f5b4-9136-83ebe0cd1a9b@denx.de> <20190114212818.GR5463@bill-the-cat> <9e679556-3e5c-07bf-1473-68a1b0263f35@denx.de> Message-ID: <20190114215048.GS5463@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Jan 14, 2019 at 10:30:36PM +0100, Marek Vasut wrote: > On 1/14/19 10:28 PM, Tom Rini wrote: > > On Mon, Jan 14, 2019 at 07:31:26PM +0100, Marek Vasut wrote: > >> On 1/14/19 5:05 PM, Simon Goldschmidt wrote: > >>> Hi Dinh, > >> > >> Hi, > >> > >>> 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. > >> > >> We had the same problem with A10, indeed. > >> > >>> 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? > >>> > >>> Plus: should U-Boot work with older Linux kernels? Because if so, we > >>> need fallback code in U-Boot to unreset peripherals when running with an > >>> older kernel... > >> > >> Yes, it'd break old broken kernels . The real question is, do we care ? > > > > Yes, we care. Especially since it sounds like we're talking about > > something that's an LTS and not super-ancient vendor kernel. Off the > > top of my head I can't recall if we ever fully removed support in sunxi > > for the vendor kernel in some cases, or just made it, eventually, opt-in > > as it was a fairly annoying incompatible behavior case. > > > > But yes, in general, we do care about old kernels and need to be loud > > and clear about when we're removing support for them on a given SoC due > > to it being a PITA to support both ways of doing X and people have had Y > > years to migrate or correct their kernel. > > Then we have to add some fallback mechanism, possibly the env variable > to tell reset controller to unreset everything. Alright, so the prior art in question is: commit accc9e446be6c3bd129315a0c5830bddccfa16da Author: Hans de Goede Date: Wed Oct 22 14:56:36 2014 +0200 sunxi: Add CONFIG_OLD_SUNXI_KERNEL_COMPAT Kconfig option And is about supporting the sunxi 3.4 vendor kernel tree, and something we have still (and a single enabler of). So, what's the range of broken / not broken kernels here? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: