* 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: [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 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: [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 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 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 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: 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 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: [PATCH v4 2/2] of: Add unit tests for applying overlays
From: Geert Uytterhoeven @ 2017-04-28 16:13 UTC (permalink / raw)
To: Frank Rowand
Cc: Rob Herring, stephen.boyd, Michal Marek,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kbuild
In-Reply-To: <59035E93.2060106@gmail.com>
Hi Frank,
On Fri, Apr 28, 2017 at 5:24 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 04/28/17 04:25, Geert Uytterhoeven wrote:
>> On Wed, Apr 26, 2017 at 2:09 AM, <frowand.list@gmail.com> wrote:
>>> create mode 100644 drivers/of/unittest-data/overlay.dts
>>> create mode 100644 drivers/of/unittest-data/overlay_bad_phandle.dts
>>> create mode 100644 drivers/of/unittest-data/overlay_base.dts
>>
>> Shouldn't these be called .dtso instead of .dts?
>
> That is a good question. I'm not worried about solving it this week for
> this patch, because this could turn into a bikeshed and I can always
> fix it with a patch if we decide to change. But if we do want to change
> the naming, I would like to make the decision in the next couple of
> months. I would like to see more progress on overlays in general
> this summer, and plan to be working on them myself.
>
> I _think_ there has been some discussion about source file naming on the
> devicetree-compiler or devicetree list in the far distant past. Or I
> may just be mis-remembering.
>
> As far as I know, the current dtc does not know any suffixes other than
> .dts for source files. Not that the compiler has to know, we can always
> specify '-I dts'.
That's not an obstacle, though. I've been compiling .dtso files into .dtbo
files for several years, cfr.
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/renesas-overlays
According to "make V=1", the kernel build system basically uses
./scripts/dtc/dtc -O dtb -o <file>.dtbo <file>.dtbo.dts.tmp
with <file>.dtbo.dts.tmp the preprocessed .dtso files.
And dtc copes fine with that.
>>> --- a/drivers/of/unittest-data/Makefile
>>> +++ b/drivers/of/unittest-data/Makefile
>>
>>> +# enable creation of __symbols__ node
>>> +DTC_FLAGS_overlay := -@
>>> +DTC_FLAGS_overlay_bad_phandle := -@
>>> +DTC_FLAGS_overlay_base := -@
>>
>> This flag is needed for all DTs that will be involved with overlays.
>>
>> Hence what about enabling this globally instead, cfr. "Enable DT symbols when"
>> CONFIG_OF_OVERLAY is used
>> ("http://www.spinics.net/lists/devicetree/msg103363.html")?
>
> And another really good question.
>
> There are some issues. I have thought about it enough to know there are issues,
> but do not have a solution and do not think I know all the issues. Some
> possible issues (or perceived issues) are:
>
> - The size of __symbols__ in an FDT (akd compile .dtb image) in either a kernel
> image or a bootloader if overlays are not actually needed on a given system
> (even if the system is physically capable of using overlays).
What do you mean with "physically capable of using overlays"?
The presence of expansion connectors, like Raspberry Pi and BeagleBone Black?
Even lacking such connectors, an overlay could add hardware description that
was just missing (forgotten, or lack of DT bindings) when the main DTB was
built.
I agree about the size, but you never know in advance if an overlay will
be used or needed later.
> - The size of __symbols__ in kernel memory if overlays are not actually needed
> on a given system (even if the system is physically capable of using overlays.)
> This could be possibly be enabled/disabled by a boot command, even if
> __symbols__ is in the FDT.
Agreed. Not allowing overlays is akin to not allowing to load (more) kernel
modules, and may increase security.
> - A base FDT might want to have __symbols__ included with the expectation that
> overlays will be used in the future. (The FDT might be built for the boot
> loader, then be stable for many kernel releases.)
>
> - Should the creation of __symbols__ be a global switch, or should it be
> controlled on a per dtb basis? Or a combination of both?
So you want to decouple OF overlay support in the Linux kernel from
__symbols__ present in the DTBs built?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] of: fix uninitialized variable warning for overlay test
From: Frank Rowand @ 2017-04-28 15:46 UTC (permalink / raw)
To: Arnd Bergmann, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170428094429.2396195-1-arnd-r2nGTMty4D4@public.gmane.org>
On 04/28/17 02:44, Arnd Bergmann wrote:
> gcc warns that an empty device tree would cause undefined behavior:
>
> drivers/of/unittest.c: In function 'of_unittest':
> drivers/of/unittest.c:2199:25: warning: 'last_sibling' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> This adds an initialization of the variable to zero, which we handle
> correctly.
>
> Fixes: 81d0848fc8d2 ("of: Add unit tests for applying overlays")
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> ---
> drivers/of/unittest.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 12597ff8cfb0..6b8f3e6aa43c 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -2192,7 +2192,7 @@ static __init void of_unittest_overlay_high_level(void)
>
> mutex_lock(&of_mutex);
>
> - for (np = of_root->child; np; np = np->sibling)
> + for (last_sibling = np = of_root->child; np; np = np->sibling)
> last_sibling = np;
>
> if (last_sibling)
>
Thanks Arnd! Linux-next also reported this and I sent Rob a different
patch for it yesterday.
Rob, I am fine with either Arnd's patch or mine, they both fix the
problem.
-Frank
--
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 2/2] of: fix unittest build without CONFIG_OF_OVERLAY
From: Frank Rowand @ 2017-04-28 15:40 UTC (permalink / raw)
To: Arnd Bergmann, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170428094429.2396195-2-arnd-r2nGTMty4D4@public.gmane.org>
On 04/28/17 02:44, Arnd Bergmann wrote:
> We get a link error when the new tests are used by overlays
> are not:
>
> drivers/of/built-in.o: In function `unflatten_device_tree':
> (.init.text+0x967): undefined reference to `unittest_unflatten_overlay_base'
>
> This makes the #ifdef check match the symbols that lead to building
> the unittest_unflatten_overlay_base function.
>
> Fixes: 81d0848fc8d2 ("of: Add unit tests for applying overlays")
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> ---
> drivers/of/of_private.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
> index de5c604f5cc4..4ebb0149d118 100644
> --- a/drivers/of/of_private.h
> +++ b/drivers/of/of_private.h
> @@ -55,7 +55,7 @@ static inline int of_property_notify(int action, struct device_node *np,
> }
> #endif /* CONFIG_OF_DYNAMIC */
>
> -#ifdef CONFIG_OF_UNITTEST
> +#if defined(CONFIG_OF_UNITTEST) && defined(CONFIG_OF_OVERLAY)
> extern void __init unittest_unflatten_overlay_base(void);
> #else
> static inline void unittest_unflatten_overlay_base(void) {};
>
I thought I had tested that OF_UNITTEST forced OF_OVERLAY. But
going back and trying again, I can confirm your results that it
does not. Thanks for catching this!
Reviewed-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
Tested-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
-Frank
--
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] ARM: dts: r7s72100: add usb clocks to device tree
From: Simon Horman @ 2017-04-28 15:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Chris Brandt, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <CAMuHMdXp75yepEMh-S0YNYqKRESb4m3DtcfG09x=uj1Fm51b_A@mail.gmail.com>
On Fri, Apr 28, 2017 at 04:27:45PM +0200, Geert Uytterhoeven wrote:
> Hi Chris,
>
> On Fri, Apr 28, 2017 at 2:47 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> > On Friday, April 28, 2017, Simon Horman wrote:
> >> On Fri, Apr 28, 2017 at 09:34:54AM +0200, Geert Uytterhoeven wrote:
> >> > On Thu, Apr 27, 2017 at 9:10 PM, Chris Brandt <chris.brandt@renesas.com>
> >> wrote:
> >> > > This adds the USB0 and USB1 clocks to the device tree.
>
> >> > Simon: see Section 29.3.2 (BUSWAIT) for the reference to the P1 clock.
> >>
> >> Thanks, I see that now.
> >
> > I was going to say that I simply look at sections:
> > 6.10.6 Internal Clock Signals (1)
> > 6.10.7 Internal Clock Signals (2)
> >
> > Because it lists all the IP blocks and their corresponding clock sources in one place.
>
> Cool, I grew up with rev. 0.60 of the user manual, so I wasn't aware of
> that secton.
Thanks, now I'm not looking at 0.60 any more I see the sections Chris
mentions too.
^ permalink raw reply
* Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Andy Shevchenko @ 2017-04-28 15:37 UTC (permalink / raw)
To: Chris Brandt
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: <SG2PR06MB11658E6434EB343246ADC9F58A130@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Fri, Apr 28, 2017 at 6:16 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Friday, April 28, 2017, Andy Shevchenko wrote:
>> Had you read the following, esp. Note there?
>>
>> * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does
>> not
>> * affect the pin's ability to drive output. 1 enables input, 0
>> disables
>> * input.
>>
>> For me manual is clearly tells about this settings:
>> "This register enables or disables the input buffer while the output
>> buffer is enabled."
>
>
> But, then if we use "input-enable" to get bi-directional functionality,
It seems you are missing the point from electrical prospective.
Standard pin buffers (electrically) means input buffer and output
buffer that are driven independently in most cases.
Here is one example:
https://electronics.stackexchange.com/questions/96932/internal-circuitry-of-io-ports-in-mcu/96953#96953
(That's what I asked before as a schematic)
> now we need something to replace what we were using "input-enable" for.
No.
> 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.
> So, if we replace "bi-directional" with "input-enable" (since logically internally that is what is going on), what do we use for the special pins that the HW manual says "hey, you need to manually set these pins to input with SW because the pin selection HW can't do it correctly)".
Yes.
BiDi is an alias to output + input enable + other pin configuration
parameters (a set depends on real HW needs).
> 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.
P.S. It looks like more and more software engineers are going far from
real hardware when developing drivers...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 2/2] of: Add unit tests for applying overlays
From: Frank Rowand @ 2017-04-28 15:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, stephen.boyd-QSEj5FYQhm4dnm+yROfE0A, Michal Marek,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kbuild
In-Reply-To: <CAMuHMdWLhLqjNgz6iUOY8LY1Jjn3-_iV2ncbOxYLCLZbf=Rz+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 04/28/17 04:25, Geert Uytterhoeven wrote:
> Hi Frank,
>
> On Wed, Apr 26, 2017 at 2:09 AM, <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>>
>> Existing overlay unit tests examine individual pieces of the overlay
>> code. The new tests target the entire process of applying an overlay.
>>
>> Signed-off-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>> ---
>>
>> There are checkpatch warnings. I have reviewed them and feel they
>> can be ignored.
>>
>> drivers/of/fdt.c | 14 +-
>> drivers/of/of_private.h | 12 +
>> drivers/of/unittest-data/Makefile | 17 +-
>> drivers/of/unittest-data/overlay.dts | 53 ++++
>> drivers/of/unittest-data/overlay_bad_phandle.dts | 20 ++
>> drivers/of/unittest-data/overlay_base.dts | 80 ++++++
>> drivers/of/unittest.c | 317 +++++++++++++++++++++++
>> 7 files changed, 505 insertions(+), 8 deletions(-)
>>
>> create mode 100644 drivers/of/unittest-data/overlay.dts
>> create mode 100644 drivers/of/unittest-data/overlay_bad_phandle.dts
>> create mode 100644 drivers/of/unittest-data/overlay_base.dts
>
> Shouldn't these be called .dtso instead of .dts?
That is a good question. I'm not worried about solving it this week for
this patch, because this could turn into a bikeshed and I can always
fix it with a patch if we decide to change. But if we do want to change
the naming, I would like to make the decision in the next couple of
months. I would like to see more progress on overlays in general
this summer, and plan to be working on them myself.
I _think_ there has been some discussion about source file naming on the
devicetree-compiler or devicetree list in the far distant past. Or I
may just be mis-remembering.
As far as I know, the current dtc does not know any suffixes other than
.dts for source files. Not that the compiler has to know, we can always
specify '-I dts'.
>
>> --- a/drivers/of/unittest-data/Makefile
>> +++ b/drivers/of/unittest-data/Makefile
>
>> +# enable creation of __symbols__ node
>> +DTC_FLAGS_overlay := -@
>> +DTC_FLAGS_overlay_bad_phandle := -@
>> +DTC_FLAGS_overlay_base := -@
>
> This flag is needed for all DTs that will be involved with overlays.
>
> Hence what about enabling this globally instead, cfr. "Enable DT symbols when"
> CONFIG_OF_OVERLAY is used
> ("http://www.spinics.net/lists/devicetree/msg103363.html")?
And another really good question.
There are some issues. I have thought about it enough to know there are issues,
but do not have a solution and do not think I know all the issues. Some
possible issues (or perceived issues) are:
- The size of __symbols__ in an FDT (akd compile .dtb image) in either a kernel
image or a bootloader if overlays are not actually needed on a given system
(even if the system is physically capable of using overlays).
- The size of __symbols__ in kernel memory if overlays are not actually needed
on a given system (even if the system is physically capable of using overlays.)
This could be possibly be enabled/disabled by a boot command, even if
__symbols__ is in the FDT.
- A base FDT might want to have __symbols__ included with the expectation that
overlays will be used in the future. (The FDT might be built for the boot
loader, then be stable for many kernel releases.)
- Should the creation of __symbols__ be a global switch, or should it be
controlled on a per dtb basis? Or a combination of both?
Again, I'm not worried about an immediate, this week solution, but I would
like to make good progress on this in the next couple of months.
-Frank
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
--
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 linux v9 2/5] hwmon: occ: Add sysfs interface
From: Eddie James @ 2017-04-28 15:22 UTC (permalink / raw)
To: Guenter Roeck
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, jdelvare,
corbet, mark.rutland, robh+dt, wsa, andrew, benh, joel,
Edward A. James
In-Reply-To: <818c5a81-1791-aa0d-a3fe-e0976041cdc9@roeck-us.net>
On 04/02/2017 06:19 AM, Guenter Roeck wrote:
> On 03/14/2017 01:55 PM, Eddie James wrote:
>> From: "Edward A. James" <eajames@us.ibm.com>
>>
>> Add a generic mechanism to expose the sensors provided by the OCC in
>> sysfs.
>>
>> Signed-off-by: Edward A. James <eajames@us.ibm.com>
>> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>> ---
>> Documentation/hwmon/occ | 62 +++++++++++
>> drivers/hwmon/occ/Makefile | 2 +-
>> drivers/hwmon/occ/occ_sysfs.c | 253
>> ++++++++++++++++++++++++++++++++++++++++++
>> drivers/hwmon/occ/occ_sysfs.h | 25 +++++
>> 4 files changed, 341 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/hwmon/occ/occ_sysfs.c
>> create mode 100644 drivers/hwmon/occ/occ_sysfs.h
>>
>> diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
>> index d1c863b..580af26 100644
>> --- a/Documentation/hwmon/occ
>> +++ b/Documentation/hwmon/occ
>> @@ -27,6 +27,68 @@ Currently, all versions of the OCC support four
>> types of sensor data: power,
>> temperature, frequency, and "caps," which indicate limits and
>> thresholds used
>> internally on the OCC.
>>
>> +sysfs Entries
>> +-------------
>> +
>> +The OCC driver uses the hwmon sysfs framework to provide data to
>> userspace.
>> +
>> +The driver exports a number of sysfs files for each type of sensor. The
>> +sensor-specific files vary depending on the processor type, though
>> many of the
>> +attributes are common for both the POWER8 and POWER9.
>> +
>> +The hwmon interface cannot define every type of sensor that may be
>> used.
>> +Therefore, the frequency sensor on the OCC uses the "input" type
>> sensor defined
>> +by the hwmon interface, rather than defining a new type of custom
>> sensor.
>> +
>> +Below are detailed the names and meaning of each sensor file for
>> both types of
>> +processors. All sensors are read-only unless otherwise specified.
>> <x> indicates
>> +the hwmon index. sensor id indicates the unique internal OCC
>> identifer. Please
>> +see the POWER OCC specification for details on all these sensor values.
>> +
>> +frequency:
>> + all processors:
>> + in<x>_input - frequency value
>> + in<x>_label - sensor id
>> +temperature:
>> + POWER8:
>> + temp<x>_input - temperature value
>> + temp<x>_label - sensor id
>> + POWER9 (in addition to above):
>> + temp<x>_type - FRU type
>> +
>> +power:
>> + POWER8:
>> + power<x>_input - power value
>> + power<x>_label - sensor id
>> + power<x>_average - accumulator
>> + power<x>_average_interval - update tag (number of samples in
>> + accumulator)
>> + POWER9:
>> + power<x>_input - power value
>> + power<x>_label - sensor id
>> + power<x>_average_min - accumulator[0]
>> + power<x>_average_max - accumulator[1] (64 bits total)
>> + power<x>_average_interval - update tag
>> + power<x>_reset_history - (function_id | (apss_channel << 8)
>> +
>> +caps:
>> + POWER8:
>> + power<x>_cap - current powercap
>> + power<x>_cap_max - max powercap
>> + power<x>_cap_min - min powercap
>> + power<x>_max - normal powercap
>> + power<x>_alarm - user powercap, r/w
>> + POWER9:
>> + power<x>_cap_alarm - user powercap source
>> +
>> +The driver also provides two sysfs entries through hwmon to better
>> +control the driver and monitor the master OCC. Though there may be
>> multiple
>> +OCCs present on the system, these two files are only present for the
>> "master"
>> +OCC.
>> + name - read the name of the driver
>> + update_interval - read or write the minimum interval for polling
>> the
>> + OCC.
>> +
>> BMC - Host Communications
>> -------------------------
>>
>> diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
>> index 3ed79a5..67b5367 100644
>> --- a/drivers/hwmon/occ/Makefile
>> +++ b/drivers/hwmon/occ/Makefile
>> @@ -1 +1 @@
>> -obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o
>> +obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o
>> diff --git a/drivers/hwmon/occ/occ_sysfs.c
>> b/drivers/hwmon/occ/occ_sysfs.c
>> new file mode 100644
>> index 0000000..50b20e2
>> --- /dev/null
>> +++ b/drivers/hwmon/occ/occ_sysfs.c
>> @@ -0,0 +1,253 @@
>> +/*
>> + * occ_sysfs.c - OCC sysfs interface
>> + *
>> + * This file contains the methods and data structures for
>> implementing the OCC
>> + * hwmon sysfs entries.
>> + *
>> + * Copyright 2017 IBM Corp.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/hwmon-sysfs.h>
>> +#include <linux/init.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/slab.h>
>> +#include "occ.h"
>> +#include "occ_sysfs.h"
>> +
>> +#define OCC_HWMON_NAME_LENGTH 32
>> +
>> +struct occ_sysfs {
>> + struct device *dev;
>> + struct occ *occ;
>> +
>> + char label_buffer[OCC_HWMON_NAME_LENGTH + 1];
>> + char hwmon_name[OCC_HWMON_NAME_LENGTH + 1];
>> + const u32 *sensor_hwmon_configs;
>> + struct hwmon_channel_info **occ_sensors;
>> + struct hwmon_chip_info occ_info;
>> + u16 user_powercap;
>> +};
>> +
>> +static int occ_hwmon_read(struct device *dev, enum
>> hwmon_sensor_types type,
>> + u32 attr, int channel, long *val)
>> +{
>> + int rc;
>> + struct occ_sysfs *driver = dev_get_drvdata(dev);
>> + struct occ *occ = driver->occ;
>> +
>> + switch (type) {
>> + case hwmon_in:
>> + rc = occ_get_sensor_field(occ, FREQ, channel, attr, val);
>> + break;
>> + case hwmon_temp:
>> + rc = occ_get_sensor_field(occ, TEMP, channel, attr, val);
>> + break;
>> + case hwmon_power:
>> + rc = occ_get_sensor_field(occ, POWER, channel, attr, val);
>> + break;
>> + default:
>> + rc = -EOPNOTSUPP;
>> + }
>> +
>> + return rc;
>> +}
>> +
>> +static int occ_hwmon_read_string(struct device *dev,
>> + enum hwmon_sensor_types type, u32 attr,
>> + int channel, const char **str)
>> +{
>> + int rc;
>> + unsigned long val = 0;
>> + struct occ_sysfs *driver = dev_get_drvdata(dev);
>> +
>> + if (!((type == hwmon_in && attr == hwmon_in_label) ||
>> + (type == hwmon_temp && attr == hwmon_temp_label) ||
>> + (type == hwmon_power && attr == hwmon_power_label)))
>> + return -EOPNOTSUPP;
>> +
>> + /* will fetch the "label", the sensor_id */
>> + rc = occ_hwmon_read(dev, type, attr, channel, &val);
>> + if (rc < 0)
>> + return rc;
>> +
>> + /* just use one label buffer for all sensors. works with current
>> hwmon
>> + * implementation. only alternative is to store a buffer for each
>> + * sensor, which gets expensive quickly.
>> + */
>
> Sorry for the late reply.
>
> No, this doesn't work and is racy. Reading all labels from multiple
> threads
> in parallel will result in random data.
>
> The label is supposed to be constant for each sensor. If it isn't, it
> is not
> a label. Either create it as constant and use the generated string, or
> drop
> the attribute.
>
> Guenter
Thanks for catching that. The driver is undergoing some significant
restructuring as a result of changes in design to the low-level driver
for the P9 side of things (actually doing the communication with the
OCC). Depending on how extensive the changes are (haven't had time to
finalize), this patchset could be abandoned and I'll start again.
Thanks for the feedback so far.
Eddie
^ permalink raw reply
* RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Chris Brandt @ 2017-04-28 15:16 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: <CAHp75VeLtOuty=iaxuCaH43rnBZDTT03iH7JyjDJBQhTD-EjzA@mail.gmail.com>
On Friday, April 28, 2017, Andy Shevchenko wrote:
> Had you read the following, esp. Note there?
>
> * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does
> not
> * affect the pin's ability to drive output. 1 enables input, 0
> disables
> * input.
>
> For me manual is clearly tells about this settings:
> "This register enables or disables the input buffer while the output
> buffer is enabled."
But, then if we use "input-enable" to get bi-directional functionality, now we need something to replace what we were using "input-enable" for.
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).
So, if we replace "bi-directional" with "input-enable" (since logically internally that is what is going on), what do we use for the special pins that the HW manual says "hey, you need to manually set these pins to input with SW because the pin selection HW can't do it correctly)". 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"
Chris
^ permalink raw reply
* RE: [PATCH v8 1/3] backlight arcxcnn add arc to vendor prefix
From: Olimpiu Dejeu @ 2017-04-28 15:04 UTC (permalink / raw)
To: 'Jingoo Han'
Cc: 'Rob Herring', 'Lee Jones',
'Geert Uytterhoeven', linux-kernel-u79uwXL29TY76Z2rM5mHXA,
'Linux Fbdev development list',
devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Dodge,
'Joe Perches', 'Daniel Thompson'
In-Reply-To: <001301d2bf7d$919d2d60$b4d78820$@gmail.com>
> On Thursday, April 27, 2017 8:37 AM, Geert Uytterhoeven wrote:
> > On Tue, Apr 25, 2017 at 6:36 PM, Jingoo Han <jingoohan1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On Monday, April 24, 2017 1:56 PM, Olimpiu Dejeu wrote:
> > >>
> > >> On Mon, April 24, 2017 11:10 AM, Rob Herring < robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > >>
> > >> > On Wed, Mar 15, 2017 at 2:45 PM, Olimpiu Dejeu
> > <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> > >> wrote:
> > >> >> backlight: Add arc to vendor prefixes
> > >> >> Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> > >> >> ---
> > >> >> v8:
> > >> >> - Version to match other patches in set
> > >> >>
> > >> >> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> > >> >> 1 file changed, 1 insertion(+)
> > >> >>
> > >> >> diff --git
> > >> >> a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > >> >> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > >> >> index 16d3b5e..6f33a4b 100644
> > >> >> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > >> >> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > >> >> @@ -28,6 +28,7 @@ andestech Andes Technology Corporation
> > >> >> apm Applied Micro Circuits Corporation (APM)
> > >> >> aptina Aptina Imaging
> > >> >> arasan Arasan Chip Systems
> > >> >> +arc Arctic Sand
> > >>
> > >> >arc is also a cpu arch. While not a vendor, it could be confusing.
> > >> >How
> > >> about "arctic" >instead?
> > >>
> > >> Rob, will do, i.e. I will change it to "arctic"
> > >
> > > Hi Olimpiu,
> > >
> > > Oh, "arc" and "arctic" is totally different.
> > > In my opinion, one of the purposes of DT is to describe hardware stuffs.
> > > So, please use more detailed words.
> >
> > Already acquired by Murata?
> Yes, Murata already announced the agreement of acquisition. [1]
> To Olimpiu Dejeu,
> What is your company's plan about naming?
> The brand name 'Artic Sand' will be continued or not?
The brand name 'Arctic Sand' will be continued
> If not, you should replace 'Artic Sand' with 'Murata'.
> As you said earlier, changing DT names is not easy after merging.
> Best regards,
> Jingoo Han
--
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] clk: stm32h7: Add stm32h743 clock driver
From: Gabriel Fernandez @ 2017-04-28 14:56 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, Lee Jones,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
ludovic.barre, olivier.bideau, amelie.delaunay
In-Reply-To: <20170407195152.GH7065@codeaurora.org>
Hi Stephen
Sorry for delay i was on sick live
On 04/07/2017 09:51 PM, Stephen Boyd wrote:
> On 04/06, Gabriel Fernandez wrote:
>> On 04/06/2017 12:32 AM, Stephen Boyd wrote:
>>> On 03/15, gabriel.fernandez@st.com wrote:
>>>> diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>>>> new file mode 100644
>>>> index 0000000..9d4b587
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>>>> @@ -0,0 +1,152 @@
>>>> +
>>>> + rcc: rcc@58024400 {
>>>> + #reset-cells = <1>;
>>>> + #clock-cells = <2>
>>>> + compatible = "st,stm32h743-rcc", "st,stm32-rcc";
>>>> + reg = <0x58024400 0x400>;
>>>> + clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
>>>> +
>>>> + st,syscfg = <&pwrcfg>;
>>>> +
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + vco1@58024430 {
>>>> + #clock-cells = <0>;
>>>> + compatible = "stm32,pll";
>>>> + reg = <0>;
>>> reg is super confusing and doesn't match unit address.
>> ok i fixed it in the v2
>>
>>>> + };
>>> Why? Shouldn't we know this from the compatible string how many
>>> PLLs there are and where they're located? Export the PLLs through
>>> rcc node's clock-cells?
>>>
>> Because i need to offer the possibility to change the PLL VCO
>> frequencies at the start-up of this driver clock.
>> The VCO algorithm needs a division factor, a multiplication factor
>> and a fractional factor.
>> Lot's of solution are possible for one frequency and it's nightmare
>> to satisfy the 3 output dividers of the PLL.
> Sure, but do we need to configure that on a per-board basis or a
> per-SoC basis? If it's just some configuration, I wonder why we
> don't put that into the driver and base it off some compatible
> string that includes the SoC the device is for.
>
I prefer to let in first, the responsibility of the boot loader to
change VCO parameters.
Then i propose a new version without DT configuration of PLL's
are you ok for that ?
best regards
Gabriel
To simply
^ permalink raw reply
* RE: [PATCH v2] clk: Provide dummy of_clk_get_from_provider() for compile-testing
From: Langer, Thomas @ 2017-04-28 14:55 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Russell King,
Rob Herring, Mark Rutland, John Crispin, Ralf Baechle
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
In-Reply-To: <1493384933-31297-1-git-send-email-geert+renesas@glider.be>
> -----Original Message-----
> From: devicetree-owner@vger.kernel.org [mailto:devicetree-
> owner@vger.kernel.org] On Behalf Of Geert Uytterhoeven
> Sent: Friday, April 28, 2017 3:09 PM
> To: Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> <sboyd@codeaurora.org>; Russell King <linux@armlinux.org.uk>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; John Crispin
> <john@phrozen.org>; Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-clk@vger.kernel.org; devicetree@vger.kernel.org; linux-
> mips@linux-mips.org; linux-kernel@vger.kernel.org; Geert Uytterhoeven
> <geert+renesas@glider.be>
> Subject: [PATCH v2] clk: Provide dummy of_clk_get_from_provider() for
> compile-testing
>
> When CONFIG_ON=n, dummies are provided for of_clk_get() and
> of_clk_get_by_name(), but not for of_clk_get_from_provider().
>
> Provide a dummy for the latter, to improve the ability to do
> compile-testing. This requires removing the existing dummy in the
> Lantiq clock code.
>
> Fixes: 766e6a4ec602d0c1 ("clk: add DT clock binding support")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Regarding the Lantiq part:
Acked-by: Thomas Langer <thomas.langer@intel.com>
> ---
> v2:
> - Remove conflicting dummy in Lantiq clock code (reported by 0day).
> ---
> arch/mips/lantiq/clk.c | 5 -----
> include/linux/clk.h | 4 ++++
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/lantiq/clk.c b/arch/mips/lantiq/clk.c
> index 149f0513c4f5d0d4..a263d1b751ffe48d 100644
> --- a/arch/mips/lantiq/clk.c
> +++ b/arch/mips/lantiq/clk.c
> @@ -160,11 +160,6 @@ void clk_deactivate(struct clk *clk)
> }
> EXPORT_SYMBOL(clk_deactivate);
>
> -struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
> -{
> - return NULL;
> -}
> -
> static inline u32 get_counter_resolution(void)
> {
> u32 res;
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index e9d36b3e49de5b1b..3ed97abb5cbb7f94 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -539,6 +539,10 @@ static inline struct clk *of_clk_get_by_name(struct
> device_node *np,
> {
> return ERR_PTR(-ENOENT);
> }
> +static inline struct clk *of_clk_get_from_provider(struct of_phandle_args
> *clkspec)
> +{
> + return ERR_PTR(-ENOENT);
> +}
> #endif
>
> #endif
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Andy Shevchenko @ 2017-04-28 14:53 UTC (permalink / raw)
To: Chris Brandt
Cc: Linus Walleij, Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart,
Rob Herring, Mark Rutland, Russell King - ARM Linux,
Linux-Renesas, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <SG2PR06MB11658EC3A3A80C57E6F539AC8A130-ESzmfEwOt/xoAsOJh7vwSm0DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Fri, Apr 28, 2017 at 4:18 PM, Chris Brandt <Chris.Brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> On Friday, April 28, 2017, Andy Shevchenko wrote:
>> > In the RZ/A1 HW manual you can kind of see that in 54.18 Port Control
>> Logical Diagram (but that wasn't obvious to me at first).
>>
>> Please, post a link to it or copy essential parts.
> The schematic is included in the "User's manual"
> https://www.renesas.com/en-us/doc/products/tool/doc/003/r20ut2596ej_r7s72100evum.pdf
Not that one I would like to see...
> The RZ/A1H Hardware manual is here:
> https://www.renesas.com/en-us/document/hw-manual?hwLayerShowFlg=true&prdLayerId=186374&layerName=RZ%252FA1H&coronrService=document-prd-search&hwDocUrl=%2Fen-us%2Fdoc%2Fproducts%2Fmpumcu%2Fdoc%2Frz%2Fr01uh0403ej0300_rz_a1h.pdf&hashKey=54f335753742b5add524d4725b7242e6
>
> Chapter 54 is the port/pin controller.
>
> "54.18 Port Control Logical Diagram" is the diagram I was talking about. Note that is says "Note: This figure shows the logic for reference, not the circuit."
>
> "54.3.13 Port Bidirection Control Register (PBDCn)" is the magic register needed to get some pins to work.
This is useful. Thanks.
>> I'm quite skeptical that cheap hardware can implement something more
>> costable than simplest open-source / open-drain + bias
>
> I don't think this is an open-source / open-drain + bias issue. It's a "the internal signal paths are not getting hooked up correctly" issue.
Had you read the following, esp. Note there?
* @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does not
* affect the pin's ability to drive output. 1 enables input, 0 disables
* input.
For me manual is clearly tells about this settings:
"This register enables or disables the input buffer while the output
buffer is enabled."
> Regardless, on this part, we needed a way to flag that some pins when put in some function modes needed 'an extra register setting'. At first we tried to sneak that info in with a simple #define in the pin/pinmux DT node properties. But, Linus didn't want it there so we had to make up a new generic property called "bi-directional".
>
> What is your end goal here? Get "bi-directional" changed to something else?
My goal is to reduce amount of (useless) entities. See Occam's razor
for details.
Linus, for me it looks like better to revert that change, until we
will have clear picture why existing configuration parameters can't
work.
--
With Best Regards,
Andy Shevchenko
--
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 v5 10/10] arm: dts: genmai: Add ethernet pin group
From: Chris Brandt @ 2017-04-28 14:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdU2CvipQQQ8-wxsiniHZJQmUMHv-t52Pw=sHD3YTd7Yug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
On Friday, April 28, 2017, Geert Uytterhoeven wrote:
> >> Shouldn't the interrupt (connected to P1_15) be described?
> >
> > That interrupt pin from the PHY is not used. It did not need to be
> connected.
>
> But it is connected, according to the schematics.
P1_15 can be configured as:
* GPIO_IN
* AN7
* AVB_CAPTURE
So...I guess you would 'describe' it as an GPIO-input.
> DT describes hardware, not software limitations.
Describing things is fine, but the kernel code takes the DT and then start configuring things based on it.
For example, on the RSK board, that line is connected to P4_14. P4_14 can be configured as IRQ6...but IRQ6 comes out in 8 different pin choices, and I might want to use one of those other choices, so I don't want to describe P4_14 as an interrupt.
If it was just describing that "pin 15 of the PHY chip is tied to pin Y19 of the RZ/A1H", that's fine because it's hardware connection that's not going to change.
But...the DT also defines the pin muxing...which is a software decision (do I want to get interrupt or just manually poll or simple ignore it).
This is the part of the whole "DT is for hardware description only" that doesn't really make sense to me.
Chris
^ permalink raw reply
* Re: [PATCH] ARM: dts: r7s72100: add usb clocks to device tree
From: Geert Uytterhoeven @ 2017-04-28 14:27 UTC (permalink / raw)
To: Chris Brandt
Cc: Simon Horman, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <SG2PR06MB1165D398BD7100FAC5AAEDC68A130-ESzmfEwOt/xoAsOJh7vwSm0DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Chris,
On Fri, Apr 28, 2017 at 2:47 PM, Chris Brandt <Chris.Brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> On Friday, April 28, 2017, Simon Horman wrote:
>> On Fri, Apr 28, 2017 at 09:34:54AM +0200, Geert Uytterhoeven wrote:
>> > On Thu, Apr 27, 2017 at 9:10 PM, Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>> wrote:
>> > > This adds the USB0 and USB1 clocks to the device tree.
>> > Simon: see Section 29.3.2 (BUSWAIT) for the reference to the P1 clock.
>>
>> Thanks, I see that now.
>
> I was going to say that I simply look at sections:
> 6.10.6 Internal Clock Signals (1)
> 6.10.7 Internal Clock Signals (2)
>
> Because it lists all the IP blocks and their corresponding clock sources in one place.
Cool, I grew up with rev. 0.60 of the user manual, so I wasn't aware of
that secton.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/8] [RFC] dt-bindings: renesas: Document R-Car H3 and M3-W SiP DT bindings
From: Geert Uytterhoeven @ 2017-04-28 14:23 UTC (permalink / raw)
To: Rob Herring
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170428133923.ycbqixcxvcsonocn@rob-hp-laptop>
Hi Rob,
On Fri, Apr 28, 2017 at 3:39 PM, Rob Herring <robh@kernel.org> wrote:
> On Wed, Apr 19, 2017 at 11:15:44AM +0200, Geert Uytterhoeven wrote:
>> Document the SiP ("System-in-Package") versions of the R-Car H3 and M3-W
>> SoCs, which contain an R-Car H3 or M3-W SoC, RAM, and HyperFlash.
>>
>> Add their compatible values to all boards equipped with R-Car Gen3 SiPs.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> Questions:
>> - Do we need more compatible values, for different configurations?
>> At least r8j7796 is available with either 2 GiB or 4 GiB of RAM,
>> possibly using RAM parts from different vendors.
>
> Same die, just a different package? If so, I don't think you need a
> different compatible. It's going to be a different board from any
> non-SiP which should be enough to distinguish.
An SiP is more like a CPU daughterboard.
The different SiP-versions based on r8a7795 contain the same r8a7795 SoC die,
but different amounts of RAM, i.e. different RAM dies.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 2/2] [media] platform: add video-multiplexer subdevice driver
From: Philipp Zabel @ 2017-04-28 14:13 UTC (permalink / raw)
To: linux-media
Cc: devicetree, Steve Longerbeam, Peter Rosin, Sakari Ailus,
Pavel Machek, Rob Herring, Mark Rutland, Vladimir Zapolskiy,
kernel, Philipp Zabel, Sascha Hauer, Steve Longerbeam
In-Reply-To: <20170428141330.16187-1-p.zabel@pengutronix.de>
This driver can handle SoC internal and external video bus multiplexers,
controlled by mux controllers provided by the mux controller framework,
such as MMIO register bitfields or GPIOs. The subdevice passes through
the mbus configuration of the active input to the output side.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
This has been last sent as part of the i.MX media series.
Changes since https://patchwork.kernel.org/patch/9647869/:
- Split out the actual mux operation to be provided by the mux controller
framework [1]. GPIO and MMIO control can be provided by individual mux
controller drivers [2][3].
[1] https://patchwork.kernel.org/patch/9695837/
[2] https://patchwork.kernel.org/patch/9695839/
[3] https://patchwork.kernel.org/patch/9704509/
- Shortened 'video-multiplexer' to 'video-mux', replaced all instances of
vidsw with video_mux.
- Made the mux inactive by default, only activated by user interaction.
- Added CONFIG_OF and CONFIG_MULTIPLEXER dependencies.
- Reuse subdev.entity.num_pads instead of keeping our own count.
- Removed implicit link disabling. Instead, trying to enable a second
sink pad link yields -EBUSY.
- Merged _async_init into _probe.
- Removed superfluous pad index check from _set_format.
- Added is_source_pad helper to tell source and sink pads apart.
- Removed test for status property in endpoint nodes. Disable the remote
device or sever the endpoint link to disable a sink pad.
---
drivers/media/platform/Kconfig | 6 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/video-mux.c | 341 +++++++++++++++++++++++++++++++++++++
3 files changed, 349 insertions(+)
create mode 100644 drivers/media/platform/video-mux.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c9106e105baba..b046a6d39fee5 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
To compile this driver as a module, choose M here: the
module will be called arv.
+config VIDEO_MUX
+ tristate "Video Multiplexer"
+ depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && MULTIPLEXER
+ help
+ This driver provides support for N:1 video bus multiplexers.
+
config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 349ddf6a69da2..fd2735ca3ff75 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o
+obj-$(CONFIG_VIDEO_MUX) += video-mux.o
+
obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
new file mode 100644
index 0000000000000..419541729f67e
--- /dev/null
+++ b/drivers/media/platform/video-mux.c
@@ -0,0 +1,341 @@
+/*
+ * video stream multiplexer controlled via mux control
+ *
+ * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
+ * Copyright (C) 2016 Pengutronix, Philipp Zabel <kernel@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/mux/consumer.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+#include <media/v4l2-async.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-subdev.h>
+#include <media/v4l2-of.h>
+
+struct video_mux {
+ struct v4l2_subdev subdev;
+ struct media_pad *pads;
+ struct v4l2_mbus_framefmt *format_mbus;
+ struct v4l2_of_endpoint *endpoint;
+ struct mux_control *mux;
+ int active;
+};
+
+static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct video_mux, subdev);
+}
+
+static inline bool is_source_pad(struct video_mux *vmux, unsigned int pad)
+{
+ return pad == vmux->subdev.entity.num_pads - 1;
+}
+
+static int video_mux_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ int ret;
+
+ /*
+ * The mux state is determined by the enabled sink pad link.
+ * Enabling or disabling the source pad link has no effect.
+ */
+ if (is_source_pad(vmux, local->index))
+ return 0;
+
+ dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]",
+ remote->entity->name, remote->index, local->entity->name,
+ local->index, flags & MEDIA_LNK_FL_ENABLED);
+
+ if (flags & MEDIA_LNK_FL_ENABLED) {
+ if (vmux->active == local->index)
+ return 0;
+
+ if (vmux->active >= 0)
+ return -EBUSY;
+
+ dev_dbg(sd->dev, "setting %d active\n", local->index);
+ ret = mux_control_try_select(vmux->mux, local->index);
+ if (ret < 0)
+ return ret;
+ vmux->active = local->index;
+ } else {
+ if (vmux->active != local->index)
+ return 0;
+
+ dev_dbg(sd->dev, "going inactive\n");
+ mux_control_deselect(vmux->mux);
+ vmux->active = -1;
+ }
+
+ return 0;
+}
+
+static struct media_entity_operations video_mux_ops = {
+ .link_setup = video_mux_link_setup,
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static bool video_mux_endpoint_disabled(struct device_node *ep)
+{
+ struct device_node *rpp = of_graph_get_remote_port_parent(ep);
+
+ return !of_device_is_available(rpp);
+}
+
+static int video_mux_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ struct v4l2_of_endpoint *endpoint;
+ struct media_pad *pad;
+ int ret;
+
+ if (vmux->active == -1) {
+ dev_err(sd->dev, "no configuration for inactive mux\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Retrieve media bus configuration from the entity connected to the
+ * active input
+ */
+ pad = media_entity_remote_pad(&vmux->pads[vmux->active]);
+ if (pad) {
+ sd = media_entity_to_v4l2_subdev(pad->entity);
+ ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
+ if (ret == -ENOIOCTLCMD)
+ pad = NULL;
+ else if (ret < 0) {
+ dev_err(sd->dev, "failed to get source configuration\n");
+ return ret;
+ }
+ }
+ if (!pad) {
+ endpoint = &vmux->endpoint[vmux->active];
+
+ /* Mirror the input side on the output side */
+ cfg->type = endpoint->bus_type;
+ if (cfg->type == V4L2_MBUS_PARALLEL ||
+ cfg->type == V4L2_MBUS_BT656)
+ cfg->flags = endpoint->bus.parallel.flags;
+ }
+
+ return 0;
+}
+
+static int video_mux_s_stream(struct v4l2_subdev *sd, int enable)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ struct v4l2_subdev *upstream_sd;
+ struct media_pad *pad;
+
+ if (vmux->active == -1) {
+ dev_err(sd->dev, "Can not start streaming on inactive mux\n");
+ return -EINVAL;
+ }
+
+ pad = media_entity_remote_pad(&sd->entity.pads[vmux->active]);
+ if (!pad) {
+ dev_err(sd->dev, "Failed to find remote source pad\n");
+ return -ENOLINK;
+ }
+
+ if (!is_media_entity_v4l2_subdev(pad->entity)) {
+ dev_err(sd->dev, "Upstream entity is not a v4l2 subdev\n");
+ return -ENODEV;
+ }
+
+ upstream_sd = media_entity_to_v4l2_subdev(pad->entity);
+
+ return v4l2_subdev_call(upstream_sd, video, s_stream, enable);
+}
+
+static const struct v4l2_subdev_video_ops video_mux_subdev_video_ops = {
+ .g_mbus_config = video_mux_g_mbus_config,
+ .s_stream = video_mux_s_stream,
+};
+
+static struct v4l2_mbus_framefmt *
+__video_mux_get_pad_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ unsigned int pad, u32 which)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+
+ switch (which) {
+ case V4L2_SUBDEV_FORMAT_TRY:
+ return v4l2_subdev_get_try_format(sd, cfg, pad);
+ case V4L2_SUBDEV_FORMAT_ACTIVE:
+ return &vmux->format_mbus[pad];
+ default:
+ return NULL;
+ }
+}
+
+static int video_mux_get_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ sdformat->format = *__video_mux_get_pad_format(sd, cfg, sdformat->pad,
+ sdformat->which);
+ return 0;
+}
+
+static int video_mux_set_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ struct v4l2_mbus_framefmt *mbusformat;
+
+ mbusformat = __video_mux_get_pad_format(sd, cfg, sdformat->pad,
+ sdformat->which);
+ if (!mbusformat)
+ return -EINVAL;
+
+ /* Source pad mirrors active sink pad, no limitations on sink pads */
+ if (is_source_pad(vmux, sdformat->pad) && vmux->active >= 0)
+ sdformat->format = vmux->format_mbus[vmux->active];
+
+ *mbusformat = sdformat->format;
+
+ return 0;
+}
+
+static struct v4l2_subdev_pad_ops video_mux_pad_ops = {
+ .get_fmt = video_mux_get_format,
+ .set_fmt = video_mux_set_format,
+};
+
+static struct v4l2_subdev_ops video_mux_subdev_ops = {
+ .pad = &video_mux_pad_ops,
+ .video = &video_mux_subdev_video_ops,
+};
+
+static int video_mux_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct v4l2_of_endpoint endpoint;
+ struct device_node *ep;
+ struct video_mux *vmux;
+ unsigned int num_pads = 0;
+ int ret;
+ int i;
+
+ vmux = devm_kzalloc(dev, sizeof(*vmux), GFP_KERNEL);
+ if (!vmux)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, vmux);
+
+ v4l2_subdev_init(&vmux->subdev, &video_mux_subdev_ops);
+ snprintf(vmux->subdev.name, sizeof(vmux->subdev.name), "%s", np->name);
+ vmux->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ vmux->subdev.dev = dev;
+
+ /*
+ * The largest numbered port is the output port. It determines
+ * total number of pads.
+ */
+ for_each_endpoint_of_node(np, ep) {
+ of_graph_parse_endpoint(ep, &endpoint.base);
+ num_pads = max(num_pads, endpoint.base.port + 1);
+ }
+
+ if (num_pads < 2) {
+ dev_err(dev, "Not enough ports %d\n", num_pads);
+ return -EINVAL;
+ }
+
+ vmux->mux = devm_mux_control_get(dev, NULL);
+ if (IS_ERR(vmux->mux)) {
+ ret = PTR_ERR(vmux->mux);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get mux: %d\n", ret);
+ return ret;
+ }
+
+ vmux->active = -1;
+ vmux->pads = devm_kzalloc(dev, sizeof(*vmux->pads) * num_pads,
+ GFP_KERNEL);
+ vmux->format_mbus = devm_kzalloc(dev, sizeof(*vmux->format_mbus) *
+ num_pads, GFP_KERNEL);
+ vmux->endpoint = devm_kzalloc(dev, sizeof(*vmux->endpoint) *
+ (num_pads - 1), GFP_KERNEL);
+
+ for (i = 0; i < num_pads - 1; i++)
+ vmux->pads[i].flags = MEDIA_PAD_FL_SINK;
+ vmux->pads[num_pads - 1].flags = MEDIA_PAD_FL_SOURCE;
+
+ vmux->subdev.entity.function = MEDIA_ENT_F_VID_MUX;
+ ret = media_entity_pads_init(&vmux->subdev.entity, num_pads,
+ vmux->pads);
+ if (ret < 0)
+ return ret;
+
+ vmux->subdev.entity.ops = &video_mux_ops;
+
+ for_each_endpoint_of_node(np, ep) {
+ v4l2_of_parse_endpoint(ep, &endpoint);
+
+ if (video_mux_endpoint_disabled(ep)) {
+ dev_dbg(dev, "port %d disabled\n", endpoint.base.port);
+ continue;
+ }
+
+ vmux->endpoint[endpoint.base.port] = endpoint;
+ }
+
+ return v4l2_async_register_subdev(&vmux->subdev);
+}
+
+static int video_mux_remove(struct platform_device *pdev)
+{
+ struct video_mux *vmux = platform_get_drvdata(pdev);
+ struct v4l2_subdev *sd = &vmux->subdev;
+
+ v4l2_async_unregister_subdev(sd);
+ media_entity_cleanup(&sd->entity);
+
+ return 0;
+}
+
+static const struct of_device_id video_mux_dt_ids[] = {
+ { .compatible = "video-mux", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, video_mux_dt_ids);
+
+static struct platform_driver video_mux_driver = {
+ .probe = video_mux_probe,
+ .remove = video_mux_remove,
+ .driver = {
+ .of_match_table = video_mux_dt_ids,
+ .name = "video-mux",
+ },
+};
+
+module_platform_driver(video_mux_driver);
+
+MODULE_DESCRIPTION("video stream multiplexer");
+MODULE_AUTHOR("Sascha Hauer, Pengutronix");
+MODULE_AUTHOR("Philipp Zabel, Pengutronix");
+MODULE_LICENSE("GPL");
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox