From: cavokz@gmail.com (Domenico Andreoli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/6] ARM: bcm476x: Add infrastructure
Date: Tue, 9 Oct 2012 13:50:35 +0200 [thread overview]
Message-ID: <20121009115034.GA28817@glitch> (raw)
In-Reply-To: <50738DD0.5090406@wwwdotorg.org>
On Mon, Oct 08, 2012 at 08:37:04PM -0600, Stephen Warren wrote:
> On 10/07/2012 04:54 PM, Domenico Andreoli wrote:
> > On Sun, Oct 07, 2012 at 09:57:59PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 03:53 Sun 07 Oct , Domenico Andreoli wrote:
> >>> From: Domenico Andreoli <domenico.andreoli@linux.com>
>
> >>> Index: b/arch/arm/boot/dts/bcm476x.dtsi
>
> >>> + vic0: interrupt-controller at 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.
> >>> Index: b/arch/arm/include/debug/bcm476x.S
>
> >>> +#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
next prev parent reply other threads:[~2012-10-09 11:50 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-07 1:53 [PATCH 0/6] ARM: Add support for Broadcom BCM476x SoCs Domenico Andreoli
2012-10-07 1:53 ` [PATCH 1/6] ARM: bcm476x: Add infrastructure Domenico Andreoli
2012-10-07 19:57 ` Jean-Christophe PLAGNIOL-VILLARD
2012-10-07 22:54 ` Domenico Andreoli
2012-10-08 13:13 ` Jean-Christophe PLAGNIOL-VILLARD
2012-10-09 2:37 ` Stephen Warren
2012-10-09 11:50 ` Domenico Andreoli [this message]
2012-10-08 11:50 ` Florian Fainelli
2012-10-09 2:41 ` Stephen Warren
2012-10-08 12:14 ` Thomas Petazzoni
2012-10-09 11:52 ` Domenico Andreoli
2012-10-09 2:48 ` Stephen Warren
2012-10-09 11:54 ` Domenico Andreoli
2012-10-09 3:08 ` Stephen Warren
2012-10-09 11:55 ` Domenico Andreoli
2012-10-09 9:18 ` Arnd Bergmann
2012-10-09 22:58 ` Domenico Andreoli
2012-10-10 6:29 ` Arnd Bergmann
2012-10-12 7:06 ` Domenico Andreoli
2012-10-12 7:26 ` Thomas Petazzoni
2012-10-12 8:03 ` Arnd Bergmann
2012-10-12 8:12 ` Thomas Petazzoni
2012-10-12 10:48 ` Arnd Bergmann
2012-10-12 11:01 ` Thomas Petazzoni
2012-10-12 11:17 ` Arnd Bergmann
2012-10-07 1:53 ` [PATCH 2/6] ARM: bcm476x: Add system timer Domenico Andreoli
2012-10-08 11:50 ` Florian Fainelli
2012-10-09 2:43 ` Stephen Warren
2012-10-09 23:04 ` Domenico Andreoli
2012-10-07 1:53 ` [PATCH 3/6] ARM: bcm476x: Add sched clock Domenico Andreoli
2012-10-09 2:54 ` Stephen Warren
2012-10-07 1:53 ` [PATCH 4/6] ARM: bcm476x: Add stub clock driver Domenico Andreoli
2012-10-09 3:00 ` Stephen Warren
2012-10-12 14:52 ` Mike Turquette
2012-10-12 15:28 ` Domenico Andreoli
2012-10-07 1:53 ` [PATCH 5/6] ARM: bcm476x: Add restart hook Domenico Andreoli
2012-10-07 1:53 ` [PATCH 6/6] ARM: bcm476x: Instantiate console UART Domenico Andreoli
2012-10-07 20:03 ` Jean-Christophe PLAGNIOL-VILLARD
2012-10-07 23:14 ` Domenico Andreoli
2012-10-09 3:06 ` Stephen Warren
2012-10-09 23:37 ` Domenico Andreoli
2012-10-07 5:22 ` [PATCH 0/6] ARM: Add support for Broadcom BCM476x SoCs Stephen Warren
2012-10-07 10:14 ` Domenico Andreoli
2012-10-09 2:44 ` Stephen Warren
2012-10-09 23:57 ` Domenico Andreoli
2012-10-07 19:47 ` Olof Johansson
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=20121009115034.GA28817@glitch \
--to=cavokz@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).