* [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Krzysztof Kozlowski @ 2017-01-07 8:51 UTC (permalink / raw)
To: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Anand Moon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Marek Szyprowski, Sylwester Nawrocki, Peter Chen,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A, sre-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
Markus Reichl
Hi,
Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
Chen, we got a power sequence generic library which solves my long
standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
My previous attempts for this can be found here [0].
This patchset is based on Peter's v11 of power sequence [1].
Patchset is available also on my Github [2].
More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
LAN9730 on Odroid U3 after tftpboot").
Best regards,
Krzysztof
[0] http://www.spinics.net/lists/linux-mmc/msg37386.html
[1] https://lwn.net/Articles/710736/
[2] https://github.com/krzk/linux/commits/for-next/odroid-u3-usb3503-pwrseq
Krzysztof Kozlowski (4):
ARM: dts: exynos: Fix indentation of EHCI and OHCI ports
ARM: dts: exynos: Fix LAN9730 on Odroid U3 after tftpboot
ARM: exynos_defconfig: Enable power sequence for Odroid U3
ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
arch/arm/boot/dts/exynos4.dtsi | 24 ++++++++++++------------
arch/arm/boot/dts/exynos4412-odroidu3.dts | 21 +++++++++++++++++++++
arch/arm/configs/exynos_defconfig | 2 ++
arch/arm/configs/multi_v7_defconfig | 1 +
4 files changed, 36 insertions(+), 12 deletions(-)
--
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/4] ARM: dts: exynos: Fix indentation of EHCI and OHCI ports
From: Krzysztof Kozlowski @ 2017-01-07 8:52 UTC (permalink / raw)
To: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Anand Moon, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Cc: Marek Szyprowski, Sylwester Nawrocki, Peter Chen, gregkh, stern,
ulf.hansson, broonie, sre, robh+dt, linux-usb, linux-pm, hverkuil,
Markus Reichl
In-Reply-To: <20170107085203.4431-1-krzk@kernel.org>
Replace spaces with tabs in EHCI and OHCI ports indentation.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/boot/dts/exynos4.dtsi | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index c64737baa45e..3209c60389e2 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -370,19 +370,19 @@
#address-cells = <1>;
#size-cells = <0>;
port@0 {
- reg = <0>;
- phys = <&exynos_usbphy 1>;
- status = "disabled";
+ reg = <0>;
+ phys = <&exynos_usbphy 1>;
+ status = "disabled";
};
port@1 {
- reg = <1>;
- phys = <&exynos_usbphy 2>;
- status = "disabled";
+ reg = <1>;
+ phys = <&exynos_usbphy 2>;
+ status = "disabled";
};
port@2 {
- reg = <2>;
- phys = <&exynos_usbphy 3>;
- status = "disabled";
+ reg = <2>;
+ phys = <&exynos_usbphy 3>;
+ status = "disabled";
};
};
@@ -396,9 +396,9 @@
#address-cells = <1>;
#size-cells = <0>;
port@0 {
- reg = <0>;
- phys = <&exynos_usbphy 1>;
- status = "disabled";
+ reg = <0>;
+ phys = <&exynos_usbphy 1>;
+ status = "disabled";
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: exynos: Fix LAN9730 on Odroid U3 after tftpboot
From: Krzysztof Kozlowski @ 2017-01-07 8:52 UTC (permalink / raw)
To: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Anand Moon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Marek Szyprowski, Sylwester Nawrocki, Peter Chen,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A, sre-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
Markus Reichl
In-Reply-To: <20170107085203.4431-1-krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
The ethernet adapter LAN9730, after enabling in bootloader (e.g. for
tftpboot) requires reset during boot. Otherwise it won't come up.
The schematics of Odroid U3 are detailed enough but after grabbing
knowledge also from other sources (like U-Boot) the overall design looks
like:
1. LAN9730 is connected to HSIC0 and USB3503 to HSIC1 of EHCI controller.
2. USB3503 comes with its own reset pin: gpx3-5.
3. Reset pin of LAN9730 is pulled up to 3.3 V so it cannot be used.
4. The supply of 3.3 V for LAN9730 is delivered from buck8.
5. Buck8 state is a logical OR of registry value (through I2C command)
and ENB8 pin. The ENB8, not described in schematics, is in fact
gpa1-1.
6. Missing or wrongly timed reset of LAN9730 might result in missing of
two devices: LAN9730 and USB3503. Without reset, LAN9730 will not
come up, if it was enabled by bootloader.
To fix the issue use the generic power sequence driver and toggle the
ENB8 (buck8) pin. Reset duration of 500 us was chosen by experiments
(shortest working time was 400 us). This is an easiest way to fix the
long standing LAN9730 reset issue.
Signed-off-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 99634c54dca9..aef49007cba0 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -84,10 +84,23 @@
regulator-max-microvolt = <2800000>;
};
+&max77686 {
+ pinctrl-0 = <&max77686_irq &max77686_enb8>;
+};
+
&mshc_0 {
vqmmc-supply = <&ldo22_reg>;
};
+&pinctrl_0 {
+ max77686_enb8: max77686-enb8 {
+ samsung,pins = "gpa1-1";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
+ };
+};
+
&pwm {
pinctrl-0 = <&pwm0_out>;
pinctrl-names = "default";
@@ -103,7 +116,15 @@
&ehci {
port@1 {
+ /* HSIC for LAN9730 */
status = "okay";
+ /* buck8 enable pin, use it for power sequence */
+ reset-gpios = <&gpa1 1 GPIO_ACTIVE_LOW>;
+ /*
+ * Reset duration of 500 us was chosen experimentally.
+ * Minimal working value was 400 us. Add some safe margin.
+ */
+ reset-duration-us = <500>;
};
port@2 {
status = "okay";
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/4] ARM: exynos_defconfig: Enable power sequence for Odroid U3
From: Krzysztof Kozlowski @ 2017-01-07 8:52 UTC (permalink / raw)
To: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Anand Moon, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Cc: Marek Szyprowski, Sylwester Nawrocki, Peter Chen, gregkh, stern,
ulf.hansson, broonie, sre, robh+dt, linux-usb, linux-pm, hverkuil,
Markus Reichl
In-Reply-To: <20170107085203.4431-1-krzk@kernel.org>
Odroid U3 needs a power sequence for lan9730, if it was enabled by
bootloader. Enable also GPIO_SYSFS which is useful for playing with
GPIO during debug process.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/configs/exynos_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index 79c415c33f69..ad1a509c296a 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -99,6 +99,7 @@ CONFIG_SPI=y
CONFIG_SPI_GPIO=y
CONFIG_SPI_S3C64XX=y
CONFIG_DEBUG_GPIO=y
+CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_WM8994=y
CONFIG_POWER_SUPPLY=y
CONFIG_BATTERY_SBS=y
@@ -108,6 +109,7 @@ CONFIG_CHARGER_MAX14577=y
CONFIG_CHARGER_MAX77693=y
CONFIG_CHARGER_MAX8997=y
CONFIG_CHARGER_TPS65090=y
+CONFIG_PWRSEQ_GENERIC=y
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_NTC_THERMISTOR=y
CONFIG_SENSORS_PWM_FAN=y
--
2.9.3
^ permalink raw reply related
* [PATCH 4/4] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
From: Krzysztof Kozlowski @ 2017-01-07 8:52 UTC (permalink / raw)
To: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Anand Moon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Marek Szyprowski, Sylwester Nawrocki, Peter Chen,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A, sre-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
Markus Reichl
In-Reply-To: <20170107085203.4431-1-krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Odroid U3 needs a power sequence for lan9730, if it was enabled by
bootloader.
Signed-off-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index b01a43851294..1750d99862b9 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -443,6 +443,7 @@ CONFIG_POWER_RESET_RMOBILE=y
CONFIG_POWER_RESET_ST=y
CONFIG_POWER_AVS=y
CONFIG_ROCKCHIP_IODOMAIN=y
+CONFIG_PWRSEQ_GENERIC=y
CONFIG_SENSORS_IIO_HWMON=y
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_LM95245=y
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v11 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library
From: Krzysztof Kozlowski @ 2017-01-07 8:53 UTC (permalink / raw)
To: Peter Chen
Cc: gregkh, stern, ulf.hansson, broonie, sre, robh+dt, shawnguo, rjw,
dbaryshkov, heiko, linux-arm-kernel, p.zabel, devicetree,
pawel.moll, mark.rutland, linux-usb, arnd, s.hauer, mail,
troy.kisky, festevam, oscar, stephen.boyd, linux-pm,
stillcompiling, linux-kernel, mka, vaibhav.hiremath, gary.bisson,
hverkuil, krzk
In-Reply-To: <1483596119-27508-2-git-send-email-peter.chen@nxp.com>
On Thu, Jan 05, 2017 at 02:01:52PM +0800, Peter Chen wrote:
> Add binding doc for generic power sequence library.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v11 2/8] power: add power sequence library
From: Krzysztof Kozlowski @ 2017-01-07 8:54 UTC (permalink / raw)
To: Peter Chen
Cc: gregkh, stern, ulf.hansson, broonie, sre, robh+dt, shawnguo, rjw,
dbaryshkov, heiko, linux-arm-kernel, p.zabel, devicetree,
pawel.moll, mark.rutland, linux-usb, arnd, s.hauer, mail,
troy.kisky, festevam, oscar, stephen.boyd, linux-pm,
stillcompiling, linux-kernel, mka, vaibhav.hiremath, gary.bisson,
hverkuil, krzk
In-Reply-To: <1483596119-27508-3-git-send-email-peter.chen@nxp.com>
On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices. The pwrseq
> librares always need to allocate extra instance for compatible
> string match.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover other controls in
> future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence is needed, else call of_pwrseq_on_list
> /of_pwrseq_off_list instead (eg, USB hub driver).
>
> For new power sequence library, it can add its compatible string
> to pwrseq_of_match_table, then the pwrseq core will match it with
> DT's, and choose this library at runtime.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> MAINTAINERS | 9 +
> drivers/power/Kconfig | 1 +
> drivers/power/Makefile | 1 +
> drivers/power/pwrseq/Kconfig | 20 ++
> drivers/power/pwrseq/Makefile | 2 +
> drivers/power/pwrseq/core.c | 335 ++++++++++++++++++++++++++++++++++
> drivers/power/pwrseq/pwrseq_generic.c | 224 +++++++++++++++++++++++
> include/linux/power/pwrseq.h | 81 ++++++++
> 8 files changed, 673 insertions(+)
> create mode 100644 drivers/power/pwrseq/Kconfig
> create mode 100644 drivers/power/pwrseq/Makefile
> create mode 100644 drivers/power/pwrseq/core.c
> create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> create mode 100644 include/linux/power/pwrseq.h
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested on Odroid U3 (reset sequence for LAN9730):
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v11 3/8] binding-doc: usb: usb-device: add optional properties for power sequence
From: Krzysztof Kozlowski @ 2017-01-07 8:55 UTC (permalink / raw)
To: Peter Chen
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A, sre-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
rjw-LthD3rsA81gm4RdzfppkhA, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w,
heiko-4mtYJXux2i+zQB+pC5nmwQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
linux-usb-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
mail-APzI5cXaD1zVlRWJc41N0YvC60bnQu0Y,
troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR,
festevam-Re5JQEeQqe8AvxtiuMwx3w, oscar-Bdbr4918Nnnk1uMJSBkQmQ,
stephen.boyd-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
stillcompiling-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, mka-F7+t8E8rja9g9hUCZPvPmw,
vaibhav.hiremath-QSEj5FYQhm4dnm+yROfE0A,
gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, krzk-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1483596119-27508-4-git-send-email-peter.chen-3arQi8VN3Tc@public.gmane.org>
On Thu, Jan 05, 2017 at 02:01:54PM +0800, Peter Chen wrote:
> Add optional properties for power sequence.
>
> Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/usb-device.txt | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
Acked-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Best regards,
Krzysztof
--
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 v11 4/8] usb: core: add power sequence handling for USB devices
From: Krzysztof Kozlowski @ 2017-01-07 8:56 UTC (permalink / raw)
To: Peter Chen
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A, sre-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
rjw-LthD3rsA81gm4RdzfppkhA, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w,
heiko-4mtYJXux2i+zQB+pC5nmwQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
linux-usb-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
mail-APzI5cXaD1zVlRWJc41N0YvC60bnQu0Y,
troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR,
festevam-Re5JQEeQqe8AvxtiuMwx3w, oscar-Bdbr4918Nnnk1uMJSBkQmQ,
stephen.boyd-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
stillcompiling-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, mka-F7+t8E8rja9g9hUCZPvPmw,
vaibhav.hiremath-QSEj5FYQhm4dnm+yROfE0A,
gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, krzk-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1483596119-27508-5-git-send-email-peter.chen-3arQi8VN3Tc@public.gmane.org>
On Thu, Jan 05, 2017 at 02:01:55PM +0800, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to do it, it may cause some hard-wired USB devices
> works abnormal or can't be recognized by controller at all.
>
> In this patch, it calls power sequence library APIs to finish
> the power sequence events. It will do power on sequence at hub's
> probe for all devices under this hub (includes root hub).
> At hub_disconnect, it will do power off sequence which is at powered
> on list.
>
> Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
> Tested-by Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Maciej S. Szmigiero <mail-APzI5cXaD1zVlRWJc41N0YvC60bnQu0Y@public.gmane.org>
> Reviewed-by: Vaibhav Hiremath <hvaibhav.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/usb/Kconfig | 1 +
> drivers/usb/core/hub.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
> drivers/usb/core/hub.h | 1 +
> 3 files changed, 46 insertions(+), 4 deletions(-)
>
Acked-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Tested on Odroid U3 (reset sequence for LAN9730):
Tested-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Best regards,
Krzysztof
--
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 v1.1] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
From: Krzysztof Kozlowski @ 2017-01-07 9:16 UTC (permalink / raw)
To: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Anand Moon, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Cc: Marek Szyprowski, Sylwester Nawrocki, Peter Chen, gregkh, stern,
ulf.hansson, broonie, sre, robh+dt, linux-usb, linux-pm, hverkuil,
Markus Reichl
In-Reply-To: <20170107085203.4431-5-krzk@kernel.org>
Odroid U3 needs a power sequence for lan9730, if it was enabled by
bootloader. Also enable the USB3503 HSCI to USB2.0 driver (device
is present on Odroid U3).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v1 (v1 -> v1.1):
1. Enable also usb3503 driver.
---
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index b01a43851294..8cc73e084b25 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -443,6 +443,7 @@ CONFIG_POWER_RESET_RMOBILE=y
CONFIG_POWER_RESET_ST=y
CONFIG_POWER_AVS=y
CONFIG_ROCKCHIP_IODOMAIN=y
+CONFIG_PWRSEQ_GENERIC=y
CONFIG_SENSORS_IIO_HWMON=y
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_LM95245=y
@@ -686,6 +687,7 @@ CONFIG_USB_DWC2=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_HSIC_USB3503=m
CONFIG_AB8500_USB=y
CONFIG_KEYSTONE_USB_PHY=y
CONFIG_OMAP_USB3=y
--
2.9.3
^ permalink raw reply related
* Re: [PATCHv2 net-next 15/16] net: mvpp2: add support for an additional clock needed for PPv2.2
From: Russell King - ARM Linux @ 2017-01-07 9:29 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Andrew Lunn,
Yehuda Yitschak, Jason Cooper, Hanna Hawa, Nadav Haklai,
Gregory Clement, Stefan Chulski, Marcin Wojtas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <1482943592-12556-16-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, Dec 28, 2016 at 05:46:31PM +0100, Thomas Petazzoni wrote:
> The PPv2.2 variant of the network controller needs an additional
> clock, the "MG clock" in order for the IP block to operate
> properly. This commit adds support for this additional clock to the
> driver, reworking as needed the error handling path.
There's more clocks that are required.
Firstly, what I'm finding is that the MDIO block in the CP110 does not
work at all (locks the system up if accessed) if these clocks are not
enabled:
cpm_syscon0 1 9, cpm_syscon0 1 6, cpm_syscon0 1 5
The XMDIO block requires the same clocks to be functional. Since the
MDIO and XMDIO blocks are actually part of the ethernet controller,
it's not that surprising.
We can't rely on the ethernet controller having been probed, because
the 8k has two sets of MDIO buses - one set per CP110. It's entirely
possible that people will put all their PHYs for both CP110 instances
on one set of MDIO buses (eg, the master). Indeed, this is exactly
what SolidRun have done, and hence how I found the problem.
So, it looks to me like DT doesn't actually describe the hardware here -
especially when looking at the reg properties, they overlap with each
other.
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> drivers/net/ethernet/marvell/mvpp2.c | 25 +++++++++++++++++++++----
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
> index 20e9429..194de00 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -702,6 +702,7 @@ struct mvpp2 {
> /* Common clocks */
> struct clk *pp_clk;
> struct clk *gop_clk;
> + struct clk *mg_clk;
>
> /* List of pointers to port structures */
> struct mvpp2_port **port_list;
> @@ -6899,6 +6900,18 @@ static int mvpp2_probe(struct platform_device *pdev)
> if (err < 0)
> goto err_pp_clk;
>
> + if (priv->hw_version == MVPP22) {
> + priv->mg_clk = devm_clk_get(&pdev->dev, "mg_clk");
> + if (IS_ERR(priv->mg_clk)) {
> + err = PTR_ERR(priv->mg_clk);
> + goto err_gop_clk;
> + }
> +
> + err = clk_prepare_enable(priv->mg_clk);
> + if (err < 0)
> + goto err_gop_clk;
> + }
> +
> /* Get system's tclk rate */
> priv->tclk = clk_get_rate(priv->pp_clk);
>
> @@ -6906,14 +6919,14 @@ static int mvpp2_probe(struct platform_device *pdev)
> err = mvpp2_init(pdev, priv);
> if (err < 0) {
> dev_err(&pdev->dev, "failed to initialize controller\n");
> - goto err_gop_clk;
> + goto err_mg_clk;
> }
>
> port_count = of_get_available_child_count(dn);
> if (port_count == 0) {
> dev_err(&pdev->dev, "no ports enabled\n");
> err = -ENODEV;
> - goto err_gop_clk;
> + goto err_mg_clk;
> }
>
> priv->port_list = devm_kcalloc(&pdev->dev, port_count,
> @@ -6921,19 +6934,22 @@ static int mvpp2_probe(struct platform_device *pdev)
> GFP_KERNEL);
> if (!priv->port_list) {
> err = -ENOMEM;
> - goto err_gop_clk;
> + goto err_mg_clk;
> }
>
> /* Initialize ports */
> for_each_available_child_of_node(dn, port_node) {
> err = mvpp2_port_probe(pdev, port_node, priv);
> if (err < 0)
> - goto err_gop_clk;
> + goto err_mg_clk;
> }
>
> platform_set_drvdata(pdev, priv);
> return 0;
>
> +err_mg_clk:
> + if (priv->hw_version == MVPP22)
> + clk_disable_unprepare(priv->mg_clk);
> err_gop_clk:
> clk_disable_unprepare(priv->gop_clk);
> err_pp_clk:
> @@ -6969,6 +6985,7 @@ static int mvpp2_remove(struct platform_device *pdev)
> aggr_txq->descs_phys);
> }
>
> + clk_disable_unprepare(priv->mg_clk);
> clk_disable_unprepare(priv->pp_clk);
> clk_disable_unprepare(priv->gop_clk);
>
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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: [PATCHv2 net-next 01/16] dt-bindings: net: update Marvell PPv2 binding for PPv2.2 support
From: Russell King - ARM Linux @ 2017-01-07 9:32 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Andrew Lunn,
Yehuda Yitschak, Jason Cooper, Hanna Hawa, Nadav Haklai,
Gregory Clement, Stefan Chulski, Marcin Wojtas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <1482943592-12556-2-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, Dec 28, 2016 at 05:46:17PM +0100, Thomas Petazzoni wrote:
> @@ -31,7 +43,7 @@ Optional properties (port):
> then fixed link is assumed, and the 'fixed-link' property is
> mandatory.
Not directly related to this patch, but this context is wrong. The
PP2 driver _requires_ a PHY. It doesn't support fixed-link in its
current form. I think the DT binding describes an expectation of
a future driver.
The side effect is that if trying to use a fixed-link on any port,
the ethernet driver fails to probe.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Russell King - ARM Linux @ 2017-01-07 9:38 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Mark Rutland, devicetree, Yehuda Yitschak, Jason Cooper,
Pawel Moll, Ian Campbell, netdev, Hanna Hawa, Nadav Haklai,
Rob Herring, Andrew Lunn, Kumar Gala, Gregory Clement,
Stefan Chulski, Marcin Wojtas, David S. Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1482943592-12556-12-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> @@ -6511,7 +6515,9 @@ static int mvpp2_port_probe(struct platform_device *pdev,
> dev_err(&pdev->dev, "failed to init port %d\n", id);
> goto err_free_stats;
> }
> - mvpp2_port_power_up(port);
> +
> + if (priv->hw_version == MVPP21)
> + mvpp21_port_power_up(port);
This has the side effect that nothing clears the port reset bit in the
GMAC, which means there's no hope of the interface working - with the
reset bit set, the port is well and truely held in "link down" state.
In any case, the GMAC part is much the same as mvneta, and I think
that code should be shared rather than writing new versions of it.
There are some subtle differences between neta, pp2.1 and pp2.2, but
it's entirely doable (I have an implementation here as I wasn't going
to duplicate this code for my phylink conversion.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] adc: add adc driver for Hisilicon BVT SOCs
From: Allen Liu @ 2017-01-07 10:16 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland
Cc: akinobu.mita, ludovic.desroches, krzk, vilhelm.gray,
ksenija.stanojevic, zhiyong.tao, daniel.baluta, leonard.crestez,
ray.jui, raveendra.padasalagi, mranostay, amsfield22, linux-iio,
devicetree, linux-kernel, xuejiancheng, kevin.lixu, liurenzhong
Add ADC driver for the ADC controller found on HiSilicon BVT SOCs, like Hi3516CV300, etc.
The ADC controller is primarily in charge of detecting voltage.
Reviewed-by: Kevin Li <kevin.lixu@hisilicon.com>
Signed-off-by: Allen Liu <liurenzhong@hisilicon.com>
---
.../devicetree/bindings/iio/adc/hibvt-lsadc.txt | 23 ++
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/hibvt_lsadc.c | 335 +++++++++++++++++++++
4 files changed, 369 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
create mode 100644 drivers/iio/adc/hibvt_lsadc.c
diff --git a/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
new file mode 100644
index 0000000..fce1ff4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
@@ -0,0 +1,23 @@
+Hisilicon BVT Low Speed (LS) A/D Converter bindings
+
+Required properties:
+- compatible: should be "hisilicon,<name>-lsadc"
+ - "hisilicon,hi3516cv300-lsadc": for hi3516cv300
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: The interrupt number for the ADC device.
+
+Optional properties:
+- resets: Must contain an entry for each entry in reset-names if need support
+ this option. See ../../reset/reset.txt for details.
+- reset-names: Must include the name "lsadc-crg".
+
+Example:
+ adc: adc@120e0000 {
+ compatible = "hisilicon,hi3516cv300-lsadc";
+ reg = <0x120e0000 0x1000>;
+ interrupts = <19>;
+ resets = <&crg 0x7c 3>;
+ reset-names = "lsadc-crg";
+ };
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 99c0514..0443f51 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -225,6 +225,16 @@ config HI8435
This driver can also be built as a module. If so, the module will be
called hi8435.
+config HIBVT_LSADC
+ tristate "HIBVT LSADC driver"
+ depends on ARCH_HISI || COMPILE_TEST
+ help
+ Say yes here to build support for the LSADC found in SoCs from
+ hisilicon BVT chip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hibvt_lsadc.
+
config INA2XX_ADC
tristate "Texas Instruments INA2xx Power Monitors IIO driver"
depends on I2C && !SENSORS_INA2XX
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04..6554d92 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
obj-$(CONFIG_HI8435) += hi8435.o
+obj-$(CONFIG_HIBVT_LSADC) += hibvt_lsadc.o
obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
diff --git a/drivers/iio/adc/hibvt_lsadc.c b/drivers/iio/adc/hibvt_lsadc.c
new file mode 100644
index 0000000..aaf2024
--- /dev/null
+++ b/drivers/iio/adc/hibvt_lsadc.c
@@ -0,0 +1,335 @@
+/*
+ * Hisilicon BVT Low Speed (LS) A/D Converter
+ * Copyright (C) 2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/reset.h>
+#include <linux/regulator/consumer.h>
+#include <linux/iio/iio.h>
+
+/* hisilicon bvt adc registers definitions */
+#define HIBVT_LSADC_CONFIG 0x00
+#define HIBVT_CONFIG_DEGLITCH BIT(17)
+#define HIBVT_CONFIG_RESET BIT(15)
+#define HIBVT_CONFIG_POWERDOWN BIT(14)
+#define HIBVT_CONFIG_MODE BIT(13)
+#define HIBVT_CONFIG_CHNC BIT(10)
+#define HIBVT_CONFIG_CHNB BIT(9)
+#define HIBVT_CONFIG_CHNA BIT(8)
+
+#define HIBVT_LSADC_TIMESCAN 0x08
+#define HIBVT_LSADC_INTEN 0x10
+#define HIBVT_LSADC_INTSTATUS 0x14
+#define HIBVT_LSADC_INTCLR 0x18
+#define HIBVT_LSADC_START 0x1C
+#define HIBVT_LSADC_STOP 0x20
+#define HIBVT_LSADC_ACTBIT 0x24
+#define HIBVT_LSADC_CHNDATA 0x2C
+
+#define HIBVT_LSADC_CON_EN (1u << 0)
+#define HIBVT_LSADC_CON_DEN (0u << 0)
+
+#define HIBVT_LSADC_NUM_BITS_V1 10
+#define HIBVT_LSADC_CHN_MASK_v1 0x7
+
+/* fix clk:3000000, default tscan set 10ms */
+#define HIBVT_LSADC_TSCAN_MS (10*3000)
+
+#define HIBVT_LSADC_TIMEOUT msecs_to_jiffies(100)
+
+/* default voltage scale for every channel <mv> */
+static int g_hibvt_lsadc_voltage[] = {
+ 3300, 3300, 3300
+};
+
+struct hibvt_lsadc {
+ void __iomem *regs;
+ struct completion completion;
+ struct reset_control *reset;
+ const struct hibvt_lsadc_data *data;
+ unsigned int cur_chn;
+ unsigned int value;
+};
+
+struct hibvt_lsadc_data {
+ int num_bits;
+ const struct iio_chan_spec *channels;
+ int num_channels;
+
+ void (*clear_irq)(struct hibvt_lsadc *info, int mask);
+ void (*start_conv)(struct hibvt_lsadc *info);
+ void (*stop_conv)(struct hibvt_lsadc *info);
+};
+
+static int hibvt_lsadc_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct hibvt_lsadc *info = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ mutex_lock(&indio_dev->mlock);
+
+ reinit_completion(&info->completion);
+
+ /* Select the channel to be used */
+ info->cur_chn = chan->channel;
+
+ if (info->data->start_conv)
+ info->data->start_conv(info);
+
+ if (!wait_for_completion_timeout(&info->completion,
+ HIBVT_LSADC_TIMEOUT)) {
+ if (info->data->stop_conv)
+ info->data->stop_conv(info);
+ mutex_unlock(&indio_dev->mlock);
+ return -ETIMEDOUT;
+ }
+
+ *val = info->value;
+ mutex_unlock(&indio_dev->mlock);
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = g_hibvt_lsadc_voltage[chan->channel];
+ *val2 = info->data->num_bits;
+ return IIO_VAL_FRACTIONAL_LOG2;
+ default:
+ return -EINVAL;
+ }
+}
+
+static irqreturn_t hibvt_lsadc_isr(int irq, void *dev_id)
+{
+ struct hibvt_lsadc *info = (struct hibvt_lsadc *)dev_id;
+ int mask;
+
+ mask = readl(info->regs + HIBVT_LSADC_INTSTATUS);
+ if ((mask & HIBVT_LSADC_CHN_MASK_v1) == 0)
+ return IRQ_NONE;
+
+ /* Clear irq */
+ mask &= HIBVT_LSADC_CHN_MASK_v1;
+ if (info->data->clear_irq)
+ info->data->clear_irq(info, mask);
+
+ /* Read value */
+ info->value = readl(info->regs +
+ HIBVT_LSADC_CHNDATA + (info->cur_chn << 2));
+ info->value &= GENMASK(info->data->num_bits - 1, 0);
+
+ /* stop adc */
+ if (info->data->stop_conv)
+ info->data->stop_conv(info);
+
+ complete(&info->completion);
+
+ return IRQ_HANDLED;
+}
+
+static const struct iio_info hibvt_lsadc_iio_info = {
+ .read_raw = hibvt_lsadc_read_raw,
+ .driver_module = THIS_MODULE,
+};
+
+#define HIBVT_LSADC_CHANNEL(_index, _id) { \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = _index, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+ .datasheet_name = _id, \
+}
+
+static const struct iio_chan_spec hibvt_lsadc_iio_channels[] = {
+ HIBVT_LSADC_CHANNEL(0, "adc0"),
+ HIBVT_LSADC_CHANNEL(1, "adc1"),
+ HIBVT_LSADC_CHANNEL(2, "adc2"),
+};
+
+static void hibvt_lsadc_v1_clear_irq(struct hibvt_lsadc *info, int mask)
+{
+ writel(mask, info->regs + HIBVT_LSADC_INTCLR);
+}
+
+static void hibvt_lsadc_v1_start_conv(struct hibvt_lsadc *info)
+{
+ unsigned int con;
+
+ /* set number bit */
+ con = GENMASK(info->data->num_bits - 1, 0);
+ writel(con, (info->regs + HIBVT_LSADC_ACTBIT));
+
+ /* config */
+ con = readl(info->regs + HIBVT_LSADC_CONFIG);
+ con &= ~HIBVT_CONFIG_RESET;
+ con |= (HIBVT_CONFIG_POWERDOWN | HIBVT_CONFIG_DEGLITCH |
+ HIBVT_CONFIG_MODE);
+ con &= ~(HIBVT_CONFIG_CHNA | HIBVT_CONFIG_CHNB | HIBVT_CONFIG_CHNC);
+ con |= (HIBVT_CONFIG_CHNA << info->cur_chn);
+ writel(con, (info->regs + HIBVT_LSADC_CONFIG));
+
+ /* set timescan */
+ writel(HIBVT_LSADC_TSCAN_MS, (info->regs + HIBVT_LSADC_TIMESCAN));
+
+ /* clear interrupt */
+ writel(HIBVT_LSADC_CHN_MASK_v1, info->regs + HIBVT_LSADC_INTCLR);
+
+ /* enable interrupt */
+ writel(HIBVT_LSADC_CON_EN, (info->regs + HIBVT_LSADC_INTEN));
+
+ /* start scan */
+ writel(HIBVT_LSADC_CON_EN, (info->regs + HIBVT_LSADC_START));
+}
+
+static void hibvt_lsadc_v1_stop_conv(struct hibvt_lsadc *info)
+{
+ /* reset the timescan */
+ writel(HIBVT_LSADC_CON_DEN, (info->regs + HIBVT_LSADC_TIMESCAN));
+
+ /* disable interrupt */
+ writel(HIBVT_LSADC_CON_DEN, (info->regs + HIBVT_LSADC_INTEN));
+
+ /* stop scan */
+ writel(HIBVT_LSADC_CON_EN, (info->regs + HIBVT_LSADC_STOP));
+}
+
+static const struct hibvt_lsadc_data lsadc_data_v1 = {
+ .num_bits = HIBVT_LSADC_NUM_BITS_V1,
+ .channels = hibvt_lsadc_iio_channels,
+ .num_channels = ARRAY_SIZE(hibvt_lsadc_iio_channels),
+
+ .clear_irq = hibvt_lsadc_v1_clear_irq,
+ .start_conv = hibvt_lsadc_v1_start_conv,
+ .stop_conv = hibvt_lsadc_v1_stop_conv,
+};
+
+static const struct of_device_id hibvt_lsadc_match[] = {
+ {
+ .compatible = "hisilicon,hi3516cv300-lsadc",
+ .data = &lsadc_data_v1,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, hibvt_lsadc_match);
+
+/* Reset LSADC Controller */
+static void hibvt_lsadc_reset_controller(struct reset_control *reset)
+{
+ reset_control_assert(reset);
+ usleep_range(10, 20);
+ reset_control_deassert(reset);
+}
+
+static int hibvt_lsadc_probe(struct platform_device *pdev)
+{
+ struct hibvt_lsadc *info = NULL;
+ struct device_node *np = pdev->dev.of_node;
+ struct iio_dev *indio_dev = NULL;
+ struct resource *mem;
+ const struct of_device_id *match;
+ int ret;
+ int irq;
+
+ if (!np)
+ return -ENODEV;
+
+ indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
+ if (!indio_dev) {
+ dev_err(&pdev->dev, "failed allocating iio device\n");
+ return -ENOMEM;
+ }
+ info = iio_priv(indio_dev);
+
+ match = of_match_device(hibvt_lsadc_match, &pdev->dev);
+ info->data = match->data;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ info->regs = devm_ioremap_resource(&pdev->dev, mem);
+ if (IS_ERR(info->regs))
+ return PTR_ERR(info->regs);
+
+ /*
+ * The reset should be an optional property, as it should work
+ * with old devicetrees as well
+ */
+ info->reset = devm_reset_control_get(&pdev->dev, "lsadc-crg");
+ if (IS_ERR(info->reset)) {
+ ret = PTR_ERR(info->reset);
+ if (ret != -ENOENT)
+ return ret;
+
+ dev_dbg(&pdev->dev, "no reset control found\n");
+ info->reset = NULL;
+ }
+
+ init_completion(&info->completion);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "no irq resource?\n");
+ return irq;
+ }
+
+ ret = devm_request_irq(&pdev->dev, irq, hibvt_lsadc_isr,
+ 0, dev_name(&pdev->dev), info);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed requesting irq %d\n", irq);
+ return ret;
+ }
+
+ if (info->reset)
+ hibvt_lsadc_reset_controller(info->reset);
+
+ platform_set_drvdata(pdev, indio_dev);
+
+ indio_dev->name = dev_name(&pdev->dev);
+ indio_dev->dev.parent = &pdev->dev;
+ indio_dev->dev.of_node = pdev->dev.of_node;
+ indio_dev->info = &hibvt_lsadc_iio_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ indio_dev->channels = info->data->channels;
+ indio_dev->num_channels = info->data->num_channels;
+
+ ret = devm_iio_device_register(&pdev->dev, indio_dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed register iio device\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct platform_driver hibvt_lsadc_driver = {
+ .probe = hibvt_lsadc_probe,
+ .driver = {
+ .name = "hibvt-lsadc",
+ .of_match_table = hibvt_lsadc_match,
+ },
+};
+
+module_platform_driver(hibvt_lsadc_driver);
+
+MODULE_AUTHOR("Allen Liu <liurenzhong@hisilicon.com>");
+MODULE_DESCRIPTION("hisilicon BVT LSADC driver");
+MODULE_LICENSE("GPL v2");
--
2.1.4
^ permalink raw reply related
* Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Russell King - ARM Linux @ 2017-01-07 11:03 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: netdev, David S. Miller, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Andrew Lunn,
Yehuda Yitschak, Jason Cooper, Hanna Hawa, Nadav Haklai,
Gregory Clement, Stefan Chulski, Marcin Wojtas, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1482943592-12556-12-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> +#define MVPP22_SMI_MISC_CFG_REG 0x2a204
> +#define MVPP22_SMI_POLLING_EN BIT(10)
> +
...
> + if (priv->hw_version == MVPP21) {
> + val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
> + val |= MVPP2_PHY_AN_STOP_SMI0_MASK;
> + writel(val, priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
> + } else {
> + val = readl(priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
> + val &= ~MVPP22_SMI_POLLING_EN;
> + writel(val, priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
> + }
The MVPP22_SMI_MISC_CFG_REG register is within the MDIO driver's
register set, although the mvmdio driver does not access this register.
Shouldn't this be taken care of by the mvmdio driver?
Also, a point that I've noticed while reviewing this is the mvmdio
driver also accesses these registers:
#define MVMDIO_ERR_INT_CAUSE 0x007C
#define MVMDIO_ERR_INT_MASK 0x0080
in addition to the un-named register at offset 0. The driver writes
to these registers unconditionally when unbinding:
writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
However, the various bindings for the driver have:
arch/arm/boot/dts/armada-370-xp.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-370-xp.dtsi- reg = <0x72004 0x4>;
arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-375.dtsi- reg = <0xc0054 0x4>;
arch/arm/boot/dts/dove.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/dove.dtsi- #address-cells = <1>;
arch/arm/boot/dts/dove.dtsi- #size-cells = <0>;
arch/arm/boot/dts/dove.dtsi- reg = <0x72004 0x84>;
arch/arm/boot/dts/orion5x.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/orion5x.dtsi- #address-cells = <1>;
arch/arm/boot/dts/orion5x.dtsi- #size-cells = <0>;
arch/arm/boot/dts/orion5x.dtsi- reg = <0x72004 0x84>;
arch/arm/boot/dts/kirkwood.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/kirkwood.dtsi- #address-cells = <1>;
arch/arm/boot/dts/kirkwood.dtsi- #size-cells = <0>;
arch/arm/boot/dts/kirkwood.dtsi- reg = <0x72004 0x84>;
arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-38x.dtsi- reg = <0x72004 0x4>;
So, for many of these, we're accessing registers outside of the given
binding, which sounds incorrect. I guess that write should be
conditional upon an interrupt being present.
The binding document says:
- reg: address and length of the SMI register
which is clearly wrong for those cases where the interrupt is used.
I also notice that the binding for CP110 uses a register size of 0x10
(even in your tree) - but I guess this should be 4.
I'm starting to wonder whether the orion-mdio driver really is a
separate chunk of hardware that warrants a separate description in
DT from the ethernet controller - it appears in all cases to be
embedded with an ethernet controller, sharing its register space
and at least some of the ethernet controllers clocks. That says
to me that it isn't an independent functional unit of hardware.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] of: remove redundant memset in overlay
From: YiPing Xu @ 2017-01-07 11:04 UTC (permalink / raw)
To: xuyiping-C8/M+/jPZTeaMJb+Lgu22Q,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: XuYing <xuyiping-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
memset in of_build_overlay_info is redundant, the ovinfo has been
zeroed in of_fill_overlay_info when error.
Signed-off-by: YiPing Xu <xuyiping-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
drivers/of/overlay.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 0d4cda7..4b1b6b3 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -314,7 +314,6 @@ static int of_build_overlay_info(struct of_overlay *ov,
cnt = 0;
for_each_child_of_node(tree, node) {
- memset(&ovinfo[cnt], 0, sizeof(*ovinfo));
err = of_fill_overlay_info(ov, node, &ovinfo[cnt]);
if (err == 0)
cnt++;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH RFC 0/4] Fix orion-mdio resource/interrupt issues indentified while reviewing mvpp2
From: Russell King - ARM Linux @ 2017-01-07 11:26 UTC (permalink / raw)
To: Thomas Petazzoni, Andrew Lunn, Jason Cooper, Gregory Clement,
Mark Rutland, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Marcin Wojtas,
netdev-u79uwXL29TY76Z2rM5mHXA, Sebastian Hesselbarth
This patch series fixes some issues identified while reviewing the
mvpp2 driver changes recently posted by Thomas. I've left the clock
issue, and the question over whether this should be separate out of
this series, concentrating on the resource size / interrupt issue.
This series updates the binding to reflect reality, and ensures that
the driver will not try to access registers outside its binding. It
also ensures that it doesn't leave the interrupt enabled in hardware
on probe failure.
.../devicetree/bindings/net/marvell-orion-mdio.txt | 17 +++++++++++++++--
drivers/net/ethernet/marvell/mvmdio.c | 11 ++++++++++-
2 files changed, 25 insertions(+), 3 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 RFC 3/4] dt-bindings: correct marvell orion MDIO binding document
From: Russell King @ 2017-01-07 11:28 UTC (permalink / raw)
To: Thomas Petazzoni, Andrew Lunn, Jason Cooper, Gregory Clement,
Mark Rutland, Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Marcin Wojtas,
Sebastian Hesselbarth, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170107112656.GL14217-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Correct the Marvell Orion MDIO binding document to properly reflect the
cases where an interrupt is present. Augment the examples to show this.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
.../devicetree/bindings/net/marvell-orion-mdio.txt | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 9417e54c26c0..ca733ff68ab9 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -7,7 +7,10 @@ interface.
Required properties:
- compatible: "marvell,orion-mdio"
-- reg: address and length of the SMI register
+- reg: address and length of the MDIO registers. When an interrupt is
+ not present, the length is the size of the SMI register (4 bytes)
+ otherwise it must be 0x84 bytes to cover the interrupt control
+ registers.
Optional properties:
- interrupts: interrupt line number for the SMI error/done interrupt
@@ -17,7 +20,7 @@ The child nodes of the MDIO driver are the individual PHY devices
connected to this MDIO bus. They must have a "reg" property given the
PHY address on the MDIO bus.
-Example at the SoC level:
+Example at the SoC level without an interrupt property:
mdio {
#address-cells = <1>;
@@ -26,6 +29,16 @@ mdio {
reg = <0xd0072004 0x4>;
};
+Example with an interrupt property:
+
+mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0xd0072004 0x84>;
+ interrupts = <30>;
+};
+
And at the board level:
mdio {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Marcin Wojtas @ 2017-01-07 12:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Thomas Petazzoni, devicetree@vger.kernel.org, Yehuda Yitschak,
Jason Cooper, Pawel Moll, Ian Campbell, netdev, Hanna Hawa,
Nadav Haklai, Rob Herring, Andrew Lunn, Kumar Gala,
Gregory Clement, Stefan Chulski, Mark Rutland, David S. Miller,
linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth
In-Reply-To: <20170107110351.GK14217@n2100.armlinux.org.uk>
Hi Russel,
2017-01-07 12:03 GMT+01:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
>> +#define MVPP22_SMI_MISC_CFG_REG 0x2a204
>> +#define MVPP22_SMI_POLLING_EN BIT(10)
>> +
> ...
>> + if (priv->hw_version == MVPP21) {
>> + val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
>> + val |= MVPP2_PHY_AN_STOP_SMI0_MASK;
>> + writel(val, priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
>> + } else {
>> + val = readl(priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
>> + val &= ~MVPP22_SMI_POLLING_EN;
>> + writel(val, priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
>> + }
>
> The MVPP22_SMI_MISC_CFG_REG register is within the MDIO driver's
> register set, although the mvmdio driver does not access this register.
> Shouldn't this be taken care of by the mvmdio driver?
>
> Also, a point that I've noticed while reviewing this is the mvmdio
> driver also accesses these registers:
>
> #define MVMDIO_ERR_INT_CAUSE 0x007C
> #define MVMDIO_ERR_INT_MASK 0x0080
>
> in addition to the un-named register at offset 0. The driver writes
> to these registers unconditionally when unbinding:
>
> writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
>
> However, the various bindings for the driver have:
>
> arch/arm/boot/dts/armada-370-xp.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-370-xp.dtsi- reg = <0x72004 0x4>;
> arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-375.dtsi- reg = <0xc0054 0x4>;
> arch/arm/boot/dts/dove.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/dove.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/dove.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/dove.dtsi- reg = <0x72004 0x84>;
> arch/arm/boot/dts/orion5x.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/orion5x.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/orion5x.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/orion5x.dtsi- reg = <0x72004 0x84>;
> arch/arm/boot/dts/kirkwood.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/kirkwood.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/kirkwood.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/kirkwood.dtsi- reg = <0x72004 0x84>;
> arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-38x.dtsi- reg = <0x72004 0x4>;
>
> So, for many of these, we're accessing registers outside of the given
> binding, which sounds incorrect. I guess that write should be
> conditional upon an interrupt being present.
>
> The binding document says:
>
> - reg: address and length of the SMI register
>
> which is clearly wrong for those cases where the interrupt is used.
>
> I also notice that the binding for CP110 uses a register size of 0x10
> (even in your tree) - but I guess this should be 4.
>
> I'm starting to wonder whether the orion-mdio driver really is a
> separate chunk of hardware that warrants a separate description in
> DT from the ethernet controller - it appears in all cases to be
> embedded with an ethernet controller, sharing its register space
> and at least some of the ethernet controllers clocks. That says
> to me that it isn't an independent functional unit of hardware.
>
In fact there is common SMI bus, but each port has its own register
set to control it (it's true at least for Neta and PP2). There is also
an option to use HW polling - every 1s hardware checks PHY over SMI
and updates MAC registers of each port independently. I was able to
use those successfully in other implementations.
However we are supposed to use libphy in Linux and I'm afraid we have
to use single instance that controls single SMI bus - I think current
implementation is a compromise between HW and libphy demands.
Best regards,
Marcin
^ permalink raw reply
* Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node
From: Andi Shyti @ 2017-01-07 12:40 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Andi Shyti, Dmitry Torokhov, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Chanwoo Choi, Beomho Seo,
linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc, Jaechul Lee, Andi Shyti, Jaechul Lee
In-Reply-To: <CAGTfZH1QtbieMxQzoPvxsP_3tSYBSuXe+wtq0uUs03mhcLFdXg@mail.gmail.com>
Hi Chanwoo,
> >>> + touchkey@20 {
> >>> + compatible = "samsung,tm2-touchkey";
> >>> + reg = <0x20>;
> >>> + interrupt-parent = <&gpa3>;
> >>> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> >>> + vcc-supply = <&ldo32_reg>;
> >>> + vdd-supply = <&ldo33_reg>;
> >>> + };
> >>> +};
> >>> +
> >>> &ldo31_reg {
> >>> regulator-name = "TSP_VDD_1.85V_AP";
> >>> regulator-min-microvolt = <1850000>;
>
> I repiled the touchkey driver against compatible name.
> Usually, when developing the device driver, we use the specific h/w name
> but in this patch, the touckey dt node uses the h/w board name instead of
> original touckhey name.
this should be a device specifically done for the tm2 and we are
not sure who is the manufacturer of the device. In order to not
assign the device to the wrong manufacturer, we preferred calling
it Samsung as it is in a Samsung device.
Andi
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Arend Van Spriel @ 2017-01-07 12:52 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Johannes Berg,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rob Herring, Rafał Miłecki
In-Reply-To: <CACna6rw22benfuw_7BSFw1wedavmMJWTo_hfPLCVa1t0kV+Aqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 5-1-2017 11:02, Rafał Miłecki wrote:
> On 5 January 2017 at 10:31, Arend Van Spriel
> <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>> On 4-1-2017 22:19, Rafał Miłecki wrote:
>>> On 4 January 2017 at 21:07, Arend Van Spriel
>>> <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>>> On 4-1-2017 18:58, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>>
>>>>> There are some devices (e.g. Netgear R8000 home router) with one chipset
>>>>> model used for different radios, some of them limited to subbands. NVRAM
>>>>> entries don't contain any extra info on such limitations and firmware
>>>>> reports full list of channels to us. We need to store extra limitation
>>>>> info in DT to support such devices properly.
>>>>>
>>>>> Now there is a cfg80211 helper for reading such info use it in brcmfmac.
>>>>> This patch adds check for channel being disabled with orig_flags which
>>>>> is how this wiphy helper and wiphy_register work.
>>>>>
>>>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>> ---
>>>>> This patch should probably go through wireless-driver-next which is why
>>>>> it got weird number 4/3. I'm sending it just as a proof of concept.
>>>>> It was succesfully tested on SmartRG SR400ac with BCM43602.
>>>>>
>>>>> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
>>>>> V5: Update commit message
>>>>> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it work
>>>>> with helper setting "flags" instead of "orig_flags".
>>>>> ---
>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 ++++++++-
>>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> index ccae3bb..a008ba5 100644
>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
>>>>> band->band);
>>>>> channel[index].hw_value = ch.control_ch_num;
>>>>>
>>>>> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
>>>>> + continue;
>>>>> +
>>>>
>>>> So to be clear this is still needed for subsequent calls to
>>>> brcmf_setup_wiphybands(). The subsequent calls are done from the
>>>> regulatory notifier. So I think we have an issue with this approach. Say
>>>> the device comes up with US. That would set DISABLED flags for channels
>>>> 12 to 14. With a country update to PL we would want to enable channels
>>>> 12 and 13, right? The orig_flags are copied from the initial flags
>>>> during wiphy_register() so it seems we will skip enabling 12 and 13. I
>>>> think we should remove the check above and call
>>>> wiphy_read_of_freq_limits() as a last step within
>>>> brcmf_setup_wiphybands(). It means it is called every time, but it
>>>> safeguards that the limits in DT are always applied.
>>>
>>> I'm not exactly happy with channels management in brcmfmac. Before
>>> calling wiphy_register it already disables channels unavailable for
>>> current country. This results in setting IEEE80211_CHAN_DISABLED in
>>
>> What do you mean by current country. There is none that we are aware off
>> in the driver. So we obtain the channels for the current
>> country/revision in the firmware and enable those before
>> wiphy_register(). This all is within the probe/init sequence so I do not
>> really see an issue. As the wiphy object is not yet registered there is
>> no user-space awareness
>
> It seems I'm terrible as describing my patches/problems/ideas :( Here
> I used 1 inaccurate word and you couldn't understand my point.
Well. Because of our track record of miscommunication and other
annoyances I want to be sure this time :-p
> By "current country" I meant current region (and so a set of
> regulatory rules) used by the firmware. I believe firmware describes
> it using "ccode" and "regrev".
>
> Now, about the issue I see:
>
> AFAIU if you set IEEE80211_CHAN_DISABLED in "orig_flags" it's meant to
> be there for good. Some reference code that makes me believe so
Indeed. Admittedly, it is the first time I became aware of it when
Johannes brought it up.
> (reg.c):
> pr_debug("Disabling freq %d MHz for good\n", chan->center_freq);
> chan->orig_flags |= IEEE80211_CHAN_DISABLED;
>
> This is what happens with brcmfmac right now. If firmware doesn't
> report some channels, you set "flags" to IEEE80211_CHAN_DISABLED for
> them. Then you call wiphy_register which copies that "flags" to the
> "orig_flags". I read it as: we are never going to use these channels.
>
> Now, consider you support regdom change (I do with my local patches).
> You translate alpha2 to a proper firmware request (board specific!),
> you execute it and then firmware may allow you to use channels that
> you marked as disabled for good. You would need to mess with
> orig_flags to recover from this issue.
>
> Does my explanation make more sense of this issue now?
Sure. It seems we should leave all channels enabled and disable them
after wiphy_register() based on firmware information. Or did you have
something else in mind. DFS channels may need to pass a feature check in
firmware and always be disabled otherwise.
>>> orig_flags of channels that may become available later, after country
>>> change. Please note it happens even right now, without this patch.
>>
>> Nope. As stated earlier the country setting in firmware is not updated
>> unless you provide a *proper* mapping of user-space country code to
>> firmware country code/revision. That is the reason, ie. firmware simply
>> returns the same list of channels as nothing changed from its
>> perspective. We may actually drop 11d support.
>
> I implemented mapping support locally, this is the feature I'm talking about.
Ok. So this is not an upstream feature. Or are you getting the mapping
from DT?
>>> Maybe you can workaround this by ignoring orig_flags in custom
>>> regulatory code, but I'd just prefer to have it nicely handled in the
>>> first place.
>>
>> Please care to explain your ideas before putting any effort in this
>> "feature". As the author of the code that makes you unhappy and as
>> driver maintainer I would like to get a clearer picture of your point of
>> view. What exactly is the issue that makes you unhappy.
>
> I meant that problem with "orig_flags" I described in the first
> paragraph. I wasn't trying to hide whatever issue I'm seeing, I swear
> ;)
>
>
>>> This is the next feature I'm going to work on. AFAIU this patch won't
>>> be applied for now (it's for wireless-drivers-next and we first need
>>> to get wiphy_read_of_freq_limits in that tree). By the time that
>>> happens I may have another patchset cleaning brcmfmac ready. And FWIW
>>> this patch wouldn't make things worse *at this point* as we don't
>>> really support country switching for any device yet.
>>
>> Now who is *we*? We as Broadcom can, because we know how to map the ISO
>> 3166-1 country code to firmware country code/revision for a specific
>> firmware release. Firmware uses its own regulatory rules which may
>> differ from what regdb has. Now I know Intel submitted a mechanism to
>> export firmware rules to regdb so maybe we should consider switching to
>> that api if that has been upstreamed. Need to check.
>
> We as a driver developers. Please read
> "we don't really support country switching for any device yet"
> as
> "brcmfmac doesn't really support country switching for any device yet"
>
> Does it help to get the context?
I indeed prefer to talk about the driver instead of we. Indeed it is
true due to the orig_flags behavior although that only seems to involve
regulatory code. Could it be that brcmfmac undo that through the notifier?
Regards,
Arend
--
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/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-07 12:53 UTC (permalink / raw)
To: Johannes Berg
Cc: Rob Herring, linux-wireless, Martin Blumenstingl, Felix Fietkau,
Arend van Spriel, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <1483707597.12677.0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On 6 January 2017 at 13:59, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Thu, 2017-01-05 at 10:34 -0600, Rob Herring wrote:
>> On Thu, Jan 5, 2017 at 5:51 AM, Johannes Berg <johannes@sipsolutions.
>> net> wrote:
>> >
>> > > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> >
>> > Do I take that to mean that we'll merge it through the subsystem
>> > tree,
>> > and not go through some common DT tree?
>>
>> Yes, that's generally the case when bindings are in a series with
>> driver changes.
>
> Alright, thanks.
>
> I've applied patches 1-3, patch 4 obviously still needs work (and
> probably won't go through my tree anyway.)
>
> Note that I made some documentation fixes in patch 3, Rafał, please
> check.
Looks great, thanks everyone for your help on getting this patchset in shape!
--
Rafał
--
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/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Rafał Miłecki @ 2017-01-07 12:58 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Johannes Berg,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rob Herring, Rafał Miłecki
In-Reply-To: <36d2dbd1-bcbe-021b-dd7f-068a5b9739ef-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 7 January 2017 at 13:52, Arend Van Spriel
<arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On 5-1-2017 11:02, Rafał Miłecki wrote:
>> On 5 January 2017 at 10:31, Arend Van Spriel
>> <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>> On 4-1-2017 22:19, Rafał Miłecki wrote:
>>>> On 4 January 2017 at 21:07, Arend Van Spriel
>>>> <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>>>> On 4-1-2017 18:58, Rafał Miłecki wrote:
>>>>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>>>
>>>>>> There are some devices (e.g. Netgear R8000 home router) with one chipset
>>>>>> model used for different radios, some of them limited to subbands. NVRAM
>>>>>> entries don't contain any extra info on such limitations and firmware
>>>>>> reports full list of channels to us. We need to store extra limitation
>>>>>> info in DT to support such devices properly.
>>>>>>
>>>>>> Now there is a cfg80211 helper for reading such info use it in brcmfmac.
>>>>>> This patch adds check for channel being disabled with orig_flags which
>>>>>> is how this wiphy helper and wiphy_register work.
>>>>>>
>>>>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>>> ---
>>>>>> This patch should probably go through wireless-driver-next which is why
>>>>>> it got weird number 4/3. I'm sending it just as a proof of concept.
>>>>>> It was succesfully tested on SmartRG SR400ac with BCM43602.
>>>>>>
>>>>>> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
>>>>>> V5: Update commit message
>>>>>> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it work
>>>>>> with helper setting "flags" instead of "orig_flags".
>>>>>> ---
>>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 ++++++++-
>>>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>>> index ccae3bb..a008ba5 100644
>>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>>> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
>>>>>> band->band);
>>>>>> channel[index].hw_value = ch.control_ch_num;
>>>>>>
>>>>>> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
>>>>>> + continue;
>>>>>> +
>>>>>
>>>>> So to be clear this is still needed for subsequent calls to
>>>>> brcmf_setup_wiphybands(). The subsequent calls are done from the
>>>>> regulatory notifier. So I think we have an issue with this approach. Say
>>>>> the device comes up with US. That would set DISABLED flags for channels
>>>>> 12 to 14. With a country update to PL we would want to enable channels
>>>>> 12 and 13, right? The orig_flags are copied from the initial flags
>>>>> during wiphy_register() so it seems we will skip enabling 12 and 13. I
>>>>> think we should remove the check above and call
>>>>> wiphy_read_of_freq_limits() as a last step within
>>>>> brcmf_setup_wiphybands(). It means it is called every time, but it
>>>>> safeguards that the limits in DT are always applied.
>>>>
>>>> I'm not exactly happy with channels management in brcmfmac. Before
>>>> calling wiphy_register it already disables channels unavailable for
>>>> current country. This results in setting IEEE80211_CHAN_DISABLED in
>>>
>>> What do you mean by current country. There is none that we are aware off
>>> in the driver. So we obtain the channels for the current
>>> country/revision in the firmware and enable those before
>>> wiphy_register(). This all is within the probe/init sequence so I do not
>>> really see an issue. As the wiphy object is not yet registered there is
>>> no user-space awareness
>>
>> It seems I'm terrible as describing my patches/problems/ideas :( Here
>> I used 1 inaccurate word and you couldn't understand my point.
>
> Well. Because of our track record of miscommunication and other
> annoyances I want to be sure this time :-p
>
>> By "current country" I meant current region (and so a set of
>> regulatory rules) used by the firmware. I believe firmware describes
>> it using "ccode" and "regrev".
>>
>> Now, about the issue I see:
>>
>> AFAIU if you set IEEE80211_CHAN_DISABLED in "orig_flags" it's meant to
>> be there for good. Some reference code that makes me believe so
>
> Indeed. Admittedly, it is the first time I became aware of it when
> Johannes brought it up.
>
>> (reg.c):
>> pr_debug("Disabling freq %d MHz for good\n", chan->center_freq);
>> chan->orig_flags |= IEEE80211_CHAN_DISABLED;
>>
>> This is what happens with brcmfmac right now. If firmware doesn't
>> report some channels, you set "flags" to IEEE80211_CHAN_DISABLED for
>> them. Then you call wiphy_register which copies that "flags" to the
>> "orig_flags". I read it as: we are never going to use these channels.
>>
>> Now, consider you support regdom change (I do with my local patches).
>> You translate alpha2 to a proper firmware request (board specific!),
>> you execute it and then firmware may allow you to use channels that
>> you marked as disabled for good. You would need to mess with
>> orig_flags to recover from this issue.
>>
>> Does my explanation make more sense of this issue now?
>
> Sure. It seems we should leave all channels enabled and disable them
> after wiphy_register() based on firmware information. Or did you have
> something else in mind. DFS channels may need to pass a feature check in
> firmware and always be disabled otherwise.
I got in mind exactly what you described. I didn't look at DFS channels yet.
>>>> orig_flags of channels that may become available later, after country
>>>> change. Please note it happens even right now, without this patch.
>>>
>>> Nope. As stated earlier the country setting in firmware is not updated
>>> unless you provide a *proper* mapping of user-space country code to
>>> firmware country code/revision. That is the reason, ie. firmware simply
>>> returns the same list of channels as nothing changed from its
>>> perspective. We may actually drop 11d support.
>>
>> I implemented mapping support locally, this is the feature I'm talking about.
>
> Ok. So this is not an upstream feature. Or are you getting the mapping
> from DT?
I'll send patch next week. So far I put mapping table directly in a
driver, but I think it's better to have this in DT.
>>>> Maybe you can workaround this by ignoring orig_flags in custom
>>>> regulatory code, but I'd just prefer to have it nicely handled in the
>>>> first place.
>>>
>>> Please care to explain your ideas before putting any effort in this
>>> "feature". As the author of the code that makes you unhappy and as
>>> driver maintainer I would like to get a clearer picture of your point of
>>> view. What exactly is the issue that makes you unhappy.
>>
>> I meant that problem with "orig_flags" I described in the first
>> paragraph. I wasn't trying to hide whatever issue I'm seeing, I swear
>> ;)
>>
>>
>>>> This is the next feature I'm going to work on. AFAIU this patch won't
>>>> be applied for now (it's for wireless-drivers-next and we first need
>>>> to get wiphy_read_of_freq_limits in that tree). By the time that
>>>> happens I may have another patchset cleaning brcmfmac ready. And FWIW
>>>> this patch wouldn't make things worse *at this point* as we don't
>>>> really support country switching for any device yet.
>>>
>>> Now who is *we*? We as Broadcom can, because we know how to map the ISO
>>> 3166-1 country code to firmware country code/revision for a specific
>>> firmware release. Firmware uses its own regulatory rules which may
>>> differ from what regdb has. Now I know Intel submitted a mechanism to
>>> export firmware rules to regdb so maybe we should consider switching to
>>> that api if that has been upstreamed. Need to check.
>>
>> We as a driver developers. Please read
>> "we don't really support country switching for any device yet"
>> as
>> "brcmfmac doesn't really support country switching for any device yet"
>>
>> Does it help to get the context?
>
> I indeed prefer to talk about the driver instead of we. Indeed it is
> true due to the orig_flags behavior although that only seems to involve
> regulatory code. Could it be that brcmfmac undo that through the notifier?
I guess you could touch orig_flags, but I don't know if it's preferred
way. This is probably question to Johannes & cfg80211 guys.
--
Rafał
--
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] arm64: dts: rockchip: add "rockchip,grf" property for RK3399 PMUCRU/CRU
From: Xing Zheng @ 2017-01-07 13:05 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: dianders-hpIqsD4AKlfQT0dZR+AlfA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Xing Zheng,
Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
Douglas Anderson, Caesar Wang, Brian Norris, Shawn Lin,
Jianqun Xu, Elaine Zhang, David Wu, William wu,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The structure rockchip_clk_provider needs to refer the GRF regmap
in somewhere, if the CRU node has not "rockchip,grf" property,
calling syscon_regmap_lookup_by_phandle will return an invaild GRF
regmap, and the MUXGRF type clock will be not supported.
Therefore, we need to add them.
Signed-off-by: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 92b731f..7790634 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1090,6 +1090,7 @@
pmucru: pmu-clock-controller@ff750000 {
compatible = "rockchip,rk3399-pmucru";
reg = <0x0 0xff750000 0x0 0x1000>;
+ rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
assigned-clocks = <&pmucru PLL_PPLL>;
@@ -1099,6 +1100,7 @@
cru: clock-controller@ff760000 {
compatible = "rockchip,rk3399-cru";
reg = <0x0 0xff760000 0x0 0x1000>;
+ rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
assigned-clocks =
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Russell King - ARM Linux @ 2017-01-07 13:50 UTC (permalink / raw)
To: Marcin Wojtas
Cc: Thomas Petazzoni, netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala, Andrew Lunn,
Yehuda Yitschak, Jason Cooper, Hanna Hawa, Nadav Haklai,
Gregory Clement, Stefan Chulski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sebastian Hesselbarth
In-Reply-To: <CAPv3WKeQ=fj2cKPyJ2NqCaAv55cOyWodujKwj3-v5iCrDYNcmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, Jan 07, 2017 at 01:12:35PM +0100, Marcin Wojtas wrote:
> In fact there is common SMI bus, but each port has its own register
> set to control it (it's true at least for Neta and PP2). There is also
> an option to use HW polling - every 1s hardware checks PHY over SMI
> and updates MAC registers of each port independently. I was able to
> use those successfully in other implementations.
>
> However we are supposed to use libphy in Linux and I'm afraid we have
> to use single instance that controls single SMI bus - I think current
> implementation is a compromise between HW and libphy demands.
One of the "DT rules" is that DT only describes the hardware in an
implementation independent way. It should not describe a particular
implementation's view of the hardware.
"libphy demands" sounds very much like an implementation dictating
the DT description, which sounds to me very wrong and against the
goals and purposes of DT.
Anyway, I don't think it's too bad - a possible solution here would
be to have the existing MDIO driver as a library, which can be
instantiated by the Neta and PP2 drivers. This could be done in
DT (taking dove as an example) as:
eth: ethernet-ctrl@72000 {
compatible = "marvell,orion-eth";
reg = <0x72000 0x4000>;
ranges = <0 0x72000 0 0x4000>;
...
mdio: mdio@4 {
compatible = "marvell,orion-mdio";
reg = <4>;
...
... phys ...
};
};
I don't think that would require that big a change - and it could be
done in a way that compatibility with the existing DT descriptions is
maintained very cheaply.
Now, I'm not suggesting that mdio@4 should be created by a platform
device via marking ethernet-ctrl@72000 with "simple-bus", but it's
something that should be created by the ethernet driver if present.
The compatible string is there so we can identify that this is a
mdio node, and which type of mdio it is (the Armada 8k has this type
and a separate clause-45 xmdio implementation, and we need to
distinguish those.)
What that means is that we no longer have to worry about clocks and
overlapping register regions and the like, and can deal with the
ethernet driver wanting to access the SMI registers as well.
We would need the ethernet driver to be capable of instantiation even
with no ports enabled, so cases where the MDIO interface is used with
other ethernet controllers continues to be supportable (eg, the
Armada 8040 case where the slave CP110 ethernet controller is used
with PHYs connected to the master CP110 ethernet controller's MDIO
buses - which afaik aren't shared between the two CP110 dies.)
However, I'd like to see libphy become more flexible and support
hardware polled mode of operation, since libphy provides a nice
library of functions for accessing various phy features (like setting
the advertisment, EEE modes, flow control, etc.) Even with hardware
polling, we should still describe the PHY in DT, because PHY is part
of the hardware description, and we need to know where it is in order
to program these phy features.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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
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