Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties
From: Andy Shevchenko @ 2017-04-28 16:23 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
	Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
	linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdbkBtJGJ_5MVy2QSAa0zcKVm=_H+vC_kH4AUcX58TiaLg@mail.gmail.com>

On Fri, Apr 28, 2017 at 11:16 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:

> But why.
>
> I have these two static inlines just below your new macros:

+1.

> We generally prefer static inlines over macros because they are easier
> to read.

Not only. It adds type checking as well AFAIUC.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply

* Re: linux-next: Tree for Apr 28 (of/unittest)
From: Randy Dunlap @ 2017-04-28 16:44 UTC (permalink / raw)
  To: Stephen Rothwell, Linux-Next Mailing List
  Cc: Linux Kernel Mailing List, devicetree@vger.kernel.org
In-Reply-To: <20170428171121.4a21b861@canb.auug.org.au>

On 04/28/17 00:11, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20170427:
> 

on i386:

when CONFIG_OF_OVERLAY is not enabled:

drivers/built-in.o: In function `unflatten_device_tree':
(.init.text+0x1209f): undefined reference to `unittest_unflatten_overlay_base'


-- 
~Randy

^ permalink raw reply

* RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Chris Brandt @ 2017-04-28 16:46 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Linus Walleij, Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart,
	Rob Herring, Mark Rutland, Russell King - ARM Linux,
	Linux-Renesas, linux-gpio@vger.kernel.org, devicetree,
	linux-kernel@vger.kernel.org
In-Reply-To: <CAHp75VfYPfm_GKPzvX7Go010fRi99t12ub7VUPubB6z3HnsFLg@mail.gmail.com>

On Friday, April 28, 2017, Andy Shevchenko wrote:
> > We were using "input-enable" to signal when the pin function that we set
> also needs to be forcible set to input by the software (once again,
> because the HW is not smart enough to do it on its own), but is different
> than the bi-directional functionality (ie, a different register setting).
> 
> You are trying to introduce an abstraction, called BiDi, which is
> *not* a separate thing from a set of pin properties.

Note, I'm talking about 2 different issues we had:

1) Pins that need input and output buffers enabled during normal use. We created "bi-directional" for that.

2) For whatever reason, the HW manual points out that the PFC hardware can't really automatically set buffers enables correctly for some pin instances, and we have to manually assign the pin as input or output using another register. For that, we were using "input-enable" and "output-enable".


For #2:

> > Note that we added a enable-output for the same reason.
> > See RZ/A1H HW Manual section "Table 54.7 Alternative Functions that
> PIPCn.PIPCnm Bit Should be Set to 0"
> 
> Perhaps needs to be revisited as well.

Sorry, we didn't 'add' anything new. The property "output-enable", (ie, PIN_CONFIG_OUTPUT) already existed and describes what we are doing in the case for output.

But, we still have the issue that we have 2 cases that need the input enabled, but they are not the same situation, so we can't just use "input-enable" for both.


My only suggestion is (and I'm not sure this is possible in the driver):

"input-enable"  : case #2 where you need the pin to be forced as an input
"output-enable" : case #2 where you need the pin to be forced as an output
"input-enable" + "output-enable" : case #1 (replaces "bi-directional").

For example:

	i2c2_pins: i2c2 {
		pinmux = <RZA1_PINMUX(1, 4, 1)>, <RZA1_PINMUX(1, 5, 1)>;
		input-enable;
		output-enable;
	};

So in the SW driver, if we see both, that will signal to us what is going on and what to do about it (as in, set the bi-directional register and not the input direction register).


Thoughts?


Chris


^ permalink raw reply

* Re: [PATCH v2] power: tps65217_charger: Add properties like voltage and current charge
From: Rob Herring @ 2017-04-28 16:49 UTC (permalink / raw)
  To: Enric Balletbo i Serra
  Cc: Sebastian Reichel, Mark Rutland, linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170421155032.22784-1-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>

On Fri, Apr 21, 2017 at 05:50:32PM +0200, Enric Balletbo i Serra wrote:
> Allow the possibility to configure the charge and the current voltage of
> the charger and also the NTC type for battery temperature measurement.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> Changes since v1:
>  - Requested by Rob Herring
>    - Rename ti,charge-* to charge-* to be standard properties.
>    - Use unit suffixes as per bindings/property-units.txt
> ---
>  .../bindings/power/supply/tps65217_charger.txt     |  15 ++

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

>  drivers/power/supply/tps65217_charger.c            | 187 +++++++++++++++++++--
>  include/linux/mfd/tps65217.h                       |   2 +
>  3 files changed, 192 insertions(+), 12 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH RFC 5/7] ASoC: Add Odroid sound DT bindings documentation
From: Rob Herring @ 2017-04-28 17:03 UTC (permalink / raw)
  To: Sylwester Nawrocki
  Cc: linux-samsung-soc, linux-clk, dri-devel, alsa-devel, devicetree,
	inki.dae, sw0312.kim, cw00.choi, javier, krzk, jy0922.shim,
	broonie, b.zolnierkie
In-Reply-To: <1492795191-31298-6-git-send-email-s.nawrocki@samsung.com>

On Fri, Apr 21, 2017 at 07:19:49PM +0200, Sylwester Nawrocki wrote:
> This patch adds DT binding documentation for Odroid XU3/4
> sound subsystem.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
>  .../devicetree/bindings/sound/samsung,odroid.txt   | 57 ++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/samsung,odroid.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.txt b/Documentation/devicetree/bindings/sound/samsung,odroid.txt
> new file mode 100644
> index 0000000..c1ac70c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.txt
> @@ -0,0 +1,57 @@
> +Samsung Exynos Odroid XU3/XU4 audio complex with MAX98090 codec
> +
> +Required properties:
> +
> + - compatible - "samsung,odroidxu3-audio" - for Odroid XU3 board,
> +		"samsung,odroidxu4-audio" - for Odroid XU4 board
> + - model - the user-visible name of this sound complex

ASoC will support "label" soon (see graph support). Use that instead.

> + - 'cpu' subnode with a 'sound-dai' property containing the phandle of the I2S
> +    controller
> + - 'codec' subnode with a 'sound-dai' property containing list of phandles
> +    to the CODEC nodes, first entry must be corresponding to the MAX98090
> +    CODEC and the second entry must be the phandle of the HDMI IP block node

These are not properties, so move them to a sub-node section.

> + - clocks - should contain entries matching clock names in the clock-names
> +    property
> + - clock-names - should contain following entries:
> +    - "epll" - indicating the EPLL output clock
> +    - "i2s_rclk" - indicating the RCLK (root) clock of the I2S0 controller

At least the 2nd one should be in the i2s node. This node isn't really a 
h/w block, so it shouldn't have clocks IMO.

> + - samsung,audio-widgets - this property specifies off-codec audio elements
> +   like headphones or speakers, for details see widgets.txt
> + - samsung,audio-routing - a list of the connections between audio
> +   components;  each entry is a pair of strings, the first being the
> +   connection's sink, the second being the connection's source;
> +   valid names for sources and sinks are the MAX98090's pins (as
> +   documented in its binding), and the jacks on the board
> +
> +   For Odroid X2:
> +     "Headphone Jack", "Mic Jack", "DMIC"
> +
> +   For Odroid U3, XU3:
> +     "Headphone Jack", "Speakers"
> +
> +   For Odroid XU4:
> +     no entries
> +
> +Example:
> +
> +sound {
> +	compatible = "samsung,odroidxu3-audio";

> +	samsung,cpu-dai = <&i2s0>;
> +	samsung,codec-dai = <&max98090>;

Not documented. Nor needed?

> +	model = "Odroid-XU3";
> +	samsung,audio-routing =
> +		"Headphone Jack", "HPL",
> +		"Headphone Jack", "HPR",
> +		"IN1", "Mic Jack",
> +		"Mic Jack", "MICBIAS";
> +
> +	clocks = <&clock CLK_FOUT_EPLL>, <&i2s0 CLK_I2S_RCLK_SRC>;
> +	clock-names = "epll", "sclk_i2s";
> +
> +	cpu {
> +		sound-dai = <&i2s0 0>;
> +	};
> +	codec {
> +		sound-dai = <&hdmi>, <&max98090>;
> +	};
> +};
> -- 
> 1.9.1
> 

^ permalink raw reply

* Re: [PATCH] streamline TLV320AIC23 drivers
From: Rob Herring @ 2017-04-28 17:11 UTC (permalink / raw)
  To: Jens Rottmann
  Cc: Mark Rutland, Jaroslav Kysela, Takashi Iwai,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Mark Brown
In-Reply-To: <b4127646-565b-ab16-0a8f-1fd6c263389e-AbX7Xxim+f4qDJ6do+/SaQ@public.gmane.org>

On Fri, Apr 21, 2017 at 09:22:02PM +0200, Jens Rottmann wrote:
> The iMX-TLV320AIC23 driver isn't from Freescale, but from a company named
> Eukrea Electromatique, originally for their own boards. From the code I get
> the impression it is a bit older, its DT options use a differing naming
> scheme. Patch it up a bit:

Needs a subject following the format of the subsystem.

> 
> - Remove Eukrea naming, i.MX is from Freescale, TLV320AIC23 is from TI,
>   driver was written by Eukrea, but it's DT capable, so it's not exclusive:
>   - Kconfig option title
>   - 'model' option
>   - driver 'compatible' string
> - Other options just have changed over time, this driver remaining (one of)
>   the last with the old semantics:
>   - 'audio-codec' option (also moved from ssi node)
>   - 'mux-int/ext-port' options
> - All options stay backwards compatible, the DT binding documents new and
>   old names.
> 
> CONFIG variable and files have not been renamed, though, so no need to
> change old defconfigs.
> 
> Signed-off-by: Jens Rottmann <Jens.Rottmann-AbX7Xxim+f4qDJ6do+/SaQ@public.gmane.org>
> ---
> 
> --- a/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt
> +++ b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt

Perhaps change the filename. The compatible string is a good choice.

> @@ -1,16 +1,23 @@
> -Audio complex for Eukrea boards with tlv320aic23 codec.
> +Audio complex for Freescale i.MX boards with TI TLV320AIC23 I2S codecs,
> +like those from Eukrea Electromatique.
>  
>  Required properties:
>  
> -  - compatible		: "eukrea,asoc-tlv320"
> +  - compatible		: "fsl,imx-audio-tlv320aic23" or
> +			  "eukrea,asoc-tlv320" (deprecated)
>  
> -  - eukrea,model	: The user-visible name of this sound complex.
> +  - model		: The user-visible name of this sound complex.
> +  - eukrea,model	: Dito, deprecated.
>  
>    - ssi-controller	: The phandle of the SSI controller.
>  
> -  - fsl,mux-int-port	: The internal port of the i.MX audio muxer (AUDMUX).
> +  - mux-int-port	: The internal port of the i.MX audio muxer (AUDMUX).
> +  - fsl,mux-int-port	: Dito, deprecated.
>  
> -  - fsl,mux-ext-port	: The external port of the i.MX audio muxer.
> +  - mux-ext-port	: The external port of the i.MX audio muxer.
> +  - fsl,mux-ext-port	: Dito, deprecated.

Is this used elsewhere? This is FSL specific, so you should keep the 
prefix.

> +
> +  - audio-codec		: The phandle of the audio codec.
>  
>  Note: The AUDMUX port numbering should start at 1, which is consistent with
>  hardware manual.
> @@ -18,9 +25,10 @@ hardware manual.
>  Example:
>  
>  	sound {
> -		compatible = "eukrea,asoc-tlv320";
> -		eukrea,model = "imx51-eukrea-tlv320aic23";
> +		compatible = "fsl,imx-audio-tlv320aic23";
> +		model = "imx51-eukrea-tlv320aic23";
>  		ssi-controller = <&ssi2>;
> -		fsl,mux-int-port = <2>;
> -		fsl,mux-ext-port = <3>;
> +		mux-int-port = <2>;
> +		mux-ext-port = <3>;
> +		audio-codec = <&codec>;
>  	};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 3/5] mtd: gpmi: document current clock requirements
From: Rob Herring @ 2017-04-28 17:13 UTC (permalink / raw)
  To: Stefan Agner
  Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
	computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
	boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
	marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, richard-/L3Ra7n9ekc,
	cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
	shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
	han.xu-3arQi8VN3Tc, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
	LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170422012338.4635-4-stefan-XLVq0VzYD2Y@public.gmane.org>

On Fri, Apr 21, 2017 at 06:23:36PM -0700, Stefan Agner wrote:
> The clock requirements are completely missing, add the clocks
> currently required by the driver.
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/mtd/gpmi-nand.txt | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [RFC 1/3] dt-binding: soc: qcom: Add binding for RFSA
From: Rob Herring @ 2017-04-28 17:42 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Frank Rowand, Mark Rutland,
	linux-arm-msm, linux-soc, devicetree, linux-kernel
In-Reply-To: <20170422173519.5782-1-bjorn.andersson@linaro.org>

On Sat, Apr 22, 2017 at 10:35:17AM -0700, Bjorn Andersson wrote:
> This adds the binding for describing shared memory buffers for
> implementing the remote filesystem protocol.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> My initial attempt was to mimic the ramoops of just adding the compatible to
> the reserved-memory node, but I have not been able to figure out a sane way of
> getting hold of the base address in the case that the memory region is
> described my a "size" only (done on some platforms).

I prefer the ramoops way.

> The problem is that we create the reserved_mem objects (and remove the
> memblocks) while we're still operating on the flattened representation, so
> without a phandle it doesn't seem like we have anything to perform the
> comparison with later on.

I'm not sure I follow.

> 
>  .../devicetree/bindings/soc/qcom/qcom,rfsa.txt     | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,rfsa.txt
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rfsa.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,rfsa.txt
> new file mode 100644
> index 000000000000..b4de0de74e46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rfsa.txt
> @@ -0,0 +1,43 @@
> +Qualcomm Remote File System Access binding
> +
> +This binding describes the Qualcomm RFSA, which serves the purpose of managing
> +the shared memory region used for remote processors to access block device data
> +using the Remote Filesystem protocol.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be:
> +		    "qcom,rfsa"

No versioning?

> +
> +- memory-region:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: handle to memory reservation the associated rfsa region.
> +
> +- qcom,client-id:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: identifier of the client to use this region for buffers.

What determines these numbers?

> +
> += EXAMPLE
> +The following example shows the RFSA setup for APQ8016, with the RFSA region
> +for the Hexagon DSP (id #1) located at 0x86700000.
> +
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		rmtfs: rmtfs@86700000 {

I think you should have a compatible here even with the 2 node approach.

> +			reg = <0x0 0x86700000 0x0 0xe0000>;
> +			no-map;
> +		};
> +	};
> +
> +	hexagon-rfsa {
> +		compatible = "qcom,rfsa";
> +		memory-region = <&rmtfs>;
> +
> +		qcom,client-id = <1>;
> +	};
> -- 
> 2.12.0
> 

^ permalink raw reply

* Re: [PATCH 2/2] dt-bindings: phy: Add documentation for Mediatek PCIe PHY
From: Rob Herring @ 2017-04-28 17:52 UTC (permalink / raw)
  To: Ryder Lee
  Cc: devicetree, linux-kernel, Kishon Vijay Abraham I, linux-mediatek,
	Matthias Brugger, linux-arm-kernel
In-Reply-To: <1492935453-17373-3-git-send-email-ryder.lee@mediatek.com>

On Sun, Apr 23, 2017 at 04:17:33PM +0800, Ryder Lee wrote:
> Add documentation for PCIe PHY available in MT7623 series SoCs.
> 
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
>  .../devicetree/bindings/phy/phy-mt7623-pcie.txt    | 67 ++++++++++++++++++++++
>  1 file changed, 67 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-mt7623-pcie.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt7623-pcie.txt b/Documentation/devicetree/bindings/phy/phy-mt7623-pcie.txt
> new file mode 100644
> index 0000000..27a9253
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mt7623-pcie.txt
> @@ -0,0 +1,67 @@
> +Mediatek MT7623 PCIe PHY
> +-----------------------
> +
> +Required properties:
> + - compatible: Should contain "mediatek,mt7623-pcie-phy"
> + - #phy-cells: must be 0
> + - clocks: Must contain an entry in clock-names.
> +	See ../clocks/clock-bindings.txt for details.
> + - clock-names: Must be "refclk"
> + - resets: Must contain an entry in reset-names.
> +	See ../reset/reset.txt for details.
> + - reset-names: Must be "phy"
> +
> +Optional properties:
> + - phy-switch: The PHY on PCIe port2 is shared with USB u3phy2. If you
> +	want to enable port2, you should contain it.

