linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Marc Carino <marc.ceeeee@gmail.com>
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-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
Date: Wed, 15 Jan 2014 14:10:38 +0100	[thread overview]
Message-ID: <201401151410.39112.arnd@arndb.de> (raw)
In-Reply-To: <1389743333-16741-8-git-send-email-marc.ceeeee@gmail.com>

On Wednesday 15 January 2014, Marc Carino wrote:
> +       gen-ctrl {
> +               compatible = "brcm,brcmstb-gen-ctrl-v1";
> +               reg = <0xf0404304 0x4
> +                      0xf0404308 0x4
> +                      0xf03e2578 0x4
> +                      0xf03e2488 0x10
> +                      0xf0452000 0x20>;
> +       };

Sorry I didn't get back to you on this when we discussed the previous
version. I'm actually less happy with this DT representation than the
original. What I take from your description is that you have multiple
register ranges that basically combine more-or-less random registers
that belong into different Linux subsystems.

I think the best way to deal with this is to have the "syscon" driver
handle the multiplexing between the various drivers that need access
to the registers. It would look something like (taking the numbers
from your previous patch):

	ahb {
		ranges = <0 0xf0000000 0x1000000>; /* 16 MB remapped registers */

		hif-cpubuictrl: syscon@3e2400 {
			compatible = "brcm,7445-cpubioctrl", "syscon";
			reg = <0x3e2000, 0x1000>;
		};

		hif-continuation: syscon@45200 {
			compatible = "brcm,7445-hif-continuation", "syscon";
			reg = <0x452000, 0x1000>;
		};

		sun-top-ctrl: ...
	};

This lets the syscon driver find and map the three register areas.
Drivers that need access to the registers then do 

	reset {
		compatible = "brcm,7445-reset-ctrl";
		syscon = <&sun-top-ctrl 0x300 0x100>;
		#reset-cells = <1>;
	};

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.

	Arnd

  reply	other threads:[~2014-01-15 13:10 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 [this message]
2014-01-15 18:22     ` Marc
2014-01-16  1:03       ` Marc C
2014-01-16 11:19         ` Arnd Bergmann
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=201401151410.39112.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=bcm@fixthebug.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 \
    /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).