On 04/29/2016 08:02 AM, Simon Glass wrote:
Hi Stephen,
On 27 April 2016 at 10:13, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/27/2016 08:50 AM, Simon Glass wrote:
Hi Stephen,
On 25 April 2016 at 13:25, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/23/2016 11:14 AM, Simon Glass wrote:
Hi Stephen,
On 19 April 2016 at 14:59, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
U-Boot is compiled for a single board, which in turn uses a specific SoC. There's no need to make runtime decisions based on SoC ID. While there's certainly an argument for making the code support different SoCs at run-time, the Tegra code is so far from that possible ideal that the existing runtime code is an anomaly. If this changes in the future, all runtime decisions should likely be based on DT anyway.
Signed-off-by: Stephen Warren swarren@nvidia.com
arch/arm/mach-tegra/ap.c | 106 ++++++++++----------------------- arch/arm/mach-tegra/cache.c | 20 +++---- arch/arm/mach-tegra/cpu.c | 16 ++--- arch/arm/mach-tegra/cpu.h | 6 -- arch/arm/mach-tegra/tegra20/warmboot.c | 20 ++----- 5 files changed, 51 insertions(+), 117 deletions(-)What exactly is missing to prevent multi-arch support?
In a word: everything:-)
Pretty much all decisions in core architecture code, core Tegra code, drivers, and even board files are currently made at compile time. For example, consider drivers where the register layouts are different between different SoCs; not just new fields added, but existing fields moved to different offsets. Right now, we handle this by changing the register struct definition at compile time. To support multiple chips, we'd have to either (a) link in n copies of the driver, one per register layout, or (b) rework the driver to use #defines and runtime calculations for register offsets, like the Linux kernel drivers do. Tegra USB is one example. The pinmux and clock drivers have a significantly different sets of pins/clocks/resets/... per SoC, and enums/tables describing those sets are currently configured at compile time. Some PMIC constants (e.g. vdd_cpu voltage) are configured at compile-time, and even differ per board.
I wonder how far we would get by converting clock, pinctrl, reset to driver model drivers?
Well, I expect we'll find out soon. The next SoC has radically different clock/reset mechanisms, so we'll need to switch to standardized APIs for clock/reset on Tegra to isolate drivers from those differences, and I imagine that conversion would also involve conversion to DM since any standard APIs probably assume use of DM. I haven't investigated this in detail yet though.
That sounds like a good move.
I'm not sure if you still object to this patch for now, or would be happy giving it an ack?