Need to state what the value is (i.e. a phandle to ?). Also needs a 
vendor prefix.

> +
> +Example:
> +
> +	pcie0_phy: pciephy@1a149000 {

pcie-phy@...

> +		compatible = "mediatek,mt7623-pcie-phy";
> +		reg = <0 0x1a149000 0 0x1000>;
> +		clocks = <&clk26m>;
> +		clock-names = "pciephya_ref";
> +		#phy-cells = <0>;
> +		status = "disabled";

Don't show status in examples.

> +	};
> +
> +	pcie1_phy: pciephy@1a14a000 {
> +		compatible = "mediatek,mt7623-pcie-phy";
> +		reg = <0 0x1a14a000 0 0x1000>;
> +		clocks = <&clk26m>;
> +		clock-names = "pciephya_ref";
> +		#phy-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	pcie2_phy: pciephy@1a244000 {
> +		compatible = "mediatek,mt7623-pcie-phy";
> +		reg = <0 0x1a244000 0 0x1000>;
> +		clocks = <&clk26m>;
> +		clock-names = "pciephya_ref";
> +		#phy-cells = <0>;
> +
> +		phy-switch = <&hifsys>;
> +		status = "disabled";
> +	};
> +
> +Specifying phy control of devices
> +---------------------------------
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the phy node and phy-names.
> +
> +Example:
> +
> +#include <dt-bindings/phy/phy.h>
> +
> +pcie: pcie@1a140000 {
> +	...
> +	pcie@1,0 {
> +		...
> +		phys = <&pcie0_phy>;
> +		phy-names = "pcie-phy0";
> +	}
> +	...
> +};
> -- 
> 1.9.1
> 

^ permalink raw reply

* Re: [PATCH v5 01/11] dt-bindings: add binding for the Allwinner DE2 CCU
From: Rob Herring @ 2017-04-28 17:52 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
	linux-clk-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170423103754.50012-2-icenowy-h8G6r0blFSE@public.gmane.org>

On Sun, Apr 23, 2017 at 06:37:44PM +0800, Icenowy Zheng wrote:
> Allwinner "Display Engine 2.0" contains some clock controls in it.
> 
> In order to add them as clock drivers, we need a device tree binding.
> Add the binding here.
> 
> Also add the device tree binding headers.
> 
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v5:
> - Moved dt-binding headers here.
> - Changed dt-binding headers' license header to SPDX license.
> Changes in v4:
> - Dropped the leading 0 in clock at 1000000 .
> Changes in v3:
> - Fill the address space length of DE2 CCU to 0x100000, just reach the start of mixer0.
> 
>  .../devicetree/bindings/clock/sun8i-de2.txt        | 31 ++++++++++++++++++++++
>  include/dt-bindings/clock/sun8i-de2.h              | 18 +++++++++++++
>  include/dt-bindings/reset/sun8i-de2.h              | 14 ++++++++++
>  3 files changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
>  create mode 100644 include/dt-bindings/clock/sun8i-de2.h
>  create mode 100644 include/dt-bindings/reset/sun8i-de2.h

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

^ permalink raw reply

* Re: [PATCH 1/2] dt: bindings: fpga: add lattice machxo2 slave spi binding description
From: Rob Herring @ 2017-04-28 17:54 UTC (permalink / raw)
  To: Paolo Pisati
  Cc: Mark Rutland, Alan Tull, Moritz Fischer, devicetree, linux-fpga,
	linux-kernel
In-Reply-To: <1492960845-342-2-git-send-email-p.pisati@gmail.com>

On Sun, Apr 23, 2017 at 05:20:44PM +0200, Paolo Pisati wrote:
> Add dt binding documentation details for Lattice MachXO2 FPGA configuration
> over Slave SPI interface.
> 
> Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
> ---
>  .../bindings/fpga/lattice-machxo2-spi.txt          | 29 ++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fpga/lattice-machxo2-spi.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: add bindings doc for ZTE pinctrl
From: Rob Herring @ 2017-04-28 17:58 UTC (permalink / raw)
  To: Shawn Guo
  Cc: devicetree, Xin Zhou, Linus Walleij, Baoyou Xie, linux-gpio,
	Jun Nie, Shawn Guo, linux-arm-kernel
In-Reply-To: <1493038873-18354-2-git-send-email-shawnguo@kernel.org>

On Mon, Apr 24, 2017 at 09:01:12PM +0800, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
> 
> It adds device tree bindings for ZTE pin controller found on ZX2967xx
> family SoCs.
> 
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
>  .../devicetree/bindings/pinctrl/pinctrl-zx.txt     | 85 ++++++++++++++++++++++
>  1 file changed, 85 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-zx.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 1/2] thermal: broadcom: Allow for NSP to use ns-thermal driver
From: Jon Mason @ 2017-04-28 18:04 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: Florian Fainelli, Zhang Rui, Rob Herring, Mark Rutland,
	BCM Kernel Feedback, linux-arm-kernel, open list, linux-pm,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20170428130659.GA28546@localhost.localdomain>

On Fri, Apr 28, 2017 at 9:07 AM, Eduardo Valentin <edubezval@gmail.com> wrote:
> On Thu, Apr 27, 2017 at 01:42:25PM -0400, Jon Mason wrote:
>> On Thu, Apr 27, 2017 at 12:37 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
>> > Hey Jason,
>>
>> It's Jon :)
>
> Apologies. I think I either read too fast, or my fingers were faster
> than my brain. Sorry.

