* Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask
From: Robin Murphy @ 2017-04-06 10:24 UTC (permalink / raw)
To: Frank Rowand, Sricharan R, will.deacon-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, tn-nYOzD4b6Jr9Wk0Htik3J/w,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A, okaya-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sudeep.holla-5wv7dgnIgG8,
rjw-LthD3rsA81gm4RdzfppkhA, lenb-DgEjT+Ai2ygdnm+yROfE0A,
catalin.marinas-5wv7dgnIgG8, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
In-Reply-To: <58E5E7B7.1050400-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 06/04/17 08:01, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> Size of the dma-range is calculated as coherent_dma_mask + 1
>> and passed to arch_setup_dma_ops further. It overflows when
>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF,
>> resulting in size getting passed as 0 wrongly. Fix this by
>> passsing in max(mask, mask + 1). Note that in this case
>> when the mask is set to full 64bits, we will be passing the mask
>> itself to arch_setup_dma_ops instead of the size. The real fix
>> for this should be to make arch_setup_dma_ops receive the
>> mask and handle it, to be done in the future.
>>
>> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> drivers/of/device.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index c17c19d..c2ae6bb 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>> if (ret < 0) {
>> dma_addr = offset = 0;
>> - size = dev->coherent_dma_mask + 1;
>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>> } else {
>> offset = PFN_DOWN(paddr - dma_addr);
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>
>
> NACK.
>
> Passing an invalid size to arch_setup_dma_ops() is only part of the problem.
> size is also used in of_dma_configure() before calling arch_setup_dma_ops():
>
> dev->coherent_dma_mask = min(dev->coherent_dma_mask,
> DMA_BIT_MASK(ilog2(dma_addr + size)));
> *dev->dma_mask = min((*dev->dma_mask),
> DMA_BIT_MASK(ilog2(dma_addr + size)));
>
> which would be incorrect for size == 0xffffffffffffffffULL when
> dma_addr != 0. So the proposed fix really is not papering over
> the base problem very well.
I'm not sure I agree there. Granted, there exist many more problematic
aspects than are dealt with here (I've got more patches cooking to sort
out some of the other issues we have with dma-ranges), but considering
size specifically:
- It is not possible to explicitly specify a range with a size of 2^64
in DT. If someone does specify a size of 0, they've done a silly thing
and should not be surprised that it ends badly.
- It *is* perfectly legitimate for bus code (or a previous device
driver, once we start coming here at probe time) to have set a device's
DMA mask to 0xffffffffffffffffULL. If this code then blindly overflows
and infers an invalid size of 0 from that, breaking things in the
process, that is this code's fault alone. It just so happens that
nothing managed to trigger the latent problem until patch #7 here shakes
up the callsites.
Yes, wacky impossible base + size combinations in DT were a theoretical
problem before, and remain a theoretical problem, but also fall into the
"how did you ever expect this to work?" category. There's certainly
plenty more we can do to improve the DT parsing/validation, but that
still doesn't apply to this path where the information is *not* coming
from the DT at all.
> I agree that the proper solution involves passing a mask instead
> of a size to arch_setup_dma_ops().
Having started writing that patch too, I can tell you it's a big bugger
touching multiple architectures and fixing up various drivers doing
stupid things, hence why I'm happy with this point fix being the lesser
of two evils in terms of not holding up this mostly-orthogonal series.
Robin.
>
> -Frank
>
^ permalink raw reply
* Re: [PATCH 0/2] pmu0 MMIO region for A64 USB PHY
From: Kishon Vijay Abraham I @ 2017-04-06 10:26 UTC (permalink / raw)
To: Icenowy Zheng, Maxime Ripard, Chen-Yu Tsai, Greg Kroah-Hartman
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405143034.8868-1-icenowy-h8G6r0blFSE@public.gmane.org>
Hi,
On Wednesday 05 April 2017 08:00 PM, Icenowy Zheng wrote:
> The USB PHY of A64 contains a "pmu0" MMIO region, which contains some control
> registers for the EHCI0/OHCI0 pair on A64 SoC.
>
> This pair is not used currently in 4.11, but when enabling it in 4.12, the
> MMIO region is needed.
>
> In order to prevent device tree compatibility breakage, add this region in
> 4.11.
I feel the binding documentation can go along with the dt changes. Moreover I
have no plans of sending another pull request for this -rc cycle.
FWIW:
Acked-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Thanks
Kishon
>
> Icenowy Zheng (2):
> dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64
> arm64: allwinner: a64: add pmu0 regs for USB PHY
>
> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 ++
> 2 files changed, 3 insertions(+)
>
^ permalink raw reply
* Re: [PATCH v5 1/9] phy: phy-mt65xx-usb3: improve RX detection stable time
From: Kishon Vijay Abraham I @ 2017-04-06 10:28 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Felipe Balbi, Ian Campbell, linux-usb,
linux-kernel, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
In-Reply-To: <1490945735-9531-1-git-send-email-chunfeng.yun@mediatek.com>
On Friday 31 March 2017 01:05 PM, Chunfeng Yun wrote:
> The default value of RX detection stable time is 10us, and this
> margin is too big for some critical cases which cause U3 link fail
> and link to U2(probability is about 1%). So change it to 5us.
>
merged all the phy patches in this series to linux-phy -next.
Thanks
Kishon
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/phy/phy-mt65xx-usb3.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> index d972067..fe2392a 100644
> --- a/drivers/phy/phy-mt65xx-usb3.c
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -112,6 +112,14 @@
> #define P3D_RG_CDR_BIR_LTD0 GENMASK(12, 8)
> #define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8)
>
> +#define U3P_U3_PHYD_RXDET1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x128)
> +#define P3D_RG_RXDET_STB2_SET GENMASK(17, 9)
> +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9)
> +
> +#define U3P_U3_PHYD_RXDET2 (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c)
> +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0)
> +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x) (0x1ff & (x))
> +
> #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018)
> #define XC3_RG_U3_XTAL_RX_PWD BIT(9)
> #define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8)
> @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
> tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3);
> writel(tmp, port_base + U3P_PHYD_CDR1);
>
> + tmp = readl(port_base + U3P_U3_PHYD_RXDET1);
> + tmp &= ~P3D_RG_RXDET_STB2_SET;
> + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10);
> + writel(tmp, port_base + U3P_U3_PHYD_RXDET1);
> +
> + tmp = readl(port_base + U3P_U3_PHYD_RXDET2);
> + tmp &= ~P3D_RG_RXDET_STB2_SET_P3;
> + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10);
> + writel(tmp, port_base + U3P_U3_PHYD_RXDET2);
> +
> dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
> }
>
>
^ permalink raw reply
* [RFC] Documentation: pinctrl: Add "pinmux" property
From: Jacopo Mondi @ 2017-04-06 10:35 UTC (permalink / raw)
To: linus.walleij, geert, robh+dt, mark.rutland
Cc: linux-gpio, devicetree, linux-renesas-soc, linux-kernel
Document "pinmux" property as part of generic pin controller
documentation.
Fix 2 minor typos in documentation while at there.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
Hi Linus and linux-gpio community.
During development of Renesas RZ/A1 pin controller I've been suggested to add
description of "pinmux" property to generic pin controller documentation.
Currently several pin controller drivers are using this property in place of
the already documented "pin"/"group" and "function" ones: stm32, mt65xx, mt8173
and in-review r7s72100, not sure about at91-sama5d2)
Sending this one as RFC to collect feedback. If the change is not rejected is it
worth adding to pin controller core helper functions to parse the newly
documented property, as this commit
<https://patchwork.kernel.org/patch/9411231/>
did for "pinctrl-pin-array" one?
All drivers using "pinmux" exhibit the same behavior which is fine as long as
"pinmux" only accepts a list of u32 parameters.
...
pins = of_find_property(node, "pinmux", NULL);
...
npins = pins->length / sizeof(u32);
...
of_property_read_u32_index(node, "pinmux",
i, &pinfunc);
...
Thanks
---
.../bindings/pinctrl/pinctrl-bindings.txt | 46 +++++++++++++++++++---
1 file changed, 41 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index f2ed458..6609389 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -162,8 +162,8 @@ state_2_node_a {
pins = "mfio29", "mfio30";
};
-Optionally an altenative binding can be used if more suitable depending on the
-pin controller hardware. For hardaware where there is a large number of identical
+Optionally an alternative binding can be used if more suitable depending on the
+pin controller hardware. For hardware where there is a large number of identical
pin controller instances, naming each pin and function can easily become
unmaintainable. This is especially the case if the same controller is used for
different pins and functions depending on the SoC revision and packaging.
@@ -198,6 +198,28 @@ registers, and must not be a virtual index of pin instances. The reason for
this is to avoid mapping of the index in the dts files and the pin controller
driver as it can change.
+For hardware where pin multiplexing configurations have to be specified for
+each single pin the number of required sub-nodes containing "pin" and
+"function" properties can quickly escalate and become hard to write and
+maintain.
+
+For cases like this, the pin controller driver may use the pinmux helper
+property, where the pin identifier is packed with mux configuration settings
+in a single integer.
+
+The pinmux property accepts an array of integers, each of them describing
+a single pin multiplexing configuration.
+
+pincontroller {
+ state_0_node_a {
+ pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ...;
+ };
+};
+
+Each individual pin controller driver bindings documentation shall specify
+how those values (pin IDs and pin multiplexing configuration) are defined and
+assembled together.
+
== Generic pin configuration node content ==
Many data items that are represented in a pin configuration node are common
@@ -210,12 +232,15 @@ structure of the DT nodes that contain these properties.
Supported generic properties are:
pins - the list of pins that properties in the node
- apply to (either this or "group" has to be
+ apply to (either this, "group" or "pinmux" has to be
specified)
group - the group to apply the properties to, if the driver
supports configuration of whole groups rather than
- individual pins (either this or "pins" has to be
- specified)
+ individual pins (either this, "pins" or "pinmux" has
+ to be specified)
+pinmux - the list of numeric pin ids and their mux settings
+ that properties in the node apply to (either this,
+ "pins" or "groups" have to be specified)
bias-disable - disable any pin bias
bias-high-impedance - high impedance mode ("third-state", "floating")
bias-bus-hold - latch weakly
@@ -260,6 +285,12 @@ state_2_node_a {
bias-pull-up;
};
};
+state_3_node_a {
+ mux {
+ pinmux = <GPIOx_PINm_MUXn>, <GPIOx_PINj_MUXk)>;
+ input-enable;
+ };
+};
Some of the generic properties take arguments. For those that do, the
arguments are described below.
@@ -268,6 +299,11 @@ arguments are described below.
binding for the hardware defines:
- Whether the entries are integers or strings, and their meaning.
+- pinmux takes a list of pin IDs and mux settings as required argument. The
+ specific bindings for the hardware defines:
+ - How pin IDs and mux settings are defined and assembled together in a single
+ integer.
+
- bias-pull-up, -down and -pin-default take as optional argument on hardware
supporting it the pull strength in Ohm. bias-disable will disable the pull.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/3] phy: rockchip-usb: Add vbus regulator support.
From: Kishon Vijay Abraham I @ 2017-04-06 10:37 UTC (permalink / raw)
To: Sjoerd Simons, John Youn, Heiko Stuebner
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Randy Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170405140613.4444-2-sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
On Wednesday 05 April 2017 07:36 PM, Sjoerd Simons wrote:
> On rockchip devices vbus is supplied by a separate power supply, often
> through a regulator. Add support for describing the the regulator in
> device-tree following the same convention as several other usb phy's.
>
merged, thanks.
-Kishon
> Signed-off-by: Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> ---
>
> .../devicetree/bindings/phy/rockchip-usb-phy.txt | 1 +
> drivers/phy/phy-rockchip-usb.c | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
> index 57dc388e2fa2..4ed569046daf 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
> @@ -30,6 +30,7 @@ Optional Properties:
> - reset-names: Only allow the following entries:
> - phy-reset
> - resets: Must contain an entry for each entry in reset-names.
> +- vbus-supply: power-supply phandle for vbus power source
>
> Example:
>
> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
> index 734987fa0ad7..3378eeb7a562 100644
> --- a/drivers/phy/phy-rockchip-usb.c
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -66,6 +66,7 @@ struct rockchip_usb_phy {
> struct phy *phy;
> bool uart_enabled;
> struct reset_control *reset;
> + struct regulator *vbus;
> };
>
> static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
> @@ -88,6 +89,9 @@ static void rockchip_usb_phy480m_disable(struct clk_hw *hw)
> struct rockchip_usb_phy,
> clk480m_hw);
>
> + if (phy->vbus)
> + regulator_disable(phy->vbus);
> +
> /* Power down usb phy analog blocks by set siddq 1 */
> rockchip_usb_phy_power(phy, 1);
> }
> @@ -143,6 +147,14 @@ static int rockchip_usb_phy_power_on(struct phy *_phy)
> if (phy->uart_enabled)
> return -EBUSY;
>
> + if (phy->vbus) {
> + int ret;
> +
> + ret = regulator_enable(phy->vbus);
> + if (ret)
> + return ret;
> + }
> +
> return clk_prepare_enable(phy->clk480m);
> }
>
> @@ -268,6 +280,13 @@ static int rockchip_usb_phy_init(struct rockchip_usb_phy_base *base,
> }
> phy_set_drvdata(rk_phy->phy, rk_phy);
>
> + rk_phy->vbus = devm_regulator_get_optional(&rk_phy->phy->dev, "vbus");
> + if (IS_ERR(rk_phy->vbus)) {
> + if (PTR_ERR(rk_phy->vbus) == -EPROBE_DEFER)
> + return PTR_ERR(rk_phy->vbus);
> + rk_phy->vbus = NULL;
> + }
> +
> /*
> * When acting as uart-pipe, just keep clock on otherwise
> * only power up usb phy when it use, so disable it when init
>
^ permalink raw reply
* Re: [PATCH v5 1/9] phy: phy-mt65xx-usb3: improve RX detection stable time
From: Chunfeng Yun @ 2017-04-06 10:49 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Matthias Brugger, Felipe Balbi, Rob Herring, Mark Rutland,
Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <de1b9870-d325-e97a-a2f0-bd355c70356c-l0cyMroinI0@public.gmane.org>
On Thu, 2017-04-06 at 15:58 +0530, Kishon Vijay Abraham I wrote:
>
> On Friday 31 March 2017 01:05 PM, Chunfeng Yun wrote:
> > The default value of RX detection stable time is 10us, and this
> > margin is too big for some critical cases which cause U3 link fail
> > and link to U2(probability is about 1%). So change it to 5us.
> >
> merged all the phy patches in this series to linux-phy -next.
Thanks a lot
>
> Thanks
> Kishon
>
> > Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/phy/phy-mt65xx-usb3.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> > index d972067..fe2392a 100644
> > --- a/drivers/phy/phy-mt65xx-usb3.c
> > +++ b/drivers/phy/phy-mt65xx-usb3.c
> > @@ -112,6 +112,14 @@
> > #define P3D_RG_CDR_BIR_LTD0 GENMASK(12, 8)
> > #define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8)
> >
> > +#define U3P_U3_PHYD_RXDET1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x128)
> > +#define P3D_RG_RXDET_STB2_SET GENMASK(17, 9)
> > +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9)
> > +
> > +#define U3P_U3_PHYD_RXDET2 (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c)
> > +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0)
> > +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x) (0x1ff & (x))
> > +
> > #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018)
> > #define XC3_RG_U3_XTAL_RX_PWD BIT(9)
> > #define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8)
> > @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
> > tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3);
> > writel(tmp, port_base + U3P_PHYD_CDR1);
> >
> > + tmp = readl(port_base + U3P_U3_PHYD_RXDET1);
> > + tmp &= ~P3D_RG_RXDET_STB2_SET;
> > + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10);
> > + writel(tmp, port_base + U3P_U3_PHYD_RXDET1);
> > +
> > + tmp = readl(port_base + U3P_U3_PHYD_RXDET2);
> > + tmp &= ~P3D_RG_RXDET_STB2_SET_P3;
> > + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10);
> > + writel(tmp, port_base + U3P_U3_PHYD_RXDET2);
> > +
> > dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
> > }
> >
> >
--
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 07/16] regulator: madera-micsupp: Mic supply for Cirrus Logic Madera codecs
From: Mark Brown @ 2017-04-06 10:57 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: gnurou, alsa-devel, jason, devicetree, linus.walleij, patches,
linux-kernel, linux-gpio, robh+dt, tglx, lee.jones
In-Reply-To: <1491400437.4096.5.camel@rf-debian.wolfsonmicro.main>
[-- Attachment #1.1: Type: text/plain, Size: 650 bytes --]
On Wed, Apr 05, 2017 at 02:53:57PM +0100, Richard Fitzgerald wrote:
> On Wed, 2017-04-05 at 14:40 +0100, Mark Brown wrote:
> > Again, this appears to have only data and minor code style changes
> > relative to the existing arizona driver - is there no opportunity for
> > code sharing here?
> I'll have a look at how it would work out.
> My thought was that these two regulator drivers are so small it wasn't
> worth creating an entanglement between arizona and madera for so little
> code.
It's a fairly small amount of code but it's an extremely high proportion
of the code in the driver and doing something a bit unusual, not just
boilerplate.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask
From: Sricharan R @ 2017-04-06 11:01 UTC (permalink / raw)
To: Frank Rowand, robin.murphy, will.deacon, joro, lorenzo.pieralisi,
iommu, linux-arm-kernel, linux-arm-msm, m.szyprowski, bhelgaas,
linux-pci, linux-acpi, tn, hanjun.guo, okaya, robh+dt, devicetree,
linux-kernel, sudeep.holla, rjw, lenb, catalin.marinas, arnd,
linux-arch, gregkh
In-Reply-To: <58E5E7B7.1050400@gmail.com>
Hi Frank,
On 4/6/2017 12:31 PM, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> Size of the dma-range is calculated as coherent_dma_mask + 1
>> and passed to arch_setup_dma_ops further. It overflows when
>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF,
>> resulting in size getting passed as 0 wrongly. Fix this by
>> passsing in max(mask, mask + 1). Note that in this case
>> when the mask is set to full 64bits, we will be passing the mask
>> itself to arch_setup_dma_ops instead of the size. The real fix
>> for this should be to make arch_setup_dma_ops receive the
>> mask and handle it, to be done in the future.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/of/device.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index c17c19d..c2ae6bb 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>> if (ret < 0) {
>> dma_addr = offset = 0;
>> - size = dev->coherent_dma_mask + 1;
>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>> } else {
>> offset = PFN_DOWN(paddr - dma_addr);
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>
>
> NACK.
>
> Passing an invalid size to arch_setup_dma_ops() is only part of the problem.
> size is also used in of_dma_configure() before calling arch_setup_dma_ops():
>
> dev->coherent_dma_mask = min(dev->coherent_dma_mask,
> DMA_BIT_MASK(ilog2(dma_addr + size)));
> *dev->dma_mask = min((*dev->dma_mask),
> DMA_BIT_MASK(ilog2(dma_addr + size)));
>
> which would be incorrect for size == 0xffffffffffffffffULL when
> dma_addr != 0. So the proposed fix really is not papering over
> the base problem very well.
>
Ok, but with your fix for of_dma_get_range and the above fix,
dma_addr will be '0' when size = 0xffffffffffffffffULL,
but DMA_BIT_MASK(ilog2(dma_addr + size)) would be wrong though,
making coherent_dma_mask to be smaller 0x7fffffffffffffffULL.
Regards,
Sricharan
> I agree that the proper solution involves passing a mask instead
> of a size to arch_setup_dma_ops().
>
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v4 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Michael Hennerich @ 2017-04-06 11:31 UTC (permalink / raw)
To: Peter Rosin, wsa, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel
In-Reply-To: <a5127934-863a-64d6-88e6-b8119035baf9@axentia.se>
On 06.04.2017 10:39, Peter Rosin wrote:
> Hi Michael,
>
> I would still like to hear from someone with more gpio experience.
I'll ping Linus.
>
> Anyway, from my point of view, there's just a few minor things left,
> with comments inline as usual.
>
> Thanks for you patience!
Thanks for review.
>
> Cheers,
> peda
>
> On 2017-04-05 15:07, michael.hennerich@analog.com wrote:
>> From: Michael Hennerich <michael.hennerich@analog.com>
>>
>> This patch adds support for the Analog Devices / Linear Technology
>> LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
>> The LTC4306 optionally provides two general purpose input/output pins
>> (GPIOs) that can be configured as logic inputs, opendrain outputs or
>> push-pull outputs via the generic GPIOLIB framework.
>>
>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>>
>> ---
>>
>> Changes since v1:
>>
>> - Sort makefile entries
>> - Sort driver includes
>> - Use proper defines
>> - Miscellaneous coding style fixups
>> - Rename mux select callback
>> - Revise i2c-mux-idle-disconnect handling
>> - Add ENABLE GPIO handling on error and device removal.
>> - Remove surplus of_match_device call.
>>
>> Changes since v2:
>>
>> - Stop double error reporting (i2c_mux_add_adapter)
>> - Change subject
>> - Split dt bindings to separate patch
>>
>> Changes since v3:
>>
>> - Change subject and add spaces
>> - Convert to I2C_MUX_LOCKED
>> - Convert to regmap
>> - Remove local register cache
>> - Restore previous ENABLE GPIO handling
>> - Initially pulse ENABLE low
>> - Eliminate i2c client struct in driver state structure
>> - Simplify error return path
>> - Misc minor cleanups
>> ---
>> MAINTAINERS | 8 +
>> drivers/i2c/muxes/Kconfig | 11 ++
>> drivers/i2c/muxes/Makefile | 1 +
>> drivers/i2c/muxes/i2c-mux-ltc4306.c | 310 ++++++++++++++++++++++++++++++++++++
>> 4 files changed, 330 insertions(+)
>> create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index c776906..9a27a19 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7698,6 +7698,14 @@ S: Maintained
>> F: Documentation/hwmon/ltc4261
>> F: drivers/hwmon/ltc4261.c
>>
>> +LTC4306 I2C MULTIPLEXER DRIVER
>> +M: Michael Hennerich <michael.hennerich@analog.com>
>> +W: http://ez.analog.com/community/linux-device-drivers
>> +L: linux-i2c@vger.kernel.org
>> +S: Supported
>> +F: drivers/i2c/muxes/i2c-mux-ltc4306.c
>> +F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
>> +
>> LTP (Linux Test Project)
>> M: Mike Frysinger <vapier@gentoo.org>
>> M: Cyril Hrubis <chrubis@suse.cz>
>> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
>> index 10b3d17..41153b4 100644
>> --- a/drivers/i2c/muxes/Kconfig
>> +++ b/drivers/i2c/muxes/Kconfig
>> @@ -30,6 +30,17 @@ config I2C_MUX_GPIO
>> This driver can also be built as a module. If so, the module
>> will be called i2c-mux-gpio.
>>
>> +config I2C_MUX_LTC4306
>> + tristate "LTC LTC4306/5 I2C multiplexer"
>> + select GPIOLIB
>> + select REGMAP_I2C
>> + help
>> + If you say yes here you get support for the LTC LTC4306 or LTC4305
>
> This reads a bit funny, and I think you should just spell out the
> first LTC? But perhaps not in the tristate above though, depending
> on how long it gets?
Ok - I rename LTC -> Analog Devices
>
>> + I2C mux/switch devices.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called i2c-mux-ltc4306.
>> +
>> config I2C_MUX_PCA9541
>> tristate "NXP PCA9541 I2C Master Selector"
>> help
>> diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
>> index 9948fa4..ff7618c 100644
>> --- a/drivers/i2c/muxes/Makefile
>> +++ b/drivers/i2c/muxes/Makefile
>> @@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o
>> obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
>>
>> obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
>> +obj-$(CONFIG_I2C_MUX_LTC4306) += i2c-mux-ltc4306.o
>> obj-$(CONFIG_I2C_MUX_MLXCPLD) += i2c-mux-mlxcpld.o
>> obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
>> obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
>> diff --git a/drivers/i2c/muxes/i2c-mux-ltc4306.c b/drivers/i2c/muxes/i2c-mux-ltc4306.c
>> new file mode 100644
>> index 0000000..7d34434
>> --- /dev/null
>> +++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
>> @@ -0,0 +1,310 @@
>> +/*
>> + * Linear Technology LTC4306 and LTC4305 I2C multiplexer/switch
>> + *
>> + * Copyright (C) 2017 Analog Devices Inc.
>> + *
>> + * Licensed under the GPL-2.
>> + *
>> + * Based on: i2c-mux-pca954x.c
>> + *
>> + * Datasheet: http://cds.linear.com/docs/en/datasheet/4306.pdf
>> + */
>> +
>> +#include <linux/device.h>
>> +#include <linux/gpio.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/gpio/driver.h>
>> +#include <linux/i2c-mux.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +
>> +#define LTC4305_MAX_NCHANS 2
>> +#define LTC4306_MAX_NCHANS 4
>> +
>> +#define LTC_REG_STATUS 0x0
>> +#define LTC_REG_CONFIG 0x1
>> +#define LTC_REG_MODE 0x2
>> +#define LTC_REG_SWITCH 0x3
>> +
>> +#define LTC_DOWNSTREAM_ACCL_EN BIT(6)
>> +#define LTC_UPSTREAM_ACCL_EN BIT(7)
>> +
>> +#define LTC_GPIO_ALL_INPUT 0xC0
>> +#define LTC_SWITCH_MASK 0xF0
>> +
>> +enum ltc_type {
>> + ltc_4305,
>> + ltc_4306,
>> +};
>> +
>> +struct chip_desc {
>> + u8 nchans;
>> + u8 num_gpios;
>> +};
>> +
>> +struct ltc4306 {
>> + struct regmap *regmap;
>> + struct gpio_chip gpiochip;
>> + const struct chip_desc *chip;
>> +};
>> +
>> +static const struct chip_desc chips[] = {
>> + [ltc_4305] = {
>> + .nchans = LTC4305_MAX_NCHANS,
>> + },
>> + [ltc_4306] = {
>> + .nchans = LTC4306_MAX_NCHANS,
>> + .num_gpios = 2,
>> + },
>> +};
>> +
>> +static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg)
>> +{
>> + return (reg == LTC_REG_CONFIG) ? true : false;
>> +}
>> +
>> +static const struct regmap_config ltc4306_regmap_config = {
>> + .reg_bits = 8,
>> + .val_bits = 8,
>> + .max_register = LTC_REG_SWITCH,
>> + .volatile_reg = ltc4306_is_volatile_reg,
>> + .cache_type = REGCACHE_RBTREE,
>
> Did you consider REGCACHE_FLAT? There are very few registers and no hole
> in the map, and maintaining a tree seems like total overkill.
There is no reason to use REGCACHE_FLAT, in our case it will be a single
node.
>
>> +};
>> +
>> +static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> + unsigned int val;
>> + int ret;
>> +
>> + ret = regmap_read(data->regmap, LTC_REG_CONFIG, &val);
>> + if (ret < 0)
>> + return ret;
>> +
>> + return (val & BIT(1 - offset));
>
> The outer parentheses do not add anything, and I think they might remain
> from when you just removed a double negation at some point. But is it
> good practice to indicate "high" with anything other than one? Sure, the
> gpiolib function that wraps the ->get() op does the !! dance for you,
> but even so, every single one of the half dozen random gpio providers I
> looked at had code to coerce the value to 0/1 (or error). Which makes me
> think you should also have it. And the gpio_chip documentation on ->get()
> agrees with me...
I'll restore the double negations.
>
>> +}
>> +
>> +static void ltc4306_gpio_set(struct gpio_chip *chip, unsigned int offset,
>> + int value)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + regmap_update_bits(data->regmap, LTC_REG_CONFIG, BIT(5 - offset),
>> + value ? BIT(5 - offset) : 0);
>> +}
>> +
>> +static int ltc4306_gpio_direction_input(struct gpio_chip *chip,
>> + unsigned int offset)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
>> + BIT(7 - offset), BIT(7 - offset));
>> +}
>> +
>> +static int ltc4306_gpio_direction_output(struct gpio_chip *chip,
>> + unsigned int offset, int value)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + ltc4306_gpio_set(chip, offset, value);
>> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
>> + BIT(7 - offset), 0);
>> +}
>> +
>> +static int ltc4306_gpio_set_config(struct gpio_chip *chip,
>> + unsigned int offset, unsigned long config)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> + unsigned int val;
>> +
>> + switch (pinconf_to_config_param(config)) {
>> + case PIN_CONFIG_DRIVE_OPEN_DRAIN:
>> + val = 0;
>> + break;
>> + case PIN_CONFIG_DRIVE_PUSH_PULL:
>> + val = BIT(4 - offset);
>> + break;
>> + default:
>> + return -ENOTSUPP;
>> + }
>> +
>> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
>> + BIT(4 - offset), val);
>> +}
>> +
>> +static int ltc4306_gpio_init(struct ltc4306 *data)
>> +{
>> + struct device *dev = regmap_get_device(data->regmap);
>> +
>> + if (!data->chip->num_gpios)
>> + return 0;
>> +
>> + data->gpiochip.label = dev_name(dev);
>> + data->gpiochip.base = -1;
>> + data->gpiochip.ngpio = data->chip->num_gpios;
>> + data->gpiochip.parent = dev;
>> + data->gpiochip.can_sleep = true;
>> + data->gpiochip.direction_input = ltc4306_gpio_direction_input;
>> + data->gpiochip.direction_output = ltc4306_gpio_direction_output;
>
> I'm missing a get_direction op?
No - its purely optional - the vast majority of gpiochips don't
implement it.
linux/drivers/gpio$ grep -lr --include \*.c get_direction | wc
36 36 523
linux/drivers/gpio$ grep -Lr --include \*.c get_direction | wc
101 101 1461
>
>> + data->gpiochip.get = ltc4306_gpio_get;
>> + data->gpiochip.set = ltc4306_gpio_set;
>> + data->gpiochip.set_config = ltc4306_gpio_set_config;
>> + data->gpiochip.owner = THIS_MODULE;
>> +
>> + /* gpiolib assumes all GPIOs default input */
>> + regmap_write(data->regmap, LTC_REG_MODE, LTC_GPIO_ALL_INPUT);
>> +
>> + return devm_gpiochip_add_data(dev, &data->gpiochip, data);
>> +}
>> +
>> +static int ltc4306_select_mux(struct i2c_mux_core *muxc, u32 chan)
>> +{
>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>> +
>> + return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
>> + LTC_SWITCH_MASK, BIT(7 - chan));
>
> Since the bits outside the mask are ignored for writes, I'd go with
> regmap_write. Especially since those bits are volatile, which admittedly
> will not have much impact until there is a need to read those volatile
> bits outside the mask. But still.
Yes they are volatile - but not declared as such.
So regmap cache just ignores them.
And we totally ignore these RONLY status bits, too.
regmap_write() will always write and ignore the cache, while
regmap_update_bits() uses the cached value.
Are these callbacks guaranteed to be never called with the same CHAN
sequentially? if yes - use regmap_write() otherwise its more efficient
to use regmap_update_bits().
>
>> +}
>> +
>> +static int ltc4306_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
>> +{
>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>> +
>> + return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
>> + LTC_SWITCH_MASK, 0);
>
> Dito.
>
>> +}
>> +
>> +static const struct i2c_device_id ltc4306_id[] = {
>> + { "ltc4305", ltc_4305 },
>> + { "ltc4306", ltc_4306 },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, ltc4306_id);
>> +
>> +static const struct of_device_id ltc4306_of_match[] = {
>> + { .compatible = "lltc,ltc4305", .data = &chips[ltc_4305] },
>> + { .compatible = "lltc,ltc4306", .data = &chips[ltc_4306] },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, ltc4306_of_match);
>> +
>> +static int ltc4306_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
>> + struct device_node *of_node = client->dev.of_node;
>> + struct i2c_mux_core *muxc;
>> + struct ltc4306 *data;
>> + struct gpio_desc *gpio;
>> + bool idle_disc = false;
>> + int num, ret;
>> +
>> + if (of_node)
>> + idle_disc = of_property_read_bool(of_node,
>> + "i2c-mux-idle-disconnect");
>> +
>> + muxc = i2c_mux_alloc(adap, &client->dev,
>> + LTC4306_MAX_NCHANS, sizeof(*data),
>
> Hmmm, I didn't see this before, but if you do some more rearranging, it
> should be possible to replace LTC4306_MAX_NCHANS with data->chip->nchans
> and reduce resource waste for ltc4305. But it's just storage for two
> pointers which is really really minor... Feel free to ignore.
>
> But you want to set a good example, right :-)
>
>> + I2C_MUX_LOCKED, ltc4306_select_mux,
>> + idle_disc ? ltc4306_deselect_mux : NULL);
>> + if (!muxc)
>> + return -ENOMEM;
>> + data = i2c_mux_priv(muxc);
>> +
>> + i2c_set_clientdata(client, muxc);
>> +
>> + data->regmap = devm_regmap_init_i2c(client, <c4306_regmap_config);
>> + if (IS_ERR(data->regmap)) {
>> + ret = PTR_ERR(data->regmap);
>> + dev_err(&client->dev, "Failed to allocate register map: %d\n",
>> + ret);
>> + return ret;
>> + }
>> +
>> + /* Reset and enable the mux if an enable GPIO is specified. */
>> + gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_LOW);
>> + if (IS_ERR(gpio))
>> + return PTR_ERR(gpio);
>> +
>> + if (gpio) {
>> + udelay(1);
>> + gpiod_set_value(gpio, 1);
>> + }
>> +
>> + /*
>> + * Write the mux register at addr to verify
>> + * that the mux is in fact present. This also
>> + * initializes the mux to disconnected state.
>> + */
>> + if (regmap_write(data->regmap, LTC_REG_SWITCH, 0) < 0) {
>> + dev_warn(&client->dev, "probe failed\n");
>> + return -ENODEV;
>> + }
>> +
>> + if (of_node) {
>> + unsigned int val = 0;
>> +
>> + data->chip = of_device_get_match_data(&client->dev);
>> +
>> + if (of_property_read_bool(of_node,
>> + "ltc,downstream-accelerators-enable"))
>> + val |= LTC_DOWNSTREAM_ACCL_EN;
>> +
>> + if (of_property_read_bool(of_node,
>> + "ltc,upstream-accelerators-enable"))
>> + val |= LTC_UPSTREAM_ACCL_EN;
>> +
>> + if (regmap_write(data->regmap, LTC_REG_CONFIG, val) < 0)
>> + return -ENODEV;
>> + } else {
>> + data->chip = &chips[id->driver_data];
>> + }
>> +
>> + ret = ltc4306_gpio_init(data);
>> + if (ret < 0)
>> + return ret;
>> +
>> + /* Now create an adapter for each channel */
>> + for (num = 0; num < data->chip->nchans; num++) {
>> + ret = i2c_mux_add_adapter(muxc, 0, num, 0);
>> + if (ret) {
>> + i2c_mux_del_adapters(muxc);
>> + return ret;
>> + }
>> + }
>> +
>> + dev_info(&client->dev,
>> + "registered %d multiplexed busses for I2C switch %s\n",
>> + num, client->name);
>> +
>> + return 0;
>> +}
>> +
>> +static int ltc4306_remove(struct i2c_client *client)
>> +{
>> + struct i2c_mux_core *muxc = i2c_get_clientdata(client);
>> +
>> + i2c_mux_del_adapters(muxc);
>> +
>> + return 0;
>> +}
>> +
>> +static struct i2c_driver ltc4306_driver = {
>> + .driver = {
>> + .name = "ltc4306",
>> + .of_match_table = of_match_ptr(ltc4306_of_match),
>> + },
>> + .probe = ltc4306_probe,
>> + .remove = ltc4306_remove,
>> + .id_table = ltc4306_id,
>> +};
>> +
>> +module_i2c_driver(ltc4306_driver);
>> +
>> +MODULE_AUTHOR("Michael Hennerich <michael.hennerich@analog.com>");
>> +MODULE_DESCRIPTION("Linear Technology LTC4306, LTC4305 I2C mux/switch driver");
>> +MODULE_LICENSE("GPL v2");
>>
>
>
--
Greetings,
Michael
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
^ permalink raw reply
* Re: [RESEND PATCH V7 1/5] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
From: Guenter Roeck @ 2017-04-06 11:32 UTC (permalink / raw)
To: Steve Twiss, DEVICETREE, LINUX-KERNEL, LINUX-WATCHDOG,
Mark Rutland, Rob Herring, Wim Van Sebroeck
Cc: Dmitry Torokhov, Eduardo Valentin, LINUX-INPUT, LINUX-PM,
Lee Jones, Liam Girdwood, Mark Brown, Support Opensource,
Zhang Rui
In-Reply-To: <1d280a35fc522f7b271c730988ab0f186fef25ba.1491467308.git.stwiss.opensource@diasemi.com>
On 04/06/2017 01:28 AM, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Add binding information for DA9062 and DA9061 watchdog.
>
> Example bindings for both DA9062 and DA9061 devices are added. For
> the DA9061 device, a fallback compatible line is added as a valid
> combination of compatible strings.
>
> The original binding for DA9062 (only) used to reside inside the
> Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
> The da9062-watchdog section was deleted in that file and replaced
> with a link to the new DA9061/62 binding information stored in this
> patch.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> ---
>
> Hi,
>
> I have just noticed.
>
> The driver code changes for the da9062/61 watchdog have been applied to
> the linux kernel. The da9062/61 alterations for
> drivers/watchdog/da9062_wdt.c appear in linux-stable/v4.10-rc1. Those
> changes are linked to this binding patch, but this patch seems to have
> been missed out.
>
> The source code dependency for this patch is given in the commit:
> 72106c1 v4.10-rc1 watchdog: da9062/61: watchdog driver
>
> I don't see anything blocking for merge of this patch now.
>
> Regards,
> Steve
>
> This patch applies against linux-next and v4.11-rc3
>
> v6 -> v7
> - NO CODE CHANGE
>
> v5 -> v6
> - NO CODE CHANGE
> - Rebased from v4.9 to v4.11-rc3
>
> v4 -> v5
> - NO CODE CHANGE
> - Rebased from v4.8 to v4.9
>
> v3 -> v4
> - NO CODE CHANGE
> - Patch renamed from [PATCH V3 2/9] to [PATCH V4 1/8]
> - Added Acked-by Rob Herring
>
> v2 -> v3
> - Patch renamed from [PATCH V1 02/10] to [PATCH V3 2/9]
> - Each compatible line should be a valid combination of compatible
> strings, alter DA9061 line to include the fall back compatible string
> - Update the commit message to describe this change
> - Add information about associated patches from this set without
> describing them as being explicitly dependent on this binding
>
> v1 -> v2
> - Patch renamed from [PATCH V1 07/10] to [PATCH V2 02/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
> - Updated the patch description to be explicit about where parts of
> this binding had originally been stored
> - A second example for DA9061 is provided to highlight the use of a
> fall-back compatible option for the DA9062 watchdog driver
>
> As previously:
>
> For the watchdog case: the DA9062 device driver is compatible with the
> DA9061 and for this reason there is minimal change required to the DA9062
> watchdog device driver. The example for the DA9061 watchdog shows the
> use of a fall-back compatible string.
>
> Other information:
> The device driver from this patch set (associated with this binding) is
> [PATCH V5 6/8] watchdog: da9061: watchdog driver
>
> Regards,
> Steve Twiss, Dialog Semiconductor
>
>
> .../devicetree/bindings/watchdog/da9062-wdt.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> new file mode 100644
> index 0000000..b935b52
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> @@ -0,0 +1,23 @@
> +* Dialog Semiconductor DA9062/61 Watchdog Timer
> +
> +Required properties:
> +
> +- compatible: should be one of the following valid compatible string lines:
> + "dlg,da9061-watchdog", "dlg,da9062-watchdog"
> + "dlg,da9062-watchdog"
> +
> +Example: DA9062
> +
> + pmic0: da9062@58 {
> + watchdog {
> + compatible = "dlg,da9062-watchdog";
> + };
> + };
> +
> +Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
> +
> + pmic0: da9061@58 {
> + watchdog {
> + compatible = "dlg,da9061-watchdog", "dlg,da9062-watchdog";
> + };
> + };
>
^ permalink raw reply
* Re: [PATCH v3 00/12] Add Basic SoC support for MT6797
From: Mars Cheng @ 2017-04-06 12:11 UTC (permalink / raw)
To: Matthias Brugger
Cc: Rob Herring, Marc Zyngier, Michael Turquette, Stephen Boyd,
CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
My Chuang, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
wsd_upstream-NuS5LvNUpcJWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490229971.25996.2.camel@mtkswgap22>
Hi Matthias, Stephen
Would you like to give some comments for this patch set?
If there are any suggestions, I will try my best to fix the errors.
Thanks.
On Thu, 2017-03-23 at 08:46 +0800, Mars Cheng wrote:
> Hi Matthias, Rob, Marc, Stephen
>
> gentle ping for this patch set.
>
> Thanks.
>
> On Sun, 2017-03-19 at 23:26 +0800, Mars Cheng wrote:
> > This patch set adds basic SoC support for mediatek's first 10-core
> > chip, X20, also known as MT6797.
> >
> > - based on 4.11-rc1
> > - support multiple base address for sysirq
> > - support common clk framework
> >
> > Changes since v2:
> > - prevent uncessary #intpol-bases for mtk-sysirq
> > - add fast path for mtk-sysirq set_type when introducing multiple bases
> > - add acked-by and tested-by
> > - remove wrong usage for timer node
> >
> > Changes since v1:
> > - add multiple base addresses support, v1 only allow 2 bases
> > - clean up clk driver
> >
> >
> > Kevin-CW Chen (2):
> > dt-bindings: arm: mediatek: document clk bindings for MT6797
> > clk: mediatek: add clk support for MT6797
> >
> > Mars Cheng (10):
> > dt-bindings: mediatek: multiple bases support for sysirq
> > irqchip: mtk-sysirq: extend intpol base to arbitrary number
> > irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
> > dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform
> > arm64: dts: mediatek: add mt6797 support
> > soc: mediatek: avoid using fixed spm power status defines
> > soc: mediatek: add vdec item for scpsys
> > dt-bindings: mediatek: add MT6797 power dt-bindings
> > soc: mediatek: add MT6797 scysys support
> > arm64: dts: mediatek: add clk and scp nodes for MT6797
> >
> > Documentation/devicetree/bindings/arm/mediatek.txt | 4 +
> > .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,imgsys.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,infracfg.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,mmsys.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,topckgen.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,vdecsys.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,vencsys.txt | 3 +-
> > .../interrupt-controller/mediatek,sysirq.txt | 12 +-
> > .../devicetree/bindings/serial/mtk-uart.txt | 1 +
> > .../devicetree/bindings/soc/mediatek/scpsys.txt | 6 +-
> > arch/arm64/boot/dts/mediatek/Makefile | 1 +
> > arch/arm64/boot/dts/mediatek/mt6797-evb.dts | 36 +
> > arch/arm64/boot/dts/mediatek/mt6797.dtsi | 245 +++++++
> > drivers/clk/mediatek/Kconfig | 32 +
> > drivers/clk/mediatek/Makefile | 5 +
> > drivers/clk/mediatek/clk-mt6797-img.c | 76 +++
> > drivers/clk/mediatek/clk-mt6797-mm.c | 136 ++++
> > drivers/clk/mediatek/clk-mt6797-vdec.c | 93 +++
> > drivers/clk/mediatek/clk-mt6797-venc.c | 78 +++
> > drivers/clk/mediatek/clk-mt6797.c | 716 ++++++++++++++++++++
> > drivers/irqchip/irq-mtk-sysirq.c | 116 +++-
> > drivers/soc/mediatek/mtk-scpsys.c | 149 +++-
> > include/dt-bindings/clock/mt6797-clk.h | 281 ++++++++
> > include/dt-bindings/power/mt6797-power.h | 30 +
> > 25 files changed, 1993 insertions(+), 33 deletions(-)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-evb.dts
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6797.dtsi
> > create mode 100644 drivers/clk/mediatek/clk-mt6797-img.c
> > create mode 100644 drivers/clk/mediatek/clk-mt6797-mm.c
> > create mode 100644 drivers/clk/mediatek/clk-mt6797-vdec.c
> > create mode 100644 drivers/clk/mediatek/clk-mt6797-venc.c
> > create mode 100644 drivers/clk/mediatek/clk-mt6797.c
> > create mode 100644 include/dt-bindings/clock/mt6797-clk.h
> > create mode 100644 include/dt-bindings/power/mt6797-power.h
> >
> > --
> > 1.7.9.5
> >
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3
From: Lee Jones @ 2017-04-06 12:11 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Zhang Rui, linux-sunxi,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Quentin Schulz, Maxime Ripard,
Jonathan Cameron,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai
In-Reply-To: <20170406095534.299945C355D-Y9/x5g2N/Tt0ykcd9G8QkxTxI0vvWBSX@public.gmane.org>
On Thu, 06 Apr 2017, Icenowy Zheng wrote:
> 2017年4月6日 03:04于 Rob Herring <robh@kernel.org>写道：
> > On Tue, Apr 4, 2017 at 10:02 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> > > 在 2017年04月04日 22:47, Rob Herring 写道:
> OK. I will make it :
> ths: temperature-sensor@1c25000
Can you fix your broken email client please? You need to set it up to
reply to mails to they stay threaded. Your mailer is currently
sending all of your replies as their own, independent messages.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
* Re: [PATCH V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets
From: Vivek Gautam @ 2017-04-06 12:17 UTC (permalink / raw)
To: Kishon Vijay Abraham I, robh+dt
Cc: linux-arm-kernel, linux-arm-msm, linux-kernel, linux-usb,
devicetree, mark.rutland, sboyd, bjorn.andersson,
srinivas.kandagatla
In-Reply-To: <9f928f13-3bee-6f36-6760-095da5a03495@ti.com>
On 04/06/2017 03:41 PM, Kishon Vijay Abraham I wrote:
>
> On Thursday 06 April 2017 11:21 AM, Vivek Gautam wrote:
>> Hi Kishon,
>> Here's the series with fixed checkpatch warnings/checks.
>> Please pick it for phy/next.
>>
>> This patch series adds couple of PHY drivers for Qualcomm chipsets.
>> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
>> b) qcom-qmp phy driver: that is a combo phy providing support for
>> USB3, PCIe, UFS and few other controllers.
>>
>> The patches are based on next branch of linux-phy tree.
>>
>> These patches have been tested on Dragon board db820c hardware with
>> required set of dt patches.
>> The tested branch[3] is based on torvald's master with greg's usb/usb-next
>> merged. Additionally the patches to get rpm up on msm8996 are also pulled
>> in.
> merged, thanks!
Thanks Kishon.
BRs
Vivek
>
> -Kishon
>> Changes since v7:
>> - Fixed 'checkpatch --strict' alignment warnings/checks, and
>> added Stephen's Reviewed-by tag.
>>
>> Changes since v6:
>> - Rebased on phy/next and *not* including phy grouping series[4].
>> - qusb2-phy: addressed Stephen's comment.
>> - Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
>> - qmp-phy: none on functionality side.
>>
>> Changes since v5:
>> - Addressed review comments from Bjorn:
>> - Removed instances of readl/wirtel_relaxed calls from the drivers.
>> Instead, using simple readl/writel. Inserting a readl after a writel
>> to ensure the write is through to the device.
>> - Replaced regulator handling with regulator_bulk_** apis. This helps
>> in cutting down a lot of regulator handling code.
>> - Fixed minor return statements.
>>
>> Changes since v4:
>> - Addressed comment to add child nodes for qmp phy driver. Each phy lane
>> now has a separate child node under the main qmp node.
>> - Modified the clock and reset initialization and enable methods.
>> Different phys - pcie, usb and later ufs, have varying number of clocks
>> and resets that are mandatory. So adding provision for clocks and reset
>> lists helps in requesting all mandatory resources for individual phys
>> and handle their failure cases accordingly.
>>
>> Changes since v3:
>> - Addressed review comments given by Rob and Stephen for qusb2 phy
>> and qmp phy bindings respectively.
>> - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
>>
>> Changes since v2:
>> - Addressed review comments given by Rob and Stephen for bindings.
>> - Addressed the review comments given by Stephen for the qusb2 and qmp
>> phy drivers.
>>
>> Changes since v1:
>> - Moved device tree binding documentation to separate patches, as suggested
>> by Rob.
>> - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
>> given by Rob.
>> - Addressed review comments from Kishon.
>> - Addressed review comments from Srinivas for QMP phy driver.
>> - Addressed kbuild warning.
>>
>> Please see individual patches for detailed changelogs.
>>
>> [1] https://patchwork.kernel.org/patch/9567767/
>> [2] https://patchwork.kernel.org/patch/9567779/
>> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
>> [4] https://lkml.org/lkml/2017/3/20/407
>>
>> Vivek Gautam (4):
>> dt-bindings: phy: Add support for QUSB2 phy
>> phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
>> dt-bindings: phy: Add support for QMP phy
>> phy: qcom-qmp: new qmp phy driver for qcom-chipsets
>>
>> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 ++
>> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 +
>> drivers/phy/Kconfig | 18 +
>> drivers/phy/Makefile | 2 +
>> drivers/phy/phy-qcom-qmp.c | 1153 ++++++++++++++++++++
>> drivers/phy/phy-qcom-qusb2.c | 493 +++++++++
>> 6 files changed, 1815 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> create mode 100644 drivers/phy/phy-qcom-qmp.c
>> create mode 100644 drivers/phy/phy-qcom-qusb2.c
>>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v5 0/5] STM32 Independent watchdog
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: devicetree, linux-watchdog, Philippe Cornu, linux-kernel,
Gabriel FERNANDEZ, linux-arm-kernel
Version 5:
- Update bindings (add field timeout-sec)
- Update driver (rework start, rework settings & remove max_timeout)
Version 4:
- Update bindings (iwdg > watchdog)
- Update typo
- Update commit header
- remove gerrit tags
- Update driver (remove unnecessary tests) a add watchdog_init_timeout
Version 3:
- Update typo into bindings file
- Reorder node in devicetree (ordering by address)
- Remove unnecessary lines in commits
Version 2:
- Add commit messages
Version 1:
- Initial commit
The purpose of this set of patches is to add a new watchdog driver for
stm32f429.
This driver was developed and tested on evaluation board stm32429i.
Yannick Fertre (5):
dt-bindings: watchdog: Document STM32 IWDG bindings
drivers: watchdog: Add STM32 IWDG driver
ARM: dts: stm32: Add watchdog support for STM32F429 SoC
ARM: dts: stm32: Add watchdog support for STM32F429 eval board
ARM: configs: stm32: Add watchdog support in STM32 defconfig
.../devicetree/bindings/watchdog/st,stm32-iwdg.txt | 19 ++
arch/arm/boot/dts/stm32429i-eval.dts | 5 +
arch/arm/boot/dts/stm32f429.dtsi | 9 +-
arch/arm/configs/stm32_defconfig | 1 +
drivers/watchdog/Kconfig | 12 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/stm32_iwdg.c | 253 +++++++++++++++++++++
7 files changed, 299 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
create mode 100644 drivers/watchdog/stm32_iwdg.c
--
1.9.1
^ permalink raw reply
* [PATCH v5 1/5] dt-bindings: watchdog: Document STM32 IWDG bindings
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Philippe Cornu,
Gabriel FERNANDEZ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1491481168-22213-1-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>
This adds documentation of device tree bindings for the STM32 IWDG
(Independent WatchDoG).
Signed-off-by: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>
---
.../devicetree/bindings/watchdog/st,stm32-iwdg.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
diff --git a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
new file mode 100644
index 0000000..cc13b10a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
@@ -0,0 +1,19 @@
+STM32 Independent WatchDoG (IWDG)
+---------------------------------
+
+Required properties:
+- compatible: "st,stm32-iwdg"
+- reg: physical base address and length of the registers set for the device
+- clocks: must contain a single entry describing the clock input
+
+Optional Properties:
+- timeout-sec: Watchdog timeout value in seconds.
+
+Example:
+
+iwdg: watchdog@40003000 {
+ compatible = "st,stm32-iwdg";
+ reg = <0x40003000 0x400>;
+ clocks = <&clk_lsi>;
+ timeout-sec = <32>;
+};
--
1.9.1
--
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 related
* [PATCH v5 2/5] drivers: watchdog: Add STM32 IWDG driver
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: devicetree, linux-watchdog, Philippe Cornu, linux-kernel,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1491481168-22213-1-git-send-email-yannick.fertre@st.com>
This patch adds IWDG (Independent WatchDoG) support for STM32 platform.
Signed-off-by: Yannick FERTRE <yannick.fertre@st.com>
---
drivers/watchdog/Kconfig | 12 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/stm32_iwdg.c | 253 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 266 insertions(+)
create mode 100644 drivers/watchdog/stm32_iwdg.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 52a70ee..d014deb 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -744,6 +744,18 @@ config ZX2967_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called zx2967_wdt.
+config STM32_WATCHDOG
+ tristate "STM32 Independent WatchDoG (IWDG) support"
+ depends on ARCH_STM32
+ select WATCHDOG_CORE
+ default y
+ help
+ Say Y here to include support for the watchdog timer
+ in stm32 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stm32_iwdg.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a2126e2..a35e423 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
+obj-$(CONFIG_STM32_WATCHDOG) += stm32_iwdg.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
new file mode 100644
index 0000000..6c501b7
--- /dev/null
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -0,0 +1,253 @@
+/*
+ * Driver for STM32 Independent Watchdog
+ *
+ * Copyright (C) Yannick Fertre 2017
+ * Author: Yannick Fertre <yannick.fertre@st.com>
+ *
+ * This driver is based on tegra_wdt.c
+ *
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/watchdog.h>
+
+/* IWDG registers */
+#define IWDG_KR 0x00 /* Key register */
+#define IWDG_PR 0x04 /* Prescaler Register */
+#define IWDG_RLR 0x08 /* ReLoad Register */
+#define IWDG_SR 0x0C /* Status Register */
+#define IWDG_WINR 0x10 /* Windows Register */
+
+/* IWDG_KR register bit mask */
+#define KR_KEY_RELOAD 0xAAAA /* reload counter enable */
+#define KR_KEY_ENABLE 0xCCCC /* peripheral enable */
+#define KR_KEY_EWA 0x5555 /* write access enable */
+#define KR_KEY_DWA 0x0000 /* write access disable */
+
+/* IWDG_PR register bit values */
+#define PR_4 0x00 /* prescaler set to 4 */
+#define PR_8 0x01 /* prescaler set to 8 */
+#define PR_16 0x02 /* prescaler set to 16 */
+#define PR_32 0x03 /* prescaler set to 32 */
+#define PR_64 0x04 /* prescaler set to 64 */
+#define PR_128 0x05 /* prescaler set to 128 */
+#define PR_256 0x06 /* prescaler set to 256 */
+
+/* IWDG_RLR register values */
+#define RLR_MIN 0x07C /* min value supported by reload register */
+#define RLR_MAX 0xFFF /* max value supported by reload register */
+
+/* IWDG_SR register bit mask */
+#define FLAG_PVU BIT(0) /* Watchdog prescaler value update */
+#define FLAG_RVU BIT(1) /* Watchdog counter reload value update */
+
+/* set timeout to 100000 us */
+#define TIMEOUT_US 100000
+#define SLEEP_US 1000
+
+struct stm32_iwdg {
+ struct watchdog_device wdd;
+ void __iomem *regs;
+ struct clk *clk;
+ unsigned int rate;
+};
+
+static inline u32 reg_read(void __iomem *base, u32 reg)
+{
+ return readl_relaxed(base + reg);
+}
+
+static inline void reg_write(void __iomem *base, u32 reg, u32 val)
+{
+ writel_relaxed(val, base + reg);
+}
+
+static int stm32_iwdg_start(struct watchdog_device *wdd)
+{
+ struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
+ u32 val = FLAG_PVU | FLAG_RVU;
+ u32 reload;
+ int ret;
+
+ dev_dbg(wdd->parent, "%s\n", __func__);
+
+ /* prescaler fixed to 256 */
+ reload = clamp_t(unsigned int, ((wdd->timeout * wdt->rate) / 256) - 1,
+ RLR_MIN, RLR_MAX);
+
+ /* enable write access */
+ reg_write(wdt->regs, IWDG_KR, KR_KEY_EWA);
+
+ /* set prescaler & reload registers */
+ reg_write(wdt->regs, IWDG_PR, PR_256); /* prescaler fix to 256 */
+ reg_write(wdt->regs, IWDG_RLR, reload);
+ reg_write(wdt->regs, IWDG_KR, KR_KEY_ENABLE);
+
+ /* wait for the registers to be updated (max 100ms) */
+ ret = readl_relaxed_poll_timeout(wdt->regs + IWDG_SR, val,
+ !(val & (FLAG_PVU | FLAG_RVU)),
+ SLEEP_US, TIMEOUT_US);
+ if (ret) {
+ dev_err(wdd->parent,
+ "Fail to set prescaler or reload registers\n");
+ return ret;
+ }
+
+ /* reload watchdog */
+ reg_write(wdt->regs, IWDG_KR, KR_KEY_RELOAD);
+
+ return 0;
+}
+
+static int stm32_iwdg_ping(struct watchdog_device *wdd)
+{
+ struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
+
+ dev_dbg(wdd->parent, "%s\n", __func__);
+
+ /* reload watchdog */
+ reg_write(wdt->regs, IWDG_KR, KR_KEY_RELOAD);
+
+ return 0;
+}
+
+static int stm32_iwdg_set_timeout(struct watchdog_device *wdd,
+ unsigned int timeout)
+{
+ dev_dbg(wdd->parent, "%s timeout: %d sec\n", __func__, timeout);
+
+ wdd->timeout = timeout;
+
+ if (watchdog_active(wdd))
+ return stm32_iwdg_start(wdd);
+
+ return 0;
+}
+
+static const struct watchdog_info stm32_iwdg_info = {
+ .options = WDIOF_SETTIMEOUT |
+ WDIOF_MAGICCLOSE |
+ WDIOF_KEEPALIVEPING,
+ .identity = "STM32 Independent Watchdog",
+};
+
+static struct watchdog_ops stm32_iwdg_ops = {
+ .owner = THIS_MODULE,
+ .start = stm32_iwdg_start,
+ .ping = stm32_iwdg_ping,
+ .set_timeout = stm32_iwdg_set_timeout,
+};
+
+static int stm32_iwdg_probe(struct platform_device *pdev)
+{
+ struct watchdog_device *wdd;
+ struct stm32_iwdg *wdt;
+ struct resource *res;
+ void __iomem *regs;
+ struct clk *clk;
+ int ret;
+
+ /* This is the timer base. */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(regs)) {
+ dev_err(&pdev->dev, "Could not get resource\n");
+ return PTR_ERR(regs);
+ }
+
+ clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "Unable to get clock\n");
+ return PTR_ERR(clk);
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Unable to prepare clock %p\n", clk);
+ return ret;
+ }
+
+ /*
+ * Allocate our watchdog driver data, which has the
+ * struct watchdog_device nested within it.
+ */
+ wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
+ if (!wdt) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ /* Initialize struct stm32_iwdg. */
+ wdt->regs = regs;
+ wdt->clk = clk;
+ wdt->rate = clk_get_rate(clk);
+
+ /* Initialize struct watchdog_device. */
+ wdd = &wdt->wdd;
+ wdd->info = &stm32_iwdg_info;
+ wdd->ops = &stm32_iwdg_ops;
+ wdd->min_timeout = ((RLR_MIN + 1) * 256) / wdt->rate;
+ wdd->max_hw_heartbeat_ms = ((RLR_MAX + 1) * 256 * 1000) / wdt->rate;
+ wdd->parent = &pdev->dev;
+
+ watchdog_set_drvdata(wdd, wdt);
+ watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT);
+
+ ret = watchdog_init_timeout(wdd, 0, &pdev->dev);
+ if (ret)
+ dev_warn(&pdev->dev,
+ "unable to set timeout value, using default\n");
+
+ ret = watchdog_register_device(wdd);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register watchdog device\n");
+ goto err;
+ }
+
+ platform_set_drvdata(pdev, wdt);
+
+ return 0;
+err:
+ clk_disable_unprepare(clk);
+
+ return ret;
+}
+
+static int stm32_iwdg_remove(struct platform_device *pdev)
+{
+ struct stm32_iwdg *wdt = platform_get_drvdata(pdev);
+
+ watchdog_unregister_device(&wdt->wdd);
+ clk_disable_unprepare(wdt->clk);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_iwdg_of_match[] = {
+ { .compatible = "st,stm32-iwdg" },
+ { /* end node */ }
+};
+MODULE_DEVICE_TABLE(of, stm32_iwdg_of_match);
+
+static struct platform_driver stm32_iwdg_driver = {
+ .probe = stm32_iwdg_probe,
+ .remove = stm32_iwdg_remove,
+ .driver = {
+ .name = "iwdg",
+ .of_match_table = stm32_iwdg_of_match,
+ },
+};
+module_platform_driver(stm32_iwdg_driver);
+
+MODULE_AUTHOR("Yannick Fertre <yannick.fertre@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32 Independent Watchdog Driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v5 3/5] ARM: dts: stm32: Add watchdog support for STM32F429 SoC
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: devicetree, linux-watchdog, Philippe Cornu, linux-kernel,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1491481168-22213-1-git-send-email-yannick.fertre@st.com>
Add watchdog into DT for stm32f429 family.
Signed-off-by: Yannick FERTRE <yannick.fertre@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 89327d6..d84dd44 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -64,7 +64,7 @@
clock-frequency = <32768>;
};
- clk-lsi {
+ clk_lsi: clk-lsi {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32000>;
@@ -306,6 +306,13 @@
status = "disabled";
};
+ iwdg: watchdog@40003000 {
+ compatible = "st,stm32-iwdg";
+ reg = <0x40003000 0x400>;
+ clocks = <&clk_lsi>;
+ status = "disabled";
+ };
+
usart2: serial@40004400 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004400 0x400>;
--
1.9.1
^ permalink raw reply related
* [PATCH v5 4/5] ARM: dts: stm32: Add watchdog support for STM32F429 eval board
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: devicetree, linux-watchdog, Philippe Cornu, linux-kernel,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1491481168-22213-1-git-send-email-yannick.fertre@st.com>
This patch adds watchdog support for STM32x9I-Eval board.
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
---
arch/arm/boot/dts/stm32429i-eval.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 6e4b42a..ff29980 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -144,6 +144,11 @@
};
};
+&iwdg {
+ status = "okay";
+ timeout-sec = <32>;
+};
+
&adc {
pinctrl-names = "default";
pinctrl-0 = <&adc3_in8_pin>;
--
1.9.1
^ permalink raw reply related
* [PATCH v5 5/5] ARM: configs: stm32: Add watchdog support in STM32 defconfig
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: devicetree, linux-watchdog, Philippe Cornu, linux-kernel,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1491481168-22213-1-git-send-email-yannick.fertre@st.com>
This patch adds STM32 watchdog support in stm32_defconfig file
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
---
arch/arm/configs/stm32_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 29ac5a4..1fb901c 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -51,6 +51,7 @@ CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_STM32F4=y
# CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_USB_SUPPORT is not set
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 2/5] drivers: watchdog: Add STM32 IWDG driver
From: Yannick FERTRE @ 2017-04-06 12:24 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck, Rob Herring, Alexandre TORGUE,
Benjamin GAIGNARD, Maxime Coquelin
Cc: linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Philippe CORNU, Gabriel FERNANDEZ,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <91cacc1b-3ae7-c955-29c6-583298ee8f1a-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
Hi Guenter,
thanks for your help.
Best regards
On 04/02/2017 01:48 PM, Guenter Roeck wrote:
> On 03/30/2017 08:15 AM, Yannick Fertre wrote:
>> This patch adds IWDG (Independent WatchDoG) support for STM32 platform.
>>
>> Signed-off-by: Yannick FERTRE <yannick.fertre-qxv4g6HH51o@public.gmane.org>
>> ---
>> drivers/watchdog/Kconfig | 12 ++
>> drivers/watchdog/Makefile | 1 +
>> drivers/watchdog/stm32_iwdg.c | 260
>> ++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 273 insertions(+)
>> create mode 100644 drivers/watchdog/stm32_iwdg.c
>>
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index 52a70ee..d014deb 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -744,6 +744,18 @@ config ZX2967_WATCHDOG
>> To compile this driver as a module, choose M here: the
>> module will be called zx2967_wdt.
>>
>> +config STM32_WATCHDOG
>> + tristate "STM32 Independent WatchDoG (IWDG) support"
>> + depends on ARCH_STM32
>> + select WATCHDOG_CORE
>> + default y
>> + help
>> + Say Y here to include support for the watchdog timer
>> + in stm32 SoCs.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called stm32_iwdg.
>> +
>> # AVR32 Architecture
>>
>> config AT32AP700X_WDT
>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
>> index a2126e2..a35e423 100644
>> --- a/drivers/watchdog/Makefile
>> +++ b/drivers/watchdog/Makefile
>> @@ -84,6 +84,7 @@ obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
>> obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
>> obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
>> obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
>> +obj-$(CONFIG_STM32_WATCHDOG) += stm32_iwdg.o
>>
>> # AVR32 Architecture
>> obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
>> diff --git a/drivers/watchdog/stm32_iwdg.c
>> b/drivers/watchdog/stm32_iwdg.c
>> new file mode 100644
>> index 0000000..629c305
>> --- /dev/null
>> +++ b/drivers/watchdog/stm32_iwdg.c
>> @@ -0,0 +1,260 @@
>> +/*
>> + * Driver for STM32 Independent Watchdog
>> + *
>> + * Copyright (C) Yannick Fertre 2017
>> + * Author: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>
>> + *
>> + * This driver is based on tegra_wdt.c
>> + *
>> + * License terms: GNU General Public License (GPL), version 2
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/watchdog.h>
>> +
>> +/* watchdog trigger timeout, in seconds */
>> +#define WDT_MIN_TIMEOUT 1
>> +#define WDT_MAX_TIMEOUT 32
>> +#define WDT_DEFAULT_TIMEOUT 30
>> +
>> +/* IWDG registers */
>> +#define IWDG_KR 0x00 /* Key register */
>> +#define IWDG_PR 0x04 /* Prescaler Register */
>> +#define IWDG_RLR 0x08 /* ReLoad Register */
>> +#define IWDG_SR 0x0C /* Status Register */
>> +#define IWDG_WINR 0x10 /* Windows Register */
>> +
>> +/* IWDG_KR register bit mask */
>> +#define KR_KEY_RELOAD 0xAAAA /* reload counter enable */
>> +#define KR_KEY_ENABLE 0xCCCC /* peripheral enable */
>> +#define KR_KEY_EWA 0x5555 /* write access enable */
>> +#define KR_KEY_DWA 0x0000 /* write access disable */
>> +
>> +/* IWDG_PR register bit values */
>> +#define PR_4 0x00 /* prescaler set to 4 */
>> +#define PR_8 0x01 /* prescaler set to 8 */
>> +#define PR_16 0x02 /* prescaler set to 16 */
>> +#define PR_32 0x03 /* prescaler set to 32 */
>> +#define PR_64 0x04 /* prescaler set to 64 */
>> +#define PR_128 0x05 /* prescaler set to 128 */
>> +#define PR_256 0x06 /* prescaler set to 256 */
>> +
>> +/* IWDG_RLR register values */
>> +#define RLR_MAX 0xFFF /* max value supported by reload
>> register */
>> +
>> +/* IWDG_SR register bit mask */
>> +#define FLAG_PVU BIT(0) /* Watchdog prescaler value update */
>> +#define FLAG_RVU BIT(1) /* Watchdog counter reload value update */
>> +
>> +/* set timeout to 100000 us */
>> +#define TIMEOUT_US 100000
>> +#define SLEEP_US 1000
>> +
>> +struct stm32_iwdg {
>> + struct watchdog_device wdd;
>> + void __iomem *regs;
>> + struct clk *clk;
>> + unsigned int rate;
>> +};
>> +
>> +static inline u32 reg_read(void __iomem *base, u32 reg)
>> +{
>> + return readl_relaxed(base + reg);
>> +}
>> +
>> +static inline void reg_write(void __iomem *base, u32 reg, u32 val)
>> +{
>> + writel_relaxed(val, base + reg);
>> +}
>> +
>> +static int stm32_iwdg_start(struct watchdog_device *wdd)
>> +{
>> + struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
>> + u32 val = FLAG_PVU | FLAG_RVU;
>> + u32 reload;
>> + int ret;
>> +
>> + dev_dbg(wdd->parent, "%s\n", __func__);
>> +
>> + /* enable watchdog */
>> + reg_write(wdt->regs, IWDG_KR, KR_KEY_EWA);
>> + reg_write(wdt->regs, IWDG_KR, KR_KEY_ENABLE);
>> +
>> + /* prescaler fixed to 256 */
>> + reload = (wdd->timeout * wdt->rate) / 256;
>> + if (reload > RLR_MAX + 1)
>> + reload = RLR_MAX + 1;
>> +
>> + /* set prescaler & reload registers */
>> + reg_write(wdt->regs, IWDG_PR, PR_256); /* prescaler fix to 256 */
>> + reg_write(wdt->regs, IWDG_RLR, reload - 1);
>> +
>> + /* wait for the registers to be updated (max 100ms) */
>> + ret = readl_relaxed_poll_timeout(wdt->regs + IWDG_SR, val,
>> + !(val & (FLAG_PVU | FLAG_RVU)),
>> + SLEEP_US, TIMEOUT_US);
>> + if (ret) {
>> + dev_err(wdd->parent,
>> + "Fail to set prescaler or reload registers\n");
>> + return ret;
>> + }
>> +
>> + /* reload watchdog */
>> + reg_write(wdt->regs, IWDG_KR, KR_KEY_RELOAD);
>> +
>> + return 0;
>> +}
>> +
>> +static int stm32_iwdg_ping(struct watchdog_device *wdd)
>> +{
>> + struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
>> +
>> + dev_dbg(wdd->parent, "%s\n", __func__);
>> +
>> + /* reload watchdog */
>> + reg_write(wdt->regs, IWDG_KR, KR_KEY_RELOAD);
>> +
>> + return 0;
>> +}
>> +
>> +static int stm32_iwdg_set_timeout(struct watchdog_device *wdd,
>> + unsigned int timeout)
>> +{
>> + dev_dbg(wdd->parent, "%s timeout: %d sec\n", __func__, timeout);
>> +
>> + wdd->timeout = timeout;
>> +
>> + if (watchdog_active(wdd))
>> + return stm32_iwdg_start(wdd);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct watchdog_info stm32_iwdg_info = {
>> + .options = WDIOF_SETTIMEOUT |
>> + WDIOF_MAGICCLOSE |
>> + WDIOF_KEEPALIVEPING,
>> + .identity = "STM32 Independent Watchdog",
>> +};
>> +
>> +static struct watchdog_ops stm32_iwdg_ops = {
>> + .owner = THIS_MODULE,
>> + .start = stm32_iwdg_start,
>> + .ping = stm32_iwdg_ping,
>> + .set_timeout = stm32_iwdg_set_timeout,
>> +};
>> +
>> +static int stm32_iwdg_probe(struct platform_device *pdev)
>> +{
>> + struct watchdog_device *wdd;
>> + struct stm32_iwdg *wdt;
>> + struct resource *res;
>> + void __iomem *regs;
>> + struct clk *clk;
>> + int ret;
>> +
>> + /* This is the timer base. */
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + regs = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(regs)) {
>> + dev_err(&pdev->dev, "Could not get resource\n");
>> + return PTR_ERR(regs);
>> + }
>> +
>> + clk = devm_clk_get(&pdev->dev, NULL);
>> + if (IS_ERR(clk)) {
>> + dev_err(&pdev->dev, "Unable to get clock\n");
>> + return PTR_ERR(clk);
>> + }
>> +
>> + ret = clk_prepare_enable(clk);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Unable to prepare clock %p\n", clk);
>> + return ret;
>> + }
>> +
>> + /*
>> + * Allocate our watchdog driver data, which has the
>> + * struct watchdog_device nested within it.
>> + */
>> + wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
>> + if (!wdt) {
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>> +
>> + /* Initialize struct stm32_iwdg. */
>> + wdt->regs = regs;
>> + wdt->clk = clk;
>> + wdt->rate = clk_get_rate(clk);
>> +
>> + /* Initialize struct watchdog_device. */
>> + wdd = &wdt->wdd;
>> + wdd->info = &stm32_iwdg_info;
>> + wdd->ops = &stm32_iwdg_ops;
>> + wdd->min_timeout = WDT_MIN_TIMEOUT;
>> + wdd->max_timeout = WDT_MAX_TIMEOUT;
>> + wdd->max_hw_heartbeat_ms = WDT_MAX_TIMEOUT;
>
> This would have to be in milli-seconds. Also only provide max_timeout
> or max_hw_heartbeat_ms, but not both.
>
Fix in V5
>> + wdd->parent = &pdev->dev;
>> +
>> + watchdog_set_drvdata(wdd, wdt);
>> + watchdog_set_nowayout(wdd, true);
>> +
>> + ret = watchdog_init_timeout(wdd, WDT_DEFAULT_TIMEOUT, &pdev->dev);
>
> Timeout parameter should be 0 to give the core a chance to pick up a
> timeout
> from fdt if specified. Otherwise the call is quite useless.
Fix in V5
>
>> + if (ret)
>> + dev_warn(&pdev->dev,
>> + "unable to set timeout value, using default\n");
>> +
>> + ret = watchdog_register_device(wdd);
>> + if (ret) {
>> + dev_err(&pdev->dev,
>> + "failed to register watchdog device\n");
>> + goto err;
>> + }
>> +
>> + platform_set_drvdata(pdev, wdt);
>> +
>> + return 0;
>> +err:
>> + clk_disable_unprepare(clk);
>> +
>> + return ret;
>> +}
>> +
>> +static int stm32_iwdg_remove(struct platform_device *pdev)
>> +{
>> + struct stm32_iwdg *wdt = platform_get_drvdata(pdev);
>> +
>> + watchdog_unregister_device(&wdt->wdd);
>> + clk_disable_unprepare(wdt->clk);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id stm32_iwdg_of_match[] = {
>> + { .compatible = "st,stm32-iwdg" },
>> + { /* end node */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, stm32_iwdg_of_match);
>> +
>> +static struct platform_driver stm32_iwdg_driver = {
>> + .probe = stm32_iwdg_probe,
>> + .remove = stm32_iwdg_remove,
>> + .driver = {
>> + .name = "iwdg",
>> + .of_match_table = stm32_iwdg_of_match,
>> + },
>> +};
>> +module_platform_driver(stm32_iwdg_driver);
>> +
>> +MODULE_AUTHOR("Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>");
>> +MODULE_DESCRIPTION("STMicroelectronics STM32 Independent Watchdog
>> Driver");
>> +MODULE_LICENSE("GPL v2");
>>
>--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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
* [PATCH 1/3] ASoC: cs35l35: Improve power down time
From: Charles Keepax @ 2017-04-06 12:52 UTC (permalink / raw)
To: broonie
Cc: mark.rutland, devicetree, brian.austin, alsa-devel, patches,
lgirdwood, Paul.Handrigan, robh+dt
Shorten the time it takes to power down the amp by disabling the volume
ramp whilst doing the final shutdown. The driver has already muted the
amplifier at this stage so doing the volume ramp serves no purpose.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
sound/soc/codecs/cs35l35.c | 8 ++++++++
sound/soc/codecs/cs35l35.h | 3 +++
2 files changed, 11 insertions(+)
diff --git a/sound/soc/codecs/cs35l35.c b/sound/soc/codecs/cs35l35.c
index 9688274..1db07a6 100644
--- a/sound/soc/codecs/cs35l35.c
+++ b/sound/soc/codecs/cs35l35.c
@@ -187,6 +187,10 @@ static int cs35l35_sdin_event(struct snd_soc_dapm_widget *w,
regmap_update_bits(cs35l35->regmap, CS35L35_PWRCTL1,
CS35L35_PDN_ALL_MASK, 1);
+ /* Already muted, so disable volume ramp for faster shutdown */
+ regmap_update_bits(cs35l35->regmap, CS35L35_AMP_DIG_VOL_CTL,
+ CS35L35_AMP_DIGSFT_MASK, 0);
+
reinit_completion(&cs35l35->pdn_done);
ret = wait_for_completion_timeout(&cs35l35->pdn_done,
@@ -199,6 +203,10 @@ static int cs35l35_sdin_event(struct snd_soc_dapm_widget *w,
regmap_update_bits(cs35l35->regmap, CS35L35_CLK_CTL1,
CS35L35_MCLK_DIS_MASK,
1 << CS35L35_MCLK_DIS_SHIFT);
+
+ regmap_update_bits(cs35l35->regmap, CS35L35_AMP_DIG_VOL_CTL,
+ CS35L35_AMP_DIGSFT_MASK,
+ 1 << CS35L35_AMP_DIGSFT_SHIFT);
break;
default:
dev_err(codec->dev, "Invalid event = 0x%x\n", event);
diff --git a/sound/soc/codecs/cs35l35.h b/sound/soc/codecs/cs35l35.h
index 156d2f0..54e9ac5 100644
--- a/sound/soc/codecs/cs35l35.h
+++ b/sound/soc/codecs/cs35l35.h
@@ -190,6 +190,9 @@
#define CS35L35_AMP_GAIN_ZC_MASK 0x10
#define CS35L35_AMP_GAIN_ZC_SHIFT 4
+#define CS35L35_AMP_DIGSFT_MASK 0x02
+#define CS35L35_AMP_DIGSFT_SHIFT 1
+
/* CS35L35_SP_FMT_CTL3 */
#define CS35L35_SP_I2S_DRV_MASK 0x03
#define CS35L35_SP_I2S_DRV_SHIFT 0
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] ASoC: cs35l35: Correct handling of PDN_DONE with external boost
From: Charles Keepax @ 2017-04-06 12:52 UTC (permalink / raw)
To: broonie-DgEjT+Ai2ygdnm+yROfE0A
Cc: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, brian.austin-jGc1dHjMKG3QT0dZR+AlfA,
Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E
In-Reply-To: <1491483134-28079-1-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
When using an external boost supply the PDN_DONE bit is not set, update
the handling in this case to use to use an appropriate fixed delay.
Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
---
include/sound/cs35l35.h | 2 ++
sound/soc/codecs/cs35l35.c | 32 ++++++++++++++++++++++++--------
2 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/include/sound/cs35l35.h b/include/sound/cs35l35.h
index 983c610..88744bb 100644
--- a/include/sound/cs35l35.h
+++ b/include/sound/cs35l35.h
@@ -96,6 +96,8 @@ struct cs35l35_platform_data {
int adv_channel;
/* Shared Boost for stereo */
bool shared_bst;
+ /* Specifies this amp is using an external boost supply */
+ bool ext_bst;
/* ClassH Algorithm */
struct classh_cfg classh_algo;
/* Monitor Config */
diff --git a/sound/soc/codecs/cs35l35.c b/sound/soc/codecs/cs35l35.c
index 1db07a6..6ecb7dd 100644
--- a/sound/soc/codecs/cs35l35.c
+++ b/sound/soc/codecs/cs35l35.c
@@ -162,6 +162,27 @@ static bool cs35l35_precious_register(struct device *dev, unsigned int reg)
}
}
+static int cs35l35_wait_for_pdn(struct cs35l35_private *cs35l35)
+{
+ int ret;
+
+ if (cs35l35->pdata.ext_bst) {
+ usleep_range(5000, 5500);
+ return 0;
+ }
+
+ reinit_completion(&cs35l35->pdn_done);
+
+ ret = wait_for_completion_timeout(&cs35l35->pdn_done,
+ msecs_to_jiffies(100));
+ if (ret == 0) {
+ dev_err(cs35l35->dev, "PDN_DONE did not complete\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
static int cs35l35_sdin_event(struct snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol, int event)
{
@@ -191,14 +212,7 @@ static int cs35l35_sdin_event(struct snd_soc_dapm_widget *w,
regmap_update_bits(cs35l35->regmap, CS35L35_AMP_DIG_VOL_CTL,
CS35L35_AMP_DIGSFT_MASK, 0);
- reinit_completion(&cs35l35->pdn_done);
-
- ret = wait_for_completion_timeout(&cs35l35->pdn_done,
- msecs_to_jiffies(100));
- if (ret == 0) {
- dev_err(codec->dev, "TIMEOUT PDN_DONE did not complete in 100ms\n");
- ret = -ETIMEDOUT;
- }
+ ret = cs35l35_wait_for_pdn(cs35l35);
regmap_update_bits(cs35l35->regmap, CS35L35_CLK_CTL1,
CS35L35_MCLK_DIS_MASK,
@@ -1198,6 +1212,8 @@ static int cs35l35_handle_of_data(struct i2c_client *i2c_client,
"cirrus,shared-boost");
}
+ pdata->ext_bst = of_property_read_bool(np, "cirrus,external-boost");
+
pdata->gain_zc = of_property_read_bool(np, "cirrus,amp-gain-zc");
classh = of_get_child_by_name(np, "cirrus,classh-internal-algo");
--
2.1.4
--
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 related
* [PATCH 3/3] ASoC: cs35l35: Add DT binding to specify usage of an external boost supply
From: Charles Keepax @ 2017-04-06 12:52 UTC (permalink / raw)
To: broonie-DgEjT+Ai2ygdnm+yROfE0A
Cc: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, brian.austin-jGc1dHjMKG3QT0dZR+AlfA,
Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E
In-Reply-To: <1491483134-28079-1-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Add a device tree binding to let the driver know that the amplifier is
configured to use an external boost supply.
Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
---
Documentation/devicetree/bindings/sound/cs35l35.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/cs35l35.txt b/Documentation/devicetree/bindings/sound/cs35l35.txt
index 958f0ea..457d176 100644
--- a/Documentation/devicetree/bindings/sound/cs35l35.txt
+++ b/Documentation/devicetree/bindings/sound/cs35l35.txt
@@ -33,6 +33,10 @@ Optional properties:
- cirrus,shared-boost : Boolean to enable ClassH tracking of Advisory Signal
if 2 Devices share Boost BST_CTL
+ - cirrus,external-boost : Boolean to specify the device is using an external
+ boost supply, note that sharing a boost from another cs35l35 would constitute
+ using an external supply for the slave device
+
- cirrus,sp-drv-strength : Value for setting the Serial Port drive strength
Table 3-10 of the datasheet lists drive-strength specifications
0 = 1x (Default)
--
2.1.4
--
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 related
* Re: [PATCH 3/4] pwm: tegra: Add DT binding details to configure pin in suspends/resume
From: Thierry Reding @ 2017-04-06 13:03 UTC (permalink / raw)
To: Jon Hunter
Cc: Laxman Dewangan, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <33445b27-ae0b-b28e-afca-e7b776b4b7c0-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]
On Thu, Apr 06, 2017 at 09:57:09AM +0100, Jon Hunter wrote:
>
> On 05/04/17 15:13, Laxman Dewangan wrote:
> > In some of NVIDIA Tegra's platform, PWM controller is used to
> > control the PWM controlled regulators. PWM signal is connected to
> > the VID pin of the regulator where duty cycle of PWM signal decide
> > the voltage level of the regulator output.
> >
> > The tristate (high impedance of PWM pin form Tegra) also define
> > one of the state of PWM regulator which needs to be configure in
> > suspend state of system.
> >
> > Add DT binding details to provide the pin configuration state
> > from PWM and pinctrl DT node in suspend and active state of
> > the system.
> >
> > Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 43 ++++++++++++++++++++++
> > 1 file changed, 43 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
> > index b4e7377..145c323 100644
> > --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
> > +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
> > @@ -19,6 +19,19 @@ Required properties:
> > - reset-names: Must include the following entries:
> > - pwm
> >
> > +Optional properties:
> > +============================
> > +In some of the interface like PWM based regualator device, it is required
> > +to configure the pins diffrently in different states, specially in suspend
>
> s/diffrently/differently
> s/specially/especially
>
> > +state of the system. The configuration of pin is provided via the pinctrl
> > +DT node as detailed in the pinctrl DT binding document
> > + Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > +
> > +The PWM node will have following optional properties.
> > +pinctrl-names: Pin state names. Must be "suspend" and "resume".
>
> Why not just use the pre-defined names here? There is a pre-defined name
> for "default", "idle" and "sleep" and then you can use the following
> APIs and avoid the lookup of the state ...
>
> pinctrl_pm_select_default_state()
> pinctrl_pm_select_idle_state()
> pinctrl_pm_select_sleep_state()
>
> Note for i2c [0][1], I used "default" as the active/on state (which I
> know is not that descriptive) and then used 'idle' as the suspended
> state. This way we don't need any custom names.
Agreed, I think that's how these states are meant to be used.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2 1/3] ARM: dts: rockchip: Add support for phyCORE-RK3288 SoM
From: Wadim Egorov @ 2017-04-06 13:04 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
heiko-4mtYJXux2i+zQB+pC5nmwQ, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 13982 bytes --]
The phyCORE-RK3288 is a SoM (System on Module) containing a RK3288 SoC.
The module can be connected to different carrier boards.
It can be also equipped with different RAM, SPI flash and eMMC variants.
The Rapid Development Kit option is using the following setup:
- 1 GB DDR3 RAM (2 Banks)
- 1x 4 KB EEPROM
- DP83867 Gigabit Ethernet PHY
- 16 MB SPI Flash
- 4 GB eMMC Flash
Signed-off-by: Wadim Egorov <w.egorov-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
---
Changes in v2:
- Added a dual license which is used for all rk3288 based boards.
Include minor changes from Heiko Stübner:
- moved phy-handle property up a bit
- switches compatible and #address+#size-cells in mdio0
- dropped rockchip,grf from &io_domains (grf is a simple-mfd and can
get the grf syscon on its own via its parent)
- vdd_cpu: regulator@60 (from fan53555@60)
- serial_flash: flash@0 (from m25p80@0)
Nodes should be named after their "category" not the actual device
---
arch/arm/boot/dts/rk3288-phycore-som.dtsi | 497 ++++++++++++++++++++++++++++++
1 file changed, 497 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-phycore-som.dtsi
diff --git a/arch/arm/boot/dts/rk3288-phycore-som.dtsi b/arch/arm/boot/dts/rk3288-phycore-som.dtsi
new file mode 100644
index 0000000..26cd3ad
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-phycore-som.dtsi
@@ -0,0 +1,497 @@
+/*
+ * Device tree file for Phytec phyCORE-RK3288 SoM
+ * Copyright (C) 2017 PHYTEC Messtechnik GmbH
+ * Author: Wadim Egorov <w.egorov-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include "rk3288.dtsi"
+
+/ {
+ model = "Phytec RK3288 phyCORE";
+ compatible = "phytec,rk3288-phycore-som", "rockchip,rk3288";
+
+ /*
+ * Set the minimum memory size here and
+ * let the bootloader set the real size.
+ */
+ memory {
+ device_type = "memory";
+ reg = <0 0x8000000>;
+ };
+
+ aliases {
+ rtc0 = &i2c_rtc;
+ rtc1 = &rk818;
+ };
+
+ ext_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ clock-output-names = "ext_gmac";
+ };
+
+ leds: user-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_led>;
+
+ user {
+ label = "green_led";
+ gpios = <&gpio7 2 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "keep";
+ };
+ };
+
+ vdd_emmc_io: vdd-emmc-io {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_emmc_io";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vdd_3v3_io>;
+ };
+
+ vdd_in_otg_out: vdd-in-otg-out {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_in_otg_out";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vdd_misc_1v8: vdd-misc-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_misc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+};
+
+&cpu0 {
+ cpu0-supply = <&vdd_cpu>;
+ operating-points = <
+ /* KHz uV */
+ 1800000 1400000
+ 1608000 1350000
+ 1512000 1300000
+ 1416000 1200000
+ 1200000 1100000
+ 1008000 1050000
+ 816000 1000000
+ 696000 950000
+ 600000 900000
+ 408000 900000
+ 312000 900000
+ 216000 900000
+ 126000 900000
+ >;
+};
+
+&emmc {
+ status = "okay";
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ disable-wp;
+ non-removable;
+ num-slots = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;
+ vmmc-supply = <&vdd_3v3_io>;
+ vqmmc-supply = <&vdd_emmc_io>;
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_MAC>;
+ assigned-clock-parents = <&ext_gmac>;
+ clock_in_out = "input";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins &phy_rst &phy_int>;
+ phy-handle = <&phy0>;
+ phy-supply = <&vdd_eth_2v5>;
+ phy-mode = "rgmii-id";
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>;
+ tx_delay = <0x0>;
+ rx_delay = <0x0>;
+
+ mdio0 {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ enet-phy-lane-no-swap;
+ };
+ };
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c5>;
+};
+
+&io_domains {
+ status = "okay";
+ sdcard-supply = <&vdd_io_sd>;
+ flash0-supply = <&vdd_emmc_io>;
+ flash1-supply = <&vdd_misc_1v8>;
+ gpio1830-supply = <&vdd_3v3_io>;
+ gpio30-supply = <&vdd_3v3_io>;
+ bb-supply = <&vdd_3v3_io>;
+ dvp-supply = <&vdd_3v3_io>;
+ lcdc-supply = <&vdd_3v3_io>;
+ wifi-supply = <&vdd_3v3_io>;
+ audio-supply = <&vdd_3v3_io>;
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ rk818: pmic@1c {
+ compatible = "rockchip,rk818";
+ reg = <0x1c>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int>;
+ rockchip,system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+
+ vcc1-supply = <&vdd_sys>;
+ vcc2-supply = <&vdd_sys>;
+ vcc3-supply = <&vdd_sys>;
+ vcc4-supply = <&vdd_sys>;
+ boost-supply = <&vdd_in_otg_out>;
+ vcc6-supply = <&vdd_sys>;
+ vcc7-supply = <&vdd_misc_1v8>;
+ vcc8-supply = <&vdd_misc_1v8>;
+ vcc9-supply = <&vdd_3v3_io>;
+ vddio-supply = <&vdd_3v3_io>;
+
+ regulators {
+ vdd_log: DCDC_REG1 {
+ regulator-name = "vdd_log";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: DCDC_REG2 {
+ regulator-name = "vdd_gpu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_3v3_io: DCDC_REG4 {
+ regulator-name = "vdd_3v3_io";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vdd_sys: DCDC_BOOST {
+ regulator-name = "vdd_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <5000000>;
+ };
+ };
+
+ /* vcc9 */
+ vdd_sd: SWITCH_REG {
+ regulator-name = "vdd_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ /* vcc6 */
+ vdd_eth_2v5: LDO_REG2 {
+ regulator-name = "vdd_eth_2v5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2500000>;
+ };
+ };
+
+ /* vcc7 */
+ vdd_1v0: LDO_REG3 {
+ regulator-name = "vdd_1v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ /* vcc8 */
+ vdd_1v8_lcd_ldo: LDO_REG4 {
+ regulator-name = "vdd_1v8_lcd_ldo";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ /* vcc8 */
+ vdd_1v0_lcd: LDO_REG6 {
+ regulator-name = "vdd_1v0_lcd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ /* vcc7 */
+ vdd_1v8_ldo: LDO_REG7 {
+ regulator-name = "vdd_1v8_ldo";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ /* vcc9 */
+ vdd_io_sd: LDO_REG9 {
+ regulator-name = "vdd_io_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+ };
+ };
+
+ /* M24C32-D */
+ i2c_eeprom: eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ vdd_cpu: regulator@60 {
+ compatible = "fcs,fan53555";
+ reg = <0x60>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-enable-ramp-delay = <300>;
+ regulator-name = "vdd_cpu";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1430000>;
+ regulator-ramp-delay = <8000>;
+ vin-supply = <&vdd_sys>;
+ };
+};
+
+&pinctrl {
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ emmc {
+ /*
+ * We run eMMC at max speed; bump up drive strength.
+ * We also have external pulls, so disable the internal ones.
+ */
+ emmc_clk: emmc-clk {
+ rockchip,pins = <3 18 RK_FUNC_2 &pcfg_pull_none_12ma>;
+ };
+
+ emmc_cmd: emmc-cmd {
+ rockchip,pins = <3 16 RK_FUNC_2 &pcfg_pull_none_12ma>;
+ };
+
+ emmc_bus8: emmc-bus8 {
+ rockchip,pins = <3 0 RK_FUNC_2 &pcfg_pull_none_12ma>,
+ <3 1 RK_FUNC_2 &pcfg_pull_none_12ma>,
+ <3 2 RK_FUNC_2 &pcfg_pull_none_12ma>,
+ <3 3 RK_FUNC_2 &pcfg_pull_none_12ma>,
+ <3 4 RK_FUNC_2 &pcfg_pull_none_12ma>,
+ <3 5 RK_FUNC_2 &pcfg_pull_none_12ma>,
+ <3 6 RK_FUNC_2 &pcfg_pull_none_12ma>,
+ <3 7 RK_FUNC_2 &pcfg_pull_none_12ma>;
+ };
+ };
+
+ gmac {
+ phy_int: phy-int {
+ rockchip,pins = <4 2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ phy_rst: phy-rst {
+ rockchip,pins = <4 8 RK_FUNC_GPIO &pcfg_output_high>;
+ };
+ };
+
+ leds {
+ user_led: user-led {
+ rockchip,pins = <7 2 RK_FUNC_GPIO &pcfg_output_high>;
+ };
+ };
+
+ pmic {
+ pmic_int: pmic-int {
+ rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ /* Pin for switching state between sleep and non-sleep state */
+ pmic_sleep: pmic-sleep {
+ rockchip,pins = <RK_GPIO0 0 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pwm1 {
+ status = "okay";
+};
+
+&saradc {
+ status = "okay";
+ vref-supply = <&vdd_1v8_ldo>;
+};
+
+&spi2 {
+ status = "okay";
+
+ serial_flash: flash@0 {
+ compatible = "micron,n25q128a13", "jedec,spi-nor";
+ reg = <0x0>;
+ spi-max-frequency = <50000000>;
+ m25p,fast-read;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "okay";
+ };
+};
+
+&tsadc {
+ status = "okay";
+ rockchip,hw-tshut-mode = <0>;
+ rockchip,hw-tshut-polarity = <0>;
+};
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+};
+
+&vopl_mmu {
+ status = "okay";
+};
+
+&wdt {
+ status = "okay";
+};
--
1.9.1
--
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 related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox