Thread (1 message) 1 message, 1 author, 2012-10-09

Re: [PATCH 1/6] ARM: bcm476x: Add infrastructure

From: Domenico Andreoli <hidden>
Date: 2012-10-09 11:50:35
Also in: linux-arm-kernel

On Mon, Oct 08, 2012 at 08:37:04PM -0600, Stephen Warren wrote:
On 10/07/2012 04:54 PM, Domenico Andreoli wrote:
quoted
On Sun, Oct 07, 2012 at 09:57:59PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
quoted
On 03:53 Sun 07 Oct     , Domenico Andreoli wrote:
quoted
From: Domenico Andreoli <redacted>
quoted
quoted
quoted
Index: b/arch/arm/boot/dts/bcm476x.dtsi
quoted
quoted
quoted
+		vic0: interrupt-controller@80000 {
+			compatible = "brcm,bcm476x-pl192", "arm,pl192-vic", "arm,primecell";
why brcm specific compatbile?
Nothing breaks if I drop it. I think it's a future-proof clause, especially
if you consider that the devicetree could be not easy to upgrade and you
may need a way to differentiate the bcm476x's implementation from the
common one. I'm not sure it's an actual requirement with use cases.
Indeed, everything works fine right now if you drop that. However, it is
correct practice to include a compatible value for the particular SoC
that incorporates the IP so that if in the future some SoC-specific
workaround is required, the compatible value needed to trigger this is
already in all historical .dts file.
This matches with what I know but it seems anyway that in the arm,primecell
cases this is not a great concern, almost none of the dts currently in
mainline go as far as specifying the machine specific name.
quoted
quoted
quoted
Index: b/arch/arm/include/debug/bcm476x.S
quoted
quoted
quoted
+#if defined(CONFIG_DEBUG_BCM476X_UART0)
+# define BCM476X_DEBUG_PHYS	0x000c0000
+# define BCM476X_DEBUG_VIRT	0xd00c0000
+#elif defined(CONFIG_DEBUG_BCM476X_UART1)
+# define BCM476X_DEBUG_PHYS	0x000c1000
+# define BCM476X_DEBUG_VIRT	0xd00c1000
+#elif defined(CONFIG_DEBUG_BCM476X_UART2)
+# define BCM476X_DEBUG_PHYS	0x000b2000
+# define BCM476X_DEBUG_VIRT	0xd00b2000
+#else
+# error Unknown BCM476x debug port
+#endif
can't you detect it?
If I can assume that the boot loader will configure and enable only the
console port, I could use the first one in such state.

Where could I place such detection, in the maco addruart itself?
Auto-detection is not necessarily a good idea; there's no reason in
general to believe that no future board will ever use a UART for any
purposes other than console/debug. Being explicit is probably good.
After thinking at it a bit, I also prefer to leave the guessing out. It
can break things in non-obvious ways. I prefer a full consistent and
testable behaviour.

Thanks,
Domenico
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help