Skip to contentSkip to conversation

arm64: first set of Kconfig patches for Tegra132 support

PATCH New Paul Walmsley 5 participants 11 messages Jan 7, 2015 – Jan 8, 2015

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover arm64: first set of Kconfig patches for Tegra132 support

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

#1 lore raw

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

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 <[email protected]>.

Cc Paul Walmsley <[email protected]>
Cc Allen Martin <[email protected]>
Cc Thierry Reding <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Mark Rutland <[email protected]>
---
 arch/arm64/Kconfig |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
arch/arm64/Kconfig +29 -0
index b1f9a20a3677..f2f8ade6f3e9 100644
@@ -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
#2 lore raw

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

Quoted 11 lines · 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

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?

Quoted 2 lines

"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>

#3 lore raw

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

Hi Thierry,

Quoted 12 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 9 lines · 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:

Quoted 6 lines
Quoted 2 lines

"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.

Quoted 7 lines
Quoted 2 lines

"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

#4 lore raw

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

Quoted 22 lines · Paul Walmsley

Hi Thierry,

Quoted 12 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 9 lines · 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:

Quoted 6 lines
Quoted 2 lines

"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?

Quoted 4 lines

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.

Quoted 8 lines
Quoted 7 lines
Quoted 2 lines

"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.

Quoted 5 lines

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>

#5 lore raw

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

In reply to 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 <[email protected]> and Thierry Reding <[email protected]>.

Cc Paul Walmsley <[email protected]>
Cc Allen Martin <[email protected]>
Cc Thierry Reding <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Mark Rutland <[email protected]>
---
 arch/arm64/configs/defconfig |   52 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 42 insertions(+), 10 deletions(-)
arch/arm64/configs/defconfig +42 -10
index 5376d908eabe..8de319d23802 100644
@@ -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
#6 lore raw

cover arm64: first set of Kconfig patches for Tegra132 support

In reply to Paul Walmsley
Quoted 1 line · Paul Walmsley

Hi Catalin & Will,

Hi Paul,

Quoted 11 lines

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.

Quoted 4 lines

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

#7 lore raw

cover arm64: first set of Kconfig patches for Tegra132 support

Quoted 21 lines · Will Deacon
Quoted 1 line · Paul Walmsley

Hi Catalin & Will,

Hi Paul,

Quoted 11 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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>

#8 lore raw

cover arm64: first set of Kconfig patches for Tegra132 support

Quoted 23 lines · Thierry Reding
Quoted 17 lines · Will Deacon
Quoted 11 lines · Paul Walmsley

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.

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 8 lines

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).

Quoted 3 lines

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

maintainer
#9 lore raw

cover arm64: first set of Kconfig patches for Tegra132 support

Quoted 29 lines · Will Deacon
Quoted 28 lines · Thierry Reding
Quoted 17 lines · Will Deacon
Quoted 11 lines · Paul Walmsley

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.

Quoted 4 lines

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.

Quoted 4 lines

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).

Quoted 6 lines
Quoted 3 lines

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).

Signature · 1 line
Catalin
#10 lore raw

cover arm64: first set of Kconfig patches for Tegra132 support

In reply to Will Deacon

Hi Will,

Quoted 4 lines · Will Deacon

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