[PATCH 0/2] arm64: first set of Kconfig patches for Tegra132 support

[PATCH 0/2] arm64: first set of Kconfig patches for Tegra132 support

[Paul Walmsley]

Hi Catalin & Will,

These patches start the ARM64 Kconfig and defconfig changes to
support the Tegra132 (aka Tegra K1 64-bit) SoC and the NVIDIA
Norrin64 FFD board.

Tegra132 support is made conditional on CONFIG_BROKEN, since
there are some patches pending for other maintainers to fix
compilation when CONFIG_ARCH_TEGRA is set during an ARM64 build.
Once those patches have been merged, a subsequent patch will be
sent to remove the CONFIG_BROKEN dependency and to make a few other
defconfig changes that are dependent on CONFIG_ARCH_TEGRA.

These patches apply on the arm64 fixes/core branch, commit
5d96e0cba263.  They have been boot-tested on QEMU 2.2.0 AArch64,
and (after other patches have been applied) have been boot-tested
on the Tegra132 Norrin64 FFD board.

A signed tag containing these patches is available at:

git://git.kernel.org/pub/scm/linux/kernel/git/pjw/tegra-pending tags/arm64-tegra132-kconfig-a-20150107


- Paul

---

Paul Walmsley (2):
      arm64: Kconfig: add basic support for the Tegra SoC family and the Tegra132 SoC
      arm64: defconfig: add some Kconfig entries used by Tegra132 Norrin FFD board


 arch/arm64/Kconfig           |   29 +++++++++++++++++++++++
 arch/arm64/configs/defconfig |   52 ++++++++++++++++++++++++++++++++++--------
 2 files changed, 71 insertions(+), 10 deletions(-)

   text	   data	    bss	    dec	    hex	filename
7173728	 449984	 199064	 7822776 775db8	vmlinux.old
9435086	 626104	 220208	10281398 9ce1b6	vmlinux

[PATCH 1/2] arm64: Kconfig: add basic support for the Tegra SoC family and the Tegra132 SoC

[Paul Walmsley]

Add basic Kbuild support for the Tegra SoC family, and specifically,
the Tegra132 SoC.  Tegra132 pairs the NVIDIA Denver CPU complex with
the SoC integration of Tegra124 - hence the use of ARCH_TEGRA and the
Tegra124 pinctrl option.

For the time being, Tegra ARM64 support is added with a dependency on
CONFIG_BROKEN.  This is temporary and can be removed when the
following two patches for compilation failures have been merged:

"soc: tegra: pmc: restrict compilation of suspend-related support to ARM"
https://git.kernel.org/cgit/linux/kernel/git/pjw/tegra-dev.git/commit/?id=053decbf3900d4e8fee799f9a29cf8d905b2fcb1

"clocksource: tegra: wrap arch/arm-specific sections in CONFIG_ARM"
https://git.kernel.org/cgit/linux/kernel/git/pjw/tegra-dev.git/commit/?id=220aa7fcc74a1a089916be6cb34b0e326f31841f

This patch was based on a patch originally written by Allen Martin
<amartin@nvidia.com>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Allen Martin <amartin@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
---
 arch/arm64/Kconfig |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b1f9a20a3677..f2f8ade6f3e9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -153,6 +153,35 @@ config ARCH_SEATTLE
 	help
 	  This enables support for AMD Seattle SOC Family
 
+config ARCH_TEGRA
+	bool
+	depends on BROKEN
+	select ARCH_HAS_RESET_CONTROLLER
+	select ARCH_REQUIRE_GPIOLIB
+	select CLKDEV_LOOKUP
+	select CLKSRC_MMIO
+	select CLKSRC_OF
+	select GENERIC_CLOCKEVENTS
+	select HAVE_CLK
+	select HAVE_SMP
+	select PINCTRL
+	help
+	  This enables support for the NVIDIA Tegra SoC family
+
+config ARCH_TEGRA_132_SOC
+	bool "NVIDIA Tegra132 SoC"
+	depends on BROKEN
+	select ARCH_TEGRA
+	select PINCTRL_TEGRA124
+	select USB_ARCH_HAS_EHCI if USB_SUPPORT
+	select USB_ULPI if USB_PHY
+	select USB_ULPI_VIEWPORT if USB_PHY
+	help
+	  Enable support for NVIDIA Tegra132 SoC, based on the Denver
+	  ARMv8 CPU.  The Tegra132 SoC is similar to the Tegra124 SoC,
+	  but contains an NVIDIA Denver CPU complex in place of
+	  Tegra124's "4+1" Cortex-A15 CPU complex.
+
 config ARCH_THUNDER
 	bool "Cavium Inc. Thunder SoC Family"
 	help

