* Re: [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor
From: Stefan Wahren @ 2018-05-22 19:31 UTC (permalink / raw)
To: Rob Herring, Guenter Roeck, Eric Anholt, Mark Rutland,
Jonathan Corbet, Jean Delvare
Cc: linux-hwmon, devicetree, Florian Fainelli, Scott Branden,
linux-doc, Ray Jui, Phil Elwell, Noralf Trønnes,
bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel
In-Reply-To: <bea3d6c7-a713-c4aa-8ae8-7fec80c5da5d@roeck-us.net>
> Guenter Roeck <linux@roeck-us.net> hat am 22. Mai 2018 um 16:10 geschrieben:
>
>
> On 05/22/2018 06:51 AM, Stefan Wahren wrote:
> > Hi Guenter,
> >
> >> Guenter Roeck <linux@roeck-us.net> hat am 22. Mai 2018 um 15:41 geschrieben:
> >>
> >>
> >> On 05/22/2018 04:21 AM, Stefan Wahren wrote:
> >>> Currently there is no easy way to detect undervoltage conditions on a
> >>> remote Raspberry Pi. This hwmon driver retrieves the state of the
> >>> undervoltage sensor via mailbox interface. The handling based on
> >>> Noralf's modifications to the downstream firmware driver. In case of
> >>> an undervoltage condition only an entry is written to the kernel log.
> >>>
> >>> CC: "Noralf Trønnes" <noralf@tronnes.org>
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> Documentation/hwmon/raspberrypi-hwmon | 22 +++++
> >>> drivers/hwmon/Kconfig | 10 ++
> >>> drivers/hwmon/Makefile | 1 +
> >>> drivers/hwmon/raspberrypi-hwmon.c | 168 ++++++++++++++++++++++++++++++++++
> >>> 4 files changed, 201 insertions(+)
> >>> create mode 100644 Documentation/hwmon/raspberrypi-hwmon
> >>> create mode 100644 drivers/hwmon/raspberrypi-hwmon.c
> >>>
> >>> diff --git a/Documentation/hwmon/raspberrypi-hwmon b/Documentation/hwmon/raspberrypi-hwmon
> >>> new file mode 100644
> >>> index 0000000..3c92e2c
> >>> --- /dev/null
> >>> +++ b/Documentation/hwmon/raspberrypi-hwmon
> >>> @@ -0,0 +1,22 @@
> >>> +Kernel driver raspberrypi-hwmon
> >>> +===============================
> >>> +
> >>> +Supported boards:
> >>> + * Raspberry Pi A+ (via GPIO on SoC)
> >>> + * Raspberry Pi B+ (via GPIO on SoC)
> >>> + * Raspberry Pi 2 B (via GPIO on SoC)
> >>> + * Raspberry Pi 3 B (via GPIO on port expander)
> >>> + * Raspberry Pi 3 B+ (via PMIC)
> >>> +
> >>> +Author: Stefan Wahren <stefan.wahren@i2se.com>
> >>> +
> >>> +Description
> >>> +-----------
> >>> +
> >>> +This driver periodically polls a mailbox property of the VC4 firmware to detect
> >>> +undervoltage conditions.
> >>> +
> >>> +Sysfs entries
> >>> +-------------
> >>> +
> >>> +in0_lcrit_alarm Undervoltage alarm
> >>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> >>> index 768aed5..9a5bdb0 100644
> >>> --- a/drivers/hwmon/Kconfig
> >>> +++ b/drivers/hwmon/Kconfig
> >>> @@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
> >>> This driver can also be built as a module. If so, the module
> >>> will be called pwm-fan.
> >>>
> >>> +config SENSORS_RASPBERRYPI_HWMON
> >>> + tristate "Raspberry Pi voltage monitor"
> >>> + depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
> >>> + help
> >>> + If you say yes here you get support for voltage sensor on the
> >>> + Raspberry Pi.
> >>> +
> >>> + This driver can also be built as a module. If so, the module
> >>> + will be called raspberrypi-hwmon.
> >>> +
> >>> config SENSORS_SHT15
> >>> tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
> >>> depends on GPIOLIB || COMPILE_TEST
> >>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> >>> index e7d52a3..a929770 100644
> >>> --- a/drivers/hwmon/Makefile
> >>> +++ b/drivers/hwmon/Makefile
> >>> @@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> >>> obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> >>> obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
> >>> obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
> >>> +obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON) += raspberrypi-hwmon.o
> >>> obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
> >>> obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
> >>> obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
> >>> diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
> >>> new file mode 100644
> >>> index 0000000..6233e84
> >>> --- /dev/null
> >>> +++ b/drivers/hwmon/raspberrypi-hwmon.c
> >>> @@ -0,0 +1,168 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +/*
> >>> + * Raspberry Pi voltage sensor driver
> >>> + *
> >>> + * Based on firmware/raspberrypi.c by Noralf Trønnes
> >>> + *
> >>> + * Copyright (C) 2018 Stefan Wahren <stefan.wahren@i2se.com>
> >>> + */
> >>> +#include <linux/device.h>
> >>> +#include <linux/err.h>
> >>> +#include <linux/hwmon.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/platform_device.h>
> >>> +#include <linux/slab.h>
> >>> +#include <linux/workqueue.h>
> >>> +#include <soc/bcm2835/raspberrypi-firmware.h>
> >>> +
> >>> +#define UNDERVOLTAGE_STICKY_BIT BIT(16)
> >>> +
> >>> +struct rpi_hwmon_data {
> >>> + struct device *hwmon_dev;
> >>> + struct rpi_firmware *fw;
> >>> + u32 last_throttled;
> >>> + struct delayed_work get_values_poll_work;
> >>> +};
> >>> +
> >>> +static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
> >>> +{
> >>> + u32 new_uv, old_uv, value;
> >>> + int ret;
> >>> +
> >>> + /* Request firmware to clear sticky bits */
> >>> + value = 0xffff;
> >>> +
> >>> + ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
> >>> + &value, sizeof(value));
> >>> + if (ret) {
> >>> + dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
> >>> + ret);
> >>> + return;
> >>> + }
> >>> +
> >>> + new_uv = value & UNDERVOLTAGE_STICKY_BIT;
> >>> + old_uv = data->last_throttled & UNDERVOLTAGE_STICKY_BIT;
> >>> + data->last_throttled = value;
> >>> +
> >>> + if (new_uv == old_uv)
> >>> + return;
> >>> +
> >>> + if (new_uv)
> >>> + dev_crit(data->hwmon_dev, "Undervoltage detected!\n");
> >>> + else
> >>> + dev_info(data->hwmon_dev, "Voltage normalised\n");
> >>> +
> >>> + sysfs_notify(&data->hwmon_dev->kobj, NULL, "in0_lcrit_alarm");
> >>> +}
> >>> +
> >>> +static void get_values_poll(struct work_struct *work)
> >>> +{
> >>> + struct rpi_hwmon_data *data;
> >>> +
> >>> + data = container_of(work, struct rpi_hwmon_data,
> >>> + get_values_poll_work.work);
> >>> +
> >>> + rpi_firmware_get_throttled(data);
> >>> +
> >>> + /*
> >>> + * We can't run faster than the sticky shift (100ms) since we get
> >>> + * flipping in the sticky bits that are cleared.
> >>> + */
> >>> + schedule_delayed_work(&data->get_values_poll_work, 2 * HZ);
> >>> +}
> >>> +
> >>> +static int rpi_read(struct device *dev, enum hwmon_sensor_types type,
> >>> + u32 attr, int channel, long *val)
> >>> +{
> >>> + struct rpi_hwmon_data *data = dev_get_drvdata(dev);
> >>> +
> >>> + *val = !!(data->last_throttled & UNDERVOLTAGE_STICKY_BIT);
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static umode_t rpi_is_visible(const void *_data, enum hwmon_sensor_types type,
> >>> + u32 attr, int channel)
> >>> +{
> >>> + return 0444;
> >>> +}
> >>> +
> >>> +static const u32 rpi_in_config[] = {
> >>> + HWMON_I_LCRIT_ALARM,
> >>> + 0
> >>> +};
> >>> +
> >>> +static const struct hwmon_channel_info rpi_in = {
> >>> + .type = hwmon_in,
> >>> + .config = rpi_in_config,
> >>> +};
> >>> +
> >>> +static const struct hwmon_channel_info *rpi_info[] = {
> >>> + &rpi_in,
> >>> + NULL
> >>> +};
> >>> +
> >>> +static const struct hwmon_ops rpi_hwmon_ops = {
> >>> + .is_visible = rpi_is_visible,
> >>> + .read = rpi_read,
> >>> +};
> >>> +
> >>> +static const struct hwmon_chip_info rpi_chip_info = {
> >>> + .ops = &rpi_hwmon_ops,
> >>> + .info = rpi_info,
> >>> +};
> >>> +
> >>> +static int rpi_hwmon_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct device *dev = &pdev->dev;
> >>> + struct rpi_hwmon_data *data;
> >>> + int ret;
> >>> +
> >>> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> >>> + if (!data)
> >>> + return -ENOMEM;
> >>> +
> >>> + data->fw = platform_get_drvdata(to_platform_device(dev->parent));
> >>> + if (!data->fw)
> >>> + return -EPROBE_DEFER;
> >>> +
> >>
> >> I am a bit at loss here (and sorry I didn't bring this up before).
> >> How would this ever be possible, given that the driver is registered
> >> from the firmware driver ?
> >
> > Do you refer to the (wrong) return code, the assumption that the parent must be a platform driver or a possible race?
> >
>
> The return code is one thing. My question was how the driver would ever be instantiated
> with platform_get_drvdata(to_platform_device(dev->parent)) == NULL (but dev->parent != NULL),
> so I referred to the race. But, sure, a second question would be how that would indicate
> that the parent is not instantiated yet (which by itself seems like an odd question).
This shouldn't happen and worth a log error. In patch #3 the registration is called after the complete private data of the firmware driver is initialized. Did i missed something?
But i must confess that i didn't test all builtin/module combinations.
>
> Yet another question, as you point out, is why to use platform_get_drvdata(to_platform_device(dev->parent))
> instead of dev_get_drvdata(dev->parent).
Sure this is much simpler
Thanks
Stefan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4 05/11] ARM: dts: aspeed: peci: Add PECI node
From: kbuild test robot @ 2018-05-22 19:28 UTC (permalink / raw)
Cc: kbuild-all, Rob Herring, Mark Rutland, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Jae Hyun Yoo, Jason M Biils, Ryan Chen
In-Reply-To: <20180521195846.27894-1-jae.hyun.yoo@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
Hi Jae,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jae-Hyun-Yoo/dt-bindings-Add-a-document-of-PECI-subsystem/20180522-204411
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/aspeed-g5.dtsi:382.21-22 syntax error
FATAL ERROR: Unable to parse input tree
--
>> Error: arch/arm/boot/dts/aspeed-g4.dtsi:332.21-22 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 64516 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ARM: pxa: dts: add gpio-ranges to gpio controller
From: Robert Jarzmik @ 2018-05-22 19:19 UTC (permalink / raw)
To: Daniel Mack; +Cc: devicetree, robh+dt, linux-arm-kernel, haojian.zhuang
In-Reply-To: <20180521220044.821-1-daniel@zonque.org>
Daniel Mack <daniel@zonque.org> writes:
> The PXA GPIO driver calls out to the pinctrl driver for claiming pins
> unless the config has CONFIG_PINCTRL unset. IOW, if a pinctrl driver is
> active, it must be visible to the GPIO driver.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
Applied to pxa/dt, thanks.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] arm64: dts: stingray: move common board components to stingray-board-base
From: Scott Branden @ 2018-05-22 18:55 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
Florian Fainelli
Cc: BCM Kernel Feedback, devicetree, linux-arm-kernel, linux-kernel,
Scott Branden
Move common board components from base bcm958742 dtsi file to new
stingray-board-base dtsi file so they can be shared between many stingray
boards following common design.
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
.../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 35 +--------------
.../dts/broadcom/stingray/stingray-board-base.dtsi | 51 ++++++++++++++++++++++
2 files changed, 52 insertions(+), 34 deletions(-)
create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index cacc25e..d74f6df 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -30,20 +30,9 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#include "stingray.dtsi"
+#include "stingray-board-base.dtsi"
/ {
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- aliases {
- serial0 = &uart1;
- serial1 = &uart0;
- serial2 = &uart2;
- serial3 = &uart3;
- };
-
sdio0_vddo_ctrl_reg: sdio0_vddo_ctrl {
compatible = "regulator-gpio";
regulator-name = "sdio0_vddo_ctrl_reg";
@@ -67,23 +56,6 @@
};
};
-&memory { /* Default DRAM banks */
- reg = <0x00000000 0x80000000 0x0 0x80000000>, /* 2G @ 2G */
- <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
-};
-
-&mdio_mux_iproc {
- mdio@10 {
- gphy0: eth-phy@10 {
- reg = <0x10>;
- };
- };
-};
-
-&uart1 {
- status = "okay";
-};
-
&pwm {
status = "okay";
};
@@ -111,8 +83,6 @@
};
&enet {
- phy-mode = "rgmii-id";
- phy-handle = <&gphy0>;
status = "okay";
};
@@ -133,13 +103,10 @@
&sdio0 {
vqmmc-supply = <&sdio0_vddo_ctrl_reg>;
- non-removable;
- full-pwr-cycle;
status = "okay";
};
&sdio1 {
vqmmc-supply = <&sdio1_vddo_ctrl_reg>;
- full-pwr-cycle;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
new file mode 100644
index 0000000..82a2471
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ * Copyright(c) 2016-2018 Broadcom
+ */
+
+#include "stingray.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart0;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&memory { /* Default DRAM banks */
+ reg = <0x00000000 0x80000000 0x0 0x80000000>, /* 2G @ 2G */
+ <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
+};
+
+&enet {
+ phy-mode = "rgmii-id";
+ phy-handle = <&gphy0>;
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&sdio0 {
+ non-removable;
+ full-pwr-cycle;
+};
+
+&sdio1 {
+ full-pwr-cycle;
+};
+
+&mdio_mux_iproc {
+ mdio@10 {
+ gphy0: eth-phy@10 {
+ reg = <0x10>;
+ };
+ };
+};
--
2.5.0
^ permalink raw reply related
* [PATCH 5/5] arm64: defconfig: add CONFIG_ARM_SP805_WATCHDOG
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Frank Rowand, Catalin Marinas, Will Deacon
Cc: linux-watchdog, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
Enable the SP805 watchdog timer
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ecf6137..3fe5eb5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -351,6 +351,7 @@ CONFIG_ROCKCHIP_THERMAL=m
CONFIG_TEGRA_BPMP_THERMAL=m
CONFIG_UNIPHIER_THERMAL=y
CONFIG_WATCHDOG=y
+CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_S3C2410_WATCHDOG=y
CONFIG_MESON_GXBB_WATCHDOG=m
CONFIG_MESON_WATCHDOG=m
--
2.1.4
^ permalink raw reply related
* [PATCH 4/5] arm64: dt: set initial SR watchdog timeout to 60 seconds
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Frank Rowand, Catalin Marinas, Will Deacon
Cc: linux-watchdog, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
Set initial Stingray watchdog timeout to 60 seconds
By the time when the userspace watchdog daemon is ready and taking
control over, the watchdog timeout will then be reset to what's
configured in the daemon
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 99aaff0..1e1cf49 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -420,6 +420,7 @@
interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&hsls_25m_div2_clk>, <&hsls_div4_clk>;
clock-names = "wdogclk", "apb_pclk";
+ timeout-sec = <60>;
};
gpio_hsls: gpio@d0000 {
--
2.1.4
^ permalink raw reply related
* [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Frank Rowand, Catalin Marinas, Will Deacon
Cc: linux-watchdog, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
If the watchdog hardware is already enabled during the boot process,
when the Linux watchdog driver loads, it should reset the watchdog and
tell the watchdog framework. As a result, ping can be generated from
the watchdog framework, until the userspace watchdog daemon takes over
control
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 1484609..408ffbe 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -42,6 +42,7 @@
/* control register masks */
#define INT_ENABLE (1 << 0)
#define RESET_ENABLE (1 << 1)
+ #define ENABLE_MASK (INT_ENABLE | RESET_ENABLE)
#define WDTINTCLR 0x00C
#define WDTRIS 0x010
#define WDTMIS 0x014
@@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout,
"Set to 1 to keep watchdog running after device release");
+/* returns true if wdt is running; otherwise returns false */
+static bool wdt_is_running(struct watchdog_device *wdd)
+{
+ struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
+ ENABLE_MASK)
+ return true;
+ else
+ return false;
+}
+
/* This routine finds load value that will reset system in required timout */
static int wdt_setload(struct watchdog_device *wdd, unsigned int timeout)
{
@@ -239,6 +252,15 @@ sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id)
watchdog_init_timeout(&wdt->wdd, 0, &adev->dev);
wdt_setload(&wdt->wdd, wdt->wdd.timeout);
+ /*
+ * If HW is already running, enable/reset the wdt and set the running
+ * bit to tell the wdt subsystem
+ */
+ if (wdt_is_running(&wdt->wdd)) {
+ wdt_enable(&wdt->wdd);
+ set_bit(WDOG_HW_RUNNING, &wdt->wdd.status);
+ }
+
ret = watchdog_register_device(&wdt->wdd);
if (ret) {
dev_err(&adev->dev, "watchdog_register_device() failed: %d\n",
--
2.1.4
^ permalink raw reply related
* [PATCH 2/5] watchdog: sp805: add 'timeout-sec' DT property support
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Frank Rowand, Catalin Marinas, Will Deacon
Cc: linux-watchdog, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
Add support for optional devicetree property 'timeout-sec'.
'timeout-sec' is used in the driver if specified in devicetree.
Otherwise, fall back to driver default, i.e., 60 seconds
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
drivers/watchdog/sp805_wdt.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 03805bc..1484609 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -230,7 +230,14 @@ sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id)
spin_lock_init(&wdt->lock);
watchdog_set_nowayout(&wdt->wdd, nowayout);
watchdog_set_drvdata(&wdt->wdd, wdt);
- wdt_setload(&wdt->wdd, DEFAULT_TIMEOUT);
+
+ /*
+ * If 'timeout-sec' devicetree property is specified, use that.
+ * Otherwise, use DEFAULT_TIMEOUT
+ */
+ wdt->wdd.timeout = DEFAULT_TIMEOUT;
+ watchdog_init_timeout(&wdt->wdd, 0, &adev->dev);
+ wdt_setload(&wdt->wdd, wdt->wdd.timeout);
ret = watchdog_register_device(&wdt->wdd);
if (ret) {
--
2.1.4
^ permalink raw reply related
* [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Frank Rowand, Catalin Marinas, Will Deacon
Cc: linux-watchdog, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
Update the SP805 binding document to add optional 'timeout-sec'
devicetree property
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
index edc4f0e..f898a86 100644
--- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
@@ -19,6 +19,8 @@ Required properties:
Optional properties:
- interrupts : Should specify WDT interrupt number.
+- timeout-sec : Should specify default WDT timeout in seconds. If unset, the
+ default timeout is 30 seconds
Examples:
--
2.1.4
^ permalink raw reply related
* [PATCH 0/5] Enhance support for the SP805 WDT
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland,
Frank Rowand, Catalin Marinas, Will Deacon
Cc: linux-watchdog, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui
This patch series enhances the support for the SP805 watchdog timer.
First of all, 'timeout-sec' devicetree property is added. In addition,
support is also added to allow the driver to reset the watchdog if it
has been detected that watchdot has been started in the bootloader. In
this case, the driver will initiate the ping service from the kernel
watchdog subsystem, before a user mode daemon takes over. This series
also enables SP805 in the default ARM64 defconfig
This patch series is based off v4.17-rc5 and is available on GIHUB:
repo: https://github.com/Broadcom/arm64-linux.git
branch: sp805-wdt-v1
Ray Jui (5):
Documentation: DT: Add optional 'timeout-sec' property for sp805
watchdog: sp805: add 'timeout-sec' DT property support
watchdog: sp805: set WDOG_HW_RUNNING when appropriate
arm64: dt: set initial SR watchdog timeout to 60 seconds
arm64: defconfig: add CONFIG_ARM_SP805_WATCHDOG
.../devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
arch/arm64/configs/defconfig | 1 +
drivers/watchdog/sp805_wdt.c | 31 +++++++++++++++++++++-
4 files changed, 34 insertions(+), 1 deletion(-)
--
2.1.4
^ permalink raw reply
* Re: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file
From: Geert Uytterhoeven @ 2018-05-22 18:44 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Magnus Damm, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Geert Uytterhoeven,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk
In-Reply-To: <1526983321-41949-3-git-send-email-michel.pollet@bp.renesas.com>
Hi Michel,
On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> This adds the constants necessary to use the renesas,rzn1-clocks driver.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Thanks for your patch!
> ---
> include/dt-bindings/clock/rzn1-clocks.h | 187 ++++++++++++++++++++++++++++++++
> 1 file changed, 187 insertions(+)
> create mode 100644 include/dt-bindings/clock/rzn1-clocks.h
>
> diff --git a/include/dt-bindings/clock/rzn1-clocks.h b/include/dt-bindings/clock/rzn1-clocks.h
> new file mode 100644
> index 0000000..8a73db2
> --- /dev/null
> +++ b/include/dt-bindings/clock/rzn1-clocks.h
Given this is part of the DT ABI, and there exist multiple different RZ/N1
SoCs (and there are probably planned more), I wouldn't call this header
file "rzn1-clocks.h", but e.g. "r9a06g032-clocks.h".
> @@ -0,0 +1,187 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * RZ/N1 clock IDs
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> + * Derived from zx-reboot.c
> + */
> +
> +#ifndef __DT_BINDINGS_RZN1_CLOCK_H__
> +#define __DT_BINDINGS_RZN1_CLOCK_H__
> +
> +#define RZN1_CLKOUT 0
Similar for the RZN1 prefix.
I'll look at the actual list of clocks later...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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
^ permalink raw reply
* Re: [PATCH v6 3/6] dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver
From: Geert Uytterhoeven @ 2018-05-22 18:42 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Magnus Damm, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Geert Uytterhoeven,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk
In-Reply-To: <1526983321-41949-4-git-send-email-michel.pollet@bp.renesas.com>
Hi Michel,
On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
> to provide the SoC clock infrastructure for Linux.
>
> This documents the driver bindings.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> @@ -0,0 +1,44 @@
> +* Renesas RZ/N1 Clock Driver
> +
> +This driver provides the clock infrastructure used by all the other drivers.
> +
> +One of the 'special' feature of this infrastructure is that Linux doesn't
> +necessary 'own' all the clocks on the SoC, some other OS runs on
> +the Cortex-M3 core and that OS can access and claim it's own clocks.
> +
> +Required Properties:
> +
> + - compatible: Must be
> + - "renesas,r9a06g032-clocks" for the RZ/N1D
> + and "renesas,rzn1-clocks" as a fallback.
Why the fallback? I doubt all existing (and future) RZ/N1D SoCs provide the
exact same clock hierarchy.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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
^ permalink raw reply
* Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver
From: rishabhb @ 2018-05-22 18:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-arm Mailing List, linux-arm-msm, devicetree,
Linux Kernel Mailing List, linux-arm, tsoni, ckadabi, evgreen,
Rob Herring
In-Reply-To: <CAHp75VdO7+u-PQ+RBH71sxHHG0WkAyEVxv0BNPaycbcRnrZang@mail.gmail.com>
On 2018-05-18 14:01, Andy Shevchenko wrote:
> On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar
> <rishabhb@codeaurora.org> wrote:
>> LLCC (Last Level Cache Controller) provides additional cache memory
>> in the system. LLCC is partitioned into multiple slices and each
>> slice gets its own priority, size, ID and other config parameters.
>> LLCC driver programs these parameters for each slice. Clients that
>> are assigned to use LLCC need to get information such size & ID of the
>> slice they get and activate or deactivate the slice as needed. LLCC
>> driver
>> provides API for the clients to perform these operations.
>
>> +static const struct of_device_id sdm845_qcom_llcc_of_match[] = {
>> + { .compatible = "qcom,sdm845-llcc", },
>
>> + { },
>
> Slightly better w/o comma
Changed
>
>> +};
>
>> +static struct platform_driver sdm845_qcom_llcc_driver = {
>> + .driver = {
>> + .name = "sdm845-llcc",
>
>> + .owner = THIS_MODULE,
>
> No need. See below.
>
>> + .of_match_table = sdm845_qcom_llcc_of_match,
>> + },
>> + .probe = sdm845_qcom_llcc_probe,
>> +};
>
>> +
>> +static int __init sdm845_init_qcom_llcc_init(void)
>> +{
>> + return platform_driver_register(&sdm845_qcom_llcc_driver);
>> +}
>> +module_init(sdm845_init_qcom_llcc_init);
>> +
>> +static void __exit sdm845_exit_qcom_llcc_exit(void)
>> +{
>> + platform_driver_unregister(&sdm845_qcom_llcc_driver);
>> +}
>> +module_exit(sdm845_exit_qcom_llcc_exit);
>
> Why not to use module_platform_driver() macro?
Done
>
>> +#define ACTIVATE 0x1
>> +#define DEACTIVATE 0x2
>> +#define ACT_CTRL_OPCODE_ACTIVATE 0x1
>> +#define ACT_CTRL_OPCODE_DEACTIVATE 0x2
>> +#define ACT_CTRL_ACT_TRIG 0x1
>
> Are these bits? Perhaps BIT() ?
>
isn't it just better to use fixed size as u suggest in the next comment?
>> +#define ACT_CTRL_OPCODE_SHIFT 0x1
>> +#define ATTR1_PROBE_TARGET_WAYS_SHIFT 0x2
>> +#define ATTR1_FIXED_SIZE_SHIFT 0x3
>> +#define ATTR1_PRIORITY_SHIFT 0x4
>> +#define ATTR1_MAX_CAP_SHIFT 0x10
>
> Better to use fixed size pattern, i.e. 0x01, 0x02, 0x03, 0x04, 0x10.
>
>> +#define ATTR0_RES_WAYS_MASK 0x00000fff
>> +#define ATTR0_BONUS_WAYS_MASK 0x0fff0000
>
> GENMASK()
Done
>
>> +#define LLCC_LB_CNT_MASK 0xf0000000
>
> Ditto.
>
>> +#define MAX_CAP_TO_BYTES(n) (n * 1024)
>
> (n * SZ_1K) ?
Done
>
>> +#define LLCC_TRP_ACT_CTRLn(n) (n * 0x1000)
>
> SZ_4K ?
>
>> +#define LLCC_TRP_STATUSn(n) (4 + n * 0x1000)
>
> Ditto.
>
>> +struct llcc_slice_desc *llcc_slice_getd(u32 uid)
>> +{
>> + const struct llcc_slice_config *cfg;
>> + struct llcc_slice_desc *desc;
>> + u32 sz, count = 0;
>> +
>> + cfg = drv_data->cfg;
>> + sz = drv_data->cfg_size;
>> +
>
>> + while (cfg && count < sz) {
>> + if (cfg->usecase_id == uid)
>> + break;
>> + cfg++;
>> + count++;
>> + }
>> + if (cfg == NULL || count == sz)
>> + return ERR_PTR(-ENODEV);
>
> if (!cfg)
> return ERR_PTR(-ENODEV);
>
> while (cfg->... != uid) {
> cfg++;
> count++;
> }
>
> if (count == sz)
> return ...
>
> Though I would rather put it to for () loop.
>
In each while loop iteration the cfg pointer needs to be checked for
NULL. What if the usecase id never matches the uid passed by client
and we keep iterating. At some point it will crash.
>> +static int llcc_update_act_ctrl(u32 sid,
>> + u32 act_ctrl_reg_val, u32 status)
>> +{
>> + u32 act_ctrl_reg;
>> + u32 status_reg;
>> + u32 slice_status;
>
>> + int ret = 0;
>
> Useless assignment. Check entire patch series for a such.
Checked and removed these.
>
>> + ret = regmap_read_poll_timeout(drv_data->regmap, status_reg,
>> + slice_status, !(slice_status & status), 0,
>> LLCC_STATUS_READ_DELAY);
>
> Wrong indentation.
Corrected
>
>> + return ret;
>> +}
>
>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>> + DEACTIVATE);
>
> Perhaps one line (~83 characters here is OK) ?
The checkpatch script complains about such lines.
>
>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>> + ACTIVATE);
>
> Ditto.
>
>> + attr1_cfg = bcast_off +
>> +
>> LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
>> + attr0_cfg = bcast_off +
>> +
>> LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
>
> Ditto.
>
>> + attr1_val |= llcc_table[i].probe_target_ways <<
>> + ATTR1_PROBE_TARGET_WAYS_SHIFT;
>> + attr1_val |= llcc_table[i].fixed_size <<
>> + ATTR1_FIXED_SIZE_SHIFT;
>> + attr1_val |= llcc_table[i].priority <<
>> ATTR1_PRIORITY_SHIFT;
>
> foo |=
> bar << SHIFT;
>
> would look slightly better.
>
>> +int qcom_llcc_probe(struct platform_device *pdev,
>> + const struct llcc_slice_config *llcc_cfg, u32
>> sz)
>> +{
>
>> + drv_data->offsets = devm_kzalloc(dev, num_banks * sizeof(u32),
>> + GFP_KERNEL);
>> + if (!drv_data->offsets)
>> + return -ENOMEM;
>
> devm_kcalloc() ?
changed
>> +
>> + for (i = 0; i < num_banks; i++)
>> + drv_data->offsets[i] = (i * BANK_OFFSET_STRIDE);
>
> Pointless parens.
Removed
>
>> + drv_data->bitmap = devm_kcalloc(dev,
>> + BITS_TO_LONGS(drv_data->max_slices), sizeof(unsigned long),
>> + GFP_KERNEL);
>> + if (!drv_data->bitmap)
>> + return -ENOMEM;
>
> Perhaps at some point someone will add
> bitmap_alloc()
> devm_bitmap_alloc()
>
>> + bitmap_zero(drv_data->bitmap, drv_data->max_slices);
>
> Pointless
Removed
^ permalink raw reply
* Re: [PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware
From: Saravana Kannan @ 2018-05-22 18:30 UTC (permalink / raw)
To: Rob Herring
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Mark Rutland,
Rajendra Nayak, Amit Kucheria, linux-pm, devicetree, linux-kernel
In-Reply-To: <20180522180838.GA13423@rob-hp-laptop>
On 05/22/2018 11:08 AM, Rob Herring wrote:
> On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote:
>> The firmware present in some QCOM chipsets offloads the steps necessary for
>> changing the frequency of some devices (Eg: L3). This driver implements the
>> devfreq interface for this firmware so that various governors could be used
>> to scale the frequency of these devices.
>>
>> Each client (say cluster 0 and cluster 1) that wants to vote for a
>> particular device's frequency (say, L3 frequency) is represented as a
>> separate voter device (qcom,devfreq-fw-voter) that's a child of the
>> firmware device (qcom,devfreq-fw).
>>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> ---
>> .../bindings/devfreq/devfreq-qcom-fw.txt | 41 +++
>> drivers/devfreq/Kconfig | 14 +
>> drivers/devfreq/Makefile | 1 +
>> drivers/devfreq/devfreq_qcom_fw.c | 330 +++++++++++++++++++++
>> 4 files changed, 386 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
>> create mode 100644 drivers/devfreq/devfreq_qcom_fw.c
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
>> new file mode 100644
>> index 0000000..f882a0b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
>> @@ -0,0 +1,41 @@
>> +QCOM Devfreq firmware device
>> +
>> +Some Qualcomm Technologies, Inc. (QTI) chipsets have a firmware that
>> +offloads the steps for frequency switching. It provides a table of
>> +supported frequencies and a register to request one of the supported
>> +freqencies.
>> +
>> +The qcom,devfreq-fw represents this firmware as a device. Sometimes,
>> +multiple entities want to vote on the frequency request that is sent to the
>> +firmware. The qcom,devfreq-fw-voter represents these voters as child
>> +devices of the corresponding qcom,devfreq-fw device.
>> +
>> +Required properties:
>> +- compatible: Must be "qcom,devfreq-fw" or "qcom,devfreq-fw-voter"
>
> No versions of firmware?
Sure, I can add a v1. Right now the interface has always been identical.
I thought if it changed in the future I'll add -v2.
>
>> +Only for qcom,devfreq-fw:
>> +- reg: Pairs of physical base addresses and region sizes of
>> + memory mapped registers.
>
> Registers? Is this firmware or h/w block?
It's a HW block that has its own firmware.
>
>> +- reg-names: Names of the bases for the above registers.
>> + Required register regions are:
>> + - "en-base": address of register to check if the
>> + firmware is enabled.
>> + - "ftbl-base": address region for the frequency
>> + table.
>> + - "perf-base": address of register to request a
>> + frequency.
>> +
>> +Example:
>> +
>> + qcom,devfreq-l3 {
>> + compatible = "qcom,devfreq-fw";
>> + reg-names = "en-base", "ftbl-base", "perf-base";
>> + reg = <0x18321000 0x4>, <0x18321110 0x600>, <0x18321920 0x4>;
>> +
>> + qcom,cpu0-l3 {
>> + compatible = "qcom,devfreq-fw-voter";
>
> There's no point in these nodes. They don't have any properties or
> resources.
These nodes decide how many voters this device supports. Each voter
would be a devfreq node that will have its own governor set. For
example, one of them would use this governor:
http://lkml.iu.edu/hypermail/linux/kernel/1805.2/02474.html
You can also attach different devfreq-event devices to each one of these
voter devices based on what events you want to use for scaling each
voter. So, the devices are definitely needed in the larger context.
Thanks,
Saravana
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: dts: imx28/imx53: enable edt-ft5x06 wakeup source
From: Dmitry Torokhov @ 2018-05-22 18:20 UTC (permalink / raw)
To: Shawn Guo
Cc: mark.rutland, devicetree, robh+dt, linux-arm-kernel, kernel,
linux-input, fabio.estevam, Daniel Mack
In-Reply-To: <20180520130528.GC26863@dragon>
On Sun, May 20, 2018 at 09:05:30PM +0800, Shawn Guo wrote:
> On Thu, May 17, 2018 at 11:05:52AM +0200, Daniel Mack wrote:
> > The touchscreen driver no longer configures the device as wakeup source by
> > default. A "wakeup-source" property is needed.
> >
> > To avoid regressions, this patch changes the DTS files for the only two
> > users of this driver that didn't have this property yet.
> >
> > Signed-off-by: Daniel Mack <daniel@zonque.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
>
> Applied this one, thanks.
I think there are few more that need "wakeup-source" added:
arch/arm/boot/dts/am437x-sk-evm.dts
arch/arm/boot/dts/imx6q-var-dt6customboard.dts
arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64: dts: specify 1.8V EMMC capabilities for bcm958742t
From: Florian Fainelli @ 2018-05-22 18:12 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Scott Branden, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1527008499-4120-1-git-send-email-scott.branden@broadcom.com>
On Tue, 22 May 2018 10:01:39 -0700, Scott Branden <scott.branden@broadcom.com> wrote:
> Specify 1.8V EMMC capabilities for bcm958742t board to indicate support
> for UHS mode.
>
> Fixes: d4b4aba6be8a ("arm64: dts: Initial DTS files for Broadcom Stingray SOC")
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
Applied to devicetree-arm64/fixes, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH V1 3/3] mmc: host: Register changes for sdcc V5
From: Evan Green @ 2018-05-22 18:12 UTC (permalink / raw)
To: vviswana
Cc: adrian.hunter, Ulf Hansson, robh+dt, mark.rutland, linux-mmc,
linux-kernel, shawn.lin, linux-arm-msm, georgi.djakov, devicetree,
asutoshd, stummala, venkatg, jeremymc, Bjorn Andersson, riteshh,
vbadigan, Doug Anderson, sayalil
In-Reply-To: <1526552938-21292-4-git-send-email-vviswana@codeaurora.org>
Hi Vijay. Thanks for this patch.
On Thu, May 17, 2018 at 3:30 AM Vijay Viswanath <vviswana@codeaurora.org>
wrote:
> From: Sayali Lokhande <sayalil@codeaurora.org>
> For SDCC version 5.0.0 and higher, new compatible string
> "qcom,sdhci-msm-v5" is added.
> Based on the msm variant, pick the relevant variant data and
> use it for register read/write to msm specific registers.
> Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
> ---
> .../devicetree/bindings/mmc/sdhci-msm.txt | 5 +-
> drivers/mmc/host/sdhci-msm.c | 344
+++++++++++++--------
> 2 files changed, 222 insertions(+), 127 deletions(-)
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> index bfdcdc4..c2b7b2b 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> @@ -4,7 +4,10 @@ This file documents differences between the core
properties in mmc.txt
> and the properties used by the sdhci-msm driver.
> Required properties:
> -- compatible: Should contain "qcom,sdhci-msm-v4".
> +- compatible: Should contain "qcom,sdhci-msm-v4" or "qcom,sdhci-msm-v5".
> + For SDCC version 5.0.0, MCI registers are removed from
SDCC
> + interface and some registers are moved to HC. New
compatible
> + string is added to support this change -
"qcom,sdhci-msm-v5".
> - reg: Base address and length of the register in the following order:
> - Host controller register map (required)
> - SD Core register map (required)
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index bb2bb59..408e6b2 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -33,16 +33,11 @@
> #define CORE_MCI_GENERICS 0x70
> #define SWITCHABLE_SIGNALING_VOLTAGE BIT(29)
> -#define CORE_HC_MODE 0x78
Remove CORE_MCI_VERSION as well.
> #define HC_MODE_EN 0x1
> #define CORE_POWER 0x0
> #define CORE_SW_RST BIT(7)
> #define FF_CLK_SW_RST_DIS BIT(13)
> -#define CORE_PWRCTL_STATUS 0xdc
> -#define CORE_PWRCTL_MASK 0xe0
> -#define CORE_PWRCTL_CLEAR 0xe4
> -#define CORE_PWRCTL_CTL 0xe8
> #define CORE_PWRCTL_BUS_OFF BIT(0)
> #define CORE_PWRCTL_BUS_ON BIT(1)
> #define CORE_PWRCTL_IO_LOW BIT(2)
> @@ -63,17 +58,13 @@
> #define CORE_CDR_EXT_EN BIT(19)
> #define CORE_DLL_PDN BIT(29)
> #define CORE_DLL_RST BIT(30)
> -#define CORE_DLL_CONFIG 0x100
> #define CORE_CMD_DAT_TRACK_SEL BIT(0)
> -#define CORE_DLL_STATUS 0x108
> -#define CORE_DLL_CONFIG_2 0x1b4
> #define CORE_DDR_CAL_EN BIT(0)
> #define CORE_FLL_CYCLE_CNT BIT(18)
> #define CORE_DLL_CLOCK_DISABLE BIT(21)
> -#define CORE_VENDOR_SPEC 0x10c
> -#define CORE_VENDOR_SPEC_POR_VAL 0xa1c
> +#define CORE_VENDOR_SPEC_POR_VAL 0xa1c
> #define CORE_CLK_PWRSAVE BIT(1)
> #define CORE_HC_MCLK_SEL_DFLT (2 << 8)
> #define CORE_HC_MCLK_SEL_HS400 (3 << 8)
> @@ -111,17 +102,14 @@
> #define CORE_CDC_SWITCH_BYPASS_OFF BIT(0)
> #define CORE_CDC_SWITCH_RC_EN BIT(1)
> -#define CORE_DDR_200_CFG 0x184
> #define CORE_CDC_T4_DLY_SEL BIT(0)
> #define CORE_CMDIN_RCLK_EN BIT(1)
> #define CORE_START_CDC_TRAFFIC BIT(6)
> -#define CORE_VENDOR_SPEC3 0x1b0
> +
> #define CORE_PWRSAVE_DLL BIT(3)
> -#define CORE_DDR_CONFIG 0x1b8
> #define DDR_CONFIG_POR_VAL 0x80040853
> -#define CORE_VENDOR_SPEC_CAPABILITIES0 0x11c
> #define INVALID_TUNING_PHASE -1
> #define SDHCI_MSM_MIN_CLOCK 400000
> @@ -380,10 +368,14 @@ static inline int msm_dll_poll_ck_out_en(struct
sdhci_host *host, u8 poll)
> u32 wait_cnt = 50;
> u8 ck_out_en;
> struct mmc_host *mmc = host->mmc;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + const struct sdhci_msm_offset *msm_offset =
> + msm_host->offset;
I notice this pattern is pasted all over the place in order to get to the
offsets. Maybe a macro or inlined function would be cleaner to get you to
directly to the sdhci_msm_offset struct from sdhci_host, rather than this
blob of paste soup everywhere. In some places you do seem to use the
intermediate locals, so those cases wouldn't need to use the new helper.
> /* Poll for CK_OUT_EN bit. max. poll time = 50us */
> - ck_out_en = !!(readl_relaxed(host->ioaddr + CORE_DLL_CONFIG) &
> - CORE_CK_OUT_EN);
> + ck_out_en = !!(readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config) & CORE_CK_OUT_EN);
> while (ck_out_en != poll) {
> if (--wait_cnt == 0) {
> @@ -393,8 +385,8 @@ static inline int msm_dll_poll_ck_out_en(struct
sdhci_host *host, u8 poll)
> }
> udelay(1);
> - ck_out_en = !!(readl_relaxed(host->ioaddr +
CORE_DLL_CONFIG) &
> - CORE_CK_OUT_EN);
> + ck_out_en = !!(readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config) & CORE_CK_OUT_EN);
> }
> return 0;
> @@ -410,16 +402,20 @@ static int msm_config_cm_dll_phase(struct
sdhci_host *host, u8 phase)
> unsigned long flags;
> u32 config;
> struct mmc_host *mmc = host->mmc;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + const struct sdhci_msm_offset *msm_offset =
> + msm_host->offset;
> if (phase > 0xf)
> return -EINVAL;
> spin_lock_irqsave(&host->lock, flags);
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
msm_offset->core_dll_config);
> config &= ~(CORE_CDR_EN | CORE_CK_OUT_EN);
> config |= (CORE_CDR_EXT_EN | CORE_DLL_EN);
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
msm_offset->core_dll_config);
> /* Wait until CK_OUT_EN bit of DLL_CONFIG register becomes '0' */
> rc = msm_dll_poll_ck_out_en(host, 0);
> @@ -430,24 +426,24 @@ static int msm_config_cm_dll_phase(struct
sdhci_host *host, u8 phase)
> * Write the selected DLL clock output phase (0 ... 15)
> * to CDR_SELEXT bit field of DLL_CONFIG register.
> */
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
msm_offset->core_dll_config);
> config &= ~CDR_SELEXT_MASK;
> config |= grey_coded_phase_table[phase] << CDR_SELEXT_SHIFT;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
msm_offset->core_dll_config);
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
msm_offset->core_dll_config);
> config |= CORE_CK_OUT_EN;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
msm_offset->core_dll_config);
> /* Wait until CK_OUT_EN bit of DLL_CONFIG register becomes '1' */
> rc = msm_dll_poll_ck_out_en(host, 1);
> if (rc)
> goto err_out;
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
msm_offset->core_dll_config);
> config |= CORE_CDR_EN;
> config &= ~CORE_CDR_EXT_EN;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
msm_offset->core_dll_config);
Nit: host->ioaddr + msm_offset->core_dll_config might benefit from having
its own local, since you use it so much in this function. Same goes for
where I've noted below...
> goto out;
> err_out:
> @@ -573,6 +569,10 @@ static int msm_find_most_appropriate_phase(struct
sdhci_host *host,
> static inline void msm_cm_dll_set_freq(struct sdhci_host *host)
> {
> u32 mclk_freq = 0, config;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + const struct sdhci_msm_offset *msm_offset =
> + msm_host->offset;
> /* Program the MCLK value to MCLK_FREQ bit field */
> if (host->clock <= 112000000)
> @@ -592,10 +592,10 @@ static inline void msm_cm_dll_set_freq(struct
sdhci_host *host)
> else if (host->clock <= 200000000)
> mclk_freq = 7;
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
msm_offset->core_dll_config);
> config &= ~CMUX_SHIFT_PHASE_MASK;
> config |= mclk_freq << CMUX_SHIFT_PHASE_SHIFT;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
msm_offset->core_dll_config);
> }
> /* Initialize the DLL (Programmable Delay Line) */
> @@ -607,6 +607,8 @@ static int msm_init_cm_dll(struct sdhci_host *host)
> int wait_cnt = 50;
> unsigned long flags;
> u32 config;
> + const struct sdhci_msm_offset *msm_offset =
> + msm_host->offset;
> spin_lock_irqsave(&host->lock, flags);
> @@ -615,34 +617,43 @@ static int msm_init_cm_dll(struct sdhci_host *host)
> * tuning is in progress. Keeping PWRSAVE ON may
> * turn off the clock.
> */
> - config = readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC);
> + config = readl_relaxed(host->ioaddr +
msm_offset->core_vendor_spec);
> config &= ~CORE_CLK_PWRSAVE;
> - writel_relaxed(config, host->ioaddr + CORE_VENDOR_SPEC);
> + writel_relaxed(config, host->ioaddr +
msm_offset->core_vendor_spec);
> if (msm_host->use_14lpp_dll_reset) {
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config);
> config &= ~CORE_CK_OUT_EN;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config);
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG_2);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config_2);
> config |= CORE_DLL_CLOCK_DISABLE;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG_2);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config_2);
> }
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config);
> config |= CORE_DLL_RST;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config);
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config);
> config |= CORE_DLL_PDN;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config);
> msm_cm_dll_set_freq(host);
> if (msm_host->use_14lpp_dll_reset &&
> !IS_ERR_OR_NULL(msm_host->xo_clk)) {
> u32 mclk_freq = 0;
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG_2);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config_2);
> config &= CORE_FLL_CYCLE_CNT;
> if (config)
> mclk_freq = DIV_ROUND_CLOSEST_ULL((host->clock *
8),
> @@ -651,40 +662,52 @@ static int msm_init_cm_dll(struct sdhci_host *host)
> mclk_freq = DIV_ROUND_CLOSEST_ULL((host->clock *
4),
> clk_get_rate(msm_host->xo_clk));
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG_2);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config_2);
> config &= ~(0xFF << 10);
> config |= mclk_freq << 10;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG_2);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config_2);
> /* wait for 5us before enabling DLL clock */
> udelay(5);
> }
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config);
> config &= ~CORE_DLL_RST;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config);
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config);
> config &= ~CORE_DLL_PDN;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config);
> if (msm_host->use_14lpp_dll_reset) {
> msm_cm_dll_set_freq(host);
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG_2);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config_2);
> config &= ~CORE_DLL_CLOCK_DISABLE;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG_2);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config_2);
> }
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config);
> config |= CORE_DLL_EN;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config);
> - config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_dll_config);
> config |= CORE_CK_OUT_EN;
> - writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> + writel_relaxed(config, host->ioaddr +
> + msm_offset->core_dll_config);
...here. A local for host->ioaddr + msm_offset->core_dll_config would save
you a lot of split lines.
> @@ -1272,12 +1327,17 @@ static void sdhci_msm_dump_pwr_ctrl_regs(struct
sdhci_host *host)
> {
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + const struct sdhci_msm_offset *msm_offset =
> + msm_host->offset;
> pr_err("%s: PWRCTL_STATUS: 0x%08x | PWRCTL_MASK: 0x%08x |
PWRCTL_CTL: 0x%08x\n",
> - mmc_hostname(host->mmc),
> - readl_relaxed(msm_host->core_mem +
CORE_PWRCTL_STATUS),
> - readl_relaxed(msm_host->core_mem +
CORE_PWRCTL_MASK),
> - readl_relaxed(msm_host->core_mem +
CORE_PWRCTL_CTL));
> + mmc_hostname(host->mmc),
> + msm_host->var_ops->msm_readl_relaxed(host,
There's a weird extra space here.
> + msm_offset->core_pwrctl_status),
> + msm_host->var_ops->msm_readl_relaxed(host,
> + msm_offset->core_pwrctl_mask),
> + msm_host->var_ops->msm_readl_relaxed(host,
> + msm_offset->core_pwrctl_ctl));
I think the idea of function pointers is fine, but overall the use of them
everywhere sure is ugly. It makes it really hard to actually see what's
happening. I wonder if things might look a lot cleaner with a helper
function here. Then instead of:
msm_host->var_ops->msm_readl_relaxed(host, msm_offset->core_pwrctl_ctl);
You could have
msm_core_read(host, msm_offset->core_pwrctl_ctl);
> @@ -1553,7 +1619,8 @@ static void sdhci_msm_set_regulator_caps(struct
sdhci_msm_host *msm_host)
> */
> u32 io_level = msm_host->curr_io_level;
> - config = readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC);
> + config = readl_relaxed(host->ioaddr +
> + msm_offset->core_vendor_spec);
Remove the second space before the readl_relaxed.
> @@ -1710,32 +1793,40 @@ static int sdhci_msm_probe(struct platform_device
*pdev)
> dev_warn(&pdev->dev, "TCXO clk not present (%d)\n", ret);
> }
> - core_memres = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - msm_host->core_mem = devm_ioremap_resource(&pdev->dev,
core_memres);
> + if (!msm_host->mci_removed) {
> + core_memres = platform_get_resource(pdev, IORESOURCE_MEM,
1);
> + msm_host->core_mem = devm_ioremap_resource(&pdev->dev,
> + core_memres);
> - if (IS_ERR(msm_host->core_mem)) {
> - dev_err(&pdev->dev, "Failed to remap registers\n");
> - ret = PTR_ERR(msm_host->core_mem);
> - goto clk_disable;
> + if (IS_ERR(msm_host->core_mem)) {
> + dev_err(&pdev->dev, "Failed to remap
registers\n");
> + ret = PTR_ERR(msm_host->core_mem);
> + goto clk_disable;
> + }
> }
> /* Reset the vendor spec register to power on reset state */
> writel_relaxed(CORE_VENDOR_SPEC_POR_VAL,
> - host->ioaddr + CORE_VENDOR_SPEC);
> -
> - /* Set HC_MODE_EN bit in HC_MODE register */
> - writel_relaxed(HC_MODE_EN, (msm_host->core_mem + CORE_HC_MODE));
> -
> - config = readl_relaxed(msm_host->core_mem + CORE_HC_MODE);
> - config |= FF_CLK_SW_RST_DIS;
> - writel_relaxed(config, msm_host->core_mem + CORE_HC_MODE);
> + host->ioaddr + msm_offset->core_vendor_spec);
> +
> + if (!msm_host->mci_removed) {
> + /* Set HC_MODE_EN bit in HC_MODE register */
> + msm_host->var_ops->msm_writel_relaxed(HC_MODE_EN, host,
> + msm_offset->core_hc_mode);
> + config = msm_host->var_ops->msm_readl_relaxed(host,
> + msm_offset->core_hc_mode);
> + config |= FF_CLK_SW_RST_DIS;
> + msm_host->var_ops->msm_writel_relaxed(config, host,
> + msm_offset->core_hc_mode);
> + }
> host_version = readw_relaxed((host->ioaddr + SDHCI_HOST_VERSION));
> dev_dbg(&pdev->dev, "Host Version: 0x%x Vendor Version 0x%x\n",
> host_version, ((host_version & SDHCI_VENDOR_VER_MASK) >>
> SDHCI_VENDOR_VER_SHIFT));
> - core_version = readl_relaxed(msm_host->core_mem +
CORE_MCI_VERSION);
> + core_version = msm_host->var_ops->msm_readl_relaxed(host,
> + msm_offset->core_mci_version);
Another double space after the =. Perhaps this was a find/replace error?
Look out for more of these that I missed.
-Evan
^ permalink raw reply
* Re: [PATCH v3 0/4] Introduce STM32MP1 RTC
From: Alexandre Belloni @ 2018-05-22 18:11 UTC (permalink / raw)
To: Amelie Delaunay
Cc: Alessandro Zummo, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, linux-rtc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1526558666-24243-1-git-send-email-amelie.delaunay@st.com>
On 17/05/2018 14:04:22+0200, Amelie Delaunay wrote:
> This series introduces STM32MP1 RTC.
> On STM32MP1:
> - two clocks are needed, plck and rtc_ck;
> - to wakeup the system, a wakeup alarm interrupt is needed;
> - some registers or bits have moved, but the operation is the same;
> - the Backup Domain Protection (DBP) is not managed by RTC driver.
>
> ---
> Changes in v3:
> * Move cleanup changes in a separate patch
> * Replace regs and evts by pointers to ensure no copy is made
> * Set all registers offset as u16 instead of u8 and u16
> * Fix Kbuild smatch warning:
> drivers/rtc/rtc-stm32.c:827 stm32_rtc_probe()
> warn: always true condition '(regs.verr != ~0) => (0-u16max != (-1))'
>
> Changes in v2:
> * One compatible per line in bindings file
> * Remove unnecessary comment under rtc_ck as this clock is required for all
> * Remove interrupts-extended and add stm32mp1 rtc alarm wakeup interrupt in
> interrupts property description
>
> Amelie Delaunay (4):
> rtc: stm32: fix misspelling and misalignment issues
> rtc: stm32: rework register management to prepare other version of RTC
> dt-bindings: rtc: update stm32-rtc documentation for stm32mp1 rtc
> rtc: stm32: add stm32mp1 rtc support
>
> .../devicetree/bindings/rtc/st,stm32-rtc.txt | 27 +-
> drivers/rtc/rtc-stm32.c | 273 ++++++++++++++++-----
> 2 files changed, 229 insertions(+), 71 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 14/26] dt-bindings: display: Add compatible for A64 HDMI
From: Rob Herring @ 2018-05-22 18:10 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Icenowy Zheng, Jernej Skrabec,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Michael Turquette,
Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA, Michael Trimarchi,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20180518094536.17201-15-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
On Fri, May 18, 2018 at 03:15:24PM +0530, Jagan Teki wrote:
> HDMI on Allwinner A64 has similar like H3/H5/A83T.
>
> Add compatible a64 and update A83T compatible as fallback.
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
> Changes for v2:
> - Add fallback compatible
>
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH V1 2/3] mmc: sdhci-msm: Add msm version specific ops and data structures
From: Evan Green @ 2018-05-22 18:10 UTC (permalink / raw)
To: vviswana
Cc: adrian.hunter, Ulf Hansson, robh+dt, mark.rutland, linux-mmc,
linux-kernel, shawn.lin, linux-arm-msm, georgi.djakov, devicetree,
asutoshd, stummala, venkatg, jeremymc, Bjorn Andersson, riteshh,
vbadigan, Doug Anderson, sayalil
In-Reply-To: <1526552938-21292-3-git-send-email-vviswana@codeaurora.org>
On Thu, May 17, 2018 at 3:30 AM Vijay Viswanath <vviswana@codeaurora.org>
wrote:
> In addition to offsets of certain registers changing, the registers in
> core_mem have been shifted to HC mem as well. To access these registers,
> define msm version specific functions. These functions can be loaded
> into the function pointers at the time of probe based on the msm version
> detected.
> Also defind new data structure to hold version specific Ops and register
> addresses.
> Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
> ---
> drivers/mmc/host/sdhci-msm.c | 112
+++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 112 insertions(+)
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 2524455..bb2bb59 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -226,6 +226,25 @@ struct sdhci_msm_offset {
> .core_ddr_config_2 = 0x1BC,
> };
> +struct sdhci_msm_variant_ops {
> + u8 (*msm_readb_relaxed)(struct sdhci_host *host, u32 offset);
I don't see any uses of msm_readb_relaxed or msm_writeb_relaxed in this
patch or the next one. Are these needed?
> + u32 (*msm_readl_relaxed)(struct sdhci_host *host, u32 offset);
> + void (*msm_writeb_relaxed)(u8 val, struct sdhci_host *host, u32
offset);
> + void (*msm_writel_relaxed)(u32 val, struct sdhci_host *host,
> + u32 offset);
> +};
> +
> +/*
> + * From V5, register spaces have changed. Wrap this info in a structure
> + * and choose the data_structure based on version info mentioned in DT.
> + */
> +struct sdhci_msm_variant_info {
> + bool mci_removed;
> + const struct sdhci_msm_variant_ops *var_ops;
> + const struct sdhci_msm_offset *offset;
> +};
> +
> +
Remove extra blank line.
> struct sdhci_msm_host {
> struct platform_device *pdev;
> void __iomem *core_mem; /* MSM SDCC mapped address */
> @@ -245,8 +264,75 @@ struct sdhci_msm_host {
> wait_queue_head_t pwr_irq_wait;
> bool pwr_irq_flag;
> u32 caps_0;
> + bool mci_removed;
> + const struct sdhci_msm_variant_ops *var_ops;
> + const struct sdhci_msm_offset *offset;
> };
> +/*
> + * APIs to read/write to vendor specific registers which were there in
the
> + * core_mem region before MCI was removed.
> + */
> +static u8 sdhci_msm_mci_variant_readb_relaxed(struct sdhci_host *host,
> + u32 offset)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> +
> + return readb_relaxed(msm_host->core_mem + offset);
> +}
> +
> +static u8 sdhci_msm_v5_variant_readb_relaxed(struct sdhci_host *host,
> + u32 offset)
> +{
> + return readb_relaxed(host->ioaddr + offset);
> +}
> +
> +static u32 sdhci_msm_mci_variant_readl_relaxed(struct sdhci_host *host,
> + u32 offset)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> +
> + return readl_relaxed(msm_host->core_mem + offset);
> +}
> +
> +static u32 sdhci_msm_v5_variant_readl_relaxed(struct sdhci_host *host,
> + u32 offset)
> +{
> + return readl_relaxed(host->ioaddr + offset);
> +}
> +
> +static void sdhci_msm_mci_variant_writeb_relaxed(u8 val,
> + struct sdhci_host *host, u32 offset)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> +
> + writeb_relaxed(val, msm_host->core_mem + offset);
> +}
> +
> +static void sdhci_msm_v5_variant_writeb_relaxed(u8 val, struct
sdhci_host *host,
> + u32 offset)
> +{
> + writeb_relaxed(val, host->ioaddr + offset);
> +}
> +
> +static void sdhci_msm_mci_variant_writel_relaxed(u32 val,
> + struct sdhci_host *host, u32 offset)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> +
> + writel_relaxed(val, msm_host->core_mem + offset);
> +}
> +
> +static void sdhci_msm_v5_variant_writel_relaxed(u32 val, struct
sdhci_host *host,
You squeaked over 80 characters here. Move the second parameter down with
the third.
-Evan
^ permalink raw reply
* Re: [PATCH v2 07/26] dt-bindings: display: Add compatible for A64 DE2 tcon1 blocks
From: Rob Herring @ 2018-05-22 18:10 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Icenowy Zheng, Jernej Skrabec,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Michael Turquette,
Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA, Michael Trimarchi,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20180518094536.17201-8-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
On Fri, May 18, 2018 at 03:15:17PM +0530, Jagan Teki wrote:
> Allwinner A64 has DE2 pipeline with tcon0 and tcon1 block
> which is similar Allwinner A83T.
>
> This patch adds dt-binding documentation for A64 DE2 tcon1 blocks.
>
> Mixer1 has different configuration for A64 so use separate compatible
> but tcon1 has similar behaviour with A83T so add fallback compatible.
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
> Changes for v2:
> - Add fallback compatible for tcon1
> - Add separate compatible for mixer1
>
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH V1 1/3] mmc: sdhci-msm: Define new Register address map
From: Evan Green @ 2018-05-22 18:09 UTC (permalink / raw)
To: vviswana
Cc: adrian.hunter, Ulf Hansson, robh+dt, mark.rutland, linux-mmc,
linux-kernel, shawn.lin, linux-arm-msm, georgi.djakov, devicetree,
asutoshd, stummala, venkatg, jeremymc, Bjorn Andersson, riteshh,
vbadigan, Doug Anderson, sayalil
In-Reply-To: <1526552938-21292-2-git-send-email-vviswana@codeaurora.org>
Hi Vijay,
On Thu, May 17, 2018 at 3:30 AM Vijay Viswanath <vviswana@codeaurora.org>
wrote:
> From: Sayali Lokhande <sayalil@codeaurora.org>
> For SDCC version 5.0.0, MCI registers are removed from SDCC
> interface and some registers are moved to HC.
> Define a new data structure where we can statically define
> the address offsets for the registers in different SDCC versions.
> Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
> ---
> drivers/mmc/host/sdhci-msm.c | 89
++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index bb11916..2524455 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -137,6 +137,95 @@
> /* Timeout value to avoid infinite waiting for pwr_irq */
> #define MSM_PWR_IRQ_TIMEOUT_MS 5000
> +struct sdhci_msm_offset {
> + u32 core_hc_mode;
> + u32 core_mci_data_cnt;
> + u32 core_mci_status;
> + u32 core_mci_fifo_cnt;
> + u32 core_mci_version;
> + u32 core_generics;
> + u32 core_testbus_config;
> + u32 core_testbus_sel2_bit;
> + u32 core_testbus_ena;
> + u32 core_testbus_sel2;
> + u32 core_pwrctl_status;
> + u32 core_pwrctl_mask;
> + u32 core_pwrctl_clear;
> + u32 core_pwrctl_ctl;
> + u32 core_sdcc_debug_reg;
> + u32 core_dll_config;
> + u32 core_dll_status;
> + u32 core_vendor_spec;
> + u32 core_vendor_spec_adma_err_addr0;
> + u32 core_vendor_spec_adma_err_addr1;
> + u32 core_vendor_spec_func2;
> + u32 core_vendor_spec_capabilities0;
> + u32 core_ddr_200_cfg;
> + u32 core_vendor_spec3;
> + u32 core_dll_config_2;
> + u32 core_ddr_config;
> + u32 core_ddr_config_2;
> +};
> +
> +static const struct sdhci_msm_offset sdhci_msm_v5_offset = {
> + .core_mci_data_cnt = 0x35c,
> + .core_mci_status = 0x324,
> + .core_mci_fifo_cnt = 0x308,
> + .core_mci_version = 0x318,
> + .core_generics = 0x320,
> + .core_testbus_config = 0x32c,
> + .core_testbus_sel2_bit = 3,
> + .core_testbus_ena = (1 << 31),
> + .core_testbus_sel2 = (1 << 3),
> + .core_pwrctl_status = 0x240,
> + .core_pwrctl_mask = 0x244,
> + .core_pwrctl_clear = 0x248,
> + .core_pwrctl_ctl = 0x24c,
> + .core_sdcc_debug_reg = 0x358,
> + .core_dll_config = 0x200,
> + .core_dll_status = 0x208,
> + .core_vendor_spec = 0x20c,
> + .core_vendor_spec_adma_err_addr0 = 0x214,
> + .core_vendor_spec_adma_err_addr1 = 0x218,
> + .core_vendor_spec_func2 = 0x210,
> + .core_vendor_spec_capabilities0 = 0x21c,
> + .core_ddr_200_cfg = 0x224,
> + .core_vendor_spec3 = 0x250,
> + .core_dll_config_2 = 0x254,
> + .core_ddr_config = 0x258,
> + .core_ddr_config_2 = 0x25c,
> +};
> +
> +static const struct sdhci_msm_offset sdhci_msm_mci_offset = {
> + .core_hc_mode = 0x78,
> + .core_mci_data_cnt = 0x30,
> + .core_mci_status = 0x34,
> + .core_mci_fifo_cnt = 0x44,
> + .core_mci_version = 0x050,
> + .core_generics = 0x70,
> + .core_testbus_config = 0x0CC,
> + .core_testbus_sel2_bit = 4,
> + .core_testbus_ena = (1 << 3),
> + .core_testbus_sel2 = (1 << 4),
> + .core_pwrctl_status = 0xDC,
> + .core_pwrctl_mask = 0xE0,
> + .core_pwrctl_clear = 0xE4,
> + .core_pwrctl_ctl = 0xE8,
> + .core_sdcc_debug_reg = 0x124,
> + .core_dll_config = 0x100,
> + .core_dll_status = 0x108,
> + .core_vendor_spec = 0x10C,
> + .core_vendor_spec_adma_err_addr0 = 0x114,
> + .core_vendor_spec_adma_err_addr1 = 0x118,
> + .core_vendor_spec_func2 = 0x110,
> + .core_vendor_spec_capabilities0 = 0x11C,
> + .core_ddr_200_cfg = 0x184,
> + .core_vendor_spec3 = 0x1B0,
> + .core_dll_config_2 = 0x1B4,
> + .core_ddr_config = 0x1B8,
> + .core_ddr_config_2 = 0x1BC,
> +};
> +
I notice a lot of these are never used in the subsequent patches of this
series. I guess more register definitions are always better than fewer,
it's just a shame that they take up space now. Did you just add everything
that was different between v4 and v5, or how did you come up with this set?
Also, I think lowercase hex letters are preferred.
I verified that the v5 register offsets look good, at least for the
registers I have documentation for.
-Evan
^ permalink raw reply
* Re: [PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware
From: Rob Herring @ 2018-05-22 18:08 UTC (permalink / raw)
To: Saravana Kannan
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Mark Rutland,
Rajendra Nayak, Amit Kucheria, linux-pm, devicetree, linux-kernel
In-Reply-To: <1526629965-28729-1-git-send-email-skannan@codeaurora.org>
On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote:
> The firmware present in some QCOM chipsets offloads the steps necessary for
> changing the frequency of some devices (Eg: L3). This driver implements the
> devfreq interface for this firmware so that various governors could be used
> to scale the frequency of these devices.
>
> Each client (say cluster 0 and cluster 1) that wants to vote for a
> particular device's frequency (say, L3 frequency) is represented as a
> separate voter device (qcom,devfreq-fw-voter) that's a child of the
> firmware device (qcom,devfreq-fw).
>
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> ---
> .../bindings/devfreq/devfreq-qcom-fw.txt | 41 +++
> drivers/devfreq/Kconfig | 14 +
> drivers/devfreq/Makefile | 1 +
> drivers/devfreq/devfreq_qcom_fw.c | 330 +++++++++++++++++++++
> 4 files changed, 386 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
> create mode 100644 drivers/devfreq/devfreq_qcom_fw.c
>
> diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
> new file mode 100644
> index 0000000..f882a0b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
> @@ -0,0 +1,41 @@
> +QCOM Devfreq firmware device
> +
> +Some Qualcomm Technologies, Inc. (QTI) chipsets have a firmware that
> +offloads the steps for frequency switching. It provides a table of
> +supported frequencies and a register to request one of the supported
> +freqencies.
> +
> +The qcom,devfreq-fw represents this firmware as a device. Sometimes,
> +multiple entities want to vote on the frequency request that is sent to the
> +firmware. The qcom,devfreq-fw-voter represents these voters as child
> +devices of the corresponding qcom,devfreq-fw device.
> +
> +Required properties:
> +- compatible: Must be "qcom,devfreq-fw" or "qcom,devfreq-fw-voter"
No versions of firmware?
> +Only for qcom,devfreq-fw:
> +- reg: Pairs of physical base addresses and region sizes of
> + memory mapped registers.
Registers? Is this firmware or h/w block?
> +- reg-names: Names of the bases for the above registers.
> + Required register regions are:
> + - "en-base": address of register to check if the
> + firmware is enabled.
> + - "ftbl-base": address region for the frequency
> + table.
> + - "perf-base": address of register to request a
> + frequency.
> +
> +Example:
> +
> + qcom,devfreq-l3 {
> + compatible = "qcom,devfreq-fw";
> + reg-names = "en-base", "ftbl-base", "perf-base";
> + reg = <0x18321000 0x4>, <0x18321110 0x600>, <0x18321920 0x4>;
> +
> + qcom,cpu0-l3 {
> + compatible = "qcom,devfreq-fw-voter";
There's no point in these nodes. They don't have any properties or
resources.
> + };
> +
> + qcom,cpu4-l3 {
> + compatible = "qcom,devfreq-fw-voter";
> + };
> + };
^ permalink raw reply
* Re: [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Rob Herring @ 2018-05-22 18:02 UTC (permalink / raw)
To: djw
Cc: linux-rockchip, Wayne Chou, Heiko Stuebner, devicetree,
Linus Walleij, linux-kernel, linux-gpio, Mark Rutland,
linux-arm-kernel
In-Reply-To: <1526615528-9707-2-git-send-email-djw@t-chip.com.cn>
On Fri, May 18, 2018 at 11:52:05AM +0800, djw@t-chip.com.cn wrote:
> From: Levin Du <djw@t-chip.com.cn>
>
> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
> which do not belong to the general pinctrl.
>
> Adding gpio-syscon support makes controlling regulator or
> LED using these special pins very easy by reusing existing
> drivers, such as gpio-regulator and led-gpio.
>
> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>
> ---
>
> Changes in v2:
> - Rename gpio_syscon10 to gpio_mute in doc
>
> Changes in v1:
> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> - Add doc rockchip,gpio-syscon.txt
>
> .../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++++++++++++++++++++++
> drivers/gpio/gpio-syscon.c | 30 ++++++++++++++++
> 2 files changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> new file mode 100644
> index 0000000..b1b2a67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> @@ -0,0 +1,41 @@
> +* Rockchip GPIO support for GRF_SOC_CON registers
> +
> +Required properties:
> +- compatible: Should contain "rockchip,gpio-syscon".
> +- gpio-controller: Marks the device node as a gpio controller.
> +- #gpio-cells: Should be two. The first cell is the pin number and
> + the second cell is used to specify the gpio polarity:
> + 0 = Active high,
> + 1 = Active low.
There's no need for this child node. Just make the parent node a gpio
controller.
Rob
^ permalink raw reply
* Re: [PATCH v7 0/9] Add support for SAMA5D2 touchscreen
From: Jonathan Cameron @ 2018-05-22 17:57 UTC (permalink / raw)
To: Eugen Hristev
Cc: ludovic.desroches, alexandre.belloni, linux-arm-kernel,
devicetree, linux-kernel, linux-iio, linux-input, nicolas.ferre,
dmitry.torokhov, robh
In-Reply-To: <1526975559-18966-1-git-send-email-eugen.hristev@microchip.com>
On Tue, 22 May 2018 10:52:30 +0300
Eugen Hristev <eugen.hristev@microchip.com> wrote:
> Hello,
>
> This patch series is a rework of my previous series named:
> [PATCH 00/14] iio: triggers: add consumer support
>
> This is the version 7 of the series, and addresses the received feedback
> on the v2 series named:
> [PATCH v2 00/10] Add support for SAMA5D2 touchscreen
> and the v3 series named
> [PATCH v3 00/11] Add support for SAMA5D2 touchscreen
> and the v4 series named
> [PATCH v4 0/9] Add support for SAMA5D2 touchscreen
> and fixes one bug found in series named
> [PATCH v5 0/9] Add support for SAMA5D2 touchscreen
> and addresses comments in series named
> [PATCH v6 0/9] Add support for SAMA5D2 touchscreen
>
> This series applies on top of fixes-togreg branch of iio.git,
> specifically on top of commit:
> "f0c8d1f" : iio: adc: at91-sama5d2_adc:
> fix channel configuration for differential channels
>
> Jonathan, if you need me to rebase this on top of testing, let me know.
>
> Changes in previous versions are presented at the end of the cover letter below.
> Thanks everyone for the feedback. Below is the original v2 cover letter:
>
> In few words, this is the implementation of splitting the functionality
> of the IP block ADC device in SAMA5D2 SoC from ADC with touchscreen
> support. In order to avoid having a MFD device, two separate
> drivers that would work on same register base and split the IRQ,etc,
> as advised on the mailing list, I created a consumer driver for the
> channels, that will connect to the ADC as described in the device tree.
>
> I have collected feedback from everyone and here is the result:
> I have added a new generic resistive touchscreen driver, which acts
> as a iio consumer for the given channels and will create an input
> device and report the events. It uses a callback buffer to register
> to the IIO device and waits for data to be pushed.
> Inside the IIO device, I have kept a similar approach with the first version
> of the series, except that now the driver can take multiple buffers, and
> will configure the touchscreen part of the hardware device if the specific
> channels are requested.
>
> The SAMA5D2 ADC driver registers three new channels: two for the
> position on the X and Y axis, and one for the touch pressure.
> When channels are requested, it will check if the touchscreen channel mask
> includes the requested channels (it is possible that the consumer driver
> will not request pressure for example). If it's the case, it will work
> in touchscreen mode, and will refuse to do usual analog-digital conversion,
> because we have a single trigger and the touchscreen needs it.
> When the scan mask will include only old channels, the driver will function
> in the same way as before. If the scan mask somehow is a mix of the two (the
> masks intersect), the driver will refuse to work whatsoever (cannot have both
> in the same time).
> The driver allows reading raw data for the new channels, if claim direct
> mode works: no touchscreen driver requested anything. The new channels can
> act like the old ones. However, when requesting these channels, the usual
> trigger will not work and will not be enabled. The touchscreen channels
> require special trigger and irq configuration: pen detect, no pen detect
> and a periodic trigger to sample the touchscreen position and pressure.
> If the user attempts to use another trigger while there is a buffer
> that already requested the touchscreen channels (thus the trigger), the
> driver will refuse to comply.
>
> In order to have defines for the channel numbers, I added a bindings include
> file that goes on a separate commit :
> dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer info
> This should go in the same tree with the following commits :
> ARM: dts: at91: sama5d2: add channel cells for ADC device
> ARM: dts: at91: sama5d2: Add resistive touch device
>
> as build will break because these commits depend on the binding one
> which creates the included header file.
> V5 update: After discussing with Alexandre Belloni on Mailing list, the two
> DTS patches are to be taken in the next version after bindings reach mainline.
>
> Changes in v7:
> - Addressed some feedback from Dmitry, explained in input driver patch
> changelog.
> - Added Acked-by Dmitry.
>
> Changes in v6:
> - Fixed a crash in ADC driver , explained in driver patch changelog.
> - changed a dev_err to dev_dbg in input driver.
> - added Reviewed-by Rob Herring.
>
> Changes in v5:
> - renamed property touchscreen-threshold-pressure to touchscreen-min-pressure
> - added one return in touchscreen driver
>
> Changes in v4:
> - removed patch for inkern module get/set kref
> - addressed feedback on both the ADC and the touchscreen driver. each
> patch has a history inside the patch file for the specific changes.
> - patch that fixes the channel fix
> [PATCH v3 01/11] iio: adc: at91-sama5d2_adc:
> fix channel configuration for differential channels
> was accepted in fixes-togreg branch thus removed from this series.
> - added Reviewed-by for the bindings by Rob Herring
>
> Changes in v3:
> - changed input driver name according to feedback and reworked in commits
> to adapt to binding changes and new name.
> - moved channel index fix in at91-sama5d2_adc at the beginning of the series
> (PATCH 01/11)
> - created a new optional binding for the touchscreen as a separate commit
> and added it to the series :
> [PATCH v3 04/11] dt-bindings: input: touchscreen: add pressure
> threshold touchscreen property
> - changed at91-sama5d2_adc driver patch to address the comments. Exact changes
> are in the patch file for the driver source file.
>
> Eugen Hristev (9):
> MAINTAINERS: add generic resistive touchscreen adc
> iio: Add channel for Position Relative
> dt-bindings: input: touchscreen: add minimum pressure touchscreen
> property
> dt-bindings: input: touchscreen: resistive-adc-touch: create bindings
> iio: adc: at91-sama5d2_adc: add support for position and pressure
> channels
> input: touchscreen: resistive-adc-touch: add generic resistive ADC
> touchscreen
> dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer
> info
> ARM: dts: at91: sama5d2: add channel cells for ADC device
> ARM: dts: at91: sama5d2: Add resistive touch device
>
> Documentation/ABI/testing/sysfs-bus-iio | 12 +
> .../bindings/iio/adc/at91-sama5d2_adc.txt | 9 +
> .../input/touchscreen/resistive-adc-touch.txt | 30 +
> .../bindings/input/touchscreen/touchscreen.txt | 3 +
> MAINTAINERS | 6 +
> arch/arm/boot/dts/sama5d2.dtsi | 12 +
> drivers/iio/adc/at91-sama5d2_adc.c | 609 +++++++++++++++++++--
> drivers/iio/industrialio-core.c | 1 +
> drivers/input/touchscreen/Kconfig | 13 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/resistive-adc-touch.c | 204 +++++++
> include/dt-bindings/iio/adc/at91-sama5d2_adc.h | 16 +
> include/uapi/linux/iio/types.h | 1 +
> tools/iio/iio_event_monitor.c | 2 +
> 14 files changed, 861 insertions(+), 58 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
> create mode 100644 drivers/input/touchscreen/resistive-adc-touch.c
> create mode 100644 include/dt-bindings/iio/adc/at91-sama5d2_adc.h
>
Hi All,
I'm happy to take this, but there is a slight issue that we have a fix working
it's way in which this is dependent on.
I'll see if we can get this sorted before the merge window, but we may be
cutting it fine.
Jonathan
^ 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