NP,  That exact error happens more frequently that you would think :)

>>
>> >
>> > On Tue, Apr 25, 2017 at 04:49:10PM -0400, Jon Mason wrote:
>> >> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
>> >> the ns-thermal driver to be selected via menuconfig.  Also, change the
>> >> ns-thermal driver to work on any iProc based SoC.  Finally, tweak the
>> >> Kconfig description to mention support for NSP and make the default on
>> >> for iProc based platforms.
>> >
>> >
>> > Thanks for the patch, but..
>> >>
>> >> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>> >> ---
>> >>  arch/arm/mach-bcm/Kconfig        | 2 ++
>> >>  drivers/thermal/broadcom/Kconfig | 9 +++++----
>> >>  2 files changed, 7 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> >> index a0e66d8..da2bfeb 100644
>> >> --- a/arch/arm/mach-bcm/Kconfig
>> >> +++ b/arch/arm/mach-bcm/Kconfig
>> >> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
>> >>       select GPIOLIB
>> >>       select ARM_AMBA
>> >>       select PINCTRL
>> >> +     select THERMAL
>> >> +     select THERMAL_OF
>> >>       help
>> >>         This enables support for systems based on Broadcom IPROC architected SoCs.
>> >>         The IPROC complex contains one or more ARM CPUs along with common
>> >
>> > It would be better if this is split and sent through your arch tree, to
>> > avoid conflicts. I could also pick it if you get an ack from one of your
>> > maintainers. Still, first option is preferable.
>>
>> Sure, I'll be happy to split this off.  I should've thought to split
>> it up before sending.  Thanks for the suggestion.
>
> Cool!
>
>>
>> >
>> >> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
>> >> index f0dea8a..26d706c 100644
>> >> --- a/drivers/thermal/broadcom/Kconfig
>> >> +++ b/drivers/thermal/broadcom/Kconfig
>> >> @@ -1,8 +1,9 @@
>> >>  config BCM_NS_THERMAL
>> >>       tristate "Northstar thermal driver"
>> >>       depends on ARCH_BCM_IPROC || COMPILE_TEST
>> >> +     default ARCH_BCM_IPROC
>> >
>> > Not sure if this is really what you wanted. Based on your commit log
>> > message, you meant the following, perhaps?
>> >
>> >  +      default y if ARCH_BCM_IPROC
>>
>> IIUC, my original default works, as we have used it frequently in
>> other places in the kernel.
>> grep -rI "default ARCH_BCM_IPROC" * | wc -l
>> 15
>
> Yeah... Are you sure they are all correct?
>
>>
>> However, if the above is preferred (or the other 15 massively broken),
>> I'll be happy to do it that way.
>
> Your construction is syntactically correct. Maybe might still work (did
> not check myself) for the purpose you describe, but the construction
> mentioned in Documentation/kbuild/kconfig-language.txt is:
>  +      default y if BAR
>
> So, please fix it.

Oh, thanks for the info.  I was unaware of this, and we should
definitely follow the documentation..  I'll make the relevant changes
and do follow-on patches to correct the other places.

>
>>
>>
>> >>       help
>> >> -       Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
>> >> -       BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
>> >> -       with a thermal sensor that allows checking CPU temperature. This
>> >> -       driver provides support for it.
>> >> +       Support for the Northstar and Northstar Plus family of SoCs (e.g.
>> >> +       BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
>> >
>> > Did we look BCM47094 somehow on this patch?
>>
>> Naa, just trying to be more concise, while adding the NSP products to
>> the list..  BCM47094 is a type of BCM4709.  So, it is still there :)
>>
>> >
>> >> +       Management Unit) block with a thermal sensor that allows checking CPU
>> >> +       temperature.
>> >> --
>> >> 2.7.4
>> >>

^ permalink raw reply

* Re: [PATCH v2 1/3] ARM: BCM: Enable thermal support for iProc SoCs
From: Jon Mason @ 2017-04-28 18:05 UTC (permalink / raw)
  To: Scott Branden
  Cc: Florian Fainelli, Zhang Rui, Eduardo Valentin, Rob Herring,
	Mark Rutland, BCM Kernel Feedback, linux-arm-kernel, open list,
	linux-pm,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <bceb9b66-c769-faf3-9288-26581b5d5dc6@broadcom.com>

On Thu, Apr 27, 2017 at 7:10 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
>
>
> On 17-04-27 02:23 PM, Jon Mason wrote:
>>
>> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
>> the ns-thermal driver to be selected via menuconfig.
>>
>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>> ---
>>  arch/arm/mach-bcm/Kconfig | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index a0e66d8..da2bfeb 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
>>         select GPIOLIB
>>         select ARM_AMBA
>>         select PINCTRL
>> +       select THERMAL
>> +       select THERMAL_OF
>
> This is NSP specific at this point.  Also, If it increases code size in any
> way it shouldn't be selected for all IPROC SoCS.  I'd rather this was just
> selected via defconfig

This isn't selectable via menuconfig without being in the kconfig.
I'll move it to the NSP portion of the kconfig, as to not increase the
size of other's kernels.

Thanks,
Jon

>
>>         help
>>           This enables support for systems based on Broadcom IPROC
>> architected SoCs.
>>           The IPROC complex contains one or more ARM CPUs along with
>> common
>>
>

^ permalink raw reply

* Re: [PATCH v2 15/18] dt-bindings: sound: Add bindings for Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:06 UTC (permalink / raw)
  To: Mark Brown
  Cc: Richard Fitzgerald, lee.jones, linus.walleij, gnurou, tglx, jason,
	alsa-devel, patches, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20170425155257.s6m4wgrzxxsxcggo@sirena.org.uk>

On Tue, Apr 25, 2017 at 04:52:57PM +0100, Mark Brown wrote:
> On Mon, Apr 24, 2017 at 05:08:41PM +0100, Richard Fitzgerald wrote:
> > The Cirrus Logic Madera codecs are a family of related codecs with
> > extensive digital and analogue I/O, digital mixing and routing,
> > signal processing and programmable DSPs.
> 
> Please submit patches using subject lines reflecting the style for the
> subsystem.  This makes it easier for people to identify relevant
> patches.  Look at what existing commits in the area you're changing are
> doing and make sure your subject lines visually resemble what they're
> doing.
> 
> > +Required properties:
> > +  - compatible : One of the following chip-specific strings:
> > +        "cirrus,cs47l35-codec"
> > +        "cirrus,cs47l85-codec"
> > +        "cirrus,cs47l90-codec"
> 
> You shouldn't have compatible strings for subfunctions of a MFD unless
> these represent meaningful reusable IPs that can exist separately from
> the parent chip, that's clearly not the case here.  All you're doing
> here is encoding Linux internal abstractions which aren't OS neutral and
> might change in future (for example clocking might move more into the
> clock API).

s/compatible strings/child nodes/ and I agree. If you have child nodes, 
then they need to have compatible strings so we can tell what child is 
which. Node name can be used, but there's no way to version node names. 
A compatible implies what properties are valid.

Rob


^ permalink raw reply

* Re: [PATCH v2 03/18] dt-bindings: mfd: Add bindings for Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:07 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: lee.jones, broonie, linus.walleij, gnurou, tglx, jason,
	alsa-devel, patches, linux-gpio, devicetree, linux-kernel
In-Reply-To: <1493050124-5970-4-git-send-email-rf@opensource.wolfsonmicro.com>

On Mon, Apr 24, 2017 at 05:08:29PM +0100, Richard Fitzgerald wrote:
> Specification of the bindings for the parent MFD driver component
> of the Cirrus Logic Madera codec drivers.
> 
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> Changes since V1:
> - split out from main MFD patch
> - moved interrupt control binding descriptions into here
> - added description of the regulator child nodes
> - fixed the node name of the example
> - removed the MICBIAS from the example, these have been removed from the code
> 
>  Documentation/devicetree/bindings/mfd/madera.txt | 96 ++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/madera.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v2 07/18] regulator: arizona-micsupp: Add support for Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:07 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, broonie-DgEjT+Ai2ygdnm+yROfE0A,
	linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
	gnurou-Re5JQEeQqe8AvxtiuMwx3w, tglx-hfZtesqFncYOwBW4kG4KsQ,
	jason-NLaQJdtUoK4Be96aLqz0jA, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493050124-5970-8-git-send-email-rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>

On Mon, Apr 24, 2017 at 05:08:33PM +0100, Richard Fitzgerald wrote:
> This adds a new driver identity "madera-micsupp" and probe function
> so that this driver can be used to control the micsupp regulator on
> Cirrus Logic Madera codecs.
> 
> Signed-off-by: Richard Fitzgerald <rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
> Replaces the madera-specific driver from V1 patchset
> 
>  .../bindings/regulator/arizona-regulator.txt       |  3 +-

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

>  drivers/regulator/Kconfig                          |  7 ++-
>  drivers/regulator/arizona-micsupp.c                | 71 +++++++++++++++++++++-
>  3 files changed, 76 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 11/18] dt-bindings: pinctrl: Add bindings for Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:16 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, broonie-DgEjT+Ai2ygdnm+yROfE0A,
	linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
	gnurou-Re5JQEeQqe8AvxtiuMwx3w, tglx-hfZtesqFncYOwBW4kG4KsQ,
	jason-NLaQJdtUoK4Be96aLqz0jA, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493050124-5970-12-git-send-email-rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>

On Mon, Apr 24, 2017 at 05:08:37PM +0100, Richard Fitzgerald wrote:
> This is the binding description of the pinctrl driver for Cirru Logic
> Madera codecs. The binding uses the generic pinctrl binding so  the main
> purpose here is to describe the device-specific names for groups and
> functions.
> 
> Signed-off-by: Richard Fitzgerald <rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
> Changes since V1:
> - split out from main pinctrl patch into a separate patch
> - fixed typo in pinctrl-names property description
> 
>  .../bindings/pinctrl/cirrus,madera-pinctrl.txt     | 102 +++++++++++++++++++++
>  1 file changed, 102 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 13/18] dt-bindings: gpio: Add bindings for GPIO on Cirrus Logic Madera codecs
From: Rob Herring @ 2017-04-28 18:17 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: lee.jones, broonie, linus.walleij, gnurou, tglx, jason,
	alsa-devel, patches, linux-gpio, devicetree, linux-kernel
In-Reply-To: <1493050124-5970-14-git-send-email-rf@opensource.wolfsonmicro.com>

On Mon, Apr 24, 2017 at 05:08:39PM +0100, Richard Fitzgerald wrote:
> The Cirrus Logic Madera codecs have a range of GPIO pins that can be
> used as single-bit logic input or output. These are presented as a
> standard GPIO binding.
> 
> The second cell in a GPIO binding is currently reserved for future use
> as chip-specific flags.
> 
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> Changes from V1:
> - moved out of main gpio patch into a separate patch
> - added gpio-line-names as an optional property
> 
>  .../devicetree/bindings/gpio/gpio-madera.txt       | 27 ++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-madera.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v7 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller
From: Rob Herring @ 2017-04-28 18:19 UTC (permalink / raw)
  To: Brendan Higgins
  Cc: wsa-z923LK4zBo2bacvFa/9K2g, mark.rutland-5wv7dgnIgG8,
	tglx-hfZtesqFncYOwBW4kG4KsQ, jason-NLaQJdtUoK4Be96aLqz0jA,
	marc.zyngier-5wv7dgnIgG8, joel-U3u1mxZcP9KHXe+LvDLADg,
	vz-ChpfBGZJDbMAvxtiuMwx3w, mouse-Pma6HLj0uuo, clg-Bxea+6Xhats,
	benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	openbmc-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <20170424181818.2754-2-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

