From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4 1/5] ARM: add infra-structure for BCM2835 and Raspberry Pi
Date: Fri, 14 Sep 2012 09:51:31 -0600 [thread overview]
Message-ID: <50535283.9040905@wwwdotorg.org> (raw)
In-Reply-To: <201209140750.44039.arnd@arndb.de>
On 09/14/2012 01:50 AM, Arnd Bergmann wrote:
> On Friday 14 September 2012, Stephen Warren wrote:
>> From: Simon Arlott <simon@fire.lp0.eu>
>>
>> The BCM2835 is an ARM SoC from Broadcom. This patch adds very basic
>> support for this SoC.
>>
>> http://www.broadcom.com/products/BCM2835
>> http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pd
>
> Just looked at that document. Funny how they actually put details about
> the kernel implementation (the static mapping address) into a hardware
> manual.
Yes. I keep hoping they'll fix this and re-issue the document. Dom, what
do you think that chances are of that?
>> Note that the documentation in the latter .pdf assumes the MMU setup
>> that's used on the "VideoCore" companion processor, and does not document
>> physical peripheral addresses. Subtract 0x5e000000 to obtain the physical
>> addresses.
>
> This had escaped me so far. I think we should put this into the device tree
> so that the representation of devices in the .dts file matches the one in
> the manual, like this
>
> vc-bus {
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0x20000000 0x7e000000 0x02000000>;
>
> other devices {
>
> };
> };
I guess I can see the advantage of having the .dts reg values match the
documentation. I just worry that doing so is more about matching the
documentation rather than describing the true HW. Still, I suppose with
the ranges property, it's clear what the true physical addresses are..
It also introduces a completely fake bus just to perform the address
re-writing; I wonder if putting the ranges property at the top-level
node work instead?.
So now that almost everything is ack'd, how should this get into the
tree - will you take (an updated version of) these patches and apply
them directly to arm-soc, or should I commit them and send a pull
request? (For the latter, I'd have to look up how to create a new k.org
git repo).
Thanks for the reviews.
next prev parent reply other threads:[~2012-09-14 15:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 4:41 [PATCH V4 1/5] ARM: add infra-structure for BCM2835 and Raspberry Pi Stephen Warren
2012-09-14 4:41 ` [PATCH V4 2/5] ARM: bcm2835: add interrupt controller driver Stephen Warren
2012-09-14 7:55 ` Arnd Bergmann
2012-09-14 4:41 ` [PATCH V4 3/5] ARM: bcm2835: add system timer Stephen Warren
2012-09-14 4:41 ` [PATCH V4 4/5] ARM: bcm2835: add stub clock driver Stephen Warren
2012-09-14 4:41 ` [PATCH V4 5/5] ARM: bcm2835: instantiate console UART Stephen Warren
2012-09-14 7:56 ` Arnd Bergmann
2012-09-14 7:50 ` [PATCH V4 1/5] ARM: add infra-structure for BCM2835 and Raspberry Pi Arnd Bergmann
2012-09-14 15:51 ` Stephen Warren [this message]
2012-09-14 20:01 ` Arnd Bergmann
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=50535283.9040905@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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 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.