linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
	Peter Rosin <peda@axentia.se>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Steve Longerbeam <slongerbeam@gmail.com>,
	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: Tue, 18 Apr 2017 13:51:59 +0200	[thread overview]
Message-ID: <20170418115159.GD14505@amd> (raw)
In-Reply-To: <20170418105540.GH7456@valkosipuli.retiisi.org.uk>

[-- Attachment #1: Type: text/plain, Size: 4114 bytes --]

On Tue 2017-04-18 13:55:40, Sakari Ailus wrote:
> On Tue, Apr 18, 2017 at 12:34:53PM +0200, Pavel Machek wrote:
> > On Tue 2017-04-18 13:08:41, Sakari Ailus wrote:
> > > Hi Philipp,
> > > 
> > > On Tue, Apr 18, 2017 at 10:19:04AM +0200, Philipp Zabel wrote:
> > > > On Thu, 2017-04-13 at 17:48 +0200, Philipp Zabel wrote:
> > > > > This adds device tree binding documentation for mmio-based syscon
> > > > > multiplexers controlled by a single bitfield in a syscon register
> > > > > range.
> > > > > 
> > > > > 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
> > > > > +device tree node must be a syscon node to provide register access.
> > > > > +
> > > > > +Required properties:
> > > > > +- compatible : "gpio-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 {
> > > > > +		compatible = "video-mux";
> > > > > +		mux-controls = <&mux>;
> > > > > +
> > > > > +		ports {
> > > > > +			/* input 0 */
> > > > > +			port@0 {
> > > > > +				reg = <0>;
> > > > > +			};
> > > > > +
> > > > > +			/* input 1 */
> > > > > +			port@1 {
> > > > > +				reg = <1>;
> > > > > +			};
> > > > > +
> > > > > +			/* output */
> > > > > +			port@2 {
> > > > > +				reg = <2>;
> > > > > +			};
> > > > > +		};
> > > > > +	};
> > > > 
> > > > So Pavel (added to Cc:) suggested to merge these into one node for the
> > > > video mux, as really we are describing a single hardware entity that
> > > > happens to be multiplexing multiple video buses into one:
> > > 
> > > Two drivers will be needed in a way or another to disconnect the dependency
> > > between the video switch driver and the MUX implementation. Are there ways
> > > to do that cleanly other than having two devices?
> > 
> > Yes.
> > 
> > Device tree describes hardware, not the driver structure.
> 
> I think you you could view the MUX control as a device, too, and that's
> separate from the actual video switch.

Actually, I believe what matters here is hardware. There's some chip,
somewhere, that does the switching, and the device tree should should
basically describe that switch.


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2017-04-18 11:52 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 ` [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings Steve Longerbeam
2017-04-19 11:47   ` 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 [this message]
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=20170418115159.GD14505@amd \
    --to=pavel@ucw.cz \
    --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 \
    --cc=slongerbeam@gmail.com \
    /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).