From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755515AbdDRKGn (ORCPT ); Tue, 18 Apr 2017 06:06:43 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:40451 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753239AbdDRKGk (ORCPT ); Tue, 18 Apr 2017 06:06:40 -0400 Message-ID: <1492509996.2432.63.camel@pengutronix.de> Subject: Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux From: Philipp Zabel To: Peter Rosin Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Mark Rutland , devicetree@vger.kernel.org, Lars-Peter Clausen , Wolfram Sang , linux-iio@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, kernel@pengutronix.de, Paul Gortmaker , Rob Herring , linux-i2c@vger.kernel.org, Peter Meerwald-Stadler , Hartmut Knaack , Colin Ian King , Andrew Morton , Jonathan Cameron Date: Tue, 18 Apr 2017 12:06:36 +0200 In-Reply-To: <1492101794-13444-3-git-send-email-peda@axentia.se> References: <1492101794-13444-1-git-send-email-peda@axentia.se> <1492101794-13444-3-git-send-email-peda@axentia.se> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:3ad5:47ff:feaf:1a17 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote: > Allow specifying that a single multiplexer controller can be used to > control several parallel multiplexers, thus enabling sharing of the > multiplexer controller by different consumers. > > Add a binding for a first mux controller in the form of a GPIO based mux > controller. > > Acked-by: Jonathan Cameron > Acked-by: Rob Herring > Signed-off-by: Peter Rosin > --- > Documentation/devicetree/bindings/mux/gpio-mux.txt | 69 +++++++++ > .../devicetree/bindings/mux/mux-controller.txt | 157 +++++++++++++++++++++ > MAINTAINERS | 6 + > include/dt-bindings/mux/mux.h | 16 +++ > 4 files changed, 248 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mux/gpio-mux.txt > create mode 100644 Documentation/devicetree/bindings/mux/mux-controller.txt > create mode 100644 include/dt-bindings/mux/mux.h > > diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.txt b/Documentation/devicetree/bindings/mux/gpio-mux.txt > new file mode 100644 > index 000000000000..b8f746344d80 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mux/gpio-mux.txt > @@ -0,0 +1,69 @@ > +GPIO-based multiplexer controller bindings > + > +Define what GPIO pins are used to control a multiplexer. Or several > +multiplexers, if the same pins control more than one multiplexer. > + > +Required properties: > +- compatible : "gpio-mux" > +- mux-gpios : list of gpios used to control the multiplexer, least > + significant bit first. > +- #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 number represented by the > +multiplexer GPIO pins, where the first pin is the least significant > +bit. An active pin is a binary 1, an inactive pin is a binary 0. > + > +Example: > + > + mux: mux-controller { > + compatible = "gpio-mux"; > + #mux-control-cells = <0>; > + > + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, > + <&pioA 1 GPIO_ACTIVE_HIGH>; > + }; > + > + adc-mux { > + compatible = "io-channel-mux"; > + io-channels = <&adc 0>; > + io-channel-names = "parent"; > + > + mux-controls = <&mux>; > + > + channels = "sync-1", "in", "out", "sync-2"; > + }; Could you explain in more detail the reasoning behind this split between the mux controller and the actual mux? For SoC internal video bus muxes that are controlled by a register bitfield, it seems a bit strange to have to split them into two device tree nodes. Basically I'm trying to figure out whether a video mux (which has a mux control plus OF-graph bindings to describe its ports and connections) would fit into the same category as an adc-mux or i2c-mux, or whether it would be better to handle them as a specialized form of mux-controller. regards Philipp