From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
Date: Wed, 17 Oct 2012 14:03:27 +0000 [thread overview]
Message-ID: <201210171403.27535.arnd@arndb.de> (raw)
In-Reply-To: <1350328024-30485-3-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On Monday 15 October 2012, Stephen Warren wrote:
> Rob, Arnd, Olof, I'd particularly like feedback on whether the following:
>
> #include "../../mach-tegra/iomap.h"
>
> in arch/arm/include/debug/tegra.S is acceptable. I'd really like to
> continue to #include a header to share the defines to Tegra physical
> memory layout and virtual based addresses with Tegra's io.c's struct
> map_desc entries, so they can't get out of sync. So, the include can
> either use the relative path as quoted above (which I don't think will
> cause any significant maintenance issue), or Tegra's iomap.h would have
> to be moved somewhere public so e.g. <tegra-iomap.h> could be included.
I don't have a good answer for this unfortunately. I wouldn't want relative
include paths to take over because they can paper over a lot of other
problems when people get lazy.
> Second, is the Kconfig.debug change reasonable? I guess I could remove
> the second choice menu I added, and just put all the options in the main
> "Kernel low-level debugging port" choice. However, that would make the
> "if" statements in "config DEBUG_LL_INCLUDE" rather more unwieldy.
It looks ok to me in principle, but you could also solve this by making
DEBUG_TEGRA_UART a silent option like this:
@@ -345,6 +345,46 @@ choice
Say Y here if you want kernel low-level debugging support
on SOCFPGA based platforms.
+ config DEBUG_TEGRA_UARTA
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTA for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTB
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTB for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTC
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTC for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTD
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTD for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTE
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTE for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
config DEBUG_VEXPRESS_UART0_DETECT
bool "Autodetect UART0 on Versatile Express Cortex-A core tiles"
depends on ARCH_VEXPRESS && CPU_CP15_MMU
@@ -409,6 +416,36 @@ choice
endchoice
+config DEBUG_TEGRA_UART
+ bool
I don't have a strong preference either way.
ARnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
Date: Wed, 17 Oct 2012 14:03:27 +0000 [thread overview]
Message-ID: <201210171403.27535.arnd@arndb.de> (raw)
In-Reply-To: <1350328024-30485-3-git-send-email-swarren@wwwdotorg.org>
On Monday 15 October 2012, Stephen Warren wrote:
> Rob, Arnd, Olof, I'd particularly like feedback on whether the following:
>
> #include "../../mach-tegra/iomap.h"
>
> in arch/arm/include/debug/tegra.S is acceptable. I'd really like to
> continue to #include a header to share the defines to Tegra physical
> memory layout and virtual based addresses with Tegra's io.c's struct
> map_desc entries, so they can't get out of sync. So, the include can
> either use the relative path as quoted above (which I don't think will
> cause any significant maintenance issue), or Tegra's iomap.h would have
> to be moved somewhere public so e.g. <tegra-iomap.h> could be included.
I don't have a good answer for this unfortunately. I wouldn't want relative
include paths to take over because they can paper over a lot of other
problems when people get lazy.
> Second, is the Kconfig.debug change reasonable? I guess I could remove
> the second choice menu I added, and just put all the options in the main
> "Kernel low-level debugging port" choice. However, that would make the
> "if" statements in "config DEBUG_LL_INCLUDE" rather more unwieldy.
It looks ok to me in principle, but you could also solve this by making
DEBUG_TEGRA_UART a silent option like this:
@@ -345,6 +345,46 @@ choice
Say Y here if you want kernel low-level debugging support
on SOCFPGA based platforms.
+ config DEBUG_TEGRA_UARTA
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTA for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTB
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTB for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTC
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTC for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTD
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTD for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTE
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTE for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
config DEBUG_VEXPRESS_UART0_DETECT
bool "Autodetect UART0 on Versatile Express Cortex-A core tiles"
depends on ARCH_VEXPRESS && CPU_CP15_MMU
@@ -409,6 +416,36 @@ choice
endchoice
+config DEBUG_TEGRA_UART
+ bool
I don't have a strong preference either way.
ARnd
next prev parent reply other threads:[~2012-10-17 14:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-15 19:07 [PATCH V2 1/3] ARM: tegra: simplify DEBUG_LL UART selection options Stephen Warren
2012-10-15 19:07 ` Stephen Warren
[not found] ` <1350328024-30485-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-15 19:07 ` [PATCH V2 2/3] ARM: tegra: make debug-macro.S work standalone Stephen Warren
2012-10-15 19:07 ` Stephen Warren
2012-10-15 19:07 ` [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug Stephen Warren
2012-10-15 19:07 ` Stephen Warren
[not found] ` <1350328024-30485-3-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-17 14:03 ` Arnd Bergmann [this message]
2012-10-17 14:03 ` Arnd Bergmann
2012-10-17 14:38 ` Rob Herring
2012-10-17 14:38 ` Rob Herring
[not found] ` <507EC303.1080000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-10-17 16:22 ` Stephen Warren
2012-10-17 16:22 ` Stephen Warren
[not found] ` <507EDB37.1060102-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-17 21:12 ` Stephen Warren
2012-10-17 21:12 ` Stephen Warren
[not found] ` <507F1F31.2060503-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-18 9:53 ` Russell King - ARM Linux
2012-10-18 9:53 ` Russell King - ARM Linux
[not found] ` <20121018095328.GS21164-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2012-10-19 16:37 ` Stephen Warren
2012-10-19 16:37 ` Stephen Warren
2012-10-18 13:47 ` Rob Herring
2012-10-18 13:47 ` Rob Herring
[not found] ` <5080088C.9090607-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-10-18 13:54 ` Russell King - ARM Linux
2012-10-18 13:54 ` Russell King - ARM Linux
[not found] ` <20121018135444.GT21164-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2012-10-18 14:15 ` Rob Herring
2012-10-18 14:15 ` Rob Herring
2012-10-19 16:40 ` Stephen Warren
2012-10-19 16:40 ` Stephen Warren
2012-10-17 23:17 ` Rob Herring
2012-10-17 23:17 ` Rob Herring
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=201210171403.27535.arnd@arndb.de \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.