linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ray Jui <rjui@broadcom.com>
To: Arnd Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>, <devicetree@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	<linux-kernel@vger.kernel.org>,
	<bcm-kernel-feedback-list@broadcom.com>,
	Kumar Gala <galak@codeaurora.org>
Subject: Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus
Date: Fri, 18 Sep 2015 15:11:27 -0700	[thread overview]
Message-ID: <55FC8C0F.9020308@broadcom.com> (raw)
In-Reply-To: <1929872.EmD9YkfFuv@wuerfel>



On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
> On Friday 18 September 2015 14:24:10 Ray Jui wrote:
>> +       soc {
>> +               compatible = "simple-bus";
>> +               ranges;
>> +               #address-cells = <1>;
>> +               #size-cells = <1>;
> 
>> +               pinctrl: pinctrl@0301d0c8 {
>>
> 
> Similarly to the core bus, this seems to have address ranges 0x03xxxxxx and
> 0x18xxxxxx on it, so put those into the ranges.
>

Okay we have an issue here. For whatever reason, the Cygnus ASIC team
decided to put registers for the same block in random locations. We see
similar issues in all of our other iProc based SoCs. We have
communicated this to our ASIC team, and hopefully they can revert the
trend for the next SoC.

For example, the gpio_ccm has registers in the following regions:

gpio_ccm: gpio@1800a000 {
    compatible = "brcm,cygnus-ccm-gpio";
    reg = <0x1800a000 0x50>,
          <0x0301d164 0x20>;

NAND is worse, it has registers in 3 different separate regions:

nand: nand@18046000 {
    compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
                 "brcm,brcmnand";
    reg = <0x18046000 0x600>, <0xf8105408 0x600>,
          <0x18046f00 0x20>;

As you can see, this makes it impossible to define a proper address
range for the bus; therefore, I'll have to keep the ranges undefined and
a simple 1:1 mapping under this bus.

> It probably also makes sense to name the bus according to what kind of
> bus (axi, ahb, plb, ...) is used here. If the soc has nested buses
> (e.g. an ahb connected to an axi bus,) then model both of them in the DT.

Based on the block diagram from the ASIC team, it looks like all of them
are connected to one major AXI fabric. I can rename the bus to AXI.

> 
> 	Arnd
> 

Thanks,

Ray

  reply	other threads:[~2015-09-18 22:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-18 21:24 [PATCH v2 0/9] Broadcom Cygnus device tree changes Ray Jui
2015-09-18 21:24 ` [PATCH v2 1/9] ARM: dts: consolidate aliases for Cygnus dt files Ray Jui
2015-09-18 21:27   ` Arnd Bergmann
2015-09-18 21:44     ` Ray Jui
2015-09-23 21:31       ` Arnd Bergmann
2015-09-23 21:46         ` Ray Jui
2015-09-23 21:48           ` Florian Fainelli
2015-09-24 22:23             ` Ray Jui
2015-09-18 21:24 ` [PATCH v2 2/9] ARM: dts: Use label for device nodes in Cygnus dts Ray Jui
2015-09-18 21:24 ` [PATCH v2 3/9] ARM: dts: Remove unused PCI I/O resource in Cygnus Ray Jui
2015-09-18 21:28   ` Arnd Bergmann
2015-09-18 21:53     ` Ray Jui
2015-09-18 21:24 ` [PATCH v2 4/9] ARM: dts: Put Cygnus core components under core bus Ray Jui
2015-09-18 21:30   ` Arnd Bergmann
2015-09-18 21:57     ` Ray Jui
2015-09-18 21:24 ` [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus Ray Jui
2015-09-18 21:34   ` Arnd Bergmann
2015-09-18 22:11     ` Ray Jui [this message]
2015-09-23 21:29       ` Arnd Bergmann
2015-09-23 21:55         ` Ray Jui
2015-09-24  5:54           ` Ray Jui
2015-09-18 21:24 ` [PATCH v2 6/9] ARM: dts: Reorder Cygnus peripherals Ray Jui
2015-09-18 21:24 ` [PATCH v2 7/9] ARM: dts: Enable various peripherals on bcm958305k Ray Jui
2015-09-18 21:24 ` [PATCH v2 8/9] ARM: dts: Enable NAND support on bcm911360_entphn Ray Jui
2015-09-18 21:24 ` [PATCH v2 9/9] ARM: dts: enable touchscreen support on Cygnus Ray Jui

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=55FC8C0F.9020308@broadcom.com \
    --to=rjui@broadcom.com \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.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).