On Mon, Apr 24, 2017 at 11:18:14AM -0700, Brendan Higgins wrote:
> Added device tree binding documentation for Aspeed I2C Interrupt
> Controller.
> 
> Signed-off-by: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
> Added in v6:
>   - Pulled "aspeed_i2c_controller" out into a interrupt controller since that is
>     what it actually does.
> Changes for v7:
>   - None
> ---
>  .../interrupt-controller/aspeed,ast2400-i2c-ic.txt | 25 ++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v7 3/5] i2c: aspeed: added documentation for Aspeed I2C driver
From: Rob Herring @ 2017-04-28 18:21 UTC (permalink / raw)
  To: Brendan Higgins
  Cc: wsa, mark.rutland, tglx, jason, marc.zyngier, joel, vz, mouse,
	clg, benh, linux-i2c, devicetree, linux-kernel, openbmc
In-Reply-To: <20170424181818.2754-4-brendanhiggins@google.com>

On Mon, Apr 24, 2017 at 11:18:16AM -0700, Brendan Higgins wrote:
> Added device tree binding documentation for Aspeed I2C busses.
> 
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> ---
> Changes for v2:
>   - None
> Changes for v3:
>   - Removed reference to "bus" device tree param
> Changes for v4:
>   - None
> Changes for v5:
>   - None
> Changes for v6:
>   - Replaced the controller property with and interrupt controller, leaving only
>     the busses in the I2C documentation.
> Changes for v7:
>   - Changed clock-frequency to bus-frequency in device tree
> ---
>  .../devicetree/bindings/i2c/i2c-aspeed.txt         | 47 ++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 1/2] clk: Add bindings for the Gemini Clock Controller
From: Rob Herring @ 2017-04-28 18:24 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Michael Turquette, Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Janos Laube, Paulius Zaleckas,
	openwrt-devel-p3rKhJxN3npAfugRpC6u6w,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Hans Ulli Kroll, Florian Fainelli
In-Reply-To: <20170424185545.26608-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

On Mon, Apr 24, 2017 at 08:55:45PM +0200, Linus Walleij wrote:
> This adds device tree bindings and a header for the Gemini SoC
> Clock Controller.
> 
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  .../clock/cortina,gemini-clock-controller.txt      | 25 +++++++++++++++++++
>  include/dt-bindings/clock/cortina,gemini-clock.h   | 29 ++++++++++++++++++++++
>  2 files changed, 54 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
>  create mode 100644 include/dt-bindings/clock/cortina,gemini-clock.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
> new file mode 100644
> index 000000000000..7af84acfcbce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
> @@ -0,0 +1,25 @@
> +Clock bindings for the Cortina Systems Gemini SoC Clock Controller
> +
> +Required properties :
> +- compatible : shall contain the following:
> +  "cortina,gemini-clock-controller"
> +- #clock-cells should be <1>
> +
> +The Gemini clock controller needs to be placed as a subnode of the
> +system controller.
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/cortina,gemini-clock.h header and can be used in device
> +tree sources.
> +
> +Example:
> +
> +syscon: syscon@40000000 {
> +	compatible = "cortina,gemini-syscon", "syscon", "simple-mfd";
> +	reg = <0x40000000 0x1000>;
> +
> +	clock-controller {
> +		compatible = "cortina,gemini-clock-controller";
> +		#clock-cells = <1>;

There's not really much reason to have a child node here. The parent can 
be the clock provider.

Rob

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 1/2] reset: Add DT bindings for the Gemini reset controller
From: Rob Herring @ 2017-04-28 18:27 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Philipp Zabel, devicetree-u79uwXL29TY76Z2rM5mHXA, Janos Laube,
	Paulius Zaleckas, openwrt-devel-p3rKhJxN3npAfugRpC6u6w,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Hans Ulli Kroll, Florian Fainelli
In-Reply-To: <20170424192746.27378-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

On Mon, Apr 24, 2017 at 09:27:46PM +0200, Linus Walleij wrote:
> This is a simple reset controller in a single 32bit
> register.
> 
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  .../bindings/reset/cortina,gemini-reset.txt        | 59 ++++++++++++++++++++++
>  1 file changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> 
> diff --git a/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> new file mode 100644
> index 000000000000..21aa12901774
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> @@ -0,0 +1,59 @@
> +Cortina Gemini Reset Controller
> +
> +This reset controller is found in Cortina Systems CS3516 and
> +the predecessor StorLink SL3516.
> +
> +Required properties:
> +- compatible: "cortina,gemini-reset"
> +- #reset-cells: Must be 1
> +
> +The Gemini reset controller must be a child node of the
> +system controller. Apart from this it follows the standard reset
> +controller bindings.

Same comment as clocks. The parent can be the provider.

> +
> +Valid reset line values:
> +
> +0:  DRAM controller

Why no header like clocks?

> +1:  Flash controller
> +2:  IDE controller
> +3:  RAID controller
> +4:  Security module
> +5:  GMAC0 (ethernet)
> +6:  GMAC1 (ethernet)
> +7:  PCI host bridge
> +8:  USB0 USB host controller
> +9:  USB1 USB host controller
> +10: General DMA controller
> +11: APB bridge
> +12: LPC (Low Pin Count) controller
> +13: LCD module
> +14: Interrupt controller 0
> +15: Interrupt controller 1
> +16: RTC module
> +17: Timer module
> +18: UART controller
> +19: SSP controller
> +20: GPIO0 GPIO controller
> +21: GPIO1 GPIO controller
> +22: GPIO2 GPIO controller
> +23: Watchdog timer
> +24: External device reset
> +25: CIR module (infrared)
> +26: SATA0 SATA bridge
> +27: SATA1 SATA bridge
> +28: TVE TV Encoder module
> +29: Reserved
> +30: CPU1 reset
> +31: Global soft reset
> +
> +Example:
> +
> +syscon: syscon@40000000 {
> +	compatible = "cortina,gemini-syscon", "syscon", "simple-mfd";
> +	reg = <0x40000000 0x1000>;
> +
> +	reset-controller {
> +		compatible = "cortina,gemini-reset";
> +		#reset-cells = <1>;
> +	};
> +};
> -- 
> 2.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 1/3 v3] drm/vc4: Turn the V3D clock on at runtime.
From: Rob Herring @ 2017-04-28 18:29 UTC (permalink / raw)
  To: Eric Anholt; +Cc: Mark Rutland, devicetree, linux-kernel, dri-devel
