From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 29 Apr 2016 10:27:07 -0600 Subject: [U-Boot] [PATCH 38/60] ARM: tegra: remove tegra_get_chip() In-Reply-To: References: <1461099580-3866-1-git-send-email-swarren@wwwdotorg.org> <1461099580-3866-39-git-send-email-swarren@wwwdotorg.org> <571E6F1D.3040405@wwwdotorg.org> <5720E515.3020208@wwwdotorg.org> Message-ID: <57238B5B.6090608@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/29/2016 08:02 AM, Simon Glass wrote: > Hi Stephen, > > On 27 April 2016 at 10:13, Stephen Warren wrote: >> On 04/27/2016 08:50 AM, Simon Glass wrote: >>> >>> Hi Stephen, >>> >>> On 25 April 2016 at 13:25, Stephen Warren wrote: >>>> >>>> On 04/23/2016 11:14 AM, Simon Glass wrote: >>>>> >>>>> >>>>> Hi Stephen, >>>>> >>>>> On 19 April 2016 at 14:59, Stephen Warren wrote: >>>>>> >>>>>> >>>>>> From: Stephen Warren >>>>>> >>>>>> 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 >>>>>> --- >>>>>> 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?