[PATCH 3/6] arm64: tegra: Add Tegra210 support

[Thierry Reding]

On Tue, May 19, 2015 at 03:52:11PM +0100, Catalin Marinas wrote:
> On Fri, May 15, 2015 at 12:19:16PM +0200, Thierry Reding wrote:
> > On Wed, May 13, 2015 at 06:11:15PM +0100, Catalin Marinas wrote:
> > > On Wed, May 13, 2015 at 04:57:42PM +0200, Thierry Reding wrote:
> > > > From: Thierry Reding <treding at nvidia.com>
> > > > 
> > > > NVIDIA Tegra210 (also known as Tegra X1) has four Cortex-A57 and four
> > > > Cortex-A53 CPUs. Compared to Tegra124 and Tegra132 it comes with a 256-
> > > > core Maxwell GPU. It supports processing videos of up to 4K resolutions
> > > > at 60 fps (H.265, VP9, H.264).
> > > > 
> > > > Signed-off-by: Thierry Reding <treding at nvidia.com>
> > > > ---
> > > >  arch/arm64/Kconfig                       |   9 +
> > > >  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 998 +++++++++++++++++++++++++++++++
> > > >  2 files changed, 1007 insertions(+)
> > > >  create mode 100644 arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > > 
> > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > > index 7796af4b1d6f..bfdf064ada66 100644
> > > > --- a/arch/arm64/Kconfig
> > > > +++ b/arch/arm64/Kconfig
> > > > @@ -225,6 +225,15 @@ config ARCH_TEGRA_132_SOC
> > > >  	  but contains an NVIDIA Denver CPU complex in place of
> > > >  	  Tegra124's "4+1" Cortex-A15 CPU complex.
> > > >  
> > > > +config ARCH_TEGRA_210_SOC
> > > > +	bool "NVIDIA Tegra210 SoC"
> > > > +	depends on ARCH_TEGRA
> > > > +	select PINCTRL_TEGRA210
> > > > +	select USB_ULPI if USB_PHY
> > > > +	select USB_ULPI_VIEWPORT if USB_PHY
> > > > +	help
> > > > +	  Enable support for the NVIDIA Tegra210 SoC.
> > > > +
> > > 
> > > The previous ARCH_TEGRA_132_SOC escaped me. Do we need all these
> > > ARCH_TEGRA_*_SOC entries? Can we not have per-driver Kconfig options?
> > > For example, ARCH_TEGRA_132_SOC seems to be only used in
> > > drivers/clk/tegra, a specific Kconfig entry in there would suffice.
> > 
> > There are actually a couple of other places where this will be used in
> > subsequent patches (e.g. memory controller driver). The idea behind
> > having these is that each one of them is used to enable the essentials
> > out of the box, so that people don't have to go and enable a bunch of
> > driver-specific Kconfig options just to get a kernel configuration that
> > can actually boot.
> 
> We debated whether to have ARCH_* options at all on arm64 and we settled
> for the middle ground - only add them for SoC families, not individual
> SoCs. As for the kernel configuration that actually boots, we want the
> arm64 defconfig to include all the supported SoCs and drivers (though
> longer term I'd like to see more drivers built as modules by default).
> 
> > This is also useful for integrators since they can simply omit all SoC
> > generations that they're not interested in. Having a per-SoC option
> > provides an easy way of doing so.
> 
> The integrators could just select a SoC family and trim down unwanted
> options, I don't think they rely on the kernel defconfig for a final
> product. If this becomes an issue, I would rather have per-SoC
> defconfigs than lots of Kconfig entries.

I understand the desire to start with a clean plate on a new
architecture, but Tegra has worked like this for the past 5 years and
it's worked out really well for us. So I'm reluctant to introduce these
inconsistencies merely because 64-bit ARM now lives in a different
directory.

Are you concerned about arch/arm64/Kconfig growing wild? If so we could
easily move these configuration options outside to something like
drivers/soc/tegra/Kconfig. While at it, we could move existing options
from arch/arm/mach-tegra over to that as well.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150519/dfe5be8f/attachment.sig>