From: thierry.reding@gmail•com (Thierry Reding)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 3/6] arm64: tegra: Add Tegra210 support
Date: Tue, 19 May 2015 17:17:42 +0200 [thread overview]
Message-ID: <20150519151740.GA28161@ulmo.nvidia.com> (raw)
In-Reply-To: <20150519145211.GX21251@e104818-lin.cambridge.arm.com>
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@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@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>
next prev parent reply other threads:[~2015-05-19 15:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 14:57 [PATCH 1/6] arm64: tegra: Add Tegra132 support Thierry Reding
2015-05-13 14:57 ` [PATCH 2/6] arm64: tegra: Add NVIDIA Tegra132 Norrin support Thierry Reding
2015-05-13 14:57 ` [PATCH 3/6] arm64: tegra: Add Tegra210 support Thierry Reding
2015-05-13 17:11 ` Catalin Marinas
2015-05-15 10:19 ` Thierry Reding
2015-05-19 14:52 ` Catalin Marinas
2015-05-19 15:17 ` Thierry Reding [this message]
2015-05-22 13:38 ` Catalin Marinas
2015-05-22 15:05 ` Thierry Reding
2015-05-22 15:33 ` Catalin Marinas
2015-05-22 15:37 ` Stephen Warren
2015-05-13 14:57 ` [PATCH 4/6] arm64: tegra: Add NVIDIA P2530 compute module support Thierry Reding
2015-05-13 14:57 ` [PATCH 5/6] arm64: tegra: Add NVIDIA P2595 base board support Thierry Reding
2015-05-13 14:57 ` [PATCH 6/6] arm64: tegra: Add NVIDIA P2371 support Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150519151740.GA28161@ulmo.nvidia.com \
--to=thierry.reding@gmail$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox