On Mon, Jan 19, 2026 at 09:18:23PM +0100, Markus Schneider-Pargmann wrote: > Hi Tom, > > On Fri Jan 16, 2026 at 7:45 PM CET, Tom Rini wrote: > > On Thu, Dec 04, 2025 at 11:25:36AM +0100, Markus Schneider-Pargmann > > (TI.com) wrote: > > > >> The series is split into two logical groups: > >> > >> - Patches 1-4: Fixes for am335x-evm to boot and support the LCD panel > >> with the current u-boot devicetree. > >> - Patches 5-8: Make upstream devicetree working with uboot. This > >> adds tick-timer, adds compatibility of the board code for different > >> USB probing and updates the defconfig. > >> > >> The series has been tested on am335x-evm. Note that I don't have all > >> other boards built with the am335x_*evm_*defconfig, so tests are > >> appreciated. buildman reports builds are working. > >> > >> Dependencies: > >> - clk: ti: Cleanup common functions and omap-cm > >> > >> https://lore.kernel.org/r/20251128-topic-am33-clk-regmap-dep-v2026-01-v2-0-451b4f4e7...@baylibre.com > >> - dm: core: Support same compatible in host/gadget musb drivers > >> > >> https://lore.kernel.org/r/20251126-topic-musb-probing-v2026-01-v1-0-ff8d8c487...@baylibre.com > >> - simple-pm-bus: Make clocks optional > >> > >> https://lore.kernel.org/r/20251128-topic-simple-pm-bus-optional-clocks-v2026-01-v1-1-e38040c88...@baylibre.com > >> - video: simple_panel support for am335x evm panel > >> > >> https://lore.kernel.org/r/20251204-topic-am33-evm-lcd-v2026-01-v3-0-ca74853bd...@baylibre.com > >> - power: domain: Add ti-omap-prm stub > >> > >> https://lore.kernel.org/r/[email protected] > > > > All of the deps are now merged. Unfortunately, this now overflows SRAM > > by 80 bytes, when using the gcc-14.2.0 toolchain from kernel.org that CI > > uses. You might need to look at enabling LTO here, which I haven't tried > > in a long time but recall had its own problem unfortunately when I did. > > But that was years ago, and perhaps is no longer a problem. > > I wasn't able to reproduce the issue so I reproduced it in the same CI > container, as mentioned on IRC. > > LTO indeed helped in the container with gcc-14.2. But it failed for me > on gcc-15.2 where it produced code that is too large. > > SPL_OPTIMIZE_INLINING is currently not set for am335x_evm and I think > this is a safe option. It helps both for gcc-14.2 and gcc-15.2. Are > there any pitfalls with this option that I am not aware of?
Just run-time test it as much as you can please. I forget if there's still the ability to force inline functions with that, but I *think* there is, and in turn I think everything should still work right. -- Tom
signature.asc
Description: PGP signature
