* [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches
From: Bartosz Golaszewski @ 2016-12-11 22:21 UTC (permalink / raw)
To: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland
Cc: linux-iio, devicetree, linux-kernel, Kevin Hilman,
Patrick Titiano, Neil Armstrong, Linus Walleij, Alexandre Courbot,
linux-gpio, Sebastian Reichel, linux-pm, Mark Brown,
Liam Girdwood, Bartosz Golaszewski
In-Reply-To: <1481494905-18037-1-git-send-email-bgolaszewski@baylibre.com>
Some boards are equipped with simple, GPIO-driven power load switches.
An example of such ICs is the TI tps229* series.
Add device tree bindings allowing to describe them.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../bindings/power/gpio-power-switch.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/gpio-power-switch.txt
diff --git a/Documentation/devicetree/bindings/power/gpio-power-switch.txt b/Documentation/devicetree/bindings/power/gpio-power-switch.txt
new file mode 100644
index 0000000..21420ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/gpio-power-switch.txt
@@ -0,0 +1,25 @@
+GPIO Power Switch
+-----------------
+
+This is the device tree binding for simple, GPIO-driven power load switches
+that do not have any control signals.
+
+Required properties:
+
+- compatible: must be "gpio-power-switch"
+- power-gpios: phandle for the GPIO driving the power load switch
+
+Optional properties:
+
+- power-switch-name: the name of the power switch
+- power-switch-on: the power switch GPIO is driven high by default
+
+Example
+-------
+
+acme_probe0_power_switch: gpio_power_switch@0 {
+ compatible = "gpio-power-switch";
+ power-switch-name = "acme_probe0_switch";
+ power-gpios = <&pca9535 1 GPIO_ACTIVE_HIGH>;
+ power-switch-on;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] iio: GPIO power switch support
From: Bartosz Golaszewski @ 2016-12-11 22:21 UTC (permalink / raw)
To: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Kevin Hilman,
Patrick Titiano, Neil Armstrong, Linus Walleij, Alexandre Courbot,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Mark Brown, Liam Girdwood,
Bartosz Golaszewski
This series is aimed at improving the support for baylibre-acme[1]
power measurement capes.
We would like to add support for power-cycling of devices measured
using TI INA226 ADCs. An example use case would be measuring the power
consumption of a development board during boot and power-cycling it
remotely using a GPIO power switch.
The first patch proposes to add a new DT binding for describing simple
power switches.
The second adds a simple IIO driver exposing a single attribute.
The motivation for using the IIO framework is the fact that we already
use it for reading the data from the ADC and that power-cycling the
measured devices is an integral part of our use case. Users would find
it convenient to be able to use libiio as the single interface.
[1] http://baylibre.com/acme/
Bartosz Golaszewski (2):
devicetree: power: add bindings for GPIO-driven power switches
iio: misc: add support for GPIO power switches
.../bindings/power/gpio-power-switch.txt | 25 ++++
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/misc/Kconfig | 17 +++
drivers/iio/misc/Makefile | 6 +
drivers/iio/misc/gpio-power-switch.c | 127 +++++++++++++++++++++
6 files changed, 177 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/gpio-power-switch.txt
create mode 100644 drivers/iio/misc/Kconfig
create mode 100644 drivers/iio/misc/Makefile
create mode 100644 drivers/iio/misc/gpio-power-switch.c
--
2.9.3
--
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 2/2] i2c: sh_mobile: Add per-Generation fallback bindings
From: Wolfram Sang @ 2016-12-11 21:53 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfram Sang, Magnus Damm, linux-i2c, linux-renesas-soc,
devicetree
In-Reply-To: <1481107193-32502-1-git-send-email-horms+renesas@verge.net.au>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Wed, Dec 07, 2016 at 11:39:53AM +0100, Simon Horman wrote:
> Add per-Generation fallback bindings for R-Car SoCs.
>
> This is in keeping with the compatibility string scheme is being adopted
> for drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
I took the liberty to merge patch 1/2 into this one. Then, applied to
for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Wolfram Sang @ 2016-12-11 21:49 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfram Sang, Magnus Damm, linux-i2c, linux-renesas-soc,
Rob Herring, devicetree
In-Reply-To: <1481040088-22596-1-git-send-email-horms+renesas@verge.net.au>
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
On Tue, Dec 06, 2016 at 05:01:28PM +0100, Simon Horman wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme is being adopted for
> drivers for Renesas SoCs.
>
> Also:
> * Deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
> * Add some text to describe per-SoC bindings
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Changed '//' comment to '/*' comment and applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/5] i2c: Add STM32F4 I2C driver
From: Wolfram Sang @ 2016-12-11 21:42 UTC (permalink / raw)
To: M'boumba Cedric Madianga
Cc: robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1481185563-8735-3-git-send-email-cedric.madianga@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
Hi,
> +config I2C_STM32F4
> + tristate "STMicroelectronics STM32F4 I2C support"
> + depends on ARCH_STM32 || COMPILE_TEST
Double space.
> +#define STM32F4_I2C_MIN_FREQ 2
> +#define STM32F4_I2C_MAX_FREQ 42
Those two must be unsigned to fix the build error (e.g. 2U) reported by
build-bot.
Also, I get the following build warnings:
CC drivers/i2c/busses/i2c-stm32f4.o
drivers/i2c/busses/i2c-stm32f4.c: In function ‘stm32f4_i2c_handle_rx_addr’:
drivers/i2c/busses/i2c-stm32f4.c:445:6: warning: variable ‘sr2’ set but not used [-Wunused-but-set-variable]
u32 sr2;
^~~
drivers/i2c/busses/i2c-stm32f4.c: In function ‘stm32f4_i2c_isr_event’:
drivers/i2c/busses/i2c-stm32f4.c:496:41: warning: variable ‘sr2’ set but not used [-Wunused-but-set-variable]
u32 real_status, possible_status, ien, sr2;
I assume those are reads to clear the register, so we really don't need
to save the value in a variable.
Rest is looking good.
Thanks,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v10 2/2] ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset
From: Randy Li @ 2016-12-11 15:36 UTC (permalink / raw)
To: linux-usb
Cc: John.Youn, kishon, felipe.balbi, mark.rutland, devicetree, heiko,
gregkh, linux-kernel, robh+dt, randy.li, Randy Li
In-Reply-To: <1481470568-32072-1-git-send-email-ayaka@soulik.info>
The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup. We'll use the reset that's in the CRU to reset the
port when it's in a bad state.
Note that we add the reset to both dwc2 controllers even though only one
has the errata in case we find some other use for this reset that's
unrelated to the current hardware errata. Only the host port gets the
quirk property, though.
Signed-off-by: Randy Li <ayaka@soulik.info>
---
arch/arm/boot/dts/rk3288.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 4fad133..c779365 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -858,6 +858,8 @@
clocks = <&cru SCLK_OTGPHY0>;
clock-names = "phyclk";
#clock-cells = <0>;
+ resets = <&cru SRST_USBOTG_PHY>;
+ reset-names = "phy-reset";
};
usbphy1: usb-phy@334 {
@@ -874,6 +876,8 @@
clocks = <&cru SCLK_OTGPHY2>;
clock-names = "phyclk";
#clock-cells = <0>;
+ resets = <&cru SRST_USBHOST1_PHY>;
+ reset-names = "phy-reset";
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v10 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform
From: Randy Li @ 2016-12-11 15:36 UTC (permalink / raw)
To: linux-usb
Cc: John.Youn, kishon, felipe.balbi, mark.rutland, devicetree, heiko,
gregkh, linux-kernel, robh+dt, randy.li, Randy Li
In-Reply-To: <1481470568-32072-1-git-send-email-ayaka@soulik.info>
On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).
We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.
We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit) in chip, which does a more full
reset. The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).
It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.
Signed-off-by: Randy Li <ayaka@soulik.info>
Acked-by: John Youn <johnyoun@synopsys.com>
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/core_intr.c | 11 +++++++++++
drivers/usb/dwc2/platform.c | 9 +++++++++
3 files changed, 21 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e..0cd5896 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -919,6 +919,7 @@ struct dwc2_hsotg {
unsigned int ll_hw_enabled:1;
struct phy *phy;
+ struct work_struct phy_rst_work;
struct usb_phy *uphy;
struct dwc2_hsotg_plat *plat;
struct regulator_bulk_data supplies[ARRAY_SIZE(dwc2_hsotg_supply_names)];
diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 5b228ba..bf1c029 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
{
int ret;
+ struct device_node *np = hsotg->dev->of_node;
/* Clear interrupt */
dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
@@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
/* Restart the Phy Clock */
pcgcctl &= ~PCGCTL_STOPPCLK;
dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
+
+ /*
+ * It is a quirk in Rockchip RK3288, causing by
+ * a hardware bug. This will propagate out and
+ * eventually we'll re-enumerate the device.
+ * Not great but the best we can do.
+ */
+ if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
+ schedule_work(&hsotg->phy_rst_work);
+
mod_timer(&hsotg->wkp_timer,
jiffies + msecs_to_jiffies(71));
} else {
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 4fc8c60..8ef278e 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -207,6 +207,14 @@ int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
return ret;
}
+/* Only used to reset usb phy at interrupter runtime */
+static void dwc2_reset_phy_work(struct work_struct *data)
+{
+ struct dwc2_hsotg *hsotg = container_of(data, struct dwc2_hsotg,
+ phy_rst_work);
+ phy_reset(hsotg->phy);
+}
+
static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
{
int i, ret;
@@ -251,6 +259,7 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
return ret;
}
}
+ INIT_WORK(&hsotg->phy_rst_work, dwc2_reset_phy_work);
if (!hsotg->phy) {
hsotg->uphy = devm_usb_get_phy(hsotg->dev, USB_PHY_TYPE_USB2);
--
2.7.4
^ permalink raw reply related
* [PATCH v10 0/2] the fixup for the USB HOST1 at rk3288 platform
From: Randy Li @ 2016-12-11 15:36 UTC (permalink / raw)
To: linux-usb
Cc: John.Youn, kishon, felipe.balbi, mark.rutland, devicetree, heiko,
gregkh, linux-kernel, robh+dt, randy.li, Randy Li
changelog:
v10
minior fixup
v9
use a work_queue to reset usb phy to prevent access mutex lock at interrupter
runtime.
v8
minior fixup
v7
add the forgot dummy phy_reset() for the generic phy is disabled.
v7
Some minor fixup
v6
Send the last two patches
v5
A few modification at style, add the missing doc in the last
commit.
v4
1. Adding the reset callback in struct phy_ops.
2. Moving the reset into phy rockchip usb.
3. Trying to call a reset when dwc2 wakeup in rk3288.
v3
Rebased from previous commit
v2
Rebased from previous commit
v1
orignal from google
Randy Li (2):
usb: dwc2: assert phy reset when waking up in rk3288 platform
ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset
arch/arm/boot/dts/rk3288.dtsi | 4 ++++
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/core_intr.c | 11 +++++++++++
drivers/usb/dwc2/platform.c | 9 +++++++++
4 files changed, 25 insertions(+)
--
2.7.4
^ permalink raw reply
* Re: [RFC PATCH 2/2] ARM: i.MX: dts: add fsl, imx25-wdt compatible to all relevant watchdog nodes
From: Uwe Kleine-König @ 2016-12-11 9:40 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Wim Van Sebroeck,
Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sascha Hauer, Fabio Estevam, Shawn Guo, Guenter Roeck
In-Reply-To: <20160926062759.3eoezyezog6clz6x-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hello,
On Mon, Sep 26, 2016 at 08:27:59AM +0200, Uwe Kleine-König wrote:
> On Mon, Sep 26, 2016 at 03:39:21AM +0300, Vladimir Zapolskiy wrote:
> > Watchdog device controller found on all modern SoCs from i.MX series
> > and firstly introduced in i.MX25 is not one in one compatible with the
> > watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
> > controlles don't have WICR (and pretimeout notification support) and
> > WMCR registers. To get benefit from the more advanced watchdog device
> > and to avoid operations over non-existing registers on legacy SoCs add
> > fsl,imx25-wdt compatible to descriptions of all i.MX25 compatible
> > watchdog controllers.
> >
> > Signed-off-by: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org>
> > ---
> > arch/arm/boot/dts/imx35.dtsi | 3 ++-
> > arch/arm/boot/dts/imx50.dtsi | 3 ++-
> > arch/arm/boot/dts/imx51.dtsi | 6 ++++--
> > arch/arm/boot/dts/imx53.dtsi | 6 ++++--
> > arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++--
> > arch/arm/boot/dts/imx6sl.dtsi | 6 ++++--
> > arch/arm/boot/dts/imx6sx.dtsi | 9 ++++++---
> > arch/arm/boot/dts/imx6ul.dtsi | 6 ++++--
> > arch/arm/boot/dts/imx7s.dtsi | 12 ++++++++----
> > arch/arm/boot/dts/ls1021a.dtsi | 2 +-
> > arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
> > 11 files changed, 41 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
> > index 490b7b4..8fd4482 100644
> > --- a/arch/arm/boot/dts/imx35.dtsi
> > +++ b/arch/arm/boot/dts/imx35.dtsi
> > @@ -284,7 +284,8 @@
> > };
> >
> > wdog: wdog@53fdc000 {
> > - compatible = "fsl,imx35-wdt", "fsl,imx21-wdt";
> > + compatible = "fsl,imx35-wdt", "fsl,imx25-wdt",
> > + "fsl,imx21-wdt";
>
> When this is used on an old kernel that doesn't know about fsl,imx25-wdt
> this picks up the imx21 driver logic. As this is wrong I think you
> should drop imx21-wdt here. Can one of the dt-people comfirm?
I forgot in the mail at the other end of this thread that the dti were
already addressed. I (implicitly) wrote there that fsl,imx35-wdt should
be the new compatible describing the wdt with misc register. Picking
imx25 (as you did) works, too, but e.g. the CSPI device has
compatible = "fsl,imx25-cspi", "fsl,imx35-cspi";
on the i.MX25 and
compatible = "fsl,imx35-cspi";
on the i.MX35. So I think we should pick i.MX35 here, too, as the one
giving its name.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Input: imx6ul_tsc - generalize the averaging property
From: Guy Shapiro @ 2016-12-11 7:06 UTC (permalink / raw)
To: dmitry.torokhov, robh
Cc: fabio.estevam, mark.rutland, Guy Shapiro, devicetree, haibo.chen,
linux-input, linux-arm-kernel
Make the avarage-samples property a general touchscreen property
rather than imx6ul device specific.
Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
---
.../bindings/input/touchscreen/imx6ul_tsc.txt | 11 ++----
.../bindings/input/touchscreen/touchscreen.txt | 3 ++
drivers/input/touchscreen/imx6ul_tsc.c | 46 ++++++++++++++++------
3 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
index a66069f..d4927c2 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
@@ -17,13 +17,8 @@ Optional properties:
This value depends on the touch screen.
- pre-charge-time: the touch screen need some time to precharge.
This value depends on the touch screen.
-- average-samples: Number of data samples which are averaged for each read.
- Valid values 0-4
- 0 = 1 sample
- 1 = 4 samples
- 2 = 8 samples
- 3 = 16 samples
- 4 = 32 samples
+- touchscreen-average-samples: Number of data samples which are averaged for
+ each read. Valid values are 1, 4, 8, 16 and 32.
Example:
tsc: tsc@02040000 {
@@ -39,6 +34,6 @@ Example:
xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
measure-delay-time = <0xfff>;
pre-charge-time = <0xffff>;
- average-samples = <4>;
+ touchscreen-average-samples = <32>;
status = "okay";
};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
index bccaa4e..537643e 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
@@ -14,6 +14,9 @@ Optional properties for Touchscreens:
- touchscreen-fuzz-pressure : pressure noise value of the absolute input
device (arbitrary range dependent on the
controller)
+ - touchscreen-average-samples : Number of data samples which are averaged
+ for each read (valid values dependent on the
+ controller)
- touchscreen-inverted-x : X axis is inverted (boolean)
- touchscreen-inverted-y : Y axis is inverted (boolean)
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
diff --git a/drivers/input/touchscreen/imx6ul_tsc.c b/drivers/input/touchscreen/imx6ul_tsc.c
index d2a3912..58d1aa5 100644
--- a/drivers/input/touchscreen/imx6ul_tsc.c
+++ b/drivers/input/touchscreen/imx6ul_tsc.c
@@ -93,7 +93,8 @@ struct imx6ul_tsc {
u32 measure_delay_time;
u32 pre_charge_time;
- u32 average_samples;
+ bool average_enable;
+ u32 average_select;
struct completion completion;
};
@@ -117,9 +118,9 @@ static int imx6ul_adc_init(struct imx6ul_tsc *tsc)
adc_cfg |= ADC_12BIT_MODE | ADC_IPG_CLK;
adc_cfg &= ~(ADC_CLK_DIV_MASK | ADC_SAMPLE_MODE_MASK);
adc_cfg |= ADC_CLK_DIV_8 | ADC_SHORT_SAMPLE_MODE;
- if (tsc->average_samples) {
+ if (tsc->average_enable) {
adc_cfg &= ~ADC_AVGS_MASK;
- adc_cfg |= (tsc->average_samples - 1) << ADC_AVGS_SHIFT;
+ adc_cfg |= (tsc->average_select) << ADC_AVGS_SHIFT;
}
adc_cfg &= ~ADC_HARDWARE_TRIGGER;
writel(adc_cfg, tsc->adc_regs + REG_ADC_CFG);
@@ -132,7 +133,7 @@ static int imx6ul_adc_init(struct imx6ul_tsc *tsc)
/* start ADC calibration */
adc_gc = readl(tsc->adc_regs + REG_ADC_GC);
adc_gc |= ADC_CAL;
- if (tsc->average_samples)
+ if (tsc->average_enable)
adc_gc |= ADC_AVGE;
writel(adc_gc, tsc->adc_regs + REG_ADC_GC);
@@ -362,6 +363,7 @@ static int imx6ul_tsc_probe(struct platform_device *pdev)
int err;
int tsc_irq;
int adc_irq;
+ u32 average_samples;
tsc = devm_kzalloc(&pdev->dev, sizeof(*tsc), GFP_KERNEL);
if (!tsc)
@@ -466,14 +468,36 @@ static int imx6ul_tsc_probe(struct platform_device *pdev)
if (err)
tsc->pre_charge_time = 0xfff;
- err = of_property_read_u32(np, "average-samples",
- &tsc->average_samples);
+ err = of_property_read_u32(np, "touchscreen-average-samples",
+ &average_samples);
if (err)
- tsc->average_samples = 0;
-
- if (tsc->average_samples > 4) {
- dev_err(&pdev->dev, "average-samples (%u) must be [0-4]\n",
- tsc->average_samples);
+ average_samples = 1;
+
+ switch (average_samples) {
+ case 1:
+ tsc->average_enable = false;
+ tsc->average_select = 0; /* value unused; initialize anyway */
+ break;
+ case 4:
+ tsc->average_enable = true;
+ tsc->average_select = 0;
+ break;
+ case 8:
+ tsc->average_enable = true;
+ tsc->average_select = 1;
+ break;
+ case 16:
+ tsc->average_enable = true;
+ tsc->average_select = 2;
+ break;
+ case 32:
+ tsc->average_enable = true;
+ tsc->average_select = 3;
+ break;
+ default:
+ dev_err(&pdev->dev,
+ "touchscreen-average-samples (%u) must be 1, 4, 8, 16 or 32\n",
+ average_samples);
return -EINVAL;
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v5 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: kbuild test robot @ 2016-12-11 6:13 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, Alan Tull, Moritz Fischer, Mark Rutland,
Russell King, Rob Herring, Anatolij Gustschin, Joshua Clayton,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1778a82d1989d13919b24e47fa09eeb56b2cb8e5.1481139171.git.stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]
Hi Joshua,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc8]
[cannot apply to next-20161209]
[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/Joshua-Clayton/lib-add-bitrev8x4/20161208-070638
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
In file included from drivers/fpga/cyclone-ps-spi.c:13:0:
drivers/fpga/cyclone-ps-spi.c: In function 'rev_buf':
>> include/linux/bitrev.h:12:21: error: implicit declaration of function '__arch_bitrev8x4' [-Werror=implicit-function-declaration]
#define __bitrev8x4 __arch_bitrev8x4
^
include/linux/bitrev.h:101:2: note: in expansion of macro '__bitrev8x4'
__bitrev8x4(__x); \
^~~~~~~~~~~
drivers/fpga/cyclone-ps-spi.c:84:11: note: in expansion of macro 'bitrev8x4'
*fw32 = bitrev8x4(*fw32);
^~~~~~~~~
In file included from include/linux/delay.h:10:0,
from drivers/fpga/cyclone-ps-spi.c:14:
drivers/fpga/cyclone-ps-spi.c: In function 'cyclonespi_write':
include/linux/kernel.h:739:16: warning: comparison of distinct pointer types lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:742:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^~~~~
drivers/fpga/cyclone-ps-spi.c:98:19: note: in expansion of macro 'min'
size_t stride = min(fw_data_end - fw_data, SZ_4K);
^~~
cc1: some warnings being treated as errors
vim +/__arch_bitrev8x4 +12 include/linux/bitrev.h
556d2f05 Yalin Wang 2014-11-03 6 #ifdef CONFIG_HAVE_ARCH_BITREVERSE
556d2f05 Yalin Wang 2014-11-03 7 #include <asm/bitrev.h>
556d2f05 Yalin Wang 2014-11-03 8
556d2f05 Yalin Wang 2014-11-03 9 #define __bitrev32 __arch_bitrev32
556d2f05 Yalin Wang 2014-11-03 10 #define __bitrev16 __arch_bitrev16
556d2f05 Yalin Wang 2014-11-03 11 #define __bitrev8 __arch_bitrev8
533d0eab Joshua Clayton 2016-12-07 @12 #define __bitrev8x4 __arch_bitrev8x4
a5cfc1ec Akinobu Mita 2006-12-08 13
556d2f05 Yalin Wang 2014-11-03 14 #else
556d2f05 Yalin Wang 2014-11-03 15 extern u8 const byte_rev_table[256];
:::::: The code at line 12 was first introduced by commit
:::::: 533d0eabff8f37edfdec7fdf6e705fdecb297daa lib: add bitrev8x4()
:::::: TO: Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
:::::: CC: 0day robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
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: 52456 bytes --]
^ permalink raw reply
* Courier was not able to deliver your parcel (ID000422883, FedEx)
From: FedEx Priority Delivery @ 2016-12-11 4:59 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 176 bytes --]
Dear Devi,
We can not deliver your parcel arrived at December 09.
Please check the attachment for complete details!
With many thanks,
Joel Price,
Parcels Delivery Manager.
[-- Attachment #2: Undelivered-Package-000422883.zip --]
[-- Type: application/zip, Size: 3000 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.
From: kbuild test robot @ 2016-12-11 0:14 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, Herbert Xu, David S. Miller, Rob Herring,
Mark Rutland, linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ray Jui, Scott Branden,
Jon Mason, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
Catalin Marinas, Will Deacon,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Steve Lin,
Rob Rice
In-Reply-To: <1480536453-24781-4-git-send-email-rob.rice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
Hi Rob,
[auto build test ERROR on cryptodev/master]
[also build test ERROR on v4.9-rc8]
[cannot apply to next-20161209]
[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/Rob-Rice/crypto-brcm-DT-documentation-for-Broadcom-SPU-driver/20161202-010038
base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> ERROR: Input tree has errors, aborting (use -f to force output)
---
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: 31957 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/5] i2c: designware: Add slave mode as separated driver
From: kbuild test robot @ 2016-12-10 23:44 UTC (permalink / raw)
Cc: kbuild-all, wsa, robh+dt, mark.rutland, jarkko.nikula,
andriy.shevchenko, mika.westerberg, linux-i2c, devicetree,
linux-kernel, Luis.Oliveira, Ramiro.Oliveira, Joao.Pinto,
CARLOS.PALMINHA
In-Reply-To: <a7ca5014ad1c3f4905349a02ebe5294fe64c318e.1481131072.git.lolivei@synopsys.com>
[-- Attachment #1: Type: text/plain, Size: 6820 bytes --]
Hi Luis,
[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on next-20161209]
[cannot apply to v4.9-rc8]
[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/Luis-Oliveira/i2c-designware-Refactoring-of-the-i2c-designware/20161208-044045
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: i386-randconfig-c0-12110449 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/i2c/busses/i2c-designware-slave.c: In function 'i2c_dw_irq_handler_slave':
>> drivers/i2c/busses/i2c-designware-slave.c:294:3: error: implicit declaration of function 'i2c_slave_event' [-Werror=implicit-function-declaration]
i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
^
>> drivers/i2c/busses/i2c-designware-slave.c:294:31: error: 'I2C_SLAVE_WRITE_REQUESTED' undeclared (first use in this function)
i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
^
drivers/i2c/busses/i2c-designware-slave.c:294:31: note: each undeclared identifier is reported only once for each function it appears in
In file included from include/linux/err.h:4:0,
from drivers/i2c/busses/i2c-designware-slave.c:26:
>> drivers/i2c/busses/i2c-designware-slave.c:301:6: error: 'I2C_SLAVE_WRITE_RECEIVED' undeclared (first use in this function)
I2C_SLAVE_WRITE_RECEIVED, &val)) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^
drivers/i2c/busses/i2c-designware-slave.c:300:5: note: in expansion of macro 'if'
if (!i2c_slave_event(dev->slave,
^
>> drivers/i2c/busses/i2c-designware-slave.c:313:7: error: 'I2C_SLAVE_READ_REQUESTED' undeclared (first use in this function)
I2C_SLAVE_READ_REQUESTED, &val))
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^
drivers/i2c/busses/i2c-designware-slave.c:312:4: note: in expansion of macro 'if'
if (!i2c_slave_event(dev->slave,
^
>> drivers/i2c/busses/i2c-designware-slave.c:319:36: error: 'I2C_SLAVE_READ_PROCESSED' undeclared (first use in this function)
if (!i2c_slave_event(dev->slave, I2C_SLAVE_READ_PROCESSED,
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^
drivers/i2c/busses/i2c-designware-slave.c:319:3: note: in expansion of macro 'if'
if (!i2c_slave_event(dev->slave, I2C_SLAVE_READ_PROCESSED,
^
>> drivers/i2c/busses/i2c-designware-slave.c:323:31: error: 'I2C_SLAVE_STOP' undeclared (first use in this function)
i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
^
drivers/i2c/busses/i2c-designware-slave.c: At top level:
>> drivers/i2c/busses/i2c-designware-slave.c:358:2: error: unknown field 'reg_slave' specified in initializer
.reg_slave = i2c_dw_reg_slave,
^
drivers/i2c/busses/i2c-designware-slave.c:358:2: warning: excess elements in struct initializer
drivers/i2c/busses/i2c-designware-slave.c:358:2: warning: (near initialization for 'i2c_dw_algo')
>> drivers/i2c/busses/i2c-designware-slave.c:359:2: error: unknown field 'unreg_slave' specified in initializer
.unreg_slave = i2c_dw_unreg_slave,
^
drivers/i2c/busses/i2c-designware-slave.c:359:2: warning: excess elements in struct initializer
drivers/i2c/busses/i2c-designware-slave.c:359:2: warning: (near initialization for 'i2c_dw_algo')
cc1: some warnings being treated as errors
vim +/i2c_slave_event +294 drivers/i2c/busses/i2c-designware-slave.c
288 dw_readl(dev, DW_IC_CLR_START_DET);
289 if (stat & DW_IC_INTR_ACTIVITY)
290 dw_readl(dev, DW_IC_CLR_ACTIVITY);
291 if (stat & DW_IC_INTR_RX_OVER)
292 dw_readl(dev, DW_IC_CLR_RX_OVER);
293 if ((stat & DW_IC_INTR_RX_FULL) && (stat & DW_IC_INTR_STOP_DET))
> 294 i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
295
296 if (slave_activity) {
297 if (stat & DW_IC_INTR_RD_REQ) {
298 if (stat & DW_IC_INTR_RX_FULL) {
299 val = dw_readl(dev, DW_IC_DATA_CMD);
300 if (!i2c_slave_event(dev->slave,
> 301 I2C_SLAVE_WRITE_RECEIVED, &val)) {
302 dev_dbg(dev->dev, "Byte %X acked!",
303 val);
304 }
305 dw_readl(dev, DW_IC_CLR_RD_REQ);
306 stat = i2c_dw_read_clear_intrbits_slave(dev);
307 } else {
308 dw_readl(dev, DW_IC_CLR_RD_REQ);
309 dw_readl(dev, DW_IC_CLR_RX_UNDER);
310 stat = i2c_dw_read_clear_intrbits_slave(dev);
311 }
312 if (!i2c_slave_event(dev->slave,
> 313 I2C_SLAVE_READ_REQUESTED, &val))
314 dw_writel(dev, val, DW_IC_DATA_CMD);
315 }
316 }
317
318 if (stat & DW_IC_INTR_RX_DONE) {
> 319 if (!i2c_slave_event(dev->slave, I2C_SLAVE_READ_PROCESSED,
320 &val))
321 dw_readl(dev, DW_IC_CLR_RX_DONE);
322
> 323 i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
324 stat = i2c_dw_read_clear_intrbits_slave(dev);
325 return true;
326 }
327
328 if (stat & DW_IC_INTR_RX_FULL) {
329 val = dw_readl(dev, DW_IC_DATA_CMD);
330 if (!i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_RECEIVED,
331 &val))
332 dev_dbg(dev->dev, "Byte %X acked!", val);
333 } else {
334 i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
335 stat = i2c_dw_read_clear_intrbits_slave(dev);
336 }
337
338 if (stat & DW_IC_INTR_TX_OVER)
339 dw_readl(dev, DW_IC_CLR_TX_OVER);
340
341 return true;
342 }
343
344 static irqreturn_t i2c_dw_isr_slave(int this_irq, void *dev_id)
345 {
346 struct dw_i2c_dev *dev = dev_id;
347
348 i2c_dw_read_clear_intrbits_slave(dev);
349 if (!i2c_dw_irq_handler_slave(dev))
350 return IRQ_NONE;
351
352 complete(&dev->cmd_complete);
353 return IRQ_HANDLED;
354 }
355
356 static struct i2c_algorithm i2c_dw_algo = {
357 .functionality = i2c_dw_func,
> 358 .reg_slave = i2c_dw_reg_slave,
> 359 .unreg_slave = i2c_dw_unreg_slave,
360 };
361
362 void i2c_dw_disable_slave(struct dw_i2c_dev *dev)
---
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: 31719 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 1/2] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Vladimir Zapolskiy @ 2016-12-10 22:37 UTC (permalink / raw)
To: Magnus Lilja, Guenter Roeck
Cc: Shawn Guo, Wim Van Sebroeck, Rob Herring, Fabio Estevam,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAM=E1R6hzob5ZzyTLmrLL5s-6=vbZQbCig1sLHMSLChJEz9YgA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Magnus,
On 12/10/2016 09:28 PM, Magnus Lilja wrote:
> Hi,
>
> On 26 September 2016 at 15:02, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote:
>> On 09/25/2016 05:39 PM, Vladimir Zapolskiy wrote:
>>>
>>> Power down counter enable/disable bit switch is located in WMCR
>>> register, but watchdog controllers found on legacy i.MX21, i.MX27 and
>>> i.MX31 SoCs don't have this register. As a result of writing data to
>>> the non-existing register on driver probe the SoC hangs up, to fix the
>>> problem add more OF compatible strings and on this basis get
>>> information about availability of the WMCR register.
>>>
>>> Fixes: 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on
>>> boot")
>>> Signed-off-by: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org>
>>> ---
[snip]
>
> Has this patch (or an updated one) been merged in any tree? I've
> tested it on a i.MX31 board with positive result.
>
no, it's not in the linux-watchdog repository at the moment, I'm going
to fix Guenter's review comments and send the change today or tomorrow
in hope that it enters v4.10.
Thank you for testing, for your information I'm on the way to send more
i.MX31 changes to get better i.MX31 device tree support.
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 1/2] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Guenter Roeck @ 2016-12-10 20:14 UTC (permalink / raw)
To: Magnus Lilja
Cc: Vladimir Zapolskiy, Shawn Guo, Wim Van Sebroeck, Rob Herring,
Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAM=E1R6hzob5ZzyTLmrLL5s-6=vbZQbCig1sLHMSLChJEz9YgA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/10/2016 11:28 AM, Magnus Lilja wrote:
> Hi,
>
> On 26 September 2016 at 15:02, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote:
>> On 09/25/2016 05:39 PM, Vladimir Zapolskiy wrote:
>>>
>>> Power down counter enable/disable bit switch is located in WMCR
>>> register, but watchdog controllers found on legacy i.MX21, i.MX27 and
>>> i.MX31 SoCs don't have this register. As a result of writing data to
>>> the non-existing register on driver probe the SoC hangs up, to fix the
>>> problem add more OF compatible strings and on this basis get
>>> information about availability of the WMCR register.
>>>
>>> Fixes: 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on
>>> boot")
>>> Signed-off-by: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org>
>>> ---
>>> drivers/watchdog/imx2_wdt.c | 47
>>> +++++++++++++++++++++++++++++++++++++++++++--
>>> 1 file changed, 45 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
>>> index 62f346b..b6763e0 100644
>>> --- a/drivers/watchdog/imx2_wdt.c
>>> +++ b/drivers/watchdog/imx2_wdt.c
>>> @@ -29,6 +29,7 @@
>>> #include <linux/module.h>
>>> #include <linux/moduleparam.h>
>>> #include <linux/of_address.h>
>>> +#include <linux/of_device.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/regmap.h>
>>> #include <linux/watchdog.h>
>>> @@ -57,6 +58,10 @@
>>>
>>> #define WDOG_SEC_TO_COUNT(s) ((s * 2 - 1) << 8)
>>>
>>> +struct imx2_wdt_data {
>>> + bool has_pdc;
>>> +};
>>> +
>>> struct imx2_wdt_device {
>>> struct clk *clk;
>>> struct regmap *regmap;
>>> @@ -64,6 +69,8 @@ struct imx2_wdt_device {
>>> bool ext_reset;
>>> };
>>>
>>> +static const struct of_device_id imx2_wdt_dt_ids[];
>>> +
>>> static bool nowayout = WATCHDOG_NOWAYOUT;
>>> module_param(nowayout, bool, 0);
>>> MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
>>> (default="
>>> @@ -200,10 +207,13 @@ static const struct regmap_config
>>> imx2_wdt_regmap_config = {
>>>
>>> static int __init imx2_wdt_probe(struct platform_device *pdev)
>>> {
>>> + const struct of_device_id *of_id;
>>> + const struct imx2_wdt_data *data;
>>> struct imx2_wdt_device *wdev;
>>> struct watchdog_device *wdog;
>>> struct resource *res;
>>> void __iomem *base;
>>> + bool has_pdc;
>>> int ret;
>>> u32 val;
>>>
>>> @@ -261,12 +271,24 @@ static int __init imx2_wdt_probe(struct
>>> platform_device *pdev)
>>> set_bit(WDOG_HW_RUNNING, &wdog->status);
>>> }
>>>
>>> + if (pdev->dev.of_node) {
>>> + of_id = of_match_device(imx2_wdt_dt_ids, &pdev->dev);
>>> + if (!of_id)
>>> + return -ENODEV;
>>> +
>>> + data = of_id->data;
>>> + has_pdc = data->has_pdc;
>>> + } else {
>>> + has_pdc = false;
>>> + }
>>> +
>>> /*
>>> * Disable the watchdog power down counter at boot. Otherwise the
>>> power
>>> * down counter will pull down the #WDOG interrupt line for one
>>> clock
>>> * cycle.
>>> */
>>> - regmap_write(wdev->regmap, IMX2_WDT_WMCR, 0);
>>> + if (has_pdc)
>>> + regmap_write(wdev->regmap, IMX2_WDT_WMCR, 0);
>>>
>>> ret = watchdog_register_device(wdog);
>>> if (ret) {
>>> @@ -363,8 +385,29 @@ static int imx2_wdt_resume(struct device *dev)
>>> static SIMPLE_DEV_PM_OPS(imx2_wdt_pm_ops, imx2_wdt_suspend,
>>> imx2_wdt_resume);
>>>
>>> +static const struct imx2_wdt_data imx21_wdt_data = {
>>> + .has_pdc = false,
>>> +};
>>> +
>>> +static const struct imx2_wdt_data imx25_wdt_data = {
>>> + .has_pdc = true,
>>> +};
>>> +
>>> static const struct of_device_id imx2_wdt_dt_ids[] = {
>>> - { .compatible = "fsl,imx21-wdt", },
>>> + { .compatible = "fsl,imx21-wdt", .data = &imx21_wdt_data },
>>
>>
>> Please just specify the flag directly, as in
>> .data = (void *) true
>> or, if you prefer, use defines.
>> .data = (void *) IMX_SUPPORTS_PDC
>>
>> Then, in above code:
>> has_pdc = (bool) of_id->data;
>>
>> Guenter
>
> Has this patch (or an updated one) been merged in any tree? I've
> tested it on a i.MX31 board with positive result.
>
I had asked for a change, and I don't recall seeing v2. So, at least as far
as I know, the answer is no.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 1/2] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Magnus Lilja @ 2016-12-10 19:28 UTC (permalink / raw)
To: Guenter Roeck
Cc: Vladimir Zapolskiy, Shawn Guo, Wim Van Sebroeck, Rob Herring,
Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <ebece25b-7a3b-3fdf-d117-dd0a3a2975b7-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
Hi,
On 26 September 2016 at 15:02, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote:
> On 09/25/2016 05:39 PM, Vladimir Zapolskiy wrote:
>>
>> Power down counter enable/disable bit switch is located in WMCR
>> register, but watchdog controllers found on legacy i.MX21, i.MX27 and
>> i.MX31 SoCs don't have this register. As a result of writing data to
>> the non-existing register on driver probe the SoC hangs up, to fix the
>> problem add more OF compatible strings and on this basis get
>> information about availability of the WMCR register.
>>
>> Fixes: 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on
>> boot")
>> Signed-off-by: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org>
>> ---
>> drivers/watchdog/imx2_wdt.c | 47
>> +++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 45 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
>> index 62f346b..b6763e0 100644
>> --- a/drivers/watchdog/imx2_wdt.c
>> +++ b/drivers/watchdog/imx2_wdt.c
>> @@ -29,6 +29,7 @@
>> #include <linux/module.h>
>> #include <linux/moduleparam.h>
>> #include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> #include <linux/platform_device.h>
>> #include <linux/regmap.h>
>> #include <linux/watchdog.h>
>> @@ -57,6 +58,10 @@
>>
>> #define WDOG_SEC_TO_COUNT(s) ((s * 2 - 1) << 8)
>>
>> +struct imx2_wdt_data {
>> + bool has_pdc;
>> +};
>> +
>> struct imx2_wdt_device {
>> struct clk *clk;
>> struct regmap *regmap;
>> @@ -64,6 +69,8 @@ struct imx2_wdt_device {
>> bool ext_reset;
>> };
>>
>> +static const struct of_device_id imx2_wdt_dt_ids[];
>> +
>> static bool nowayout = WATCHDOG_NOWAYOUT;
>> module_param(nowayout, bool, 0);
>> MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
>> (default="
>> @@ -200,10 +207,13 @@ static const struct regmap_config
>> imx2_wdt_regmap_config = {
>>
>> static int __init imx2_wdt_probe(struct platform_device *pdev)
>> {
>> + const struct of_device_id *of_id;
>> + const struct imx2_wdt_data *data;
>> struct imx2_wdt_device *wdev;
>> struct watchdog_device *wdog;
>> struct resource *res;
>> void __iomem *base;
>> + bool has_pdc;
>> int ret;
>> u32 val;
>>
>> @@ -261,12 +271,24 @@ static int __init imx2_wdt_probe(struct
>> platform_device *pdev)
>> set_bit(WDOG_HW_RUNNING, &wdog->status);
>> }
>>
>> + if (pdev->dev.of_node) {
>> + of_id = of_match_device(imx2_wdt_dt_ids, &pdev->dev);
>> + if (!of_id)
>> + return -ENODEV;
>> +
>> + data = of_id->data;
>> + has_pdc = data->has_pdc;
>> + } else {
>> + has_pdc = false;
>> + }
>> +
>> /*
>> * Disable the watchdog power down counter at boot. Otherwise the
>> power
>> * down counter will pull down the #WDOG interrupt line for one
>> clock
>> * cycle.
>> */
>> - regmap_write(wdev->regmap, IMX2_WDT_WMCR, 0);
>> + if (has_pdc)
>> + regmap_write(wdev->regmap, IMX2_WDT_WMCR, 0);
>>
>> ret = watchdog_register_device(wdog);
>> if (ret) {
>> @@ -363,8 +385,29 @@ static int imx2_wdt_resume(struct device *dev)
>> static SIMPLE_DEV_PM_OPS(imx2_wdt_pm_ops, imx2_wdt_suspend,
>> imx2_wdt_resume);
>>
>> +static const struct imx2_wdt_data imx21_wdt_data = {
>> + .has_pdc = false,
>> +};
>> +
>> +static const struct imx2_wdt_data imx25_wdt_data = {
>> + .has_pdc = true,
>> +};
>> +
>> static const struct of_device_id imx2_wdt_dt_ids[] = {
>> - { .compatible = "fsl,imx21-wdt", },
>> + { .compatible = "fsl,imx21-wdt", .data = &imx21_wdt_data },
>
>
> Please just specify the flag directly, as in
> .data = (void *) true
> or, if you prefer, use defines.
> .data = (void *) IMX_SUPPORTS_PDC
>
> Then, in above code:
> has_pdc = (bool) of_id->data;
>
> Guenter
Has this patch (or an updated one) been merged in any tree? I've
tested it on a i.MX31 board with positive result.
Regards, Magnus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/5] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Marek Vasut @ 2016-12-10 19:08 UTC (permalink / raw)
To: Cédric Le Goater, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Joel Stanley
In-Reply-To: <f0ad683a-0989-e1ae-b33b-9746260ffa0e-Bxea+6Xhats@public.gmane.org>
On 12/10/2016 06:34 PM, Cédric Le Goater wrote:
> Hello,
Hi!
> On 12/10/2016 05:01 AM, Marek Vasut wrote:
>> On 12/09/2016 05:49 PM, Cédric Le Goater wrote:
>>
>> [...]
>>
>>
>>> +static int aspeed_smc_read_from_ahb(void *buf, const void __iomem *src,
>>> + size_t len)
>>> +{
>>> + if (IS_ALIGNED((u32)src, sizeof(u32)) &&
>>> + IS_ALIGNED((u32)buf, sizeof(u32)) &&
>>> + IS_ALIGNED(len, sizeof(u32))) {
>>
>> Did you try compiling this on any 64bit system ?
>
> I cross compile the kernel on a 64bit host and then upload on the
> target. What kind of problem are you forseeing ?
Something about the pointer being clipped to 4 bytes, I'd rather use
uintptr_t cast instead of u32 . I don't think it matters for this check,
but just to be extra precise ...
>>
>>> + while (len > 3) {
>>> + *(u32 *)buf = readl(src);
[...]
>>> +/*
>>> + * Segment Address Registers. Start and end addresses are encoded
>>> + * using 8MB units
>>> + */
>>> +#define SEGMENT_ADDR_REG0 0x30
>>> +#define SEGMENT_ADDR_START(_r) ((((_r) >> 16) & 0xFF) << 23)
>>
>> is that ((r) & 0xff0000) << 7 ?
>>
>>> +#define SEGMENT_ADDR_END(_r) ((((_r) >> 24) & 0xFF) << 23)
>>
>> ((r) & 0xff000000) >> 1 ?
>
> yes.
>
> I rather keep the initial macros though, which I found easier to
> understand.
>
> The Segment Register uses a 8MB unit to encode the start address
> and the end address of the mapping window of a flash SPI slave :
>
> | byte 1 | byte 2 | byte 3 | byte 4 |
> +--------+--------+--------+--------+
> | end | start | 0 | 0 |
Then the above should be in the comment , it's a good explanation :)
Thanks!
--
Best regards,
Marek Vasut
--
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 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings
From: Jonathan Cameron @ 2016-12-10 18:21 UTC (permalink / raw)
To: Peter Rosin, Rob Herring
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Mark Rutland,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <ea58cfe1-88ed-f215-59df-e9ffba485eaa-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 06/12/16 09:18, Peter Rosin wrote:
> On 2016-12-06 00:26, Rob Herring wrote:
>> On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote:
>>> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>>> ---
>>> .../bindings/iio/multiplexer/iio-mux.txt | 40 ++++++++++++++++++++++
>>> MAINTAINERS | 6 ++++
>>> 2 files changed, 46 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>>
>> I'm still not convinced about this binding, but don't really have more
>> comments ATM. Sending 6 versions in 2 weeks or so doesn't really help
>> either.
>
> Sorry about the noise, I'll try to be more careful going forward. On
> the flip side, I haven't touched the code since v6.
>
> I don't see how bindings that are as flexible as the current (and
> original) phandle link between the mux consumer and the mux controller
> would look, and at the same time be simpler to understand. You need
> to be able to refer to a mux controller from several mux consumers, and
> you need to support several mux controllers in one node (the ADG792A
> case). And, AFAICT, the complex case wasn't really the problem, it was
> that it is overly complex to describe the simple case of one mux
> consumer and one mux controller. But in your comment for v2 [1] you
> said that I was working around limitations with shared GPIO pins. But
> solving that in the GPIO subsystem would not solve all that the
> phandle approach is solving, since you would not have support for
> ADG792A (or other non-GPIO controlled muxes). So, I think listing
> the gpio pins inside the mux consumer node is a non-starter, the mux
> controller has to live in its own node with its own compatible.
>
> Would you be happier if I managed to marry the phandle approach with
> the option of having the mux controller as a child node of the mux
> consumer for the simple case?
>
> I added an example at the end of this message (the same as the first
> example in v4 [2], at least in principle) for easy comparison between
> the phandle and the controller-in-child-node approaches. I can't say
> that I personally find the difference all that significant, and do not
> think it is worth it. As I see it, the "simple option" would just muddy
> the waters...
>
> [1] http://marc.info/?l=linux-kernel&m=147948334204795&w=2
> [2] http://marc.info/?l=linux-kernel&m=148001364904240&w=2
>
>>> diff --git a/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>>> new file mode 100644
>>> index 000000000000..8080cf790d82
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>>> @@ -0,0 +1,40 @@
>>> +IIO multiplexer bindings
>>> +
>>> +If a multiplexer is used to select which hardware signal is fed to
>>> +e.g. an ADC channel, these bindings describe that situation.
>>> +
>>> +Required properties:
>>> +- compatible : "iio-mux"
>>
>> This is a Linuxism. perhaps "adc-mux".
>
> No, that's not general enough, it could just as well be used to mux a
> temperature sensor. Or whatever. Hmmm, given that "iio-mux" is bad, perhaps
> "io-channel-mux" is better? That matches the io-channels property used to
> refer to the parent channel.
analog-mux maybe? Makes more sense out of context (though with io-channels defined on
the next line you have plenty of context here ;)
>
>>> +- io-channels : Channel node of the parent channel that has multiplexed
>>> + input.
>>> +- io-channel-names : Should be "parent".
>>> +- #address-cells = <1>;
>>> +- #size-cells = <0>;
>>> +- mux-controls : Mux controller node to use for operating the mux
>>> +- channels : List of strings, labeling the mux controller states.
>>> +
>>> +The multiplexer state as described in ../misc/mux-controller.txt
>>> +
>>> +For each non-empty string in the channels property, an iio channel will
>>> +be created. The number of this iio channel is the same as the index into
>>> +the list of strings in the channels property, and also matches the mux
>>> +controller state.
>>> +
>>> +Example:
>>> + mux: mux-controller {
>>> + compatible = "mux-gpio";
>>> + #mux-control-cells = <0>;
>>> +
>>> + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
>>> + <&pioA 1 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>> + adc-mux {
>>> + compatible = "iio-mux";
>>> + io-channels = <&adc 0>;
>>> + io-channel-names = "parent";
>>> +
>>> + mux-controls = <&mux>;
>>> +
>>> + channels = "sync", "in", system-regulator";
>>> + };
>
> Describing the same as above, but with the mux controller as a child
> node.
>
> adc-mux {
> compatible = "iio-mux";
> io-channels = <&adc 0>;
> io-channel-names = "parent";
>
> channels = "sync", "in", system-regulator";
>
> mux-controller {
> compatible = "mux-gpio";
>
> mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
> <&pioA 1 GPIO_ACTIVE_HIGH>;
> };
> };
>
> Cheers,
> Peter
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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] iio: misc: add a generic regulator driver
From: Jonathan Cameron @ 2016-12-10 18:17 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lars-Peter Clausen, Hartmut Knaack, Peter Meerwald-Stadler,
Rob Herring, Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-devicetree, LKML, Kevin Hilman, Patrick Titiano,
Neil Armstrong, Liam Girdwood, Mark Brown
In-Reply-To: <CAMpxmJVJ+y9tRbRBsVg+i0EJO_6EFuvrypwC=ETnBWbMnxRFyg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 06/12/16 11:12, Bartosz Golaszewski wrote:
> 2016-12-03 10:11 GMT+01:00 Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>> On 30/11/16 10:10, Lars-Peter Clausen wrote:
>>> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote:
>>>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>:
>>>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
>>>>> [...]
>>>>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..147458f
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>>>> @@ -0,0 +1,18 @@
>>>>>> +Industrial IO regulator device driver
>>>>>> +-------------------------------------
>>>>>> +
>>>>>> +This document describes the bindings for the iio-regulator - a dummy device
>>>>>> +driver representing a physical regulator within the iio framework.
>>>>>
>>>>> No bindings for drivers, only for hardware. So this wont work.
>>>>>
>>>>
>>>> What about exporting regulator attributes analogous to the one in this
>>>> patch from the iio-core when a *-supply property is specified for a
>>>> node?
>>>
>>> The problem with exposing direct control to the regulator is that it allows
>>> to modify the hardware state without the drivers knowledge. If you
>>> power-cycle a device all previous configuration that has been written to the
>>> device is reset. The device driver needs to be aware of this otherwise its
>>> assumed state and the actual device state can divert which will result in
>>> undefined behavior. Also access to the device will fail unexpectedly when
>>> the regulator is turned off. So I think generally the driver should
>>> explicitly control the regulator, power-up when needed, power-down when not.
>> I agree with what Lars has said.
>>
>> There 'may' be some argument to ultimately have a bridge driver from
>> regulators to IIO. That would be for cases where the divide between a regulator
>> and a DAC is blurred. However it would still have to play nicely with the
>> regulator framework and any other devices registered on that regulator.
>> Ultimately the ideal in that case would then be to describe what the DAC is
>> actually being used to do but that's a more complex issue!
>>
>> That doesn't seem to be what you are targeting here.
>>
>> What it sounds like you need is to have the hardware well enough described that
>> the standard runtime power management can disable the regulator just fine when
>> it is not in use. This may mean improving the power management in the relevant
>> drivers.
>>
>> Jonathan
>>
>> p.s. If ever proposing to do something 'unusual' with a regulator you should
>> bring in the regulator framework maintainers in the cc list.
>>>
>>> - Lars
>>>
>>
>
> I wrote the initial patch quickly and didn't give it much of a
> thought. Now I realized I completely missed the point and managed to
> confuse everybody - myself included.
>
> So the problem we have is not power-cycling the adc - it's
> power-cycling the device connected to a probe on which there's an adc.
> What I was trying to do was adding support for the power-switch on
> baylibre-acme[1] probes.
>
> For example: we have a USB probe on which the VBUS signal goes through
> a power load switch and than through the adc. The adc (in this case
> ina226) is always powered on, while the fixed regulator I wanted to
> enable/disable actually drives the power switch to cut/restore power
> to the connected USB device i.e. there's no real regulator - just a
> GPIO driving the power switch.
>
> A typical use case is measuring the power consumption of development
> boards[2]. Rebooting them remotely using acme probes is already done,
> but we're using the obsolete /sys/class/gpio interface.
>
> We're already using libiio to read the measured data from the power
> monitor, that's why we'd like to use the iio framework for
> power-cycling the devices as well. My question is: would bridging the
> regulator framework be the right solution? Should we look for
> something else? Bridge the GPIO framework instead?
Definitely doesn't fit inside standard scope of IIO - though I can see
why you were thinking along these lines.
Mark Brown, any thoughts?
Effectively we are are looking at something that (in general form) might
be the equivalent of controlling a lab bench supply... So regulators
at the edge of the known world, with no visibility of what lies beyond.
>
> Best regards,
> Bartosz Golaszewski
>
> [1] http://baylibre.com/acme/
> [2] https://github.com/BayLibre/POWERCI
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/5] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Cédric Le Goater @ 2016-12-10 17:34 UTC (permalink / raw)
To: Marek Vasut, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Joel Stanley
In-Reply-To: <68aa03be-8195-1824-a9e1-609a5ad74381-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello,
On 12/10/2016 05:01 AM, Marek Vasut wrote:
> On 12/09/2016 05:49 PM, Cédric Le Goater wrote:
>
> [...]
>
>
>> +static int aspeed_smc_read_from_ahb(void *buf, const void __iomem *src,
>> + size_t len)
>> +{
>> + if (IS_ALIGNED((u32)src, sizeof(u32)) &&
>> + IS_ALIGNED((u32)buf, sizeof(u32)) &&
>> + IS_ALIGNED(len, sizeof(u32))) {
>
> Did you try compiling this on any 64bit system ?
I cross compile the kernel on a 64bit host and then upload on the
target. What kind of problem are you forseeing ?
>
>> + while (len > 3) {
>> + *(u32 *)buf = readl(src);
>
> ioread32_rep() to avoid open-coding the loop .
ok.
>> + buf += 4;
>> + src += 4;
>> + len -= 4;
>> + }
>> + }
>> +
>> + while (len--) {
>> + *(u8 *)buf = readb(src);
>> + buf += 1;
>> + src += 1;
>> + }
>> + return 0;
>> +}
>> +
>> +static int aspeed_smc_write_to_ahb(void __iomem *dst, const void *buf,
>> + size_t len)
>> +{
>> + if (IS_ALIGNED((u32)dst, sizeof(u32)) &&
>> + IS_ALIGNED((u32)buf, sizeof(u32)) &&
>> + IS_ALIGNED(len, sizeof(u32))) {
>> + while (len > 3) {
>> + u32 val = *(u32 *)buf;
>> +
>> + writel(val, dst);
>
> iowrite32_rep()
>
>> + buf += 4;
>> + dst += 4;
>> + len -= 4;
>> + }
>> + }
>> +
>> + while (len--) {
>> + u8 val = *(u8 *)buf;
>> +
>> + writeb(val, dst);
>> + buf += 1;
>> + dst += 1;
>> + }
>> + return 0;
>> +}
>> +
>> +/*
>> + * The driver only support SPI flash
>> + */
>> +enum aspeed_smc_flash_type {
>> + smc_type_nor = 0,
>> + smc_type_nand = 1,
>> + smc_type_spi = 2,
>> +};
>> +
>> +struct aspeed_smc_chip;
>> +
>> +struct aspeed_smc_info {
>> + u32 maxsize; /* maximum size of chip window */
>> + u8 nce; /* number of chip enables */
>> + bool hastype; /* flash type field exists in config reg */
>> + u8 we0; /* shift for write enable bit for CE0 */
>> + u8 ctl0; /* offset in regs of ctl for CE0 */
>> +
>> + void (*set_4b)(struct aspeed_smc_chip *chip);
>> +};
>
> Move all the structs to the beginning of the driver please.
ok.
>
>> +static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip);
>> +
>> +static const struct aspeed_smc_info fmc_2500_info = {
>> + .maxsize = 256 * 1024 * 1024,
>> + .nce = 3,
>> + .hastype = true,
>> + .we0 = 16,
>> + .ctl0 = 0x10,
>> + .set_4b = aspeed_smc_chip_set_4b,
>> +};
>> +
>> +static const struct aspeed_smc_info spi_2500_info = {
>> + .maxsize = 128 * 1024 * 1024,
>> + .nce = 2,
>> + .hastype = false,
>> + .we0 = 16,
>> + .ctl0 = 0x10,
>> + .set_4b = aspeed_smc_chip_set_4b,
>> +};
>> +
>> +enum aspeed_smc_ctl_reg_value {
>> + smc_base, /* base value without mode for other commands */
>> + smc_read, /* command reg for (maybe fast) reads */
>> + smc_write, /* command reg for writes */
>> + smc_max,
>> +};
>
> [...]
>
>> +#define CONTROL_CE_STOP_ACTIVE_CONTROL BIT(2)
>> +#define CONTROL_COMMAND_MODE_MASK GENMASK(1, 0)
>> +#define CONTROL_COMMAND_MODE_NORMAL (0)
>> +#define CONTROL_COMMAND_MODE_FREAD (1)
>> +#define CONTROL_COMMAND_MODE_WRITE (2)
>> +#define CONTROL_COMMAND_MODE_USER (3)
>
> Drop the parenthesis around constants :)
yeah
>> +#define CONTROL_KEEP_MASK \
>> + (CONTROL_AAF_MODE | CONTROL_CE_INACTIVE_MASK | CONTROL_CLK_DIV4 | \
>> + CONTROL_IO_DUMMY_MASK | CONTROL_CLOCK_FREQ_SEL_MASK | \
>> + CONTROL_LSB_FIRST | CONTROL_CLOCK_MODE_3)
>> +
>> +/*
>> + * Segment Address Registers. Start and end addresses are encoded
>> + * using 8MB units
>> + */
>> +#define SEGMENT_ADDR_REG0 0x30
>> +#define SEGMENT_ADDR_START(_r) ((((_r) >> 16) & 0xFF) << 23)
>
> is that ((r) & 0xff0000) << 7 ?
>
>> +#define SEGMENT_ADDR_END(_r) ((((_r) >> 24) & 0xFF) << 23)
>
> ((r) & 0xff000000) >> 1 ?
yes.
I rather keep the initial macros though, which I found easier to
understand.
The Segment Register uses a 8MB unit to encode the start address
and the end address of the mapping window of a flash SPI slave :
| byte 1 | byte 2 | byte 3 | byte 4 |
+--------+--------+--------+--------+
| end | start | 0 | 0 |
>> +static inline u32 aspeed_smc_chip_write_bit(struct aspeed_smc_chip *chip)
>> +{
>> + return BIT(chip->controller->info->we0 + chip->cs);
>> +}
>
> [...]
>
>> +static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
>> + struct resource *res)
>> +{
>> + struct aspeed_smc_controller *controller = chip->controller;
>> + const struct aspeed_smc_info *info = controller->info;
>> + u32 reg, base_reg;
>> +
>> + /*
>> + * Always turn on the write enable bit to allow opcodes to be
>> + * sent in user mode.
>> + */
>> + aspeed_smc_chip_enable_write(chip);
>> +
>> + /* The driver only supports SPI type flash */
>> + if (info->hastype)
>> + aspeed_smc_chip_set_type(chip, smc_type_spi);
>> +
>> + /*
>> + * Configure chip base address in memory
>> + */
>> + chip->ahb_base = aspeed_smc_chip_base(chip, res);
>> + if (!chip->ahb_base) {
>> + dev_warn(chip->nor.dev, "CE segment window closed.\n");
>> + return -1;
>
> return -EINVAL ? Check whether you always use errno.h macros in returns.
ah yes. I missed that one.
>
>> + }
>> +
>> + /*
>> + * Get value of the inherited control register. U-Boot usually
>> + * does some timing calibration on the FMC chip, so it's good
>> + * to keep them. In the future, we should handle calibration
>> + * from Linux.
>> + */
>> + reg = readl(chip->ctl);
>> + dev_dbg(controller->dev, "control register: %08x\n", reg);
>> +
>> + base_reg = reg & CONTROL_KEEP_MASK;
>> + if (base_reg != reg) {
>> + dev_info(controller->dev,
>> + "control register changed to: %08x\n",
>> + base_reg);
>> + }
>> + chip->ctl_val[smc_base] = base_reg;
>
> [...]
>
> Mostly minor nits, looks nice otherwise, thanks :)
Thanks for the review,
C.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/5] mtd: aspeed: add memory controllers for the Aspeed AST2400 SoC
From: Marek Vasut @ 2016-12-10 17:30 UTC (permalink / raw)
To: Cédric Le Goater, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Joel Stanley
In-Reply-To: <30a50d6d-07c5-0ca6-2d1b-3ba46c10da49-Bxea+6Xhats@public.gmane.org>
On 12/10/2016 06:18 PM, Cédric Le Goater wrote:
> On 12/10/2016 05:03 AM, Marek Vasut wrote:
>>> +/*
>>> + * The AST2400 SPI flash controller does not have a CE Control
>>> + * register. It uses the CE0 control register to set 4Byte mode at the
>>> + * controller level.
>>> + */
>>> +static void aspeed_smc_chip_set_4b_spi_2400(struct aspeed_smc_chip *chip)
>>> +{
>>> + chip->ctl_val[smc_base] |= CONTROL_IO_ADDRESS_4B;
>>> + chip->ctl_val[smc_read] |= CONTROL_IO_ADDRESS_4B;
>> How do you know the SPI NOR is in 4B mode ?
>
> in aspeed_smc_chip_setup_finish() :
>
> if (chip->nor.addr_width == 4 && info->set_4b)
> info->set_4b(chip);
>
Ahhh, great :)
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/5] mtd: aspeed: add memory controllers for the Aspeed AST2400 SoC
From: Cédric Le Goater @ 2016-12-10 17:18 UTC (permalink / raw)
To: Marek Vasut, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Joel Stanley
In-Reply-To: <076683ea-fa94-2284-f269-2fcebd793940-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12/10/2016 05:03 AM, Marek Vasut wrote:
>> +/*
>> + * The AST2400 SPI flash controller does not have a CE Control
>> + * register. It uses the CE0 control register to set 4Byte mode at the
>> + * controller level.
>> + */
>> +static void aspeed_smc_chip_set_4b_spi_2400(struct aspeed_smc_chip *chip)
>> +{
>> + chip->ctl_val[smc_base] |= CONTROL_IO_ADDRESS_4B;
>> + chip->ctl_val[smc_read] |= CONTROL_IO_ADDRESS_4B;
> How do you know the SPI NOR is in 4B mode ?
in aspeed_smc_chip_setup_finish() :
if (chip->nor.addr_width == 4 && info->set_4b)
info->set_4b(chip);
C.
>> +}
>> +
>> static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
>> struct resource *res)
>> {
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/5] mtd: aspeed: used a label property
From: Cédric Le Goater @ 2016-12-10 17:16 UTC (permalink / raw)
To: Marek Vasut, linux-mtd
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Rob Herring, Joel Stanley, Cyrille Pitchen, Brian Norris,
David Woodhouse
In-Reply-To: <6bc350c3-b162-dc10-4cd3-c32f9a3d4eaf@gmail.com>
On 12/10/2016 05:03 AM, Marek Vasut wrote:
> On 12/09/2016 05:49 PM, Cédric Le Goater wrote:
>> This can be used to easily identify a chip on a system with multiple
>> chips.
>
> I don't think I understand what this patch does.
> It seems to me like this one should be wrapped into 1/5.
Yes, but this is to open the discussion on the change required in the
jedec,spi-nor binding.
C.
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/mtd/spi-nor/aspeed-smc.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
>> index 99302b0d7786..9119c0ca86b6 100644
>> --- a/drivers/mtd/spi-nor/aspeed-smc.c
>> +++ b/drivers/mtd/spi-nor/aspeed-smc.c
>> @@ -676,6 +676,8 @@ static int aspeed_smc_setup_flash(struct aspeed_smc_controller *controller,
>> nor->prepare = aspeed_smc_prep;
>> nor->unprepare = aspeed_smc_unprep;
>>
>> + mtd->name = of_get_property(child, "label", NULL);
>> +
>> ret = aspeed_smc_chip_setup_init(chip, r);
>> if (ret)
>> break;
>>
>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH v3 2/2] Documentation: dt: iio: add st_lsm6dsx sensor device binding
From: Lorenzo Bianconi @ 2016-12-10 9:02 UTC (permalink / raw)
To: jic23-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, lorenzo.bianconi-qxv4g6HH51o
In-Reply-To: <20161210090218.4609-1-lorenzo.bianconi-qxv4g6HH51o@public.gmane.org>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi-qxv4g6HH51o@public.gmane.org>
---
.../devicetree/bindings/iio/imu/st_lsm6dsx.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
diff --git a/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt b/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
new file mode 100644
index 0000000..ed3cdac
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
@@ -0,0 +1,24 @@
+* ST_LSM6DSx driver for STM 6-axis (acc + gyro) imu Mems sensors
+
+Required properties:
+- compatible: must be one of:
+ "st,lsm6ds3"
+ "st,lsm6dsm"
+- reg: i2c address of the sensor / spi cs line
+
+Optional properties:
+- interrupt-parent: should be the phandle for the interrupt controller
+- interrupts: interrupt mapping for IRQ. It should be configured with
+ flags IRQ_TYPE_LEVEL_HIGH or IRQ_TYPE_EDGE_RISING.
+
+ Refer to interrupt-controller/interrupts.txt for generic interrupt
+ client node bindings.
+
+Example:
+
+lsm6dsm@6b {
+ compatible = "st,lsm6dsm";
+ reg = <0x6b>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <0 IRQ_TYPE_EDGE_RISING>;
+};
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox