On 04/29/2016 08:02 AM, Simon Glass wrote:
Hi Stephen,
On 27 April 2016 at 10:13, Stephen Warren <swar...@wwwdotorg.org> wrote:
On 04/27/2016 08:50 AM, Simon Glass wrote:
Hi Stephen,
On 25 April 2016 at 13:25, Stephen Warren <swar...@wwwdotorg.org> wrote:
On 04/23/2016 11:14 AM, Simon Glass wrote:
Hi Stephen,
On 19 April 2016 at 14:59, Stephen Warren <swar...@wwwdotorg.org> wrote:
From: Stephen Warren <swar...@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 <swar...@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?
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
