From: Steve Longerbeam <slongerbeam@gmail.com>
To: Philipp Zabel <p.zabel@pengutronix.de>, Peter Rosin <peda@axentia.se>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Sakari Ailus <sakari.ailus@iki.fi>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de
Subject: Re: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
Date: Thu, 13 Apr 2017 18:03:43 -0700 [thread overview]
Message-ID: <d6d32063-5df3-3848-32f5-824c500a8927@gmail.com> (raw)
In-Reply-To: <20170413154812.19597-1-p.zabel@pengutronix.de>
On 04/13/2017 08:48 AM, Philipp Zabel wrote:
> This adds device tree binding documentation for mmio-based syscon
> multiplexers controlled by a single bitfield in a syscon register
> range.
Nice! (you beat me to it, I was about to embark on this myself :)
Looks good to me, just some minor comments below.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> Documentation/devicetree/bindings/mux/mmio-mux.txt | 56 ++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mux/mmio-mux.txt
>
> diff --git a/Documentation/devicetree/bindings/mux/mmio-mux.txt b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> new file mode 100644
> index 0000000000000..11d96f5d98583
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> @@ -0,0 +1,56 @@
> +MMIO bitfield-based multiplexer controller bindings
> +
> +Define a syscon bitfield to be used to control a multiplexer. The parent
I think "Define a register bitfield to be used ..." is more clear.
> +device tree node must be a syscon node to provide register access.
> +
> +Required properties:
> +- compatible : "gpio-mux"
Er, "mmio-mux"
> +- reg : register base of the register containing the control bitfield
> +- bit-mask : bitmask of the control bitfield in the control register
> +- bit-shift : bit offset of the control bitfield in the control register
> +- #mux-control-cells : <0>
> +* Standard mux-controller bindings as decribed in mux-controller.txt
> +
> +Optional properties:
> +- idle-state : if present, the state the mux will have when idle. The
> + special state MUX_IDLE_AS_IS is the default.
> +
> +The multiplexer state is defined as the value of the bitfield described
> +by the reg, bit-mask, and bit-shift properties, accessed through the parent
> +syscon.
> +
> +Example:
> +
> + syscon {
> + compatible = "syscon";
> +
> + mux: mux-controller@3 {
> + compatible = "mmio-mux";
> + reg = <0x3>;
> + bit-mask = <0x1>;
> + bit-shift = <5>;
> + #mux-control-cells = <0>;
> + };
> + };
> +
> + video-mux {
I like this as an example consumer of a mmio-mux, but just
the same some might argue this doesn't really fit here.
Steve
> + compatible = "video-mux";
> + mux-controls = <&mux>;
> +
> + ports {
> + /* input 0 */
> + port@0 {
> + reg = <0>;
> + };
> +
> + /* input 1 */
> + port@1 {
> + reg = <1>;
> + };
> +
> + /* output */
> + port@2 {
> + reg = <2>;
> + };
> + };
> + };
next prev parent reply other threads:[~2017-04-14 1:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-13 15:48 [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings Philipp Zabel
2017-04-13 15:48 ` [RFC 2/2] mux: mmio-based syscon mux controller Philipp Zabel
2017-04-14 1:09 ` Steve Longerbeam
2017-04-19 11:50 ` Philipp Zabel
2017-04-19 11:58 ` Peter Rosin
2017-04-19 15:27 ` Philipp Zabel
2017-04-19 16:23 ` Steve Longerbeam
2017-04-19 16:32 ` Philipp Zabel
2017-04-19 16:42 ` Peter Rosin
2017-04-14 1:03 ` Steve Longerbeam [this message]
2017-04-19 11:47 ` [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings Philipp Zabel
2017-04-18 8:19 ` Philipp Zabel
2017-04-18 10:08 ` Sakari Ailus
2017-04-18 10:34 ` Pavel Machek
2017-04-18 10:55 ` Sakari Ailus
2017-04-18 11:51 ` Pavel Machek
2017-04-18 10:51 ` Philipp Zabel
2017-04-19 22:09 ` Rob Herring
2017-04-20 8:14 ` Philipp Zabel
2017-04-20 11:57 ` Peter Rosin
2017-04-20 13:03 ` Philipp Zabel
2017-04-20 13:39 ` Rob Herring
2017-04-20 13:32 ` Peter Rosin
2017-04-20 14:13 ` Peter Rosin
2017-04-20 14:50 ` Philipp Zabel
2017-04-20 15:01 ` Peter Rosin
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=d6d32063-5df3-3848-32f5-824c500a8927@gmail.com \
--to=slongerbeam@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=p.zabel@pengutronix.de \
--cc=peda@axentia.se \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@iki.fi \
/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).