[PATCH 1/2] arm64: Kconfig: add basic support for the Tegra SoC family and the Tegra132 SoC

[Thierry Reding]

On Wed, Jan 07, 2015 at 01:17:33AM -0700, Paul Walmsley wrote:
> Add basic Kbuild support for the Tegra SoC family, and specifically,
> the Tegra132 SoC.  Tegra132 pairs the NVIDIA Denver CPU complex with
> the SoC integration of Tegra124 - hence the use of ARCH_TEGRA and the
> Tegra124 pinctrl option.
> 
> For the time being, Tegra ARM64 support is added with a dependency on
> CONFIG_BROKEN.  This is temporary and can be removed when the
> following two patches for compilation failures have been merged:
> 
> "soc: tegra: pmc: restrict compilation of suspend-related support to ARM"
> https://git.kernel.org/cgit/linux/kernel/git/pjw/tegra-dev.git/commit/?id=053decbf3900d4e8fee799f9a29cf8d905b2fcb1

I think you said you were going to respin this on top of v3.19-rc1, but
the above doesn't seem to be rebased yet. Given that the only comments
were bikeshed from my part, do you have any objections to me taking the
patch and apply the bikeshed myself?

> "clocksource: tegra: wrap arch/arm-specific sections in CONFIG_ARM"
> https://git.kernel.org/cgit/linux/kernel/git/pjw/tegra-dev.git/commit/?id=220aa7fcc74a1a089916be6cb34b0e326f31841f

I don't think I've seen any comments other than mine on this patch.
Given that this patch depends on the above to get rid of the BROKEN
dependency, it might still be preferable to take both via the Tegra
tree. Otherwise we probably have to wait until v3.21 before we can
apply this.

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/20150107/f7299807/attachment.sig>

[PATCH 1/2] arm64: Kconfig: add basic support for the Tegra SoC family and the Tegra132 SoC

[Paul Walmsley]

Hi Thierry,

On 01/07/2015 07:20 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Wed, Jan 07, 2015 at 01:17:33AM -0700, Paul Walmsley wrote:
>> Add basic Kbuild support for the Tegra SoC family, and specifically,
>> the Tegra132 SoC.  Tegra132 pairs the NVIDIA Denver CPU complex with
>> the SoC integration of Tegra124 - hence the use of ARCH_TEGRA and the
>> Tegra124 pinctrl option.
>>
>> For the time being, Tegra ARM64 support is added with a dependency on
>> CONFIG_BROKEN.  This is temporary and can be removed when the
>> following two patches for compilation failures have been merged:
>>
>> "soc: tegra: pmc: restrict compilation of suspend-related support to ARM"
>> https://git.kernel.org/cgit/linux/kernel/git/pjw/tegra-dev.git/commit/?id=053decbf3900d4e8fee799f9a29cf8d905b2fcb1
> I think you said you were going to respin this on top of v3.19-rc1, but
> the above doesn't seem to be rebased yet. Given that the only comments
> were bikeshed from my part, do you have any objections to me taking the
> patch and apply the bikeshed myself?

Sorry about that.  I am indeed on the hook for that.   I got distracted 
with some other patches and haven't yet reposted that one :-(
I will do that later today.  If you would prefer to do it yourself, 
that's fine too.

>> "clocksource: tegra: wrap arch/arm-specific sections in CONFIG_ARM"
>> https://git.kernel.org/cgit/linux/kernel/git/pjw/tegra-dev.git/commit/?id=220aa7fcc74a1a089916be6cb34b0e326f31841f
> I don't think I've seen any comments other than mine on this patch.
> Given that this patch depends on the above to get rid of the BROKEN
> dependency, it might still be preferable to take both via the Tegra
> tree. Otherwise we probably have to wait until v3.21 before we can
> apply this.

