* Re: [PATCH v2 2/2] phy: meson: add USB2 PHY support for Meson GXL and GXM
From: Martin Blumenstingl @ 2017-03-28 21:33 UTC (permalink / raw)
To: kishon-l0cyMroinI0,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
hendrik-MJglGmTD+GWCT0AhDRffsw, Martin Blumenstingl,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, carlo-KA+7E9HrN00dnm+yROfE0A,
khilman-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20170318130013.20771-3-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Hi Kishon,
On Sat, Mar 18, 2017 at 2:00 PM, Martin Blumenstingl
<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> This adds a new driver for the USB2 PHYs found on Meson GXL and GXM SoCs
> (both SoCs are using the same USB PHY register layout).
>
> The USB2 PHY is a simple PHY which only has a few registers to configure
> the mode (host/device) and a reset register (to enable/disable the PHY).
>
> Unfortunately there are no datasheets available for this PHY. The driver
> was written by reading the code from Amlogic's GPL kernel sources and
> by analyzing the registers on an actual GXL and GXM device running the
> kernel that was shipped on the boards I have.
gentle ping - did you have time to review this patch in v2 yet?
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> drivers/phy/Kconfig | 14 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-meson-gxl-usb2.c | 273 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 288 insertions(+)
> create mode 100644 drivers/phy/phy-meson-gxl-usb2.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index dc5277ad1b5a..2573e139fd17 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -510,6 +510,19 @@ config PHY_MESON8B_USB2
> and GXBB SoCs.
> If unsure, say N.
>
> +config PHY_MESON_GXL_USB
> + tristate "Meson GXL and GXM USB2 PHY drivers"
> + default ARCH_MESON
> + depends on OF && (ARCH_MESON || COMPILE_TEST)
> + depends on USB_SUPPORT
> + select USB_COMMON
> + select GENERIC_PHY
> + select REGMAP_MMIO
> + help
> + Enable this to support the Meson USB2 PHYs found in Meson
> + GXL and GXM SoCs.
> + If unsure, say N.
> +
> config PHY_NSP_USB3
> tristate "Broadcom NorthStar plus USB3 PHY driver"
> depends on OF && (ARCH_BCM_NSP || COMPILE_TEST)
> @@ -518,4 +531,5 @@ config PHY_NSP_USB3
> help
> Enable this to support the Broadcom Northstar plus USB3 PHY.
> If unsure, say N.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index e7b0feb1e125..e680b856e38e 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -62,4 +62,5 @@ obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
> obj-$(CONFIG_PHY_MESON8B_USB2) += phy-meson8b-usb2.o
> +obj-$(CONFIG_PHY_MESON_GXL_USB) += phy-meson-gxl-usb2.o
> obj-$(CONFIG_PHY_NSP_USB3) += phy-bcm-nsp-usb3.o
> diff --git a/drivers/phy/phy-meson-gxl-usb2.c b/drivers/phy/phy-meson-gxl-usb2.c
> new file mode 100644
> index 000000000000..4bf646a52c45
> --- /dev/null
> +++ b/drivers/phy/phy-meson-gxl-usb2.c
> @@ -0,0 +1,273 @@
> +/*
> + * Meson GXL and GXM USB2 PHY driver
> + *
> + * Copyright (C) 2017 Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/regmap.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/usb/of.h>
> +
> +/* bits [31:27] are read-only */
> +#define U2P_R0 0x0
> + #define U2P_R0_BYPASS_SEL BIT(0)
> + #define U2P_R0_BYPASS_DM_EN BIT(1)
> + #define U2P_R0_BYPASS_DP_EN BIT(2)
> + #define U2P_R0_TXBITSTUFF_ENH BIT(3)
> + #define U2P_R0_TXBITSTUFF_EN BIT(4)
> + #define U2P_R0_DM_PULLDOWN BIT(5)
> + #define U2P_R0_DP_PULLDOWN BIT(6)
> + #define U2P_R0_DP_VBUS_VLD_EXT_SEL BIT(7)
> + #define U2P_R0_DP_VBUS_VLD_EXT BIT(8)
> + #define U2P_R0_ADP_PRB_EN BIT(9)
> + #define U2P_R0_ADP_DISCHARGE BIT(10)
> + #define U2P_R0_ADP_CHARGE BIT(11)
> + #define U2P_R0_DRV_VBUS BIT(12)
> + #define U2P_R0_ID_PULLUP BIT(13)
> + #define U2P_R0_LOOPBACK_EN_B BIT(14)
> + #define U2P_R0_OTG_DISABLE BIT(15)
> + #define U2P_R0_COMMON_ONN BIT(16)
> + #define U2P_R0_FSEL_MASK GENMASK(19, 17)
> + #define U2P_R0_REF_CLK_SEL_MASK GENMASK(21, 20)
> + #define U2P_R0_POWER_ON_RESET BIT(22)
> + #define U2P_R0_V_ATE_TEST_EN_B_MASK GENMASK(24, 23)
> + #define U2P_R0_ID_SET_ID_DQ BIT(25)
> + #define U2P_R0_ATE_RESET BIT(26)
> + #define U2P_R0_FSV_MINUS BIT(27)
> + #define U2P_R0_FSV_PLUS BIT(28)
> + #define U2P_R0_BYPASS_DM_DATA BIT(29)
> + #define U2P_R0_BYPASS_DP_DATA BIT(30)
> +
> +#define U2P_R1 0x4
> + #define U2P_R1_BURN_IN_TEST BIT(0)
> + #define U2P_R1_ACA_ENABLE BIT(1)
> + #define U2P_R1_DCD_ENABLE BIT(2)
> + #define U2P_R1_VDAT_SRC_EN_B BIT(3)
> + #define U2P_R1_VDAT_DET_EN_B BIT(4)
> + #define U2P_R1_CHARGES_SEL BIT(5)
> + #define U2P_R1_TX_PREEMP_PULSE_TUNE BIT(6)
> + #define U2P_R1_TX_PREEMP_AMP_TUNE_MASK GENMASK(8, 7)
> + #define U2P_R1_TX_RES_TUNE_MASK GENMASK(10, 9)
> + #define U2P_R1_TX_RISE_TUNE_MASK GENMASK(12, 11)
> + #define U2P_R1_TX_VREF_TUNE_MASK GENMASK(16, 13)
> + #define U2P_R1_TX_FSLS_TUNE_MASK GENMASK(20, 17)
> + #define U2P_R1_TX_HSXV_TUNE_MASK GENMASK(22, 21)
> + #define U2P_R1_OTG_TUNE_MASK GENMASK(25, 23)
> + #define U2P_R1_SQRX_TUNE_MASK GENMASK(28, 26)
> + #define U2P_R1_COMP_DIS_TUNE_MASK GENMASK(31, 29)
> +
> +/* bits [31:14] are read-only */
> +#define U2P_R2 0x8
> + #define U2P_R2_DATA_IN_MASK GENMASK(3, 0)
> + #define U2P_R2_DATA_IN_EN_MASK GENMASK(7, 4)
> + #define U2P_R2_ADDR_MASK GENMASK(11, 8)
> + #define U2P_R2_DATA_OUT_SEL BIT(12)
> + #define U2P_R2_CLK BIT(13)
> + #define U2P_R2_DATA_OUT_MASK GENMASK(17, 14)
> + #define U2P_R2_ACA_PIN_RANGE_C BIT(18)
> + #define U2P_R2_ACA_PIN_RANGE_B BIT(19)
> + #define U2P_R2_ACA_PIN_RANGE_A BIT(20)
> + #define U2P_R2_ACA_PIN_GND BIT(21)
> + #define U2P_R2_ACA_PIN_FLOAT BIT(22)
> + #define U2P_R2_CHARGE_DETECT BIT(23)
> + #define U2P_R2_DEVICE_SESSION_VALID BIT(24)
> + #define U2P_R2_ADP_PROBE BIT(25)
> + #define U2P_R2_ADP_SENSE BIT(26)
> + #define U2P_R2_SESSION_END BIT(27)
> + #define U2P_R2_VBUS_VALID BIT(28)
> + #define U2P_R2_B_VALID BIT(29)
> + #define U2P_R2_A_VALID BIT(30)
> + #define U2P_R2_ID_DIG BIT(31)
> +
> +#define U2P_R3 0xc
> +
> +#define RESET_COMPLETE_TIME 500
> +
> +struct phy_meson_gxl_usb2_priv {
> + struct regmap *regmap;
> + enum phy_mode mode;
> + int is_enabled;
> +};
> +
> +static const struct regmap_config phy_meson_gxl_usb2_regmap_conf = {
> + .reg_bits = 8,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = U2P_R3,
> +};
> +
> +static int phy_meson_gxl_usb2_reset(struct phy *phy)
> +{
> + struct phy_meson_gxl_usb2_priv *priv = phy_get_drvdata(phy);
> +
> + if (priv->is_enabled) {
> + /* reset the PHY and wait until settings are stabilized */
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_POWER_ON_RESET,
> + U2P_R0_POWER_ON_RESET);
> + udelay(RESET_COMPLETE_TIME);
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_POWER_ON_RESET,
> + 0);
> + udelay(RESET_COMPLETE_TIME);
> + }
> +
> + return 0;
> +}
> +
> +static int phy_meson_gxl_usb2_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + struct phy_meson_gxl_usb2_priv *priv = phy_get_drvdata(phy);
> +
> + switch (mode) {
> + case PHY_MODE_USB_HOST:
> + case PHY_MODE_USB_OTG:
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_DM_PULLDOWN,
> + U2P_R0_DM_PULLDOWN);
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_DP_PULLDOWN,
> + U2P_R0_DP_PULLDOWN);
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_ID_PULLUP, 0);
> + break;
> +
> + case PHY_MODE_USB_DEVICE:
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_DM_PULLDOWN,
> + 0);
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_DP_PULLDOWN,
> + 0);
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_ID_PULLUP,
> + U2P_R0_ID_PULLUP);
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + phy_meson_gxl_usb2_reset(phy);
> +
> + priv->mode = mode;
> +
> + return 0;
> +}
> +
> +static int phy_meson_gxl_usb2_power_off(struct phy *phy)
> +{
> + struct phy_meson_gxl_usb2_priv *priv = phy_get_drvdata(phy);
> +
> + priv->is_enabled = 0;
> +
> + /* power off the PHY by putting it into reset mode */
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_POWER_ON_RESET,
> + U2P_R0_POWER_ON_RESET);
> +
> + return 0;
> +}
> +
> +static int phy_meson_gxl_usb2_power_on(struct phy *phy)
> +{
> + struct phy_meson_gxl_usb2_priv *priv = phy_get_drvdata(phy);
> + int ret;
> +
> + priv->is_enabled = 1;
> +
> + /* power on the PHY by taking it out of reset mode */
> + regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_POWER_ON_RESET, 0);
> +
> + ret = phy_meson_gxl_usb2_set_mode(phy, priv->mode);
> + if (ret) {
> + phy_meson_gxl_usb2_power_off(phy);
> +
> + dev_err(&phy->dev, "Failed to initialize PHY with mode %d\n",
> + priv->mode);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct phy_ops phy_meson_gxl_usb2_ops = {
> + .power_on = phy_meson_gxl_usb2_power_on,
> + .power_off = phy_meson_gxl_usb2_power_off,
> + .set_mode = phy_meson_gxl_usb2_set_mode,
> + .reset = phy_meson_gxl_usb2_reset,
> + .owner = THIS_MODULE,
> +};
> +
> +static int phy_meson_gxl_usb2_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct phy_provider *phy_provider;
> + struct resource *res;
> + struct phy_meson_gxl_usb2_priv *priv;
> + struct phy *phy;
> + void __iomem *base;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + switch (of_usb_get_dr_mode_by_phy(dev->of_node, -1)) {
> + case USB_DR_MODE_PERIPHERAL:
> + priv->mode = PHY_MODE_USB_DEVICE;
> + break;
> + case USB_DR_MODE_OTG:
> + priv->mode = PHY_MODE_USB_OTG;
> + break;
> + case USB_DR_MODE_HOST:
> + default:
> + priv->mode = PHY_MODE_USB_HOST;
> + break;
> + }
> +
> + priv->regmap = devm_regmap_init_mmio(dev, base,
> + &phy_meson_gxl_usb2_regmap_conf);
> + if (IS_ERR(priv->regmap))
> + return PTR_ERR(priv->regmap);
> +
> + phy = devm_phy_create(dev, NULL, &phy_meson_gxl_usb2_ops);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to create PHY\n");
> + return PTR_ERR(phy);
> + }
> +
> + phy_set_drvdata(phy, priv);
> +
> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> +
> + return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct of_device_id phy_meson_gxl_usb2_of_match[] = {
> + { .compatible = "amlogic,meson-gxl-usb2-phy", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, phy_meson_gxl_usb2_of_match);
> +
> +static struct platform_driver phy_meson_gxl_usb2_driver = {
> + .probe = phy_meson_gxl_usb2_probe,
> + .driver = {
> + .name = "phy-meson-gxl-usb2",
> + .of_match_table = phy_meson_gxl_usb2_of_match,
> + },
> +};
> +module_platform_driver(phy_meson_gxl_usb2_driver);
> +
> +MODULE_AUTHOR("Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>");
> +MODULE_DESCRIPTION("Meson GXL and GXM USB2 PHY driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.12.0
>
--
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 1/2] dt-bindings: mtd: Add Cavium SOCs NAND bindings
From: Jan Glauber @ 2017-03-28 21:30 UTC (permalink / raw)
To: Boris Brezillon
Cc: Richard Weinberger, David Woodhouse, Brian Norris, Marek Vasut,
Cyrille Pitchen, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170328222035.29f4ed31@bbrezillon>
On Tue, Mar 28, 2017 at 10:20:35PM +0200, Boris Brezillon wrote:
> Hi Jan,
>
> On Mon, 27 Mar 2017 18:05:23 +0200
> Jan Glauber <jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org> wrote:
>
> > Add device tree binding description for Cavium SOC nand flash controller.
> >
> > CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >
> > Signed-off-by: Jan Glauber <jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> > ---
> > .../devicetree/bindings/mtd/cavium_nand.txt | 32 ++++++++++++++++++++++
> > 1 file changed, 32 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mtd/cavium_nand.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/cavium_nand.txt b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
> > new file mode 100644
> > index 0000000..4698d1f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
> > @@ -0,0 +1,32 @@
> > +* Cavium NAND controller
> > +
> > +Required properties:
> > +
> > +- compatible: should be "cavium,cn8xxx-nand"
> > +- reg: PCI devfn
> > +- clocks: must contain system clock
> > +- #address-cells: <1>
> > +- #size-cells: <0>
> > +
> > +The nand flash controller may contain up to 8 subnodes representing
> > +NAND flash chips. Their properties are as follows.
> > +
> > +Required properties:
> > +- compatible: should be "cavium,nandcs"
>
> Why do you need a compatible here? All sub-nodes should be representing
> NAND devices connected to the NAND controller. If you need an extra
> subnode to represent something that is not a NAND device, then it should
> not have a reg property, so testing if reg is present to detect if the
> subnode is reprensenting a NAND device should be enough.
>
> Am I missing something?
Hi Boris,
You're right. We don't need or check this compatible. The chip type
which would make more sense than what I used above is detected via ONFI,
so I can just remove the compatible string.
> > +- reg: a single integer representing the chip-select number
> > +- nand-ecc-mode: see nand.txt
> > +
> > +Example:
> > +
> > +nfc: nand@b,0 {
>
> ^ nand-controller@xxx
OK.
> > + compatible = "cavium,cn8xxx-nand";
> > + reg = <0x5800 0 0 0 0>;
> > + clocks = <&sclk>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + nand@1 {
> > + compatible = "cavium,nandcs";
> > + reg = <1>;
> > + nand-ecc-mode = "on-die";
> > +};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2,1/3] meson_uart: expose CLKID_UARTx
From: Martin Blumenstingl @ 2017-03-28 21:24 UTC (permalink / raw)
To: Jerome Brunet
Cc: devicetree, mturquette, sboyd, linux-kernel, Helmut Klein,
linux-amlogic, linux-clk, linux-arm-kernel
In-Reply-To: <1490728490.20764.8.camel@baylibre.com>
Hi Jerome,
On Tue, Mar 28, 2017 at 9:14 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Tue, 2017-03-28 at 20:18 +0200, Helmut Klein wrote:
>> i know for sure that the bluetooth chip of my system is connected to
>> uart_A. so this clock must be exposed.
>>
>> i don't know if the other 2 uarts are used on other hardware. so i will
>> remove them from my patch.
>
> What I meant is device trees "upstream".
> I would expect such patch as part of a series to add support for your board in
> device-tree, with its bluetooth chipset.
are you sure about this? Helmut is configuring the core clock of the
UART controller(s) here. we have the same thing for many other drivers
as well (MMC, SAR ADC, I2C, SPI, ethernet, you name it...) - these
clocks are not part of a device specific .dts but rather the SoC
specific dts (for example meson-gxbb.dtsi - because these clocks are
not board specific).
I guess most boards are not affected because the bootloader simply
enables the UART0 core/gate clock and keeps it enabled when booting
the kernel. additionally our clock gates are marked with
CLK_IGNORE_UNUSED so if the bootloader keeps the gates enabled then
we're not disabling it either.
> I think it would better to drop this patch from the series.
> You can either keep it for your personal work, or send it again when upstreaming
> the support for your board and/or add the support for the bluetooth chip.
if we decide to pass the core/gate clock directly in SoC.dtsi then we
should think about doing it for all three non-AO UARTs (uart_a, uart_b
and uart_c).
we can test uart_b on GPIODV_24 and GPIODV_25 on the Khadas VIM board
for example (pins 22 and 23 on the header, default mode of these pins
is i2c_sck_a and i2c_sda_a, but we can re-configure it).
uart_c unfortunately cannot be tested on the Khadas VIM board since
it's only routed to GPIOX_8 and GPIOX_9 which are hard-wired to the
bluetooth module's PCM pins (BTPCM_DOUT and BTPCM_DIN).
for Helmut this would mean that instead of dropping this patch (or
dropping CLKID_UART1 and CLKID_UART2 from this patch) he would rather
have to *add* another patch (for meson-gxbb.dtsi and meson-gxl.dtsi)
which passes the core clocks to the corresponding UART controllers
(similar to the CLKID_SD_EMMC_ clocks).
Regards,
Martin
[0] http://lxr.free-electrons.com/source/drivers/clk/meson/clkc.h?v=4.10#L110
^ permalink raw reply
* [PATCH 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers
From: Dave Gerlach @ 2017-03-28 20:55 UTC (permalink / raw)
To: Rob Herring, Tony Lindgren, Santosh Shilimkar, Russell King
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Dave Gerlach, Keerthy J
In-Reply-To: <20170328205511.21166-1-d-gerlach-l0cyMroinI0@public.gmane.org>
Certain SoCs like Texas Instruments AM335x and AM437x require parts
of the EMIF PM code to run late in the suspend sequence from SRAM,
such as saving and restoring the EMIF context and placing the memory
into self-refresh.
One requirement for these SoCs to suspend and enter its lowest power
mode, called DeepSleep0, is that the PER power domain must be shut off.
Because the EMIF (DDR Controller) resides within this power domain, it
will lose context during a suspend operation, so we must save it so we
can restore once we resume. However, we cannot execute this code from
external memory, as it is not available at this point, so the code must
be executed late in the suspend path from SRAM.
This patch introduces a ti-emif-sram driver that includes several
functions written in ARM ASM that are relocatable so the PM SRAM
code can use them. It also allocates a region of writable SRAM to
be used by the code running in the executable region of SRAM to save
and restore the EMIF context. It can export a table containing the
absolute addresses of the available PM functions so that other SRAM
code can branch to them. This code is required for suspend/resume on
AM335x and AM437x to work.
In addition to this, to be able to share data structures between C and
the ti-emif-sram-pm assembly code, we can automatically generate all of
the C struct member offsets and sizes as macros by making use of the ARM
asm-offsets file. In the same header that we define our data structures
in we also define all the macros in an inline function and by adding a
call to this in the asm_offsets file all macros are properly generated
and available to the assembly code without cluttering up the asm-offsets
file.
Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
arch/arm/kernel/asm-offsets.c | 6 +
drivers/memory/Kconfig | 10 ++
drivers/memory/Makefile | 4 +
drivers/memory/emif.h | 17 ++
drivers/memory/ti-emif-pm.c | 295 ++++++++++++++++++++++++++++++++++
drivers/memory/ti-emif-sram-pm.S | 334 +++++++++++++++++++++++++++++++++++++++
include/linux/ti-emif-sram.h | 143 +++++++++++++++++
7 files changed, 809 insertions(+)
create mode 100644 drivers/memory/ti-emif-pm.c
create mode 100644 drivers/memory/ti-emif-sram-pm.S
create mode 100644 include/linux/ti-emif-sram.h
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index 608008229c7d..d728b5660e36 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -28,6 +28,7 @@
#include <asm/vdso_datapage.h>
#include <asm/hardware/cache-l2x0.h>
#include <linux/kbuild.h>
+#include <linux/ti-emif-sram.h>
/*
* Make sure that the compiler and target are compatible.
@@ -183,5 +184,10 @@ int main(void)
#ifdef CONFIG_VDSO
DEFINE(VDSO_DATA_SIZE, sizeof(union vdso_data_store));
#endif
+#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
+ BLANK();
+ ti_emif_offsets();
+#endif
+
return 0;
}
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index ec80e35c8dfe..c29505fdb5cd 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -83,6 +83,16 @@ config OMAP_GPMC_DEBUG
bootloader or else the GPMC timings won't be identical with the
bootloader timings.
+config TI_EMIF_SRAM
+ tristate "Texas Instruments EMIF SRAM driver"
+ depends on (SOC_AM33XX || SOC_AM43XX) && SRAM
+ help
+ This driver is for the EMIF module available on Texas Instruments
+ AM33XX and AM43XX SoCs and is required for PM. Certain parts of
+ the EMIF PM code must run from on-chip SRAM late in the suspend
+ sequence so this driver provides several relocatable PM functions
+ for the SoC PM code to use.
+
config MVEBU_DEVBUS
bool "Marvell EBU Device Bus Controller"
default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index e88097fbc085..6194b37a4265 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -21,3 +21,7 @@ obj-$(CONFIG_DA8XX_DDRCTL) += da8xx-ddrctl.o
obj-$(CONFIG_SAMSUNG_MC) += samsung/
obj-$(CONFIG_TEGRA_MC) += tegra/
+obj-$(CONFIG_TI_EMIF_SRAM) += ti-emif-sram.o
+ti-emif-sram-objs := ti-emif-pm.o ti-emif-sram-pm.o
+
+AFLAGS_ti-emif-sram-pm.o :=-Wa,-march=armv7-a
diff --git a/drivers/memory/emif.h b/drivers/memory/emif.h
index bfe08bae961a..9e9f8037955d 100644
--- a/drivers/memory/emif.h
+++ b/drivers/memory/emif.h
@@ -555,6 +555,9 @@
#define READ_LATENCY_SHDW_SHIFT 0
#define READ_LATENCY_SHDW_MASK (0x1f << 0)
+#define EMIF_SRAM_AM33_REG_LAYOUT 0x00000000
+#define EMIF_SRAM_AM43_REG_LAYOUT 0x00000001
+
#ifndef __ASSEMBLY__
/*
* Structure containing shadow of important registers in EMIF
@@ -585,5 +588,19 @@ struct emif_regs {
u32 ext_phy_ctrl_3_shdw;
u32 ext_phy_ctrl_4_shdw;
};
+
+struct ti_emif_pm_functions;
+
+extern unsigned int ti_emif_sram;
+extern unsigned int ti_emif_sram_sz;
+extern struct ti_emif_pm_data ti_emif_pm_sram_data;
+extern struct emif_regs_amx3 ti_emif_regs_amx3;
+
+void ti_emif_save_context(void);
+void ti_emif_restore_context(void);
+void ti_emif_enter_sr(void);
+void ti_emif_exit_sr(void);
+void ti_emif_abort_sr(void);
+
#endif /* __ASSEMBLY__ */
#endif /* __EMIF_H */
diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c
new file mode 100644
index 000000000000..5fbdbcc85de5
--- /dev/null
+++ b/drivers/memory/ti-emif-pm.c
@@ -0,0 +1,295 @@
+/*
+ * TI AM33XX SRAM EMIF Driver
+ *
+ * Copyright (C) 2016-2017 Texas Instruments Inc.
+ * Dave Gerlach
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/genalloc.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/sram.h>
+#include <linux/ti-emif-sram.h>
+
+#include "emif.h"
+
+#define TI_EMIF_SRAM_SYMBOL_OFFSET(sym) ((unsigned long)(sym) - \
+ (unsigned long)&ti_emif_sram)
+
+#define EMIF_POWER_MGMT_WAIT_SELF_REFRESH_8192_CYCLES 0x00a0
+
+static phys_addr_t ti_emif_sram_phys, ti_emif_sram_data_phys;
+static unsigned long ti_emif_sram_virt, ti_emif_sram_data_virt;
+static struct gen_pool *sram_pool_code, *sram_pool_data;
+static struct ti_emif_pm_data pm_data;
+static struct ti_emif_pm_functions pm_functions;
+
+static u32 sram_suspend_address(unsigned long addr)
+{
+ return (ti_emif_sram_virt + TI_EMIF_SRAM_SYMBOL_OFFSET(addr));
+}
+
+static phys_addr_t sram_resume_address(unsigned long addr)
+{
+ return ((unsigned long)ti_emif_sram_phys +
+ TI_EMIF_SRAM_SYMBOL_OFFSET(addr));
+}
+
+static void ti_emif_free_sram(void)
+{
+ gen_pool_free(sram_pool_code, ti_emif_sram_virt, ti_emif_sram_sz);
+ gen_pool_free(sram_pool_data, ti_emif_sram_data_virt,
+ sizeof(struct emif_regs_amx3));
+}
+
+static int ti_emif_prepare_push_sram(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ int ret;
+
+ sram_pool_code = of_gen_pool_get(np, "sram", 0);
+ if (!sram_pool_code) {
+ dev_err(dev, "Unable to get sram pool for ocmcram code\n");
+ return -ENODEV;
+ }
+
+ ti_emif_sram_virt = gen_pool_alloc(sram_pool_code, ti_emif_sram_sz);
+ if (!ti_emif_sram_virt) {
+ dev_err(dev, "Unable to allocate code memory from ocmcram\n");
+ return -ENOMEM;
+ }
+
+ /* Save physical address to calculate resume offset during pm init */
+ ti_emif_sram_phys = gen_pool_virt_to_phys(sram_pool_code,
+ ti_emif_sram_virt);
+
+ /* Get sram pool for data section and allocate space */
+ sram_pool_data = of_gen_pool_get(np, "sram", 1);
+ if (!sram_pool_data) {
+ dev_err(dev, "Unable to get sram pool for ocmcram data\n");
+ ret = -ENODEV;
+ goto err_free_sram_code;
+ }
+
+ ti_emif_sram_data_virt = gen_pool_alloc(sram_pool_data,
+ sizeof(struct emif_regs_amx3));
+ if (!ti_emif_sram_data_virt) {
+ dev_err(dev, "Unable to allocate data memory from ocmcram\n");
+ return -ENOMEM;
+ goto err_free_sram_code;
+ }
+
+ /* Save physical address to calculate resume offset during pm init */
+ ti_emif_sram_data_phys = gen_pool_virt_to_phys(sram_pool_data,
+ ti_emif_sram_data_virt);
+ /*
+ * These functions are called during suspend path while MMU is
+ * still on so add virtual base to offset for absolute address
+ */
+ pm_functions.save_context =
+ sram_suspend_address((unsigned long)ti_emif_save_context);
+ pm_functions.enter_sr =
+ sram_suspend_address((unsigned long)ti_emif_enter_sr);
+ pm_functions.abort_sr =
+ sram_suspend_address((unsigned long)ti_emif_abort_sr);
+
+ /*
+ * These are called during resume path when MMU is not enabled
+ * so physical address is used instead
+ */
+ pm_functions.restore_context =
+ sram_resume_address((unsigned long)ti_emif_restore_context);
+ pm_functions.exit_sr =
+ sram_resume_address((unsigned long)ti_emif_exit_sr);
+
+ pm_data.regs_virt = (struct emif_regs_amx3 *)ti_emif_sram_data_virt;
+ pm_data.regs_phys = ti_emif_sram_data_phys;
+
+ return 0;
+
+err_free_sram_code:
+ gen_pool_free(sram_pool_code, ti_emif_sram_virt, ti_emif_sram_sz);
+ return ret;
+}
+
+static int ti_emif_push_sram(struct device *dev)
+{
+ int ret;
+
+ ret = sram_exec_copy(sram_pool_code, (void *)ti_emif_sram_virt,
+ &ti_emif_sram, ti_emif_sram_sz);
+ if (ret) {
+ dev_err(dev, "Cannot copy emif code to sram\n");
+ return ret;
+ }
+
+ ret = sram_exec_copy(sram_pool_code,
+ (void *)sram_suspend_address((unsigned long)&ti_emif_pm_sram_data),
+ &pm_data, sizeof(pm_data));
+ if (ret) {
+ dev_err(dev, "Cannot copy emif data to code sram\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * Due to Usage Note 3.1.2 "DDR3: JEDEC Compliance for Maximum
+ * Self-Refresh Command Limit" found in AM335x Silicon Errata
+ * (Document SPRZ360F Revised November 2013) we must configure
+ * the self refresh delay timer to 0xA (8192 cycles) to avoid
+ * generating too many refresh command from the EMIF.
+ */
+static void ti_emif_configure_sr_delay(void)
+{
+ writel(EMIF_POWER_MGMT_WAIT_SELF_REFRESH_8192_CYCLES,
+ (pm_data.ti_emif_base_addr_virt +
+ EMIF_POWER_MANAGEMENT_CONTROL));
+
+ writel(EMIF_POWER_MGMT_WAIT_SELF_REFRESH_8192_CYCLES,
+ (pm_data.ti_emif_base_addr_virt +
+ EMIF_POWER_MANAGEMENT_CTRL_SHDW));
+}
+
+/**
+ * ti_emif_copy_pm_function_table - copy mapping of pm funcs in sram
+ * @sram_pool: pointer to struct gen_pool where dst resides
+ * @dst: void * to address that table should be copied
+ *
+ * Returns 0 if success other error code if table is not available
+ */
+int ti_emif_copy_pm_function_table(struct gen_pool *sram_pool, void *dst)
+{
+ int ret;
+
+ if (!ti_emif_sram_virt)
+ return -EINVAL;
+
+ ret = sram_exec_copy(sram_pool, dst, &pm_functions,
+ sizeof(pm_functions));
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(ti_emif_copy_pm_function_table);
+
+/**
+ * ti_emif_get_mem_type - return type for memory type in use
+ *
+ * Returns memory type value read from EMIF or error code if fails
+ */
+int ti_emif_get_mem_type(void)
+{
+ unsigned long temp;
+
+ if (!pm_data.ti_emif_base_addr_virt ||
+ IS_ERR(pm_data.ti_emif_base_addr_virt))
+ return -ENODEV;
+
+ temp = readl(pm_data.ti_emif_base_addr_virt +
+ EMIF_SDRAM_CONFIG);
+
+ temp = (temp & SDRAM_TYPE_MASK) >> SDRAM_TYPE_SHIFT;
+ return temp;
+}
+EXPORT_SYMBOL_GPL(ti_emif_get_mem_type);
+
+static const struct of_device_id ti_emif_of_match[] = {
+ { .compatible = "ti,emif-am3352", .data =
+ (void *)EMIF_SRAM_AM33_REG_LAYOUT, },
+ { .compatible = "ti,emif-am4372", .data =
+ (void *)EMIF_SRAM_AM43_REG_LAYOUT, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ti_emif_of_match);
+
+static int ti_emif_probe(struct platform_device *pdev)
+{
+ int ret = -ENODEV;
+ struct resource *res;
+ struct device *dev = &pdev->dev;
+ const struct of_device_id *match;
+
+ match = of_match_device(ti_emif_of_match, &pdev->dev);
+ if (!match)
+ return -ENODEV;
+
+ pm_data.ti_emif_sram_config = (u32)match->data;
+
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(dev, "pm_runtime_get_sync() failed\n");
+ goto fail_runtime_put;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pm_data.ti_emif_base_addr_virt = devm_ioremap_resource(dev, res);
+ if (IS_ERR(pm_data.ti_emif_base_addr_virt)) {
+ dev_err(dev, "could not ioremap emif mem\n");
+ ret = PTR_ERR(pm_data.ti_emif_base_addr_virt);
+ goto fail_runtime_put;
+ }
+
+ pm_data.ti_emif_base_addr_phys = res->start;
+
+ ti_emif_configure_sr_delay();
+
+ ret = ti_emif_prepare_push_sram(dev);
+ if (ret)
+ goto fail_runtime_put;
+
+ ret = ti_emif_push_sram(dev);
+ if (ret)
+ goto fail_free_sram;
+
+ return 0;
+
+fail_free_sram:
+ ti_emif_free_sram();
+fail_runtime_put:
+ pm_runtime_put_sync(dev);
+ return ret;
+}
+
+static int ti_emif_remove(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+
+ ti_emif_free_sram();
+
+ return 0;
+}
+
+static struct platform_driver ti_emif_driver = {
+ .probe = ti_emif_probe,
+ .remove = ti_emif_remove,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = of_match_ptr(ti_emif_of_match),
+ },
+};
+module_platform_driver(ti_emif_driver);
+
+MODULE_AUTHOR("Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>");
+MODULE_DESCRIPTION("Texas Instruments SRAM EMIF driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/memory/ti-emif-sram-pm.S b/drivers/memory/ti-emif-sram-pm.S
new file mode 100644
index 000000000000..75888a22eb7f
--- /dev/null
+++ b/drivers/memory/ti-emif-sram-pm.S
@@ -0,0 +1,334 @@
+/*
+ * Low level PM code for TI EMIF
+ *
+ * Copyright (C) 2016-2017 Texas Instruments Incorporated - http://www.ti.com/
+ * Dave Gerlach
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/linkage.h>
+#include <asm/asm-offsets.h>
+#include <asm/assembler.h>
+#include <asm/memory.h>
+
+#include "emif.h"
+
+#define EMIF_POWER_MGMT_WAIT_SELF_REFRESH_8192_CYCLES 0x00a0
+#define EMIF_POWER_MGMT_SR_TIMER_MASK 0x00f0
+#define EMIF_POWER_MGMT_SELF_REFRESH_MODE 0x0200
+#define EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK 0x0700
+
+#define EMIF_SDCFG_TYPE_DDR2 0x2 << SDRAM_TYPE_SHIFT
+#define EMIF_STATUS_READY 0x4
+
+#define AM43XX_EMIF_PHY_CTRL_REG_COUNT 0x120
+
+#define EMIF_AM437X_REGISTERS 0x1
+
+ .data
+ .align 3
+
+ENTRY(ti_emif_sram)
+
+/*
+ * void ti_emif_save_context(void)
+ *
+ * Used during suspend to save the context of all required EMIF registers
+ * to local memory if the EMIF is going to lose context during the sleep
+ * transition. Operates on the VIRTUAL address of the EMIF.
+ */
+ENTRY(ti_emif_save_context)
+ stmfd sp!, {r4 - r11, lr} @ save registers on stack
+
+ adr r4, ti_emif_pm_sram_data
+ ldr r0, [r4, #EMIF_PM_BASE_ADDR_VIRT_OFFSET]
+ ldr r2, [r4, #EMIF_PM_REGS_VIRT_OFFSET]
+
+ /* Save EMIF configuration */
+ ldr r1, [r0, #EMIF_SDRAM_CONFIG]
+ str r1, [r2, #EMIF_SDCFG_VAL_OFFSET]
+
+ ldr r1, [r0, #EMIF_SDRAM_REFRESH_CONTROL]
+ str r1, [r2, #EMIF_REF_CTRL_VAL_OFFSET]
+
+ ldr r1, [r0, #EMIF_SDRAM_TIMING_1]
+ str r1, [r2, #EMIF_TIMING1_VAL_OFFSET]
+
+ ldr r1, [r0, #EMIF_SDRAM_TIMING_2]
+ str r1, [r2, #EMIF_TIMING2_VAL_OFFSET]
+
+ ldr r1, [r0, #EMIF_SDRAM_TIMING_3]
+ str r1, [r2, #EMIF_TIMING3_VAL_OFFSET]
+
+ ldr r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL]
+ str r1, [r2, #EMIF_PMCR_VAL_OFFSET]
+
+ ldr r1, [r0, #EMIF_POWER_MANAGEMENT_CTRL_SHDW]
+ str r1, [r2, #EMIF_PMCR_SHDW_VAL_OFFSET]
+
+ ldr r1, [r0, #EMIF_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG]
+ str r1, [r2, #EMIF_ZQCFG_VAL_OFFSET]
+
+ ldr r1, [r0, #EMIF_DDR_PHY_CTRL_1]
+ str r1, [r2, #EMIF_DDR_PHY_CTLR_1_OFFSET]
+
+ ldr r1, [r0, #EMIF_COS_CONFIG]
+ str r1, [r2, #EMIF_COS_CONFIG_OFFSET]
+
+ ldr r1, [r0, #EMIF_PRIORITY_TO_CLASS_OF_SERVICE_MAPPING]
+ str r1, [r2, #EMIF_PRIORITY_TO_COS_MAPPING_OFFSET]
+
+ ldr r1, [r0, #EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_1_MAPPING]
+ str r1, [r2, #EMIF_CONNECT_ID_SERV_1_MAP_OFFSET]
+
+ ldr r1, [r0, #EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_2_MAPPING]
+ str r1, [r2, #EMIF_CONNECT_ID_SERV_2_MAP_OFFSET]
+
+ ldr r1, [r0, #EMIF_OCP_CONFIG]
+ str r1, [r2, #EMIF_OCP_CONFIG_VAL_OFFSET]
+
+ ldr r5, [r4, #EMIF_PM_CONFIG_OFFSET]
+ cmp r5, #EMIF_SRAM_AM43_REG_LAYOUT
+ bne emif_skip_save_extra_regs
+
+ ldr r1, [r0, #EMIF_READ_WRITE_LEVELING_RAMP_CONTROL]
+ str r1, [r2, #EMIF_RD_WR_LEVEL_RAMP_CTRL_OFFSET]
+
+ ldr r1, [r0, #EMIF_READ_WRITE_EXECUTION_THRESHOLD]
+ str r1, [r2, #EMIF_RD_WR_EXEC_THRESH_OFFSET]
+
+ ldr r1, [r0, #EMIF_LPDDR2_NVM_TIMING]
+ str r1, [r2, #EMIF_LPDDR2_NVM_TIM_OFFSET]
+
+ ldr r1, [r0, #EMIF_LPDDR2_NVM_TIMING_SHDW]
+ str r1, [r2, #EMIF_LPDDR2_NVM_TIM_SHDW_OFFSET]
+
+ ldr r1, [r0, #EMIF_DLL_CALIB_CTRL]
+ str r1, [r2, #EMIF_DLL_CALIB_CTRL_VAL_OFFSET]
+
+ ldr r1, [r0, #EMIF_DLL_CALIB_CTRL_SHDW]
+ str r1, [r2, #EMIF_DLL_CALIB_CTRL_VAL_SHDW_OFFSET]
+
+ /* Loop and save entire block of emif phy regs */
+ mov r5, #0x0
+ add r4, r2, #EMIF_EXT_PHY_CTRL_VALS_OFFSET
+ add r3, r0, #EMIF_EXT_PHY_CTRL_1
+ddr_phy_ctrl_save:
+ ldr r1, [r3, r5]
+ str r1, [r4, r5]
+ add r5, r5, #0x4
+ cmp r5, #AM43XX_EMIF_PHY_CTRL_REG_COUNT
+ bne ddr_phy_ctrl_save
+
+emif_skip_save_extra_regs:
+ ldmfd sp!, {r4 - r11, pc} @ restore regs and return
+ENDPROC(ti_emif_save_context)
+
+/*
+ * void ti_emif_restore_context(void)
+ *
+ * Used during resume to restore the context of all required EMIF registers
+ * from local memory after the EMIF has lost context during a sleep transition.
+ * Operates on the PHYSICAL address of the EMIF.
+ */
+ENTRY(ti_emif_restore_context)
+ adr r4, ti_emif_pm_sram_data
+ ldr r0, [r4, #EMIF_PM_BASE_ADDR_PHYS_OFFSET]
+ ldr r2, [r4, #EMIF_PM_REGS_PHYS_OFFSET]
+
+ /* Config EMIF Timings */
+ ldr r1, [r2, #EMIF_DDR_PHY_CTLR_1_OFFSET]
+ str r1, [r0, #EMIF_DDR_PHY_CTRL_1]
+ str r1, [r0, #EMIF_DDR_PHY_CTRL_1_SHDW]
+
+ ldr r1, [r2, #EMIF_TIMING1_VAL_OFFSET]
+ str r1, [r0, #EMIF_SDRAM_TIMING_1]
+ str r1, [r0, #EMIF_SDRAM_TIMING_1_SHDW]
+
+ ldr r1, [r2, #EMIF_TIMING2_VAL_OFFSET]
+ str r1, [r0, #EMIF_SDRAM_TIMING_2]
+ str r1, [r0, #EMIF_SDRAM_TIMING_2_SHDW]
+
+ ldr r1, [r2, #EMIF_TIMING3_VAL_OFFSET]
+ str r1, [r0, #EMIF_SDRAM_TIMING_3]
+ str r1, [r0, #EMIF_SDRAM_TIMING_3_SHDW]
+
+ ldr r1, [r2, #EMIF_REF_CTRL_VAL_OFFSET]
+ str r1, [r0, #EMIF_SDRAM_REFRESH_CONTROL]
+ str r1, [r0, #EMIF_SDRAM_REFRESH_CTRL_SHDW]
+
+ ldr r1, [r2, #EMIF_PMCR_VAL_OFFSET]
+ str r1, [r0, #EMIF_POWER_MANAGEMENT_CTRL_SHDW]
+
+ ldr r1, [r2, #EMIF_PMCR_SHDW_VAL_OFFSET]
+ str r1, [r0, #EMIF_POWER_MANAGEMENT_CTRL_SHDW]
+
+ ldr r1, [r2, #EMIF_COS_CONFIG_OFFSET]
+ str r1, [r0, #EMIF_COS_CONFIG]
+
+ ldr r1, [r2, #EMIF_PRIORITY_TO_COS_MAPPING_OFFSET]
+ str r1, [r0, #EMIF_PRIORITY_TO_CLASS_OF_SERVICE_MAPPING]
+
+ ldr r1, [r2, #EMIF_CONNECT_ID_SERV_1_MAP_OFFSET]
+ str r1, [r0, #EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_1_MAPPING]
+
+ ldr r1, [r2, #EMIF_CONNECT_ID_SERV_2_MAP_OFFSET]
+ str r1, [r0, #EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_2_MAPPING]
+
+ ldr r1, [r2, #EMIF_OCP_CONFIG_VAL_OFFSET]
+ str r1, [r0, #EMIF_OCP_CONFIG]
+
+ ldr r5, [r4, #EMIF_PM_CONFIG_OFFSET]
+ cmp r5, #EMIF_SRAM_AM43_REG_LAYOUT
+ bne emif_skip_restore_extra_regs
+
+ ldr r1, [r2, #EMIF_RD_WR_LEVEL_RAMP_CTRL_OFFSET]
+ str r1, [r0, #EMIF_READ_WRITE_LEVELING_RAMP_CONTROL]
+
+ ldr r1, [r2, #EMIF_RD_WR_EXEC_THRESH_OFFSET]
+ str r1, [r0, #EMIF_READ_WRITE_EXECUTION_THRESHOLD]
+
+ ldr r1, [r2, #EMIF_LPDDR2_NVM_TIM_OFFSET]
+ str r1, [r0, #EMIF_LPDDR2_NVM_TIMING]
+
+ ldr r1, [r2, #EMIF_LPDDR2_NVM_TIM_SHDW_OFFSET]
+ str r1, [r0, #EMIF_LPDDR2_NVM_TIMING_SHDW]
+
+ ldr r1, [r2, #EMIF_DLL_CALIB_CTRL_VAL_OFFSET]
+ str r1, [r0, #EMIF_DLL_CALIB_CTRL]
+
+ ldr r1, [r2, #EMIF_DLL_CALIB_CTRL_VAL_SHDW_OFFSET]
+ str r1, [r0, #EMIF_DLL_CALIB_CTRL_SHDW]
+
+ ldr r1, [r2, #EMIF_ZQCFG_VAL_OFFSET]
+ str r1, [r0, #EMIF_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG]
+
+ /* Loop and restore entire block of emif phy regs */
+ mov r5, #0x0
+ /* Load ti_emif_regs_amx3 + EMIF_EXT_PHY_CTRL_VALS_OFFSET for address
+ * to phy register save space
+ */
+ add r3, r2, #EMIF_EXT_PHY_CTRL_VALS_OFFSET
+ add r4, r0, #EMIF_EXT_PHY_CTRL_1
+ddr_phy_ctrl_restore:
+ ldr r1, [r3, r5]
+ str r1, [r4, r5]
+ add r5, r5, #0x4
+ cmp r5, #AM43XX_EMIF_PHY_CTRL_REG_COUNT
+ bne ddr_phy_ctrl_restore
+
+emif_skip_restore_extra_regs:
+ /*
+ * Output impedence calib needed only for DDR3
+ * but since the initial state of this will be
+ * disabled for DDR2 no harm in restoring the
+ * old configuration
+ */
+ ldr r1, [r2, #EMIF_ZQCFG_VAL_OFFSET]
+ str r1, [r0, #EMIF_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG]
+
+ /* Write to sdcfg last for DDR2 only */
+ ldr r1, [r2, #EMIF_SDCFG_VAL_OFFSET]
+ and r2, r1, #SDRAM_TYPE_MASK
+ cmp r2, #EMIF_SDCFG_TYPE_DDR2
+ streq r1, [r0, #EMIF_SDRAM_CONFIG]
+
+ mov pc, lr
+ENDPROC(ti_emif_restore_context)
+
+/*
+ * void ti_emif_enter_sr(void)
+ *
+ * Programs the EMIF to tell the SDRAM to enter into self-refresh
+ * mode during a sleep transition. Operates on the VIRTUAL address
+ * of the EMIF.
+ */
+ENTRY(ti_emif_enter_sr)
+ stmfd sp!, {r4 - r11, lr} @ save registers on stack
+
+ adr r4, ti_emif_pm_sram_data
+ ldr r0, [r4, #EMIF_PM_BASE_ADDR_VIRT_OFFSET]
+ ldr r2, [r4, #EMIF_PM_REGS_VIRT_OFFSET]
+
+ ldr r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL]
+ bic r1, r1, #EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK
+ orr r1, r1, #EMIF_POWER_MGMT_SELF_REFRESH_MODE
+ str r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL]
+
+ ldmfd sp!, {r4 - r11, pc} @ restore regs and return
+ENDPROC(ti_emif_enter_sr)
+
+/*
+ * void ti_emif_exit_sr(void)
+ *
+ * Programs the EMIF to tell the SDRAM to exit self-refresh mode
+ * after a sleep transition. Operates on the PHYSICAL address of
+ * the EMIF.
+ */
+ENTRY(ti_emif_exit_sr)
+ adr r4, ti_emif_pm_sram_data
+ ldr r0, [r4, #EMIF_PM_BASE_ADDR_PHYS_OFFSET]
+ ldr r2, [r4, #EMIF_PM_REGS_PHYS_OFFSET]
+
+ /*
+ * Toggle EMIF to exit refresh mode:
+ * if EMIF lost context, PWR_MGT_CTRL is currently 0, writing disable
+ * (0x0), wont do diddly squat! so do a toggle from SR(0x2) to disable
+ * (0x0) here.
+ * *If* EMIF did not lose context, nothing broken as we write the same
+ * value(0x2) to reg before we write a disable (0x0).
+ */
+ ldr r1, [r2, #EMIF_PMCR_VAL_OFFSET]
+ bic r1, r1, #EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK
+ orr r1, r1, #EMIF_POWER_MGMT_SELF_REFRESH_MODE
+ str r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL]
+ bic r1, r1, #EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK
+ str r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL]
+
+ /* Wait for EMIF to become ready */
+1: ldr r1, [r0, #EMIF_STATUS]
+ tst r1, #EMIF_STATUS_READY
+ beq 1b
+
+ mov pc, lr
+ENDPROC(ti_emif_exit_sr)
+
+/*
+ * void ti_emif_abort_sr(void)
+ *
+ * Disables self-refresh after a failed transition to a low-power
+ * state so the kernel can jump back to DDR and follow abort path.
+ * Operates on the VIRTUAL address of the EMIF.
+ */
+ENTRY(ti_emif_abort_sr)
+ stmfd sp!, {r4 - r11, lr} @ save registers on stack
+
+ adr r4, ti_emif_pm_sram_data
+ ldr r0, [r4, #EMIF_PM_BASE_ADDR_VIRT_OFFSET]
+ ldr r2, [r4, #EMIF_PM_REGS_VIRT_OFFSET]
+
+ ldr r1, [r2, #EMIF_PMCR_VAL_OFFSET]
+ bic r1, r1, #EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK
+ str r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL]
+
+ /* Wait for EMIF to become ready */
+1: ldr r1, [r0, #EMIF_STATUS]
+ tst r1, #EMIF_STATUS_READY
+ beq 1b
+
+ ldmfd sp!, {r4 - r11, pc} @ restore regs and return
+ENDPROC(ti_emif_abort_sr)
+
+ .align 3
+ENTRY(ti_emif_pm_sram_data)
+ .space EMIF_PM_DATA_SIZE
+ENTRY(ti_emif_sram_sz)
+ .word . - ti_emif_save_context
diff --git a/include/linux/ti-emif-sram.h b/include/linux/ti-emif-sram.h
new file mode 100644
index 000000000000..4e15e4cc5363
--- /dev/null
+++ b/include/linux/ti-emif-sram.h
@@ -0,0 +1,143 @@
+/*
+ * TI AM33XX EMIF Routines
+ *
+ * Copyright (C) 2016-2017 Texas Instruments Inc.
+ * Dave Gerlach
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef __LINUX_TI_EMIF_H
+#define __LINUX_TI_EMIF_H
+
+#include <linux/kbuild.h>
+#ifndef __ASSEMBLY__
+
+struct emif_regs_amx3 {
+ u32 emif_sdcfg_val;
+ u32 emif_timing1_val;
+ u32 emif_timing2_val;
+ u32 emif_timing3_val;
+ u32 emif_ref_ctrl_val;
+ u32 emif_zqcfg_val;
+ u32 emif_pmcr_val;
+ u32 emif_pmcr_shdw_val;
+ u32 emif_rd_wr_level_ramp_ctrl;
+ u32 emif_rd_wr_exec_thresh;
+ u32 emif_cos_config;
+ u32 emif_priority_to_cos_mapping;
+ u32 emif_connect_id_serv_1_map;
+ u32 emif_connect_id_serv_2_map;
+ u32 emif_ocp_config_val;
+ u32 emif_lpddr2_nvm_tim;
+ u32 emif_lpddr2_nvm_tim_shdw;
+ u32 emif_dll_calib_ctrl_val;
+ u32 emif_dll_calib_ctrl_val_shdw;
+ u32 emif_ddr_phy_ctlr_1;
+ u32 emif_ext_phy_ctrl_vals[120];
+};
+
+struct ti_emif_pm_data {
+ void __iomem *ti_emif_base_addr_virt;
+ phys_addr_t ti_emif_base_addr_phys;
+ unsigned long ti_emif_sram_config;
+ struct emif_regs_amx3 *regs_virt;
+ phys_addr_t regs_phys;
+} __packed;
+
+struct ti_emif_pm_functions {
+ u32 save_context;
+ u32 restore_context;
+ u32 enter_sr;
+ u32 exit_sr;
+ u32 abort_sr;
+} __packed;
+
+extern inline void ti_emif_offsets(void)
+{
+ DEFINE(EMIF_SDCFG_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_sdcfg_val));
+ DEFINE(EMIF_TIMING1_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_timing1_val));
+ DEFINE(EMIF_TIMING2_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_timing2_val));
+ DEFINE(EMIF_TIMING3_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_timing3_val));
+ DEFINE(EMIF_REF_CTRL_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_ref_ctrl_val));
+ DEFINE(EMIF_ZQCFG_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_zqcfg_val));
+ DEFINE(EMIF_PMCR_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_pmcr_val));
+ DEFINE(EMIF_PMCR_SHDW_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_pmcr_shdw_val));
+ DEFINE(EMIF_RD_WR_LEVEL_RAMP_CTRL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_rd_wr_level_ramp_ctrl));
+ DEFINE(EMIF_RD_WR_EXEC_THRESH_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_rd_wr_exec_thresh));
+ DEFINE(EMIF_COS_CONFIG_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_cos_config));
+ DEFINE(EMIF_PRIORITY_TO_COS_MAPPING_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_priority_to_cos_mapping));
+ DEFINE(EMIF_CONNECT_ID_SERV_1_MAP_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_connect_id_serv_1_map));
+ DEFINE(EMIF_CONNECT_ID_SERV_2_MAP_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_connect_id_serv_2_map));
+ DEFINE(EMIF_OCP_CONFIG_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_ocp_config_val));
+ DEFINE(EMIF_LPDDR2_NVM_TIM_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_lpddr2_nvm_tim));
+ DEFINE(EMIF_LPDDR2_NVM_TIM_SHDW_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_lpddr2_nvm_tim_shdw));
+ DEFINE(EMIF_DLL_CALIB_CTRL_VAL_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_dll_calib_ctrl_val));
+ DEFINE(EMIF_DLL_CALIB_CTRL_VAL_SHDW_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_dll_calib_ctrl_val_shdw));
+ DEFINE(EMIF_DDR_PHY_CTLR_1_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_ddr_phy_ctlr_1));
+ DEFINE(EMIF_EXT_PHY_CTRL_VALS_OFFSET,
+ offsetof(struct emif_regs_amx3, emif_ext_phy_ctrl_vals));
+ DEFINE(EMIF_REGS_AMX3_SIZE, sizeof(struct emif_regs_amx3));
+
+ BLANK();
+
+ DEFINE(EMIF_PM_BASE_ADDR_VIRT_OFFSET,
+ offsetof(struct ti_emif_pm_data, ti_emif_base_addr_virt));
+ DEFINE(EMIF_PM_BASE_ADDR_PHYS_OFFSET,
+ offsetof(struct ti_emif_pm_data, ti_emif_base_addr_phys));
+ DEFINE(EMIF_PM_CONFIG_OFFSET,
+ offsetof(struct ti_emif_pm_data, ti_emif_sram_config));
+ DEFINE(EMIF_PM_REGS_VIRT_OFFSET,
+ offsetof(struct ti_emif_pm_data, regs_virt));
+ DEFINE(EMIF_PM_REGS_PHYS_OFFSET,
+ offsetof(struct ti_emif_pm_data, regs_phys));
+ DEFINE(EMIF_PM_DATA_SIZE, sizeof(struct ti_emif_pm_data));
+
+ BLANK();
+
+ DEFINE(EMIF_PM_SAVE_CONTEXT_OFFSET,
+ offsetof(struct ti_emif_pm_functions, save_context));
+ DEFINE(EMIF_PM_RESTORE_CONTEXT_OFFSET,
+ offsetof(struct ti_emif_pm_functions, restore_context));
+ DEFINE(EMIF_PM_ENTER_SR_OFFSET,
+ offsetof(struct ti_emif_pm_functions, enter_sr));
+ DEFINE(EMIF_PM_EXIT_SR_OFFSET,
+ offsetof(struct ti_emif_pm_functions, exit_sr));
+ DEFINE(EMIF_PM_ABORT_SR_OFFSET,
+ offsetof(struct ti_emif_pm_functions, abort_sr));
+ DEFINE(EMIF_PM_FUNCTIONS_SIZE, sizeof(struct ti_emif_pm_functions));
+}
+
+struct gen_pool;
+
+int ti_emif_copy_pm_function_table(struct gen_pool *sram_pool, void *dst);
+int ti_emif_get_mem_type(void);
+
+#endif
+#endif /* __LINUX_TI_EMIF_H */
--
2.11.0
--
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 1/2] Documentation: dt: Update ti,emif bindings
From: Dave Gerlach @ 2017-03-28 20:55 UTC (permalink / raw)
To: Rob Herring, Tony Lindgren, Santosh Shilimkar, Russell King
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Dave Gerlach, Keerthy J
In-Reply-To: <20170328205511.21166-1-d-gerlach-l0cyMroinI0@public.gmane.org>
Update the Texas Instruments EMIF binding document to include the device
tree bindings for ti,emif-am3352 and ti,emif-am4372 which are used by
the ti-emif-sram driver to provide low-level PM functionality.
Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/memory-controllers/ti/emif.txt | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
index 0db60470ebb6..8c0214b17c2b 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -8,6 +8,7 @@ of the EMIF IP and memory parts attached to it.
Required properties:
- compatible : Should be of the form "ti,emif-<ip-rev>" where <ip-rev>
is the IP revision of the specific EMIF instance.
+ For am335x should be ti,emif-am3352.
For am437x should be ti,emif-am4372.
- phy-type : <u32> indicating the DDR phy type. Following are the
@@ -21,6 +22,13 @@ Required properties:
the value shall be "emif<n>" where <n> is the number of the EMIF
instance with base 1.
+Required only for "ti,emif-am3352" and "ti,emif-am4372":
+- sram : Phandles for generic sram driver nodes,
+ first should be type 'protect-exec' for the driver to use to copy
+ and run PM functions, second should be regular pool to be used for
+ data region for code. See Documentation/devicetree/bindings/sram/sram.txt
+ for more details.
+
Optional properties:
- cs1-used : Have this property if CS1 of this EMIF
instance has a memory part attached to it. If there is a memory
@@ -42,7 +50,7 @@ Optional properties:
- hw-caps-temp-alert : Have this property if the controller
has capability for generating SDRAM temperature alerts
-Example:
+-Examples:
emif1: emif@0x4c000000 {
compatible = "ti,emif-4d";
@@ -54,3 +62,11 @@ emif1: emif@0x4c000000 {
hw-caps-ll-interface;
hw-caps-temp-alert;
};
+
+/* From am33xx.dtsi */
+emif: emif@4c000000 {
+ compatible = "ti,emif-am3352";
+ reg = <0x4C000000 0x1000>;
+ sram = <&pm_sram_code
+ &pm_sram_data>;
+};
--
2.11.0
--
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 0/2] memory: Introduce ti-emif-sram driver
From: Dave Gerlach @ 2017-03-28 20:55 UTC (permalink / raw)
To: Rob Herring, Tony Lindgren, Santosh Shilimkar, Russell King
Cc: devicetree, Dave Gerlach, Keerthy J, linux-kernel, linux-omap,
linux-arm-kernel
Hi,
This series introduces a ti-emif-sram driver to be used on am335x and am437x.
These SoCs have low power modes that require that the PER power domain be shut
off. Because the EMIF (DDR Controller) resides within this power domain, it
will lose context during a suspend operation, so we must save it so we can
restore once we resume. However, we cannot execute this code from external
memory, as it is not available at this point, so the code must be executed late
in the suspend path and early in the resume path from SRAM.
Patch 2 includes several functions written in ARM ASM that can be relocated to
on-chip SRAM. It also exports a table containing the absolute addresses of the
available PM functions so that other PM code also running from SRAM can branch
to them. It must also calculate virtual addresses for the suspend path, but
physical addresses for the resume path as the MMU is not active when the code
runs.
One thing that may not be immediately clear in the driver is that we can only
get read-only exectuable memory regions from the mmio-sram driver so we also
provide a second region to the driver that is read/write to be used for data
during execution. This is the reason two sram regions are mapped and so many
offsets must be provided to the code section.
In order for structs to co-exist in C and ASM, I went ahead and extended the
generic asm-offsets.c for ARM and added a single function call for this driver
that adds all the constants needed for the ASM code to get offsets into the
struct members. I managed to do it without many direct additions to the
asm-offsets file so I do not think it is too intrusive. This was the only way I
saw to do peaceful C and ASM data structure co-existence. Due to the
dependencies of all of the code on this I did not not split ARM vs drivers/
changes into separate patches because I think it would be more confusing that
way but if needed I think it can be done.
This code is required for low-power modes to work on AM335x and AM437x and a
forthcoming PM series for those platforms will depend on this series. After
both this and the PM series are reviewed I will send the necessary device tree
changes for both, but in the meantime all remaining patches for am335x and
am437x PM can be found here [1].
Regards,
Dave
[1] https://github.com/dgerlach/linux-pm/tree/upstream/v4.11/amx3-suspend-dev
Dave Gerlach (2):
Documentation: dt: Update ti,emif bindings
memory: ti-emif-sram: introduce relocatable suspend/resume handlers
.../bindings/memory-controllers/ti/emif.txt | 18 +-
arch/arm/kernel/asm-offsets.c | 6 +
drivers/memory/Kconfig | 10 +
drivers/memory/Makefile | 4 +
drivers/memory/emif.h | 17 ++
drivers/memory/ti-emif-pm.c | 295 ++++++++++++++++++
drivers/memory/ti-emif-sram-pm.S | 334 +++++++++++++++++++++
include/linux/ti-emif-sram.h | 143 +++++++++
8 files changed, 826 insertions(+), 1 deletion(-)
create mode 100644 drivers/memory/ti-emif-pm.c
create mode 100644 drivers/memory/ti-emif-sram-pm.S
create mode 100644 include/linux/ti-emif-sram.h
--
2.11.0
^ permalink raw reply
* Re: [RFC 3/8] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend
From: Rafael J. Wysocki @ 2017-03-28 20:50 UTC (permalink / raw)
To: Leonard Crestez
Cc: Mark Rutland, devicetree, Anson Huang, Irina Tirdea, Viresh Kumar,
linux-pm, Liam Girdwood, Rob Herring, linux-kernel, Mark Brown,
Octavian Purdila, Sascha Hauer, Fabio Estevam, Robin Gong,
Shawn Guo, linux-arm-kernel
In-Reply-To: <1490731431.15830.9.camel@nxp.com>
On Tuesday, March 28, 2017 11:03:51 PM Leonard Crestez wrote:
> On Thu, 2017-03-23 at 10:04 +0530, Viresh Kumar wrote:
> > On 22-03-17, 18:53, Leonard Crestez wrote:
> > > If the cpufreq driver tries to modify voltage/freq during suspend/resume
> > > it might need to control an external PMIC via I2C or SPI but those
> > > devices might be already suspended.
> > >
> > > To avoid this scenario we just increase cpufreq to highest setpoint
> > > before suspend. This issue can easily be triggered by ldo-bypass but in
> > > theory any regulator set_voltage call can end up having to modify
> > > external supply voltages.
> > >
> > > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> > > ---
> > > drivers/cpufreq/imx6q-cpufreq.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> The first couple of patches are obvious fixes despite being marked as
> RFC. It would be great if you could apply them to your tree separately
Why?
> from the rest of the series but I'm not sure what the process is here.
Well, you have to talk to me.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH v6 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed
From: Benjamin Herrenschmidt @ 2017-03-28 20:50 UTC (permalink / raw)
To: Marc Zyngier, Brendan Higgins, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
tglx-hfZtesqFncYOwBW4kG4KsQ, jason-NLaQJdtUoK4Be96aLqz0jA,
joel-U3u1mxZcP9KHXe+LvDLADg, vz-ChpfBGZJDbMAvxtiuMwx3w,
mouse-Pma6HLj0uuo, clg-Bxea+6Xhats
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
openbmc-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <91936f1a-0a0d-4091-b981-976503a6f7cd-5wv7dgnIgG8@public.gmane.org>
On Tue, 2017-03-28 at 10:40 +0100, Marc Zyngier wrote:
> On 28/03/17 10:12, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-03-28 at 09:32 +0100, Marc Zyngier wrote:
> > > I'm a bit concerned by this. It means that you can't even mask an
> > > interrupt. Is that really what you intend to do? Or all that the HW can
> > > do? If you cannot mask an interrupt, you're at the mercy of a screaming
> > > device...
> >
> > This is not really an interrupt controller. It's a "summary" register
> > that reflects the state of the 14 i2c controller interrupts.
> >
> > This approach does have the advantage of providing separate counters in
> > /proc/interrupts which is rather nice, but it does have overhead. On
> > those shittly little ARMv9 400Mhz cores it can be significant.
>
> <pedantic>
> s/ARMv9/ARM9/, as we're still on variations of the ARMv8 architecture ;-)
> </pedantic>
It was a typo, I meant ARM9/ARMv5 :-)
The 2 SOC families we are talking about (Aspeed 24xx and 25xx) are
based on a ARM926EJ at 400Mhz and an ARM1176JZFS at 800Mhz
respectively, so cycles do count :-)
> A 400MHz ARM9 (which is either ARMv4 or ARMv5) is not too bad (hey, we
> still have a couple of Versatile-ABs here...). Caches are pretty small
> though.
16K/16K, no L2 :)
> > I would personally have some kind of trick to register a single
> > interrupt handler that calls directly the handlers of the respective
> > i2c busses via a simple indirection for speed, maybe adding my custom
> > sysfs or debugfs statistics. But that's just me trying to suck the last
> > cycle out of the bloody thing ;-)
>
> I'd hope the irqdomain itself to be pretty light (the revmap should help
> here), but of course you're going to do more work. Counters also come at
> a cost. It'd be interesting to see if Brendan has any overhead data
> about this.
Thankfully, the HW supports buffered sends/receive or even DMA. The
current patch doesn't yet support these but they would be a good way to
alleviate the cost of the interrupts if it becomes a problem.
Cheers,
Ben.
> Cheers,
>
> M.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: rockchip: Enable sata support on rock2 square
From: Heiko Stuebner @ 2017-03-28 20:22 UTC (permalink / raw)
To: Sjoerd Simons
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170317135118.17333-1-sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Am Freitag, 17. März 2017, 14:51:17 CEST schrieb Sjoerd Simons:
> The Rock 2 square board has a USB -> SATA converter hooked up to its usb
> host1 connection. Enable the usb controller and always turn on the power
> on the 5V sata power connector (controlled by gpio).
>
> Signed-off-by: Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
applied for 4.12
Thanks
Heiko
--
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 1/2] dt-bindings: mtd: Add Cavium SOCs NAND bindings
From: Boris Brezillon @ 2017-03-28 20:20 UTC (permalink / raw)
To: Jan Glauber
Cc: Richard Weinberger, David Woodhouse, Brian Norris, Marek Vasut,
Cyrille Pitchen, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170327160524.29019-2-jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Hi Jan,
On Mon, 27 Mar 2017 18:05:23 +0200
Jan Glauber <jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org> wrote:
> Add device tree binding description for Cavium SOC nand flash controller.
>
> CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> Signed-off-by: Jan Glauber <jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/cavium_nand.txt | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/cavium_nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/cavium_nand.txt b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
> new file mode 100644
> index 0000000..4698d1f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
> @@ -0,0 +1,32 @@
> +* Cavium NAND controller
> +
> +Required properties:
> +
> +- compatible: should be "cavium,cn8xxx-nand"
> +- reg: PCI devfn
> +- clocks: must contain system clock
> +- #address-cells: <1>
> +- #size-cells: <0>
> +
> +The nand flash controller may contain up to 8 subnodes representing
> +NAND flash chips. Their properties are as follows.
> +
> +Required properties:
> +- compatible: should be "cavium,nandcs"
Why do you need a compatible here? All sub-nodes should be representing
NAND devices connected to the NAND controller. If you need an extra
subnode to represent something that is not a NAND device, then it should
not have a reg property, so testing if reg is present to detect if the
subnode is reprensenting a NAND device should be enough.
Am I missing something?
> +- reg: a single integer representing the chip-select number
> +- nand-ecc-mode: see nand.txt
> +
> +Example:
> +
> +nfc: nand@b,0 {
^ nand-controller@xxx
> + compatible = "cavium,cn8xxx-nand";
> + reg = <0x5800 0 0 0 0>;
> + clocks = <&sclk>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + nand@1 {
> + compatible = "cavium,nandcs";
> + reg = <1>;
> + nand-ecc-mode = "on-die";
> +};
--
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: [RESEND PATCH v2 00/53] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb
From: Boris Brezillon @ 2017-03-28 20:14 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, Laurent Monat, thorsten.christiansson, Enrico Jorns,
Artem Bityutskiy, Dinh Nguyen, Marek Vasut, Graham Moore,
David Woodhouse, Masami Hiramatsu, Chuanxiao Dong, Jassi Brar,
devicetree, Linux Kernel Mailing List, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring,
Mark Rutland <mark.>
In-Reply-To: <CAK7LNARNUhyFpVRKYwmadkTGpR-aAjUNs2WgwYn3ao5Y+zTH1w@mail.gmail.com>
On Sat, 25 Mar 2017 23:40:38 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi Boris,
>
>
>
> 2017-03-25 5:13 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>:
>
> >>
> >> Masahiro Yamada (53):
> >> mtd: nand: allow to set only one of ECC size and ECC strength from DT
> >> mtd: nand: use read_oob() instead of cmdfunc() for bad block check
> >> mtd: nand: denali: remove unused CONFIG option and macros
> >> mtd: nand: denali: remove redundant define of BANK(x)
> >> mtd: nand: denali: remove more unused struct members
> >> mtd: nand: denali: fix comment of denali_nand_info::flash_mem
> >> mtd: nand: denali: consolidate INTR_STATUS__* and INTR_EN__* macros
> >> mtd: nand: denali: introduce capability flag
> >> mtd: nand: denali: use int where no reason to use fixed width variable
> >> mtd: nand: denali: fix erased page checking
> >> mtd: nand: denali: fix bitflips calculation in handle_ecc()
> >> mtd: nand: denali: support HW_ECC_FIXUP capability
> >> mtd: nand: denali_dt: enable HW_ECC_FIXUP for Altera SOCFPGA variant
> >> mtd: nand: denali: support 64bit capable DMA engine
> >> mtd: nand: denali_dt: remove dma-mask DT property
> >> mtd: nand: denali_dt: use pdev instead of ofdev for platform_device
> >> mtd: nand: denali: allow to override revision number
> >> mtd: nand: denali: use nand_chip to hold frequently accessed data
> >> mtd: nand: denali: call nand_set_flash_node() to set DT node
> >> mtd: nand: denali: do not set mtd->name
> >> mtd: nand: denali: move multi device fixup code to a helper function
> >> mtd: nand: denali: simplify multi device fixup code
> >> mtd: nand: denali: set DEVICES_CONNECTED 1 if not set
> >> mtd: nand: denali: remove meaningless writes to read-only registers
> >> mtd: nand: denali: remove unnecessary writes to ECC_CORRECTION
> >> mtd: nand: denali: support 1024 byte ECC step size
> >> mtd: nand: denali: avoid hard-coding ecc.strength and ecc.bytes
> >> mtd: nand: denali: support "nand-ecc-strength" DT property
> >> mtd: nand: denali: remove Toshiba and Hynix specific fixup code
> >> mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
> >> mtd: nand: denali: set NAND_ECC_CUSTOM_PAGE_ACCESS
> >> mtd: nand: denali: do not propagate NAND_STATUS_FAIL to waitfunc()
> >> mtd: nand: denali: use BIT() and GENMASK() for register macros
> >> mtd: nand: denali: remove unneeded find_valid_banks()
> >> mtd: nand: denali: handle timing parameters by setup_data_interface()
> >> mtd: nand: denali: remove meaningless pipeline read-ahead operation
> >> mtd: nand: denali: rework interrupt handling
> >> mtd: nand: denali: fix NAND_CMD_STATUS handling
> >> mtd: nand: denali: fix NAND_CMD_PARAM handling
> >> mtd: nand: do not check R/B# for CMD_READID in nand_command(_lp)
> >> mtd: nand: do not check R/B# for CMD_SET_FEATURES in nand_command(_lp)
> >> mtd: nand: denali: switch over to cmd_ctrl instead of cmdfunc
> >> mtd: nand: denali: fix bank reset function
> >> mtd: nand: denali: use interrupt instead of polling for bank reset
> >> mtd: nand: denali: propagate page to helpers via function argument
> >> mtd: nand: denali: merge struct nand_buf into struct denali_nand_info
> >> mtd: nand: denali: use flag instead of register macro for direction
> >> mtd: nand: denali: fix raw and oob accessors for syndrome page layout
> >> mtd: nand: denali: support hardware-assisted erased page detection
> >> mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset
> >> mtd: nand: denali: skip driver internal bounce buffer when possible
> >> mtd: nand: denali: use non-managed kmalloc() for DMA buffer
> >> mtd: nand: denali: enable bad block table scan
> >
> > Applied patch 1 to 9, 40 and 41. I'll see what else I can apply so that
> > you don't have to re-post the remaining 42 patches, but I fear some of
> > them won't apply correctly without patch 10 on which I had comments.
>
> Thanks!
>
> This will be very helpful when sending the next version.
>
> If you like, you can also apply the following 9 patches cleanly in this order.
>
> 18/53 mtd: nand: denali: use nand_chip to hold frequently accessed data
> 19/53 mtd: nand: denali: call nand_set_flash_node() to set DT node
> 20/53 mtd: nand: denali: do not set mtd->name
> 21/53 mtd: nand: denali: move multi device fixup code to a helper function
> 22/53 mtd: nand: denali: simplify multi device fixup code
> 23/53 mtd: nand: denali: set DEVICES_CONNECTED 1 if not set
> 24/53 mtd: nand: denali: remove meaningless writes to read-only registers
> 25/53 mtd: nand: denali: remove unnecessary writes to ECC_CORRECTION
Applied all the above patches.
> 36/53 mtd: nand: denali: remove meaningless pipeline read-ahead operation
Still need to review this one.
>
> These are less controversial, and have no dependency on 10/53-17/53.
>
>
>
>
> 50/53 "mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset"
> is a change to the NAND framework. (used as a pre-requisite for 51/53)
Had a comment on the commit message (not the patch content). I find it
too alarmist: you seem to imply that all controller drivers doing DMA
on nand buffers allocated by the core are broken, which I think is not
the case.
I don't deny the theoretical risk of using non-cache aligned buffers,
but in practice, given the workflow we have in the NAND framework, I
don't think cache management operations can trigger data corruptions (I
might be wrong, though).
^ permalink raw reply
* Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: change switch2 label
From: Vivien Didelot @ 2017-03-28 20:04 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Shawn Guo,
Florian Fainelli
In-Reply-To: <20170328193318.GG2268-g2DYL2Zd6BY@public.gmane.org>
Hi Andrew,
Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> writes:
> You might need to rebase this onto
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
>
> There have been a few other changes to the ZII dts files this cycle.
This patch applies correctly on shawnguo/for-next. Is it the correct
branch to rebase onto?
Thanks,
Vivien
--
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 3/8] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend
From: Leonard Crestez @ 2017-03-28 20:03 UTC (permalink / raw)
To: Viresh Kumar
Cc: Mark Brown, Liam Girdwood, Rafael J. Wysocki, Shawn Guo,
Sascha Hauer, Robin Gong, Anson Huang, Irina Tirdea, Rob Herring,
Mark Rutland, Fabio Estevam, Octavian Purdila,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170323043427.GE12094@vireshk-i7>
On Thu, 2017-03-23 at 10:04 +0530, Viresh Kumar wrote:
> On 22-03-17, 18:53, Leonard Crestez wrote:
> > If the cpufreq driver tries to modify voltage/freq during suspend/resume
> > it might need to control an external PMIC via I2C or SPI but those
> > devices might be already suspended.
> >
> > To avoid this scenario we just increase cpufreq to highest setpoint
> > before suspend. This issue can easily be triggered by ldo-bypass but in
> > theory any regulator set_voltage call can end up having to modify
> > external supply voltages.
> >
> > Signed-off-by: Leonard Crestez <leonard.crestez-3arQi8VN3Tc@public.gmane.org>
> > ---
> > drivers/cpufreq/imx6q-cpufreq.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
The first couple of patches are obvious fixes despite being marked as
RFC. It would be great if you could apply them to your tree separately
from the rest of the series but I'm not sure what the process is here.
--
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 4/8] regulator: core: Check enabling bypass respects constraints
From: Leonard Crestez @ 2017-03-28 19:49 UTC (permalink / raw)
To: Mark Brown
Cc: Sascha Hauer, Liam Girdwood, Viresh Kumar, Rafael J. Wysocki,
Shawn Guo, Robin Gong, Anson Huang, Irina Tirdea, Rob Herring,
Mark Rutland, Fabio Estevam, Octavian Purdila, linux-pm,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20170328164754.z2c2ttovs3sxbcos@sirena.org.uk>
On Tue, 2017-03-28 at 17:47 +0100, Mark Brown wrote:
> On Tue, Mar 28, 2017 at 03:39:41PM +0300, Leonard Crestez wrote:
> > On Fri, 2017-03-24 at 12:52 +0000, Mark Brown wrote:
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns. Doing this makes your messages much
> easier to read and reply to.
Sorry, still messing around with Evolution and Exchange.
> > > to the supply. Usually bypass is used for low power retention modes
> > > with different settings to those used in normal operation that wouldn't
> > > be desired in normal operation, if we were going to have constraints for
> > > this I'd expect a separate set used during bypass.
> >
> > In this particular case it's not possible to set constraints on the parent
> > regulator so that both ldo-enable and ldo-bypass modes work. The maximum allowed
> > voltage for ldo-bypass is lower than the minimum required to support the chip at
> > max frequency wit ldo-enable.
>
> If things are really so sensitive that you can't bypass without lowering
> the voltage then it's hard to see how you can safely transition into and
> out of bypass mode.
The CPU frequency is set to the minimum value so that when bypass mode
is entered and voltage rises (because the dropout goes away) it is
still low enough. Transitioning out of bypass mode is not implemented
but you would presumably have to go to the minimum frequency again,
raise the voltage above what is required and the flip the switch.
> > I'm not sure I understand why you are against applying constraints to the parent
> > when in bypass mode, it seems like the obvious thing to do if you want to
> > support flexible configuration. The check I introduced is probably not enough to
> > cover all cases, for example it would still be possible to explicitly change
> > parent voltage afterwards.
>
> To repeat what I said previously the whole point of bypassing is to not
> do regulation and generally the constraints in the unregulated idle case
> are substantially more relaxed. This would break use cases relying on
> the existing behaviour which wouldn't expect to affect the parent
> voltage at all, either stopping things working or making them less
> efficient by needlessly regulating the voltage down which defeats the
> main point of bypassing.
So what you want is to prevent voltage changes unless strictly
required, even lowering? What I want is to get the minimum voltage in
the SOC because that's where power is being consumed.
It's not at all obvious that in bypass mode the output constraints of a
regulator need not be respected by the core. I expected the opposite,
this is something that should be documented.
But if the bypassed regulator has a downstream consumer then it's
requirements should definitely still be met in bypass mode, right? I
could set my maximum voltage directly from cpufreq in that case.
Or should a bypassed regulator ignore all other requests? One of the
behaviors that this patch series relies on is that calling set_voltage
on a bypassed regulator propagates this request to the supply and picks
the minimum voltage there. An alternative implementation would be to
call set_voltage directly on the supply regulator by changing the
"{arm,soc,pu}-supply" references in DT to point to the PMIC instead.
Would that be better?
Both approaches work. Relying on propagation feels like it is the
"right way" to handle this, even if it's harder to get right and the
regulator core does not entirely support it. But it's possible that
this is based on a misunderstanding of what "bypass" is actually
supposed to do.
--
Regards,
Leonard
^ permalink raw reply
* Re: [GIT PULL] Immutable branch between MFD and LEDS due for the v4.12 merge window
From: Jacek Anaszewski @ 2017-03-28 19:37 UTC (permalink / raw)
To: Lee Jones, Sebastian Reichel
Cc: Richard Purdie, Pavel Machek, Tony Lindgren, Rob Herring,
Mark Rutland, linux-leds-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170328081342.5iobnc55sq3zucgt@dell>
On 03/28/2017 10:13 AM, Lee Jones wrote:
> Enjoy!
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-leds-v4.12
>
> for you to fetch changes up to 4f9ab0c1570800002e77515888600ca2e3dce4a9:
>
> mfd: cpcap: Add missing include dependencies (2017-03-28 09:09:50 +0100)
>
> ----------------------------------------------------------------
> Immutable branch between MFD and LEDS due for the v4.12 merge window
>
> ----------------------------------------------------------------
> Sebastian Reichel (1):
> mfd: cpcap: Add missing include dependencies
>
> include/linux/mfd/motorola-cpcap.h | 3 +++
> 1 file changed, 3 insertions(+)
>
Pulled, thanks.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/8] pinctrl: meson: add audio output pins
From: Kevin Hilman @ 2017-03-28 19:33 UTC (permalink / raw)
To: Jerome Brunet
Cc: Linus Walleij, Carlo Caione, linux-gpio, linux-arm-kernel,
linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20170326171923.19269-1-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> This patchset adds the pinctrl definition and the related device-tree
> bindings of the i2s output and spdif output pins on the meson gxbb and
> gxl SoCs.
>
> This is part of the ongoing work to bring audio output support on the
> meson family. It was tested on the gxbb p200 and gxl p230.
>
> Changes since v1: [0]
> * add a few comments in the changelog
> * patched rebased on pinctrl/for-next + Neil patch on missing pins [1]
>
> [0]: https://marc.info/?i=20170323165101.29262-1-jbrunet%40baylibre.com
> [1]: https://marc.info/?i=20170323104112.16558-2-narmstrong%40baylibre.com
>
> Jerome Brunet (8):
> pinctrl: meson: gxbb: add i2s output pins
> pinctrl: meson: gxbb: add spdif output pins
> pinctrl: meson: gxl: add i2s output pins
> pinctrl: meson: gxl: add spdif output pins
> ARM64: dts: meson-gxbb: add i2s output pins
> ARM64: dts: meson-gxbb: add spdif output pins
> ARM64: dts: meson-gxl: add i2s output pins
> ARM64: dts: meson-gxl: add spdif output pins
DT patches applied to amlogic v4.12/dt64 branch,
Thanks for the respin,
Kevin
^ permalink raw reply
* Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: change switch2 label
From: Andrew Lunn @ 2017-03-28 19:33 UTC (permalink / raw)
To: Vivien Didelot
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Shawn Guo,
Florian Fainelli
In-Reply-To: <20170328192426.13798-1-vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
On Tue, Mar 28, 2017 at 03:24:26PM -0400, Vivien Didelot wrote:
> Rename the switch2@0 label of the switch2 node to switch@0 to respect
> the general unit@address DTS rule, and be consistent with the other
> switch nodes of the DTS file.
>
> Signed-off-by: Vivien Didelot <vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
Hi Vivien
You might need to rebase this onto
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
There have been a few other changes to the ZII dts files this cycle.
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
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
* [PATCH] ARM: dts: vf610-zii-dev-rev-b: change switch2 label
From: Vivien Didelot @ 2017-03-28 19:24 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Shawn Guo,
Florian Fainelli, Andrew Lunn, Vivien Didelot
Rename the switch2@0 label of the switch2 node to switch@0 to respect
the general unit@address DTS rule, and be consistent with the other
switch nodes of the DTS file.
Signed-off-by: Vivien Didelot <vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 7940408838df..5a93f2d875b1 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -239,7 +239,7 @@
#size-cells = <0>;
reg = <4>;
- switch2: switch2@0 {
+ switch2: switch@0 {
compatible = "marvell,mv88e6085";
#address-cells = <1>;
#size-cells = <0>;
--
2.12.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
* Re: [RESEND PATCH v3 1/2] dt-bindings: i2c: Add Mediatek MT2701 i2c binding
From: Wolfram Sang @ 2017-03-28 19:22 UTC (permalink / raw)
To: Jun Gao
Cc: Matthias Brugger, robh-DgEjT+Ai2ygdnm+yROfE0A,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <1490694612.18582.11.camel@mhfsdcap03>
[-- Attachment #1: Type: text/plain, Size: 2709 bytes --]
On Tue, Mar 28, 2017 at 05:50:12PM +0800, Jun Gao wrote:
> On Wed, 2017-03-22 at 10:05 +0100, Wolfram Sang wrote:
> > On Thu, Mar 09, 2017 at 11:13:04AM +0800, Jun Gao wrote:
> > > From: Jun Gao <jun.gao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > >
> > > Add MT2701 i2c binding to i2c-mt6577.txt and there is no need to
> > > modify i2c driver.
> > >
> > > Signed-off-by: Jun Gao <jun.gao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >
> > There is still the issue which Matthias Brugger pointed out on January,
> > 24th: you need to describe the fallback compatibles.
> >
>
> IMHO the value under compatible are just inputs which can be accepted.
> It's little strange to add fallback information in binding. Some other
> bindings do not describe so detailedly.
> Is it OK to make binding as minimum standard?
> If we describe it very detailedly, we will have to modify binding if
> there are some changes for mt2701.
My reading of the below is that I could simply use "mediatek,mt2701-i2c"
as compatible and things will work. But it won't, we don't have that in
the driver IIRC. So, we need a fallback for that to work.
> Rob, could you give some suggestions? Thanks!
Would be welcome, yes. I lost track what the preferred solution is.
>
> > > ---
> > > .../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++++++-----
> > > 1 file changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
> > > index 0ce6fa3..27dbbf9 100644
> > > --- a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
> > > +++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
> > > @@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with I2C devices.
> > >
> > > Required properties:
> > > - compatible: value should be either of the following.
> > > - (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
> > > - (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
> > > - (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
> > > - (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
> > > - (e) "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
> > > + "mediatek,mt2701-i2c"
> > > + "mediatek,mt6577-i2c"
> > > + "mediatek,mt6589-i2c"
> > > + "mediatek,mt8127-i2c"
> > > + "mediatek,mt8135-i2c"
> > > + "mediatek,mt8173-i2c"
> > > - reg: physical base address of the controller and dma base, length of memory
> > > mapped region.
> > > - interrupts: interrupt number to the cpu.
> > > --
> > > 1.7.9.5
> > >
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2,1/3] meson_uart: expose CLKID_UARTx
From: Jerome Brunet @ 2017-03-28 19:14 UTC (permalink / raw)
To: Helmut Klein, mturquette, sboyd
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel
In-Reply-To: <71489b62-78c8-7082-587e-8598dc43ca59@gmail.com>
On Tue, 2017-03-28 at 20:18 +0200, Helmut Klein wrote:
> i know for sure that the bluetooth chip of my system is connected to
> uart_A. so this clock must be exposed.
>
> i don't know if the other 2 uarts are used on other hardware. so i will
> remove them from my patch.
What I meant is device trees "upstream".
I would expect such patch as part of a series to add support for your board in
device-tree, with its bluetooth chipset.
I think it would better to drop this patch from the series.
You can either keep it for your personal work, or send it again when upstreaming
the support for your board and/or add the support for the bluetooth chip.
Cheers
Jerome
>
> Helmut
>
> On 28.03.2017 17:51, Jerome Brunet wrote:
> > On Tue, 2017-03-28 at 11:25 +0200, Helmut Klein wrote:
> > > Expose the clock ids for the three none AO uarts to the dt-bindings
> >
> > Are they all used in the device tree ?
> > We try to only expose what we need in the DT
> > The recent discussion over CLKID_CPUCLK proved it was a sane thing to do.
> >
> > >
> > > Signed-off-by: Helmut Klein <hgkr.klein@gmail.com>
> > > ---
> > > drivers/clk/meson/gxbb.h | 6 +++---
> > > include/dt-bindings/clock/gxbb-clkc.h | 3 +++
> > > 2 files changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> > > index 8ee2022ce5d5..1edfaa5fe307 100644
> > > --- a/drivers/clk/meson/gxbb.h
> > > +++ b/drivers/clk/meson/gxbb.h
> > > @@ -194,7 +194,7 @@
> > > /* #define CLKID_SAR_ADC */
> > > #define CLKID_SMART_CARD 24
> > > #define CLKID_RNG0 25
> > > -#define CLKID_UART0 26
> > > +/* CLKID_UART0 */
> > > #define CLKID_SDHC 27
> > > #define CLKID_STREAM 28
> > > #define CLKID_ASYNC_FIFO 29
> > > @@ -216,7 +216,7 @@
> > > #define CLKID_ADC 45
> > > #define CLKID_BLKMV 46
> > > #define CLKID_AIU 47
> > > -#define CLKID_UART1 48
> > > +/* CLKID_UART1 */
> > > #define CLKID_G2D 49
> > > /* CLKID_USB0 */
> > > /* CLKID_USB1 */
> > > @@ -236,7 +236,7 @@
> > > /* CLKID_USB0_DDR_BRIDGE */
> > > #define CLKID_MMC_PCLK 66
> > > #define CLKID_DVIN 67
> > > -#define CLKID_UART2 68
> > > +/* CLKID_UART2 */
> > > /* #define CLKID_SANA */
> > > #define CLKID_VPU_INTR 70
> > > #define CLKID_SEC_AHB_AHB3_BRIDGE 71
> > > diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-
> > > bindings/clock/gxbb-clkc.h
> > > index 692846c7941b..7b329df47752 100644
> > > --- a/include/dt-bindings/clock/gxbb-clkc.h
> > > +++ b/include/dt-bindings/clock/gxbb-clkc.h
> > > @@ -15,13 +15,16 @@
> > > #define CLKID_SPI 34
> > > #define CLKID_I2C 22
> > > #define CLKID_SAR_ADC 23
> > > +#define CLKID_UART0 26
> > > #define CLKID_ETH 36
> > > +#define CLKID_UART1 48
> > > #define CLKID_USB0 50
> > > #define CLKID_USB1 51
> > > #define CLKID_USB 55
> > > #define CLKID_HDMI_PCLK 63
> > > #define CLKID_USB1_DDR_BRIDGE 64
> > > #define CLKID_USB0_DDR_BRIDGE 65
> > > +#define CLKID_UART2 68
> > > #define CLKID_SANA 69
> > > #define CLKID_GCLK_VENCI_INT0 77
> > > #define CLKID_AO_I2C 93
> > > --
> > > 2.11.0
> > >
> > >
> > > _______________________________________________
> > > linux-amlogic mailing list
> > > linux-amlogic@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* [RFC PATCH] of: Fix DMA configuration for non-DT masters
From: Robin Murphy @ 2017-03-28 18:57 UTC (permalink / raw)
To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
For PCI masters not represented in DT, we pass the OF node of their
associated host bridge to of_dma_configure(), such that they can inherit
the appropriate DMA configuration from whatever is described there.
Unfortunately, whilst this has worked for the "dma-coherent" property,
it turns out to miss the case where the host bridge node has a non-empty
"dma-ranges", since nobody is expecting the 'device' to be a bus itself.
It transpires, though, that the de-facto interface since the prototype
change in 1f5c69aa51f9 ("of: Move of_dma_configure() to device.c to help
re-use") is very clear-cut: either the master_np argument is redundant
with dev->of_node, or dev->of_node is NULL and master_np is the relevant
parent bus. Let's ratify that behaviour, then teach the whole
of_dma_configure() pipeline to cope with both cases properly.
Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
---
This is what I'd consider the better fix - rather than adding yet more
special cases - which will also make it simple to handle multiple
"dma-ranges" entries with minimal further disruption. The callers now
left passing dev->of_node as 'parent' are harmless, but look a bit silly
and clearly want cleaning up - I'd be partial to renaming the existing
function and having a single-argument wrapper for the 'normal' case, e.g.:
static inline int of_dma_configure(struct device_node *dev)
{
return of_dma_configure_parent(dev, NULL);
}
Thoughts?
Robin.
drivers/iommu/of_iommu.c | 7 ++++---
drivers/of/address.c | 37 +++++++++++++++++++++++++------------
drivers/of/device.c | 12 +++++++-----
include/linux/of_address.h | 7 ++++---
include/linux/of_device.h | 4 ++--
include/linux/of_iommu.h | 4 ++--
6 files changed, 44 insertions(+), 27 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 2683e9fc0dcf..35aff07bb5eb 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -138,21 +138,22 @@ static const struct iommu_ops
}
const struct iommu_ops *of_iommu_configure(struct device *dev,
- struct device_node *master_np)
+ struct device_node *parent)
{
struct of_phandle_args iommu_spec;
- struct device_node *np;
+ struct device_node *np, *master_np;
const struct iommu_ops *ops = NULL;
int idx = 0;
if (dev_is_pci(dev))
- return of_pci_iommu_configure(to_pci_dev(dev), master_np);
+ return of_pci_iommu_configure(to_pci_dev(dev), parent);
/*
* We don't currently walk up the tree looking for a parent IOMMU.
* See the `Notes:' section of
* Documentation/devicetree/bindings/iommu/iommu.txt
*/
+ master_np = dev->of_node ? dev->of_node : parent;
while (!of_parse_phandle_with_args(master_np, "iommus",
"#iommu-cells", idx,
&iommu_spec)) {
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903fe9d2..833bc17f5e55 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -808,6 +808,7 @@ EXPORT_SYMBOL(of_io_request_and_map);
/**
* of_dma_get_range - Get DMA range info
* @np: device node to get DMA range info
+ * @parent: node of device's parent bus, if @np is NULL
* @dma_addr: pointer to store initial DMA address of DMA range
* @paddr: pointer to store initial CPU address of DMA range
* @size: pointer to store size of DMA range
@@ -822,36 +823,48 @@ EXPORT_SYMBOL(of_io_request_and_map);
* It returns -ENODEV if "dma-ranges" property was not found
* for this device in DT.
*/
-int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
+int of_dma_get_range(struct device_node *np, struct device_node *parent,
+ u64 *dma_addr, u64 *paddr, u64 *size)
{
- struct device_node *node = of_node_get(np);
+ struct device_node *node;
const __be32 *ranges = NULL;
int len, naddr, nsize, pna;
int ret = 0;
u64 dmaaddr;
- if (!node)
- return -EINVAL;
-
- while (1) {
+ if (np) {
+ node = of_node_get(np);
naddr = of_n_addr_cells(node);
nsize = of_n_size_cells(node);
node = of_get_next_parent(node);
- if (!node)
- break;
+ } else if (parent) {
+ node = of_node_get(parent);
+ np = parent;
+ if (of_property_read_u32(node, "#address-cells", &naddr))
+ naddr = of_n_addr_cells(node);
+ if (of_property_read_u32(node, "#size-cells", &nsize))
+ nsize = of_n_size_cells(node);
+ } else {
+ return -EINVAL;
+ }
+ while (node) {
ranges = of_get_property(node, "dma-ranges", &len);
- /* Ignore empty ranges, they imply no translation required */
- if (ranges && len > 0)
- break;
-
/*
* At least empty ranges has to be defined for parent node if
* DMA is supported
*/
if (!ranges)
break;
+
+ /* Ignore empty ranges, they imply no translation required */
+ if (len > 0)
+ break;
+
+ naddr = of_n_addr_cells(node);
+ nsize = of_n_size_cells(node);
+ node = of_get_next_parent(node);
}
if (!ranges) {
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 9bb8518b28f2..57ec5324ed6c 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -73,7 +73,8 @@ int of_device_add(struct platform_device *ofdev)
/**
* of_dma_configure - Setup DMA configuration
* @dev: Device to apply DMA configuration
- * @np: Pointer to OF node having DMA configuration
+ * @parent: OF node of device's parent bus, if @dev is not
+ * represented in DT (i.e. @dev->of_node is NULL)
*
* Try to get devices's DMA configuration from DT and update it
* accordingly.
@@ -82,13 +83,14 @@ int of_device_add(struct platform_device *ofdev)
* can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
* to fix up DMA configuration.
*/
-void of_dma_configure(struct device *dev, struct device_node *np)
+void of_dma_configure(struct device *dev, struct device_node *parent)
{
u64 dma_addr, paddr, size;
int ret;
bool coherent;
unsigned long offset;
const struct iommu_ops *iommu;
+ struct device_node *np = dev->of_node;
/*
* Set default coherent_dma_mask to 32 bit. Drivers are expected to
@@ -104,7 +106,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
if (!dev->dma_mask)
dev->dma_mask = &dev->coherent_dma_mask;
- ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ ret = of_dma_get_range(np, parent, &dma_addr, &paddr, &size);
if (ret < 0) {
dma_addr = offset = 0;
size = dev->coherent_dma_mask + 1;
@@ -132,11 +134,11 @@ void of_dma_configure(struct device *dev, struct device_node *np)
dev->coherent_dma_mask = DMA_BIT_MASK(ilog2(dma_addr + size));
*dev->dma_mask = dev->coherent_dma_mask;
- coherent = of_dma_is_coherent(np);
+ coherent = of_dma_is_coherent(np ? np : parent);
dev_dbg(dev, "device is%sdma coherent\n",
coherent ? " " : " not ");
- iommu = of_iommu_configure(dev, np);
+ iommu = of_iommu_configure(dev, parent);
dev_dbg(dev, "device is%sbehind an iommu\n",
iommu ? " " : " not ");
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 37864734ca50..f1a507f3ae57 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -52,8 +52,8 @@ extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
extern struct of_pci_range *of_pci_range_parser_one(
struct of_pci_range_parser *parser,
struct of_pci_range *range);
-extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size);
+extern int of_dma_get_range(struct device_node *np, struct device_node *parent,
+ u64 *dma_addr, u64 *paddr, u64 *size);
extern bool of_dma_is_coherent(struct device_node *np);
#else /* CONFIG_OF_ADDRESS */
static inline void __iomem *of_io_request_and_map(struct device_node *device,
@@ -95,7 +95,8 @@ static inline struct of_pci_range *of_pci_range_parser_one(
return NULL;
}
-static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
+static inline int of_dma_get_range(struct device_node *np,
+ struct device_node *parent, u64 *dma_addr,
u64 *paddr, u64 *size)
{
return -ENODEV;
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index c12dace043f3..bcd2b6fbeef3 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -55,7 +55,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
return of_node_get(cpu_dev->of_node);
}
-void of_dma_configure(struct device *dev, struct device_node *np);
+void of_dma_configure(struct device *dev, struct device_node *parent);
#else /* CONFIG_OF */
static inline int of_driver_match_device(struct device *dev,
@@ -103,7 +103,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
{
return NULL;
}
-static inline void of_dma_configure(struct device *dev, struct device_node *np)
+static inline void of_dma_configure(struct device *dev, struct device_node *parent)
{}
#endif /* CONFIG_OF */
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 13394ac83c66..c02b62e8e6ed 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -12,7 +12,7 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
size_t *size);
extern const struct iommu_ops *of_iommu_configure(struct device *dev,
- struct device_node *master_np);
+ struct device_node *parent);
#else
@@ -24,7 +24,7 @@ static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
}
static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
- struct device_node *master_np)
+ struct device_node *parent)
{
return NULL;
}
--
2.11.0.dirty
^ permalink raw reply related
* Re: [PATCH] arm64: tegra: Add CPU and PSCI nodes for NVIDIA Tegra210 platforms
From: Mark Rutland @ 2017-03-28 18:54 UTC (permalink / raw)
To: Jon Hunter
Cc: Stephen Warren, devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren,
Vagrant Cascadian, Thierry Reding,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Martin Michlmayr,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <f9c59c65-de48-108d-73df-c659cc3300e6-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Tue, Mar 28, 2017 at 05:49:41PM +0100, Jon Hunter wrote:
>
> On 28/03/17 17:23, Stephen Warren wrote:
> > On 03/28/2017 05:48 AM, Jon Hunter wrote:
> >> Add the CPU and PSCI nodes for the NVIDIA Tegra210 platforms so that
> >> all CPUs can be enabled on boot. This assumes that the PSCI firmware
> >> has been loaded during the initial bootstrap on the device before the
> >> kernel starts (which is typically the case for these platforms). The
> >> PSCI firmware version is set to v0.2 which aligns with the current
> >> shipping version for Tegra.
> >
> > This seems fine, although I'd expect PSCI to be used everywhere on
> > Tegra, so putting this in tegra210.dtsi would make more sense.
>
> It's fine with me. Although technically, tegra210-smaug ships with
> psci-v1.0 and tegra210-jetson-tx1 currently have psci-v0.2. However, I
> did test both with the psci version set to v1.0 and the jetson-tx1, did
> detect the version automatically and reverted to v0.2 (which is a
> feature of psci >= v0.2).
Please don't rely upon that.
If the DT lists 0.2 and the FW reports 1.0 we deliberately upgrade and
treat it as 1.0, but the other way around was not a deliberate decision.
If the FW is not necessarily 1.0, please do not list 1.0 in the DT.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2, 2/3] tty/serial: meson_uart: add documentation for the dt-bindings
From: Helmut Klein @ 2017-03-28 18:20 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree, robh+dt, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <20170328100551.GA24221@leverpostej>
Hallo Mark,
i will add your text to the patch.
Helmut
On 28.03.2017 12:05, Mark Rutland wrote:
> On Tue, Mar 28, 2017 at 11:25:44AM +0200, Helmut Klein wrote:
>> Add the documentation for the device tree binding of meson_uart
>>
>> Signed-off-by: Helmut Klein <hgkr.klein@gmail.com>
>> ---
>> .../bindings/serial/amlogic,meson_uart.txt | 25 ++++++++++++++++++++++
>> 1 file changed, 25 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson_uart.txt
>>
>> diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson_uart.txt b/Documentation/devicetree/bindings/serial/amlogic,meson_uart.txt
>> new file mode 100644
>> index 000000000000..6f94ba25760d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/amlogic,meson_uart.txt
>> @@ -0,0 +1,25 @@
>> +* Amlogic Meson UART, used in multiple SoCs (e.g. S905, s905X, ...)
>> +
>> +Required properties:
>> +- compatible : "amlogic,meson-uart"
>> +- reg : offset and length of the register set for the device.
>> +- interrupts : device interrupt
>> +- clocks : the baud rate clock for the UART and optionally the core clock for the none AO uarts
>> +e.g.
>> +uart_A: serial@84c0 {
>> + compatible = "amlogic,meson-uart";
>> + reg = <0x0 0x84c0 0x0 0x14>;
>> + pinctrl-0 = <&uart_a_pins &uart_a_cts_rts_pins>;
>> + interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&xtal>, <&clkc CLKID_UART0>;
>> + clock-names = "xtal", "core";
>
> Please define these explicitly above, e.g.
>
> - clocks: a list of phandle + clock-specifier pairs, one for each entry
> in clock names.
> - clock-names: contains:
> * "xtal" for the baud rate clock
> * "core" for the non-AO UARTs (optional)
>
> Thanks,
> Mark.
>
^ permalink raw reply
* Re: [PATCH v2,1/3] meson_uart: expose CLKID_UARTx
From: Helmut Klein @ 2017-03-28 18:18 UTC (permalink / raw)
To: Jerome Brunet, mturquette, sboyd
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <1490716277.20764.6.camel@baylibre.com>
i know for sure that the bluetooth chip of my system is connected to
uart_A. so this clock must be exposed.
i don't know if the other 2 uarts are used on other hardware. so i will
remove them from my patch.
Helmut
On 28.03.2017 17:51, Jerome Brunet wrote:
> On Tue, 2017-03-28 at 11:25 +0200, Helmut Klein wrote:
>> Expose the clock ids for the three none AO uarts to the dt-bindings
>
> Are they all used in the device tree ?
> We try to only expose what we need in the DT
> The recent discussion over CLKID_CPUCLK proved it was a sane thing to do.
>
>>
>> Signed-off-by: Helmut Klein <hgkr.klein@gmail.com>
>> ---
>> drivers/clk/meson/gxbb.h | 6 +++---
>> include/dt-bindings/clock/gxbb-clkc.h | 3 +++
>> 2 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
>> index 8ee2022ce5d5..1edfaa5fe307 100644
>> --- a/drivers/clk/meson/gxbb.h
>> +++ b/drivers/clk/meson/gxbb.h
>> @@ -194,7 +194,7 @@
>> /* #define CLKID_SAR_ADC */
>> #define CLKID_SMART_CARD 24
>> #define CLKID_RNG0 25
>> -#define CLKID_UART0 26
>> +/* CLKID_UART0 */
>> #define CLKID_SDHC 27
>> #define CLKID_STREAM 28
>> #define CLKID_ASYNC_FIFO 29
>> @@ -216,7 +216,7 @@
>> #define CLKID_ADC 45
>> #define CLKID_BLKMV 46
>> #define CLKID_AIU 47
>> -#define CLKID_UART1 48
>> +/* CLKID_UART1 */
>> #define CLKID_G2D 49
>> /* CLKID_USB0 */
>> /* CLKID_USB1 */
>> @@ -236,7 +236,7 @@
>> /* CLKID_USB0_DDR_BRIDGE */
>> #define CLKID_MMC_PCLK 66
>> #define CLKID_DVIN 67
>> -#define CLKID_UART2 68
>> +/* CLKID_UART2 */
>> /* #define CLKID_SANA */
>> #define CLKID_VPU_INTR 70
>> #define CLKID_SEC_AHB_AHB3_BRIDGE 71
>> diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-
>> bindings/clock/gxbb-clkc.h
>> index 692846c7941b..7b329df47752 100644
>> --- a/include/dt-bindings/clock/gxbb-clkc.h
>> +++ b/include/dt-bindings/clock/gxbb-clkc.h
>> @@ -15,13 +15,16 @@
>> #define CLKID_SPI 34
>> #define CLKID_I2C 22
>> #define CLKID_SAR_ADC 23
>> +#define CLKID_UART0 26
>> #define CLKID_ETH 36
>> +#define CLKID_UART1 48
>> #define CLKID_USB0 50
>> #define CLKID_USB1 51
>> #define CLKID_USB 55
>> #define CLKID_HDMI_PCLK 63
>> #define CLKID_USB1_DDR_BRIDGE 64
>> #define CLKID_USB0_DDR_BRIDGE 65
>> +#define CLKID_UART2 68
>> #define CLKID_SANA 69
>> #define CLKID_GCLK_VENCI_INT0 77
>> #define CLKID_AO_I2C 93
>> --
>> 2.11.0
>>
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
^ permalink raw reply
* Re: [PATCH v4 2/3] mailbox: Add iProc mailbox controller driver
From: Jonathan Richardson @ 2017-03-28 17:30 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Russell King, Vikram Prakash, Devicetree List,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
BCM Kernel Feedback
In-Reply-To: <CABb+yY1kbFOKJPO95SRw995zt=fCoA+SkXgECOj774i_hJUCNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 17-03-15 10:30 AM, Jassi Brar wrote:
> On Fri, Mar 3, 2017 at 2:33 AM, Jonathan Richardson
> <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>
>> On 17-02-23 09:00 PM, Jassi Brar wrote:
>>> On Fri, Feb 24, 2017 at 12:29 AM, Jonathan Richardson
>>> <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>>> On 17-02-16 10:20 PM, Jassi Brar wrote:
>>>>> On Fri, Jan 27, 2017 at 2:08 AM, Jonathan Richardson
>>>>> <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>>>>
>>>>>> +static int iproc_mbox_send_data_m0(struct mbox_chan *chan, void *data)
>>>>>> +{
>>>>>> + struct iproc_mbox *mbox = dev_get_drvdata(chan->mbox->dev);
>>>>>> + struct iproc_mbox_msg *msg = (struct iproc_mbox_msg *)data;
>>>>>> + unsigned long flags;
>>>>>> + int err = 0;
>>>>>> + const int poll_period_us = 5;
>>>>>> + const int max_retries = (MAX_M0_TIMEOUT_MS * 1000) / poll_period_us;
>>>>>> +
>>>>>> + if (!msg)
>>>>>> + return -EINVAL;
>>>>>> +
>>>>>> + spin_lock_irqsave(&mbox->lock, flags);
>>>>>> +
>>>>>> + dev_dbg(mbox->dev, "Send msg to M0: cmd=0x%x, param=0x%x, wait_ack=%d\n",
>>>>>> + msg->cmd, msg->param, msg->wait_ack);
>>>>>> +
>>>>> prints should be outside the spinlocks.
>>>>>
>>>>>> + writel(msg->cmd, mbox->base + IPROC_CRMU_MAILBOX0_OFFSET);
>>>>>> + writel(msg->param, mbox->base + IPROC_CRMU_MAILBOX1_OFFSET);
>>>>>> +
>>>>>> + if (msg->wait_ack) {
>>>>>> + int retries;
>>>>>> +
>>>>> move poll_period_us and max_retries in here or just define' them
>>>>>
>>>>>> + err = msg->reply_code = -ETIMEDOUT;
>>>>>> + for (retries = 0; retries < max_retries; retries++) {
>>>>>> + u32 val = readl(
>>>>>> + mbox->base + IPROC_CRMU_MAILBOX0_OFFSET);
>>>>>> + if (val & M0_IPC_CMD_DONE_MASK) {
>>>>>> + /*
>>>>>> + * M0 replied - save reply code and
>>>>>> + * clear error.
>>>>>> + */
>>>>>> + msg->reply_code = (val &
>>>>>> + M0_IPC_CMD_REPLY_MASK) >>
>>>>>> + M0_IPC_CMD_REPLY_SHIFT;
>>>>>> + err = 0;
>>>>>> + break;
>>>>>> + }
>>>>>> + udelay(poll_period_us);
>>>>>>
>>>>> potentially 2ms inside spin_lock_irqsave. Alternative is to implement
>>>>> a simple 'peek_data' and call it for requests with 'wait_ack'
>>>> Hi Jassi. The M0 response is normally 25-30 us.
>>>>
>>> You hardcode the behaviour of your protocol in the controller driver.
>>> What if your next platform/protocol has commands that the remote/M0
>>> takes upto 10ms to respond (because they are not critical/trivial)?
>>>
> You overlooked this concern?
>
>>> If you don't have some h/w indicator (like irq or bit-flag) for
>>> tx-done and data-rx , you have to use ack-by-client and peek method.
>> There isn't any functionality not in the driver. We write the message to two registers and poll another to know when it's complete. Nothing can touch the registers again until the operation is complete. We can't even pass data back to the controller. We pass pointers to the M0 and it can write to the memory. The only data we sent back to the client is that status code from the polled register. When complete, data will already be written into the clients memory from the M0.
>>> Commands that don't get a response will be immediately followed by
>>> mbox_client_txdone(), while others would need to call peek_data() to
>>> poll for data-rx. Please note, if you implement the tx_prepare
>>> callback, you will know when to start peeking for incoming data.
>> The driver will need to block access to the registers if we remove the spinlock.
>> If a client sends a message that doesn't get a response and another client has
>> already sent a message that does which is pending, it still needs to be blocked.
>>
>> The framework queues messages on a per channel basis. We have several clients for
>> various drivers each with their own mbox channel. send_data in the controller could
>> return EBUSY if the channel is being used by another channel (ie- transaction pending).
>> If channel A sends a message, then client B sends one before A is complete, the
>> controller's send_data must return an error.
>>
> Many platforms have clients sharing channels.
Hi Jassi. Could you point me to one? I've looked at all of them and don't see any of them sharing channels.
> The right way to do is have a 'server/owner' client that accepts
> requests from various clients and serially queue them to mailbox. That
> way you can keep the controller driver free from quirks (like max wait
> time of 30us) of your present platform.
Do you mean 1 mailbox client with one mailbox channel that all the mbox client drivers share? I thought this would work when I suggested it previously but the client callbacks are necessary in all txdone modes. Client drivers that send the messages need the callbacks and this is only possible with multiple mbox clients. And a channel can only have 1 mbox client. Clients in multiple drivers need the callbacks to either know when to start polling, or be notified when the transaction is complete. It would be nice if multiple clients could use the same channel.
Thanks.
> thanks
--
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
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