In-Reply-To: <20170424201209.31148-1-eric@anholt.net>

On Mon, Apr 24, 2017 at 01:12:09PM -0700, Eric Anholt wrote:
> For the Raspberry Pi's bindings, the power domain also implicitly
> turns on the clock and deasserts reset, but for the new Cygnus port we
> start representing the clock in the devicetree.
> 
> v2: Document the clock-names property, check for -ENOENT for no clock
>     in DT.
> v3: Drop NULL checks around clk calls which embed NULL checks.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>  .../devicetree/bindings/display/brcm,bcm-vc4.txt   |  4 +++
>  drivers/gpu/drm/vc4/vc4_drv.h                      |  1 +
>  drivers/gpu/drm/vc4/vc4_v3d.c                      | 31 +++++++++++++++++++++-
>  3 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> index ca02d3e4db91..2318266f6481 100644
> --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> @@ -59,6 +59,10 @@ Required properties for V3D:
>  - interrupts:	The interrupt number
>  		  See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>  
> +Optional properties for V3D:
> +- clocks:	The clock the unit runs on
> +- clock-names:	Must be "v3d_clk"

clock-names is pointless for a single clock. 

> +
>  Required properties for DSI:
>  - compatible:	Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1"
>  - reg:		Physical base address and length of the DSI block's registers
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCHv2 1/3] dt-bindings: display: Intel FPGA VIP drm driver Devicetree bindings
From: Rob Herring @ 2017-04-28 18:32 UTC (permalink / raw)
  To: hean.loong.ong
  Cc: devicetree, tien.hock.loh, dri-devel, dinguyen, daniel.vetter,
	Ong
In-Reply-To: <1493086006-4392-2-git-send-email-hean.loong.ong@intel.com>

On Tue, Apr 25, 2017 at 10:06:44AM +0800, hean.loong.ong@intel.com wrote:
> From: "Ong, Hean Loong" <hean.loong.ong@intel.com>
> 
> Device tree binding for Intel FPGA Video and Image
> Processing Suite. The binding involved would be generated
> from the Altera (Intel) Qsys system. The bindings would
> set the max width, max height, buts per pixel and memory
> port width. The device tree binding only supports the Intel
> Arria10 devkit and its variants. Vendor name retained as
> altr.
> 
> Signed-off-by: Ong, Hean Loong <hean.loong.ong@intel.com>
> ---
> v2:
> * Moved Device Tree bindings to Documentation/devicetree/bindings/display/
> * Added vendor name altr, to description
> ---
>  .../devicetree/bindings/display/altr,vip-fb2.txt   | 30 ++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> new file mode 100644
> index 0000000..bdffefb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> @@ -0,0 +1,30 @@
> +Intel Video and Image Processing(VIP) Frame Buffer II bindings
> +
> +Supported hardware: Arria 10 and above with display port IP
> +
> +The drm driver for the Arria 10 devkit would require the display resolution

Bindings describe h/w. DRM driver is a Linux term.

> +and pixel information to be included as these values are generated based
> +on the FPGA design that drives the video connector attached to the drm driver
> +Information the FPGA video IP component can be acquired from
> +https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_vip.pdf
> +
> +Required properties:
> +
> +- compatible: "altr,vip-frame-buffer-2.0"
> +- reg: Physical base address and length of the framebuffer controller's
> +  registers.
> +- altr,max-width: The width of the framebuffer in pixels.
> +- altr,max-height: The height of the framebuffer in pixels.
> +- altr,bits-per-symbol: only "8" is currently supported

Supported in the driver or IP? The former isn't relevant to the binding. 
In the latter case, you don't need it if that's the only thing 
supported.

> +- altr,mem-port-width = the bus width of the avalon master port on the frame reader

In bits or bytes?

> +
> +Example:
> +
> +	dp_0_frame_buf: vip@100000280 {
> +			compatible = "altr,vip-frame-buffer-2.0";
> +			reg = <0x00000001 0x00000280 0x00000040>;
> +			altr,max-width = <1280>;
> +			altr,max-height = <720>;
> +			altr,bits-per-symbol = <8>;
> +			altr,mem-port-width = <128>;
> +	};
> -- 
> 2.7.4
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox