* 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 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
* [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 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
* 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
* 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 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
* [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
* [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 2/2] iio: misc: add support for GPIO 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 power-measuring ADCs work together with power load switches which
allow to power-cycle measured devices.
An example use case would be measuring the power consumption of a
development board during boot using a power monitor such as TI INA226
and power-cycling the board remotely using a TPS229* power switch.
Add an iio driver for simple GPIO power switches and expose a sysfs
attribute allowing to toggle their state.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
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 +++++++++++++++++++++++++++++++++++
5 files changed, 152 insertions(+)
create mode 100644 drivers/iio/misc/Kconfig
create mode 100644 drivers/iio/misc/Makefile
create mode 100644 drivers/iio/misc/gpio-power-switch.c
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 6743b18..2e896e0 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -80,6 +80,7 @@ source "drivers/iio/gyro/Kconfig"
source "drivers/iio/health/Kconfig"
source "drivers/iio/humidity/Kconfig"
source "drivers/iio/imu/Kconfig"
+source "drivers/iio/misc/Kconfig"
source "drivers/iio/light/Kconfig"
source "drivers/iio/magnetometer/Kconfig"
source "drivers/iio/orientation/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 87e4c43..4008d5a 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -25,6 +25,7 @@ obj-y += frequency/
obj-y += health/
obj-y += humidity/
obj-y += imu/
+obj-y += misc/
obj-y += light/
obj-y += magnetometer/
obj-y += orientation/
diff --git a/drivers/iio/misc/Kconfig b/drivers/iio/misc/Kconfig
new file mode 100644
index 0000000..8d73751
--- /dev/null
+++ b/drivers/iio/misc/Kconfig
@@ -0,0 +1,17 @@
+#
+# Miscellaneous iio drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Miscellaneous iio drivers"
+
+config GPIO_POWER_SWITCH
+ tristate "GPIO power switch driver"
+ depends on GPIOLIB
+ help
+ Say yes here to build support for gpio power switches.
+
+ To compile this driver as a module, choose M here: the module will
+ be called gpio-power-switch.
+
+endmenu
diff --git a/drivers/iio/misc/Makefile b/drivers/iio/misc/Makefile
new file mode 100644
index 0000000..cebd0c4
--- /dev/null
+++ b/drivers/iio/misc/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO misc drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_GPIO_POWER_SWITCH) += gpio-power-switch.o
diff --git a/drivers/iio/misc/gpio-power-switch.c b/drivers/iio/misc/gpio-power-switch.c
new file mode 100644
index 0000000..25fbeb7
--- /dev/null
+++ b/drivers/iio/misc/gpio-power-switch.c
@@ -0,0 +1,127 @@
+/*
+ * GPIO power switch driver using the industrial IO framework.
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ * Bartosz Golaszewski <bgolaszewski@baylibre.com.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/gpio/consumer.h>
+
+struct gpio_pwrsw_context {
+ struct gpio_desc *gpio;
+};
+
+static ssize_t gpio_pwrsw_enable_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct gpio_pwrsw_context *ctx = iio_priv(dev_to_iio_dev(dev));
+ int val;
+
+ val = gpiod_get_value_cansleep(ctx->gpio);
+ if (val < 0)
+ return val;
+
+ return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t gpio_pwrsw_enable_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct gpio_pwrsw_context *ctx = iio_priv(dev_to_iio_dev(dev));
+ bool val;
+ int ret;
+
+ ret = strtobool(buf, &val);
+ if (ret)
+ return ret;
+
+ gpiod_set_value_cansleep(ctx->gpio, val ? 1 : 0);
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(in_active, 0644,
+ gpio_pwrsw_enable_show,
+ gpio_pwrsw_enable_store, 0);
+
+static struct attribute *gpio_pwrsw_attributes[] = {
+ &iio_dev_attr_in_active.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group gpio_pwrsw_attribute_group = {
+ .attrs = gpio_pwrsw_attributes,
+};
+
+static const struct iio_info gpio_pwrsw_info = {
+ .driver_module = THIS_MODULE,
+ .attrs = &gpio_pwrsw_attribute_group,
+};
+
+static int gpio_pwrsw_probe(struct platform_device *pdev)
+{
+ struct gpio_pwrsw_context *ctx;
+ struct iio_dev *iio_dev;
+ const char *name = NULL;
+ struct device *dev;
+ bool init_state;
+ int gpio_flags;
+
+ dev = &pdev->dev;
+
+ iio_dev = devm_iio_device_alloc(dev, sizeof(*ctx));
+ if (!iio_dev)
+ return -ENOMEM;
+
+ ctx = iio_priv(iio_dev);
+
+ init_state = of_property_read_bool(dev->of_node, "power-switch-on");
+ gpio_flags = init_state ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+
+ ctx->gpio = devm_gpiod_get(dev, "power", gpio_flags);
+ if (IS_ERR(ctx->gpio)) {
+ dev_err(dev, "unable to get the power switch gpio: %ld\n",
+ PTR_ERR(ctx->gpio));
+ return PTR_ERR(ctx->gpio);
+ }
+
+ of_property_read_string(dev->of_node, "power-switch-name", &name);
+
+ iio_dev->dev.parent = dev;
+ iio_dev->dev.of_node = dev->of_node;
+ iio_dev->name = name ? name : dev->driver->name;
+ iio_dev->info = &gpio_pwrsw_info;
+
+ return devm_iio_device_register(dev, iio_dev);
+}
+
+static const struct of_device_id gpio_pwrsw_of_match[] = {
+ { .compatible = "gpio-power-switch", },
+ { },
+};
+
+static struct platform_driver gpio_pwrsw_platform_driver = {
+ .probe = gpio_pwrsw_probe,
+ .driver = {
+ .name = "gpio-power-switch",
+ .of_match_table = gpio_pwrsw_of_match,
+ },
+};
+module_platform_driver(gpio_pwrsw_platform_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>");
+MODULE_DESCRIPTION("GPIO power switch driver for iio");
+MODULE_LICENSE("GPL v2");
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] iio: misc: add a generic regulator driver
From: Bartosz Golaszewski @ 2016-12-11 22:23 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lars-Peter Clausen, Hartmut Knaack, Peter Meerwald-Stadler,
Rob Herring, Mark Rutland, linux-iio, linux-devicetree, LKML,
Kevin Hilman, Patrick Titiano, Neil Armstrong, Liam Girdwood,
Mark Brown
In-Reply-To: <c028b2fc-7ed1-772c-82e3-b98a25f58ffb@kernel.org>
2016-12-10 19:17 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
> On 06/12/16 11:12, Bartosz Golaszewski wrote:
>>
>> 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.
>
Well, it's industrial INPUT/output right? I guess we can consider
power-cycling input in this case. :)
In our particular use case, the main reason for using IIO is having a
single interface (libiio) instead of introducing a new one just for
that (in the form of random sysfs attributes for example), but I'm
sure such power switches could find application elsewhere too
(measuring temperature, while power-cycling some cooling mechanism is
the first thing that comes to mind).
> 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.
>
Please consider the two patches I just sent. Instead of regulators,
they add DT bindings for gpio power switches and introduce a simple
iio driver using the gpio consumer API.
Best regards,
Bartosz Golaszewski
^ permalink raw reply
* Re: [PATCH v5 1/2] i2c: aspeed: added driver for Aspeed I2C
From: Wolfram Sang @ 2016-12-11 22:26 UTC (permalink / raw)
To: Brendan Higgins
Cc: vz, clg, mouse, robh+dt, mark.rutland, linux-i2c, devicetree,
joel, openbmc
In-Reply-To: <1480467618-7497-2-git-send-email-brendanhiggins@google.com>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
On Tue, Nov 29, 2016 at 05:00:17PM -0800, Brendan Higgins wrote:
> Added initial master and slave support for Aspeed I2C controller.
> Supports fourteen busses present in ast24xx and ast25xx BMC SoCs by
> Aspeed.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
BTW first the bindings patch please, then the driver.
And one seperate question I just stumbled over:
> + /* Switch from master mode to slave mode. */
> + func_ctrl_reg_val = aspeed_i2c_read(bus, ASPEED_I2C_FUN_CTRL_REG);
> + func_ctrl_reg_val &= ~ASPEED_I2CD_MASTER_EN;
> + func_ctrl_reg_val |= ASPEED_I2CD_SLAVE_EN;
> + aspeed_i2c_write(bus, func_ctrl_reg_val, ASPEED_I2C_FUN_CTRL_REG);
Can't the hardware work both as master and slave on the same bus?
Regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/5] mtd: aspeed: used a label property
From: Joel Stanley @ 2016-12-11 23:46 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <1481302167-28044-4-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> This can be used to easily identify a chip on a system with multiple
> chips.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
Our userspace benefits from having this.
Acked-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.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;
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 5/5] mtd: spi-nor: add a label property to jedec,spi-nor
From: Joel Stanley @ 2016-12-11 23:47 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <1481302167-28044-6-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> This can be used to easily identify a chip on a system with multiple
> chips.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
This is very useful when writing userspace that wants to select the
mtd device that represents a specific flash chip.
Acked-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> index 2c91c03e7eb0..b7cd02a3ebe8 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> @@ -65,6 +65,7 @@ Optional properties:
> all chips and support for it can not be detected at runtime.
> Refer to your chips' datasheet to check if this is supported
> by your chip.
> +- label : name to assign to mtd. If omitted, the label is the MTD device name.
>
> Example:
>
> @@ -75,4 +76,5 @@ Example:
> reg = <0>;
> spi-max-frequency = <40000000>;
> m25p,fast-read;
> + label = "System-firmware";
> };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/5] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Joel Stanley @ 2016-12-12 0:05 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <1481302167-28044-2-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> This driver adds mtd support for the Aspeed AST2500 SoC static memory
> controllers :
> Based on previous work from Milton D. Miller II <miltonm-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
I had a read and it looks good. Once you have addressed Marek's
review, please add:
Reviewed-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> ---
> drivers/mtd/spi-nor/Kconfig | 10 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/aspeed-smc.c | 735 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 746 insertions(+)
> create mode 100644 drivers/mtd/spi-nor/aspeed-smc.c
>
> +
> +MODULE_DESCRIPTION("ASPEED Static Memory Controller Driver");
> +MODULE_AUTHOR("Milton Miller");
You can stick your name here instead, or drop the define.
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/5] mtd: aspeed: add memory controllers for the Aspeed AST2400 SoC
From: Joel Stanley @ 2016-12-12 0:10 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <1481302167-28044-3-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> This driver adds mtd support for the Aspeed AST2400 SoC static memory
> controllers:
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
Good work. It was worth spending the time splitting out the different
controllers I think.
Reviewed-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> ---
> drivers/mtd/spi-nor/Kconfig | 2 +-
> drivers/mtd/spi-nor/aspeed-smc.c | 33 +++++++++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+), 1 deletion(-)
--
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 4/5] mtd: spi-nor: bindings for the Aspeed memory controllers
From: Joel Stanley @ 2016-12-12 0:13 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <1481302167-28044-5-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/aspeed-smc.txt | 51 ++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/aspeed-smc.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/aspeed-smc.txt b/Documentation/devicetree/bindings/mtd/aspeed-smc.txt
> new file mode 100644
> index 000000000000..e2c88cea38f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/aspeed-smc.txt
> @@ -0,0 +1,51 @@
> +* Aspeed Firmware Memory controller
> +* Aspeed SPI Flash Memory Controller
> +
> +The Firmware Memory Controller in the Aspeed AST2500 SoC supports
> +three chip selects, two of which are always of SPI type and the third
> +can be SPI or NOR type flash, but the driver only supports SPI.
As the bindings are a description of the hardware and not the driver,
we might want to reword this. Perhaps "these bindings only describe
SPI"?
Cheers,
Joel
> +
> +The two SPI flash memory controllers in the AST2500 each support two
> +chip selects.
> +
> +Required properties:
> + - compatible : Should be one of
> + "aspeed,ast2400-fmc" for the AST2400 Firmware Memory Controller
> + "aspeed,ast2400-spi" for the AST2400 SPI Flash memory Controller
> + "aspeed,ast2500-fmc" for the AST2500 Firmware Memory Controller
> + "aspeed,ast2500-spi" for the AST2500 SPI flash memory controllers
> +
> + - reg : the first contains the control register location and length,
> + the second contains the memory window mapping address and length
> + - #address-cells : must be 1 corresponding to chip select child binding
> + - #size-cells : must be 0 corresponding to chip select child binding
> +
> +Optional properties:
> + - interrupts : Should contain the interrupt for the dma device if an
> + FMC
> +
> +The child nodes are the SPI flash modules which must have a compatible
> +property as specified in bindings/mtd/jedec,spi-nor.txt
> +
> +Optionally, the child node can contain properties for SPI mode (may be
> +ignored):
> + - spi-max-frequency - max frequency of spi bus
> +
> +
> +Example:
> +fmc: fmc@1e620000 {
> + compatible = "aspeed,ast2500-fmc";
> + reg = < 0x1e620000 0x94
> + 0x20000000 0x02000000 >;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <19>;
> + flash@0 {
> + reg = < 0 >;
> + compatible = "jedec,spi-nor";
> + /* spi-max-frequency = <>; */
> + /* m25p,fast-read; */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> +};
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/5] mtd: aspeed: used a label property
From: Marek Vasut @ 2016-12-12 2:27 UTC (permalink / raw)
To: Joel Stanley, Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <CACPK8Xcj4P34-4krGbnimVG89wMcHoRX4XJ66-_7KtAt6-vTkA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/12/2016 12:46 AM, Joel Stanley wrote:
> On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
>> This can be used to easily identify a chip on a system with multiple
>> chips.
>>
>> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
>
> Our userspace benefits from having this.
>
> Acked-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
Shouldn't such thing be part of core code then ?
>> ---
>> 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;
>> --
>> 2.7.4
>>
--
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 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Jacky Bai @ 2016-12-12 2:32 UTC (permalink / raw)
To: Stephen Boyd
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
p.zabel@pengutronix.de, mturquette@baylibre.com,
daniel.lezcano@linaro.org, linux-clk@vger.kernel.org,
linux-gpio@vger.kernel.org, robh+dt@kernel.org,
kernel@pengutronix.de, jacky.baip@gmail.com, Fabio Estevam,
tglx@linutronix.de, shawnguo@kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161208225424.GQ5423@codeaurora.org>
> Subject: Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
>
> On 12/02, Bai Ping wrote:
> > Add necessary document update for i.MX6SLL support.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > ---
> > .../devicetree/bindings/clock/imx6sll-clock.txt | 13 ++++++++
> > .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt | 37 ++++++++++++++++++++++
>
> Please split the bindings into different patches and put them closer to the
> drivers that use them in the series.
Ok, I will fix it in V2.
>
> > 2 files changed, 50 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > create mode 100644
> > Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > new file mode 100644
> > index 0000000..4f52efa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > @@ -0,0 +1,13 @@
> > +* Clock bindings for Freescale i.MX6 UltraLite
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx6sll-ccm"
> > +- reg: Address and length of the register set
> > +- #clock-cells: Should be <1>
> > +- clocks: list of clock specifiers, must contain an entry for each
> > +required
> > + entry in clock-names
> > +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell. See
> > +include/dt-bindings/clock/imx6sll-clock.h
> > +for the full list of i.MX6 SLL clock IDs.
>
> Can you add an example node here?
>
Thanks for review, I will add it in V2.
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* RE: [PATCH 03/11] driver: clk: imx: Add clock driver for imx6sll
From: Jacky Bai @ 2016-12-12 2:58 UTC (permalink / raw)
To: Stephen Boyd
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
p.zabel@pengutronix.de, mturquette@baylibre.com,
daniel.lezcano@linaro.org, linux-clk@vger.kernel.org,
linux-gpio@vger.kernel.org, robh+dt@kernel.org,
kernel@pengutronix.de, jacky.baip@gmail.com, Fabio Estevam,
tglx@linutronix.de, shawnguo@kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161208225257.GP5423@codeaurora.org>
> Subject: Re: [PATCH 03/11] driver: clk: imx: Add clock driver for imx6sll
>
> On 12/02, Bai Ping wrote:
> > diff --git a/drivers/clk/imx/clk-imx6sll.c
> > b/drivers/clk/imx/clk-imx6sll.c new file mode 100644 index
> > 0000000..c5219e1
> > --- /dev/null
> > +++ b/drivers/clk/imx/clk-imx6sll.c
> > @@ -0,0 +1,366 @@
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + */
> > +
> > +#include <dt-bindings/clock/imx6sll-clock.h>
> > +#include <linux/clk.h>
> > +#include <linux/clkdev.h>
>
> Is this include used?
>
It seems no use, I will remove it in V2.
> > +#include <linux/err.h>
> > +#include <linux/init.h>
> > +#include <linux/io.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/types.h>
>
> Is there an include of clk_provider.h missing?
>
clk_provider.h is included in below "clk.h".
> > +
> > +#include "clk.h"
> > +
> > +#define BM_CCM_CCDR_MMDC_CH0_MASK (0x2 << 16)
> > +#define CCDR 0x4
> > +
> > +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
>
> const char * const? For all of these names.
>
ok, I will fix in V2.
> > +static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src",
> > +}; static const char *pll2_bypass_sels[] = { "pll2",
> > +"pll2_bypass_src", }; static const char *pll3_bypass_sels[] = {
> > +"pll3", "pll3_bypass_src", }; static const char *pll4_bypass_sels[] =
> > +{ "pll4", "pll4_bypass_src", }; static const char *pll5_bypass_sels[]
> > += { "pll5", "pll5_bypass_src", }; static const char
> > +*pll6_bypass_sels[] = { "pll6", "pll6_bypass_src", }; static const
> > +char *pll7_bypass_sels[] = { "pll7", "pll7_bypass_src", }; static
> > +const char *step_sels[] = { "osc", "pll2_pfd2_396m", }; static const
> > +char *pll1_sw_sels[] = { "pll1_sys", "step", }; static const char
> > +*axi_alt_sels[] = { "pll2_pfd2_396m", "pll3_pfd1_540m", }; static
> > +const char *axi_sels[] = {"periph", "axi_alt_sel", }; static const
> > +char *periph_pre_sels[] = { "pll2_bus", "pll2_pfd2_396m",
> > +"pll2_pfd0_352m", "pll2_198m", }; static const char
> > +*periph2_pre_sels[] = { "pll2_bus", "pll2_pfd2_396m",
> > +"pll2_pfd0_352m", "pll4_audio_div", }; static const char
> > +*periph_clk2_sels[] = { "pll3_usb_otg", "osc", "osc", }; static const
> > +char *periph2_clk2_sels[] = { "pll3_usb_otg", "osc", }; static const
> > +char *periph_sels[] = { "periph_pre", "periph_clk2", }; static const
> > +char *periph2_sels[] = { "periph2_pre", "periph2_clk2", }; static
> > +const char *usdhc_sels[] = { "pll2_pfd2_396m", "pll2_pfd0_352m", };
> > +static const char *ssi_sels[] = {"pll3_pfd2_508m", "pll3_pfd3_454m",
> > +"pll4_audio_div", "dummy",}; static const char *spdif_sels[] = {
> > +"pll4_audio_div", "pll3_pfd2_508m", "pll5_video_div", "pll3_usb_otg",
> > +}; static const char *ldb_di0_div_sels[] = { "ldb_di0_div_3_5",
> > +"ldb_di0_div_7", }; static const char *ldb_di1_div_sels[] = {
> > +"ldb_di1_div_3_5", "ldb_di1_div_7", }; static const char
> > +*ldb_di0_sels[] = { "pll5_video_div", "pll2_pfd0_352m",
> > +"pll2_pfd2_396m", "pll2_pfd3_594m", "pll2_pfd1_594m",
> > +"pll3_pfd3_454m", }; static const char *ldb_di1_sels[] = {
> > +"pll3_usb_otg", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll2_bus",
> > +"pll3_pfd3_454m", "pll3_pfd2_508m", }; static const char
> > +*lcdif_pre_sels[] = { "pll2_bus", "pll3_pfd3_454m", "pll5_video_div",
> > +"pll2_pfd0_352m", "pll2_pfd1_594m", "pll3_pfd1_540m", }; static const
> > +char *ecspi_sels[] = { "pll3_60m", "osc", }; static const char
> > +*uart_sels[] = { "pll3_80m", "osc", }; static const char
> > +*perclk_sels[] = { "ipg", "osc", }; static const char *lcdif_sels[] =
> > +{ "lcdif_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> > +
> > +static const char *epdc_pre_sels[] = { "pll2_bus", "pll3_usb_otg",
> > +"pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m",
> > +"pll3_pfd2_508m", }; static const char *epdc_sels[] = { "epdc_podf",
> > +"ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> > +
> > +static struct clk *clks[IMX6SLL_CLK_END]; static struct
> > +clk_onecell_data clk_data;
> > +
> > +static int const clks_init_on[] __initconst = {
>
> static const int is more preferred style.
>
ok, will fix in V2.
> > + IMX6SLL_CLK_AIPSTZ1, IMX6SLL_CLK_AIPSTZ2,
> > + IMX6SLL_CLK_OCRAM, IMX6SLL_CLK_ARM, IMX6SLL_CLK_ROM,
> > + IMX6SLL_CLK_MMDC_P0_FAST, IMX6SLL_CLK_MMDC_P0_IPG, };
> > +
> > +static struct clk_div_table post_div_table[] = {
>
> const?
>
ok, will fix in V2.
> > + { .val = 2, .div = 1, },
> > + { .val = 1, .div = 2, },
> > + { .val = 0, .div = 4, },
> > + { }
> > +};
> > +
> > +static struct clk_div_table video_div_table[] = {
>
> const?
>
ok. will fix in V2.
> > + { .val = 0, .div = 1, },
> > + { .val = 1, .div = 2, },
> > + { .val = 2, .div = 1, },
> > + { .val = 3, .div = 4, },
> > + { }
> > +};
> > +
> > +static u32 share_count_audio;
> > +static u32 share_count_ssi1;
> > +static u32 share_count_ssi2;
> > +static u32 share_count_ssi3;
> > +
> > +static void __init imx6sll_clocks_init(struct device_node *ccm_node)
> > +{
> > + struct device_node *np;
> > + void __iomem *base;
> > + int i;
> > +
> > + clks[IMX6SLL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
> > +
> > + clks[IMX6SLL_CLK_CKIL] = of_clk_get_by_name(ccm_node, "ckil");
> > + clks[IMX6SLL_CLK_OSC] = of_clk_get_by_name(ccm_node, "osc");
> > +
> > + /* ipp_di clock is external input */
> > + clks[IMX6SLL_CLK_IPP_DI0] = of_clk_get_by_name(ccm_node,
> "ipp_di0");
> > + clks[IMX6SLL_CLK_IPP_DI1] = of_clk_get_by_name(ccm_node,
> "ipp_di1");
> > +
> > + np = of_find_compatible_node(NULL, NULL, "fsl,imx6sll-anatop");
> > + base = of_iomap(np, 0);
> > + WARN_ON(!base);
> > +
> > + clks[IMX6SLL_PLL1_BYPASS_SRC] = imx_clk_mux("pll1_bypass_src",
> base + 0x00, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL2_BYPASS_SRC] = imx_clk_mux("pll2_bypass_src",
> base + 0x30, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL3_BYPASS_SRC] = imx_clk_mux("pll3_bypass_src",
> base + 0x10, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL4_BYPASS_SRC] = imx_clk_mux("pll4_bypass_src",
> base + 0x70, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL5_BYPASS_SRC] = imx_clk_mux("pll5_bypass_src",
> base + 0xa0, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL6_BYPASS_SRC] = imx_clk_mux("pll6_bypass_src",
> base + 0xe0, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL7_BYPASS_SRC] = imx_clk_mux("pll7_bypass_src",
> base
> > ++ 0x20, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +
> > + clks[IMX6SLL_CLK_PLL1] = imx_clk_pllv3(IMX_PLLV3_SYS, "pll1",
> "pll1_bypass_src", base + 0x00, 0x7f);
> > + clks[IMX6SLL_CLK_PLL2] = imx_clk_pllv3(IMX_PLLV3_GENERIC, "pll2",
> "pll2_bypass_src", base + 0x30, 0x1);
> > + clks[IMX6SLL_CLK_PLL3] = imx_clk_pllv3(IMX_PLLV3_USB, "pll3",
> "pll3_bypass_src", base + 0x10, 0x3);
> > + clks[IMX6SLL_CLK_PLL4] = imx_clk_pllv3(IMX_PLLV3_AV, "pll4",
> "pll4_bypass_src", base + 0x70, 0x7f);
> > + clks[IMX6SLL_CLK_PLL5] = imx_clk_pllv3(IMX_PLLV3_AV, "pll5",
> "pll5_bypass_src", base + 0xa0, 0x7f);
> > + clks[IMX6SLL_CLK_PLL6] = imx_clk_pllv3(IMX_PLLV3_ENET, "pll6",
> "pll6_bypass_src", base + 0xe0, 0x3);
> > + clks[IMX6SLL_CLK_PLL7] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7",
> "pll7_bypass_src", base + 0x20, 0x3);
> > +
> > + clks[IMX6SLL_PLL1_BYPASS] = imx_clk_mux_flags("pll1_bypass", base
> + 0x00, 16, 1, pll1_bypass_sels, ARRAY_SIZE(pll1_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL2_BYPASS] = imx_clk_mux_flags("pll2_bypass", base
> + 0x30, 16, 1, pll2_bypass_sels, ARRAY_SIZE(pll2_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL3_BYPASS] = imx_clk_mux_flags("pll3_bypass", base
> + 0x10, 16, 1, pll3_bypass_sels, ARRAY_SIZE(pll3_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL4_BYPASS] = imx_clk_mux_flags("pll4_bypass", base
> + 0x70, 16, 1, pll4_bypass_sels, ARRAY_SIZE(pll4_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL5_BYPASS] = imx_clk_mux_flags("pll5_bypass", base
> + 0xa0, 16, 1, pll5_bypass_sels, ARRAY_SIZE(pll5_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL6_BYPASS] = imx_clk_mux_flags("pll6_bypass", base
> + 0xe0, 16, 1, pll6_bypass_sels, ARRAY_SIZE(pll6_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL7_BYPASS] = imx_clk_mux_flags("pll7_bypass", base
> +
> > +0x20, 16, 1, pll7_bypass_sels, ARRAY_SIZE(pll7_bypass_sels),
> > +CLK_SET_RATE_PARENT);
> > +
> > + /* Do not bypass PLLs initially */
> > + clk_set_parent(clks[IMX6SLL_PLL1_BYPASS], clks[IMX6SLL_CLK_PLL1]);
> > + clk_set_parent(clks[IMX6SLL_PLL2_BYPASS], clks[IMX6SLL_CLK_PLL2]);
> > + clk_set_parent(clks[IMX6SLL_PLL3_BYPASS], clks[IMX6SLL_CLK_PLL3]);
> > + clk_set_parent(clks[IMX6SLL_PLL4_BYPASS], clks[IMX6SLL_CLK_PLL4]);
> > + clk_set_parent(clks[IMX6SLL_PLL5_BYPASS], clks[IMX6SLL_CLK_PLL5]);
> > + clk_set_parent(clks[IMX6SLL_PLL6_BYPASS], clks[IMX6SLL_CLK_PLL6]);
> > + clk_set_parent(clks[IMX6SLL_PLL7_BYPASS], clks[IMX6SLL_CLK_PLL7]);
>
> Can we just put raw register writes here instead? I'd prefer we didn't use clk
> consumer APIs to do things to the clk tree from the providers. The problem
> there being that:
>
> 1) We're trying to move away from using consumer APIs in provider drivers.
> It's ok if they're used during probe, but inside clk_ops is not preferred.
>
> 2) Even if you have a clk pointer, it may be "orphaned" at the time of
> registration and so calling the APIs here works now but eventually we may
> want to return an EPROBE_DEFER error in that case and this may block that
> effort.
>
> I suppose if this is the only clk driver on this machine then this last point isn't a
> concern and things are probably ok here.
>
Using raw register writing has an issue. The register is modified, but it seems the clock 'parent-child' relationship can
not match the register setting. The register setting is not bypass the pll, but in debug 'clk_summary', the
pll is bypassed.
BR
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* RE: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Jacky Bai @ 2016-12-12 2:59 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
p.zabel@pengutronix.de, mturquette@baylibre.com,
daniel.lezcano@linaro.org, sboyd@codeaurora.org,
linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org,
kernel@pengutronix.de, jacky.baip@gmail.com, Fabio Estevam,
tglx@linutronix.de, shawnguo@kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161209181201.ewcqeqslyf3je7kq@rob-hp-laptop>
> Subject: Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
>
> On Fri, Dec 02, 2016 at 02:39:33PM +0800, Bai Ping wrote:
> > Add necessary document update for i.MX6SLL support.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > ---
> > .../devicetree/bindings/clock/imx6sll-clock.txt | 13 ++++++++
> > .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt | 37 ++++++++++++++++++++++
> > 2 files changed, 50 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > create mode 100644
> > Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > new file mode 100644
> > index 0000000..4f52efa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > @@ -0,0 +1,13 @@
> > +* Clock bindings for Freescale i.MX6 UltraLite
>
> I thought UltraLite was MX6UL?
>
Sorry, it is a typo, will fix in V2.
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx6sll-ccm"
> > +- reg: Address and length of the register set
> > +- #clock-cells: Should be <1>
> > +- clocks: list of clock specifiers, must contain an entry for each
> > +required
> > + entry in clock-names
> > +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell. See
> > +include/dt-bindings/clock/imx6sll-clock.h
> > +for the full list of i.MX6 SLL clock IDs.
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> > b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> > new file mode 100644
> > index 0000000..096e471
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.tx
> > +++ t
> > @@ -0,0 +1,37 @@
> > +* Freescale i.MX6 UltraLite IOMUX Controller
>
> ditto
>
Will fix in V2. Thanks for review.
> > +
> > +Please refer to fsl,imx-pinctrl.txt in this directory for common
> > +binding part and usage.
> > +
> > +Required properties:
> > +- compatible: "fsl,imx6sll-iomuxc"
> > +- fsl,pins: each entry consists of 6 integers and represents the mux
> > +and config
> > + setting for one pin. The first 5 integers <mux_reg conf_reg
> > +input_reg mux_val
> > + input_val> are specified using a PIN_FUNC_ID macro, which can be
> > +found in
> > + imx6ul-pinfunc.h under device tree source folder. The last integer
> > +CONFIG is
> > + the pad setting value like pull-up on this pin. Please refer to
> > +i.MX6SLL
> > + Reference Manual for detailed CONFIG settings.
> > +
> > +CONFIG bits definition:
> > +PAD_CTL_LVE (1 << 22)
> > +PAD_CTL_HYS (1 << 16)
> > +PAD_CTL_PUS_100K_DOWN (0 << 14)
> > +PAD_CTL_PUS_47K_UP (1 << 14)
> > +PAD_CTL_PUS_100K_UP (2 << 14)
> > +PAD_CTL_PUS_22K_UP (3 << 14)
> > +PAD_CTL_PUE (1 << 13)
> > +PAD_CTL_PKE (1 << 12)
> > +PAD_CTL_ODE (1 << 11)
> > +PAD_CTL_SPEED_LOW (0 << 6)
> > +PAD_CTL_SPEED_MED (1 << 6)
> > +PAD_CTL_SPEED_HIGH (3 << 6)
> > +PAD_CTL_DSE_DISABLE (0 << 3)
> > +PAD_CTL_DSE_260ohm (1 << 3)
> > +PAD_CTL_DSE_130ohm (2 << 3)
> > +PAD_CTL_DSE_87ohm (3 << 3)
> > +PAD_CTL_DSE_65ohm (4 << 3)
> > +PAD_CTL_DSE_52ohm (5 << 3)
> > +PAD_CTL_DSE_43ohm (6 << 3)
> > +PAD_CTL_DSE_37ohm (7 << 3)
> > +PAD_CTL_SRE_FAST (1 << 0)
> > +PAD_CTL_SRE_SLOW (0 << 0)
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: usb:xhci: support disable usb2 LPM Remote Wakeup
From: Thang Q. Nguyen @ 2016-12-12 4:00 UTC (permalink / raw)
To: Rob Herring
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Mathias Nyman,
Greg Kroah-Hartman, devicetree, linux-kernel, linux-usb, Phong Vo,
Loc Ho, Vu Nguyen, patches
In-Reply-To: <20161209213629.76ixdmr24ln72uaw@rob-hp-laptop>
On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring <robh@kernel.org> wrote:
> On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote:
>> From: Thang Nguyen <tqnguyen@apm.com>
>>
>> As per USB 2.0 link power management addendum ECN, table 1-2, page 4,
>> device or host initiated via resume signaling; device-initiated resumes
>> can be optionally enabled/disabled by software. This patch adds support
>> to control enabling the USB2 RWE feature via DT/ACPI attribute.
>>
>> Signed-off-by: Vu Nguyen <vnguyen@apm.com>
>> Signed-off-by: Thang Nguyen <tqnguyen@apm.com>
>> ---
>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>> drivers/usb/host/xhci-plat.c | 3 +++
>> drivers/usb/host/xhci.c | 5 ++++-
>> drivers/usb/host/xhci.h | 1 +
>> 4 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> index 966885c..9b4cd14 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> @@ -25,6 +25,7 @@ Required properties:
>>
>> Optional properties:
>> - clocks: reference to a clock
>> + - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable
>
> Remote wakeup has been around since USB 1.0 days. Does this need to be
> USB2 or XHCI specific?
This is XHCI specific. Per XHCI specification 1.1, remote wakeup is
optional for XHCI 1.0 and required for XHCI 1.1. This patch provides
ability for software to disable RWE for USB2 in XHCI1.0 controller.
>
>> - usb3-lpm-capable: determines if platform is USB3 LPM capable
>>
>> Example:
--
Thang Q. Nguyen | Staff SW Eng.
C: +849.7684.7606 | O: +848.3770.0640
F: +848.3770.0641 | tqnguyen@apm.com
^ permalink raw reply
* Re: [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
From: Ricky Liang @ 2016-12-12 4:34 UTC (permalink / raw)
To: Rick Chang
Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Matthias Brugger, Rob Herring, open list,
linux-media-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
moderated list:ARM/Mediatek SoC...,
moderated list:ARM/Mediatek SoC...,
open list:OPEN FIRMWARE AND..., Minghsiu Tsai, Bin Liu
In-Reply-To: <1480475340-21893-3-git-send-email-rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Hi Rick,
On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> Add v4l2 driver for Mediatek JPEG Decoder
>
> Signed-off-by: Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
<snip...>
> +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx,
> + struct mtk_jpeg_dec_param *param)
> +{
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct mtk_jpeg_q_data *q_data;
> +
> + q_data = &ctx->out_q;
> + if (q_data->w != param->pic_w || q_data->h != param->pic_h) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Picture size change\n");
> + return true;
> + }
> +
> + q_data = &ctx->cap_q;
> + if (q_data->fmt != mtk_jpeg_find_format(ctx, param->dst_fourcc,
> + MTK_JPEG_FMT_TYPE_CAPTURE)) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "format change\n");
> + return true;
> + }
> + return false;
<snip...>
> +static void mtk_jpeg_device_run(void *priv)
> +{
> + struct mtk_jpeg_ctx *ctx = priv;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct vb2_buffer *src_buf, *dst_buf;
> + enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> + unsigned long flags;
> + struct mtk_jpeg_src_buf *jpeg_src_buf;
> + struct mtk_jpeg_bs bs;
> + struct mtk_jpeg_fb fb;
> + int i;
> +
> + src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
> +
> + if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
> + for (i = 0; i < dst_buf->num_planes; i++)
> + vb2_set_plane_payload(dst_buf, i, 0);
> + buf_state = VB2_BUF_STATE_DONE;
> + goto dec_end;
> + }
> +
> + if (mtk_jpeg_check_resolution_change(ctx, &jpeg_src_buf->dec_param)) {
> + mtk_jpeg_queue_src_chg_event(ctx);
> + ctx->state = MTK_JPEG_SOURCE_CHANGE;
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> + return;
> + }
This only detects source change if multiple OUPUT buffers are queued.
It does not catch the source change in the following scenario:
- OUPUT buffers for jpeg1 enqueued
- OUTPUT queue STREAMON
- userspace creates CAPTURE buffers
- CAPTURE buffers enqueued
- CAPTURE queue STREAMON
- decode
- OUTPUT queue STREAMOFF
- userspace recreates OUTPUT buffers for jpeg2
- OUTPUT buffers for jpeg2 enqueued
- OUTPUT queue STREAMON
In the above sequence if jpeg2's decoded size is larger than jpeg1 the
function fails to detect that the existing CAPTURE buffers are not big
enough to hold the decoded data.
A possible fix is to pass *dst_buf to
mtk_jpeg_check_resolution_change(), and check in the function that all
the dst_buf planes are large enough to hold the decoded data.
> +
> + mtk_jpeg_set_dec_src(ctx, src_buf, &bs);
> + if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, dst_buf, &fb))
> + goto dec_end;
> +
> + spin_lock_irqsave(&jpeg->hw_lock, flags);
> + mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> + mtk_jpeg_dec_set_config(jpeg->dec_reg_base,
> + &jpeg_src_buf->dec_param, &bs, &fb);
> +
> + mtk_jpeg_dec_start(jpeg->dec_reg_base);
> + spin_unlock_irqrestore(&jpeg->hw_lock, flags);
> + return;
> +
> +dec_end:
> + v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state);
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> +}
<snip...>
--
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: Joel Stanley @ 2016-12-12 5:02 UTC (permalink / raw)
To: Cédric Le Goater, Marek Vasut
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland, Brendan Higgins
In-Reply-To: <1481302167-28044-2-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Sat, Dec 10, 2016 at 3:49 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 4a682ee0f632..5c0efbd9dd89 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -29,6 +29,16 @@ config MTD_SPI_NOR_USE_4K_SECTORS
> Please note that some tools/drivers/filesystems may not work with
> 4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
>
> +config SPI_ASPEED
> + tristate "Aspeed flash controllers in SPI mode"
> + depends on ARCH_ASPEED || COMPILE_TEST
> + depends on HAS_IOMEM && OF
> + help
> + This enables support for the Firmware Memory controller (FMC)
> + in the Aspeed AST2500 SoC when attached to SPI NOR chips,
> + and support for the SPI flash memory controller (SPI) for
> + the host firmware. The implementation only supports SPI NOR.
> +
> config SPI_ATMEL_QUADSPI
> tristate "Atmel Quad SPI Controller"
> depends on ARCH_AT91 || (ARM && COMPILE_TEST)
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 121695e83542..d73d772c689c 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o
> +obj-$(CONFIG_SPI_ASPEED) += aspeed-smc.o
Can we make the symbol CONFIG_SPI_ASPEED_SMC?
Brendan has proposed a generic SPI master driver for the Aspeed SoC
that would allow the controller to be used for non-flash devices. The
obvious symbol for that driver is CONFIG_SPI_ASPEED.
Cheers,
Joel
--
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 1/8] MFD: add bindings for STM32 Timers driver
From: Lee Jones @ 2016-12-12 7:46 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
arnaud.pouliquen-qxv4g6HH51o,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Benjamin Gaignard
In-Reply-To: <1481292919-26587-2-git-send-email-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
On Fri, 09 Dec 2016, Benjamin Gaignard wrote:
> Add bindings information for STM32 Timers
>
> version 6:
> - rename stm32-gtimer to stm32-timers
> - change compatible
> - add description about the IPs
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> new file mode 100644
> index 0000000..b30868e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> @@ -0,0 +1,46 @@
> +STM32 Timers driver bindings
> +
> +This IP provides 3 types of timer along with PWM functionality:
> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
> + programmable prescaler and PWM outputs.
> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
> +
> +Required parameters:
> +- compatible: must be "st,stm32-timers"
> +
> +- reg: Physical base address and length of the controller's
> + registers.
> +- clock-names: Set to "clk_int".
> +- clocks: Phandle to the clock used by the timer module.
> + For Clk properties, please refer to ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets: Phandle to the parent reset controller.
> + See ../reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm: See ../pwm/pwm-stm32.txt
> +- timer: See ../iio/timer/stm32-timer-trigger.txt
> +
> +Example:
> + timers@40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
> + };
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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