[Big trim of the CC list] On Tue, Oct 27, 2026 at 09:06:00AM +0000, Simon Glass wrote: > Hi Quentin, > > On Thu, 8 Oct 2026 at 23:53, Quentin Schulz <[email protected]> wrote: > > > > Hi Simon, > > > > On 8/7/26 9:46 PM, Simon Glass wrote: > > > Hi Jonas, > > > > > > On Tue, 4 Aug 2026 at 13:57, Jonas Karlman <[email protected]> wrote: > > >> > > >> Hi Simon, > > >> > > >> On 8/4/2026 9:19 PM, Simon Glass wrote: > > >>> Hi Jonas, > > >>> > > >>> On Tue, 4 Aug 2026 at 04:57, Jonas Karlman <[email protected]> wrote: > > >>>> > > >>>> This series takes the initial steps required to try and remove use of > > >>>> syscon_get_first_range() or syscon_get_regmap_by_driver_data() to get > > >>>> GRF base addresses at runtime for the Rockchip platform. > > >>>> > > >>>> The GRF base addresses are fixed and known at compile time, yet drivers > > >>>> keep trying to resolve them at runtime delaying some operations by > > >>>> several ms. > > >>> > > >>> I suppose all addresses are known at compile-time, if you have a > > >>> single device tree. I have always hoped that we might end up with a > > >>> generic U-Boot for rockchip. > > >> > > >> I do not understand how removing these unneeded syscon drivers and > > >> helpers would stop such goals or make that any harder. From my point of > > >> view, they are currently making such things harder and only adds extra > > >> code, runtime and energy waste. E.g. around 227 ms was wasted resolving > > >> fixed known base addresses for RK3399 last time I measured it, see [1]. > > >> > > >> Most drivers or any SoC specific code is already identified using a > > >> compatible that is SoC specific, i.e. the RAM or CLK drivers are matched > > >> using a SoC specific compatible and seeing how all GRF variants are > > >> unique there will always need to be SoC specific code to handle the GRFs > > >> base address and reg offsets. > > >> > > >> And for drivers that are more dynamic in nature the DT typically have a > > >> phandle to the GRF syscon node anyway, so getting it from the phandle > > >> will be a better option and closer matches how Linux handles similar > > >> references. > > >> > > >> The biggest current blocker for a more generic U-Boot proper on Rockchip > > >> platform is rockchip_get_cru() and how it currently makes it impossible > > >> to support multiple SoCs in one build due to how it is used in the > > >> sysreset driver. Fortunately, I have a pending series that also cleans > > >> up the unneeded rockchip_get_cru/clk() related helpers. > > >> > > >>> > > >>> I wonder if there is another way to do this, perhaps reading the > > >>> address once and caching it? > > >> > > >> I really do not see the need for that; it would only make things more > > >> complex than it really needs to be. We should use constants where > > >> appropriate, e.g. soc specific drivers/code and use generic phandle > > >> lookups elsewhere. > > >> > > >> At least that is my end goal with this and pending follow-up series. > > > > > > Long delay while I took some time to look at this area in detail. > > > > > > Pre-relocation is an area which I sort-of glossed over with the driver > > > model implementation. There was talk about keeping the pre-relocation > > > devices around rather than recreating them. We also looked at > > > providing post-relocation devices access to the pre-relocation info. > > > Over the years we have had discussions about having 'simple' versions > > > of drivers (that don't go through driver model and perhaps don't use > > > device tree) but no one has made the effort to implement this. > > > > > > Anyway, after a few days of hacking I've come up with some > > > improvements to the existing code, at the cost of about 500 bytes of > > > size increase. It works by using slightly better algorithms for four > > > key functions - fdt_parent_offset(), __of_translate_address(), > > > ofnode_pre_reloc() and lists_bind_fdt(). The result is saving on > > > firefly-rk3399 of 230ms, about what you are getting. Note that I have > > > made no attempt to enable the relevant options in TPL/SPL (it only > > > saves another 13ms), so your work is mostly complimentary. > > > > > > The key difference is that this should help all boards, not just > > > Rockchip, plus it still uses DT for everything. Tom doesn't want me to > > > send patches at present but I did write up a post about it as a way of > > > providing the comparison. [2] > > > > > > > Please refrain from pointing contributors to patches that are > > written/assisted by AI/LLMs as those aren't currently welcome in the > > project. > > Do you have any update on the VBE series I sent? [3] It was written > before the AI era. I believe it was originally sent 18 months ago. It > is the final thing to get VBE running on a real board in mainline.
Your use of AI is not the reason your patches haven't been welcome. -- Tom
signature.asc
Description: PGP signature
