* Re: [PATCH v2 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family
From: Shawn Guo @ 2017-01-20 6:08 UTC (permalink / raw)
To: Baoyou Xie
Cc: jun.nie-QSEj5FYQhm4dnm+yROfE0A, wim-IQzOog9fTRqzQB+pC5nmwQ,
linux-0h96xk9xTtrk1uMJSBkQmQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1484791192-31674-3-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Jan 19, 2017 at 09:59:52AM +0800, Baoyou Xie wrote:
> This patch adds watchdog controller driver for ZTE's zx2967 family.
>
> Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/watchdog/Kconfig | 10 ++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/zx2967_wdt.c | 383 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 394 insertions(+)
> create mode 100644 drivers/watchdog/zx2967_wdt.c
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index acb00b5..05093a2 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -714,6 +714,16 @@ config ASPEED_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called aspeed_wdt.
>
> +config ZX2967_WATCHDOG
> + tristate "ZTE zx2967 SoCs watchdog support"
> + depends on ARCH_ZX
> + select WATCHDOG_CORE
> + help
> + Say Y here to include support for the watchdog timer
> + in ZTE zx2967 SoCs.
> + To compile this driver as a module, choose M here: the
> + module will be called zx2967_wdt.
> +
> # AVR32 Architecture
>
> config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 0c3d35e..bf2d296 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -82,6 +82,7 @@ obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
> obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
> obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
> obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
> +obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
>
> # AVR32 Architecture
> obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
> new file mode 100644
> index 0000000..35eaecd
> --- /dev/null
> +++ b/drivers/watchdog/zx2967_wdt.c
> @@ -0,0 +1,383 @@
> +/*
> + * watchdog driver for ZTE's zx2967 family
> + *
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> + *
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/reboot.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <linux/watchdog.h>
> +
> +#define ZX2967_WDT_CFG_REG 0x4
> +#define ZX2967_WDT_LOAD_REG 0x8
> +#define ZX2967_WDT_REFRESH_REG 0x18
> +#define ZX2967_WDT_START_REG 0x1c
> +
> +#define ZX2967_WDT_REFRESH_MASK 0x3f
> +
> +#define ZX2967_WDT_CFG_DIV(n) ((((n) & 0xff) - 1) << 8)
> +#define ZX2967_WDT_START_EN 0x1
> +
> +#define ZX2967_WDT_WRITEKEY 0x12340000
> +
> +#define ZX2967_WDT_DIV_DEFAULT 16
> +#define ZX2967_WDT_DEFAULT_TIMEOUT 32
> +#define ZX2967_WDT_MIN_TIMEOUT 1
> +#define ZX2967_WDT_MAX_TIMEOUT 500
> +#define ZX2967_WDT_MAX_COUNT 0xffff
> +
> +#define ZX2967_WDT_FLAG_REBOOT_MON (1 << 0)
> +
> +#define ZX2967_RESET_MASK_REG 0xb0
> +
> +struct zx2967_wdt {
> + struct device *dev;
> + struct clk *clock;
> + void __iomem *reg_base;
> + unsigned int conf;
> + unsigned int load;
> + unsigned int flags;
> + struct watchdog_device wdt_device;
> + struct notifier_block restart_handler;
> + struct notifier_block reboot_handler;
> +};
> +
> +#define zx2967_wdt_read_reg(r) readl_relaxed(r)
> +
> +static inline void
> +zx2967_wdt_write_reg(u32 val, void __iomem *addr)
> +{
> + writel_relaxed(val | ZX2967_WDT_WRITEKEY, addr);
> +}
static inline u32 zx2967_wdt_readl(struct zx2967_wdt *wdt, u16 reg)
{
return readl_relaxed(wdt->reg_base + reg);
}
static inline void zx2967_wdt_writel(struct zx2967_wdt *wdt, u16 reg, u32 val)
{
writel_relaxed(val | ZX2967_WDT_WRITEKEY, wdt->reg_base + reg);
}
This is what I would suggest to make the caller a bit easier. Anyway,
it's just a suggestion, not a strong opinion.
> +
> +static void zx2967_wdt_refresh(struct zx2967_wdt *wdt)
> +{
> + u32 val;
> +
> + val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_REFRESH_REG);
> + val ^= ZX2967_WDT_REFRESH_MASK;
> + zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_REFRESH_REG);
> +}
> +
> +static unsigned int
> +__zx2967_wdt_set_timeout(struct zx2967_wdt *wdt, unsigned int timeout)
> +{
> + unsigned int freq = clk_get_rate(wdt->clock);
> + unsigned int divisor = ZX2967_WDT_DIV_DEFAULT;
> + unsigned int count;
> +
> + count = timeout * freq;
> + if (count > divisor * ZX2967_WDT_MAX_COUNT)
> + divisor = DIV_ROUND_UP(count, ZX2967_WDT_MAX_COUNT);
> + count = DIV_ROUND_UP(count, divisor);
> + zx2967_wdt_write_reg(ZX2967_WDT_CFG_DIV(divisor),
> + wdt->reg_base + ZX2967_WDT_CFG_REG);
> + zx2967_wdt_write_reg(count, wdt->reg_base + ZX2967_WDT_LOAD_REG);
> + zx2967_wdt_refresh(wdt);
> + wdt->load = count;
> +
> + return (count * divisor) / freq;
> +}
> +
> +static int zx2967_wdt_set_timeout(struct watchdog_device *wdd,
> + unsigned int timeout)
> +{
> + struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + if (watchdog_timeout_invalid(&wdt->wdt_device, timeout)) {
> + dev_err(wdt->dev, "timeout %d is invalid\n", timeout);
> + return -EINVAL;
> + }
> +
> + wdd->timeout = __zx2967_wdt_set_timeout(wdt, timeout);
> +
> + return 0;
> +}
> +
> +static void __zx2967_wdt_start(struct zx2967_wdt *wdt)
> +{
> + u32 val;
> +
> + val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_START_REG);
> + val |= ZX2967_WDT_START_EN;
> + zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_START_REG);
> +}
> +
> +static void __zx2967_wdt_stop(struct zx2967_wdt *wdt)
> +{
> + u32 val;
> +
> + val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_START_REG);
> + val &= ~ZX2967_WDT_START_EN;
> + zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_START_REG);
> +}
> +
> +static int zx2967_wdt_start(struct watchdog_device *wdd)
> +{
> + struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + __zx2967_wdt_stop(wdt);
> + zx2967_wdt_set_timeout(wdd, wdd->timeout);
> + __zx2967_wdt_start(wdt);
> +
> + return 0;
> +}
> +
> +static int zx2967_wdt_stop(struct watchdog_device *wdd)
> +{
> + struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + __zx2967_wdt_stop(wdt);
> +
> + return 0;
> +}
> +
> +static int zx2967_wdt_keepalive(struct watchdog_device *wdd)
> +{
> + struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + zx2967_wdt_refresh(wdt);
> +
> + return 0;
> +}
> +
> +#define ZX2967_WDT_OPTIONS \
> + (WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE)
> +static const struct watchdog_info zx2967_wdt_ident = {
> + .options = ZX2967_WDT_OPTIONS,
> + .firmware_version = 0,
> + .identity = "zx2967 watchdog",
> +};
> +
> +static struct watchdog_ops zx2967_wdt_ops = {
> + .owner = THIS_MODULE,
> + .start = zx2967_wdt_start,
> + .stop = zx2967_wdt_stop,
> + .ping = zx2967_wdt_keepalive,
> + .set_timeout = zx2967_wdt_set_timeout,
> +};
> +
> +static void zx2967_wdt_fix_sysdown(struct zx2967_wdt *wdt)
> +{
> + __zx2967_wdt_stop(wdt);
> + __zx2967_wdt_set_timeout(wdt, 15);
> + __zx2967_wdt_start(wdt);
> +}
> +
> +static int zx2967_wdt_notify_sys(struct notifier_block *this,
> + unsigned long code, void *unused)
> +{
> + struct zx2967_wdt *wdt = container_of(this, struct zx2967_wdt,
> + reboot_handler);
> +
> + wdt->flags |= ZX2967_WDT_FLAG_REBOOT_MON;
> + switch (code) {
> + case SYS_HALT:
> + case SYS_POWER_OFF:
> + case SYS_RESTART:
> + zx2967_wdt_fix_sysdown(wdt);
> + break;
> + default:
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static int zx2967_wdt_restart(struct notifier_block *this,
> + unsigned long mode, void *cmd)
> +{
> + struct zx2967_wdt *wdt;
> +
> + wdt = container_of(this, struct zx2967_wdt, restart_handler);
> +
> + zx2967_wdt_stop(&wdt->wdt_device);
> +
> + zx2967_wdt_write_reg(0x80, wdt->reg_base + ZX2967_WDT_LOAD_REG);
> + zx2967_wdt_refresh(wdt);
> + zx2967_wdt_write_reg(ZX2967_WDT_START_EN,
> + wdt->reg_base + ZX2967_WDT_START_REG);
> +
> + zx2967_wdt_start(&wdt->wdt_device);
> + /* wait for reset*/
> + mdelay(500);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static void zx2967_wdt_reset_sysctrl(struct device *dev)
> +{
> + int ret;
> + struct device_node *np = NULL;
> + void __iomem *regmap;
> + unsigned int val, mask, config;
> + struct of_phandle_args out_args;
> +
> + ret = of_parse_phandle_with_fixed_args(dev->of_node,
> + "wdt-reset-sysctrl", 2, 0, &out_args);
> + if (ret) {
> + dev_info(dev, "have no wdt-reset-sysctrl node");
wdt-reset-sysctrl is not a node but a property. Also, the call can fail
on other reasons, e.g. the arguments are not two. So I suggest the
message like "failed to parse wdt-reset-sysctrl".
> + return;
> + }
> + config = out_args.args[0];
> + mask = out_args.args[1];
> +
> + regmap = syscon_node_to_regmap(out_args.np);
> + if (IS_ERR(regmap))
> + goto out;
> +
> + ret = regmap_read(regmap, ZX2967_RESET_MASK_REG, &val);
I think this register offset can also be an argument of phandle in
device tree.
> +
> + val &= ~mask;
> + val |= config;
> + regmap_write(regmap, ZX2967_RESET_MASK_REG, val);
regmap_update_bits() can be used.
> +out:
> + of_node_put(np);
> +}
> +
> +static int zx2967_wdt_probe(struct platform_device *pdev)
> +{
> + struct device *dev;
> + struct zx2967_wdt *wdt;
> + struct resource *base;
> + int err, ret = 0;
> + unsigned int rate;
> +
> + struct reset_control *rstc;
> +
> + dev = &pdev->dev;
> +
> + wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
> + if (!wdt)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, wdt);
> +
> + wdt->dev = dev;
> + wdt->wdt_device.info = &zx2967_wdt_ident;
> + wdt->wdt_device.ops = &zx2967_wdt_ops;
> + wdt->wdt_device.timeout = ZX2967_WDT_DEFAULT_TIMEOUT;
> + wdt->wdt_device.max_timeout = ZX2967_WDT_MAX_TIMEOUT;
> + wdt->wdt_device.min_timeout = ZX2967_WDT_MIN_TIMEOUT;
> + wdt->wdt_device.parent = &pdev->dev;
> +
> + base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + wdt->reg_base = devm_ioremap_resource(dev, base);
> + if (IS_ERR(wdt->reg_base)) {
> + dev_err(dev, "ioremap failed\n");
> + return PTR_ERR(wdt->reg_base);
> + }
> +
> + zx2967_wdt_reset_sysctrl(dev);
> +
> + wdt->reboot_handler.notifier_call = zx2967_wdt_notify_sys;
> + ret = register_reboot_notifier(&wdt->reboot_handler);
> + wdt->clock = devm_clk_get(dev, "wdtclk");
devm_clk_get(dev, NULL), so that clock-names can be saved from DT.
> + if (IS_ERR(wdt->clock)) {
> + dev_err(dev, "failed to find watchdog clock source\n");
> + return PTR_ERR(wdt->clock);
> + }
> + ret = clk_prepare_enable(wdt->clock);
> + if (ret < 0) {
> + dev_err(dev, "failed to enable clock\n");
> + return ret;
> + }
> +
> + rate = clk_get_rate(wdt->clock);
> + if (rate == 24000000)
> + clk_set_rate(wdt->clock, 32768);
What's the logic behind this? We need to set the frequency to 32768
only when it's 24000000? Any other frequency will just work?
> +
> + rstc = devm_reset_control_get(dev, "wdtrst");
devm_reset_control_get(dev, NULL), so that reset-names can be saved.
> + if (!rstc) {
> + dev_err(dev, "rstc get failed");
Will it still work if "reset" property is missing? If yes, the property
should be documented as optional, not required. If no, we should stop
probing and return error right here.
> + } else {
> + reset_control_assert(rstc);
> + mdelay(10);
> + reset_control_deassert(rstc);
> + }
> +
> + watchdog_set_drvdata(&wdt->wdt_device, wdt);
> +
> + watchdog_init_timeout(&wdt->wdt_device,
> + ZX2967_WDT_DEFAULT_TIMEOUT, dev);
> + watchdog_set_nowayout(&wdt->wdt_device, WATCHDOG_NOWAYOUT);
> +
> + zx2967_wdt_stop(&wdt->wdt_device);
> +
> + err = watchdog_register_device(&wdt->wdt_device);
Why not use 'ret' directly?
Shawn
> + if (unlikely(err)) {
> + ret = err;
> + goto fail_register;
> + }
> +
> + wdt->restart_handler.notifier_call = zx2967_wdt_restart;
> + wdt->restart_handler.priority = 128;
> + ret = register_restart_handler(&wdt->restart_handler);
> + if (ret) {
> + dev_err(dev, "cannot register restart handler, %d\n", ret);
> + goto fail_restart;
> + }
> +
> + dev_info(dev, "watchdog enabled (timeout=%d sec, nowayout=%d)",
> + wdt->wdt_device.timeout, WATCHDOG_NOWAYOUT);
> +
> + return 0;
> +
> +fail_restart:
> + watchdog_unregister_device(&wdt->wdt_device);
> +fail_register:
> + clk_disable_unprepare(wdt->clock);
> + return ret;
> +}
> +
> +static int zx2967_wdt_remove(struct platform_device *pdev)
> +{
> + struct zx2967_wdt *wdt = platform_get_drvdata(pdev);
> +
> + unregister_restart_handler(&wdt->restart_handler);
> + watchdog_unregister_device(&wdt->wdt_device);
> + clk_disable_unprepare(wdt->clock);
> +
> + return 0;
> +}
> +
> +static void zx2967_wdt_shutdown(struct platform_device *pdev)
> +{
> + struct zx2967_wdt *wdt = platform_get_drvdata(pdev);
> +
> + if (!(wdt->flags & ZX2967_WDT_FLAG_REBOOT_MON))
> + zx2967_wdt_stop(&wdt->wdt_device);
> +}
> +
> +static const struct of_device_id zx2967_wdt_match[] = {
> + { .compatible = "zte,zx296718-wdt", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, zx2967_wdt_match);
> +
> +static struct platform_driver zx2967_wdt_driver = {
> + .probe = zx2967_wdt_probe,
> + .remove = zx2967_wdt_remove,
> + .shutdown = zx2967_wdt_shutdown,
> + .driver = {
> + .name = "zx2967-wdt",
> + .of_match_table = of_match_ptr(zx2967_wdt_match),
> + },
> +};
> +module_platform_driver(zx2967_wdt_driver);
> +
> +MODULE_AUTHOR("Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>");
> +MODULE_DESCRIPTION("ZTE zx2967 Watchdog Device Driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] devicetree: add documentation for MAX30102 oximeter
From: Matt Ranostay @ 2017-01-20 5:40 UTC (permalink / raw)
To: jic23-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA, Matt Ranostay,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170120054100.902-1-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
---
.../devicetree/bindings/iio/health/max30102.txt | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/health/max30102.txt
diff --git a/Documentation/devicetree/bindings/iio/health/max30102.txt b/Documentation/devicetree/bindings/iio/health/max30102.txt
new file mode 100644
index 000000000000..c93d1bb25597
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/health/max30102.txt
@@ -0,0 +1,30 @@
+Maxim MAX30102 heart rate and pulse oximeter sensor
+
+* https://datasheets.maximintegrated.com/en/ds/MAX30102.pdf
+
+Required properties:
+ - compatible: must be "maxim,max30102"
+ - reg: the I2C address of the sensor
+ - interrupt-parent: should be the phandle for the interrupt controller
+ - interrupts: the sole interrupt generated by the device
+
+ Refer to interrupt-controller/interrupts.txt for generic
+ interrupt client node bindings.
+
+Optional properties:
+ - maxim,red-led-current-microamp: configuration for RED LED current
+ - maxim,ir-led-current-microamp: configuration for IR LED current
+
+ Note that each step is approximately 200 microamps, ranging from 0 uA to
+ 50800 uA.
+
+Example:
+
+max30100@57 {
+ compatible = "maxim,max30102";
+ reg = <57>;
+ maxim,red-led-current-microamp = <7000>;
+ maxim,ir-led-current-microamp = <7000>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <16 2>;
+};
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] arm64: dts: exynos: Remove address node from usb parent node
From: pankaj.dubey @ 2017-01-20 4:23 UTC (permalink / raw)
To: Javier Martinez Canillas, Chanwoo Choi, devicetree, linux-kernel,
linux-samsung-soc
Cc: robh+dt, krzk, kgene
In-Reply-To: <7280351b-d26a-accb-b442-fc1eb056c8d6@osg.samsung.com>
Hi Javier,
On Wednesday 18 January 2017 09:06 PM, Javier Martinez Canillas wrote:
> Hello,
>
> On 01/18/2017 04:04 AM, Chanwoo Choi wrote:
>> Hi Pankaj,
>>
>> This issue already posted by Javier Martinez Canillas[1].
>> Maybe, he will post v2.
>>
>
> That's correct, I didn't post a v2 since I was waiting for feedback
> from the DT maintainers on patches 1/2 and 2/2 from the same series:
>
> https://www.spinics.net/lists/arm-kernel/msg553286.html
>
> But I'll re-spin just this patch since the changes are independent.
>
I didn't noticed this earlier. In this case my patch [1] can be ignored.
[1]: https://patchwork.kernel.org/patch/9522645/
Thanks,
Pankaj Dubey
> Best regards,
>
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: exynos: Use macros for pinctrl configuration on Exynos7
From: Pankaj Dubey @ 2017-01-20 4:19 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, devicetree
Cc: krzk, kgene, robh+dt, sanath, javier, s.nawrocki, Pankaj Dubey
In-Reply-To: <1484885997-21004-1-git-send-email-pankaj.dubey@samsung.com>
Usage of DTS macros instead of hard-coded numbers makes code easier to
read. One does not have to remember which value means pull-up/down or
specific driver strength.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 4 +-
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 302 ++++++++++++------------
2 files changed, 154 insertions(+), 152 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index c528dd5..25d9b4a 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -328,8 +328,8 @@
&pinctrl_alive {
pmic_irq: pmic-irq {
samsung,pins = "gpa0-2";
- samsung,pin-pud = <3>;
- samsung,pin-drv = <3>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>;
};
};
diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
index 7ebb939..8f58850 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -12,6 +12,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/pinctrl/samsung.h>
+
&pinctrl_alive {
gpa0: gpa0 {
gpio-controller;
@@ -187,163 +189,163 @@
hs_i2c10_bus: hs-i2c10-bus {
samsung,pins = "gpb0-1", "gpb0-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
hs_i2c11_bus: hs-i2c11-bus {
samsung,pins = "gpb0-3", "gpb0-2";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
hs_i2c2_bus: hs-i2c2-bus {
samsung,pins = "gpd0-3", "gpd0-2";
- samsung,pin-function = <3>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
uart0_data: uart0-data {
samsung,pins = "gpd0-0", "gpd0-1";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
uart0_fctl: uart0-fctl {
samsung,pins = "gpd0-2", "gpd0-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
uart2_data: uart2-data {
samsung,pins = "gpd1-4", "gpd1-5";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
hs_i2c3_bus: hs-i2c3-bus {
samsung,pins = "gpd1-3", "gpd1-2";
- samsung,pin-function = <3>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
uart1_data: uart1-data {
samsung,pins = "gpd1-0", "gpd1-1";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
uart1_fctl: uart1-fctl {
samsung,pins = "gpd1-2", "gpd1-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
hs_i2c0_bus: hs-i2c0-bus {
samsung,pins = "gpd2-1", "gpd2-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
hs_i2c1_bus: hs-i2c1-bus {
samsung,pins = "gpd2-3", "gpd2-2";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
hs_i2c9_bus: hs-i2c9-bus {
samsung,pins = "gpd2-7", "gpd2-6";
- samsung,pin-function = <3>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
pwm0_out: pwm0-out {
samsung,pins = "gpd2-4";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
pwm1_out: pwm1-out {
samsung,pins = "gpd2-5";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
pwm2_out: pwm2-out {
samsung,pins = "gpd2-6";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
pwm3_out: pwm3-out {
samsung,pins = "gpd2-7";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
hs_i2c8_bus: hs-i2c8-bus {
samsung,pins = "gpd5-3", "gpd5-2";
- samsung,pin-function = <3>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
uart3_data: uart3-data {
samsung,pins = "gpd5-0", "gpd5-1";
- samsung,pin-function = <3>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
spi2_bus: spi2-bus {
samsung,pins = "gpd5-0", "gpd5-1", "gpd5-2", "gpd5-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
spi1_bus: spi1-bus {
samsung,pins = "gpd6-2", "gpd6-3", "gpd6-4", "gpd6-5";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
spi0_bus: spi0-bus {
samsung,pins = "gpd8-0", "gpd8-1", "gpd6-0", "gpd6-1";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
hs_i2c4_bus: hs-i2c4-bus {
samsung,pins = "gpg3-1", "gpg3-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
hs_i2c5_bus: hs-i2c5-bus {
samsung,pins = "gpg3-3", "gpg3-2";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
};
@@ -358,9 +360,9 @@
hs_i2c6_bus: hs-i2c6-bus {
samsung,pins = "gpj0-1", "gpj0-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
};
@@ -375,9 +377,9 @@
hs_i2c7_bus: hs-i2c7-bus {
samsung,pins = "gpj1-1", "gpj1-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
};
@@ -392,9 +394,9 @@
spi3_bus: spi3-bus {
samsung,pins = "gpg4-0", "gpg4-1", "gpg4-2", "gpg4-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
};
@@ -409,9 +411,9 @@
spi4_bus: spi4-bus {
samsung,pins = "gpv7-0", "gpv7-1", "gpv7-2", "gpv7-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
};
@@ -426,37 +428,37 @@
sd2_clk: sd2-clk {
samsung,pins = "gpr4-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <3>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>;
};
sd2_cmd: sd2-cmd {
samsung,pins = "gpr4-1";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <3>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>;
};
sd2_cd: sd2-cd {
samsung,pins = "gpr4-2";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <3>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>;
};
sd2_bus1: sd2-bus-width1 {
samsung,pins = "gpr4-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <3>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>;
};
sd2_bus4: sd2-bus-width4 {
samsung,pins = "gpr4-4", "gpr4-5", "gpr4-6";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <3>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>;
};
};
@@ -495,107 +497,107 @@
sd0_clk: sd0-clk {
samsung,pins = "gpr0-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <4>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV2>;
};
sd0_cmd: sd0-cmd {
samsung,pins = "gpr0-1";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <4>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV2>;
};
sd0_ds: sd0-ds {
samsung,pins = "gpr0-2";
- samsung,pin-function = <2>;
- samsung,pin-pud = <1>;
- samsung,pin-drv = <4>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV2>;
};
sd0_qrdy: sd0-qrdy {
samsung,pins = "gpr0-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <1>;
- samsung,pin-drv = <4>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV2>;
};
sd0_bus1: sd0-bus-width1 {
samsung,pins = "gpr1-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <4>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV2>;
};
sd0_bus4: sd0-bus-width4 {
samsung,pins = "gpr1-1", "gpr1-2", "gpr1-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <4>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV2>;
};
sd0_bus8: sd0-bus-width8 {
samsung,pins = "gpr1-4", "gpr1-5", "gpr1-6", "gpr1-7";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <4>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV2>;
};
sd1_clk: sd1-clk {
samsung,pins = "gpr2-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <2>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV3>;
};
sd1_cmd: sd1-cmd {
samsung,pins = "gpr2-1";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <2>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV3>;
};
sd1_ds: sd1-ds {
samsung,pins = "gpr2-2";
- samsung,pin-function = <2>;
- samsung,pin-pud = <1>;
- samsung,pin-drv = <6>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV4>;
};
sd1_qrdy: sd1-qrdy {
samsung,pins = "gpr2-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <1>;
- samsung,pin-drv = <6>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV4>;
};
sd1_int: sd1-int {
samsung,pins = "gpr2-4";
- samsung,pin-function = <2>;
- samsung,pin-pud = <1>;
- samsung,pin-drv = <6>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV4>;
};
sd1_bus1: sd1-bus-width1 {
samsung,pins = "gpr3-0";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <2>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV3>;
};
sd1_bus4: sd1-bus-width4 {
samsung,pins = "gpr3-1", "gpr3-2", "gpr3-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <2>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV3>;
};
sd1_bus8: sd1-bus-width8 {
samsung,pins = "gpr3-4", "gpr3-5", "gpr3-6", "gpr3-7";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <2>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS7_FSYS1_PIN_DRV_LV3>;
};
};
@@ -682,22 +684,22 @@
spi5_bus: spi5-bus {
samsung,pins = "gpf2-0", "gpf2-1", "gpf2-2", "gpf2-3";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
ufs_refclk_out: ufs-refclk-out {
samsung,pins = "gpg2-4";
- samsung,pin-function = <2>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <2>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV2>;
};
ufs_rst_n: ufs-rst-n {
samsung,pins = "gph1-5";
- samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] pinctrl: dt-bindings: samsung: Add Exynos7 specific pinctrl macro definitions
From: Pankaj Dubey @ 2017-01-20 4:19 UTC (permalink / raw)
To: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: krzk-DgEjT+Ai2ygdnm+yROfE0A, kgene-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, sanath-Sze3O3UU22JBDgjK7y7TUQ,
javier-JPH+aEBZ4P+UEJcrhfAQsw, s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ,
Pankaj Dubey
In-Reply-To: <1484885997-21004-1-git-send-email-pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Exynos7 SoC pinctrl configurations are similar to existing Exynos4/5 except
for FSYS1 pinctrl drive strengths. So adding Exynos7 specific FSYS1 blocks
pinctrl driver strength related macros which will be used in Exynos7
DTSi files.
Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Alim Akhtar <alim.akhtar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Acked-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
include/dt-bindings/pinctrl/samsung.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/include/dt-bindings/pinctrl/samsung.h b/include/dt-bindings/pinctrl/samsung.h
index 6276eb7..3f1d583 100644
--- a/include/dt-bindings/pinctrl/samsung.h
+++ b/include/dt-bindings/pinctrl/samsung.h
@@ -54,4 +54,12 @@
#define EXYNOS_PIN_FUNC_6 6
#define EXYNOS_PIN_FUNC_F 0xf
+/* Drive strengths for Exynos7 FSYS1 block */
+#define EXYNOS7_FSYS1_PIN_DRV_LV1 0
+#define EXYNOS7_FSYS1_PIN_DRV_LV2 4
+#define EXYNOS7_FSYS1_PIN_DRV_LV3 2
+#define EXYNOS7_FSYS1_PIN_DRV_LV4 6
+#define EXYNOS7_FSYS1_PIN_DRV_LV5 1
+#define EXYNOS7_FSYS1_PIN_DRV_LV6 5
+
#endif /* __DT_BINDINGS_PINCTRL_SAMSUNG_H__ */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/3] arm64: dts: exynos: Fix drive strength of sd0_xxx pin definitions
From: Pankaj Dubey @ 2017-01-20 4:19 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, devicetree
Cc: krzk, kgene, robh+dt, sanath, javier, s.nawrocki, Pankaj Dubey
In-Reply-To: <1484885997-21004-1-git-send-email-pankaj.dubey@samsung.com>
As per Exynos7 datasheet FSYS1 pinctrl block does not support drive
strength value of 0x3. This patch fixes this and update the correct
drive strength for sd0_xxx pin definitions.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
index 8232198..7ebb939 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -497,49 +497,49 @@
samsung,pins = "gpr0-0";
samsung,pin-function = <2>;
samsung,pin-pud = <0>;
- samsung,pin-drv = <3>;
+ samsung,pin-drv = <4>;
};
sd0_cmd: sd0-cmd {
samsung,pins = "gpr0-1";
samsung,pin-function = <2>;
samsung,pin-pud = <3>;
- samsung,pin-drv = <3>;
+ samsung,pin-drv = <4>;
};
sd0_ds: sd0-ds {
samsung,pins = "gpr0-2";
samsung,pin-function = <2>;
samsung,pin-pud = <1>;
- samsung,pin-drv = <3>;
+ samsung,pin-drv = <4>;
};
sd0_qrdy: sd0-qrdy {
samsung,pins = "gpr0-3";
samsung,pin-function = <2>;
samsung,pin-pud = <1>;
- samsung,pin-drv = <3>;
+ samsung,pin-drv = <4>;
};
sd0_bus1: sd0-bus-width1 {
samsung,pins = "gpr1-0";
samsung,pin-function = <2>;
samsung,pin-pud = <3>;
- samsung,pin-drv = <3>;
+ samsung,pin-drv = <4>;
};
sd0_bus4: sd0-bus-width4 {
samsung,pins = "gpr1-1", "gpr1-2", "gpr1-3";
samsung,pin-function = <2>;
samsung,pin-pud = <3>;
- samsung,pin-drv = <3>;
+ samsung,pin-drv = <4>;
};
sd0_bus8: sd0-bus-width8 {
samsung,pins = "gpr1-4", "gpr1-5", "gpr1-6", "gpr1-7";
samsung,pin-function = <2>;
samsung,pin-pud = <3>;
- samsung,pin-drv = <3>;
+ samsung,pin-drv = <4>;
};
sd1_clk: sd1-clk {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/3] Use macros for pinctrl configuration on Exynos7
From: Pankaj Dubey @ 2017-01-20 4:19 UTC (permalink / raw)
To: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: krzk-DgEjT+Ai2ygdnm+yROfE0A, kgene-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, sanath-Sze3O3UU22JBDgjK7y7TUQ,
javier-JPH+aEBZ4P+UEJcrhfAQsw, s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ,
Pankaj Dubey
In-Reply-To: <CGME20170120041717epcas5p152b88433819396e114a42b0f82af3f7a@epcas5p1.samsung.com>
Currently Exynos7 DTSi files are using hard-coded values for pinctrl
configurations such as pin-function, pin-pud and pin-drv. These hard
coded values are difficult to understand without datasheet, lets use
macros for such configurations.
While doing this observed that Exynos7 has different drive strengths
values *ONLY* for FSYS1 blocks pins, so adding new macro definition
for the same in patch[2/3]
Also some of sd0_xxxx pin definition is using drive strength as 0x3 but
as per datasheet of Exynos7, FSYS1 block's pin does not support 0x3 value
for drive strenth so fixing the same in patch[1/3].
I have verified these patches for boot on Exynos7 based espresso board.
Changes since v1:
- Fixed drive strength of pmic_irq pins as pointed by Krzysztof
- Included Alim's R-o-B tag
Pankaj Dubey (3):
arm64: dts: exynos: Fix drive strength of sd0_xxx pin definitions
pinctrl: dt-bindings: samsung: Add Exynos7 specific pinctrl macro
definitions
arm64: dts: exynos: Use macros for pinctrl configuration on Exynos7
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 4 +-
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 302 ++++++++++++------------
include/dt-bindings/pinctrl/samsung.h | 8 +
3 files changed, 162 insertions(+), 152 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: exynos: Use macros for pinctrl configuration on Exynos7
From: pankaj.dubey @ 2017-01-20 3:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc, alim.akhtar, javier, robh+dt,
kgene, s.nawrocki, sanath, linux-arm-kernel
In-Reply-To: <20170118150131.ttalzfxxtpbrw5gb@kozik-lap>
Hi Krzysztof,
On Wednesday 18 January 2017 08:31 PM, Krzysztof Kozlowski wrote:
> On Wed, Jan 18, 2017 at 11:12:21AM +0530, Pankaj Dubey wrote:
>> Usage of DTS macros instead of hard-coded numbers makes code easier to
>> read. One does not have to remember which value means pull-up/down or
>> specific driver strength.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 4 +-
>> arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 302 ++++++++++++------------
>> 2 files changed, 154 insertions(+), 152 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>> index c528dd5..1b2db9f0 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>> @@ -328,8 +328,8 @@
>> &pinctrl_alive {
>> pmic_irq: pmic-irq {
>> samsung,pins = "gpa0-2";
>> - samsung,pin-pud = <3>;
>> - samsung,pin-drv = <3>;
>> + samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
>> + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV3>;
>> };
>> };
>
> This is not equal (value 3 => 1). If the change was intended, please do
> in separate patch.
>
This was not an intended change. It should be EXYNOS4_PIN_DRV_LV4, I
will submit another set after fixing this.
Thanks,
Pankaj Dubey
> Rest looks fine.
>
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* Re: [PATCH v20 0/4] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2017-01-20 3:11 UTC (permalink / raw)
To: Rob Herring, Matthias Brugger, Jassi Brar
Cc: Daniel Kurtz, Sascha Hauer, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, CK HU, cawa cheng, Bibby Hsieh,
YT Shen, Daoyuan Huang, Damon Chu, Josh-YC Liu, Glory Hung,
Jiaguang Zhang, Dennis-YC Hsieh
In-Reply-To: <1484270826.14822.1.camel@mtksdaap41>
On Fri, 2017-01-13 at 09:27 +0800, Horng-Shyang Liao wrote:
> On Wed, 2017-01-04 at 11:06 +0800, HS Liao wrote:
> > Hi,
> >
> > This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> > to help write registers with critical time limitation, such as
> > updating display configuration during the vblank. It controls Global
> > Command Engine (GCE) hardware to achieve this requirement.
> >
> > These patches have a build dependency on top of v4.10-rc2.
> >
> > Changes since v19:
> > - rebase to v4.10-rc2
> >
> > Best regards,
> > HS Liao
> >
> > HS Liao (4):
> > dt-bindings: soc: Add documentation for the MediaTek GCE unit
> > mailbox: mediatek: Add Mediatek CMDQ driver
> > arm64: dts: mt8173: Add GCE node
> > soc: mediatek: Add Mediatek CMDQ helper
> >
> > .../devicetree/bindings/mailbox/mtk-gce.txt | 43 ++
> > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> > drivers/mailbox/Kconfig | 10 +
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/mtk-cmdq-mailbox.c | 596 +++++++++++++++++++++
> > drivers/soc/mediatek/Kconfig | 12 +
> > drivers/soc/mediatek/Makefile | 1 +
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 310 +++++++++++
> > include/linux/mailbox/mtk-cmdq-mailbox.h | 75 +++
> > include/linux/soc/mediatek/mtk-cmdq.h | 174 ++++++
> > 10 files changed, 1233 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> > create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> > create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
> > create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> > create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
> >
>
> Hi Jassi, Matthias,
>
> Sorry to disturb you.
> Do you have any further comments on CMDQ v20?
>
> Thanks.
> HS
Hi Jassi, Matthias,
Sorry to disturb you again.
Do you have any further comments on CMDQ v20?
Thanks.
HS
--
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] ahci: qoriq: added ls2088a platforms support
From: Y.T. Tang @ 2017-01-20 3:05 UTC (permalink / raw)
To: Tejun Heo
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20170118195351.GD9171-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
> -----Original Message-----
> From: Tejun Heo [mailto:htejun-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] On Behalf Of Tejun Heo
> Sent: Thursday, January 19, 2017 3:54 AM
> To: Y.T. Tang <yuantian.tang-3arQi8VN3Tc@public.gmane.org>
> Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org; linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH] ahci: qoriq: added ls2088a platforms support
>
> On Tue, Jan 17, 2017 at 02:12:01PM +0800, yuantian.tang-3arQi8VN3Tc@public.gmane.org wrote:
> > From: Tang Yuantian <Yuantian.Tang-3arQi8VN3Tc@public.gmane.org>
> >
> > Ls2088a is new introduced arm-based soc with sata support with
> > following features:
> > 1. Complies with the serial ATA 3.0 specification and the AHCI 1.3.1
> > specification
> > 2. Contains a high-speed descriptor-based DMA controller 3. Supports
> > the following:
> > a. Speeds of 1.5 Gb/s (first-generation SATA), 3 Gb/s
> > (second-generation SATA), and 6 Gb/s (third-generation SATA)
> > b. FIS-based switching
> > c. Native command queuing (NCQ) commands
> > d. Port multiplier operation
> > e. Asynchronous notification
> > f. SATA BIST mode
> >
> > Signed-off-by: Tang Yuantian <yuantian.tang-3arQi8VN3Tc@public.gmane.org>
>
> Reverted due to build failure. Did you even try to compile it before
> submission? We all make mistakes and that's fine but this one seems a bit
> too careless. Please don't do this.
>
Sorry for the trouble.
I never send a patch without testing. This patch depends on other two patches which I sent a long time ago which I thought they were merged.
Anyway, my mistake.
I will resend all the patches with correct order.
Regards,
Yuantian
> Thanks.
>
> --
> tejun
--
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 v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Shawn Lin @ 2017-01-20 2:42 UTC (permalink / raw)
To: Ulf Hansson, Matt Ranostay
Cc: shawn.lin, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, Tony Lindgren
In-Reply-To: <CAPDyKFpcKuybQmhqCkaAkOM5d+ubU8O8=adLm+PXwc=+N87vng@mail.gmail.com>
On 2017/1/19 22:13, Ulf Hansson wrote:
> +Shawn
>
> On 13 January 2017 at 06:29, Matt Ranostay <matt@ranostay.consulting> wrote:
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>> ---
>> drivers/mmc/core/Kconfig | 10 ++++
>> drivers/mmc/core/Makefile | 1 +
>> drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 128 insertions(+)
>> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>> --- a/drivers/mmc/core/Kconfig
>> +++ b/drivers/mmc/core/Kconfig
>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>> This driver can also be built as a module. If so, the module
>> will be called pwrseq_emmc.
>>
>> +config PWRSEQ_SD8787
>> + tristate "HW reset support for SD8787 BT + Wifi module"
>> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>> + help
>> + This selects hardware reset support for the SD8787 BT + Wifi
>> + module. By default this option is set to n.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called pwrseq_sd8787.
>> +
>> config PWRSEQ_SIMPLE
>> tristate "Simple HW reset support for MMC"
>> default y
>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>> index b2a257dc644f..0f81464fa824 100644
>> --- a/drivers/mmc/core/Makefile
>> +++ b/drivers/mmc/core/Makefile
>> @@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
>> quirks.o slot-gpio.o
>> mmc_core-$(CONFIG_OF) += pwrseq.o
>> obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
>> +obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
>> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
>> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
>> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
>> new file mode 100644
>> index 000000000000..f4080fe6439e
>> --- /dev/null
>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>> @@ -0,0 +1,117 @@
>> +/*
>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
>> + *
>> + * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
>> + *
>> + * Based on the original work pwrseq_simple.c
>> + * Copyright (C) 2014 Linaro Ltd
>> + * Author: Ulf Hansson <ulf.hansson@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/init.h>
>> +#include <linux/kernel.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/gpio/consumer.h>
>> +
>> +#include <linux/mmc/host.h>
>> +
>> +#include "pwrseq.h"
>> +
>> +struct mmc_pwrseq_sd8787 {
>> + struct mmc_pwrseq pwrseq;
>> + struct gpio_desc *reset_gpio;
>> + struct gpio_desc *pwrdn_gpio;
>> +};
>> +
>> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
>> +
>> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
>> +{
>> + struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
>> +
>> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
>> +
>> + msleep(300);
>> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
>> +}
>> +
>> +static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
>> +{
>> + struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
>> +
>> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
>> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
>> +}
>> +
>> +static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
>> + .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
>> + .power_off = mmc_pwrseq_sd8787_power_off,
>> +};
>> +
>> +static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
>> + { .compatible = "mmc-pwrseq-sd8787",},
>> + {/* sentinel */},
>> +};
>> +MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
>> +
>> +static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
>> +{
>> + struct mmc_pwrseq_sd8787 *pwrseq;
>> + struct device *dev = &pdev->dev;
>> +
>> + pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
>> + if (!pwrseq)
>> + return -ENOMEM;
>> +
>> + pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
>> + if (IS_ERR(pwrseq->pwrdn_gpio))
>> + return PTR_ERR(pwrseq->pwrdn_gpio);
>> +
>> + pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
>> + if (IS_ERR(pwrseq->reset_gpio))
>> + return PTR_ERR(pwrseq->reset_gpio);
>> +
>> + pwrseq->pwrseq.dev = dev;
>> + pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
>> + pwrseq->pwrseq.owner = THIS_MODULE;
>> + platform_set_drvdata(pdev, pwrseq);
>> +
>> + return mmc_pwrseq_register(&pwrseq->pwrseq);
>> +}
>> +
>> +static int mmc_pwrseq_sd8787_remove(struct platform_device *pdev)
>> +{
>> + struct mmc_pwrseq_sd8787 *pwrseq = platform_get_drvdata(pdev);
>> +
>> + mmc_pwrseq_unregister(&pwrseq->pwrseq);
>> +
>> + return 0;
>> +}
>> +
>> +static struct platform_driver mmc_pwrseq_sd8787_driver = {
>> + .probe = mmc_pwrseq_sd8787_probe,
>> + .remove = mmc_pwrseq_sd8787_remove,
>> + .driver = {
>> + .name = "pwrseq_sd8787",
>> + .of_match_table = mmc_pwrseq_sd8787_of_match,
>> + },
>> +};
>> +
>> +module_platform_driver(mmc_pwrseq_sd8787_driver);
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.10.2
>>
>
> Twisting my head around how this could be integrated smoothly into
> pwrseq simple. No, I just can find a good way forward without messing
> up pwrseq simple itself.
>
> So, for now I decided (once more :-), that let's keep this as separate driver!
I still worry about if there will be more and more seperate drivers. :)
IIRC Peter Chen was trying to move pwrseq out of mmc and use it
for USB stuff. It seems there is no follow-up plan there but should
we invent a new directory to fold in all the pweseq stuff there,
for instance, drivers/mmc/pweseqs/.
>
> Perhaps, following device specific mmc pwrseq drivers will needs
> something similar, but in such case we can look into that then.
> Thinking about cw1200 for example.
>
> Let's get Rob's ack for the DT bindings, seems almost there, then I
> will queue this.
>
> Kind regards
> Uffe
>
>
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board
From: Shawn Lin @ 2017-01-20 2:29 UTC (permalink / raw)
To: Eddie Cai, robh+dt, mark.rutland, heiko, linux
Cc: shawn.lin, devicetree, Eddie Cai, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <1484791919-4665-3-git-send-email-eddie.cai@rock-chips.com>
On 2017/1/19 10:11, Eddie Cai wrote:
> This patch add basic support for RK3288-Tinker board. We can boot in to rootfs
> with this patch.
>
> Signed-off-by: Eddie Cai <eddie.cai@rock-chips.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/rk3288-tinker.dts | 556 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 557 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7327250..4fc05b7 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -679,6 +679,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> rk3288-popmetal.dtb \
> rk3288-r89.dtb \
> rk3288-rock2-square.dtb \
> + rk3288-tinker.dtb \
> rk3288-veyron-brain.dtb \
> rk3288-veyron-jaq.dtb \
> rk3288-veyron-jerry.dtb \
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dts b/arch/arm/boot/dts/rk3288-tinker.dts
> new file mode 100644
> index 0000000..37cb431
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3288-tinker.dts
> @@ -0,0 +1,556 @@
> +/*
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "rk3288.dtsi"
> +
> +/ {
> + model = "Rockchip RK3288 Tinker Board";
> + compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
> +
> + memory {
> + reg = <0x0 0x80000000>;
> + device_type = "memory";
> + };
> +
> + ext_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <125000000>;
> + clock-output-names = "ext_gmac";
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + autorepeat;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwrbtn>;
> +
> + button@0 {
> + gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
> + linux,code = <116>;
> + label = "GPIO Key Power";
> + linux,input-type = <1>;
> + gpio-key,wakeup = <1>;
> + debounce-interval = <100>;
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + pwr-led {
> + gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "default-on";
> + };
> +
> + act-led {
> + gpios=<&gpio2 3 GPIO_ACTIVE_LOW>;
> + linux,default-trigger="mmc0";
> + };
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,name = "rockchip,tinker-codec";
> + simple-audio-card,mclk-fs = <512>;
> + simple-audio-card,cpu {
> + sound-dai = <&i2s>;
> + };
> + simple-audio-card,codec {
> + sound-dai = <&hdmi>;
> + };
> + };
> +
> + vcc_sys: vsys-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_sys";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + /*
> + * NOTE: vcc_sd isn't hooked up on v1.0 boards where power comes from
> + * vcc_io directly. Those boards won't be able to power cycle SD cards
> + * but it shouldn't hurt to toggle this pin there anyway.
> + */
> + vcc_sd: sdmmc-regulator {
> + compatible = "regulator-fixed";
> + gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc_pwr>;
> + regulator-name = "vcc_sd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + startup-delay-us = <100000>;
> + vin-supply = <&vcc_io>;
> + };
> +};
> +
> +&cpu0 {
> + cpu0-supply = <&vdd_cpu>;
> +};
> +
> +&gmac {
> + phy-supply = <&vcc33_lan>;
> + phy-mode = "rgmii";
> + clock_in_out = "input";
> + snps,reset-gpio = <&gpio4 7 0>;
> + snps,reset-active-low;
> + snps,reset-delays-us = <0 10000 1000000>;
> + assigned-clocks = <&cru SCLK_MAC>;
> + assigned-clock-parents = <&ext_gmac>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_pins>;
> + tx_delay = <0x30>;
> + rx_delay = <0x10>;
> + status = "ok";
> +};
> +
> +&hdmi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #sound-dai-cells = <0>;
> + ddc-i2c-bus = <&i2c5>;
> + status = "okay";
> + /* Don't use vopl for HDMI */
> + ports {
> + hdmi_in: port {
> + /delete-node/ endpoint@1;
> + };
> + };
> +};
> +
> +&i2c0 {
> + status = "okay";
> + clock-frequency = <400000>;
> +
> + rk808: pmic@1b {
> + compatible = "rockchip,rk808";
> + reg = <0x1b>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int &global_pwroff &dvs_1 &dvs_2>;
> + dvs-gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>,
> + <&gpio0 12 GPIO_ACTIVE_HIGH>;
> +
> + rockchip,system-power-controller;
> + wakeup-source;
> + #clock-cells = <1>;
> + clock-output-names = "xin32k", "rk808-clkout2";
> +
> + vcc1-supply = <&vcc_sys>;
> + vcc2-supply = <&vcc_sys>;
> + vcc3-supply = <&vcc_sys>;
> + vcc4-supply = <&vcc_sys>;
> + vcc6-supply = <&vcc_sys>;
> + vcc7-supply = <&vcc_sys>;
> + vcc8-supply = <&vcc_18>;
> + vcc9-supply = <&vcc_io>;
> + vcc10-supply = <&vcc_io>;
> + vcc11-supply = <&vcc_sys>;
> + vcc12-supply = <&vcc_io>;
> + vddio-supply = <&vcc18_ldo1>;
> +
> + regulators {
> + vdd_cpu: DCDC_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-name = "vdd_arm";
> + regulator-ramp-delay = <6000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_gpu: DCDC_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <1250000>;
> + regulator-name = "vdd_gpu";
> + regulator-ramp-delay = <6000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc_ddr";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_io: DCDC_REG4 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc_io";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc18_ldo1: LDO_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc18_ldo1";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc33_mipi: LDO_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc33_mipi";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_10: LDO_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-name = "vdd_10";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> +
> + vcc18_codec: LDO_REG4 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc18_codec";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vccio_sd: LDO_REG5 {
> + regulator-always-on;
> + regulator-boot-on;
are some other io banks or devices powered by
vccio_sd, so that you mark it as boot-on and always-on?
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vccio_sd";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vdd10_lcd: LDO_REG6 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-name = "vdd10_lcd";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> +
> + vcc_18: LDO_REG7 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc_18";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc18_lcd: LDO_REG8 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc18_lcd";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc33_sd: SWITCH_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc33_sd";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc33_lan: SWITCH_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc33_lan";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> + };
> + };
> +};
> +
> +&i2c2 {
> + status = "okay";
> +};
> +
> +&i2c5 {
> + status = "okay";
> +};
> +
> +&i2s {
> + #sound-dai-cells = <0>;
> + status = "okay";
> +};
> +
> +&io_domains {
> + status = "okay";
> +
> + sdcard-supply = <&vccio_sd>;
> +};
> +
> +&pinctrl {
> + pcfg_pull_none_drv_8ma: pcfg-pull-none-drv-8ma {
> + drive-strength = <8>;
> + };
> +
> + pcfg_pull_up_drv_8ma: pcfg-pull-up-drv-8ma {
> + bias-pull-up;
> + drive-strength = <8>;
> + };
> +
> + backlight {
> + bl_en: bl-en {
> + rockchip,pins = <7 2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + buttons {
> + pwrbtn: pwrbtn {
> + rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + eth_phy {
> + eth_phy_pwr: eth-phy-pwr {
> + rockchip,pins = <0 6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int: pmic-int {
> + rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO \
> + &pcfg_pull_up>;
> + };
> +
> + dvs_1: dvs-1 {
> + rockchip,pins = <RK_GPIO0 11 RK_FUNC_GPIO \
> + &pcfg_pull_down>;
> + };
> +
> + dvs_2: dvs-2 {
> + rockchip,pins = <RK_GPIO0 12 RK_FUNC_GPIO \
> + &pcfg_pull_down>;
> + };
> + };
> +
> + sdmmc {
> + /*
> + * Default drive strength isn't enough to achieve even
> + * high-speed mode on EVB board so bump up to 8ma.
> + */
> + sdmmc_bus4: sdmmc-bus4 {
> + rockchip,pins = <6 16 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
> + <6 17 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
> + <6 18 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
> + <6 19 RK_FUNC_1 &pcfg_pull_up_drv_8ma>;
> + };
> +
> + sdmmc_clk: sdmmc-clk {
> + rockchip,pins = <6 20 RK_FUNC_1 \
> + &pcfg_pull_none_drv_8ma>;
> + };
> +
> + sdmmc_cmd: sdmmc-cmd {
> + rockchip,pins = <6 21 RK_FUNC_1 &pcfg_pull_up_drv_8ma>;
> + };
> +
> + sdmmc_pwr: sdmmc-pwr {
> + rockchip,pins = <7 11 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + usb {
> + host_vbus_drv: host-vbus-drv {
> + rockchip,pins = <0 14 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + pwr_3g: pwr-3g {
> + rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +};
> +
> +&pwm0 {
> + status = "okay";
> +};
> +
> +&saradc {
> + vref-supply = <&vcc18_ldo1>;
> + status ="okay";
> +};
> +
> +&sdmmc {
> + bus-width = <4>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + card-detect-delay = <200>;
> + disable-wp; /* wp not hooked up */
> + num-slots = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
> + status = "okay";
> + supports-sd;
This is not upstreamed property. We have no-sdio/no-emmc there to
skip the init sequence.
> + vmmc-supply = <&vcc_sd>;
> + vqmmc-supply = <&vccio_sd>;
> +};
> +
> +&tsadc {
> + rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
> + rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> + status = "okay";
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart3 {
> + status = "okay";
> +};
> +
> +&uart4 {
> + status = "okay";
> +};
> +
> +&usbphy {
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + no-relinquish-port;
> + status = "okay";
> +};
> +
> +&usb_host1 {
> + status = "okay";
> +};
> +
> +&usb_otg {
> + status= "okay";
> +};
> +
> +&vopb {
> + status = "okay";
> +};
> +
> +&vopb_mmu {
> + status = "okay";
> +};
> +
> +&vopl {
> + status = "okay";
> + /* Don't use vopl for HDMI */
> + vopl_out: port {
> + /delete-node/ endpoint@0;
> + };
> +};
> +
> +&vopl_mmu {
> + status = "okay";
> +};
> +
> +&wdt {
> + status = "okay";
> +};
> +
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* Re: [PATCH 2/6] usb: mtu3: add reference clock
From: Chunfeng Yun @ 2017-01-20 2:20 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mathias Nyman, Felipe Balbi, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Ian Campbell, linux-kernel, linux-arm-kernel,
linux-usb, linux-mediatek, devicetree
In-Reply-To: <7fc9de99-4bef-ddf2-c5fe-985f8d2348d2@gmail.com>
On Thu, 2017-01-19 at 13:22 +0100, Matthias Brugger wrote:
>
> On 18/01/17 07:08, Chunfeng Yun wrote:
> > usually, the reference clock comes from 26M oscillator directly,
> > but some SoCs are not, add it for compatibility.
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > drivers/usb/mtu3/mtu3.h | 1 +
> > drivers/usb/mtu3/mtu3_plat.c | 21 +++++++++++++++++++--
> > 2 files changed, 20 insertions(+), 2 deletions(-)
[...]
> > @@ -154,6 +162,7 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> > static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
> > {
> > clk_disable_unprepare(ssusb->sys_clk);
> > + clk_disable_unprepare(ssusb->ref_clk);
> > regulator_disable(ssusb->vusb33);
> > ssusb_phy_power_off(ssusb);
> > ssusb_phy_exit(ssusb);
> > @@ -216,6 +225,12 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
> > return PTR_ERR(ssusb->sys_clk);
> > }
> >
> > + ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
> > + if (IS_ERR(ssusb->ref_clk)) {
> > + dev_err(dev, "failed to get ref clock\n");
> > + return PTR_ERR(ssusb->ref_clk);
> > + }
> > +
>
> That would break older dts bindings, right?
Yes, So I send a new patch for the related dts. Maybe it's not a
problem, only one dts file need be updated currently.
> ref_ck must be optional for the code.
I tend to make it be optional for the dts, but not for the code.
There are some "fixed-clock" which can be treated as dummy ones, and if
a clock is really optional, we can use one fixed-clock in dts, and keep
the code simple.
In fact, the reference clock is essential for usb controller.
>
> Regards,
> Matthias
^ permalink raw reply
* Re: [PATCH 0/6] of_graph_get_remote_endpoint()
From: Kuninori Morimoto @ 2017-01-20 2:04 UTC (permalink / raw)
To: Rob Herring
Cc: Frank Rowand, Linux-Kernel, Linux-DT, Laurent, Tomi Valkeinen,
David Airlie, Sean Paul, Peter Chen, Peter Ujfalusi,
Benoit Parrot, Mauro Carvalho Chehab, Javier Martinez Canillas,
Sakari Ailus, Bartlomiej Zolnierkiewicz
In-Reply-To: <CAL_JsqJEL4jd2gnoC+mygJzuEgPO8H4PQhN5dvmq_rN1mBfVEw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob
> This looks okay, but I think we need to be improving the graph api at
> a higher level. Each user seems to be doing too much open coding of
> walking of the graph. The user typically just wants the remote node
> parent of a given port and endpoint number. Why does the user walk the
> graph to find the endpoint node, then parse remote-endpoint, then walk
> up parents. We have lots of other graph users and you didn't need to
> update them which means they are already using helpers. Maybe the
> drivers here need to be fixed. omapfb in particular looks like it
> duplicates a bunch of helpers we already have, but maybe we're close
> to removing that driver.
Does your "we need to be improving the graph api at a higher level"
mean I need to re-work this patch ?
Or someone (?) will improve OF-graph, and I need to wait it ?
More direct words, will this patch be accepted ??
You know I'm working for OF-graph base HDMI sound now, and actually,
I have some OF-graph new API which is useful for OF-graph HDMI sound support.
(I don't like open coding, I want to have useful/understandable common api)
This get_remote_endpoint is one of them, and was ready for posting.
So, I will post other OF-graph base patches if OF-graph HDMI sound was ready.
--
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] dt: bindings: add documentation for zx2967 family watchdog controller
From: Shawn Guo @ 2017-01-20 1:53 UTC (permalink / raw)
To: Baoyou Xie
Cc: jun.nie-QSEj5FYQhm4dnm+yROfE0A, wim-IQzOog9fTRqzQB+pC5nmwQ,
linux-0h96xk9xTtrk1uMJSBkQmQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1484791192-31674-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Jan 19, 2017 at 09:59:50AM +0800, Baoyou Xie wrote:
> This patch adds dt-binding documentation for zx2967 family
> watchdog controller.
>
> Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
It seems that the comments I put on v1 remains unresolved.
> ---
> .../bindings/watchdog/zte,zx2967-wdt.txt | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
> new file mode 100644
> index 0000000..6e35ce7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
> @@ -0,0 +1,32 @@
> +ZTE zx2967 Watchdog timer
> +
> +Required properties:
> +
> +- compatible : should be one of the following.
> + * zte,zx296718-wdt
> +- reg : Specifies base physical address and size of the registers.
> +- clocks : Pairs of phandle and specifier referencing the controller's clocks.
> +- clock-names: "wdtclk" for the watchdog clock.
> +- resets : Reference to the reset controller controlling the watchdog
> + controller.
> +- reset-names : Must include the following entries:
> + * wdtrst
I do not think clock-names and reset-names are really necessary, since
there is only one clock and reset signal.
> +
> +Optional properties:
> +
> +- wdt-reset-sysctrl : should include following fields.
We need a vendor prefix for vendor specific property.
> + * phandle of aon-sysctrl.
> + * configuare value that be wrote to aon-sysctrl.
s/configuare/configure, s/wrote/written
> + * bit mask, corresponding bits will be affected.
I think we need some comments for bindings users to understand the
different role between "resets" and "wdt-reset-sysctrl". Also, why is
wdt-reset-sysctrl is optional? Does it still work well without this
property.
FYI. I have a similar bindings for TVENC below, which you may find
useful.
http://www.spinics.net/lists/devicetree/msg159668.html
> +
> +Example:
> +
> +wdt_ares: watchdog@1465000 {
What does the suffix "ares" mean? I guess "wdt" is good enough as the
label name.
Shawn
> + compatible = "zte,zx296718-wdt";
> + reg = <0x1465000 0x1000>;
> + clocks = <&topcrm WDT_WCLK>;
> + clock-names = "wdtclk";
> + resets = <&toprst 35>;
> + reset-names = "wdtrst";
> + wdt-reset-sysctrl = <&aon_sysctrl 1 0x115>;
> +};
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Question about OF-graph ports
From: Kuninori Morimoto @ 2017-01-20 1:46 UTC (permalink / raw)
To: Rob Herring; +Cc: Mark Brown, Linux-DT, Linux-ALSA
In-Reply-To: <CAL_Jsq+pDkfijyKV0ALzZUrH-NVzmLaNj6ivAEFO98NUOXGojw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob
Thank you for your feedback
> > SoC.0 Codec0
> > SoC.1 <-> Card <-> Codec1
> > SoC.2 Codec2
(snip)
> The card should only have the entry (or exit) points of the graph.
> That may not even need to be graph nodes. It could just be a list of
> CPU DAI phandles (which then have graph nodes).
>
> Look at the display side use of OF graph. We have display subsystem
> nodes (like a card) with a poorly named ports property (nothing to do
> with OF graph) listing display channels. Each phandle there is the
> entry point to the graph and is typically the front end display
> controller (perhaps a CSC and scaling unit). The graph then goes to a
> backend controller (for display timing), then to interface PHY
> (DSI/HDMI), then possibly and external bridge chip, then to a
> connector or panel node. That's a complex example. In simple cases, we
> just have a display controller connected to a panel.
If my understanding here was correct, do you mean like this ?
sound_dai0 {
ports {
port { /* Card.0 */ }
port { /* SoC.0 */ }
port { /* Codec0 */ }
};
};
sound_dai1 {
ports {
port { /* Card.1 */ }
port { /* SoC.1 */ }
port { /* Codec1 */ }
};
};
sound_dai2 {
ports {
port { /* Card.2 */ }
port { /* SoC.2 */ }
port { /* Codec2 */ }
};
};
card {
ports {
port { /* sound_dai0 */ }
port { /* sound_dai1 */ }
port { /* sound_dai2 */ }
};
};
Or this ?
sound_dai0 {
ports {
port { /* SoC.0 */ }
port { /* Codec0 */ }
};
};
sound_dai1 {
ports {
port { /* SoC.1 */ }
port { /* Codec1 */ }
};
};
sound_dai2 {
ports {
port { /* SoC.2 */ }
port { /* Codec2 */ }
};
};
card {
dais = <&sound_dai0
&sound_dai1
&sound_dai2>;
};
Best regards
---
Kuninori Morimoto
--
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 v9 0/4] arm64: arch_timer: Add workaround for hisilicon-161010101 erratum
From: Ding Tianhong @ 2017-01-20 1:22 UTC (permalink / raw)
To: Marc Zyngier, catalin.marinas, will.deacon, mark.rutland, oss,
devicetree, shawnguo, stuart.yoder, linux-arm-kernel, linuxarm
In-Reply-To: <23512329-e8d9-4b4f-c460-4d769ef7102e@arm.com>
On 2017/1/19 21:49, Marc Zyngier wrote:
> On 19/01/17 13:35, Ding Tianhong wrote:
>> Erratum Hisilicon-161010101 says that the ARM generic timer counter "has the
>> potential to contain an erroneous value when the timer value changes".
>> Accesses to TVAL (both read and write) are also affected due to the implicit counter
>> read. Accesses to CVAL are not affected.
>
> Please. 3 series in 2 hours is not fun, and is not helping your case
> either. Give us the time to properly review your patches, and wait until
> we ask you to respin if we think that this is required.
>
> Thanks,
>
OKo<\fThank you for your correction.
Thanks
Ding
> M.
>
^ permalink raw reply
* Re: [PATCH V2 3/4] arm64: dts: Enable SDHCI for Nexus 5X (msm8992)
From: Jeremy McNicoll @ 2017-01-20 0:20 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jeremy McNicoll, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh-DgEjT+Ai2ygdnm+yROfE0A, arnd-r2nGTMty4D4,
riteshh-sgV2jX0FEOL9JmXXK+q4OQ, git-LJ92rlH3Dns,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20170118190257.GQ10531@minitux>
On Wed, Jan 18, 2017 at 11:02:57AM -0800, Bjorn Andersson wrote:
> On Mon 16 Jan 16:58 PST 2017, Jeremy McNicoll wrote:
>
> > Add Nexus 5X (msm8992) SDHCI support, including initial regulator
> > entries to support enabling the main SDHCI/MMC.
> >
> > The RPM is common between 8992 & 8994 simply reflect reality with
> > a shared DT entry.
> >
> > The msm8994 RPM regulator talks over SMD to the APPS processor.
> >
> > Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> >
> > Dropped RobH's ACK explicitly after addressing all feedback.
> > The reason is that msm8994-smd-rpm.dtsi was created to allow
> > for sharing between 8992 & 8994 as the RPM is common between
> > the two.
> >
> > .../bindings/regulator/qcom,smd-rpm-regulator.txt | 40 +++
> > .../boot/dts/qcom/msm8992-bullhead-rev-101.dts | 2 +
> > arch/arm64/boot/dts/qcom/msm8992-pins.dtsi | 82 ++++++
> > arch/arm64/boot/dts/qcom/msm8992.dtsi | 153 ++++++++++++
> > arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi | 276 +++++++++++++++++++++
> > drivers/regulator/qcom_smd-regulator.c | 49 ++++
> > 6 files changed, 602 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
> > index 1f8d6f8..126989b 100644
> > --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
> > +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
> > @@ -23,6 +23,7 @@ Regulator nodes are identified by their compatible:
> > "qcom,rpm-pm8916-regulators"
> > "qcom,rpm-pm8941-regulators"
> > "qcom,rpm-pma8084-regulators"
> > + "qcom,rpm-pm8994-regulators"
> >
> > - vdd_s1-supply:
> > - vdd_s2-supply:
> > @@ -97,6 +98,40 @@ Regulator nodes are identified by their compatible:
> > Definition: reference to regulator supplying the input pin, as
> > described in the data sheet
> >
> > +- vdd_s1-supply:
> > +- vdd_s2-supply:
> > +- vdd_s3-supply:
> > +- vdd_s4-supply:
> > +- vdd_s5-supply:
> > +- vdd_s6-supply:
> > +- vdd_s7-supply:
> > +- vdd_l1_l11-supply:
> > +- vdd_l2_l3_l4_l27-supply:
> > +- vdd_l5_l7-supply:
> > +- vdd_l6_l12_l14_l15_l26-supply:
> > +- vdd_l8-supply:
> > +- vdd_l9_l10_l13_l20_l23_l24-supply:
> > +- vdd_l1_l11-supply:
> > +- vdd_l6_l12_l14_l15_l26-supply:
> > +- vdd_l16_l25-supply:
> > +- vdd_l17-supply:
> > +- vdd_l18-supply:
> > +- vdd_l19-supply:
> > +- vdd_l21-supply:
> > +- vdd_l22-supply:
> > +- vdd_l16_l25-supply:
> > +- vdd_l27-supply:
> > +- vdd_l28-supply:
> > +- vdd_l29-supply:
> > +- vdd_l30-supply:
> > +- vdd_l31-supply:
> > +- vdd_l32-supply:
> > + Usage: optional (pm8994 only)
> > + Value type: <phandle>
> > + Definition: reference to regulator supplying the input pin, as
> > + described in the data sheet.
>
> This is not entirely correct and should be part of a "arm64: dts" patch.
>
.... but the title of this patch is "[PATCH V2 3/4] arm64: dts: Enable
SDHCI for Nexus 5X (msm8992)" which has the 'arm64: dts:' you are
referring to.
A new patch?
> It seems to be compatible with the pm8994 patch we've had sitting in the
> Linaro tree for msm8996 for some time, so I did send this out; with you
> Cc. Please give it a spin.
>
Seems to work just fine. I'll drop my changes which are covered in the
afore mentioned patch. There seems to be a delta between what I have
and what you sent, nothing major and the few peripherals supported thus
far still seem to be working.
> > +
> > +
> > The regulator node houses sub-nodes for each regulator within the device. Each
> > sub-node is identified using the node's name, with valid values listed for each
> > of the pmics below.
> > @@ -118,6 +153,11 @@ pma8084:
> > l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
> > l21, l22, l23, l24, l25, l26, l27, lvs1, lvs2, lvs3, lvs4, 5vs1
> >
> > +pm8994:
> > + s1, s2, s3, s4, s5, s6, s7, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
> > + l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26,
> > + l27, l28, l29, l30, l31, l32, lvs1, lvs2
> > +
> > The content of each sub-node is defined by the standard binding for regulators -
> > see regulator.txt.
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> > index 4542133..3fc9a33 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> > +++ b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> > @@ -39,3 +39,5 @@
> > };
> > };
> > };
> > +
> > +#include "msm8994-smd-rpm.dtsi"
> > diff --git a/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
> > index d2a26f0..d3ae5ab 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
> > @@ -35,4 +35,86 @@
> > bias-pull-down;
> > };
> > };
> > +
> > + /* 0-3 for sdc1 4-6 for sdc2 */
> > + /* Order of pins */
> > + /* SDC1: CLK -> 0, CMD -> 1, DATA -> 2, RCLK -> 3 */
> > + /* SDC2: CLK -> 4, CMD -> 5, DATA -> 6 */
> > + pmx-sdc1-clk {
> > + sdc1_clk_on: clk-on {
> > + pinmux {
> > + pins = "sdc1_clk";
> > + };
>
> The name of these nodes are insignificant, so you don't have to have a
> pinmux and a pinconf, you can describe all properties in one node. I
> even think you can flatten this and drop the inner subnode.
>
Seems reasonable and a little bit more readable.
> > + pinconf {
> > + pins = "sdc1_clk";
> > + bias-disable = <0>; /* No pull */
> > + drive-strength = <16>; /* 16mA */
> > + };
> > + };
> [..]
> > diff --git a/arch/arm64/boot/dts/qcom/msm8992.dtsi b/arch/arm64/boot/dts/qcom/msm8992.dtsi
> > index 44b2d37..77edffc 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8992.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8992.dtsi
> > @@ -82,6 +82,12 @@
> > <0xf9002000 0x1000>;
> > };
> >
> > + apcs: syscon@f900d000 {
> > + compatible = "syscon";
> > + reg = <0xf900d000 0x2000>;
> > + };
> > +
> > +
>
> Please send the SMEM/SMD-ification in a separate patch from the sdhci
> addition.
>
sounds good.
> > timer@f9020000 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > @@ -172,12 +178,159 @@
> > #power-domain-cells = <1>;
> > reg = <0xfc400000 0x2000>;
> > };
> > +
> > + sdhci1: mmc@f9824900 {
> > + compatible = "qcom,sdhci-msm-v4";
> > + reg = <0xf9824900 0x1a0>, <0xf9824000 0x800>;
> > + reg-names = "hc_mem", "core_mem";
> > +
> > + interrupts = <GIC_SPI 123 IRQ_TYPE_NONE>,
> > + <GIC_SPI 138 IRQ_TYPE_NONE>;
> > + interrupt-names = "hc_irq", "pwr_irq";
> > +
> > + clocks = <&clock_gcc GCC_SDCC1_APPS_CLK>,
> > + <&clock_gcc GCC_SDCC1_AHB_CLK>;
> > + clock-names = "core", "iface";
> > +
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&sdc1_clk_on &sdc1_cmd_on &sdc1_data_on
> > + &sdc1_rclk_on>;
> > + pinctrl-1 = <&sdc1_clk_off &sdc1_cmd_off &sdc1_data_off
> > + &sdc1_rclk_off>;
> > +
> > + vdd-supply = <&pm8994_l20>;
> > + qcom,vdd-voltage-level = <2950000 2950000>;
> > + qcom,vdd-current-level = <200 570000>;
>
> These properties are not recognized upstream, please drop.
>
I believe at one point I needed them in order to use some pre-merged
patches. It was a stop gap until the latest SDHCI changes were sent
and now have been merged.
dropped.
> > +
> > + vdd-io-supply = <&pm8994_s4>;
> > + qcom,vdd-io-voltage-level = <1800000 1800000>;
> > + qcom,vdd-io-current-level = <200 325000>;
> > +
> > + regulator-always-on;
> > + bus-width = <8>;
> > + mmc-hs400-1_8v;
> > + status = "okay";
> > + };
> > +
> > + vreg_vph_pwr: vreg-vph-pwr {
> > + compatible = "regulator-fixed";
> > + status = "okay";
> > + regulator-name = "vph-pwr";
> > +
> > + regulator-min-microvolt = <3600000>;
> > + regulator-max-microvolt = <3600000>;
> > +
> > + regulator-always-on;
> > + };
>
> This doesn't have a "reg", so please move it outside "soc"
done and created a patch with just the fixed regulator change on its
own.
>
> > +
> > + rpm_msg_ram: memory@fc428000 {
> > + compatible = "qcom,rpm-msg-ram";
> > + reg = <0xfc428000 0x4000>;
> > + };
> > +
> > + sfpb_mutex_regs: syscon@fd484000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "syscon";
> > + reg = <0xfd484000 0x400>;
> > + };
> > +
> > + sfpb_mutex: hwmutex {
> > + compatible = "qcom,sfpb-mutex";
> > + syscon = <&sfpb_mutex_regs 0x0 0x100>;
> > + #hwlock-cells = <1>;
> > + };
> > +
> > + smem {
> > + compatible = "qcom,smem";
> > + memory-region = <&smem_region>;
> > + qcom,rpm-msg-ram = <&rpm_msg_ram>;
> > + hwlocks = <&sfpb_mutex 3>;
> > + };
>
> The smem enablement here looks reasonable, please split into a separate
> patch.
>
Can the rpm_msg_ram be considered as part of SMEM ?
> > };
> >
> > memory {
> > device_type = "memory";
> > reg = <0 0 0 0>; // bootloader will update
> > };
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + smem_region: smem@6a00000 {
> > + reg = <0x0 0x6a00000 0x0 0x200000>;
> > + no-map;
> > + };
> > + };
> > +
> > + smd_rpm: smd {
>
> You don't have to reference this by label, just saying "/smd" will work
> just as well.
>
msm8994-smd-rpm.dtsi is referencing it. See below.
> > + compatible = "qcom,smd";
> > +
> > + rpm {
> > + interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
> > + qcom,ipc = <&apcs 8 0>;
> > + qcom,smd-edge = <15>;
> > + qcom,local-pid = <0>;
> > + qcom,remote-pid = <6>;
> > +
> > + rpm-requests {
> > + compatible = "qcom,rpm-msm8994";
> > + qcom,smd-channels = "rpm_requests";
> > +
> > + rpmcc: qcom,rpmcc {
> > + /* TODO: update when rpmcc-msm8994 support added */
> > + compatible = "qcom,rpmcc-msm8916",
> > + "qcom,rpmcc";
> > + #clock-cells = <1>;
> > + };
>
> You're not compatible with qcom,rpmcc-msm8916, so don't fool the kernel
> to think you are. Just drop this node until you have a rpmcc and need
> it.
>
dropped
> > +
> > + smd_rpm_regulators: pm8994-regulators {
>
> This label is unused.
>
gone
> > + compatible = "qcom,rpm-pm8994-regulators";
> > +
> > + pm8994_s1: s1 {};
> > + pm8994_s2: s2 {};
> > + pm8994_s3: s3 {};
> > + pm8994_s4: s4 {};
> > + pm8994_s5: s5 {};
> > + pm8994_s6: s6 {};
> > + pm8994_s7: s7 {};
> > +
> > + pm8994_l1: l1 {};
> > + pm8994_l2: l2 {};
> > + pm8994_l3: l3 {};
> > + pm8994_l4: l4 {};
> > + pm8994_l6: l6 {};
> > + pm8994_l8: l8 {};
> > + pm8994_l9: l9 {};
> > + pm8994_l10: l10 {};
> > + pm8994_l11: l11 {};
> > + pm8994_l12: l12 {};
> > + pm8994_l13: l13 {};
> > + pm8994_l14: l14 {};
> > + pm8994_l15: l15 {};
> > + pm8994_l16: l16 {};
> > + pm8994_l17: l17 {};
> > + pm8994_l18: l18 {};
> > + pm8994_l19: l19 {};
> > + pm8994_l20: l20 {};
> > + pm8994_l21: l21 {};
> > + pm8994_l22: l22 {};
> > + pm8994_l23: l23 {};
> > + pm8994_l24: l24 {};
> > + pm8994_l25: l25 {};
> > + pm8994_l26: l26 {};
> > + pm8994_l27: l27 {};
> > + pm8994_l28: l28 {};
> > + pm8994_l29: l29 {};
> > + pm8994_l30: l30 {};
> > + pm8994_l31: l31 {};
> > + pm8994_l32: l32 {};
>
> Add lvs1 & lvs2.
>
ok
> > + };
> > + };
> > + };
> > + };
> > };
> >
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi b/arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi
>
> These rpm settings are not for msm8994, they are for your device. So
> please drop this file and move below nodes into your device dts.
>
Looks like the 8994-rpm-regulator is common between both 8992 & 8994.
Downstream seems to imply that its common. (see lines 3117->3119)
https://android.googlesource.com/kernel/msm.git/+/android-msm-angler-3.10-marshmallow-mr1/arch/arm/boot/dts/qcom/msm8992.dtsi
Do the docs say otherwise? (can only rely on downstream as I don't have
access to the docs).
Also, when testing Bastien's changes on a Nexus 6P which used the same
settings for the RPM as this patch the few peripherals which are enabled
at this point seemed to work.
> [..]
> > +&smd_rpm {
> > + rpm {
> > + rpm_requests {
> > + pm8994-regulators {
> > +
> > + vdd_l1-supply = <&pm8994_s1>;
> > + vdd_l2_26_28-supply = <&pm8994_s3>;
> > + vdd_l3_11-supply = <&pm8994_s3>;
> > + vdd_l4_27_31-supply = <&pm8994_s3>;
> > + vdd_l5_7-supply = <&pm8994_s3>;
> > + vdd_l6_12_32-supply = <&pm8994_s5>;
> > + vdd_l8_16_30-supply = <&vreg_vph_pwr>;
> > + vdd_l9_10_18_22-supply = <&vreg_vph_pwr>;
> > + vdd_l13_19_23_24-supply = <&vreg_vph_pwr>;
> > + vdd_l14_15-supply = <&pm8994_s5>;
> > + vdd_l17_29-supply = <&vreg_vph_pwr>;
> > + vdd_l20_21-supply = <&vreg_vph_pwr>;
> > + vdd_l25-supply = <&pm8994_s5>;
> > + /*vin_lvs1_2 = <&pm8994_s4>; */
>
> I added this to the pm8994 regulator patch I just sent out, called it
> "vdd_lvs1_2".
good, uncommented it.
>
> > +
> [..]
> > diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
> [..]
> >
> > +static const struct rpm_regulator_data rpm_pm8994_regulators[] = {
> > + { "s1", QCOM_SMD_RPM_SMPA, 1, &pma8084_ftsmps, "vdd_s1" },
>
> As with the binding, this isn't entirely correct. Please see my
> submitted patch.
>
I'll go with it as it seems to work for the few peripherals that
are enabled thus far.
-jeremy
> Regards,
> Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] Input: add STMicroelectronics FingerTip touchscreen driver
From: Andi Shyti @ 2017-01-20 0:19 UTC (permalink / raw)
To: Rob Herring
Cc: Andi Shyti, Dmitry Torokhov, Krzysztof Kozlowski, Chanwoo Choi,
Javier Martinez Canillas, linux-input, devicetree, linux-kernel,
linux-samsung-soc, Andi Shyti
In-Reply-To: <20170119181912.lzlcc5zbtue2ojp4@rob-hp-laptop>
Hi Rob,
> > +- compatible : must be "st,stmfts"
>
> Seems too generic. Is this a single device?
the device is precisely called ST-Microelectronics FingerTip S
(stmfts). There are variants, but they all have the same name and
same datasheet.
Maybe I can be more specific in the description, sometimes I
omitted the 'S'.
Andi
^ permalink raw reply
* [PATCH v7 3/3] ARM: dts: imx6q-evi: support cyclone-ps-spi
From: Joshua Clayton @ 2017-01-20 0:12 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer, Russell King, Shawn Guo, Sascha Hauer,
Fabio Estevam
Cc: Mark Rutland, devicetree, Joshua Clayton, linux-fpga,
linux-kernel, Rob Herring, Anatolij Gustschin, linux-arm-kernel
In-Reply-To: <cover.1484869881.git.stillcompiling@gmail.com>
Add support for Altera cyclone V FPGA connected to an spi port
to the evi devicetree file
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
arch/arm/boot/dts/imx6q-evi.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index 24fe093..a0cbb2d 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -82,6 +82,15 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1cs>;
status = "okay";
+
+ fpga_spi: cyclonespi@0 {
+ compatible = "altr,fpga-passive-serial";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ pinctrl-0 = <&pinctrl_fpgaspi>;
+ nconfig-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
+ nstat-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;
+ };
};
&ecspi3 {
@@ -313,6 +322,13 @@
>;
};
+ pinctrl_fpgaspi: fpgaspigrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
+ MX6QDL_PAD_KEY_ROW2__GPIO4_IO11 0x1b0b0
+ >;
+ };
+
pinctrl_gpminand: gpminandgrp {
fsl,pins = <
MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
--
2.9.3
^ permalink raw reply related
* [PATCH v7 2/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Joshua Clayton @ 2017-01-20 0:12 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer, Russell King, Shawn Guo, Sascha Hauer,
Fabio Estevam
Cc: Mark Rutland, devicetree, Joshua Clayton, linux-fpga,
linux-kernel, Rob Herring, Anatolij Gustschin, linux-arm-kernel
In-Reply-To: <cover.1484869881.git.stillcompiling@gmail.com>
cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial"
interface on Altera Cyclone FPGAS.
This is one of the simpler ways to set up an FPGA at runtime.
The signal interface is close to unidirectional spi with lsb first.
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
drivers/fpga/Kconfig | 7 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/cyclone-ps-spi.c | 185 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 193 insertions(+)
create mode 100644 drivers/fpga/cyclone-ps-spi.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index ce861a2..e6c032d 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -20,6 +20,13 @@ config FPGA_REGION
FPGA Regions allow loading FPGA images under control of
the Device Tree.
+config FPGA_MGR_CYCLONE_PS_SPI
+ tristate "Altera Cyclone FPGA Passive Serial over SPI"
+ depends on SPI
+ help
+ FPGA manager driver support for Altera Cyclone using the
+ passive serial interface over SPI
+
config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA || COMPILE_TEST
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8df07bc..a112bef 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_FPGA) += fpga-mgr.o
# FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_CYCLONE_PS_SPI) += cyclone-ps-spi.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
new file mode 100644
index 0000000..ae9c2c8
--- /dev/null
+++ b/drivers/fpga/cyclone-ps-spi.c
@@ -0,0 +1,185 @@
+/**
+ * Altera Cyclone Passive Serial SPI Driver
+ *
+ * Copyright (c) 2017 United Western Technologies, Corporation
+ *
+ * Joshua Clayton <stillcompiling@gmail.com>
+ *
+ * Manage Altera FPGA firmware that is loaded over spi using the passive
+ * serial configuration method.
+ * Firmware must be in binary "rbf" format.
+ * Works on Cyclone V. Should work on cyclone series.
+ * May work on other Altera FPGAs.
+ *
+ */
+
+#include <linux/bitrev.h>
+#include <linux/delay.h>
+#include <linux/fpga/fpga-mgr.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/spi/spi.h>
+#include <linux/sizes.h>
+
+#define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
+#define FPGA_MIN_DELAY 50 /* min usecs to wait for config status */
+#define FPGA_MAX_DELAY 1000 /* max usecs to wait for config status */
+
+struct cyclonespi_conf {
+ struct gpio_desc *config;
+ struct gpio_desc *status;
+ struct spi_device *spi;
+};
+
+static const struct of_device_id of_ef_match[] = {
+ { .compatible = "altr,fpga-passive-serial", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, of_ef_match);
+
+static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+
+ if (gpiod_get_value(conf->status))
+ return FPGA_MGR_STATE_RESET;
+
+ return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int cyclonespi_write_init(struct fpga_manager *mgr,
+ struct fpga_image_info *info,
+ const char *buf, size_t count)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+ int i;
+
+ if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
+ dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
+ return -EINVAL;
+ }
+
+ gpiod_set_value(conf->config, 1);
+ usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
+ if (!gpiod_get_value(conf->status)) {
+ dev_err(&mgr->dev, "Status pin failed to show a reset\n");
+ return -EIO;
+ }
+
+ gpiod_set_value(conf->config, 0);
+ for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
+ usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
+ if (!gpiod_get_value(conf->status))
+ return 0;
+ }
+
+ dev_err(&mgr->dev, "Status pin not ready.\n");
+ return -EIO;
+}
+
+static void rev_buf(char *buf, size_t len)
+{
+ const u8 *fw_end = (buf + len);
+
+ /* set buffer to lsb first */
+ while (buf < fw_end) {
+ *buf = bitrev8(*buf);
+ buf++;
+ }
+}
+
+static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
+ size_t count)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+ const char *fw_data = buf;
+ const char *fw_data_end = fw_data + count;
+
+ while (fw_data < fw_data_end) {
+ int ret;
+ size_t stride = min(fw_data_end - fw_data, SZ_4K);
+
+ rev_buf(fw_data, stride);
+ ret = spi_write(conf->spi, fw_data, stride);
+ if (ret) {
+ dev_err(&mgr->dev, "spi error in firmware write: %d\n",
+ ret);
+ return ret;
+ }
+ fw_data += stride;
+ }
+
+ return 0;
+}
+
+static int cyclonespi_write_complete(struct fpga_manager *mgr,
+ struct fpga_image_info *info)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+
+ if (gpiod_get_value(conf->status)) {
+ dev_err(&mgr->dev, "Error during configuration.\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static const struct fpga_manager_ops cyclonespi_ops = {
+ .state = cyclonespi_state,
+ .write_init = cyclonespi_write_init,
+ .write = cyclonespi_write,
+ .write_complete = cyclonespi_write_complete,
+};
+
+static int cyclonespi_probe(struct spi_device *spi)
+{
+ struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
+ GFP_KERNEL);
+
+ if (!conf)
+ return -ENOMEM;
+
+ conf->spi = spi;
+ conf->config = devm_gpiod_get(&spi->dev, "nconfig", GPIOD_OUT_HIGH);
+ if (IS_ERR(conf->config)) {
+ dev_err(&spi->dev, "Failed to get config gpio: %ld\n",
+ PTR_ERR(conf->config));
+ return PTR_ERR(conf->config);
+ }
+
+ conf->status = devm_gpiod_get(&spi->dev, "nstat", GPIOD_IN);
+ if (IS_ERR(conf->status)) {
+ dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
+ PTR_ERR(conf->status));
+ return PTR_ERR(conf->status);
+ }
+
+ return fpga_mgr_register(&spi->dev,
+ "Altera Cyclone PS SPI FPGA Manager",
+ &cyclonespi_ops, conf);
+}
+
+static int cyclonespi_remove(struct spi_device *spi)
+{
+ fpga_mgr_unregister(&spi->dev);
+
+ return 0;
+}
+
+static struct spi_driver cyclonespi_driver = {
+ .driver = {
+ .name = "cyclone-ps-spi",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(of_ef_match),
+ },
+ .probe = cyclonespi_probe,
+ .remove = cyclonespi_remove,
+};
+
+module_spi_driver(cyclonespi_driver)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Joshua Clayton <stillcompiling@gmail.com>");
+MODULE_DESCRIPTION("Module to load Altera FPGA firmware over spi");
--
2.9.3
^ permalink raw reply related
* [PATCH v7 1/3] doc: dt: add cyclone-ps-spi binding document
From: Joshua Clayton @ 2017-01-20 0:12 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer, Russell King, Shawn Guo, Sascha Hauer,
Fabio Estevam
Cc: Mark Rutland, devicetree, Joshua Clayton, linux-fpga,
linux-kernel, Rob Herring, Anatolij Gustschin, linux-arm-kernel
In-Reply-To: <cover.1484869881.git.stillcompiling@gmail.com>
Describe a cyclone-ps-spi devicetree entry, required features
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
.../bindings/fpga/altera-passive-serial.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/altera-passive-serial.txt
diff --git a/Documentation/devicetree/bindings/fpga/altera-passive-serial.txt b/Documentation/devicetree/bindings/fpga/altera-passive-serial.txt
new file mode 100644
index 0000000..b5f0bb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-passive-serial.txt
@@ -0,0 +1,25 @@
+Altera Cyclone Passive Serial SPI FPGA Manager
+
+Altera Cyclone FPGAs support a method of loading the bitstream over what is
+referred to as "passive serial".
+The passive serial link is not technically spi, and might require extra
+circuits in order to play nicely with other spi slaves on the same bus.
+
+See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
+
+Required properties:
+- compatible: should contain "altr,fpga-passive-serial"
+- reg: spi chip select of the FPGA
+- nstat-gpios: status pin (referred to as nSTATUS in the cyclone manual)
+- nconfig-gpios: config pin (referred to as nCONFIG in the cyclone manual)
+- confd-gpios: confd pin (referred to as CONF_DONE in the cyclone manual)
+
+Example:
+ fpga_spi: evi-fpga-spi@0 {
+ compatible = "altr,cyclone-ps-spi-fpga-mgr";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ nconfig-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
+ nstat-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;
+ confd-gpios = <&gpio4 12 GPIO_ACTIVE_LOW>;
+ };
--
2.9.3
^ permalink raw reply related
* [PATCH v7 0/3] Altera Cyclone Passive Serial SPI FPGA Manager
From: Joshua Clayton @ 2017-01-20 0:12 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer, Russell King, Shawn Guo, Sascha Hauer,
Fabio Estevam
Cc: Mark Rutland, devicetree, Joshua Clayton, linux-fpga,
linux-kernel, Rob Herring, Anatolij Gustschin, linux-arm-kernel
This series adds an FPGA manager for Altera cyclone FPGAs
that can program them using an spi port and a couple of gpios, using
Alteras passive serial protocol.
Changes from v6:
- moved bitrev8x4() out (I'll submit it in a separate patch set)
- Changed the dts format to match what is already done in barebox
(see https://git.pengutronix.de/cgit/barebox/tree/Documentation/devicetree/bindings/firmware/altr,passive-serial.txt)
- Changed error message from "Status pin should be low" to "Status
pin failed to show a reset" for better clarity
- Fixed any whitespace problems that had crept in.
Changes from v5:
- Rebased on next-20161214xi
- Corrected for FPGA Mgr API change in write_init() and write_complete()
- Better describe the device cyclone-ps-spi runs on in the file header.
- Split the bitrev8x4 patch into generic and arch specific patches...
- Added AARCH64 and MIPS implementations of bitrev8x4()... they all have to
have an implementation for it to compile cleanly across platforms
- Added the changes to imx6q-evi.dts to the patch set.
Changes from v4:
- Added the needed return statement to __arch_bitrev8x4()
- Added Rob Herrings ACK for and fix a typo in the commit log of patch 2
Changes from v3:
- Fixed up the state() function to return the state of the status pin
reqested by Alan Tull
- Switched the pin to ACTIVE_LOW and coresponding logic level, and updated
the corresponding documentation. Thanks Rob Herring for pointing out my
mistake.
- Per Rob Herring, switched from "gpio" to "gpios" in dts
Changes from v2:
- Merged patch 3 and 4 as suggested in review by Moritz Fischer
- Changed FPGA_MIN_DELAY from 250 to 50 ms is the time advertized by
Altera. This now works, as we don't assume it is done
Changes from v1:
- Changed the name from cyclone-spi-fpga-mgr to cyclone-ps-spi-fpga-mgr
This name change was requested by Alan Tull, to be specific about which
programming method is being employed on the fpga.
- Changed the name of the reset-gpio to config-gpio to closer match the
way the pins are described in the Altera manual
- Moved MODULE_LICENCE, _AUTHOR, and _DESCRIPTION to the bottom
- Added a bitrev8x4() function to the bitrev headers and implemented ARM
const, runtime, and ARM specific faster versions (This may end up
needing to be a standalone patch)
- Moved the bitswapping into cyclonespi_write(), as requested.
This falls short of my desired generic lsb first spi support, but is a step
in that direction.
- Fixed whitespace problems introduced during refactoring
- Replaced magic number for initial delay with a descriptive macro
- Poll the fpga to see when it is ready rather than a fixed 1 ms sleep
Joshua Clayton (3):
doc: dt: add cyclone-ps-spi binding document
fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
ARM: dts: imx6q-evi: support cyclone-ps-spi
.../bindings/fpga/altera-passive-serial.txt | 25 +++
arch/arm/boot/dts/imx6q-evi.dts | 16 ++
drivers/fpga/Kconfig | 7 +
drivers/fpga/Makefile | 1 +
drivers/fpga/cyclone-ps-spi.c | 185 +++++++++++++++++++++
5 files changed, 234 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/altera-passive-serial.txt
create mode 100644 drivers/fpga/cyclone-ps-spi.c
--
2.9.3
^ permalink raw reply
* Re: [PATCH 7/7] ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-eval
From: kbuild test robot @ 2017-01-20 0:09 UTC (permalink / raw)
Cc: mark.rutland, devicetree, benjamin.gaignard, lars,
alexandre.torgue, linux-iio, linux-kernel, pmeerw, linux, jic23,
robh+dt, kbuild-all, mcoquelin.stm32, knaack.h, fabrice.gasnier,
linux-arm-kernel, benjamin.gaignard
In-Reply-To: <1484832854-6314-8-git-send-email-fabrice.gasnier@st.com>
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
Hi Fabrice,
[auto build test ERROR on next-20170119]
[cannot apply to iio/togreg robh/for-next v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.10-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Fabrice-Gasnier/Add-support-for-triggered-buffer-mode-to-STM32-ADC/20170120-062214
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/stm32429i-eval.dts:179.1-9 Label or path timers1 not found
>> Error: arch/arm/boot/dts/stm32429i-eval.dts:193.1-9 Label or path timers3 not found
FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 22227 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Chris Packham @ 2017-01-19 23:36 UTC (permalink / raw)
To: Sebastian Hesselbarth, linux-arm-kernel@lists.infradead.org
Cc: Mark Rutland, Thomas Petazzoni, linux-gpio@vger.kernel.org,
Linus Walleij, linux-kernel@vger.kernel.org, Kalyan Kinthada,
devicetree@vger.kernel.org, Rob Herring, Laxman Dewangan
In-Reply-To: <42aa88b1-4807-245b-6107-0f1db28679b8@gmail.com>
On 20/01/17 12:19, Sebastian Hesselbarth wrote:
> On 19.01.2017 22:12, Chris Packham wrote:
>> On 14/01/17 20:50, Chris Packham wrote:
>>> On 13/01/17 22:54, Sebastian Hesselbarth wrote:
>>>> On 13.01.2017 10:12, Chris Packham wrote:
>>>>> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>>>>
>>>>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>>>>> from Marvell.
>>>>>
>>>>> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>>>>> ---
>>>>>
>>>>> Notes:
>>>>> Changes in v2:
>>>>> - include sdio support for the 98DX4251
>>>>> Changes in v3:
>>>>> - None
>>>>> Changes in v4:
>>>>> - Correct some discrepencies between binding and driver.
>>>>
>>>> Well, unfortunately I still see differences between the "gpio" in
>>>> the binding and "gpo" in the driver.
>>>>
>>>> Please go back to that list I sent you yesterday and fix them all.
>>>>
>>>
>>> I think you may have missed my initial reply [1]. Or I have missed your
>>> response to it. Long story short "gpo" is intentional because some of
>>> those pins can't be used as inputs. But if you still want me to change
>>> it I will.
>>>
>>> [1] - https://lkml.org/lkml/2017/1/12/117
>>>
>>
>> Did you get a chance to consider this. Do you still want me to change
>> gpo -> gpio given the information above?
>
> Chris,
>
> sorry if I wasn't clear enough. I don't want you to change every gpo
> into gpio. All I was referring to is the _difference_ between driver
> implementation and device tree binding - and soley resolve that.
>
> So, for the gpo's I see that the binding doc still says "gpio" for the
> available functions where the driver expects "gpo".
>
> e.g. the binding has this:
>
> mpp6 6 gpio, sd0(clk), dev(a2)
>
> if you change it to
>
> mpp6 6 gpo, sd0(clk), dev(a2)
>
> both binding and driver are the same, right?
>
> I do understand that the hardware is gp-output only and you correctly
> reflected that in the pinctrl driver - but the binding doc does not
> reflect that for those mpps in the list.
>
Ah OK thanks for clearing up my confusion. I'll make sure the binding
and the driver are consistent when I submit v5 (probably next week).
^ 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