* Re: [PATCH v7 1/2] dt-bindings: Add GPCv2 power gating driver
From: Andrey Smirnov @ 2017-03-27 18:42 UTC (permalink / raw)
To: Dong Aisheng
Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring,
Fabio Estevam, Andrey Yurovsky, Shawn Guo, linux-arm-kernel,
Lucas Stach
In-Reply-To: <20170324063216.GC12604@b29396-OptiPlex-7040>
On Thu, Mar 23, 2017 at 11:32 PM, Dong Aisheng <dongas86@gmail.com> wrote:
> On Tue, Mar 21, 2017 at 07:50:03AM -0700, Andrey Smirnov wrote:
>> Add DT bindings for power domain driver for GPCv2 IP block found in
>> i.MX7 SoCs.
>>
>> Cc: yurovsky@gmail.com
>> Cc: Lucas Stach <l.stach@pengutronix.de>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Dong Aisheng <dongas86@gmail.com>
>> Cc: devicetree@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>> ---
>> .../devicetree/bindings/power/fsl,imx-gpcv2.txt | 71 ++++++++++++++++++++++
>> include/dt-bindings/power/imx7-power.h | 18 ++++++
>> 2 files changed, 89 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> create mode 100644 include/dt-bindings/power/imx7-power.h
>>
>> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> new file mode 100644
>> index 0000000..02f45c6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> @@ -0,0 +1,71 @@
>> +Freescale i.MX General Power Controller v2
>> +==========================================
>> +
>> +The i.MX7S/D General Power Control (GPC) block contains Power Gating
>> +Control (PGC) for various power domains.
>> +
>> +Required properties:
>> +
>> +- compatible: Should be "fsl,imx7d-gpc"
>> +
>> +- reg: should be register base and length as documented in the
>> + datasheet
>> +
>> +- interrupts: Should contain GPC interrupt request 1
>> +
>> +Power domains contained within GPC node are generic power domain
>> +providers, documented in
>> +Documentation/devicetree/bindings/power/power_domain.txt, which are
>> +described as subnodes of the power gating controller 'pgc' node,
>> +which, in turn, is expected to contain the following:
>> +
>> +Required properties:
>> +
>> +- reg: Power domain index. Valid values are defined in
>> + include/dt-bindings/power/imx7-power.h
>> +
>> +- #power-domain-cells: Should be 0
>> +
>> +Optional properties:
>> +
>> +- power-supply: Power supply used to power the domain
>> +
>> +Example:
>> +
>> + gpc: gpc@303a0000 {
>> + compatible = "fsl,imx7d-gpc";
>> + reg = <0x303a0000 0x1000>;
>> + interrupt-controller;
>> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
>> + #interrupt-cells = <3>;
>> + interrupt-parent = <&intc>;
>> +
>> + pgc {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + pgc_pcie_phy: power-domain@3 {
>> + #power-domain-cells = <0>;
>> +
>> + reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
>> + power-supply = <®_1p0d>;
>> + };
>> + };
>> + };
>> +
>> +
>> +Specifying power domain for IP modules
>> +======================================
>> +
>> +IP cores belonging to a power domain should contain a 'power-domains'
>> +property that is a phandle for PGC node representing the domain.
>> +
>> +Example of a device that is part of the PCIE_PHY power domain:
>> +
>> + pcie: pcie@33800000 {
>> + reg = <0x33800000 0x4000>,
>> + <0x4ff00000 0x80000>;
>> + /* ... */
>> + power-domains = <&pgc_pcie_phy>;
>> + /* ... */
>> + };
>> diff --git a/include/dt-bindings/power/imx7-power.h b/include/dt-bindings/power/imx7-power.h
>> new file mode 100644
>> index 0000000..eb70023
>> --- /dev/null
>> +++ b/include/dt-bindings/power/imx7-power.h
>> @@ -0,0 +1,18 @@
>> +/*
>> + * Copyright (C) 2017 Impinj
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef __DT_BINDINGS_IMX7_POWER_H__
>> +#define __DT_BINDINGS_IMX7_POWER_H__
>> +
>> +#define IMX7_POWER_DOMAIN_USB_HSIC_PHY 0
>> +#define IMX7_POWER_DOMAIN_USB_OTG2_PHY 1
>> +#define IMX7_POWER_DOMAIN_USB_OTG1_PHY 2
>> +#define IMX7_POWER_DOMAIN_PCIE_PHY 3
>> +#define IMX7_POWER_DOMAIN_MIPI_PHY 4
>
> Nitpick: Probably better to define according to the reference manual
> defined order.
>
> 0x800 ~ 0x83F : PGC for A7 core0
> 0x840 ~ 0x87F: PGC for A7 core1
> 0x880 ~ 0x8BF: PGC for A7 SCU
> 0xA00 ~ 0xA3F: PGC for fastmix/megamix
> 0xC00 ~ 0xC3F: PGC for MIPI PHY
> 0xC40 ~ 0xC7F: PGC for PCIE_PHY
> 0xC80 ~ 0xCBF: Reserved
> 0xCC0 ~ 0xCFF: Reserved
> 0xD00 ~ 0xD3F: PGC for USB HSIC PHY
>
> You can drop A7 core/scu/fastmix/megamix as well.
>
Sure, will do.
Thanks,
Andrey Smirnov
^ permalink raw reply
* Re: [PATCH v2 1/2] soc: qcom: Add device tree binding for GLINK RPM
From: Rob Herring @ 2017-03-27 18:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Mark Rutland, Ohad Ben-Cohen, linux-arm-msm,
open list:ARM/QUALCOMM SUPPORT, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
In-Reply-To: <20170326043159.GA70446@Bjorns-MacBook-Pro-2.local>
On Sat, Mar 25, 2017 at 11:31 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Fri 24 Mar 09:07 PDT 2017, Rob Herring wrote:
>
>> On Mon, Mar 20, 2017 at 02:09:55PM -0700, Bjorn Andersson wrote:
>> > Add device tree binding documentation for the Qualcomm GLINK RPM, used
>> > for communication with the Resource Power Management subsystem in
>> > various Qualcomm SoCs.
>> >
>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> > ---
>> >
>> > Changes since v1:
>> > - None
>> >
>> > .../devicetree/bindings/soc/qcom/qcom,glink.txt | 73 ++++++++++++++++++++++
>> > 1 file changed, 73 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> > new file mode 100644
>> > index 000000000000..da92c4f787f3
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> > @@ -0,0 +1,73 @@
>> > +Qualcomm RPM GLINK binding
>> > +
>> > +This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
>> > +communication with the Resource Power Management system on various Qualcomm
>> > +platforms.
>> > +
>> > +- compatible:
>> > + Usage: required
>> > + Value type: <stringlist>
>> > + Definition: must be "qcom,glink-rpm"
>>
>> SoC specific compatibles please.
>>
>
> In addition to the generic qcom,glink-rpm I presume?
Right.
>
>> > +
>> > +- interrupts:
>> > + Usage: required
>> > + Value type: <prop-encoded-array>
>> > + Definition: should specify the IRQ used by the remote processor to
>> > + signal this processor about communication related events
>> > +
>> > +- qcom,rpm-msg-ram:
>> > + Usage: required
>> > + Value type: <prop-encoded-array>
>> > + Definition: handle to RPM message memory resource
>> > +
>> > +- qcom,ipc:
>> > + Usage: required
>> > + Value type: <prop-encoded-array>
>> > + Definition: three entries specifying the outgoing ipc bit used for
>> > + signaling the remote processor:
>> > + - phandle to a syscon node representing the apcs registers
>> > + - u32 representing offset to the register within the syscon
>> > + - u32 representing the ipc bit within the register
>> > +
>> > += GLINK DEVICES
>> > +Each subnode of the GLINK node represent function tied to a virtual
>> > +communication channel. The name of the nodes are not important. The properties
>> > +of these nodes are defined by the individual bindings for the specific function
>> > +- but must contain the following property:
>> > +
>> > +- qcom,glink-channels:
>> > + Usage: required
>> > + Value type: <stringlist>
>> > + Definition: a list of channels tied to this function, used for matching
>> > + the function to a set of virtual channels
>> > +
>> > += EXAMPLE
>> > +The following example represents the GLINK RPM node on a MSM8996 device, with
>> > +the function for the "rpm_request" channel defined, which is used for
>> > +regualtors and root clocks.
>> > +
>> > + apcs: syscon@f9011000 {
>> > + compatible = "syscon";
>>
>> syscon alone is not valid.
>>
>
> This is equivalent to how we have done this on all previous platforms.
Then they are wrong...
> On previous platforms this generally maps to one of the "Krait Processor
> SubSystem" blocks, so I'm quite worried with coming up with a compatible
> for this block will not be compatible with any future description of
> this block.
Perhaps why we should get rid of syscon. It's not supposed to be a "I
don't know how to define a binding, so just make all registers
available for now".
I don't really see how a compatible string alone would create problems
to extend the binding if you need to later. Even if it did, you can
always rev compatible strings.
>> > + reg = <0xf9011000 0x1000>;
>> > + };
>> > +
>> > + rpm_msg_ram: memory@68000 {
>> > + compatible = "qcom,rpm-msg-ram";
>>
>> Is this more than just mmio-sram?
>>
>> Or with a fixed use could be part of another node?
>>
>
> It represents one of the RAM modules of one of the other ARM cores in
> the SoC, used for shared memory communication with this ARM core. So the
> hardware is essentially mmio-sram. But it has none of the properties
> that a mmio-sram seem to have.
Properties such as?
>
> The reason I did not put it in the rpm-glink node is that in previous
> Qualcomm platforms we have exactly the same system design, but the data
> structure of the RAM was different, so it felt natural to just keep the
> same description of the hardware.
>
>> > + reg = <0x68000 0x6000>;
>> > + };
>> > +
>> > + rpm-glink {
>> > + compatible = "qcom,glink-rpm";
>> > +
>> > + interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
>> > +
>> > + qcom,rpm-msg-ram = <&rpm_msg_ram>;
>> > + qcom,ipc = <&apcs 0x10 0>;
>> > +
>> > + rpm-requests {
>> > + compatible = "qcom,rpm-msm8996";
>> > + qcom,glink-channels = "rpm_requests";
>> > +
>> > + ...
>> > + };
>> > + };
>
> Regards,
> Bjorn
^ permalink raw reply
* Re: [PATCH v2] ASoC: Add support for Maxim Integrated MAX98927 Amplifier
From: Rob Herring @ 2017-03-27 18:46 UTC (permalink / raw)
To: Ryan Lee
Cc: Mark Rutland, Linux-ALSA, Kuninori Morimoto, Liam Girdwood,
Takashi Iwai, Srinivas Kandagatla, romain.perier, bardliao,
Lars-Peter Clausen, Axel Lin, Paul Handrigan,
devicetree@vger.kernel.org, Arnd Bergmann, nh6z, Mark Brown,
Charles Keepax, Dylan Reid, oder_chiou, KCHSU0,
linux-kernel@vger.kernel.org, Petr Kulhavy
In-Reply-To: <1490592778-30841-1-git-send-email-ryans.lee@maximintegrated.com>
On Mon, Mar 27, 2017 at 12:32 AM, Ryan Lee
<ryans.lee@maximintegrated.com> wrote:
> Signed-off-by: Ryan Lee <ryans.lee@maximintegrated.com>
> ---
> v2: Removed local register read/write function to avoid duplication of ASoC core function.
And what about my comments in v1?
^ permalink raw reply
* Re: [PATCH 1/5 v2] iio: xoadc: augment DT bindings a bit
From: Rob Herring @ 2017-03-27 18:51 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170327075854.7390-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Mar 27, 2017 at 2:58 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> In order to accommodate in a logical manner for the premuxed channels
> in PM8921 and the similarly addressed channels in later PMICs, we
> need a twocell arrangement with premux and analog mux setting as
> a tuple to uniquely identify a hardware channel.
>
> These bindings are not yet in use, so it should be fine to augment
> them before we actually start using it in drivers and device trees.
>
> This scheme came out of lengthy discussions and reverse-engineering
> and reading of the few information sources we have.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Suggested-by: Björn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> ChangeLog v1->v2:
> - Name nodes with <01 02> in a foo@0102 pattern.
> - Minor spelling nits.
> - Delete flimsy leftover docs from an interrim development path.
Okay for the 2 cells.
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 104 +++++++++++----------
> 1 file changed, 56 insertions(+), 48 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> index 53cd146d8096..ade545487ce6 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> @@ -19,32 +19,42 @@ Required properties:
> with PMIC variant but is typically something like 2.2 or 1.8V.
>
> The following required properties are standard for IO channels, see
> -iio-bindings.txt for more details:
> +iio-bindings.txt for more details, but noitice that this particular
> +ADC has a special adressing scheme that require two cells for
> +identifying each ADC channel:
>
> -- #address-cells: should be set to <1>
> +- #address-cells: should be set to <2>, the first cell is the
> + prescaler (on PM8058) or premux (on PM8921) with two valid bits
> + so legal values are 0x00, 0x01 or 0x02. The second cell
> + is the main analog mux setting (0x00..0x0f). The combination
> + of prescaler/premux and analog mux uniquely addresses a hardware
> + channel on all systems.
>
> - #size-cells: should be set to <0>
>
> -- #io-channel-cells: should be set to <1>
> +- #io-channel-cells: should be set to <2>, again the cells are
> + precaler or premux followed by the analog muxing line.
>
> - interrupts: should refer to the parent PMIC interrupt controller
> and reference the proper ADC interrupt.
>
> Required subnodes:
>
> -The ADC channels are configured as subnodes of the ADC. Since some of
> -them are used for calibrating the ADC, these nodes are compulsory:
> +The ADC channels are configured as subnodes of the ADC.
>
> -adc-channel@c {
> - reg = <0x0c>;
> +Since some of them are used for calibrating the ADC, these nodes are
> +compulsory:
> +
> +adc-channel@000c {
Leading 0s on unit addresses is wrong.
> + reg = <0x00 0x0c>;
> };
>
> -adc-channel@d {
> - reg = <0x0d>;
> +adc-channel@000d {
> + reg = <0x00 0x0d>;
> };
>
> -adc-channel@f {
> - reg = <0x0f>;
> +adc-channel@000f {
> + reg = <0x00 0x0f>;
> };
>
> These three nodes are used for absolute and ratiometric calibration
> @@ -52,13 +62,13 @@ and only need to have these reg values: they are by hardware definition
> 1:1 ratio converters that sample 625, 1250 and 0 milliV and create
> an interpolation calibration for all other ADCs.
>
> -Optional subnodes: any channels other than channel 0x0c, 0x0d and
> -0x0f are optional.
> +Optional subnodes: any channels other than channels [0x00 0x0c],
> +[0x00 0x0d] and [0x00 0x0f] are optional.
>
> Required channel node properties:
>
> - reg: should contain the hardware channel number in the range
> - 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
> + 0 .. 0xff (8 bits).
>
> Optional channel node properties:
>
> @@ -94,56 +104,54 @@ Example:
> xoadc: xoadc@197 {
> compatible = "qcom,pm8058-adc";
> reg = <0x197>;
> - interrupt-parent = <&pm8058>;
> - interrupts = <76 1>;
> - #address-cells = <1>;
> + interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <2>;
> #size-cells = <0>;
> - #io-channel-cells = <1>;
> + #io-channel-cells = <2>;
>
> - vcoin: adc-channel@0 {
> - reg = <0x00>;
> + vcoin: adc-channel@0000 {
> + reg = <0x00 0x00>;
> };
> - vbat: adc-channel@1 {
> - reg = <0x01>;
> + vbat: adc-channel@0001 {
> + reg = <0x00 0x01>;
> };
> - dcin: adc-channel@2 {
> - reg = <0x02>;
> + dcin: adc-channel@0002 {
> + reg = <0x00 0x02>;
> };
> - ichg: adc-channel@3 {
> - reg = <0x03>;
> + ichg: adc-channel@0030 {
> + reg = <0x00 0x03>;
> };
> - vph_pwr: adc-channel@4 {
> - reg = <0x04>;
> + vph_pwr: adc-channel@0004 {
> + reg = <0x00 0x04>;
> };
> - usb_vbus: adc-channel@a {
> - reg = <0x0a>;
> + usb_vbus: adc-channel@000a {
> + reg = <0x00 0x0a>;
> };
> - die_temp: adc-channel@b {
> - reg = <0x0b>;
> + die_temp: adc-channel@000b {
> + reg = <0x00 0x0b>;
> };
> - ref_625mv: adc-channel@c {
> - reg = <0x0c>;
> + ref_625mv: adc-channel@000c {
> + reg = <0x00 0x0c>;
> };
> - ref_1250mv: adc-channel@d {
> - reg = <0x0d>;
> + ref_1250mv: adc-channel@000d {
> + reg = <0x00 0x0d>;
> };
> - ref_325mv: adc-channel@e {
> - reg = <0x0e>;
> + ref_325mv: adc-channel@000e {
> + reg = <0x00 0x0e>;
> };
> - ref_muxoff: adc-channel@f {
> - reg = <0x0f>;
> + ref_muxoff: adc-channel@000f {
> + reg = <0x00 0x0f>;
> };
> };
>
> -
> /* IIO client node */
> iio-hwmon {
> compatible = "iio-hwmon";
> - io-channels = <&xoadc 0x01>, /* Battery */
> - <&xoadc 0x02>, /* DC in (charger) */
> - <&xoadc 0x04>, /* VPH the main system voltage */
> - <&xoadc 0x0b>, /* Die temperature */
> - <&xoadc 0x0c>, /* Reference voltage 1.25V */
> - <&xoadc 0x0d>, /* Reference voltage 0.625V */
> - <&xoadc 0x0e>; /* Reference voltage 0.325V */
> + io-channels = <&xoadc 0x00 0x01>, /* Battery */
> + <&xoadc 0x00 0x02>, /* DC in (charger) */
> + <&xoadc 0x00 0x04>, /* VPH the main system voltage */
> + <&xoadc 0x00 0x0b>, /* Die temperature */
> + <&xoadc 0x00 0x0c>, /* Reference voltage 1.25V */
> + <&xoadc 0x00 0x0d>, /* Reference voltage 0.625V */
> + <&xoadc 0x00 0x0e>; /* Reference voltage 0.325V */
> };
> --
> 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
^ permalink raw reply
* Re: [PATCH 2/3] firmware: qcom: scm: Expose download-mode control
From: Rob Herring @ 2017-03-27 18:53 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Stephen Boyd, Mark Rutland, David Brown,
Srinivas Kandagatla, linux-kernel@vger.kernel.org, linux-arm-msm,
open list:ARM/QUALCOMM SUPPORT, devicetree@vger.kernel.org
In-Reply-To: <20170326051328.GD70446@Bjorns-MacBook-Pro-2.local>
On Sun, Mar 26, 2017 at 12:13 AM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Fri 24 Mar 08:06 PDT 2017, Rob Herring wrote:
>
>> On Fri, Mar 17, 2017 at 09:15:22PM -0700, Bjorn Andersson wrote:
> [..]
>> > diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
>> > index 20f26fbce875..8467a181f22c 100644
>> > --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
>> > +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
>> > @@ -18,6 +18,7 @@ Required properties:
>> > * Core, iface, and bus clocks required for "qcom,scm"
>> > - clock-names: Must contain "core" for the core clock, "iface" for the interface
>> > clock and "bus" for the bus clock per the requirements of the compatible.
>> > +- qcom,dload-mode-addr: Specifies the address for the download mode magic (optional)
>>
>> Size? 1 cell, 2 cell(, red cell, blue cell) or follows #addr-cells?
>>
>
> I believe this implementation only applies to the 64-bit systems, but
> it's probably better to make it follow (or at least claim that it
> follows) #address-cells.
Saying it is fixed 2 cells is fine and slightly easier to parse. Just
be explicit.
Rob
^ permalink raw reply
* Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver
From: Rob Herring @ 2017-03-27 19:04 UTC (permalink / raw)
To: Gabriel Fernandez
Cc: Mark Rutland, devicetree@vger.kernel.org, Daniel Thompson,
Radosław Pietrzyk, Alexandre Torgue, Arnd Bergmann,
Nicolas Pitre, Andrea Merello, Michael Turquette, Olivier Bideau,
Stephen Boyd, Russell King, linux-kernel@vger.kernel.org,
Ludovic Barre, Maxime Coquelin, Amelie Delaunay, Lee Jones,
linux-clk, linux-arm-kernel@lists.infradead.org
In-Reply-To: <dce20025-9f42-e747-e325-e1667504e615@st.com>
On Fri, Mar 24, 2017 at 4:41 AM, Gabriel Fernandez
<gabriel.fernandez@st.com> wrote:
> Hi Rob,
>
> Thanks for reviewing
>
>
>
> On 03/24/2017 03:06 AM, Rob Herring wrote:
>>
>> On Wed, Mar 15, 2017 at 10:23:30AM +0100, gabriel.fernandez@st.com wrote:
>>>
>>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>>
>>> This patch enables clocks for STM32H743 boards.
>>>
>>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>>> ---
>>> .../devicetree/bindings/clock/st,stm32h7-rcc.txt | 152 ++
>>> drivers/clk/Makefile | 1 +
>>> drivers/clk/clk-stm32h7.c | 1586
>>> ++++++++++++++++++++
>>> include/dt-bindings/clock/stm32h7-clks.h | 165 ++
>>> include/dt-bindings/mfd/stm32h7-rcc.h | 138 ++
>>> 5 files changed, 2042 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>>> create mode 100644 drivers/clk/clk-stm32h7.c
>>> create mode 100644 include/dt-bindings/clock/stm32h7-clks.h
>>> create mode 100644 include/dt-bindings/mfd/stm32h7-rcc.h
>>>
>>> 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 @@
>>> +STMicroelectronics STM32H7 Reset and Clock Controller
>>> +=====================================================
>>> +
>>> +The RCC IP is both a reset and a clock controller.
>>> +
>>> +Please refer to clock-bindings.txt for common clock controller binding
>>> usage.
>>> +Please also refer to reset.txt for common reset controller binding
>>> usage.
>>> +
>>> +Required properties:
>>> +- compatible: Should be:
>>> + "st,stm32h743-rcc"
>>> +
>>> +- reg: should be register base and length as documented in the
>>> + datasheet
>>> +
>>> +- #reset-cells: 1, see below
>>> +
>>> +- #clock-cells : from common clock binding; shall be set to 1
>>> +
>>> +- clocks: External oscillator clock phandle
>>> + - high speed external clock signal (HSE)
>>> + - low speed external clock signal (LSE)
>>> + - external I2S clock (I2S_CKIN)
>>> +
>>> +- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup
>>> domain
>>> + write protection (RTC clock).
>>> +
>>> +- pll x node: Allow to register a pll with specific parameters.
>>> + Please see PLL section below.
>>> +
>>> +Example:
>>> +
>>> + 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>;
>>
>> The reg addr value and unit address don't match.
>
> ok il will change into
>
> vco1@0 {
> reg = <0>;
>
>
>>
>>> + };
>>> +
>>> + vco2@58024438 {
>>> + #clock-cells = <0>;
>>> + compatible = "stm32,pll";
>>> + reg = <1>;
>>> + st,clock-div = <2>;
>>> + st,clock-mult = <40>;
>>> + st,frac-status = <0>;
>>> + st,frac = <0>;
>>> + st,vcosel = <1>;
>>> + st,pllrge = <2>;
>>> + };
>>> + };
>>> +
>>> +
>>> +STM32H7 PLL
>>> +-----------
>>> +
>>> +The VCO of STM32 PLL could be reprensented like this:
>>> +
>>> + Vref --------- --------
>>> + ---->| / DIVM |---->| x DIVN | ------> VCO
>>> + --------- --------
>>> + ^
>>> + |
>>> + -------
>>> + | FRACN |
>>> + -------
>>> +
>>> +When the PLL is configured in integer mode:
>>> +- VCO = ( Vref / DIVM ) * DIVN
>>> +
>>> +When the PLL is configured in fractional mode:
>>> +- VCO = ( Vref / DIVM ) * ( DIVN + FRACN / 2^13)
>>> +
>>> +
>>> +Required properties for pll node:
>>> +- compatible: Should be:
>>> + "stm32,pll"
>>
>> Only 1 single PLL design for all STM32 chips ever?
>
> no, i can change into "stm32h7,pll"
Actually, should be "st,stm32h7-pll".
>
>>> +
>>> +- #clock-cells: from common clock binding; shall be set to 0
>>> +- reg: Should be the pll number.
>>> +
>>> +Optional properties:
>>> +- st,clock-div: DIVM division factor : <1..63>
>>> +- st,clock-mult: DIVN multiplication factor : <4..512>
>>> +
>>> +- st,frac-status:
>>> + - 0 Pll is configured in integer mode
>>> + - 1 Pll is configure in fractional mode
>>
>> Isn't this implied by the presence of the next property?
>
> do you prefer this ?
>
> - st,frac :
> 0 : pll is configured in integer mode
> 1..8191 : Fractional part of the multiplication factor and pll is configured
> in fractional mode
Why not no st,frac property means integer mode?
Rob
^ permalink raw reply
* Re: [PATCH 3/9] Docs: dt: document qcom iommu bindings
From: Rob Herring @ 2017-03-27 19:10 UTC (permalink / raw)
To: Rob Clark
Cc: iommu@lists.linux-foundation.org, linux-arm-msm, Robin Murphy,
Will Deacon, Sricharan, Mark Rutland, Stanimir Varbanov,
devicetree@vger.kernel.org
In-Reply-To: <CAF6AEGsoWPhZ6x-uexGKKUJwtSsn2h+MSg1tjtBdtoPGmARAEg@mail.gmail.com>
On Thu, Mar 23, 2017 at 9:45 PM, Rob Clark <robdclark@gmail.com> wrote:
> On Thu, Mar 23, 2017 at 6:21 PM, Rob Herring <robh@kernel.org> wrote:
>> On Tue, Mar 14, 2017 at 11:18:05AM -0400, Rob Clark wrote:
>>> Cc: devicetree@vger.kernel.org
>>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>>> ---
>>> .../devicetree/bindings/iommu/qcom,iommu.txt | 113 +++++++++++++++++++++
>>> 1 file changed, 113 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
>>> new file mode 100644
>>> index 0000000..fd5b7fa
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
>>> @@ -0,0 +1,113 @@
>>> +* QCOM IOMMU v1 Implementation
>>> +
>>> +Qualcomm "B" family devices which are not compatible with arm-smmu have
>>> +a similar looking IOMMU but without access to the global register space,
>>> +and optionally requiring additional configuration to route context irqs
>>> +to non-secure vs secure interrupt line.
>>> +
>>> +** Required properties:
>>> +
>>> +- compatible : Should be one of:
>>> +
>>> + "qcom,msm8916-iommu"
>>> +
>>> +- clock-names : Should be a pair of "iface" (required for IOMMUs
>>> + register group access) and "bus" (required for
>>> + the IOMMUs underlying bus access).
>>> +- clocks : Phandles for respective clocks described by
>>> + clock-names.
>>> +- #address-cells : must be 1.
>>> +- #size-cells : must be 1.
>>> +- #iommu-cells : Must be 1.
>>> +- ranges : Base address and size of the iommu context banks.
>>> +- qcom,iommu-secure-id : secure-id.
>>> +
>>> +- List of sub-nodes, one per translation context bank. Each sub-node
>>> + has the following required properties:
>>> +
>>> + - compatible : Should be one of:
>>> + - "qcom,msm-iommu-v1-ns" : non-secure context bank
>>> + - "qcom,msm-iommu-v1-sec" : secure context bank
>>> + - reg : Base address and size of context bank within the iommu
>>> + - interrupts : The context fault irq.
>>> +
>>> +** Optional properties:
>>> +
>>> +- reg : Base address and size of the SMMU local base, should
>>> + be only specified if the iommu requires configuration
>>> + for routing of context bank irq's to secure vs non-
>>> + secure lines. (Ie. if the iommu contains secure
>>> + context banks)
>>> +
>>> +
>>> +** Examples:
>>> +
>>> + apps_iommu: iommu@1e20000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + #iommu-cells = <1>;
>>> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";
>>
>> You didn't document the fallback above. Maybe just drop it if only a few
>> chips have this iommu.
>
> not completely sure I understand what you want..
>
> I think more than a few chips.. I suspect it is more like everything
> after the last "a" family devices (snapdragon 600?) and before 820..
> (well, more or less at least a few years worth of devices, stuff that
> seems likely to be able to run an upstream kernel would be 800, 805,
> 808, 810.. and I guess there are some cut down 6xx and 4xx variants of
> those)
Okay, then you just need to list qcom,msm-iommu-v1 above. Something
like 'followed by "qcom,msm-iommu-v1"' at the end of the list of
compatibles.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: update device tree binding for Allwinner PRCM CCUs
From: icenowy-h8G6r0blFSE @ 2017-03-27 19:13 UTC (permalink / raw)
To: Maxime Ripard
Cc: Icenowy Zheng, Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai,
linux-kernel-owner-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170327134719.g6l3hzbba6cxkhb7@lukather>
在 2017-03-27 21:47，Maxime Ripard 写道：
> On Mon, Mar 27, 2017 at 05:11:29PM +0800, Icenowy Zheng wrote:
>>
>> 2017年3月26日 21:10于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
>> >
>> > On Thu, Mar 23, 2017 at 07:17:03AM +0800, Icenowy Zheng wrote:
>> > >
>> > >
>> > > 23.03.2017, 04:09, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
>> > > > On Wed, Mar 22, 2017 at 02:22:22AM +0800, Icenowy Zheng wrote:
>> > > >> 21.03.2017, 15:41, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> > > >> > On Thu, Mar 16, 2017 at 01:28:04AM +0800, Icenowy Zheng wrote:
>> > > >> >> Many Allwinner SoCs after A31 have a CCU in PRCM block.
>> > > >> >>
>> > > >> >> Give the ones on H3 and A64 compatible strings.
>> > > >> >>
>> > > >> >> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> > > >> >> ---
>> > > >> >> Changes in v2:
>> > > >> >> - Add iosc for R_CCU's on H3/A64. (A31, A23 and A33 seem to have different
>> > > >> >> clock for mux 3 of ar100 clk. Investgations are needed for them.)
>> > > >> >>
>> > > >> >> Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 18 +++++++++++++++++-
>> > > >> >> 1 file changed, 17 insertions(+), 1 deletion(-)
>> > > >> >>
>> > > >> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
>> > > >> >> index 68512aa398a9..4a4addff595d 100644
>> > > >> >> --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
>> > > >> >> +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
>> > > >> >> @@ -7,9 +7,11 @@ Required properties :
>> > > >> >> - "allwinner,sun8i-a23-ccu"
>> > > >> >> - "allwinner,sun8i-a33-ccu"
>> > > >> >> - "allwinner,sun8i-h3-ccu"
>> > > >> >> + - "allwinner,sun8i-h3-r-ccu"
>> > > >> >> - "allwinner,sun8i-v3s-ccu"
>> > > >> >> - "allwinner,sun9i-a80-ccu"
>> > > >> >> - "allwinner,sun50i-a64-ccu"
>> > > >> >> + - "allwinner,sun50i-a64-r-ccu"
>> > > >> >> - "allwinner,sun50i-h5-ccu"
>> > > >> >>
>> > > >> >> - reg: Must contain the registers base address and length
>> > > >> >> @@ -20,7 +22,11 @@ Required properties :
>> > > >> >> - #clock-cells : must contain 1
>> > > >> >> - #reset-cells : must contain 1
>> > > >> >>
>> > > >> >> -Example:
>> > > >> >> +For the PRCM CCUs on H3/A64, one more clock is needed:
>> > > >> >> +- "iosc": another frequency oscillator used for CPUS (usually at 32000Hz,
>> > > >> >> + not the same with losc)
>> > > >> >
>> > > >> > This is called the internal oscillator in the datasheet, it would
>> > > >> > probably make more sense to call it that way in the documentation too.
>> > > >> >
>> > > >> > This oscillator seems to be clocked at 16MHz, so we should represent
>> > > >> > it as such.
>> > > >> >
>> > > >> > And I'm wondering, are you *sure* that it's fed directly from the
>> > > >> > internal oscillator, or goes through the registers in the RTC, with
>> > > >> > the 32 divider and 16 prescaler by default that makes it at roughly
>> > > >> > the same rate (31.25kHz).
>> > > >>
>> > > >> In fact I know nothing about it -- I only represented the code in BSP
>> > > >> clock driver.
>> > > >>
>> > > >> The mux value 3 varies from SoC to SoC. For A64/H5 it's 32000,
>> > > >> for A33 it's 667000 (seems to be directly the internal OSC, as the
>> > > >> user manual says the internal OSC is 600~700kHz; but it's named
>> > > >> cpuosc rather than iosc in A33 BSP clock driver); for A80 it's even
>> > > >> PLL_AUDIO.
>> > > >
>> > > > Where are you getting those info from?
>> > > >
>> > > > As far as I know, the A33 PRCM takes the hosc, losc, pll6 and CPU
>> > > > (internal) oscillator:
>> > > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw5.c#L508
>> > > >
>> > > > The H3 takes the hosc and losc:
>> > > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c#L379
>> > > >
>> > > > The A80 takes the hosc and losc:
>> > > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun9iw1.c#L281
>> > > >
>> > > > The A64 takes the hosc, losc, pll-periph0 and the iosc, which indeed
>> > > > seems to be fed from the internal oscillator with the divider in the
>> > > > RTC:
>> > > > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/arch/arm64/boot/dts/sun50iw1p1-clk.dtsi#L19
>> > > > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L603
>> > >
>> > > But then in sunxi_init_clocks function, the iosc clock is initialized
>> > > as a fixed clock with 32000Hz.
>> > >
>> > > The clock node in BSP device tree have a compatible of
>> > > allwinner,fixed-clock, but not fixed-clock, which makes it not able
>> > > to be really probed.
>> >
>> > That clock is registered:
>> > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L1193
>> >
>>
>> Oh yes, but conflicts exist between the iosc registered in
>> clk-sun50iw1.c and described in sun50iw1p1-clk.dtsi . The former is
>> 32000, and the latter is 16000000.
>
> No, it is 16MHz / 32 / 16 = 31.25 kHz
>
>> What should we do then?
>>
>> (Maybe it will be better to temporarily ignore this mux, as it's
>> difficult to finally find out this correct mux...)
>
> That is not an option, we will not be able to fix it afterwards.
>
> What we should do is getting an actual idea of what's going on, and
> not just hacking something together hoping it will work.
>
> You can start by figuring out how the Allwinner clock driver actually
> works and / or by trying the various muxing options with something you
> can measure the frequency with. The i2c or uart coupled with a scope
> or logical analyzer would be a great fit for that.
>
> Using the PRCM timer is another option and you can measure the
> frequency it counts at.
The MUX 3 of AR100 is surely Internal OSC on A64/H3/H5.
Some measurement done with AR100 (all in Hz):
H5 (Orange Pi PC2):
16351952
16347120
16343624
A64 (Pine64+):
11192560
11174128
11174992
H3 (Orange Pi One):
15676016
15625088
15600144
H2+ (Orange Pi Zero):
15907560
15823768
15805144
Seems that on H3/H5 the IOSC is ~16MHz, but on A64 it's... ~12MHz?
(Although the usermanual says 16Mhz in the chapter of RTC)
Maybe some further investigations should be done on more boards.
A fork of ar100-info is at
https://github.com/Icenowy/ar100-info/tree/hz-test ,
which contains IOSC frequency calculation and show in Hz. (and of
course H5/A64 support)
>
> Maxime
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v4 0/4] gpio: mvebu: Add PWM fan support
From: Ralph Sennhauser @ 2017-03-27 19:42 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Imre Kaloz, Ralph Sennhauser, Alexandre Courbot, Rob Herring,
Mark Rutland, Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
Hi everyone
This patch series was originally submitted by Andrew Lunn but got
stalled. I picked up the series and addressed what was discussed for
the earlier submission with some helpful input from Andrew. Hopefully
this time support for the PWM fan as found on Linksys WRT1900AC (Mamba)
will make it in.
Implementing as an MFD was discarded due to backward compatibility. The
original discussion can be read at [1].
This series depends on two cleanup series. The first series [2] ("gpio:
mvebu: preparatory cleanup for pwm-fan support") is in linux
next-20170320. The second one [3] ("gpio: mvebu: use BIT macro instead
of bit shifting") is in linux-20170327.
Ralph
[1] https://patchwork.ozlabs.org/patch/427287/
[2] https://lkml.org/lkml/2017/3/16/62
[3] https://lkml.org/lkml/2017/3/17/493
---
Notes:
About npwm = 1:
The only way I can think of to achieve that requires reading the
GPIO line from the device tree. This would prevent a user to
dynamically choose a line. Which is fine for the fan found on Mamba
but let's take some development board with freely accessible GPIOs
and suddenly we limit the use of this driver. Given the above, npwm
= ngpio with only one usable at a time is a more accurate
description of the situation. The only downside is some "wasted"
space.
About the new compatible string:
Orion was chosen for the SoC variant for the same reason as in
commit 5f79c651e81e ("arm: mvebu: use global interrupts for GPIOs on
Armada XP"). I decided having the first two chips be
"marvell,armada-370-xp-gpio" and keep "marvell,orion-gpio" for the
third one for some SoCs just to be able to require the PWM property
for this compatible string. Therefore the properties remain
optional and if defined for any other than the first two chips it's
an error.
---
Pending:
* npwm = 1? I vote no if that counts. ;) (suggested by Thierry Reding)
* Tested-by: Andrew Lunn for v1 needs renewing
* Needs ACK from Thierry Reding to be merged via linux-gpio tree by Linus
Walleij. (fine with the general approach, requested changes which
should have been taken care of now)
---
Changes v3->v4:
Patch 1/4 gpio: mvebu: Add limited PWM support:
* braces for both branches in if statement if one needs it. (suggested
by Andrew Lunn)
* introduce compatible string marvell,armada-370-xp-gpio (suggest by
Thierry Reding)
* fix mvebu_pwmreg_blink_on_duration -> mvebu_pwmreg_blink_off_duration
for period callculation in mvebu_pwm_get_state()
Patch 4/4 mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
* Drop flags from pwms for Mamba, as no longer used (suggested by
Andrew Lunn)
* Use again #pwm-cell = 2, the second cell is actually the period.
Changes v2->v3:
Patch 1/4 gpio: mvebu: Add limited PWM support:
* drop pin from mvebu_pwn, can be infered (suggested by Thierry Reding)
* rename pwm to mvpwm so pwm can be used for pwm_device as in the API,
avoids some mental gymnastic.
* drop id from struct mvebu_gpio_chip, select blink counter in
mvebu_pwm_probe for all lines instead. We do not care about the
unused ones. I think a clear improvement in readability.
Makes coming up with a good comment simple as well.
* Switch to new atomic PWM API (suggested by Thierry Reding)
* rename use mvebu_gpioreg_blink_select to
mvebu_gpioreg_blink_counter_select.
* mark *_suspend() / *_resume() as __maybe_unused (suggested by Linus
Walleij)
* document #pwm-cells = 1 (suggested by Thierry Reding)
Patch 2/4 mvebu: xp: Add PWM properties to .dtsi files
* add missing reg-names / #pwm-cell properties to
armada-xp-mv78260.dtsi gpio1 node
* set pwm-cells = 1 (suggested by Thierry Reding)
All:
* always uppercase GPIO/PWM in prose (suggested by Thierry Reding)
Changes v1 -> v2:
Patch 1/4 gpio: mvebu: Add limited PWM support:
* use BIT macro (suggested by Linus Walleij)
* move id from struct mvebu_pwm to struct mvebu_gpio_chip, implement
blink select as if else and comment on the chip id for code clarity
(to accommodate Linus Walleijs request for a code clarification /
comment. If you can word it better I'm all ears.)
* Move function comment mvebu_pwm_probe into the function itself.
---
Andrew Lunn (4):
gpio: mvebu: Add limited PWM support
mvebu: xp: Add PWM properties to .dtsi files
ARM: mvebu: Enable SENSORS_PWM_FAN in defconfig
mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
.../devicetree/bindings/gpio/gpio-mvebu.txt | 32 ++
MAINTAINERS | 2 +
arch/arm/boot/dts/armada-370.dtsi | 16 +-
arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 8 +-
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 14 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 16 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 16 +-
arch/arm/configs/mvebu_v7_defconfig | 2 +
drivers/gpio/gpio-mvebu.c | 324 ++++++++++++++++++++-
9 files changed, 394 insertions(+), 36 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH v4 1/4] gpio: mvebu: Add limited PWM support
From: Ralph Sennhauser @ 2017-03-27 19:42 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Imre Kaloz, Andrew Lunn, Ralph Sennhauser, Alexandre Courbot,
Rob Herring, Mark Rutland, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170327194301.1104-1-ralph.sennhauser@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
Armada 370/XP devices can 'blink' GPIO lines with a configurable on
and off period. This can be modelled as a PWM.
However, there are only two sets of PWM configuration registers for
all the GPIO lines. This driver simply allows a single GPIO line per
GPIO chip of 32 lines to be used as a PWM. Attempts to use more return
EBUSY.
Due to the interleaving of registers it is not simple to separate the
PWM driver from the GPIO driver. Thus the GPIO driver has been
extended with a PWM driver.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
URL: https://patchwork.ozlabs.org/patch/427287/
URL: https://patchwork.ozlabs.org/patch/427295/
[Ralph Sennhauser:
* Port forward
* Merge PWM portion into gpio-mvebu.c
* Switch to atomic PWM API
* Add new compatible string marvell,armada-370-xp-gpio
* Update and merge documentation patch
* Update MAINTAINERS]
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
---
.../devicetree/bindings/gpio/gpio-mvebu.txt | 32 ++
MAINTAINERS | 2 +
drivers/gpio/gpio-mvebu.c | 324 ++++++++++++++++++++-
3 files changed, 346 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
index a6f3bec..fe49e9d 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
@@ -38,6 +38,24 @@ Required properties:
- #gpio-cells: Should be two. The first cell is the pin number. The
second cell is reserved for flags, unused at the moment.
+Optional properties:
+
+In order to use the gpio lines in PWM mode, some additional optional
+properties are required. Only Armada 370 and XP support these properties.
+
+- compatible: Must contain "marvell,armada-370-xp-gpio"
+
+- reg: an additional register set is needed, for the GPIO Blink
+ Counter on/off registers.
+
+- reg-names: Must contain an entry "pwm" corresponding to the
+ additional register range needed for pwm operation.
+
+- #pwm-cells: Should be two. The first cell is the GPIO line number. The
+ second cell is the period in nanoseconds.
+
+- clocks: Must be a phandle to the clock for the gpio controller.
+
Example:
gpio0: gpio@d0018100 {
@@ -51,3 +69,17 @@ Example:
#interrupt-cells = <2>;
interrupts = <16>, <17>, <18>, <19>;
};
+
+ gpio1: gpio@18140 {
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
+ ngpios = <17>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #pwm-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <87>, <88>, <89>;
+ clocks = <&coreclk 0>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 58b3a22..19382f5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10295,6 +10295,8 @@ F: include/linux/pwm.h
F: drivers/pwm/
F: drivers/video/backlight/pwm_bl.c
F: include/linux/pwm_backlight.h
+F: drivers/gpio/gpio-mvebu.c
+F: Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
PXA2xx/PXA3xx SUPPORT
M: Daniel Mack <daniel@zonque.org>
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index fae4db6..e310951 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -42,22 +42,34 @@
#include <linux/io.h>
#include <linux/of_irq.h>
#include <linux/of_device.h>
+#include <linux/pwm.h>
#include <linux/clk.h>
#include <linux/pinctrl/consumer.h>
#include <linux/irqchip/chained_irq.h>
+#include <linux/platform_device.h>
#include <linux/bitops.h>
+#include "gpiolib.h"
+
/*
* GPIO unit register offsets.
*/
-#define GPIO_OUT_OFF 0x0000
-#define GPIO_IO_CONF_OFF 0x0004
-#define GPIO_BLINK_EN_OFF 0x0008
-#define GPIO_IN_POL_OFF 0x000c
-#define GPIO_DATA_IN_OFF 0x0010
-#define GPIO_EDGE_CAUSE_OFF 0x0014
-#define GPIO_EDGE_MASK_OFF 0x0018
-#define GPIO_LEVEL_MASK_OFF 0x001c
+#define GPIO_OUT_OFF 0x0000
+#define GPIO_IO_CONF_OFF 0x0004
+#define GPIO_BLINK_EN_OFF 0x0008
+#define GPIO_IN_POL_OFF 0x000c
+#define GPIO_DATA_IN_OFF 0x0010
+#define GPIO_EDGE_CAUSE_OFF 0x0014
+#define GPIO_EDGE_MASK_OFF 0x0018
+#define GPIO_LEVEL_MASK_OFF 0x001c
+#define GPIO_BLINK_CNT_SELECT_OFF 0x0020
+
+/*
+ * PWM register offsets.
+ */
+#define PWM_BLINK_ON_DURATION_OFF 0x0
+#define PWM_BLINK_OFF_DURATION_OFF 0x4
+
/* The MV78200 has per-CPU registers for edge mask and level mask */
#define GPIO_EDGE_MASK_MV78200_OFF(cpu) ((cpu) ? 0x30 : 0x18)
@@ -78,6 +90,20 @@
#define MVEBU_MAX_GPIO_PER_BANK 32
+struct mvebu_pwm {
+ void __iomem *membase;
+ unsigned long clk_rate;
+ bool used;
+ struct pwm_chip chip;
+ spinlock_t lock;
+ struct mvebu_gpio_chip *mvchip;
+
+ /* Used to preserve GPIO/PWM registers across suspend/resume */
+ u32 blink_select;
+ u32 blink_on_duration;
+ u32 blink_off_duration;
+};
+
struct mvebu_gpio_chip {
struct gpio_chip chip;
spinlock_t lock;
@@ -87,6 +113,10 @@ struct mvebu_gpio_chip {
struct irq_domain *domain;
int soc_variant;
+ /* Used for PWM support */
+ struct clk *clk;
+ struct mvebu_pwm *mvpwm;
+
/* Used to preserve GPIO registers across suspend/resume */
u32 out_reg;
u32 io_conf_reg;
@@ -110,6 +140,12 @@ static void __iomem *mvebu_gpioreg_blink(struct mvebu_gpio_chip *mvchip)
return mvchip->membase + GPIO_BLINK_EN_OFF;
}
+static void __iomem *mvebu_gpioreg_blink_counter_select(struct mvebu_gpio_chip
+ *mvchip)
+{
+ return mvchip->membase + GPIO_BLINK_CNT_SELECT_OFF;
+}
+
static void __iomem *mvebu_gpioreg_io_conf(struct mvebu_gpio_chip *mvchip)
{
return mvchip->membase + GPIO_IO_CONF_OFF;
@@ -181,6 +217,20 @@ static void __iomem *mvebu_gpioreg_level_mask(struct mvebu_gpio_chip *mvchip)
}
/*
+ * Functions returning addresses of individual registers for a given
+ * PWM controller.
+ */
+static void __iomem *mvebu_pwmreg_blink_on_duration(struct mvebu_pwm *mvpwm)
+{
+ return mvpwm->membase + PWM_BLINK_ON_DURATION_OFF;
+}
+
+static void __iomem *mvebu_pwmreg_blink_off_duration(struct mvebu_pwm *mvpwm)
+{
+ return mvpwm->membase + PWM_BLINK_OFF_DURATION_OFF;
+}
+
+/*
* Functions implementing the gpio_chip methods
*/
static void mvebu_gpio_set(struct gpio_chip *chip, unsigned int pin, int value)
@@ -484,6 +534,243 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(chip, desc);
}
+/*
+ * Functions implementing the pwm_chip methods
+ */
+static struct mvebu_pwm *to_mvebu_pwm(struct pwm_chip *chip)
+{
+ return container_of(chip, struct mvebu_pwm, chip);
+}
+
+static int mvebu_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct mvebu_pwm *mvpwm = to_mvebu_pwm(chip);
+ struct gpio_desc *desc = gpio_to_desc(pwm->pwm);
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(&mvpwm->lock, flags);
+ if (mvpwm->used) {
+ ret = -EBUSY;
+ } else {
+ if (!desc) {
+ ret = -ENODEV;
+ goto out;
+ }
+ ret = gpiod_request(desc, "mvebu-pwm");
+ if (ret)
+ goto out;
+
+ ret = gpiod_direction_output(desc, 0);
+ if (ret) {
+ gpiod_free(desc);
+ goto out;
+ }
+
+ mvpwm->used = true;
+ }
+
+out:
+ spin_unlock_irqrestore(&mvpwm->lock, flags);
+ return ret;
+}
+
+static void mvebu_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct mvebu_pwm *mvpwm = to_mvebu_pwm(chip);
+ struct gpio_desc *desc = gpio_to_desc(pwm->pwm);
+ unsigned long flags;
+
+ spin_lock_irqsave(&mvpwm->lock, flags);
+ gpiod_free(desc);
+ mvpwm->used = false;
+ spin_unlock_irqrestore(&mvpwm->lock, flags);
+}
+
+static void mvebu_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state) {
+
+ struct mvebu_pwm *mvpwm = to_mvebu_pwm(chip);
+ struct mvebu_gpio_chip *mvchip = mvpwm->mvchip;
+ unsigned long long val;
+ unsigned long flags;
+ u32 u;
+
+ spin_lock_irqsave(&mvpwm->lock, flags);
+
+ val = (unsigned long long)
+ readl_relaxed(mvebu_pwmreg_blink_on_duration);
+ val *= NSEC_PER_SEC;
+ do_div(val, mvpwm->clk_rate);
+ if (val > UINT_MAX)
+ state->duty_cycle = UINT_MAX;
+ else if (val)
+ state->duty_cycle = val;
+ else
+ state->duty_cycle = 1;
+
+ val = (unsigned long long)
+ readl_relaxed(mvebu_pwmreg_blink_off_duration);
+ val *= NSEC_PER_SEC;
+ do_div(val, mvpwm->clk_rate);
+ if (val < state->duty_cycle) {
+ state->period = 1;
+ } else {
+ val -= state->duty_cycle;
+ if (val > UINT_MAX)
+ state->period = UINT_MAX;
+ else if (val)
+ state->period = val;
+ else
+ state->period = 1;
+ }
+
+ u = readl_relaxed(mvebu_gpioreg_blink(mvchip));
+ if (u)
+ state->enabled = true;
+ else
+ state->enabled = false;
+
+ spin_unlock_irqrestore(&mvpwm->lock, flags);
+}
+
+static int mvebu_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct mvebu_pwm *mvpwm = to_mvebu_pwm(chip);
+ struct mvebu_gpio_chip *mvchip = mvpwm->mvchip;
+ unsigned long long val;
+ unsigned long flags;
+ unsigned int on, off;
+
+ val = (unsigned long long) mvpwm->clk_rate * state->duty_cycle;
+ do_div(val, NSEC_PER_SEC);
+ if (val > UINT_MAX)
+ return -EINVAL;
+ if (val)
+ on = val;
+ else
+ on = 1;
+
+ val = (unsigned long long) mvpwm->clk_rate *
+ (state->period - state->duty_cycle);
+ do_div(val, NSEC_PER_SEC);
+ if (val > UINT_MAX)
+ return -EINVAL;
+ if (val)
+ off = val;
+ else
+ off = 1;
+
+ spin_lock_irqsave(&mvpwm->lock, flags);
+
+ writel_relaxed(on, mvebu_pwmreg_blink_on_duration(mvpwm));
+ writel_relaxed(off, mvebu_pwmreg_blink_off_duration(mvpwm));
+ if (state->enabled)
+ mvebu_gpio_blink(&mvchip->chip, pwm->hwpwm, 1);
+ else
+ mvebu_gpio_blink(&mvchip->chip, pwm->hwpwm, 0);
+
+ spin_unlock_irqrestore(&mvpwm->lock, flags);
+
+ return 0;
+}
+
+static const struct pwm_ops mvebu_pwm_ops = {
+ .request = mvebu_pwm_request,
+ .free = mvebu_pwm_free,
+ .get_state = mvebu_pwm_get_state,
+ .apply = mvebu_pwm_apply,
+ .owner = THIS_MODULE,
+};
+
+static void __maybe_unused mvebu_pwm_suspend(struct mvebu_gpio_chip *mvchip)
+{
+ struct mvebu_pwm *mvpwm = mvchip->mvpwm;
+
+ mvpwm->blink_select =
+ readl_relaxed(mvebu_gpioreg_blink_counter_select(mvchip));
+ mvpwm->blink_on_duration =
+ readl_relaxed(mvebu_pwmreg_blink_on_duration(mvpwm));
+ mvpwm->blink_off_duration =
+ readl_relaxed(mvebu_pwmreg_blink_off_duration(mvpwm));
+}
+
+static void __maybe_unused mvebu_pwm_resume(struct mvebu_gpio_chip *mvchip)
+{
+ struct mvebu_pwm *mvpwm = mvchip->mvpwm;
+
+ writel_relaxed(mvpwm->blink_select,
+ mvebu_gpioreg_blink_counter_select(mvchip));
+ writel_relaxed(mvpwm->blink_on_duration,
+ mvebu_pwmreg_blink_on_duration(mvpwm));
+ writel_relaxed(mvpwm->blink_off_duration,
+ mvebu_pwmreg_blink_off_duration(mvpwm));
+}
+
+static int mvebu_pwm_probe(struct platform_device *pdev,
+ struct mvebu_gpio_chip *mvchip,
+ int id)
+{
+ struct device *dev = &pdev->dev;
+ struct mvebu_pwm *mvpwm;
+ struct resource *res;
+
+ if (!of_device_is_compatible(mvchip->chip.of_node,
+ "marvell,armada-370-xp-gpio"))
+ return 0;
+ /*
+ * There are only two sets of PWM configuration registers for
+ * all the GPIO lines on those SoCs which this driver reserves
+ * for the first two GPIO chips. So if the resource is missing
+ * we can't treat it as an error.
+ */
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pwm");
+ if (!res)
+ return 0;
+
+ /*
+ * Use set A for lines of GPIO chip with id 0, B for GPIO chip
+ * with id 1. Don't allow further GPIO chips to be used for PWM.
+ */
+ if (id == 0)
+ writel_relaxed(0, mvebu_gpioreg_blink_counter_select(mvchip));
+ else if (id == 1)
+ writel_relaxed(U32_MAX,
+ mvebu_gpioreg_blink_counter_select(mvchip));
+ else
+ return -EINVAL;
+
+ mvpwm = devm_kzalloc(dev, sizeof(struct mvebu_pwm), GFP_KERNEL);
+ if (!mvpwm)
+ return -ENOMEM;
+ mvchip->mvpwm = mvpwm;
+ mvpwm->mvchip = mvchip;
+
+ mvpwm->membase = devm_ioremap_resource(dev, res);
+ if (IS_ERR(mvpwm->membase))
+ return PTR_ERR(mvpwm->membase);
+
+ if (IS_ERR(mvchip->clk))
+ return PTR_ERR(mvchip->clk);
+
+ mvpwm->clk_rate = clk_get_rate(mvchip->clk);
+ if (!mvpwm->clk_rate) {
+ dev_err(dev, "failed to get clock rate\n");
+ return -EINVAL;
+ }
+
+ mvpwm->chip.dev = dev;
+ mvpwm->chip.ops = &mvebu_pwm_ops;
+ mvpwm->chip.base = mvchip->chip.base;
+ mvpwm->chip.npwm = mvchip->chip.ngpio;
+
+ spin_lock_init(&mvpwm->lock);
+
+ return pwmchip_add(&mvpwm->chip);
+}
+
#ifdef CONFIG_DEBUG_FS
#include <linux/seq_file.h>
@@ -555,6 +842,10 @@ static const struct of_device_id mvebu_gpio_of_match[] = {
.data = (void *) MVEBU_GPIO_SOC_VARIANT_ARMADAXP,
},
{
+ .compatible = "marvell,armada-370-xp-gpio",
+ .data = (void *) MVEBU_GPIO_SOC_VARIANT_ORION,
+ },
+ {
/* sentinel */
},
};
@@ -600,6 +891,9 @@ static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state)
BUG();
}
+ if (IS_ENABLED(CONFIG_PWM))
+ mvebu_pwm_suspend(mvchip);
+
return 0;
}
@@ -643,6 +937,9 @@ static int mvebu_gpio_resume(struct platform_device *pdev)
BUG();
}
+ if (IS_ENABLED(CONFIG_PWM))
+ mvebu_pwm_resume(mvchip);
+
return 0;
}
@@ -654,7 +951,6 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
struct resource *res;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
- struct clk *clk;
unsigned int ngpios;
bool have_irqs;
int soc_variant;
@@ -688,10 +984,10 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
return id;
}
- clk = devm_clk_get(&pdev->dev, NULL);
+ mvchip->clk = devm_clk_get(&pdev->dev, NULL);
/* Not all SoCs require a clock.*/
- if (!IS_ERR(clk))
- clk_prepare_enable(clk);
+ if (!IS_ERR(mvchip->clk))
+ clk_prepare_enable(mvchip->clk);
mvchip->soc_variant = soc_variant;
mvchip->chip.label = dev_name(&pdev->dev);
@@ -822,6 +1118,10 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
mvchip);
}
+ /* Armada 370/XP has simple PWM support for GPIO lines */
+ if (IS_ENABLED(CONFIG_PWM))
+ return mvebu_pwm_probe(pdev, mvchip, id);
+
return 0;
err_domain:
--
2.10.2
^ permalink raw reply related
* [PATCH v4 2/4] mvebu: xp: Add PWM properties to .dtsi files
From: Ralph Sennhauser @ 2017-03-27 19:42 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, Alexandre Courbot,
linux-gpio, Russell King, linux-pwm, linux-kernel,
Gregory Clement, devicetree, Rob Herring, Ralph Sennhauser,
Imre Kaloz, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20170327194301.1104-1-ralph.sennhauser@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
Add properties to the GPIO nodes to allow them to be also used as PWM
lines.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
URL: https://patchwork.ozlabs.org/patch/427294/
[Ralph Sennhauser:
* Use new compatible string marvell,armada-370-xp-gpio
* Add missing reg-names / #pwm-cell properties to armada-xp-mv78260.dtsi
'gpio1' node]
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
---
arch/arm/boot/dts/armada-370.dtsi | 16 +++++++++++-----
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 14 ++++++++++----
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 16 +++++++++++-----
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 16 +++++++++++-----
4 files changed, 43 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index cc011c8..e30b076 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -137,29 +137,35 @@
};
gpio0: gpio@18100 {
- compatible = "marvell,orion-gpio";
- reg = <0x18100 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18100 0x40>, <0x181c0 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <82>, <83>, <84>, <85>;
+ clocks = <&coreclk 0>;
};
gpio1: gpio@18140 {
- compatible = "marvell,orion-gpio";
- reg = <0x18140 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <87>, <88>, <89>, <90>;
+ clocks = <&coreclk 0>;
};
gpio2: gpio@18180 {
- compatible = "marvell,orion-gpio";
+ compatible = "marvell,armada-370-xp-gpio";
reg = <0x18180 0x40>;
ngpios = <2>;
gpio-controller;
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index 07c5090..429ac10 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -202,25 +202,31 @@
internal-regs {
gpio0: gpio@18100 {
- compatible = "marvell,orion-gpio";
- reg = <0x18100 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18100 0x40>, <0x181c0 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <82>, <83>, <84>, <85>;
+ clocks = <&coreclk 0>;
};
gpio1: gpio@18140 {
- compatible = "marvell,orion-gpio";
- reg = <0x18140 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <17>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <87>, <88>, <89>;
+ clocks = <&coreclk 0>;
};
};
};
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 64e936a..333c470 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -285,29 +285,35 @@
internal-regs {
gpio0: gpio@18100 {
- compatible = "marvell,orion-gpio";
- reg = <0x18100 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18100 0x40>, <0x181c0 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <82>, <83>, <84>, <85>;
+ clocks = <&coreclk 0>;
};
gpio1: gpio@18140 {
- compatible = "marvell,orion-gpio";
- reg = <0x18140 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <87>, <88>, <89>, <90>;
+ clocks = <&coreclk 0>;
};
gpio2: gpio@18180 {
- compatible = "marvell,orion-gpio";
+ compatible = "marvell,armada-370-xp-gpio";
reg = <0x18180 0x40>;
ngpios = <3>;
gpio-controller;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index d1383dd..2ff825d 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -323,29 +323,35 @@
internal-regs {
gpio0: gpio@18100 {
- compatible = "marvell,orion-gpio";
- reg = <0x18100 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18100 0x40>, <0x181c0 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <82>, <83>, <84>, <85>;
+ clocks = <&coreclk 0>;
};
gpio1: gpio@18140 {
- compatible = "marvell,orion-gpio";
- reg = <0x18140 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <87>, <88>, <89>, <90>;
+ clocks = <&coreclk 0>;
};
gpio2: gpio@18180 {
- compatible = "marvell,orion-gpio";
+ compatible = "marvell,armada-370-xp-gpio";
reg = <0x18180 0x40>;
ngpios = <3>;
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v4 3/4] ARM: mvebu: Enable SENSORS_PWM_FAN in defconfig
From: Ralph Sennhauser @ 2017-03-27 19:42 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Imre Kaloz, Andrew Lunn, Ralph Sennhauser, Alexandre Courbot,
Rob Herring, Mark Rutland, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170327194301.1104-1-ralph.sennhauser@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
Now that the GPIO driver also supports PWM operation, enable the PWM
framework and fan driver in mvebu_v7_defconfig.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
URL: https://patchwork.ozlabs.org/patch/427297/
[Ralph Sennhauser: add fan driver to defconfig]
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
---
arch/arm/configs/mvebu_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index f1a0e25..6955370 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -135,6 +135,8 @@ CONFIG_DMADEVICES=y
CONFIG_MV_XOR=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_MEMORY=y
+CONFIG_PWM=y
+CONFIG_SENSORS_PWM_FAN=y
CONFIG_EXT4_FS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
--
2.10.2
^ permalink raw reply related
* [PATCH v4 4/4] mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
From: Ralph Sennhauser @ 2017-03-27 19:43 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Imre Kaloz, Andrew Lunn, Ralph Sennhauser, Alexandre Courbot,
Rob Herring, Mark Rutland, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170327194301.1104-1-ralph.sennhauser@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
The mvebu GPIO driver can also perform PWM on some pins. Use the pwm-fan
driver to control the fan of the WRT1900AC, giving us finer grained control
over its speed and hence noise.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
URL: https://patchwork.ozlabs.org/patch/427291/
[Ralph Sennhauser: drop flags paramter from pwms, no longer used]
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
---
arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
index 9efcf59..6d705f5 100644
--- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
@@ -308,13 +308,11 @@
};
};
- gpio_fan {
+ pwm_fan {
/* SUNON HA4010V4-0000-C99 */
- compatible = "gpio-fan";
- gpios = <&gpio0 24 0>;
- gpio-fan,speed-map = <0 0
- 4500 1>;
+ compatible = "pwm-fan";
+ pwms = <&gpio0 24 4000>;
};
dsa {
--
2.10.2
^ permalink raw reply related
* Re: [PATCH V7 2/7] PCI: Apply the new generic I/O management on PCI IO hosts
From: dann frazier @ 2017-03-27 19:46 UTC (permalink / raw)
To: zhichang.yuan
Cc: Catalin Marinas, Will Deacon, Rob Herring, frowand.list,
Bjorn Helgaas, rafael, Mark Rutland, rjw, Arnd Bergmann,
linux-arm-kernel, linux-acpi, lorenzo.pieralisi, benh,
linux-kernel@vger.kernel.org, linuxarm,
devicetree@vger.kernel.org, linux-pci,
linux-serial@vger.kernel.org, minyard, liviu.dudau, zourongrong,
john.garry, gabriele.paoloni, zhich
In-Reply-To: <1489372963-9000-3-git-send-email-yuanzhichang@hisilicon.com>
On Sun, Mar 12, 2017 at 8:42 PM, zhichang.yuan
<yuanzhichang@hisilicon.com> wrote:
> After introducing the new generic I/O space management(LIBIO), the original PCI
> MMIO relevant helpers need to be updated based on the new interfaces defined in
> LIBIO.
> This patch adapts the corresponding code to match the changes introduced by
> LIBIO.
> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de> #earlier draft
> Acked-by: Bjorn Helgaas <bhelgaas@google.com> #drivers/pci parts
> ---
> drivers/acpi/pci_root.c | 8 +++--
> drivers/of/address.c | 4 ++-
> drivers/pci/pci.c | 96 +++++++++++--------------------------------------
> include/linux/pci.h | 3 +-
> 4 files changed, 30 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 919be0a..4d8cc24 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -730,7 +730,8 @@ static void acpi_pci_root_validate_resources(struct device *dev,
> }
> }
>
> -static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
> +static void acpi_pci_root_remap_iospace(struct fwnode_handle *fwnode,
> + struct resource_entry *entry)
> {
> #ifdef PCI_IOBASE
> struct resource *res = entry->res;
> @@ -739,7 +740,7 @@ static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
> resource_size_t length = resource_size(res);
> unsigned long port;
>
> - if (pci_register_io_range(cpu_addr, length))
> + if (pci_register_io_range(fwnode, cpu_addr, length))
> goto err;
>
> port = pci_address_to_pio(cpu_addr);
> @@ -781,7 +782,8 @@ int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info)
> else {
> resource_list_for_each_entry_safe(entry, tmp, list) {
> if (entry->res->flags & IORESOURCE_IO)
> - acpi_pci_root_remap_iospace(entry);
> + acpi_pci_root_remap_iospace(&device->fwnode,
> + entry);
>
> if (entry->res->flags & IORESOURCE_DISABLED)
> resource_list_destroy_entry(entry);
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..fb5d16a 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -2,6 +2,7 @@
> #define pr_fmt(fmt) "OF: " fmt
>
> #include <linux/device.h>
> +#include <linux/fwnode.h>
> #include <linux/io.h>
> #include <linux/ioport.h>
> #include <linux/module.h>
> @@ -323,7 +324,8 @@ int of_pci_range_to_resource(struct of_pci_range *range,
>
> if (res->flags & IORESOURCE_IO) {
> unsigned long port;
> - err = pci_register_io_range(range->cpu_addr, range->size);
> + err = pci_register_io_range(&np->fwnode, range->cpu_addr,
> + range->size);
> if (err)
> goto invalid_range;
> port = pci_address_to_pio(range->cpu_addr);
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 7904d02..079319f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3238,65 +3238,37 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
> }
> EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> -#ifdef PCI_IOBASE
> -struct io_range {
> - struct list_head list;
> - phys_addr_t start;
> - resource_size_t size;
> -};
> -
> -static LIST_HEAD(io_range_list);
> -static DEFINE_SPINLOCK(io_range_lock);
> -#endif
> -
> /*
> * Record the PCI IO range (expressed as CPU physical address + size).
> * Return a negative value if an error has occured, zero otherwise
> */
> -int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
> + resource_size_t size)
> {
> int err = 0;
>
> #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - /* check if the range hasn't been previously recorded */
> - spin_lock(&io_range_lock);
> - list_for_each_entry(range, &io_range_list, list) {
> - if (addr >= range->start && addr + size <= range->start + size) {
> - /* range already registered, bail out */
> - goto end_register;
> - }
> - allocated_size += range->size;
> - }
> -
> - /* range not registed yet, check for available space */
> - if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> - /* if it's too big check if 64K space can be reserved */
> - if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
> - err = -E2BIG;
> - goto end_register;
> - }
> + struct libio_range *range, *tmprange;
>
> - size = SZ_64K;
> - pr_warn("Requested IO range too big, new size set to 64K\n");
> - }
> + if (!size || addr + size < addr)
> + return -EINVAL;
>
> - /* add the range to the list */
> - range = kzalloc(sizeof(*range), GFP_ATOMIC);
> - if (!range) {
> - err = -ENOMEM;
> - goto end_register;
> - }
> + WARN_ON(!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(size));
>
> - range->start = addr;
> + range = kzalloc(sizeof(*range), GFP_KERNEL);
> + if (!range)
> + return -ENOMEM;
> + range->node = fwnode;
> + range->flags = IO_CPU_MMIO;
> range->size = size;
> + range->hw_start = addr;
>
> - list_add_tail(&range->list, &io_range_list);
> -
> -end_register:
> - spin_unlock(&io_range_lock);
> + tmprange = register_libio_range(range);
> + if (tmprange != range) {
> + kfree(range);
> + if (!IS_ERR(tmprange))
> + err = 0;
> + }
> #endif
>
> return err;
> @@ -3307,21 +3279,10 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
> phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
>
> #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> if (pio > IO_SPACE_LIMIT)
> return address;
>
> - spin_lock(&io_range_lock);
> - list_for_each_entry(range, &io_range_list, list) {
> - if (pio >= allocated_size && pio < allocated_size + range->size) {
> - address = range->start + pio - allocated_size;
> - break;
> - }
> - allocated_size += range->size;
> - }
> - spin_unlock(&io_range_lock);
> + address = libio_to_hwaddr(pio);
> #endif
>
> return address;
> @@ -3330,25 +3291,8 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
> unsigned long __weak pci_address_to_pio(phys_addr_t address)
> {
> #ifdef PCI_IOBASE
> - struct io_range *res;
> - resource_size_t offset = 0;
> - unsigned long addr = -1;
> -
> - spin_lock(&io_range_lock);
> - list_for_each_entry(res, &io_range_list, list) {
> - if (address >= res->start && address < res->start + res->size) {
> - addr = address - res->start + offset;
> - break;
> - }
> - offset += res->size;
> - }
> - spin_unlock(&io_range_lock);
> -
> - return addr;
> + return libio_translate_cpuaddr(address);
> #else
> - if (address > IO_SPACE_LIMIT)
> - return (unsigned long)-1;
> -
> return (unsigned long) address;
> #endif
> }
fyi, this fails to build if PCI_IOBASE is defined and CONFIG_LIBIO=n:
drivers/built-in.o: In function `pci_register_io_range':
/home/ubuntu/linux-4.10.0/drivers/pci/pci.c:3266: undefined reference
to `register_libio_range'
drivers/built-in.o: In function `pci_pio_to_address':
/home/ubuntu/linux-4.10.0/drivers/pci/pci.c:3285: undefined reference
to `libio_to_hwaddr'
drivers/built-in.o: In function `pci_address_to_pio':
/home/ubuntu/linux-4.10.0/drivers/pci/pci.c:3294: undefined reference
to `libio_translate_cpuaddr'
-dann
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index eb3da1a..6401327 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1194,7 +1194,8 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
> void *alignf_data);
>
>
> -int pci_register_io_range(phys_addr_t addr, resource_size_t size);
> +int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
> + resource_size_t size);
> unsigned long pci_address_to_pio(phys_addr_t addr);
> phys_addr_t pci_pio_to_address(unsigned long pio);
> int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH RFC v4 09/10] tty: serdev-ttyport: return actual baudrate from ttyport_set_baudrate
From: Rob Herring @ 2017-03-27 19:50 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, David S. Miller, Greg Kroah-Hartman, Jiri Slaby,
Marcel Holtmann, Sebastian Reichel, netdev,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1490621848-24828-10-git-send-email-stefan.wahren@i2se.com>
On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Instead of returning the requested baudrate, we better return the
> actual one because it isn't always the same.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> drivers/tty/serdev/serdev-ttyport.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/9] clk: meson: update clock controller for audio support
From: Michael Turquette @ 2017-03-27 19:52 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet
Cc: Stephen Boyd, Carlo Caione, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m2r324bq9s.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Quoting Kevin Hilman (2017-03-10 16:39:27)
> Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
>
> > This patchset is a first round of update to the meson clock controllers
> > to bring audio support. The patchset is based on clk-next. It could be
> > rebased on amlogic tree later on, if you prefer the patches to go through
> > Kevin's tree.
>
> I'd prefer these go through the clk tree, and get an immutable branch
> that I can use for my stuff that goes through the arm-soc tree.
Applied to clk-meson, a stable branch, which has been merged into
clk-next.
Kevin, feel free to use clk-meson or any commit id therein: they will
not be rebased.
Regards,
Mike
>
> Kevin
>
> > First patch fix an issue found while writing patch 5 (Giving ternary
> > operator to SET_PARM)
> >
> > Following Stephen comment on the v1, patch 2 adds the const qualifiers
> > missing upstream.
> >
> > Patches 3 and 4 put the generic muxes and divisors declaration in tables so
> > the register address fixup works in the same way as the clock gates. We are
> > going to add more of these clock types for audio or gpu support, so we
> > can't continue to fix addresses individually like it is currently done.
> >
> > Patches 5 to 8 improve the support of the mpll clocks, now allowing the
> > rate to be set. Among other things, the mplls are the parent clocks of the
> > i2s and spdif clocks.
> >
> > Patch 9 expose the clock gates required to power on the i2s output.
> >
> > These patches have been tested on the meson gxbb p200 board, as part of the
> > ongoing work to bring audio support to meson SoC family.
> >
> > Changes since v1 [0]:
> > * Add SET_PARM fix to the series
> > * Add missing const qualifiers to the clock arrays
> > * No more additional patches required as SAR clocks have been merged
> >
> > [0]: http://lkml.kernel.org/r/20170228133002.17894-1-jbrunet@baylibre.com
> >
> > Jerome Brunet (9):
> > clk: meson: fix SET_PARM macro
> > clk: meson: add missing const qualifiers on gate arrays
> > clk: meson8b: put dividers and muxes in tables
> > clk: gxbb: put dividers and muxes in tables
> > clk: meson: mpll: add rw operation
> > clk: meson: gxbb: mpll: use rw operation
> > clk: meson8b: add the mplls clocks 0, 1 and 2
> > clk: meson: mpll: correct N2 maximum value
> > dt-bindings: clk: gxbb: expose i2s output clock gates
> >
> > drivers/clk/meson/clk-mpll.c | 152 ++++++++++++++++++++++++++++++++--
> > drivers/clk/meson/clkc.h | 6 +-
> > drivers/clk/meson/gxbb.c | 66 ++++++++++++---
> > drivers/clk/meson/gxbb.h | 10 +--
> > drivers/clk/meson/meson8b.c | 127 ++++++++++++++++++++++++++--
> > drivers/clk/meson/meson8b.h | 20 ++++-
> > include/dt-bindings/clock/gxbb-clkc.h | 5 ++
> > 7 files changed, 356 insertions(+), 30 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 v4 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL
From: Michael Turquette @ 2017-03-27 19:53 UTC (permalink / raw)
To: Kevin Hilman, Neil Armstrong
Cc: sboyd, carlo, linux-amlogic, linux-clk, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <m237e2iirk.fsf@baylibre.com>
Quoting Kevin Hilman (2017-03-24 12:20:31)
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
> > The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> >
> > The node is simply added in the meson-gxbb.dtsi file.
> >
> > For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> > patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> > dtsi files.
> >
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> LGTM, I can apply this when the clk driver changes are merged (feel free
> to let me know when that happens, in case I'm not paying attention.)
Applied to clk-meson, a stable branch, which has been merged into
clk-next.
Kevin, the dtsi is all yours.
Regards,
Mike
>
> <bikeshed>
> nit: This series (and previous ones) use MALI, but I believe the correct
> way is Mali. Could you standarize on that throughout the series?
> </bikeshed>
>
> Kevin
>
> > ---
> > arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 37 ++++++++++++++++++++
> > arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi | 43 ++++++++++++++++++++++++
> > arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi | 1 +
> > arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 1 +
> > 4 files changed, 82 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > index 04b3324..0617a3d 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > @@ -478,6 +478,43 @@
> > };
> > };
> >
> > +&apb {
> > + mali: gpu@c0000 {
> > + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> > + reg = <0x0 0xc0000 0x0 0x40000>;
> > + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> > + "pp0", "ppmmu0", "pp1", "ppmmu1",
> > + "pp2", "ppmmu2";
> > + clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
> > + clock-names = "bus", "core";
> > +
> > + /*
> > + * Mali clocking is provided by two identical clock paths
> > + * MALI_0 and MALI_1 muxed to a single clock by a glitch
> > + * free mux to safely change frequency while running.
> > + */
> > + assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
> > + <&clkc CLKID_MALI_0>,
> > + <&clkc CLKID_MALI>; /* Glitch free mux */
> > + assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
> > + <0>, /* Do Nothing */
> > + <&clkc CLKID_MALI_0>;
> > + assigned-clock-rates = <0>, /* Do Nothing */
> > + <666666666>,
> > + <0>; /* Do Nothing */
> > + };
> > +};
> > +
> > &i2c_A {
> > clocks = <&clkc CLKID_I2C>;
> > };
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> > new file mode 100644
> > index 0000000..f06cc234
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> > @@ -0,0 +1,43 @@
> > +/*
> > + * Copyright (c) 2017 BayLibre SAS
> > + * Author: Neil Armstrong <narmstrong@baylibre.com>
> > + *
> > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > + */
> > +
> > +&apb {
> > + mali: gpu@c0000 {
> > + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> > + reg = <0x0 0xc0000 0x0 0x40000>;
> > + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> > + "pp0", "ppmmu0", "pp1", "ppmmu1",
> > + "pp2", "ppmmu2";
> > + clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
> > + clock-names = "bus", "core";
> > +
> > + /*
> > + * Mali clocking is provided by two identical clock paths
> > + * MALI_0 and MALI_1 muxed to a single clock by a glitch
> > + * free mux to safely change frequency while running.
> > + */
> > + assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
> > + <&clkc CLKID_MALI_0>,
> > + <&clkc CLKID_MALI>; /* Glitch free mux */
> > + assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
> > + <0>, /* Do Nothing */
> > + <&clkc CLKID_MALI_0>;
> > + assigned-clock-rates = <0>, /* Do Nothing */
> > + <666666666>,
> > + <0>; /* Do Nothing */
> > + };
> > +};
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> > index 615308e..5a90e30 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> > @@ -42,6 +42,7 @@
> > */
> >
> > #include "meson-gxl.dtsi"
> > +#include "meson-gxl-mali.dtsi"
> >
> > / {
> > compatible = "amlogic,s905d", "amlogic,meson-gxl";
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> > index 08237ee..0f78d83 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> > @@ -42,6 +42,7 @@
> > */
> >
> > #include "meson-gxl.dtsi"
> > +#include "meson-gxl-mali.dtsi"
> >
> > / {
> > compatible = "amlogic,s905x", "amlogic,meson-gxl";
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" 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 RFC v4 10/10] tty: serdev: add functions to retrieve common UART settings
From: Rob Herring @ 2017-03-27 20:00 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, David S. Miller, Greg Kroah-Hartman, Jiri Slaby,
Marcel Holtmann, Sebastian Reichel, netdev,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1490621848-24828-11-git-send-email-stefan.wahren@i2se.com>
On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Currently serdev core doesn't provide functions to retrieve common
> UART settings like data bits, stop bits or parity. This patch adds
> the interface to the core and the necessary implementation for
> serdev-ttyport.
It doesn't provide them because why do you need to know? The attached
device should request the settings it needs and be done with it. Maybe
some devices can support a number of settings and you could want
negotiate the settings with the UART, though surely 8N1 is in that
list. It's rare to see something that's not 8N1 from what I've seen.
Rob
^ permalink raw reply
* Re: [PATCH v2 0/5] clk: meson: Fix GXBB and GXL/GXM GP0 PLL
From: Michael Turquette @ 2017-03-27 20:02 UTC (permalink / raw)
To: sboyd, carlo, khilman
Cc: devicetree, Neil Armstrong, linux-kernel, linux-amlogic,
linux-clk, linux-arm-kernel
In-Reply-To: <1490178747-14837-1-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Quoting Neil Armstrong (2017-03-22 03:32:22)
> This patchset fixes support for the Amlogic GXBB then GXL/GXM embedded GP0 PLL.
>
> The current support is done via a very generic interface where only the
> N/M/OD parameters are changed in the control registers.
>
> But unlike the Fixed PLL, this PLL is not initialized by the bootloader or
> firmware, and needs some parameters to initialize and lock correctly.
>
> This patchset also adds the GXL variant compatible string which is already
> supported by the GXL and GXM DT nodes.
>
> Changes since v1 at [1]:
> - Rebase on the Mali clocks patchset at [2]
> - also depends on v2 Audio Clocks patchset from Jerome Brunet at [3]
> - Add match table and separate tables for gxl
> - Switch to probe function to use match table data only
> - Rename unreset_for_lock to clear_reset_for_lock
Thanks for the quick changes. Applied to clk-meson, a stable branch,
which was merged into clk-next.
Best regards,
Mike
>
> [1] http://lkml.kernel.org/r/1489411604-18700-1-git-send-email-narmstrong@baylibre.com
> [2] http://lkml.kernel.org/r/1490177935-9646-1-git-send-email-narmstrong@baylibre.com
> [3] http://lkml.kernel.org/r/20170309104154.28295-1-jbrunet@baylibre.com
>
> Neil Armstrong (5):
> clk: meson: Add support for parameters for specific PLLs
> clk: meson-gxbb: Add GP0 PLL init parameters
> clk: meson-gxbb: Add GXL/GXM GP0 Variant
> clk: meson-gxbb: Expose GP0 dt-bindings clock id
> dt-bindings: clock: gxbb-clkc: Add GXL compatible variant
>
> .../bindings/clock/amlogic,gxbb-clkc.txt | 3 +-
> drivers/clk/meson/clk-pll.c | 53 +++-
> drivers/clk/meson/clkc.h | 23 ++
> drivers/clk/meson/gxbb.c | 314 +++++++++++++++++++--
> drivers/clk/meson/gxbb.h | 4 +-
> include/dt-bindings/clock/gxbb-clkc.h | 1 +
> 6 files changed, 366 insertions(+), 32 deletions(-)
>
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 3/9] arm64: mm: install SError abort handler
From: Florian Fainelli @ 2017-03-27 20:19 UTC (permalink / raw)
To: Marc Zyngier, Florian Fainelli
Cc: Mark Rutland, Doug Berger, catalin.marinas-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, will.deacon-5wv7dgnIgG8,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA, james.morse-5wv7dgnIgG8,
vladimir.murzin-5wv7dgnIgG8, panand-H+wXaHxf7aLQT0dZR+AlfA,
andre.przywara-5wv7dgnIgG8, cmetcalf-VPRAkNaXOzVWk0Htik3J/w,
mingo-DgEjT+Ai2ygdnm+yROfE0A,
sandeepa.s.prabhu-Re5JQEeQqe8AvxtiuMwx3w,
shijie.huang-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
olof-nZhT3qVonbNeoWH0uzbU5w, mirza.krak-Re5JQEeQqe8AvxtiuMwx3w,
suzuki.poulose-5wv7dgnIgG8, bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <867f3doekq.fsf-5wv7dgnIgG8@public.gmane.org>
On 03/25/2017 03:06 AM, Marc Zyngier wrote:
> On Fri, Mar 24 2017 at 07:02:05 PM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 03/24/2017 11:31 AM, Mark Rutland wrote:
>>> Hi Florian,
>>>
>>> On Fri, Mar 24, 2017 at 10:53:48AM -0700, Florian Fainelli wrote:
>>>> On 03/24/2017 10:35 AM, Mark Rutland wrote:
>>>>> On Fri, Mar 24, 2017 at 09:48:40AM -0700, Doug Berger wrote:
>>>>>> On 03/24/2017 08:16 AM, Mark Rutland wrote:
>>>>>>> On Fri, Mar 24, 2017 at 07:46:26AM -0700, Doug Berger wrote:
>>>>>
>>>>>> If you would consider an alternative implementation where we scrap
>>>>>> the SError handler (i.e. maintain the ugliness in our downstream
>>>>>> kernel) in favor of a more gentle user mode crash on SError that
>>>>>> allows the kernel the opportunity to service the interrupt for
>>>>>> diagnostic purposes I could try to repackage that.
>>>>>
>>>>> If this is just for diagnostic purposes, I believe you can register a
>>>>> panic notifier, which can then read from the bus. The panic will occur,
>>>>> but you'll have the opportunity to log some information to dmesg.
>>>>
>>>> And crash the kernel? That sounds awful, FWIW the ARM/Linux kernel is
>>>> able to recover just fine from user-space accessing e.g: invalid
>>>> physical addresses in the GISB register space, bringing the same level
>>>> of functionality to ARM64/Linux sounds reasonable to me.
>>>
>>> I disagree, given that:
>>>
>>> (a) You cannot determine the (HW) origin of the SError in an
>>> architecturally portable way. i.e. when you take an SError, you have
>>> no way of determining what asynchronous event caused it.
>>>
>>> (b) SError is effectively an edge-triggered interrupt for fatal system
>>> errors (e.g. it may be triggered in resonse to ECC errors,
>>> corruption detected in caches, etc). Even if you can determine that
>>> the GISB triggered *an* SError, this does not tell you that this was
>>> the *only* SError.
>>
>> Correct, which is why Doug's changes allow chaining of handlers.
>>
>>>
>>> If you take an SError, something bad has already happened. Your data
>>> may already have been corrupted, and worse, you don't know when or
>>> where specifically this occurred (nor how many times).
>>
>> Sure, but that still allows you to send the correct signal to a faulting
>> application (unless I am missing something here).
>>
>>>
>>> (c) You cannot determine the (SW) origin of an SError without relying
>>> upon implementation details. This cannot be written in a way that
>>> does not rely on microarchitecture, integration, etc, and would need
>>> to be updated for every future system with this misfeature.
>>
>> Which is exactly what is being done here, with the help of platform
>> specific information (we would not load brcmstb_gisb.c if we were not on
>> a platform where it makes sense to use that HW).
>>
>>>
>>> (d) Even if you can determine the (SW) origin of an SError by relying on
>>> IMPLEMENTATION DEFINED details, your handler needs to be intimately
>>> familiar with the arch in question in order to attempt to recover.
>>>
>>> For example, the existing code tries to skip an ARM instruction in
>>> some cases. For arm64 there are three cases that would need to be
>>> handled (AArch64 A64, AArch32 A32/ARM, AArch32 T32/Thumb).
>>>
>>> Further, it appears to me that the existing code is broken given
>>> that it doesn't handle Thumb, and given that it's skipping an
>>> instruction in response to an asynchronous event -- i.e. some
>>> arbitrary instruction after the one which triggered the abort.
>>
>> OK, that could presumably be fixed though.
>>
>>>
>>> For better or worse, SError *must* be treated as fatal.
>>
>> I disagree here, since this is a platform specific SError exception that
>> we can actually handle correctly there is a chance to actually not take
>> down the system on something that can be made non fatal and informative
>> at the same time.
>>
>>>
>>> As Doug stated:
>>>
>>> The main benefit is to help debug user mode code that accidentally
>>> maps a bad address since we would never make such an egregious error
>>> in the kernel ;)
>>>
>>> This is just one of many ways a userspace application with direct HW
>>> access can bring down the system. I see no reason to treat it any
>>> differently, especially given the above points.
>>
>> Partially disagree, in the absence of a way to specifically deal with
>> the exception, I would almost agree, but this is not the case here, we
>> have a piece of HW that can help us locate the problem, display an
>> informative message, and send a SIGBUS to the faulting application.
>>
>> Anyway, I won't argue much further than that, but I certainly don't
>> think taking down an entire system is going to prove itself useful when
>> you need to deploy such a kernel to hundreds of people who have no clue
>> what so ever what their actual problem is in the first place. Taking a
>> SIGBUS and printing a message can at least allow us to say: read more
>> carefully, it say exactly what's wrong.
>
> I think there is one point that hasn't been made in this discussion. You
> seem to assume that an SError should be handled the same way on an ARMv8
> system as you handle it on your ARMv7 platform.
Correct, that is absolutely a conscious (or not) assumption about the
platforms being discussed here, and therefore the proposed patches.
>
> In most cases, Linux on ARMv7 runs (for better or worse) in secure mode,
> making it the only software agent capable of handling an Asynchronous
> Abort. On v8, Linux runs in non-secure mode, and relies on secure
> firmware for a large set of platform specific services (PM, CPU
> bring-up...). Crucially, error handling is one of these services.
>
> It is largely expected that an SError should be first taken to EL3
> (SCR_EL3.EA being set), handled there by any platform-specific FW able
> to triage and log the error, and could even be reported to EL1NS via
> some standard mechanism. If the FW decides to reinject this SError to
> the non-secure side, then this is bound to be fatal, because even the FW
> couldn't handle it.
>
> So my view is that you should move that kind of error handling to the
> place where it actually belongs. It will give you the opportunity to
> print out your debug messages if necessary, and leave the SError
> handling in the kernel the way it should be: fatal.
Your point of view is absolutely valid, but does not necessarily match
the reality of things as implemented in real life because:
- the trusted firmware on some platforms is something that is subject to
a different process than a kernel or user-space upgrade and/or
security/certification process, and may be challenging to update in the
future, so people design it with everything they will ever need: PSCI
v0.2 services and that's it
- there is what ARM Ltd. provides as guidelines about how a platform
should be done (read: must, should?), and there is how implementors end
up making (most often uneducated, biased and under time pressure) design
decisions about how a platform will be designed, and prototype is as
close as you could get to a product in the embedded space
That being said, it is definitively something that should be done, so
we'll make sure this gets funneled back to the appropriate people so
they can think about adding SError handling where it should be done.
Thanks for the feedback!
--
Florian
--
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 v4 07/10] dt-bindings: net: add binding for QCA7000 UART
From: Rob Herring @ 2017-03-27 20:30 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, David S. Miller, Greg Kroah-Hartman, Jiri Slaby,
Marcel Holtmann, Sebastian Reichel, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1490621848-24828-8-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> wrote:
> This is the serdev binding for the QCA7000 UART driver (Ethernet over UART).
>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> ---
>
> According to this binding are still some questions:
>
> Where should be the optional hardware flow control defined (at master or slave side)?
Probably should be in the slave side. We already have uart-has-rtscts
and rts/cts-gpios for the UART. Those mean we have RTS/CTS, but not
necessarily that we want to enable them.
In many cases, the driver may know what it needs.
> Is it okay to have two bindings (qca-qca7000-spi and qca-qca7000-uart) or should they be merged?
Are they mutually-exclusive or both are used at the same time? What
are the dependencies between the interfaces?
>
>
> .../devicetree/bindings/net/qca-qca7000-uart.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/qca-qca7000-uart.txt
>
> diff --git a/Documentation/devicetree/bindings/net/qca-qca7000-uart.txt b/Documentation/devicetree/bindings/net/qca-qca7000-uart.txt
> new file mode 100644
> index 0000000..f2e0450
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/qca-qca7000-uart.txt
> @@ -0,0 +1,31 @@
> +* Qualcomm QCA7000 (Ethernet over UART protocol)
> +
> +Note: This binding applies in case the QCA7000 is configured as a
> +UART slave device. It is possible to preconfigure the UART settings
> +of the QCA7000 firmware, which can't be changed during runtime.
> +
> +Required properties:
> +- compatible : Should be "qca,qca7000-uart"
> +
> +Optional properties:
> +- local-mac-address : 6 bytes, Specifies MAC address
The description can be "see ./ethernet.txt"
> +- current-speed : Specifies the serial device speed in
> + bits per second (default = 115200), which is
> + predefined by the QCA7000 firmware configuration
Add this to the slave binding doc with some caveats as to when this
should or should not be used as we discussed.
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/3] device property: fwnode_property_read_string_array() may return -EILSEQ
From: Sakari Ailus @ 2017-03-27 21:39 UTC (permalink / raw)
To: Mika Westerberg
Cc: linux-acpi, devicetree, sudeep.holla, lorenzo.pieralisi, rafael,
mark.rutland, broonie, robh, ahs3
In-Reply-To: <20170327135322.GI2957@lahna.fi.intel.com>
Hi Mika,
Mika Westerberg wrote:
> On Mon, Mar 06, 2017 at 03:26:29PM +0200, Sakari Ailus wrote:
>> fwnode_property_read_string_array() may return -EILSEQ through
>> of_property_read_string_array(). Document this.
>>
>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Thanks!
>
> Though, I wonder if it would be good to change the function to only
> return what the DT version does. Now the caller needs to check for both
> values.
>
It's rather that this value is currently returned by
of_property_read_string_array(). I'd guess though that most callers
don't care about the error code.
--
Kind regards,
Sakari Ailus
sakari.ailus@linux.intel.com
^ permalink raw reply
* Re: [PATCH v1.1 3/3] device property: fwnode_property_read_string_array() returns nr of strings
From: Sakari Ailus @ 2017-03-27 21:46 UTC (permalink / raw)
To: Mika Westerberg
Cc: linux-acpi, devicetree, sudeep.holla, lorenzo.pieralisi, rafael,
mark.rutland, broonie, robh, ahs3
In-Reply-To: <20170327133618.GH2957@lahna.fi.intel.com>
Hi Mika,
Mika Westerberg wrote:
> On Wed, Mar 15, 2017 at 03:31:28PM +0200, Sakari Ailus wrote:
>> Functionally fwnode_property_read_string_array() should match
>> of_property_read_string_array() and work as a drop-in substitute for the
>> latter. of_property_read_string_array() returns the number of strings read
>> if the target string pointer array is non-NULL. Make
>> fwnode_property_read_string_array() do the same.
>>
>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>> ---
>> This patch replaces v1 3/3 patch in this set.
>>
>> Instead of changing the return value of fwnode / device property API
>> string array access on OF, change the behaviour on pset and ACPI instead.
>> This makes them to return the number of strings read on success.
>>
>> I can merge this with patch 2/3 which is changing the same part of the
>> file, however I'm sending this separately at least for now as I think it's
>> easier to review this way, rather than making a bugfix and a change of the
>> behaviour in the same patch.
>>
>> Regards,
>> Sakari
>>
>> drivers/base/property.c | 64 +++++++++++++++++++++++++++++++++++--------------
>> 1 file changed, 46 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/base/property.c b/drivers/base/property.c
>> index 8c98390..82187ac 100644
>> --- a/drivers/base/property.c
>> +++ b/drivers/base/property.c
>> @@ -340,8 +340,8 @@ EXPORT_SYMBOL_GPL(device_property_read_u64_array);
>> * Function reads an array of string properties with @propname from the device
>> * firmware description and stores them to @val if found.
>> *
>> - * Return: number of values if @val was %NULL,
>> - * %0 if the property was found (success),
>> + * Return: number of values read on success if @val is non-NULL,
>> + * number of values available on success if @val is NULL,
>> * %-EINVAL if given arguments are not valid,
>> * %-ENODATA if the property does not have a value,
>> * %-EPROTO or %-EILSEQ if the property is not an array of strings,
>> @@ -549,29 +549,57 @@ static int __fwnode_property_read_string_array(struct fwnode_handle *fwnode,
>> of_property_read_string_array(to_of_node(fwnode),
>> propname, val, nval) :
>> of_property_count_strings(to_of_node(fwnode), propname);
>> - else if (is_acpi_node(fwnode))
>> - return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
>> - val, nval);
>> - else if (is_pset_node(fwnode)) {
>> + else if (is_acpi_node(fwnode)) {
>> + int array_len =
>> + acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
>
> Why not change acpi_node_prop_read() instead? This way you don't need to
> add the extra code dealing with the return value here.
>
> Ditto for the pset counterpart.
There are a few other users of acpi_node_prop_read() albeit there are
not too many of them. acpi_node_prop_read() is just calling
acpi_dev_prop_read() which is public but apparently has no users. I
think changing that would be quite feasible, I'll take that into account
in the next version. Same for pset.
--
Sakari Ailus
sakari.ailus@linux.intel.com
^ permalink raw reply
* Re: [PATCH v2 1/2] soc: qcom: Add device tree binding for GLINK RPM
From: Bjorn Andersson @ 2017-03-27 23:30 UTC (permalink / raw)
To: Rob Herring
Cc: Andy Gross, Mark Rutland, Ohad Ben-Cohen, linux-arm-msm,
open list:ARM/QUALCOMM SUPPORT, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
In-Reply-To: <CAL_JsqKt+JXVbsZpQpXZeDQ6cD33DiQ8R1oszcfX3y5QwQVjJQ@mail.gmail.com>
On Mon 27 Mar 11:44 PDT 2017, Rob Herring wrote:
> On Sat, Mar 25, 2017 at 11:31 PM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> > On Fri 24 Mar 09:07 PDT 2017, Rob Herring wrote:
> >
> >> On Mon, Mar 20, 2017 at 02:09:55PM -0700, Bjorn Andersson wrote:
> >> > Add device tree binding documentation for the Qualcomm GLINK RPM, used
> >> > for communication with the Resource Power Management subsystem in
> >> > various Qualcomm SoCs.
> >> >
> >> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> >> > ---
> >> >
> >> > Changes since v1:
> >> > - None
> >> >
> >> > .../devicetree/bindings/soc/qcom/qcom,glink.txt | 73 ++++++++++++++++++++++
> >> > 1 file changed, 73 insertions(+)
> >> > create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> >> > new file mode 100644
> >> > index 000000000000..da92c4f787f3
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> >> > @@ -0,0 +1,73 @@
> >> > +Qualcomm RPM GLINK binding
> >> > +
> >> > +This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
> >> > +communication with the Resource Power Management system on various Qualcomm
> >> > +platforms.
> >> > +
> >> > +- compatible:
> >> > + Usage: required
> >> > + Value type: <stringlist>
> >> > + Definition: must be "qcom,glink-rpm"
> >>
> >> SoC specific compatibles please.
> >>
> >
> > In addition to the generic qcom,glink-rpm I presume?
>
> Right.
>
> >
> >> > +
> >> > +- interrupts:
> >> > + Usage: required
> >> > + Value type: <prop-encoded-array>
> >> > + Definition: should specify the IRQ used by the remote processor to
> >> > + signal this processor about communication related events
> >> > +
> >> > +- qcom,rpm-msg-ram:
> >> > + Usage: required
> >> > + Value type: <prop-encoded-array>
> >> > + Definition: handle to RPM message memory resource
> >> > +
> >> > +- qcom,ipc:
> >> > + Usage: required
> >> > + Value type: <prop-encoded-array>
> >> > + Definition: three entries specifying the outgoing ipc bit used for
> >> > + signaling the remote processor:
> >> > + - phandle to a syscon node representing the apcs registers
> >> > + - u32 representing offset to the register within the syscon
> >> > + - u32 representing the ipc bit within the register
> >> > +
> >> > += GLINK DEVICES
> >> > +Each subnode of the GLINK node represent function tied to a virtual
> >> > +communication channel. The name of the nodes are not important. The properties
> >> > +of these nodes are defined by the individual bindings for the specific function
> >> > +- but must contain the following property:
> >> > +
> >> > +- qcom,glink-channels:
> >> > + Usage: required
> >> > + Value type: <stringlist>
> >> > + Definition: a list of channels tied to this function, used for matching
> >> > + the function to a set of virtual channels
> >> > +
> >> > += EXAMPLE
> >> > +The following example represents the GLINK RPM node on a MSM8996 device, with
> >> > +the function for the "rpm_request" channel defined, which is used for
> >> > +regualtors and root clocks.
> >> > +
> >> > + apcs: syscon@f9011000 {
> >> > + compatible = "syscon";
> >>
> >> syscon alone is not valid.
> >>
> >
> > This is equivalent to how we have done this on all previous platforms.
>
> Then they are wrong...
>
> > On previous platforms this generally maps to one of the "Krait Processor
> > SubSystem" blocks, so I'm quite worried with coming up with a compatible
> > for this block will not be compatible with any future description of
> > this block.
>
> Perhaps why we should get rid of syscon. It's not supposed to be a "I
> don't know how to define a binding, so just make all registers
> available for now".
>
I know...
> I don't really see how a compatible string alone would create problems
> to extend the binding if you need to later. Even if it did, you can
> always rev compatible strings.
>
The problem is that the "apcs" region is just one of the regions related
to the KPSS; this one being the "global" region.
I could just replace the current occurrences with
"qcom,msm8974-apcs-kpss-glb" and "qcom,msm8916-apcs-kpss-glb" and then
try to figure out what it's called in this platform. I am worried,
however, that this description of the "kpss" hardware won't be the right
approach if/when anyone else tries to actually model it.
There has been talks about replacing the use of syscon here with a new
"ipc-kicker" description. Should I propose a completely new binding for
"invoking IRQs on remote processors" instead of using syscon? What's the
name of such a bike shed?
> >> > + reg = <0xf9011000 0x1000>;
> >> > + };
> >> > +
> >> > + rpm_msg_ram: memory@68000 {
> >> > + compatible = "qcom,rpm-msg-ram";
> >>
> >> Is this more than just mmio-sram?
> >>
> >> Or with a fixed use could be part of another node?
> >>
On prior platforms it was part of the qcom,smem node but was extracted
to better represent the hardware design.
> >
> > It represents one of the RAM modules of one of the other ARM cores in
> > the SoC, used for shared memory communication with this ARM core. So the
> > hardware is essentially mmio-sram. But it has none of the properties
> > that a mmio-sram seem to have.
>
> Properties such as?
>
Probably unwise of me to use the word "properties" here, as I wasn't
thinking in DT lingo, but the first paragraph of sram.txt states:
"Simple IO memory regions to be managed by the genalloc API."
This memory is not managed by genalloc, it consists of a read-only
section where we can find a pointer to the subregion that we are allowed
to read and write - any accesses outside this region will cause a access
violation.
The subregion provided is shared with a remote processor and as such
must follow the predefined data-structure - implemented by something
claiming to implement "qcom,glink-rpm".
Looking at the sram implementation there's nothing even close to useful
for us there. Claiming that this memory is something that the Linux
implementation of mmio-sram will deal with just wrong.
It might be SRAM (although I believe it's on-chip DRAM) and it is memory
mapped, but that's where the similarities ends...
Regards,
Bjorn
^ permalink raw reply
* [PATCH v6 00/39] i.MX Media Driver
From: Steve Longerbeam @ 2017-03-28 0:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, kernel, fabio.estevam, linux,
mchehab, hverkuil, nick, markus.heiser, p.zabel,
laurent.pinchart+renesas, bparrot, geert, arnd, sudipm.mukherjee,
minghsiu.tsai, tiffany.lin, jean-christophe.trotin, horms+renesas,
niklas.soderlund+renesas, robert.jarzmik, songjun.wu,
andrew-ct.chen, gregkh, shuah, sakari.ailus, pavel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In version 6:
- moved FIM error event back to a i.MX private event. I would like to
leave this as a (private) event rather than reporting a vb2 queue
error, for now. If and when the i.MX6 timer input capture patch is
accepted later, then this event can become a queue error.
- removed new-frame-before-end-of-frame (NFB4EOF) event. Instead when
this IPU DMA channel error occurs, the next captured frame is marked
with the vb2 error flag.
- updates to Documentation/media/v4l-drivers/imx.rst.
- ov5640: propagate return codes from the register read/write primitives
in various places.
- ov5640: removed the [gs]_parm ops.
- ov5640: avoid possible divide-by-0's.
- only the CSI subdevice implements [gs]_frame_interval now (or needs
to). Those ops have been removed from the subdevices that have no
control over frame rate.
- removed the patch that adds v4l2_subdev_link_validate_frame_interval().
- properly propagate the TRY formats from sink to source pads within the
subdevices (spotted by Philipp Zabel <p.zabel@pengutronix.de>).
- added enum_frame_size op to imx-ic-prpencvf and CSI subdevices.
- added enum_frame_intervals op to CSI subdevice (patch from Russell
King <rmk+kernel@armlinux.org.uk>).
- added V4L2 interface ops enum_framesizes and enum_frameintervals, which
calls the corresponding subdev op at the connected source subdev (patch
from Russell King <rmk+kernel@armlinux.org.uk>).
- added missing Bayer support to CSI subdevice (patch from Russell King
<rmk+kernel@armlinux.org.uk>).
- switched to v4l2_pipeline_pm_use() and v4l2_pipeline_link_notify()
for the pipeline power management.
- the power-on order has changed due to above: the sensor now
is powered on _before_ the MIPI CSI-2 receiver, which means
MIPI CSI-2 receiver startup sequence steps 3, 4, and 5 can
be moved up to csi2_s_power() from csi2_s_stream(). And that
means step 7 (wait for clock lane) now has a place to be called
in csi2_s_stream().
- changed the bus_info string for the capture device interfaces to
"platform:[src_sd->name]" instead of using the capture device name,
so that the bus_info strings are unique between the capture devices.
I was hoping this would provide unique device node symlink names under
/dev/v4l/by-path/, but they are still named
"platform-capture-subsystem-video-indexNN".
- fixed cropping and /2 downsizing in the CSI subdevice. These should be
specified using the crop and compose APIs at the sink pad, not the
source pad (patch from Philipp Zabel <p.zabel@pengutronix.de>).
- added a check at CSI subdevice stream on. If the connected sensor
reports faulty frames at power on via g_skip_frames op, the CSI
should avoid capturing those frames before enabling the CSI.
- moved imx.h UAPI header to include/linux/imx-media.h while imx-media
driver is still under staging.
Philipp Zabel (8):
[media] dt-bindings: Add bindings for video-multiplexer device
ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their
connections
add mux and video interface bridge entity functions
platform: add video-multiplexer subdevice driver
media: imx: csi: fix crop rectangle changes in set_fmt
media: imx: csi: add frame skipping support
media: imx: csi: fix crop rectangle reset in sink set_fmt
media: imx: csi: add sink selection rectangles
Russell King (5):
media: imx: add support for bayer formats
media: imx: csi: add support for bayer formats
media: imx: csi/fim: add support for frame intervals
media: imx-csi: add frame size/interval enumeration
media: imx-media-capture: add frame sizes/interval enumeration
Steve Longerbeam (26):
[media] dt-bindings: Add bindings for i.MX media driver
[media] dt/bindings: Add bindings for OV5640
ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
ARM: dts: imx6qdl: add capture-subsystem device
ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround
ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabreauto: create i2cmux for i2c3
ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
[media] v4l2-mc: add a function to inherit controls from a pipeline
[media] add Omnivision OV5640 sensor driver
media: Add userspace header file for i.MX
media: Add i.MX media core driver
media: imx: Add Capture Device Interface
media: imx: Add CSI subdev driver
media: imx: Add VDIC subdev driver
media: imx: Add IC subdev drivers
media: imx: Add MIPI CSI-2 Receiver subdev driver
ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers
media: imx: csi: add __csi_get_fmt
media: imx: redo pixel format enumeration and negotiation
media: imx: csi: Avoid faulty sensor frames at stream start
media: imx: propagate sink pad formats to source pads
media: imx-ic-prpencvf: add frame size enumeration
.../devicetree/bindings/media/i2c/ov5640.txt | 45 +
Documentation/devicetree/bindings/media/imx.txt | 74 +
.../bindings/media/video-multiplexer.txt | 59 +
Documentation/media/uapi/mediactl/media-types.rst | 22 +
Documentation/media/v4l-drivers/imx.rst | 590 ++++++
arch/arm/boot/dts/imx6dl-sabrelite.dts | 5 +
arch/arm/boot/dts/imx6dl-sabresd.dts | 5 +
arch/arm/boot/dts/imx6dl.dtsi | 185 ++
arch/arm/boot/dts/imx6q-sabrelite.dts | 5 +
arch/arm/boot/dts/imx6q-sabresd.dts | 5 +
arch/arm/boot/dts/imx6q.dtsi | 121 ++
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 144 +-
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 152 +-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 +-
arch/arm/boot/dts/imx6qdl.dtsi | 17 +-
arch/arm/configs/imx_v6_v7_defconfig | 11 +
drivers/media/i2c/Kconfig | 7 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov5640.c | 2219 ++++++++++++++++++++
drivers/media/platform/Kconfig | 8 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/video-multiplexer.c | 451 ++++
drivers/media/v4l2-core/v4l2-mc.c | 50 +
drivers/staging/media/Kconfig | 2 +
drivers/staging/media/Makefile | 1 +
drivers/staging/media/imx/Kconfig | 20 +
drivers/staging/media/imx/Makefile | 12 +
drivers/staging/media/imx/TODO | 17 +
drivers/staging/media/imx/imx-ic-common.c | 113 +
drivers/staging/media/imx/imx-ic-prp.c | 452 ++++
drivers/staging/media/imx/imx-ic-prpencvf.c | 1232 +++++++++++
drivers/staging/media/imx/imx-ic.h | 38 +
drivers/staging/media/imx/imx-media-capture.c | 776 +++++++
drivers/staging/media/imx/imx-media-csi.c | 1779 ++++++++++++++++
drivers/staging/media/imx/imx-media-dev.c | 503 +++++
drivers/staging/media/imx/imx-media-fim.c | 463 ++++
drivers/staging/media/imx/imx-media-internal-sd.c | 349 +++
drivers/staging/media/imx/imx-media-of.c | 267 +++
drivers/staging/media/imx/imx-media-utils.c | 947 +++++++++
drivers/staging/media/imx/imx-media-vdic.c | 910 ++++++++
drivers/staging/media/imx/imx-media.h | 305 +++
drivers/staging/media/imx/imx6-mipi-csi2.c | 673 ++++++
include/linux/imx-media.h | 27 +
include/media/imx.h | 15 +
include/media/v4l2-mc.h | 31 +
include/uapi/linux/media.h | 6 +
include/uapi/linux/v4l2-controls.h | 4 +
47 files changed, 13207 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 Documentation/devicetree/bindings/media/imx.txt
create mode 100644 Documentation/devicetree/bindings/media/video-multiplexer.txt
create mode 100644 Documentation/media/v4l-drivers/imx.rst
create mode 100644 drivers/media/i2c/ov5640.c
create mode 100644 drivers/media/platform/video-multiplexer.c
create mode 100644 drivers/staging/media/imx/Kconfig
create mode 100644 drivers/staging/media/imx/Makefile
create mode 100644 drivers/staging/media/imx/TODO
create mode 100644 drivers/staging/media/imx/imx-ic-common.c
create mode 100644 drivers/staging/media/imx/imx-ic-prp.c
create mode 100644 drivers/staging/media/imx/imx-ic-prpencvf.c
create mode 100644 drivers/staging/media/imx/imx-ic.h
create mode 100644 drivers/staging/media/imx/imx-media-capture.c
create mode 100644 drivers/staging/media/imx/imx-media-csi.c
create mode 100644 drivers/staging/media/imx/imx-media-dev.c
create mode 100644 drivers/staging/media/imx/imx-media-fim.c
create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
create mode 100644 drivers/staging/media/imx/imx-media-of.c
create mode 100644 drivers/staging/media/imx/imx-media-utils.c
create mode 100644 drivers/staging/media/imx/imx-media-vdic.c
create mode 100644 drivers/staging/media/imx/imx-media.h
create mode 100644 drivers/staging/media/imx/imx6-mipi-csi2.c
create mode 100644 include/linux/imx-media.h
create mode 100644 include/media/imx.h
--
2.7.4
^ permalink raw reply
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