I'm fine with them going in through you if you have a strong preference 
for that approach.   Generally my preference is for patches to go in 
through the direct maintainer's tree to minimize the risk and hassle of 
merge conflicts.  But if you'll take care of that side of it, it doesn't 
matter too much to me :-)   We just need to pick up acks from the direct 
maintainers, I guess?


- Paul

[PATCH 1/2] arm64: Kconfig: add basic support for the Tegra SoC family and the Tegra132 SoC

[Thierry Reding]

On Thu, Jan 08, 2015 at 03:37:04AM -0700, Paul Walmsley wrote:
> Hi Thierry,
> 
> On 01/07/2015 07:20 AM, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Wed, Jan 07, 2015 at 01:17:33AM -0700, Paul Walmsley wrote:
> >>Add basic Kbuild support for the Tegra SoC family, and specifically,
> >>the Tegra132 SoC.  Tegra132 pairs the NVIDIA Denver CPU complex with
> >>the SoC integration of Tegra124 - hence the use of ARCH_TEGRA and the
> >>Tegra124 pinctrl option.
> >>
> >>For the time being, Tegra ARM64 support is added with a dependency on
> >>CONFIG_BROKEN.  This is temporary and can be removed when the
> >>following two patches for compilation failures have been merged:
> >>
> >>"soc: tegra: pmc: restrict compilation of suspend-related support to ARM"
> >>https://git.kernel.org/cgit/linux/kernel/git/pjw/tegra-dev.git/commit/?id=053decbf3900d4e8fee799f9a29cf8d905b2fcb1
> >I think you said you were going to respin this on top of v3.19-rc1, but
> >the above doesn't seem to be rebased yet. Given that the only comments
> >were bikeshed from my part, do you have any objections to me taking the
> >patch and apply the bikeshed myself?
> 
> Sorry about that.  I am indeed on the hook for that.   I got distracted with
> some other patches and haven't yet reposted that one :-(
> I will do that later today.  If you would prefer to do it yourself, that's
> fine too.

I ended up applying your patch as is. Retrospectively my comments had
been a little too much on the pedantic side.

> >>"clocksource: tegra: wrap arch/arm-specific sections in CONFIG_ARM"
> >>https://git.kernel.org/cgit/linux/kernel/git/pjw/tegra-dev.git/commit/?id=220aa7fcc74a1a089916be6cb34b0e326f31841f
> >I don't think I've seen any comments other than mine on this patch.
> >Given that this patch depends on the above to get rid of the BROKEN
> >dependency, it might still be preferable to take both via the Tegra
> >tree. Otherwise we probably have to wait until v3.21 before we can
> >apply this.
> 
> I'm fine with them going in through you if you have a strong preference for
> that approach.   Generally my preference is for patches to go in through the
> direct maintainer's tree to minimize the risk and hassle of merge conflicts.
> But if you'll take care of that side of it, it doesn't matter too much to me
> :-)   We just need to pick up acks from the direct maintainers, I guess?

Yes, we really just need an ack from either Daniel or Thomas on the
clocksource patch. I don't think that driver has a lot of potential for
merge conflicts.

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/20150108/211b5a39/attachment.sig>

[PATCH 2/2] arm64: defconfig: add some Kconfig entries used by Tegra132 Norrin FFD board

[Paul Walmsley]

Add some Kconfig entries to the ARM64 defconfig for functionality used
by the Tegra132, or Tegra K1 64-bit, SoC on the Norrin FFD board.

Once the required compilation fixes to support ARCH_TEGRA builds on
ARM64 have been merged, a subsequent patch will be sent to remove the
CONFIG_BROKEN dependency and to add a few more Kconfig entries that
have ARCH_TEGRA dependencies.  The objective of this patch is to start
building some of the needed code as early as possible to prevent
regressions and to facilitate testing.

This patch draws on work done by Allen Martin <amartin@nvidia.com> and
Thierry Reding <treding@nvidia.com>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Allen Martin <amartin@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
---
 arch/arm64/configs/defconfig |   52 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 42 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5376d908eabe..8de319d23802 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -55,9 +55,10 @@ CONFIG_IP_PNP_BOOTP=y
 # CONFIG_INET_LRO is not set
 # CONFIG_IPV6 is not set
 CONFIG_BPF_JIT=y
-# CONFIG_WIRELESS is not set
+CONFIG_CFG80211=y
 CONFIG_NET_9P=y
 CONFIG_NET_9P_VIRTIO=y
+CONFIG_TEGRA_AHB=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
@@ -79,8 +80,10 @@ CONFIG_VIRTIO_NET=y
 CONFIG_NET_XGENE=y
 CONFIG_SMC91X=y
 CONFIG_SMSC911X=y
-# CONFIG_WLAN is not set
+CONFIG_MWIFIEX=y
+CONFIG_MWIFIEX_SDIO=y
 CONFIG_INPUT_EVDEV=y
+CONFIG_KEYBOARD_CROS_EC=y
 # CONFIG_SERIO_SERPORT is not set
 CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
@@ -91,21 +94,46 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
+CONFIG_TCG_TPM=y
+CONFIG_TCG_TIS_I2C_INFINEON=y
+# CONFIG_I2C_COMPAT is not set
+CONFIG_I2C_CHARDEV=y
+# CONFIG_I2C_HELPER_AUTO is not set
 CONFIG_SPI=y
 CONFIG_SPI_PL022=y
+CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_XGENE=y
-# CONFIG_HWMON is not set
+CONFIG_BATTERY_SBS=y
+CONFIG_CHARGER_GPIO=y
+CONFIG_POWER_RESET_AS3722=y
+CONFIG_SENSORS_LM90=y
+CONFIG_SENSORS_INA2XX=y
+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_WATCHDOG_NOWAYOUT=y
+CONFIG_MFD_AS3722=y
+CONFIG_MFD_CROS_EC=y
+CONFIG_MFD_CROS_EC_I2C=y
+CONFIG_MFD_CROS_EC_SPI=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
-CONFIG_FB=y
-CONFIG_FB_ARMCLCD=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_LOGO=y
-# CONFIG_LOGO_LINUX_MONO is not set
-# CONFIG_LOGO_LINUX_VGA16 is not set
+CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
+CONFIG_REGULATOR_USERSPACE_CONSUMER=y
+CONFIG_REGULATOR_AS3722=y
+CONFIG_DRM=y
+CONFIG_DRM_NOUVEAU=y
+# CONFIG_LCD_CLASS_DEVICE is not set
+# CONFIG_BACKLIGHT_GENERIC is not set
+CONFIG_BACKLIGHT_PWM=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_DYNAMIC_MINORS=y
+CONFIG_SND_SOC=y
 CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_ISP1760_HCD=y
 CONFIG_USB_OHCI_HCD=y
@@ -113,16 +141,20 @@ CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_ULPI=y
 CONFIG_MMC=y
+CONFIG_MMC_BLOCK_MINORS=16
 CONFIG_MMC_ARMMMCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SPI=y
 CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AS3722=y
 CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_XGENE=y
+CONFIG_DMADEVICES=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_MMIO=y
-# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_PWM=y
+CONFIG_RESET_CONTROLLER=y
 CONFIG_PHY_XGENE=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y

[PATCH 0/2] arm64: first set of Kconfig patches for Tegra132 support

[Will Deacon]

On Wed, Jan 07, 2015 at 08:17:29AM +0000, Paul Walmsley wrote:
> Hi Catalin & Will,

Hi Paul,

> These patches start the ARM64 Kconfig and defconfig changes to
> support the Tegra132 (aka Tegra K1 64-bit) SoC and the NVIDIA
> Norrin64 FFD board.
> 
> Tegra132 support is made conditional on CONFIG_BROKEN, since
> there are some patches pending for other maintainers to fix
> compilation when CONFIG_ARCH_TEGRA is set during an ARM64 build.
> Once those patches have been merged, a subsequent patch will be
> sent to remove the CONFIG_BROKEN dependency and to make a few other
> defconfig changes that are dependent on CONFIG_ARCH_TEGRA.
> 
> These patches apply on the arm64 fixes/core branch, commit
> 5d96e0cba263.  They have been boot-tested on QEMU 2.2.0 AArch64,
> and (after other patches have been applied) have been boot-tested
> on the Tegra132 Norrin64 FFD board.

