public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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.

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox