* [PATCH v5 4/5] ARM: dts: stm32: Add watchdog support for STM32F429 eval board
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: devicetree, linux-watchdog, Philippe Cornu, linux-kernel,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1491481168-22213-1-git-send-email-yannick.fertre@st.com>
This patch adds watchdog support for STM32x9I-Eval board.
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
---
arch/arm/boot/dts/stm32429i-eval.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 6e4b42a..ff29980 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -144,6 +144,11 @@
};
};
+&iwdg {
+ status = "okay";
+ timeout-sec = <32>;
+};
+
&adc {
pinctrl-names = "default";
pinctrl-0 = <&adc3_in8_pin>;
--
1.9.1
^ permalink raw reply related
* [PATCH v5 3/5] ARM: dts: stm32: Add watchdog support for STM32F429 SoC
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: devicetree, linux-watchdog, Philippe Cornu, linux-kernel,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1491481168-22213-1-git-send-email-yannick.fertre@st.com>
Add watchdog into DT for stm32f429 family.
Signed-off-by: Yannick FERTRE <yannick.fertre@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 89327d6..d84dd44 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -64,7 +64,7 @@
clock-frequency = <32768>;
};
- clk-lsi {
+ clk_lsi: clk-lsi {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32000>;
@@ -306,6 +306,13 @@
status = "disabled";
};
+ iwdg: watchdog@40003000 {
+ compatible = "st,stm32-iwdg";
+ reg = <0x40003000 0x400>;
+ clocks = <&clk_lsi>;
+ status = "disabled";
+ };
+
usart2: serial@40004400 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004400 0x400>;
--
1.9.1
^ permalink raw reply related
* [PATCH v5 2/5] drivers: watchdog: Add STM32 IWDG driver
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: devicetree, linux-watchdog, Philippe Cornu, linux-kernel,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1491481168-22213-1-git-send-email-yannick.fertre@st.com>
This patch adds IWDG (Independent WatchDoG) support for STM32 platform.
Signed-off-by: Yannick FERTRE <yannick.fertre@st.com>
---
drivers/watchdog/Kconfig | 12 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/stm32_iwdg.c | 253 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 266 insertions(+)
create mode 100644 drivers/watchdog/stm32_iwdg.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 52a70ee..d014deb 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -744,6 +744,18 @@ config ZX2967_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called zx2967_wdt.
+config STM32_WATCHDOG
+ tristate "STM32 Independent WatchDoG (IWDG) support"
+ depends on ARCH_STM32
+ select WATCHDOG_CORE
+ default y
+ help
+ Say Y here to include support for the watchdog timer
+ in stm32 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stm32_iwdg.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a2126e2..a35e423 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
+obj-$(CONFIG_STM32_WATCHDOG) += stm32_iwdg.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
new file mode 100644
index 0000000..6c501b7
--- /dev/null
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -0,0 +1,253 @@
+/*
+ * Driver for STM32 Independent Watchdog
+ *
+ * Copyright (C) Yannick Fertre 2017
+ * Author: Yannick Fertre <yannick.fertre@st.com>
+ *
+ * This driver is based on tegra_wdt.c
+ *
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/watchdog.h>
+
+/* IWDG registers */
+#define IWDG_KR 0x00 /* Key register */
+#define IWDG_PR 0x04 /* Prescaler Register */
+#define IWDG_RLR 0x08 /* ReLoad Register */
+#define IWDG_SR 0x0C /* Status Register */
+#define IWDG_WINR 0x10 /* Windows Register */
+
+/* IWDG_KR register bit mask */
+#define KR_KEY_RELOAD 0xAAAA /* reload counter enable */
+#define KR_KEY_ENABLE 0xCCCC /* peripheral enable */
+#define KR_KEY_EWA 0x5555 /* write access enable */
+#define KR_KEY_DWA 0x0000 /* write access disable */
+
+/* IWDG_PR register bit values */
+#define PR_4 0x00 /* prescaler set to 4 */
+#define PR_8 0x01 /* prescaler set to 8 */
+#define PR_16 0x02 /* prescaler set to 16 */
+#define PR_32 0x03 /* prescaler set to 32 */
+#define PR_64 0x04 /* prescaler set to 64 */
+#define PR_128 0x05 /* prescaler set to 128 */
+#define PR_256 0x06 /* prescaler set to 256 */
+
+/* IWDG_RLR register values */
+#define RLR_MIN 0x07C /* min value supported by reload register */
+#define RLR_MAX 0xFFF /* max value supported by reload register */
+
+/* IWDG_SR register bit mask */
+#define FLAG_PVU BIT(0) /* Watchdog prescaler value update */
+#define FLAG_RVU BIT(1) /* Watchdog counter reload value update */
+
+/* set timeout to 100000 us */
+#define TIMEOUT_US 100000
+#define SLEEP_US 1000
+
+struct stm32_iwdg {
+ struct watchdog_device wdd;
+ void __iomem *regs;
+ struct clk *clk;
+ unsigned int rate;
+};
+
+static inline u32 reg_read(void __iomem *base, u32 reg)
+{
+ return readl_relaxed(base + reg);
+}
+
+static inline void reg_write(void __iomem *base, u32 reg, u32 val)
+{
+ writel_relaxed(val, base + reg);
+}
+
+static int stm32_iwdg_start(struct watchdog_device *wdd)
+{
+ struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
+ u32 val = FLAG_PVU | FLAG_RVU;
+ u32 reload;
+ int ret;
+
+ dev_dbg(wdd->parent, "%s\n", __func__);
+
+ /* prescaler fixed to 256 */
+ reload = clamp_t(unsigned int, ((wdd->timeout * wdt->rate) / 256) - 1,
+ RLR_MIN, RLR_MAX);
+
+ /* enable write access */
+ reg_write(wdt->regs, IWDG_KR, KR_KEY_EWA);
+
+ /* set prescaler & reload registers */
+ reg_write(wdt->regs, IWDG_PR, PR_256); /* prescaler fix to 256 */
+ reg_write(wdt->regs, IWDG_RLR, reload);
+ reg_write(wdt->regs, IWDG_KR, KR_KEY_ENABLE);
+
+ /* wait for the registers to be updated (max 100ms) */
+ ret = readl_relaxed_poll_timeout(wdt->regs + IWDG_SR, val,
+ !(val & (FLAG_PVU | FLAG_RVU)),
+ SLEEP_US, TIMEOUT_US);
+ if (ret) {
+ dev_err(wdd->parent,
+ "Fail to set prescaler or reload registers\n");
+ return ret;
+ }
+
+ /* reload watchdog */
+ reg_write(wdt->regs, IWDG_KR, KR_KEY_RELOAD);
+
+ return 0;
+}
+
+static int stm32_iwdg_ping(struct watchdog_device *wdd)
+{
+ struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
+
+ dev_dbg(wdd->parent, "%s\n", __func__);
+
+ /* reload watchdog */
+ reg_write(wdt->regs, IWDG_KR, KR_KEY_RELOAD);
+
+ return 0;
+}
+
+static int stm32_iwdg_set_timeout(struct watchdog_device *wdd,
+ unsigned int timeout)
+{
+ dev_dbg(wdd->parent, "%s timeout: %d sec\n", __func__, timeout);
+
+ wdd->timeout = timeout;
+
+ if (watchdog_active(wdd))
+ return stm32_iwdg_start(wdd);
+
+ return 0;
+}
+
+static const struct watchdog_info stm32_iwdg_info = {
+ .options = WDIOF_SETTIMEOUT |
+ WDIOF_MAGICCLOSE |
+ WDIOF_KEEPALIVEPING,
+ .identity = "STM32 Independent Watchdog",
+};
+
+static struct watchdog_ops stm32_iwdg_ops = {
+ .owner = THIS_MODULE,
+ .start = stm32_iwdg_start,
+ .ping = stm32_iwdg_ping,
+ .set_timeout = stm32_iwdg_set_timeout,
+};
+
+static int stm32_iwdg_probe(struct platform_device *pdev)
+{
+ struct watchdog_device *wdd;
+ struct stm32_iwdg *wdt;
+ struct resource *res;
+ void __iomem *regs;
+ struct clk *clk;
+ int ret;
+
+ /* This is the timer base. */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(regs)) {
+ dev_err(&pdev->dev, "Could not get resource\n");
+ return PTR_ERR(regs);
+ }
+
+ clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "Unable to get clock\n");
+ return PTR_ERR(clk);
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Unable to prepare clock %p\n", clk);
+ return ret;
+ }
+
+ /*
+ * Allocate our watchdog driver data, which has the
+ * struct watchdog_device nested within it.
+ */
+ wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
+ if (!wdt) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ /* Initialize struct stm32_iwdg. */
+ wdt->regs = regs;
+ wdt->clk = clk;
+ wdt->rate = clk_get_rate(clk);
+
+ /* Initialize struct watchdog_device. */
+ wdd = &wdt->wdd;
+ wdd->info = &stm32_iwdg_info;
+ wdd->ops = &stm32_iwdg_ops;
+ wdd->min_timeout = ((RLR_MIN + 1) * 256) / wdt->rate;
+ wdd->max_hw_heartbeat_ms = ((RLR_MAX + 1) * 256 * 1000) / wdt->rate;
+ wdd->parent = &pdev->dev;
+
+ watchdog_set_drvdata(wdd, wdt);
+ watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT);
+
+ ret = watchdog_init_timeout(wdd, 0, &pdev->dev);
+ if (ret)
+ dev_warn(&pdev->dev,
+ "unable to set timeout value, using default\n");
+
+ ret = watchdog_register_device(wdd);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register watchdog device\n");
+ goto err;
+ }
+
+ platform_set_drvdata(pdev, wdt);
+
+ return 0;
+err:
+ clk_disable_unprepare(clk);
+
+ return ret;
+}
+
+static int stm32_iwdg_remove(struct platform_device *pdev)
+{
+ struct stm32_iwdg *wdt = platform_get_drvdata(pdev);
+
+ watchdog_unregister_device(&wdt->wdd);
+ clk_disable_unprepare(wdt->clk);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_iwdg_of_match[] = {
+ { .compatible = "st,stm32-iwdg" },
+ { /* end node */ }
+};
+MODULE_DEVICE_TABLE(of, stm32_iwdg_of_match);
+
+static struct platform_driver stm32_iwdg_driver = {
+ .probe = stm32_iwdg_probe,
+ .remove = stm32_iwdg_remove,
+ .driver = {
+ .name = "iwdg",
+ .of_match_table = stm32_iwdg_of_match,
+ },
+};
+module_platform_driver(stm32_iwdg_driver);
+
+MODULE_AUTHOR("Yannick Fertre <yannick.fertre@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32 Independent Watchdog Driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v5 1/5] dt-bindings: watchdog: Document STM32 IWDG bindings
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Philippe Cornu,
Gabriel FERNANDEZ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1491481168-22213-1-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>
This adds documentation of device tree bindings for the STM32 IWDG
(Independent WatchDoG).
Signed-off-by: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>
---
.../devicetree/bindings/watchdog/st,stm32-iwdg.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
diff --git a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
new file mode 100644
index 0000000..cc13b10a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
@@ -0,0 +1,19 @@
+STM32 Independent WatchDoG (IWDG)
+---------------------------------
+
+Required properties:
+- compatible: "st,stm32-iwdg"
+- reg: physical base address and length of the registers set for the device
+- clocks: must contain a single entry describing the clock input
+
+Optional Properties:
+- timeout-sec: Watchdog timeout value in seconds.
+
+Example:
+
+iwdg: watchdog@40003000 {
+ compatible = "st,stm32-iwdg";
+ reg = <0x40003000 0x400>;
+ clocks = <&clk_lsi>;
+ timeout-sec = <32>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v5 0/5] STM32 Independent watchdog
From: Yannick Fertre @ 2017-04-06 12:19 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Yannick Fertre, Maxime Coquelin
Cc: devicetree, linux-watchdog, Philippe Cornu, linux-kernel,
Gabriel FERNANDEZ, linux-arm-kernel
Version 5:
- Update bindings (add field timeout-sec)
- Update driver (rework start, rework settings & remove max_timeout)
Version 4:
- Update bindings (iwdg > watchdog)
- Update typo
- Update commit header
- remove gerrit tags
- Update driver (remove unnecessary tests) a add watchdog_init_timeout
Version 3:
- Update typo into bindings file
- Reorder node in devicetree (ordering by address)
- Remove unnecessary lines in commits
Version 2:
- Add commit messages
Version 1:
- Initial commit
The purpose of this set of patches is to add a new watchdog driver for
stm32f429.
This driver was developed and tested on evaluation board stm32429i.
Yannick Fertre (5):
dt-bindings: watchdog: Document STM32 IWDG bindings
drivers: watchdog: Add STM32 IWDG driver
ARM: dts: stm32: Add watchdog support for STM32F429 SoC
ARM: dts: stm32: Add watchdog support for STM32F429 eval board
ARM: configs: stm32: Add watchdog support in STM32 defconfig
.../devicetree/bindings/watchdog/st,stm32-iwdg.txt | 19 ++
arch/arm/boot/dts/stm32429i-eval.dts | 5 +
arch/arm/boot/dts/stm32f429.dtsi | 9 +-
arch/arm/configs/stm32_defconfig | 1 +
drivers/watchdog/Kconfig | 12 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/stm32_iwdg.c | 253 +++++++++++++++++++++
7 files changed, 299 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
create mode 100644 drivers/watchdog/stm32_iwdg.c
--
1.9.1
^ permalink raw reply
* Re: [PATCH V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets
From: Vivek Gautam @ 2017-04-06 12:17 UTC (permalink / raw)
To: Kishon Vijay Abraham I, robh+dt
Cc: linux-arm-kernel, linux-arm-msm, linux-kernel, linux-usb,
devicetree, mark.rutland, sboyd, bjorn.andersson,
srinivas.kandagatla
In-Reply-To: <9f928f13-3bee-6f36-6760-095da5a03495@ti.com>
On 04/06/2017 03:41 PM, Kishon Vijay Abraham I wrote:
>
> On Thursday 06 April 2017 11:21 AM, Vivek Gautam wrote:
>> Hi Kishon,
>> Here's the series with fixed checkpatch warnings/checks.
>> Please pick it for phy/next.
>>
>> This patch series adds couple of PHY drivers for Qualcomm chipsets.
>> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
>> b) qcom-qmp phy driver: that is a combo phy providing support for
>> USB3, PCIe, UFS and few other controllers.
>>
>> The patches are based on next branch of linux-phy tree.
>>
>> These patches have been tested on Dragon board db820c hardware with
>> required set of dt patches.
>> The tested branch[3] is based on torvald's master with greg's usb/usb-next
>> merged. Additionally the patches to get rpm up on msm8996 are also pulled
>> in.
> merged, thanks!
Thanks Kishon.
BRs
Vivek
>
> -Kishon
>> Changes since v7:
>> - Fixed 'checkpatch --strict' alignment warnings/checks, and
>> added Stephen's Reviewed-by tag.
>>
>> Changes since v6:
>> - Rebased on phy/next and *not* including phy grouping series[4].
>> - qusb2-phy: addressed Stephen's comment.
>> - Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
>> - qmp-phy: none on functionality side.
>>
>> Changes since v5:
>> - Addressed review comments from Bjorn:
>> - Removed instances of readl/wirtel_relaxed calls from the drivers.
>> Instead, using simple readl/writel. Inserting a readl after a writel
>> to ensure the write is through to the device.
>> - Replaced regulator handling with regulator_bulk_** apis. This helps
>> in cutting down a lot of regulator handling code.
>> - Fixed minor return statements.
>>
>> Changes since v4:
>> - Addressed comment to add child nodes for qmp phy driver. Each phy lane
>> now has a separate child node under the main qmp node.
>> - Modified the clock and reset initialization and enable methods.
>> Different phys - pcie, usb and later ufs, have varying number of clocks
>> and resets that are mandatory. So adding provision for clocks and reset
>> lists helps in requesting all mandatory resources for individual phys
>> and handle their failure cases accordingly.
>>
>> Changes since v3:
>> - Addressed review comments given by Rob and Stephen for qusb2 phy
>> and qmp phy bindings respectively.
>> - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
>>
>> Changes since v2:
>> - Addressed review comments given by Rob and Stephen for bindings.
>> - Addressed the review comments given by Stephen for the qusb2 and qmp
>> phy drivers.
>>
>> Changes since v1:
>> - Moved device tree binding documentation to separate patches, as suggested
>> by Rob.
>> - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
>> given by Rob.
>> - Addressed review comments from Kishon.
>> - Addressed review comments from Srinivas for QMP phy driver.
>> - Addressed kbuild warning.
>>
>> Please see individual patches for detailed changelogs.
>>
>> [1] https://patchwork.kernel.org/patch/9567767/
>> [2] https://patchwork.kernel.org/patch/9567779/
>> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
>> [4] https://lkml.org/lkml/2017/3/20/407
>>
>> Vivek Gautam (4):
>> dt-bindings: phy: Add support for QUSB2 phy
>> phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
>> dt-bindings: phy: Add support for QMP phy
>> phy: qcom-qmp: new qmp phy driver for qcom-chipsets
>>
>> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 ++
>> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 +
>> drivers/phy/Kconfig | 18 +
>> drivers/phy/Makefile | 2 +
>> drivers/phy/phy-qcom-qmp.c | 1153 ++++++++++++++++++++
>> drivers/phy/phy-qcom-qusb2.c | 493 +++++++++
>> 6 files changed, 1815 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> create mode 100644 drivers/phy/phy-qcom-qmp.c
>> create mode 100644 drivers/phy/phy-qcom-qusb2.c
>>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3
From: Lee Jones @ 2017-04-06 12:11 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Zhang Rui, linux-sunxi,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Quentin Schulz, Maxime Ripard,
Jonathan Cameron,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai
In-Reply-To: <20170406095534.299945C355D-Y9/x5g2N/Tt0ykcd9G8QkxTxI0vvWBSX@public.gmane.org>
On Thu, 06 Apr 2017, Icenowy Zheng wrote:
> 2017年4月6日 03:04于 Rob Herring <robh@kernel.org>写道：
> > On Tue, Apr 4, 2017 at 10:02 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> > > 在 2017年04月04日 22:47, Rob Herring 写道:
> OK. I will make it :
> ths: temperature-sensor@1c25000
Can you fix your broken email client please? You need to set it up to
reply to mails to they stay threaded. Your mailer is currently
sending all of your replies as their own, independent messages.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 00/12] Add Basic SoC support for MT6797
From: Mars Cheng @ 2017-04-06 12:11 UTC (permalink / raw)
To: Matthias Brugger
Cc: Rob Herring, Marc Zyngier, Michael Turquette, Stephen Boyd,
CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
My Chuang, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
wsd_upstream-NuS5LvNUpcJWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490229971.25996.2.camel@mtkswgap22>
Hi Matthias, Stephen
Would you like to give some comments for this patch set?
If there are any suggestions, I will try my best to fix the errors.
Thanks.
On Thu, 2017-03-23 at 08:46 +0800, Mars Cheng wrote:
> Hi Matthias, Rob, Marc, Stephen
>
> gentle ping for this patch set.
>
> Thanks.
>
> On Sun, 2017-03-19 at 23:26 +0800, Mars Cheng wrote:
> > This patch set adds basic SoC support for mediatek's first 10-core
> > chip, X20, also known as MT6797.
> >
> > - based on 4.11-rc1
> > - support multiple base address for sysirq
> > - support common clk framework
> >
> > Changes since v2:
> > - prevent uncessary #intpol-bases for mtk-sysirq
> > - add fast path for mtk-sysirq set_type when introducing multiple bases
> > - add acked-by and tested-by
> > - remove wrong usage for timer node
> >
> > Changes since v1:
> > - add multiple base addresses support, v1 only allow 2 bases
> > - clean up clk driver
> >
> >
> > Kevin-CW Chen (2):
> > dt-bindings: arm: mediatek: document clk bindings for MT6797
> > clk: mediatek: add clk support for MT6797
> >
> > Mars Cheng (10):
> > dt-bindings: mediatek: multiple bases support for sysirq
> > irqchip: mtk-sysirq: extend intpol base to arbitrary number
> > irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
> > dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform
> > arm64: dts: mediatek: add mt6797 support
> > soc: mediatek: avoid using fixed spm power status defines
> > soc: mediatek: add vdec item for scpsys
> > dt-bindings: mediatek: add MT6797 power dt-bindings
> > soc: mediatek: add MT6797 scysys support
> > arm64: dts: mediatek: add clk and scp nodes for MT6797
> >
> > Documentation/devicetree/bindings/arm/mediatek.txt | 4 +
> > .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,imgsys.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,infracfg.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,mmsys.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,topckgen.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,vdecsys.txt | 1 +
> > .../bindings/arm/mediatek/mediatek,vencsys.txt | 3 +-
> > .../interrupt-controller/mediatek,sysirq.txt | 12 +-
> > .../devicetree/bindings/serial/mtk-uart.txt | 1 +
> > .../devicetree/bindings/soc/mediatek/scpsys.txt | 6 +-
> > arch/arm64/boot/dts/mediatek/Makefile | 1 +
> > arch/arm64/boot/dts/mediatek/mt6797-evb.dts | 36 +
> > arch/arm64/boot/dts/mediatek/mt6797.dtsi | 245 +++++++
> > drivers/clk/mediatek/Kconfig | 32 +
> > drivers/clk/mediatek/Makefile | 5 +
> > drivers/clk/mediatek/clk-mt6797-img.c | 76 +++
> > drivers/clk/mediatek/clk-mt6797-mm.c | 136 ++++
> > drivers/clk/mediatek/clk-mt6797-vdec.c | 93 +++
> > drivers/clk/mediatek/clk-mt6797-venc.c | 78 +++
> > drivers/clk/mediatek/clk-mt6797.c | 716 ++++++++++++++++++++
> > drivers/irqchip/irq-mtk-sysirq.c | 116 +++-
> > drivers/soc/mediatek/mtk-scpsys.c | 149 +++-
> > include/dt-bindings/clock/mt6797-clk.h | 281 ++++++++
> > include/dt-bindings/power/mt6797-power.h | 30 +
> > 25 files changed, 1993 insertions(+), 33 deletions(-)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-evb.dts
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6797.dtsi
> > create mode 100644 drivers/clk/mediatek/clk-mt6797-img.c
> > create mode 100644 drivers/clk/mediatek/clk-mt6797-mm.c
> > create mode 100644 drivers/clk/mediatek/clk-mt6797-vdec.c
> > create mode 100644 drivers/clk/mediatek/clk-mt6797-venc.c
> > create mode 100644 drivers/clk/mediatek/clk-mt6797.c
> > create mode 100644 include/dt-bindings/clock/mt6797-clk.h
> > create mode 100644 include/dt-bindings/power/mt6797-power.h
> >
> > --
> > 1.7.9.5
> >
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH V7 1/5] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
From: Guenter Roeck @ 2017-04-06 11:32 UTC (permalink / raw)
To: Steve Twiss, DEVICETREE, LINUX-KERNEL, LINUX-WATCHDOG,
Mark Rutland, Rob Herring, Wim Van Sebroeck
Cc: Dmitry Torokhov, Eduardo Valentin, LINUX-INPUT, LINUX-PM,
Lee Jones, Liam Girdwood, Mark Brown, Support Opensource,
Zhang Rui
In-Reply-To: <1d280a35fc522f7b271c730988ab0f186fef25ba.1491467308.git.stwiss.opensource@diasemi.com>
On 04/06/2017 01:28 AM, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Add binding information for DA9062 and DA9061 watchdog.
>
> Example bindings for both DA9062 and DA9061 devices are added. For
> the DA9061 device, a fallback compatible line is added as a valid
> combination of compatible strings.
>
> The original binding for DA9062 (only) used to reside inside the
> Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
> The da9062-watchdog section was deleted in that file and replaced
> with a link to the new DA9061/62 binding information stored in this
> patch.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> ---
>
> Hi,
>
> I have just noticed.
>
> The driver code changes for the da9062/61 watchdog have been applied to
> the linux kernel. The da9062/61 alterations for
> drivers/watchdog/da9062_wdt.c appear in linux-stable/v4.10-rc1. Those
> changes are linked to this binding patch, but this patch seems to have
> been missed out.
>
> The source code dependency for this patch is given in the commit:
> 72106c1 v4.10-rc1 watchdog: da9062/61: watchdog driver
>
> I don't see anything blocking for merge of this patch now.
>
> Regards,
> Steve
>
> This patch applies against linux-next and v4.11-rc3
>
> v6 -> v7
> - NO CODE CHANGE
>
> v5 -> v6
> - NO CODE CHANGE
> - Rebased from v4.9 to v4.11-rc3
>
> v4 -> v5
> - NO CODE CHANGE
> - Rebased from v4.8 to v4.9
>
> v3 -> v4
> - NO CODE CHANGE
> - Patch renamed from [PATCH V3 2/9] to [PATCH V4 1/8]
> - Added Acked-by Rob Herring
>
> v2 -> v3
> - Patch renamed from [PATCH V1 02/10] to [PATCH V3 2/9]
> - Each compatible line should be a valid combination of compatible
> strings, alter DA9061 line to include the fall back compatible string
> - Update the commit message to describe this change
> - Add information about associated patches from this set without
> describing them as being explicitly dependent on this binding
>
> v1 -> v2
> - Patch renamed from [PATCH V1 07/10] to [PATCH V2 02/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
> - Updated the patch description to be explicit about where parts of
> this binding had originally been stored
> - A second example for DA9061 is provided to highlight the use of a
> fall-back compatible option for the DA9062 watchdog driver
>
> As previously:
>
> For the watchdog case: the DA9062 device driver is compatible with the
> DA9061 and for this reason there is minimal change required to the DA9062
> watchdog device driver. The example for the DA9061 watchdog shows the
> use of a fall-back compatible string.
>
> Other information:
> The device driver from this patch set (associated with this binding) is
> [PATCH V5 6/8] watchdog: da9061: watchdog driver
>
> Regards,
> Steve Twiss, Dialog Semiconductor
>
>
> .../devicetree/bindings/watchdog/da9062-wdt.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> new file mode 100644
> index 0000000..b935b52
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
> @@ -0,0 +1,23 @@
> +* Dialog Semiconductor DA9062/61 Watchdog Timer
> +
> +Required properties:
> +
> +- compatible: should be one of the following valid compatible string lines:
> + "dlg,da9061-watchdog", "dlg,da9062-watchdog"
> + "dlg,da9062-watchdog"
> +
> +Example: DA9062
> +
> + pmic0: da9062@58 {
> + watchdog {
> + compatible = "dlg,da9062-watchdog";
> + };
> + };
> +
> +Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
> +
> + pmic0: da9061@58 {
> + watchdog {
> + compatible = "dlg,da9061-watchdog", "dlg,da9062-watchdog";
> + };
> + };
>
^ permalink raw reply
* Re: [PATCH v4 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Michael Hennerich @ 2017-04-06 11:31 UTC (permalink / raw)
To: Peter Rosin, wsa, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel
In-Reply-To: <a5127934-863a-64d6-88e6-b8119035baf9@axentia.se>
On 06.04.2017 10:39, Peter Rosin wrote:
> Hi Michael,
>
> I would still like to hear from someone with more gpio experience.
I'll ping Linus.
>
> Anyway, from my point of view, there's just a few minor things left,
> with comments inline as usual.
>
> Thanks for you patience!
Thanks for review.
>
> Cheers,
> peda
>
> On 2017-04-05 15:07, michael.hennerich@analog.com wrote:
>> From: Michael Hennerich <michael.hennerich@analog.com>
>>
>> This patch adds support for the Analog Devices / Linear Technology
>> LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
>> The LTC4306 optionally provides two general purpose input/output pins
>> (GPIOs) that can be configured as logic inputs, opendrain outputs or
>> push-pull outputs via the generic GPIOLIB framework.
>>
>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>>
>> ---
>>
>> Changes since v1:
>>
>> - Sort makefile entries
>> - Sort driver includes
>> - Use proper defines
>> - Miscellaneous coding style fixups
>> - Rename mux select callback
>> - Revise i2c-mux-idle-disconnect handling
>> - Add ENABLE GPIO handling on error and device removal.
>> - Remove surplus of_match_device call.
>>
>> Changes since v2:
>>
>> - Stop double error reporting (i2c_mux_add_adapter)
>> - Change subject
>> - Split dt bindings to separate patch
>>
>> Changes since v3:
>>
>> - Change subject and add spaces
>> - Convert to I2C_MUX_LOCKED
>> - Convert to regmap
>> - Remove local register cache
>> - Restore previous ENABLE GPIO handling
>> - Initially pulse ENABLE low
>> - Eliminate i2c client struct in driver state structure
>> - Simplify error return path
>> - Misc minor cleanups
>> ---
>> MAINTAINERS | 8 +
>> drivers/i2c/muxes/Kconfig | 11 ++
>> drivers/i2c/muxes/Makefile | 1 +
>> drivers/i2c/muxes/i2c-mux-ltc4306.c | 310 ++++++++++++++++++++++++++++++++++++
>> 4 files changed, 330 insertions(+)
>> create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index c776906..9a27a19 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7698,6 +7698,14 @@ S: Maintained
>> F: Documentation/hwmon/ltc4261
>> F: drivers/hwmon/ltc4261.c
>>
>> +LTC4306 I2C MULTIPLEXER DRIVER
>> +M: Michael Hennerich <michael.hennerich@analog.com>
>> +W: http://ez.analog.com/community/linux-device-drivers
>> +L: linux-i2c@vger.kernel.org
>> +S: Supported
>> +F: drivers/i2c/muxes/i2c-mux-ltc4306.c
>> +F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
>> +
>> LTP (Linux Test Project)
>> M: Mike Frysinger <vapier@gentoo.org>
>> M: Cyril Hrubis <chrubis@suse.cz>
>> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
>> index 10b3d17..41153b4 100644
>> --- a/drivers/i2c/muxes/Kconfig
>> +++ b/drivers/i2c/muxes/Kconfig
>> @@ -30,6 +30,17 @@ config I2C_MUX_GPIO
>> This driver can also be built as a module. If so, the module
>> will be called i2c-mux-gpio.
>>
>> +config I2C_MUX_LTC4306
>> + tristate "LTC LTC4306/5 I2C multiplexer"
>> + select GPIOLIB
>> + select REGMAP_I2C
>> + help
>> + If you say yes here you get support for the LTC LTC4306 or LTC4305
>
> This reads a bit funny, and I think you should just spell out the
> first LTC? But perhaps not in the tristate above though, depending
> on how long it gets?
Ok - I rename LTC -> Analog Devices
>
>> + I2C mux/switch devices.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called i2c-mux-ltc4306.
>> +
>> config I2C_MUX_PCA9541
>> tristate "NXP PCA9541 I2C Master Selector"
>> help
>> diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
>> index 9948fa4..ff7618c 100644
>> --- a/drivers/i2c/muxes/Makefile
>> +++ b/drivers/i2c/muxes/Makefile
>> @@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o
>> obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
>>
>> obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
>> +obj-$(CONFIG_I2C_MUX_LTC4306) += i2c-mux-ltc4306.o
>> obj-$(CONFIG_I2C_MUX_MLXCPLD) += i2c-mux-mlxcpld.o
>> obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
>> obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
>> diff --git a/drivers/i2c/muxes/i2c-mux-ltc4306.c b/drivers/i2c/muxes/i2c-mux-ltc4306.c
>> new file mode 100644
>> index 0000000..7d34434
>> --- /dev/null
>> +++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
>> @@ -0,0 +1,310 @@
>> +/*
>> + * Linear Technology LTC4306 and LTC4305 I2C multiplexer/switch
>> + *
>> + * Copyright (C) 2017 Analog Devices Inc.
>> + *
>> + * Licensed under the GPL-2.
>> + *
>> + * Based on: i2c-mux-pca954x.c
>> + *
>> + * Datasheet: http://cds.linear.com/docs/en/datasheet/4306.pdf
>> + */
>> +
>> +#include <linux/device.h>
>> +#include <linux/gpio.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/gpio/driver.h>
>> +#include <linux/i2c-mux.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +
>> +#define LTC4305_MAX_NCHANS 2
>> +#define LTC4306_MAX_NCHANS 4
>> +
>> +#define LTC_REG_STATUS 0x0
>> +#define LTC_REG_CONFIG 0x1
>> +#define LTC_REG_MODE 0x2
>> +#define LTC_REG_SWITCH 0x3
>> +
>> +#define LTC_DOWNSTREAM_ACCL_EN BIT(6)
>> +#define LTC_UPSTREAM_ACCL_EN BIT(7)
>> +
>> +#define LTC_GPIO_ALL_INPUT 0xC0
>> +#define LTC_SWITCH_MASK 0xF0
>> +
>> +enum ltc_type {
>> + ltc_4305,
>> + ltc_4306,
>> +};
>> +
>> +struct chip_desc {
>> + u8 nchans;
>> + u8 num_gpios;
>> +};
>> +
>> +struct ltc4306 {
>> + struct regmap *regmap;
>> + struct gpio_chip gpiochip;
>> + const struct chip_desc *chip;
>> +};
>> +
>> +static const struct chip_desc chips[] = {
>> + [ltc_4305] = {
>> + .nchans = LTC4305_MAX_NCHANS,
>> + },
>> + [ltc_4306] = {
>> + .nchans = LTC4306_MAX_NCHANS,
>> + .num_gpios = 2,
>> + },
>> +};
>> +
>> +static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg)
>> +{
>> + return (reg == LTC_REG_CONFIG) ? true : false;
>> +}
>> +
>> +static const struct regmap_config ltc4306_regmap_config = {
>> + .reg_bits = 8,
>> + .val_bits = 8,
>> + .max_register = LTC_REG_SWITCH,
>> + .volatile_reg = ltc4306_is_volatile_reg,
>> + .cache_type = REGCACHE_RBTREE,
>
> Did you consider REGCACHE_FLAT? There are very few registers and no hole
> in the map, and maintaining a tree seems like total overkill.
There is no reason to use REGCACHE_FLAT, in our case it will be a single
node.
>
>> +};
>> +
>> +static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> + unsigned int val;
>> + int ret;
>> +
>> + ret = regmap_read(data->regmap, LTC_REG_CONFIG, &val);
>> + if (ret < 0)
>> + return ret;
>> +
>> + return (val & BIT(1 - offset));
>
> The outer parentheses do not add anything, and I think they might remain
> from when you just removed a double negation at some point. But is it
> good practice to indicate "high" with anything other than one? Sure, the
> gpiolib function that wraps the ->get() op does the !! dance for you,
> but even so, every single one of the half dozen random gpio providers I
> looked at had code to coerce the value to 0/1 (or error). Which makes me
> think you should also have it. And the gpio_chip documentation on ->get()
> agrees with me...
I'll restore the double negations.
>
>> +}
>> +
>> +static void ltc4306_gpio_set(struct gpio_chip *chip, unsigned int offset,
>> + int value)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + regmap_update_bits(data->regmap, LTC_REG_CONFIG, BIT(5 - offset),
>> + value ? BIT(5 - offset) : 0);
>> +}
>> +
>> +static int ltc4306_gpio_direction_input(struct gpio_chip *chip,
>> + unsigned int offset)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
>> + BIT(7 - offset), BIT(7 - offset));
>> +}
>> +
>> +static int ltc4306_gpio_direction_output(struct gpio_chip *chip,
>> + unsigned int offset, int value)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + ltc4306_gpio_set(chip, offset, value);
>> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
>> + BIT(7 - offset), 0);
>> +}
>> +
>> +static int ltc4306_gpio_set_config(struct gpio_chip *chip,
>> + unsigned int offset, unsigned long config)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> + unsigned int val;
>> +
>> + switch (pinconf_to_config_param(config)) {
>> + case PIN_CONFIG_DRIVE_OPEN_DRAIN:
>> + val = 0;
>> + break;
>> + case PIN_CONFIG_DRIVE_PUSH_PULL:
>> + val = BIT(4 - offset);
>> + break;
>> + default:
>> + return -ENOTSUPP;
>> + }
>> +
>> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
>> + BIT(4 - offset), val);
>> +}
>> +
>> +static int ltc4306_gpio_init(struct ltc4306 *data)
>> +{
>> + struct device *dev = regmap_get_device(data->regmap);
>> +
>> + if (!data->chip->num_gpios)
>> + return 0;
>> +
>> + data->gpiochip.label = dev_name(dev);
>> + data->gpiochip.base = -1;
>> + data->gpiochip.ngpio = data->chip->num_gpios;
>> + data->gpiochip.parent = dev;
>> + data->gpiochip.can_sleep = true;
>> + data->gpiochip.direction_input = ltc4306_gpio_direction_input;
>> + data->gpiochip.direction_output = ltc4306_gpio_direction_output;
>
> I'm missing a get_direction op?
No - its purely optional - the vast majority of gpiochips don't
implement it.
linux/drivers/gpio$ grep -lr --include \*.c get_direction | wc
36 36 523
linux/drivers/gpio$ grep -Lr --include \*.c get_direction | wc
101 101 1461
>
>> + data->gpiochip.get = ltc4306_gpio_get;
>> + data->gpiochip.set = ltc4306_gpio_set;
>> + data->gpiochip.set_config = ltc4306_gpio_set_config;
>> + data->gpiochip.owner = THIS_MODULE;
>> +
>> + /* gpiolib assumes all GPIOs default input */
>> + regmap_write(data->regmap, LTC_REG_MODE, LTC_GPIO_ALL_INPUT);
>> +
>> + return devm_gpiochip_add_data(dev, &data->gpiochip, data);
>> +}
>> +
>> +static int ltc4306_select_mux(struct i2c_mux_core *muxc, u32 chan)
>> +{
>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>> +
>> + return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
>> + LTC_SWITCH_MASK, BIT(7 - chan));
>
> Since the bits outside the mask are ignored for writes, I'd go with
> regmap_write. Especially since those bits are volatile, which admittedly
> will not have much impact until there is a need to read those volatile
> bits outside the mask. But still.
Yes they are volatile - but not declared as such.
So regmap cache just ignores them.
And we totally ignore these RONLY status bits, too.
regmap_write() will always write and ignore the cache, while
regmap_update_bits() uses the cached value.
Are these callbacks guaranteed to be never called with the same CHAN
sequentially? if yes - use regmap_write() otherwise its more efficient
to use regmap_update_bits().
>
>> +}
>> +
>> +static int ltc4306_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
>> +{
>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>> +
>> + return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
>> + LTC_SWITCH_MASK, 0);
>
> Dito.
>
>> +}
>> +
>> +static const struct i2c_device_id ltc4306_id[] = {
>> + { "ltc4305", ltc_4305 },
>> + { "ltc4306", ltc_4306 },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, ltc4306_id);
>> +
>> +static const struct of_device_id ltc4306_of_match[] = {
>> + { .compatible = "lltc,ltc4305", .data = &chips[ltc_4305] },
>> + { .compatible = "lltc,ltc4306", .data = &chips[ltc_4306] },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, ltc4306_of_match);
>> +
>> +static int ltc4306_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
>> + struct device_node *of_node = client->dev.of_node;
>> + struct i2c_mux_core *muxc;
>> + struct ltc4306 *data;
>> + struct gpio_desc *gpio;
>> + bool idle_disc = false;
>> + int num, ret;
>> +
>> + if (of_node)
>> + idle_disc = of_property_read_bool(of_node,
>> + "i2c-mux-idle-disconnect");
>> +
>> + muxc = i2c_mux_alloc(adap, &client->dev,
>> + LTC4306_MAX_NCHANS, sizeof(*data),
>
> Hmmm, I didn't see this before, but if you do some more rearranging, it
> should be possible to replace LTC4306_MAX_NCHANS with data->chip->nchans
> and reduce resource waste for ltc4305. But it's just storage for two
> pointers which is really really minor... Feel free to ignore.
>
> But you want to set a good example, right :-)
>
>> + I2C_MUX_LOCKED, ltc4306_select_mux,
>> + idle_disc ? ltc4306_deselect_mux : NULL);
>> + if (!muxc)
>> + return -ENOMEM;
>> + data = i2c_mux_priv(muxc);
>> +
>> + i2c_set_clientdata(client, muxc);
>> +
>> + data->regmap = devm_regmap_init_i2c(client, <c4306_regmap_config);
>> + if (IS_ERR(data->regmap)) {
>> + ret = PTR_ERR(data->regmap);
>> + dev_err(&client->dev, "Failed to allocate register map: %d\n",
>> + ret);
>> + return ret;
>> + }
>> +
>> + /* Reset and enable the mux if an enable GPIO is specified. */
>> + gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_LOW);
>> + if (IS_ERR(gpio))
>> + return PTR_ERR(gpio);
>> +
>> + if (gpio) {
>> + udelay(1);
>> + gpiod_set_value(gpio, 1);
>> + }
>> +
>> + /*
>> + * Write the mux register at addr to verify
>> + * that the mux is in fact present. This also
>> + * initializes the mux to disconnected state.
>> + */
>> + if (regmap_write(data->regmap, LTC_REG_SWITCH, 0) < 0) {
>> + dev_warn(&client->dev, "probe failed\n");
>> + return -ENODEV;
>> + }
>> +
>> + if (of_node) {
>> + unsigned int val = 0;
>> +
>> + data->chip = of_device_get_match_data(&client->dev);
>> +
>> + if (of_property_read_bool(of_node,
>> + "ltc,downstream-accelerators-enable"))
>> + val |= LTC_DOWNSTREAM_ACCL_EN;
>> +
>> + if (of_property_read_bool(of_node,
>> + "ltc,upstream-accelerators-enable"))
>> + val |= LTC_UPSTREAM_ACCL_EN;
>> +
>> + if (regmap_write(data->regmap, LTC_REG_CONFIG, val) < 0)
>> + return -ENODEV;
>> + } else {
>> + data->chip = &chips[id->driver_data];
>> + }
>> +
>> + ret = ltc4306_gpio_init(data);
>> + if (ret < 0)
>> + return ret;
>> +
>> + /* Now create an adapter for each channel */
>> + for (num = 0; num < data->chip->nchans; num++) {
>> + ret = i2c_mux_add_adapter(muxc, 0, num, 0);
>> + if (ret) {
>> + i2c_mux_del_adapters(muxc);
>> + return ret;
>> + }
>> + }
>> +
>> + dev_info(&client->dev,
>> + "registered %d multiplexed busses for I2C switch %s\n",
>> + num, client->name);
>> +
>> + return 0;
>> +}
>> +
>> +static int ltc4306_remove(struct i2c_client *client)
>> +{
>> + struct i2c_mux_core *muxc = i2c_get_clientdata(client);
>> +
>> + i2c_mux_del_adapters(muxc);
>> +
>> + return 0;
>> +}
>> +
>> +static struct i2c_driver ltc4306_driver = {
>> + .driver = {
>> + .name = "ltc4306",
>> + .of_match_table = of_match_ptr(ltc4306_of_match),
>> + },
>> + .probe = ltc4306_probe,
>> + .remove = ltc4306_remove,
>> + .id_table = ltc4306_id,
>> +};
>> +
>> +module_i2c_driver(ltc4306_driver);
>> +
>> +MODULE_AUTHOR("Michael Hennerich <michael.hennerich@analog.com>");
>> +MODULE_DESCRIPTION("Linear Technology LTC4306, LTC4305 I2C mux/switch driver");
>> +MODULE_LICENSE("GPL v2");
>>
>
>
--
Greetings,
Michael
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
^ permalink raw reply
* Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask
From: Sricharan R @ 2017-04-06 11:01 UTC (permalink / raw)
To: Frank Rowand, robin.murphy, will.deacon, joro, lorenzo.pieralisi,
iommu, linux-arm-kernel, linux-arm-msm, m.szyprowski, bhelgaas,
linux-pci, linux-acpi, tn, hanjun.guo, okaya, robh+dt, devicetree,
linux-kernel, sudeep.holla, rjw, lenb, catalin.marinas, arnd,
linux-arch, gregkh
In-Reply-To: <58E5E7B7.1050400@gmail.com>
Hi Frank,
On 4/6/2017 12:31 PM, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> Size of the dma-range is calculated as coherent_dma_mask + 1
>> and passed to arch_setup_dma_ops further. It overflows when
>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF,
>> resulting in size getting passed as 0 wrongly. Fix this by
>> passsing in max(mask, mask + 1). Note that in this case
>> when the mask is set to full 64bits, we will be passing the mask
>> itself to arch_setup_dma_ops instead of the size. The real fix
>> for this should be to make arch_setup_dma_ops receive the
>> mask and handle it, to be done in the future.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/of/device.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index c17c19d..c2ae6bb 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>> if (ret < 0) {
>> dma_addr = offset = 0;
>> - size = dev->coherent_dma_mask + 1;
>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>> } else {
>> offset = PFN_DOWN(paddr - dma_addr);
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>
>
> NACK.
>
> Passing an invalid size to arch_setup_dma_ops() is only part of the problem.
> size is also used in of_dma_configure() before calling arch_setup_dma_ops():
>
> dev->coherent_dma_mask = min(dev->coherent_dma_mask,
> DMA_BIT_MASK(ilog2(dma_addr + size)));
> *dev->dma_mask = min((*dev->dma_mask),
> DMA_BIT_MASK(ilog2(dma_addr + size)));
>
> which would be incorrect for size == 0xffffffffffffffffULL when
> dma_addr != 0. So the proposed fix really is not papering over
> the base problem very well.
>
Ok, but with your fix for of_dma_get_range and the above fix,
dma_addr will be '0' when size = 0xffffffffffffffffULL,
but DMA_BIT_MASK(ilog2(dma_addr + size)) would be wrong though,
making coherent_dma_mask to be smaller 0x7fffffffffffffffULL.
Regards,
Sricharan
> I agree that the proper solution involves passing a mask instead
> of a size to arch_setup_dma_ops().
>
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 07/16] regulator: madera-micsupp: Mic supply for Cirrus Logic Madera codecs
From: Mark Brown @ 2017-04-06 10:57 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: gnurou, alsa-devel, jason, devicetree, linus.walleij, patches,
linux-kernel, linux-gpio, robh+dt, tglx, lee.jones
In-Reply-To: <1491400437.4096.5.camel@rf-debian.wolfsonmicro.main>
[-- Attachment #1.1: Type: text/plain, Size: 650 bytes --]
On Wed, Apr 05, 2017 at 02:53:57PM +0100, Richard Fitzgerald wrote:
> On Wed, 2017-04-05 at 14:40 +0100, Mark Brown wrote:
> > Again, this appears to have only data and minor code style changes
> > relative to the existing arizona driver - is there no opportunity for
> > code sharing here?
> I'll have a look at how it would work out.
> My thought was that these two regulator drivers are so small it wasn't
> worth creating an entanglement between arizona and madera for so little
> code.
It's a fairly small amount of code but it's an extremely high proportion
of the code in the driver and doing something a bit unusual, not just
boilerplate.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/9] phy: phy-mt65xx-usb3: improve RX detection stable time
From: Chunfeng Yun @ 2017-04-06 10:49 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Matthias Brugger, Felipe Balbi, Rob Herring, Mark Rutland,
Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <de1b9870-d325-e97a-a2f0-bd355c70356c-l0cyMroinI0@public.gmane.org>
On Thu, 2017-04-06 at 15:58 +0530, Kishon Vijay Abraham I wrote:
>
> On Friday 31 March 2017 01:05 PM, Chunfeng Yun wrote:
> > The default value of RX detection stable time is 10us, and this
> > margin is too big for some critical cases which cause U3 link fail
> > and link to U2(probability is about 1%). So change it to 5us.
> >
> merged all the phy patches in this series to linux-phy -next.
Thanks a lot
>
> Thanks
> Kishon
>
> > Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/phy/phy-mt65xx-usb3.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> > index d972067..fe2392a 100644
> > --- a/drivers/phy/phy-mt65xx-usb3.c
> > +++ b/drivers/phy/phy-mt65xx-usb3.c
> > @@ -112,6 +112,14 @@
> > #define P3D_RG_CDR_BIR_LTD0 GENMASK(12, 8)
> > #define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8)
> >
> > +#define U3P_U3_PHYD_RXDET1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x128)
> > +#define P3D_RG_RXDET_STB2_SET GENMASK(17, 9)
> > +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9)
> > +
> > +#define U3P_U3_PHYD_RXDET2 (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c)
> > +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0)
> > +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x) (0x1ff & (x))
> > +
> > #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018)
> > #define XC3_RG_U3_XTAL_RX_PWD BIT(9)
> > #define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8)
> > @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
> > tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3);
> > writel(tmp, port_base + U3P_PHYD_CDR1);
> >
> > + tmp = readl(port_base + U3P_U3_PHYD_RXDET1);
> > + tmp &= ~P3D_RG_RXDET_STB2_SET;
> > + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10);
> > + writel(tmp, port_base + U3P_U3_PHYD_RXDET1);
> > +
> > + tmp = readl(port_base + U3P_U3_PHYD_RXDET2);
> > + tmp &= ~P3D_RG_RXDET_STB2_SET_P3;
> > + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10);
> > + writel(tmp, port_base + U3P_U3_PHYD_RXDET2);
> > +
> > dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
> > }
> >
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] phy: rockchip-usb: Add vbus regulator support.
From: Kishon Vijay Abraham I @ 2017-04-06 10:37 UTC (permalink / raw)
To: Sjoerd Simons, John Youn, Heiko Stuebner
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Randy Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170405140613.4444-2-sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
On Wednesday 05 April 2017 07:36 PM, Sjoerd Simons wrote:
> On rockchip devices vbus is supplied by a separate power supply, often
> through a regulator. Add support for describing the the regulator in
> device-tree following the same convention as several other usb phy's.
>
merged, thanks.
-Kishon
> Signed-off-by: Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> ---
>
> .../devicetree/bindings/phy/rockchip-usb-phy.txt | 1 +
> drivers/phy/phy-rockchip-usb.c | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
> index 57dc388e2fa2..4ed569046daf 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
> @@ -30,6 +30,7 @@ Optional Properties:
> - reset-names: Only allow the following entries:
> - phy-reset
> - resets: Must contain an entry for each entry in reset-names.
> +- vbus-supply: power-supply phandle for vbus power source
>
> Example:
>
> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
> index 734987fa0ad7..3378eeb7a562 100644
> --- a/drivers/phy/phy-rockchip-usb.c
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -66,6 +66,7 @@ struct rockchip_usb_phy {
> struct phy *phy;
> bool uart_enabled;
> struct reset_control *reset;
> + struct regulator *vbus;
> };
>
> static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
> @@ -88,6 +89,9 @@ static void rockchip_usb_phy480m_disable(struct clk_hw *hw)
> struct rockchip_usb_phy,
> clk480m_hw);
>
> + if (phy->vbus)
> + regulator_disable(phy->vbus);
> +
> /* Power down usb phy analog blocks by set siddq 1 */
> rockchip_usb_phy_power(phy, 1);
> }
> @@ -143,6 +147,14 @@ static int rockchip_usb_phy_power_on(struct phy *_phy)
> if (phy->uart_enabled)
> return -EBUSY;
>
> + if (phy->vbus) {
> + int ret;
> +
> + ret = regulator_enable(phy->vbus);
> + if (ret)
> + return ret;
> + }
> +
> return clk_prepare_enable(phy->clk480m);
> }
>
> @@ -268,6 +280,13 @@ static int rockchip_usb_phy_init(struct rockchip_usb_phy_base *base,
> }
> phy_set_drvdata(rk_phy->phy, rk_phy);
>
> + rk_phy->vbus = devm_regulator_get_optional(&rk_phy->phy->dev, "vbus");
> + if (IS_ERR(rk_phy->vbus)) {
> + if (PTR_ERR(rk_phy->vbus) == -EPROBE_DEFER)
> + return PTR_ERR(rk_phy->vbus);
> + rk_phy->vbus = NULL;
> + }
> +
> /*
> * When acting as uart-pipe, just keep clock on otherwise
> * only power up usb phy when it use, so disable it when init
>
^ permalink raw reply
* [RFC] Documentation: pinctrl: Add "pinmux" property
From: Jacopo Mondi @ 2017-04-06 10:35 UTC (permalink / raw)
To: linus.walleij, geert, robh+dt, mark.rutland
Cc: linux-gpio, devicetree, linux-renesas-soc, linux-kernel
Document "pinmux" property as part of generic pin controller
documentation.
Fix 2 minor typos in documentation while at there.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
Hi Linus and linux-gpio community.
During development of Renesas RZ/A1 pin controller I've been suggested to add
description of "pinmux" property to generic pin controller documentation.
Currently several pin controller drivers are using this property in place of
the already documented "pin"/"group" and "function" ones: stm32, mt65xx, mt8173
and in-review r7s72100, not sure about at91-sama5d2)
Sending this one as RFC to collect feedback. If the change is not rejected is it
worth adding to pin controller core helper functions to parse the newly
documented property, as this commit
<https://patchwork.kernel.org/patch/9411231/>
did for "pinctrl-pin-array" one?
All drivers using "pinmux" exhibit the same behavior which is fine as long as
"pinmux" only accepts a list of u32 parameters.
...
pins = of_find_property(node, "pinmux", NULL);
...
npins = pins->length / sizeof(u32);
...
of_property_read_u32_index(node, "pinmux",
i, &pinfunc);
...
Thanks
---
.../bindings/pinctrl/pinctrl-bindings.txt | 46 +++++++++++++++++++---
1 file changed, 41 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index f2ed458..6609389 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -162,8 +162,8 @@ state_2_node_a {
pins = "mfio29", "mfio30";
};
-Optionally an altenative binding can be used if more suitable depending on the
-pin controller hardware. For hardaware where there is a large number of identical
+Optionally an alternative binding can be used if more suitable depending on the
+pin controller hardware. For hardware where there is a large number of identical
pin controller instances, naming each pin and function can easily become
unmaintainable. This is especially the case if the same controller is used for
different pins and functions depending on the SoC revision and packaging.
@@ -198,6 +198,28 @@ registers, and must not be a virtual index of pin instances. The reason for
this is to avoid mapping of the index in the dts files and the pin controller
driver as it can change.
+For hardware where pin multiplexing configurations have to be specified for
+each single pin the number of required sub-nodes containing "pin" and
+"function" properties can quickly escalate and become hard to write and
+maintain.
+
+For cases like this, the pin controller driver may use the pinmux helper
+property, where the pin identifier is packed with mux configuration settings
+in a single integer.
+
+The pinmux property accepts an array of integers, each of them describing
+a single pin multiplexing configuration.
+
+pincontroller {
+ state_0_node_a {
+ pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ...;
+ };
+};
+
+Each individual pin controller driver bindings documentation shall specify
+how those values (pin IDs and pin multiplexing configuration) are defined and
+assembled together.
+
== Generic pin configuration node content ==
Many data items that are represented in a pin configuration node are common
@@ -210,12 +232,15 @@ structure of the DT nodes that contain these properties.
Supported generic properties are:
pins - the list of pins that properties in the node
- apply to (either this or "group" has to be
+ apply to (either this, "group" or "pinmux" has to be
specified)
group - the group to apply the properties to, if the driver
supports configuration of whole groups rather than
- individual pins (either this or "pins" has to be
- specified)
+ individual pins (either this, "pins" or "pinmux" has
+ to be specified)
+pinmux - the list of numeric pin ids and their mux settings
+ that properties in the node apply to (either this,
+ "pins" or "groups" have to be specified)
bias-disable - disable any pin bias
bias-high-impedance - high impedance mode ("third-state", "floating")
bias-bus-hold - latch weakly
@@ -260,6 +285,12 @@ state_2_node_a {
bias-pull-up;
};
};
+state_3_node_a {
+ mux {
+ pinmux = <GPIOx_PINm_MUXn>, <GPIOx_PINj_MUXk)>;
+ input-enable;
+ };
+};
Some of the generic properties take arguments. For those that do, the
arguments are described below.
@@ -268,6 +299,11 @@ arguments are described below.
binding for the hardware defines:
- Whether the entries are integers or strings, and their meaning.
+- pinmux takes a list of pin IDs and mux settings as required argument. The
+ specific bindings for the hardware defines:
+ - How pin IDs and mux settings are defined and assembled together in a single
+ integer.
+
- bias-pull-up, -down and -pin-default take as optional argument on hardware
supporting it the pull strength in Ohm. bias-disable will disable the pull.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v5 1/9] phy: phy-mt65xx-usb3: improve RX detection stable time
From: Kishon Vijay Abraham I @ 2017-04-06 10:28 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Felipe Balbi, Ian Campbell, linux-usb,
linux-kernel, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
In-Reply-To: <1490945735-9531-1-git-send-email-chunfeng.yun@mediatek.com>
On Friday 31 March 2017 01:05 PM, Chunfeng Yun wrote:
> The default value of RX detection stable time is 10us, and this
> margin is too big for some critical cases which cause U3 link fail
> and link to U2(probability is about 1%). So change it to 5us.
>
merged all the phy patches in this series to linux-phy -next.
Thanks
Kishon
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/phy/phy-mt65xx-usb3.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> index d972067..fe2392a 100644
> --- a/drivers/phy/phy-mt65xx-usb3.c
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -112,6 +112,14 @@
> #define P3D_RG_CDR_BIR_LTD0 GENMASK(12, 8)
> #define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8)
>
> +#define U3P_U3_PHYD_RXDET1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x128)
> +#define P3D_RG_RXDET_STB2_SET GENMASK(17, 9)
> +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9)
> +
> +#define U3P_U3_PHYD_RXDET2 (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c)
> +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0)
> +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x) (0x1ff & (x))
> +
> #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018)
> #define XC3_RG_U3_XTAL_RX_PWD BIT(9)
> #define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8)
> @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
> tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3);
> writel(tmp, port_base + U3P_PHYD_CDR1);
>
> + tmp = readl(port_base + U3P_U3_PHYD_RXDET1);
> + tmp &= ~P3D_RG_RXDET_STB2_SET;
> + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10);
> + writel(tmp, port_base + U3P_U3_PHYD_RXDET1);
> +
> + tmp = readl(port_base + U3P_U3_PHYD_RXDET2);
> + tmp &= ~P3D_RG_RXDET_STB2_SET_P3;
> + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10);
> + writel(tmp, port_base + U3P_U3_PHYD_RXDET2);
> +
> dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
> }
>
>
^ permalink raw reply
* Re: [PATCH 0/2] pmu0 MMIO region for A64 USB PHY
From: Kishon Vijay Abraham I @ 2017-04-06 10:26 UTC (permalink / raw)
To: Icenowy Zheng, Maxime Ripard, Chen-Yu Tsai, Greg Kroah-Hartman
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405143034.8868-1-icenowy-h8G6r0blFSE@public.gmane.org>
Hi,
On Wednesday 05 April 2017 08:00 PM, Icenowy Zheng wrote:
> The USB PHY of A64 contains a "pmu0" MMIO region, which contains some control
> registers for the EHCI0/OHCI0 pair on A64 SoC.
>
> This pair is not used currently in 4.11, but when enabling it in 4.12, the
> MMIO region is needed.
>
> In order to prevent device tree compatibility breakage, add this region in
> 4.11.
I feel the binding documentation can go along with the dt changes. Moreover I
have no plans of sending another pull request for this -rc cycle.
FWIW:
Acked-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Thanks
Kishon
>
> Icenowy Zheng (2):
> dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64
> arm64: allwinner: a64: add pmu0 regs for USB PHY
>
> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 ++
> 2 files changed, 3 insertions(+)
>
^ permalink raw reply
* Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask
From: Robin Murphy @ 2017-04-06 10:24 UTC (permalink / raw)
To: Frank Rowand, Sricharan R, will.deacon-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, tn-nYOzD4b6Jr9Wk0Htik3J/w,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A, okaya-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sudeep.holla-5wv7dgnIgG8,
rjw-LthD3rsA81gm4RdzfppkhA, lenb-DgEjT+Ai2ygdnm+yROfE0A,
catalin.marinas-5wv7dgnIgG8, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
In-Reply-To: <58E5E7B7.1050400-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 06/04/17 08:01, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> Size of the dma-range is calculated as coherent_dma_mask + 1
>> and passed to arch_setup_dma_ops further. It overflows when
>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF,
>> resulting in size getting passed as 0 wrongly. Fix this by
>> passsing in max(mask, mask + 1). Note that in this case
>> when the mask is set to full 64bits, we will be passing the mask
>> itself to arch_setup_dma_ops instead of the size. The real fix
>> for this should be to make arch_setup_dma_ops receive the
>> mask and handle it, to be done in the future.
>>
>> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> drivers/of/device.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index c17c19d..c2ae6bb 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>> if (ret < 0) {
>> dma_addr = offset = 0;
>> - size = dev->coherent_dma_mask + 1;
>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>> } else {
>> offset = PFN_DOWN(paddr - dma_addr);
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>
>
> NACK.
>
> Passing an invalid size to arch_setup_dma_ops() is only part of the problem.
> size is also used in of_dma_configure() before calling arch_setup_dma_ops():
>
> dev->coherent_dma_mask = min(dev->coherent_dma_mask,
> DMA_BIT_MASK(ilog2(dma_addr + size)));
> *dev->dma_mask = min((*dev->dma_mask),
> DMA_BIT_MASK(ilog2(dma_addr + size)));
>
> which would be incorrect for size == 0xffffffffffffffffULL when
> dma_addr != 0. So the proposed fix really is not papering over
> the base problem very well.
I'm not sure I agree there. Granted, there exist many more problematic
aspects than are dealt with here (I've got more patches cooking to sort
out some of the other issues we have with dma-ranges), but considering
size specifically:
- It is not possible to explicitly specify a range with a size of 2^64
in DT. If someone does specify a size of 0, they've done a silly thing
and should not be surprised that it ends badly.
- It *is* perfectly legitimate for bus code (or a previous device
driver, once we start coming here at probe time) to have set a device's
DMA mask to 0xffffffffffffffffULL. If this code then blindly overflows
and infers an invalid size of 0 from that, breaking things in the
process, that is this code's fault alone. It just so happens that
nothing managed to trigger the latent problem until patch #7 here shakes
up the callsites.
Yes, wacky impossible base + size combinations in DT were a theoretical
problem before, and remain a theoretical problem, but also fall into the
"how did you ever expect this to work?" category. There's certainly
plenty more we can do to improve the DT parsing/validation, but that
still doesn't apply to this path where the information is *not* coming
from the DT at all.
> I agree that the proper solution involves passing a mask instead
> of a size to arch_setup_dma_ops().
Having started writing that patch too, I can tell you it's a big bugger
touching multiple architectures and fixing up various drivers doing
stupid things, hence why I'm happy with this point fix being the lesser
of two evils in terms of not holding up this mostly-orthogonal series.
Robin.
>
> -Frank
>
^ permalink raw reply
* Re: [PATCH V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets
From: Kishon Vijay Abraham I @ 2017-04-06 10:11 UTC (permalink / raw)
To: Vivek Gautam, robh+dt
Cc: mark.rutland, devicetree, linux-arm-msm, linux-usb, sboyd,
linux-kernel, bjorn.andersson, srinivas.kandagatla,
linux-arm-kernel
In-Reply-To: <1491457885-5254-1-git-send-email-vivek.gautam@codeaurora.org>
On Thursday 06 April 2017 11:21 AM, Vivek Gautam wrote:
> Hi Kishon,
> Here's the series with fixed checkpatch warnings/checks.
> Please pick it for phy/next.
>
> This patch series adds couple of PHY drivers for Qualcomm chipsets.
> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
> b) qcom-qmp phy driver: that is a combo phy providing support for
> USB3, PCIe, UFS and few other controllers.
>
> The patches are based on next branch of linux-phy tree.
>
> These patches have been tested on Dragon board db820c hardware with
> required set of dt patches.
> The tested branch[3] is based on torvald's master with greg's usb/usb-next
> merged. Additionally the patches to get rpm up on msm8996 are also pulled
> in.
merged, thanks!
-Kishon
>
> Changes since v7:
> - Fixed 'checkpatch --strict' alignment warnings/checks, and
> added Stephen's Reviewed-by tag.
>
> Changes since v6:
> - Rebased on phy/next and *not* including phy grouping series[4].
> - qusb2-phy: addressed Stephen's comment.
> - Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
> - qmp-phy: none on functionality side.
>
> Changes since v5:
> - Addressed review comments from Bjorn:
> - Removed instances of readl/wirtel_relaxed calls from the drivers.
> Instead, using simple readl/writel. Inserting a readl after a writel
> to ensure the write is through to the device.
> - Replaced regulator handling with regulator_bulk_** apis. This helps
> in cutting down a lot of regulator handling code.
> - Fixed minor return statements.
>
> Changes since v4:
> - Addressed comment to add child nodes for qmp phy driver. Each phy lane
> now has a separate child node under the main qmp node.
> - Modified the clock and reset initialization and enable methods.
> Different phys - pcie, usb and later ufs, have varying number of clocks
> and resets that are mandatory. So adding provision for clocks and reset
> lists helps in requesting all mandatory resources for individual phys
> and handle their failure cases accordingly.
>
> Changes since v3:
> - Addressed review comments given by Rob and Stephen for qusb2 phy
> and qmp phy bindings respectively.
> - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
>
> Changes since v2:
> - Addressed review comments given by Rob and Stephen for bindings.
> - Addressed the review comments given by Stephen for the qusb2 and qmp
> phy drivers.
>
> Changes since v1:
> - Moved device tree binding documentation to separate patches, as suggested
> by Rob.
> - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
> given by Rob.
> - Addressed review comments from Kishon.
> - Addressed review comments from Srinivas for QMP phy driver.
> - Addressed kbuild warning.
>
> Please see individual patches for detailed changelogs.
>
> [1] https://patchwork.kernel.org/patch/9567767/
> [2] https://patchwork.kernel.org/patch/9567779/
> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
> [4] https://lkml.org/lkml/2017/3/20/407
>
> Vivek Gautam (4):
> dt-bindings: phy: Add support for QUSB2 phy
> phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
> dt-bindings: phy: Add support for QMP phy
> phy: qcom-qmp: new qmp phy driver for qcom-chipsets
>
> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 ++
> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 +
> drivers/phy/Kconfig | 18 +
> drivers/phy/Makefile | 2 +
> drivers/phy/phy-qcom-qmp.c | 1153 ++++++++++++++++++++
> drivers/phy/phy-qcom-qusb2.c | 493 +++++++++
> 6 files changed, 1815 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
> create mode 100644 drivers/phy/phy-qcom-qmp.c
> create mode 100644 drivers/phy/phy-qcom-qusb2.c
>
^ permalink raw reply
* Re: [PATCH V10 03/12] of: dma: Move range size workaround to of_dma_get_range()
From: Robin Murphy @ 2017-04-06 10:03 UTC (permalink / raw)
To: Frank Rowand, Sricharan R, will.deacon-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, tn-nYOzD4b6Jr9Wk0Htik3J/w,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A, okaya-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sudeep.holla-5wv7dgnIgG8,
rjw-LthD3rsA81gm4RdzfppkhA, lenb-DgEjT+Ai2ygdnm+yROfE0A,
catalin.marinas-5wv7dgnIgG8, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
In-Reply-To: <58E5DF13.2020700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Frank,
On 06/04/17 07:24, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>>
>> Invalid dma-ranges values should be worked around when retrieving the
>> DMA range in of_dma_get_range(), not by all callers of the function.
>> This isn't much of a problem now that we have a single caller, but that
>> situation will change when moving DMA configuration to device probe
>> time.
>
> Please drop this patch from the series. I just now sent Rob an
> alternative that reflects other changes that have occurred since
> this patch series was first created many, many moons ago
> (https://lkml.org/lkml/2017/4/6/53).
Fine by me too - if we can get rid of that dubious fixup altogether, all
the better. Feel free to transfer my Reviewed-by to your patch if you like.
Thanks,
Robin.
> Thanks,
>
> Frank
>
>>
>> Tested-by: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>> ---
>> drivers/of/address.c | 20 ++++++++++++++++++--
>> drivers/of/device.c | 15 ---------------
>> 2 files changed, 18 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903..6aeb816 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -819,8 +819,8 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
>> * CPU addr (phys_addr_t) : pna cells
>> * size : nsize cells
>> *
>> - * It returns -ENODEV if "dma-ranges" property was not found
>> - * for this device in DT.
>> + * Return 0 on success, -ENODEV if the "dma-ranges" property was not found for
>> + * this device in DT, or -EINVAL if the CPU address or size is invalid.
>> */
>> int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
>> {
>> @@ -880,6 +880,22 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
>> *dma_addr = dmaaddr;
>>
>> *size = of_read_number(ranges + naddr + pna, nsize);
>> + /*
>> + * DT nodes sometimes incorrectly set the size as a mask. Work around
>> + * those incorrect DT by computing the size as mask + 1.
>> + */
>> + if (*size & 1) {
>> + pr_warn("%s: size 0x%llx for dma-range in node(%s) set as mask\n",
>> + __func__, *size, np->full_name);
>> + *size = *size + 1;
>> + }
>> +
>> + if (!*size) {
>> + pr_err("%s: invalid size zero for dma-range in node(%s)\n",
>> + __func__, np->full_name);
>> + ret = -EINVAL;
>> + goto out;
>> + }
>>
>> pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
>> *dma_addr, *paddr, *size);
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index b1e6beb..09dedd0 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -110,21 +110,6 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> size = dev->coherent_dma_mask + 1;
>> } else {
>> offset = PFN_DOWN(paddr - dma_addr);
>> -
>> - /*
>> - * Add a work around to treat the size as mask + 1 in case
>> - * it is defined in DT as a mask.
>> - */
>> - if (size & 1) {
>> - dev_warn(dev, "Invalid size 0x%llx for dma-range\n",
>> - size);
>> - size = size + 1;
>> - }
>> -
>> - if (!size) {
>> - dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
>> - return;
>> - }
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>> }
>>
>>
^ permalink raw reply
* Re: [PATCH V5 2/4] dt-bindings: arm: Add bindings for SP9860G
From: Chunyan Zhang @ 2017-04-06 10:00 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
Catalin Marinas, Will Deacon, Arnd Bergmann, Mathieu Poirier,
Orson Zhai (翟京),
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Chunyan Zhang
In-Reply-To: <1490594802-27073-3-git-send-email-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
Hello Greg,
I guess there will be no further comments on this patchset :), could
you please take the patches 2/3/4 through tty git?
Thanks,
Chunyan
On 27 March 2017 at 14:06, Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org> wrote:
> Added bindings for Spreadtrum SP9860G board and SC9860 SoC.
> This patch also revised bindings of SC9836 to make the format
> more clear.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/sprd.txt | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/sprd.txt b/Documentation/devicetree/bindings/arm/sprd.txt
> index 31a629d..3df034b 100644
> --- a/Documentation/devicetree/bindings/arm/sprd.txt
> +++ b/Documentation/devicetree/bindings/arm/sprd.txt
> @@ -1,11 +1,14 @@
> Spreadtrum SoC Platforms Device Tree Bindings
> ----------------------------------------------------
>
> -Sharkl64 is a Spreadtrum's SoC Platform which is based
> -on ARM 64-bit processor.
> +SC9836 openphone Board
> +Required root node properties:
> + - compatible = "sprd,sc9836-openphone", "sprd,sc9836";
>
> -SC9836 openphone board with SC9836 SoC based on the
> -Sharkl64 Platform shall have the following properties.
> +SC9860 SoC
> +Required root node properties:
> + - compatible = "sprd,sc9860"
>
> +SP9860G 3GFHD Board
> Required root node properties:
> - - compatible = "sprd,sc9836-openphone", "sprd,sc9836";
> + - compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
> --
> 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: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1
From: Philipp Zabel @ 2017-04-06 9:57 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Russell King - ARM Linux, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
Steve Longerbeam, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, nick-gcszYUEDH4VrovVCs/uTlw,
markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
shuah-DgEjT+Ai2ygdnm+yROfE0A, sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
pavel-+ZI9xUNit7I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170405115336.7135e542-ch4gOOMV7nf/PtFMR13I2A@public.gmane.org>
On Wed, 2017-04-05 at 11:53 -0300, Mauro Carvalho Chehab wrote:
[...]
> There are a number of drivers that can work with different
> types of TV demodulators. Typical examples of such hardware can be
> found at em28xx, saa7134, cx88 drivers (among lots of other drivers).
> Those drivers don't use the subdev API. Instead, they use a generic
> helper function with sets the pipelines, based on the pad number.
>
> The problem here is that, currently, both MC API and MC core
> lacks a way to identify PAD ports per type, as the only information
> that a bridge driver has is a pad number. So, in order for a
> generic helper function to work, we had to hardcode pad numbers,
> in a way that it would work for all possible types of demods.
>
> It shouldn't be hard to add a "pad_type" information at media_pad
> struct, but passing such info to userspace requires a new API
> (we're calling it as "properties API"). Sakari was meant to send
> us an updated RFC for it[1] with a patchset, back in 2015, but
> this never happened.
>
> [1] https://linuxtv.org/news.php?entry=2015-08-17.mchehab
[...]
That would be most useful.
> So, in short, the tvp5150 demod doesn't decode audio, but there
> are other demods that do it.
>
> In the case of VBI, tvp5150 has actually two ways of reporting
> it:
>
> 1) via YOUT[7:0] pins. VBI information is transmitted as a
> set of raw samples, via an ancillary data block, during
> vertical/horizontal blanking intervals. So, yes, it shares
> the same hardware output, although the VBI contents are
> actually multiplexed there. Please notice that not all
> video out PADS encapsulate raw VBI the same way as tvp5150
> (and some devices even don't support raw VBI, like saa7110 and
> some models supported by saa7115 driver).
This is the physical interface that corresponds to the output port
(should be port@1) in the device tree. It should correspond to the video
output media entity pad.
What is unclear to is me whether the VBI media entity pad also should
correspond to the same physical interface / DT port.
> 2) via an interrupt that indicates that it decoded VBI data. The
> VBI information itself is there on FIFO, accessible via a set of
> registers (see "VBI Data processor" chapter at the datasheet).
>
> Currently, the driver doesn't support (2), because, at the time
> I wrote the driver, I didn't find a way to read the interrupts generated
> by tvp5150 at em28xx[1], due to the lack of em28xx documentation,
> but adding support for it shoudn't be hard. I may eventually do it
> when I have some time to play with my ISEE hardware.
>
> So, in the case of tvp5150 hardware, have those PADS:
>
> - Input baseband;
> - Video + raw VBI output;
> - sliced VBI output.
This DEMOD_PAD_VBI_OUT, does it correspond to 1) or 2) above?
> Yet, we need an always unconnected audio output, in order to support
> different demods out there.
Are you saying we have to keep pad[DEMOD_PAD_AUDIO_OUT] in tvp5150 even
though it doesn't exist because the framework can't cope with an
audio-less ATV_DECODER that only has three pads?
> [1] tvp5150 was written to support some em28xx-based devices
>
> >
> > > So, it has one input and three outputs. How does marking the direction
> > > in the port node (which would indicate that there was a data flow out of
> > > TVP5150 into the iMX6 capture) help identify which of those pads should
> > > be used?
> > >
> > > It would eliminate the input pad, but you still have three output pads
> > > to choose from.
> > >
> > > So no, your idea can't work.
> >
> > In this case, removal of the VBI and audio pads might make this work,
> > but in general this is true. In my opinion, to make this truly generic,
> > we need an interface to ask the driver which media entity pad a given
> > device tree port corresponds to, as there might not even be a single
> > media entity corresponding to all ports for more complex devices.
>
> Yes. We also need something like that at the userspace API.
thanks
Philipp
--
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 0/4] arm64: renesas: enable M3ULCB board peripherals
From: Geert Uytterhoeven @ 2017-04-06 9:53 UTC (permalink / raw)
To: Simon Horman
Cc: Vladimir Barinov, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
Sjoerd Simons
In-Reply-To: <1489788135.8957.2.camel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Hi Simon,
On Fri, Mar 17, 2017 at 11:02 PM, Sjoerd Simons
<sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> On Thu, 2017-01-26 at 17:53 +0300, Vladimir Barinov wrote:
>> This adds the folowing:
>> - R8A7796 SoC based M3ULCB board peripherals
>>
>> Vladimir Barinov (4):
>> [1/4] arm64: dts: m3ulcb: enable I2C
>> [2/4] arm64: dts: m3ulcb: Update memory node to 2 GiB map
>> [3/4] arm64: dts: m3ulcb: enable EthernetAVB
>> [4/4] arm64: dts: m3ulcb: enable HS200 for eMMC
>
> Seems these didn't hit -next just yet, for this series (tested on a
> M3ULCB)
>
> Tested-By: Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
It seems this series is still pending? Any reason (not) to apply it?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 19/39] media: Add i.MX media core driver
From: Philipp Zabel @ 2017-04-06 9:43 UTC (permalink / raw)
To: Steve Longerbeam
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
nick-gcszYUEDH4VrovVCs/uTlw, markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
shuah-DgEjT+Ai2ygdnm+yROfE0A, sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
pavel-+ZI9xUNit7I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490661656-10318-20-git-send-email-steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On Mon, 2017-03-27 at 17:40 -0700, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
[...]
> diff --git a/drivers/staging/media/imx/imx-media-of.c b/drivers/staging/media/imx/imx-media-of.c
> new file mode 100644
> index 0000000..b383be4
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-of.c
> @@ -0,0 +1,267 @@
[...]
> +/*
> + * find the remote device node and remote port id (remote pad #)
> + * given local endpoint node
> + */
> +static void of_get_remote_pad(struct device_node *epnode,
> + struct device_node **remote_node,
> + int *remote_pad)
> +{
> + struct device_node *rp, *rpp;
> + struct device_node *remote;
> +
> + rp = of_graph_get_remote_port(epnode);
> + rpp = of_graph_get_remote_port_parent(epnode);
> +
> + if (of_device_is_compatible(rpp, "fsl,imx6q-ipu")) {
> + /* the remote is one of the CSI ports */
> + remote = rp;
> + *remote_pad = 0;
> + of_node_put(rpp);
> + } else {
> + remote = rpp;
> + of_property_read_u32(rp, "reg", remote_pad);
If this fails because there is no reg property, *remote_pad will keep
the previous value. It should be set to 0 in this case.
----------8<----------
--- a/drivers/staging/media/imx/imx-media-of.c
+++ b/drivers/staging/media/imx/imx-media-of.c
@@ -85,7 +85,9 @@ static void of_get_remote_pad(struct device_node *epnode,
of_node_put(rpp);
} else {
remote = rpp;
- of_property_read_u32(rp, "reg", remote_pad);
+ /* FIXME port number and pad index are not the same */
+ if (of_property_read_u32(rp, "reg", remote_pad))
+ *remote_pad = 0;
of_node_put(rp);
}
---------->8----------
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver
From: Gabriel Fernandez @ 2017-04-06 9:35 UTC (permalink / raw)
To: Stephen Boyd
Cc: Mark Rutland, devicetree, daniel.thompson, radoslaw.pietrzyk,
Alexandre Torgue, Arnd Bergmann, Nicolas Pitre, andrea.merello,
Michael Turquette, olivier.bideau, Russell King, linux-kernel,
Rob Herring, ludovic.barre, Maxime Coquelin, amelie.delaunay,
Lee Jones, linux-clk, linux-arm-kernel
In-Reply-To: <20170405223233.GJ7065@codeaurora.org>
Hi Stephen,
On 04/06/2017 12:32 AM, Stephen Boyd wrote:
> On 03/15, gabriel.fernandez@st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch enables clocks for STM32H743 boards.
> Like what clocks exactly? All of them?
>
Yes all of them, it's new IP
>> diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>> new file mode 100644
>> index 0000000..9d4b587
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>> @@ -0,0 +1,152 @@
>> +STMicroelectronics STM32H7 Reset and Clock Controller
>> +=====================================================
>> +
>> +The RCC IP is both a reset and a clock controller.
>> +
>> +Please refer to clock-bindings.txt for common clock controller binding usage.
>> +Please also refer to reset.txt for common reset controller binding usage.
>> +
>> +Required properties:
>> +- compatible: Should be:
>> + "st,stm32h743-rcc"
>> +
>> +- reg: should be register base and length as documented in the
>> + datasheet
>> +
>> +- #reset-cells: 1, see below
>> +
>> +- #clock-cells : from common clock binding; shall be set to 1
>> +
>> +- clocks: External oscillator clock phandle
>> + - high speed external clock signal (HSE)
>> + - low speed external clock signal (LSE)
>> + - external I2S clock (I2S_CKIN)
>> +
>> +- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
>> + write protection (RTC clock).
>> +
>> +- pll x node: Allow to register a pll with specific parameters.
>> + Please see PLL section below.
>> +
>> +Example:
>> +
>> + rcc: rcc@58024400 {
>> + #reset-cells = <1>;
>> + #clock-cells = <2>
>> + compatible = "st,stm32h743-rcc", "st,stm32-rcc";
>> + reg = <0x58024400 0x400>;
>> + clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
>> +
>> + st,syscfg = <&pwrcfg>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + vco1@58024430 {
>> + #clock-cells = <0>;
>> + compatible = "stm32,pll";
>> + reg = <0>;
> reg is super confusing and doesn't match unit address.
ok i fixed it in the v2
>
>> + };
> Why? Shouldn't we know this from the compatible string how many
> PLLs there are and where they're located? Export the PLLs through
> rcc node's clock-cells?
>
Because i need to offer the possibility to change the PLL VCO
frequencies at the start-up of this driver clock.
The VCO algorithm needs a division factor, a multiplication factor and a
fractional factor.
Lot's of solution are possible for one frequency and it's nightmare to
satisfy the 3 output dividers of the PLL.
>> +
>> + vco2@58024438 {
>> + #clock-cells = <0>;
>> + compatible = "stm32,pll";
>> + reg = <1>;
> reg is super confusing and doesn't match unit address.
>
>> + st,clock-div = <2>;
>> + st,clock-mult = <40>;
>> + st,frac-status = <0>;
>> + st,frac = <0>;
>> + st,vcosel = <1>;
>> + st,pllrge = <2>;
> Does this stuff change on a per-board basis? I hope none of these
> properties need to be in DT.
These properties are optionals.
I absolute need it to custumize VCO frequencies of a pll without the
boot loader..
i suppressed "st,frac-status" and "st,pllrge" in the v2
>
>> + };
>> + };
>> +
>> +
>> +STM32H7 PLL
>> +-----------
>> +
> [...]
>> +
>> +Specifying softreset control of devices
>> +=======================================
>> +
>> +Device nodes should specify the reset channel required in their "resets"
>> +property, containing a phandle to the reset device node and an index specifying
>> +which channel to use.
>> +The index is the bit number within the RCC registers bank, starting from RCC
>> +base address.
>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>> +Where bit_offset is the bit offset within the register.
>> +
>> +For example, for CRC reset:
>> + crc = AHB4RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x88 / 4 * 32 + 19 = 1107
>> +
>> +All available preprocessor macros for reset are defined dt-bindings//mfd/stm32h7-rcc.h
> One too many slashes?
ok i will fix it
>
>> +header and can be used in device tree sources.
>> +
>> +example:
>> +
>> + timer2 {
>> + resets = <&rcc STM32H7_APB1L_RESET(TIM2)>;
>> + };
>> diff --git a/drivers/clk/clk-stm32h7.c b/drivers/clk/clk-stm32h7.c
>> new file mode 100644
>> index 0000000..c8eb729
>> --- /dev/null
>> +++ b/drivers/clk/clk-stm32h7.c
>> @@ -0,0 +1,1586 @@
>> +/*
>> + * Copyright (C) Gabriel Fernandez 2017
>> + * Author: Gabriel Fernandez <gabriel.fernandez@st.com>
>> + *
>> + * License terms: GPL V2.0.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope 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.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/clk.h>
> Is this used?
No i will suppress it
>
>> +#include <linux/clk-provider.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/regmap.h>
>> +
>> +#include <dt-bindings/clock/stm32h7-clks.h>
>> +
>> +/* Reset Clock Control Registers */
>> +#define RCC_CR 0x00
>> +#define RCC_CFGR 0x10
>> +#define RCC_D1CFGR 0x18
>> +#define RCC_D2CFGR 0x1C
>> +#define RCC_D3CFGR 0x20
>> +#define RCC_PLLCKSELR 0x28
>> +#define RCC_PLLCFGR 0x2C
>> +#define RCC_PLL1DIVR 0x30
>> +#define RCC_PLL1FRACR 0x34
>> +#define RCC_PLL2DIVR 0x38
>> +#define RCC_PLL2FRACR 0x3C
>> +#define RCC_PLL3DIVR 0x40
>> +#define RCC_PLL3FRACR 0x44
>> +#define RCC_D1CCIPR 0x4C
>> +#define RCC_D2CCIP1R 0x50
>> +#define RCC_D2CCIP2R 0x54
>> +#define RCC_D3CCIPR 0x58
>> +#define RCC_BDCR 0x70
>> +#define RCC_CSR 0x74
>> +#define RCC_AHB3ENR 0xD4
>> +#define RCC_AHB1ENR 0xD8
>> +#define RCC_AHB2ENR 0xDC
>> +#define RCC_AHB4ENR 0xE0
>> +#define RCC_APB3ENR 0xE4
>> +#define RCC_APB1LENR 0xE8
>> +#define RCC_APB1HENR 0xEC
>> +#define RCC_APB2ENR 0xF0
>> +#define RCC_APB4ENR 0xF4
>> +
>> +static DEFINE_SPINLOCK(rlock);
> This is super generic and will make lockdep debugging sad.
> Perhaps stm32rcc_lock?
ok
>
>> +
>> +static void __iomem *base;
>> +static struct regmap *pdrm;
>> +static struct clk_hw **hws;
>> +
>> +/* System clock parent */
>> +static const char * const sys_src[] = {
>> + "hsi_ck", "csi_ck", "hse_ck", "pll1_p" };
>> +
>> +static const char * const tracein_src[] = {
>> + "hsi_ck", "csi_ck", "hse_ck", "pll1_r" };
> [...]
>> +
>> +static unsigned long pll_fd_recalc_rate(struct clk_hw *hw,
>> + unsigned long parent_rate)
>> +{
>> + struct stm32_pll_obj *clk_elem = to_pll(hw);
>> + struct stm32_fractional_divider *fd = &clk_elem->div;
>> + unsigned long m, n;
>> + u32 val, mask;
>> + u64 rate, rate1 = 0;
>> +
>> + val = clk_readl(fd->mreg);
> Please don't use clk_readl() unless you need it for some reason.
ok
>
>> + mask = (GENMASK(fd->mwidth - 1, 0) << fd->mshift);
>> + m = (val & mask) >> fd->mshift;
>> +
>> + val = clk_readl(fd->nreg);
>> + mask = (GENMASK(fd->nwidth - 1, 0) << fd->nshift);
> Useless parentheses. And isn't GENMASK supposed to take the
> actual bit positions? Then we avoid overflow issues?
ok il will fix it.
>> + n = ((val & mask) >> fd->nshift) + 1;
>> +
>> + if (!n || !m)
>> + return parent_rate;
>> +
>> + rate = (u64)parent_rate * n;
>> + do_div(rate, m);
>> +
>> + if (pll_frac_is_enabled(hw)) {
>> + val = pll_read_frac(hw);
>> + rate1 = (u64) parent_rate * (u64) val;
>> + do_div(rate1, (m * 8191));
>> + }
>> +
>> + return rate + rate1;
>> +}
>> +
> [...]
>> +
>> + /* Micro-controller clocks */
>> + for (n = 0; n < ARRAY_SIZE(mco_clk); n++) {
>> + get_cfg_composite_div(&mco_clk_cfg, &mco_clk[n], &c_cfg,
>> + &rlock);
>> +
>> + hws[MCO_BANK + n] = clk_hw_register_composite(NULL,
>> + mco_clk[n].name,
>> + mco_clk[n].parent_name,
>> + mco_clk[n].num_parents,
>> + c_cfg.mux_hw, c_cfg.mux_ops,
>> + c_cfg.div_hw, c_cfg.div_ops,
>> + c_cfg.gate_hw, c_cfg.gate_ops,
>> + mco_clk[n].flags);
>> + }
>> +
>> + of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_data);
>> +
>> + return;
>> +
>> +err_free_clks:
>> + kfree(clk_data);
>> +}
>> +CLK_OF_DECLARE_DRIVER(stm32h7_rcc, "st,stm32h743-rcc", stm32h7_rcc_init);
> Is there another driver that uses the same register space?
> Nothing showing up in -next right now. Perhaps a comment should
> be added to indicate the other driver.
Yes the reset controler.
ok il will add a comment.
BR
Gabriel
^ 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