Whilst I'm happy to take the second patch for 3.20 (getting those
dependencies building and keeping them building is a Good Thing), can we
hold off on the first patch until it's not broken? Having an unconditional
depends on BROKEN isn't really that useful.

Cheers,

Will

[PATCH 0/2] arm64: first set of Kconfig patches for Tegra132 support

[Thierry Reding]

On Wed, Jan 07, 2015 at 11:07:38AM +0000, Will Deacon wrote:
> On Wed, Jan 07, 2015 at 08:17:29AM +0000, Paul Walmsley wrote:
> > Hi Catalin & Will,
> 
> Hi Paul,
> 
> > These patches start the ARM64 Kconfig and defconfig changes to
> > support the Tegra132 (aka Tegra K1 64-bit) SoC and the NVIDIA
> > Norrin64 FFD board.
> > 
> > Tegra132 support is made conditional on CONFIG_BROKEN, since
> > there are some patches pending for other maintainers to fix
> > compilation when CONFIG_ARCH_TEGRA is set during an ARM64 build.
> > Once those patches have been merged, a subsequent patch will be
> > sent to remove the CONFIG_BROKEN dependency and to make a few other
> > defconfig changes that are dependent on CONFIG_ARCH_TEGRA.
> > 
> > These patches apply on the arm64 fixes/core branch, commit
> > 5d96e0cba263.  They have been boot-tested on QEMU 2.2.0 AArch64,
> > and (after other patches have been applied) have been boot-tested
> > on the Tegra132 Norrin64 FFD board.
> 
> Whilst I'm happy to take the second patch for 3.20 (getting those
> dependencies building and keeping them building is a Good Thing), can we
> hold off on the first patch until it's not broken? Having an unconditional
> depends on BROKEN isn't really that useful.

The two patches that require the BROKEN dependency are fairly trivial,
so I don't think it would be a stretch to merge them for 3.20. But they
apply to different trees (one to the clocksource tree, the other to the
Tegra tree).

How do you usually handle the ARM64 patches? Do you manually pick up the
patches that touch arch/arm64 or would you prefer for me to collect them
in a pull request?

Either way I could probably provide a stable branch for you to pull into
the arm64 tree to resolve the build dependencies provided that Daniel or
Thomas will ack the clocksource patch.

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/20150107/f54cd099/attachment.sig>

[PATCH 0/2] arm64: first set of Kconfig patches for Tegra132 support

[Will Deacon]

On Wed, Jan 07, 2015 at 02:25:21PM +0000, Thierry Reding wrote:
> On Wed, Jan 07, 2015 at 11:07:38AM +0000, Will Deacon wrote:
> > On Wed, Jan 07, 2015 at 08:17:29AM +0000, Paul Walmsley wrote:
> > > These patches start the ARM64 Kconfig and defconfig changes to
> > > support the Tegra132 (aka Tegra K1 64-bit) SoC and the NVIDIA
> > > Norrin64 FFD board.
> > > 
> > > Tegra132 support is made conditional on CONFIG_BROKEN, since
> > > there are some patches pending for other maintainers to fix
> > > compilation when CONFIG_ARCH_TEGRA is set during an ARM64 build.
> > > Once those patches have been merged, a subsequent patch will be
> > > sent to remove the CONFIG_BROKEN dependency and to make a few other
> > > defconfig changes that are dependent on CONFIG_ARCH_TEGRA.
> > > 
> > > These patches apply on the arm64 fixes/core branch, commit
> > > 5d96e0cba263.  They have been boot-tested on QEMU 2.2.0 AArch64,
> > > and (after other patches have been applied) have been boot-tested
> > > on the Tegra132 Norrin64 FFD board.
> > 
> > Whilst I'm happy to take the second patch for 3.20 (getting those
> > dependencies building and keeping them building is a Good Thing), can we
> > hold off on the first patch until it's not broken? Having an unconditional
> > depends on BROKEN isn't really that useful.
> 
> The two patches that require the BROKEN dependency are fairly trivial,
> so I don't think it would be a stretch to merge them for 3.20. But they
> apply to different trees (one to the clocksource tree, the other to the
> Tegra tree).
> 
> How do you usually handle the ARM64 patches? Do you manually pick up the
> patches that touch arch/arm64 or would you prefer for me to collect them
> in a pull request?

