From: Arnd Bergmann <arnd@arndb.de>
To: Marc C <marc.ceeeee@gmail.com>,
Michal Simek <michal.simek@xilinx.com>,
Mark Brown <broonie@kernel.org>,
David Brown <davidb@codeaurora.org>,
Stephen Boyd <sboyd@codeaurora.org>
Cc: Christian Daudt <bcm@fixthebug.org>,
Florian Fainelli <f.fainelli@gmail.com>,
Matt Porter <matt.porter@linaro.org>,
Russell King <linux@arm.linux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
Date: Thu, 16 Jan 2014 12:19:00 +0100 [thread overview]
Message-ID: <201401161219.01038.arnd@arndb.de> (raw)
In-Reply-To: <52D72FCD.1030005@gmail.com>
On Thursday 16 January 2014, Marc C wrote:
> > And then you can add a regular device driver to drivers/reset that provides a
> > device_reset() API to other drivers, or a system-reset function to be registered as
> > arm_pm_restart. This driver would use syscon_regmap_lookup_by_phandle() to get access
> > to a regmap pointer, and then use either hardcoded offsets into the regmap, or get
> > those offsets from numbers in the devicetree, as provided in the example above.
>
> I was able to port a standalone "reboot" driver using syscon + regmap. However, for the
> SMP initialization case, it turns out that syscon is configured after SMP init. Do you
> have any advice for this type of situation?
>
> I'd hate to go around in circles, but without resorting to hard-coded offsets, perhaps I
> can just add the remaining "non-regmap" register offsets in the DT?
You are not the first one to stumble over this problem. There are
two ways to get out of it, and we should probably implement both in
the long run:
1. Other platforms also require the syscon driver to be active before
the regular device driver probing starts. Michal Simek has the same
issue in the zynq clock driver that you have for SMP initialization.
We have talked about this with Mark Brown already, and I think we will
find a solution for this in the end, but it's not as straightforward
as I first hoped. We can probably use help in this area.
2. There is actually no reason for the SMP code to be called this early,
and multiple platforms would like to move SMP init to a later stage.
Stephen Boyd has recently started reworking the way we do SMP init,
and he may have some more insight.
In the meantime, I'd suggest you do the binding under the assumption
that it will work eventually, and then work around the current limitations
in the SMP code by looking for the device nodes you need and map them
manually, as you did in the previous versions of your patch set.
Arnd
next prev parent reply other threads:[~2014-01-16 11:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 23:48 [PATCH v3 0/7] ARM: brcmstb: Add Broadcom STB SoC support Marc Carino
2014-01-14 23:48 ` [PATCH v3 1/7] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs Marc Carino
2014-01-14 23:48 ` [PATCH v3 2/7] ARM: brcmstb: add debug UART for earlyprintk support Marc Carino
2014-01-14 23:48 ` [PATCH v3 3/7] ARM: do CPU-specific init for Broadcom Brahma15 cores Marc Carino
2014-01-15 17:19 ` Will Deacon
2014-01-14 23:48 ` [PATCH v3 4/7] ARM: brcmstb: add CPU binding for Broadcom Brahma15 Marc Carino
2014-01-15 16:58 ` Mark Rutland
2014-01-14 23:48 ` [PATCH v3 5/7] ARM: brcmstb: add misc. DT bindings for brcm,brcmstb-* Marc Carino
2014-01-15 17:11 ` Mark Rutland
2014-01-15 17:15 ` Arnd Bergmann
2014-01-15 17:55 ` Florian Fainelli
2014-01-14 23:48 ` [PATCH v3 6/7] ARM: brcmstb: gic: add compatible string for Broadcom Brahma15 Marc Carino
2014-01-15 17:20 ` Mark Rutland
2014-01-14 23:48 ` [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445 Marc Carino
2014-01-15 13:10 ` Arnd Bergmann
2014-01-15 18:22 ` Marc
2014-01-16 1:03 ` Marc C
2014-01-16 11:19 ` Arnd Bergmann [this message]
2014-01-16 13:37 ` Michal Simek
2014-01-16 13:47 ` Mark Brown
2014-01-17 17:04 ` Arnd Bergmann
2014-01-23 8:58 ` Michal Simek
2014-01-23 12:25 ` Mark Brown
2014-01-15 17:40 ` Mark Rutland
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=201401161219.01038.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=bcm@fixthebug.org \
--cc=broonie@kernel.org \
--cc=davidb@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=marc.ceeeee@gmail.com \
--cc=matt.porter@linaro.org \
--cc=michal.simek@xilinx.com \
--cc=sboyd@codeaurora.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