Either is fine; if it's a large series then a pull request tends to work
better. Catalin is handling the 3.20 merge window (we take it in turns).

> Either way I could probably provide a stable branch for you to pull into
> the arm64 tree to resolve the build dependencies provided that Daniel or
> Thomas will ack the clocksource patch.

Sure; if you have dependencies in other subsystems then we'd need either an
ack from the relevant subsystem maintainer or for them to publish a stable
branch that we can pull in. There's not really a hard-and-fast rule for
this but we can work something out.

Will

[PATCH 0/2] arm64: first set of Kconfig patches for Tegra132 support

[Catalin Marinas]

On Wed, Jan 07, 2015 at 02:54:23PM +0000, Will Deacon wrote:
> On Wed, Jan 07, 2015 at 02:25:21PM +0000, Thierry Reding wrote:
> > On Wed, Jan 07, 2015 at 11:07:38AM +0000, Will Deacon wrote:
> > > On Wed, Jan 07, 2015 at 08:17:29AM +0000, Paul Walmsley wrote:
> > > > These patches start the ARM64 Kconfig and defconfig changes to
> > > > support the Tegra132 (aka Tegra K1 64-bit) SoC and the NVIDIA
> > > > Norrin64 FFD board.
> > > > 
> > > > Tegra132 support is made conditional on CONFIG_BROKEN, since
> > > > there are some patches pending for other maintainers to fix
> > > > compilation when CONFIG_ARCH_TEGRA is set during an ARM64 build.
> > > > Once those patches have been merged, a subsequent patch will be
> > > > sent to remove the CONFIG_BROKEN dependency and to make a few other
> > > > defconfig changes that are dependent on CONFIG_ARCH_TEGRA.
> > > > 
> > > > These patches apply on the arm64 fixes/core branch, commit
> > > > 5d96e0cba263.  They have been boot-tested on QEMU 2.2.0 AArch64,
> > > > and (after other patches have been applied) have been boot-tested
> > > > on the Tegra132 Norrin64 FFD board.
> > > 
> > > Whilst I'm happy to take the second patch for 3.20 (getting those
> > > dependencies building and keeping them building is a Good Thing), can we
> > > hold off on the first patch until it's not broken? Having an unconditional
> > > depends on BROKEN isn't really that useful.
> > 
> > The two patches that require the BROKEN dependency are fairly trivial,
> > so I don't think it would be a stretch to merge them for 3.20. But they
> > apply to different trees (one to the clocksource tree, the other to the
> > Tegra tree).
> > 
> > How do you usually handle the ARM64 patches? Do you manually pick up the
> > patches that touch arch/arm64 or would you prefer for me to collect them
> > in a pull request?
> 
> Either is fine; if it's a large series then a pull request tends to work
> better. Catalin is handling the 3.20 merge window (we take it in turns).

Indeed, for 2-3 patches, I just cherry-pick them (but not before cursing
the email system for corrupting the patches).

-- 
Catalin

[PATCH 0/2] arm64: first set of Kconfig patches for Tegra132 support

[Paul Walmsley]

Hi Will,

On Wed, 7 Jan 2015, Will Deacon wrote:

> Whilst I'm happy to take the second patch for 3.20 (getting those
> dependencies building and keeping them building is a Good Thing), can we
> hold off on the first patch until it's not broken? Having an unconditional
> depends on BROKEN isn't really that useful.

I reflected on this when preparing the patches.  It seemed to me that the 
CONFIG_BROKEN approach was slightly preferable.  If initial support for 
CONFIG_ARCH_TEGRA is merged, there will be a base set of mainline Kconfig 
directives in mainline for others to use when working on support for 
future Tegra chips, such as the X1.  It also moves mainline slightly 
closer to Tegra132 support than it would be without the patch.  At this 
point in time in my life, I've come to appreciate the incremental "baby 
step" approach ;-)

That written, the difference between the two approaches is rather minimal.  
So ultimately I'm fine with whatever you and Catalin want to do.


regards,

- Paul