* Re: [PATCH 16/18] ARM64: dts: meson-gxl-s905x-nexbox-a95x: Reorder nodes
From: Neil Armstrong @ 2017-01-23 8:58 UTC (permalink / raw)
To: Andreas Färber, linux-amlogic
Cc: Mark Rutland, devicetree, Kevin Hilman, Will Deacon, linux-kernel,
Rob Herring, Catalin Marinas, Carlo Caione, linux-arm-kernel
In-Reply-To: <20170120222118.21476-17-afaerber@suse.de>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> .../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts | 28 +++++++++++-----------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> index cea4a3eded9b..9e91f0809dcd 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> @@ -129,10 +129,10 @@
> };
> };
>
> -&uart_AO {
> - status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> - pinctrl-names = "default";
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> };
>
> ðmac {
> @@ -147,6 +147,14 @@
> pinctrl-names = "default";
> };
>
> +&pwm_ef {
> + status = "okay";
> + pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-names = "default";
> + clocks = <&clkc CLKID_FCLK_DIV4>;
> + clock-names = "clkin0";
> +};
> +
> /* Wireless SDIO Module */
> &sd_emmc_a {
> status = "okay";
> @@ -206,16 +214,8 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -&pwm_ef {
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> - clocks = <&clkc CLKID_FCLK_DIV4>;
> - clock-names = "clkin0";
> -};
> -
> -&cvbs_vdac_port {
> - cvbs_vdac_out: endpoint {
> - remote-endpoint = <&cvbs_connector_in>;
> - };
> };
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH 15/18] ARM64: dts: meson-gxl: Reorder nodes
From: Neil Armstrong @ 2017-01-23 8:57 UTC (permalink / raw)
To: Andreas Färber, linux-amlogic
Cc: Mark Rutland, devicetree, Kevin Hilman, Will Deacon, linux-kernel,
Rob Herring, Catalin Marinas, Carlo Caione, linux-arm-kernel
In-Reply-To: <20170120222118.21476-16-afaerber@suse.de>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 40 +++++++++++++++---------------
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index bdf2305a2e25..afa74455e1de 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -120,6 +120,26 @@
> };
> };
>
> +&hiubus {
> + clkc: clock-controller@0 {
> + compatible = "amlogic,gxl-clkc", "amlogic,gxbb-clkc";
> + #clock-cells = <1>;
> + reg = <0x0 0x0 0x0 0x3db>;
> + };
> +};
> +
> +&i2c_A {
> + clocks = <&clkc CLKID_I2C>;
> +};
> +
> +&i2c_B {
> + clocks = <&clkc CLKID_I2C>;
> +};
> +
> +&i2c_C {
> + clocks = <&clkc CLKID_I2C>;
> +};
> +
> &periphs {
> pinctrl_periphs: pinctrl@4b0 {
> compatible = "amlogic,meson-gxl-periphs-pinctrl";
> @@ -320,26 +340,6 @@
> };
> };
>
> -&hiubus {
> - clkc: clock-controller@0 {
> - compatible = "amlogic,gxl-clkc", "amlogic,gxbb-clkc";
> - #clock-cells = <1>;
> - reg = <0x0 0x0 0x0 0x3db>;
> - };
> -};
> -
> -&i2c_A {
> - clocks = <&clkc CLKID_I2C>;
> -};
> -
> -&i2c_B {
> - clocks = <&clkc CLKID_I2C>;
> -};
> -
> -&i2c_C {
> - clocks = <&clkc CLKID_I2C>;
> -};
> -
> &sd_emmc_a {
> clocks = <&clkc CLKID_SD_EMMC_A>,
> <&xtal>,
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH 13/18] ARM64: dts: meson-gxbb-nexbox-a95x: Reorder nodes
From: Neil Armstrong @ 2017-01-23 8:57 UTC (permalink / raw)
To: Andreas Färber,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Kevin Hilman,
Will Deacon, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Catalin Marinas, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170120222118.21476-14-afaerber-l3A5Bk7waGM@public.gmane.org>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 28 +++++++++++-----------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> index 4cbd626a9e88..e642bfd5eec5 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -154,10 +154,10 @@
> };
> };
>
> -&uart_AO {
> - status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> - pinctrl-names = "default";
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> };
>
> ðmac {
> @@ -173,6 +173,14 @@
> pinctrl-names = "default";
> };
>
> +&pwm_ef {
> + status = "okay";
> + pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-names = "default";
> + clocks = <&clkc CLKID_FCLK_DIV4>;
> + clock-names = "clkin0";
> +};
> +
> /* Wireless SDIO Module */
> &sd_emmc_a {
> status = "okay";
> @@ -232,16 +240,8 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -&pwm_ef {
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> - clocks = <&clkc CLKID_FCLK_DIV4>;
> - clock-names = "clkin0";
> -};
> -
> -&cvbs_vdac_port {
> - cvbs_vdac_out: endpoint {
> - remote-endpoint = <&cvbs_connector_in>;
> - };
> };
>
Reviewed-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
--
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 07/18] ARM64: dts: meson-gxl-s905x: Comment typo fix
From: Neil Armstrong @ 2017-01-23 8:56 UTC (permalink / raw)
To: Andreas Färber,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Carlo Caione, Kevin Hilman,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170120222118.21476-8-afaerber-l3A5Bk7waGM@public.gmane.org>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> Cc: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> index 08237ee1e362..d49ee3c04dd7 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> @@ -47,7 +47,7 @@
> compatible = "amlogic,s905x", "amlogic,meson-gxl";
> };
>
> -/* S905X Only has access to its internal PHY */
> +/* S905X only has access to its internal PHY */
> ðmac {
> phy-mode = "rmii";
> phy-handle = <&internal_phy>;
>
Can't hurt
Reviewed-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
--
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 06/18] ARM64: dts: meson-gxm-nexbox-a1: Drop UART comment
From: Neil Armstrong @ 2017-01-23 8:55 UTC (permalink / raw)
To: Andreas Färber, linux-amlogic
Cc: Carlo Caione, Kevin Hilman, linux-arm-kernel, linux-kernel,
Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
devicetree
In-Reply-To: <20170120222118.21476-7-afaerber@suse.de>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> Product pictures show no DB9 connector, so this seems copy&paste.
>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> index 5a337d339df1..439060652689 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -102,7 +102,6 @@
> };
> };
>
> -/* This UART is brought out to the DB9 connector */
> &uart_AO {
> status = "okay";
> pinctrl-0 = <&uart_ao_a_pins>;
>
Exact
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH 05/18] ARM64: dts: meson-gx-p23x-q20x: Fix Wifi node name
From: Neil Armstrong @ 2017-01-23 8:55 UTC (permalink / raw)
To: Andreas Färber,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Carlo Caione, Kevin Hilman,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170120222118.21476-6-afaerber-l3A5Bk7waGM@public.gmane.org>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> bcrmf -> brcmf
>
> Fixes: bb51b5350d2f ("ARM64: dts: Add support for Meson GXM")
> Cc: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> index 7a078bef04cd..419c46cc64e4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> @@ -133,7 +133,7 @@
> vmmc-supply = <&vddao_3v3>;
> vqmmc-supply = <&vddio_boot>;
>
> - brcmf: bcrmf@1 {
> + brcmf: brcmf@1 {
> reg = <1>;
> compatible = "brcm,bcm4329-fmac";
> };
>
Reviewed-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
--
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 04/18] ARM64: dts: meson-gxbb-p20x: Fix Wifi node name
From: Neil Armstrong @ 2017-01-23 8:55 UTC (permalink / raw)
To: Andreas Färber,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Carlo Caione, Kevin Hilman,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170120222118.21476-5-afaerber-l3A5Bk7waGM@public.gmane.org>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> bcrmf -> brcmf
>
> Fixes: ab3943fe57a2 ("ARM64: dts: meson-gxbb: Add P20x Wifi SDIO support")
> Cc: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index 4a96e0f6f926..5183c5ce90c6 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -193,7 +193,7 @@
> vmmc-supply = <&vddao_3v3>;
> vqmmc-supply = <&vddio_boot>;
>
> - brcmf: bcrmf@1 {
> + brcmf: brcmf@1 {
> reg = <1>;
> compatible = "brcm,bcm4329-fmac";
> };
>
Good catch !
Reviewed-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
--
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 v9 0/4] arm64: arch_timer: Add workaround for hisilicon-161010101 erratum
From: Marc Zyngier @ 2017-01-23 8:43 UTC (permalink / raw)
To: Ding Tianhong, Mark Rutland, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, Daniel Lezcano, Thomas Gleixner
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuart.yoder-3arQi8VN3Tc,
linuxarm-hv44wF8Li93QT0dZR+AlfA, oss-fOR+EgIDQEHk1uMJSBkQmQ,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <56554f95-b51d-abc7-8ac0-7f561728375a-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On 23/01/17 07:36, Ding Tianhong wrote:
>
>
> On 2017/1/20 23:04, Mark Rutland wrote:
>> On Thu, Jan 19, 2017 at 09:35:12PM +0800, Ding Tianhong wrote:
>>> Ding Tianhong (4):
>>> arm64: arch_timer: Add device tree binding for hisilicon-161010101
>>> erratum
>>> arm64: arch_timer: Introduce a generic erratum handing mechanism for
>>> fsl-a008585
>>> arm64: arch_timer: Work around Erratum Hisilicon-161010101
>>> arm64: arch timer: Add timer erratum property for Hip05-d02 and
>>> Hip06-d03
>>>
>>> Documentation/admin-guide/kernel-parameters.txt | 9 --
>>> Documentation/arm64/silicon-errata.txt | 43 +++---
>>> .../devicetree/bindings/arm/arch_timer.txt | 6 +
>>> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
>>> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
>>> arch/arm64/include/asm/arch_timer.h | 38 ++----
>>> drivers/clocksource/Kconfig | 18 +++
>>> drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------
>>> 8 files changed, 171 insertions(+), 95 deletions(-)
>>
>> I've picked these up (with a few local cleanups), given that some local
>> testing, and pushed the result to a branch [1] on my git repo.
>>
>> There are likely to be clashes with the arm64 tree (e.g. for
>> silicon-errata.txt), and we're also likely to have more arch timer
>> updates shortly for the GTDT stuff, so I think the best bet is for both
>> arm64 and the clocksource tree to pull that branch for v4.11.
>>
>> Alternatively, we could take this all through the arm64 tree, if the
>> clocksource maintainers are happy with that.
>>
>> Thoughts?
>>
>
> Hi Mark:
> > It is really a great milestone now, Thanks for the help, and I will
> still wait for Marc's new opinion for this version, hoping no need to
> change anything else. :)
I'm working directly with Mark, and any change I feel necessary will go
directly on top of Mark's branch (as far as I'm concerned, these patches
are now in a "frozen" state).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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 RFC v2 1/4] ARM: dts: imx6qdl: add HummingBoard2 boards
From: Shawn Guo @ 2017-01-23 8:33 UTC (permalink / raw)
To: Russell King
Cc: Fabio Estevam, Sascha Hauer, Jon Nettleton,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland
In-Reply-To: <E1cS36a-0002wB-Vy-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
On Fri, Jan 13, 2017 at 02:45:24PM +0000, Russell King wrote:
> From: Jon Nettleton <jon-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
>
> This adds support for the Hummingboard Gate and Edge devices from
> SolidRun.
>
> Signed-off-by: Jon Nettleton <jon-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
> Signed-off-by: Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx6dl-hummingboard2.dts | 52 +++
> arch/arm/boot/dts/imx6q-hummingboard2.dts | 60 +++
> arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 543 +++++++++++++++++++++++++++
> 4 files changed, 657 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-hummingboard2.dts
> create mode 100644 arch/arm/boot/dts/imx6q-hummingboard2.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7327250f0bb6..09227cc15199 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -348,6 +348,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6dl-gw552x.dtb \
> imx6dl-gw553x.dtb \
> imx6dl-hummingboard.dtb \
> + imx6dl-hummingboard2.dtb \
> imx6dl-icore.dtb \
> imx6dl-nit6xlite.dtb \
> imx6dl-nitrogen6x.dtb \
> @@ -390,6 +391,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6q-gw553x.dtb \
> imx6q-h100.dtb \
> imx6q-hummingboard.dtb \
> + imx6q-hummingboard2.dtb \
> imx6q-icore.dtb \
> imx6q-icore-rqs.dtb \
> imx6q-marsboard.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-hummingboard2.dts b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
> new file mode 100644
> index 000000000000..990b5050de5b
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
> @@ -0,0 +1,52 @@
> +/*
> + * Device Tree file for SolidRun HummingBoard2
> + * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
> + * Based on work by Russell King
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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.
> + *
> + * This file 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.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
The licence text is still the mangled version.
> +/dts-v1/;
> +
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-hummingboard2.dtsi"
> +
> +/ {
> + model = "SolidRun HummingBoard2 Solo/DualLite";
> + compatible = "solidrun,hummingboard2/dl", "fsl,imx6dl";
> +};
> diff --git a/arch/arm/boot/dts/imx6q-hummingboard2.dts b/arch/arm/boot/dts/imx6q-hummingboard2.dts
> new file mode 100644
> index 000000000000..f5eec9163bb8
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-hummingboard2.dts
> @@ -0,0 +1,60 @@
> +/*
> + * Device Tree file for SolidRun HummingBoard2
> + * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
> + * Based on work by Russell King
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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.
> + *
> + * This file 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.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
Ditto
> +/dts-v1/;
> +
> +#include "imx6q.dtsi"
> +#include "imx6qdl-hummingboard2.dtsi"
> +
> +/ {
> + model = "SolidRun HummingBoard2 Dual/Quad";
> + compatible = "solidrun,hummingboard2/q", "fsl,imx6q";
> +};
> +
> +&sata {
> + status = "okay";
> + fsl,transmit-level-mV = <1104>;
> + fsl,transmit-boost-mdB = <0>;
> + fsl,transmit-atten-16ths = <9>;
> + fsl,no-spread-spectrum;
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> new file mode 100644
> index 000000000000..11b63f6f2b89
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> @@ -0,0 +1,543 @@
> +/*
> + * Device Tree file for SolidRun HummingBoard2
> + * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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.
> + *
> + * This file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
This one is correct.
> +#include "imx6qdl-microsom.dtsi"
> +#include "imx6qdl-microsom-ar8035.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path = &uart1;
> + };
> +
> + ir_recv: ir-receiver {
> + compatible = "gpio-ir-receiver";
> + gpios = <&gpio7 9 1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_gpio7_9>;
> + linux,rc-map-name = "rc-rc6-mce";
> + };
> +
> + usdhc2_pwrseq: usdhc2-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
> + };
> +
> + reg_3p3v: regulator-3p3v {
> + compatible = "regulator-fixed";
> + regulator-name = "3P3V";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + reg_1p8v: regulator-1p8v {
> + compatible = "regulator-fixed";
> + regulator-name = "1P8V";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + reg_usbh1_vbus: regulator-usb-h1-vbus {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio1 0 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_usbh1_vbus>;
> + regulator-name = "usb_h1_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> +
> + reg_usbotg_vbus: regulator-usb-otg-vbus {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio3 22 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_usbotg_vbus>;
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> +
> + reg_usbh2_vbus: regulator-usb-h2-vbus {
> + compatible = "regulator-gpio";
> + enable-active-high;
> + enable-gpio = <&gpio2 13 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_usbh2_vbus>;
> + regulator-name = "usb_h2_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-boot-on;
> + };
> +
> + reg_usbh3_vbus: regulator-usb-h3-vbus {
> + compatible = "regulator-gpio";
> + enable-active-high;
> + enable-gpio = <&gpio7 10 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_usbh3_vbus>;
> + regulator-name = "usb_h3_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-boot-on;
> + };
> +
> + sound-sgtl5000 {
> + audio-codec = <&sgtl5000>;
> + audio-routing =
> + "MIC_IN", "Mic Jack",
> + "Mic Jack", "Mic Bias",
> + "Headphone Jack", "HP_OUT";
> + compatible = "fsl,imx-audio-sgtl5000";
> + model = "On-board Codec";
> + mux-ext-port = <5>;
> + mux-int-port = <1>;
> + ssi-controller = <&ssi1>;
> + };
> +};
> +
> +&audmux {
> + status = "okay";
> +};
> +
> +&ecspi2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_ecspi2>;
> + cs-gpios = <&gpio2 26 0>;
> + status = "okay";
> +};
> +
> +&hdmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_hdmi>;
> + ddc-i2c-bus = <&i2c2>;
> + status = "okay";
> +};
> +
> +&i2c1 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_i2c1>;
> + status = "okay";
> +
> + pcf8523: rtc@68 {
> + compatible = "nxp,pcf8523";
> + reg = <0x68>;
> + nxp,12p5_pf;
> + };
I do not see this support in mainline kernel.
Shawn
> +
> + sgtl5000: codec@0a {
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + compatible = "fsl,sgtl5000";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_sgtl5000>;
> + reg = <0x0a>;
> + VDDA-supply = <®_3p3v>;
> + VDDIO-supply = <®_3p3v>;
> + };
> +};
> +
> +&i2c2 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_i2c2>;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_i2c3>;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hog>;
> +
> + hummingboard2 {
> + pinctrl_hog: hoggrp {
> + fsl,pins = <
> + /*
> + * 36 pin headers GPIO description. The pins
> + * numbering as following -
> + *
> + * 3.2v 5v 74 75
> + * 73 72 71 70
> + * 69 68 67 66
> + *
> + * 77 78 79 76
> + * 65 64 61 60
> + * 53 52 51 50
> + * 49 48 166 132
> + * 95 94 90 91
> + * GND 54 24 204
> + *
> + * The GPIO numbers can be extracted using
> + * signal name from below.
> + * Example -
> + * MX6QDL_PAD_EIM_DA10__GPIO3_IO10 is
> + * GPIO(3,10) which is (3-1)*32+10 = gpio 74
> + *
> + * i.e. The mapping of GPIO(X,Y) to Linux gpio
> + * number is : gpio number = (X-1) * 32 + Y
> + */
> + /* DI1_PIN15 */
> + MX6QDL_PAD_EIM_DA10__GPIO3_IO10 0x400130b1
> + /* DI1_PIN02 */
> + MX6QDL_PAD_EIM_DA11__GPIO3_IO11 0x400130b1
> + /* DISP1_DATA00 */
> + MX6QDL_PAD_EIM_DA9__GPIO3_IO09 0x400130b1
> + /* DISP1_DATA01 */
> + MX6QDL_PAD_EIM_DA8__GPIO3_IO08 0x400130b1
> + /* DISP1_DATA02 */
> + MX6QDL_PAD_EIM_DA7__GPIO3_IO07 0x400130b1
> + /* DISP1_DATA03 */
> + MX6QDL_PAD_EIM_DA6__GPIO3_IO06 0x400130b1
> + /* DISP1_DATA04 */
> + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x400130b1
> + /* DISP1_DATA05 */
> + MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0x400130b1
> + /* DISP1_DATA06 */
> + MX6QDL_PAD_EIM_DA3__GPIO3_IO03 0x400130b1
> + /* DISP1_DATA07 */
> + MX6QDL_PAD_EIM_DA2__GPIO3_IO02 0x400130b1
> + /* DI1_D0_CS */
> + MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x400130b1
> + /* DI1_D1_CS */
> + MX6QDL_PAD_EIM_DA14__GPIO3_IO14 0x400130b1
> + /* DI1_PIN01 */
> + MX6QDL_PAD_EIM_DA15__GPIO3_IO15 0x400130b1
> + /* DI1_PIN03 */
> + MX6QDL_PAD_EIM_DA12__GPIO3_IO12 0x400130b1
> + /* DISP1_DATA08 */
> + MX6QDL_PAD_EIM_DA1__GPIO3_IO01 0x400130b1
> + /* DISP1_DATA09 */
> + MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0x400130b1
> + /* DISP1_DATA10 */
> + MX6QDL_PAD_EIM_EB1__GPIO2_IO29 0x400130b1
> + /* DISP1_DATA11 */
> + MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0x400130b1
> + /* DISP1_DATA12 */
> + MX6QDL_PAD_EIM_A17__GPIO2_IO21 0x400130b1
> + /* DISP1_DATA13 */
> + MX6QDL_PAD_EIM_A18__GPIO2_IO20 0x400130b1
> + /* DISP1_DATA14 */
> + MX6QDL_PAD_EIM_A19__GPIO2_IO19 0x400130b1
> + /* DISP1_DATA15 */
> + MX6QDL_PAD_EIM_A20__GPIO2_IO18 0x400130b1
> + /* DISP1_DATA16 */
> + MX6QDL_PAD_EIM_A21__GPIO2_IO17 0x400130b1
> + /* DISP1_DATA17 */
> + MX6QDL_PAD_EIM_A22__GPIO2_IO16 0x400130b1
> + /* DISP1_DATA18 */
> + MX6QDL_PAD_EIM_A23__GPIO6_IO06 0x400130b1
> + /* DISP1_DATA19 */
> + MX6QDL_PAD_EIM_A24__GPIO5_IO04 0x400130b1
> + /* DISP1_DATA20 */
> + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x400130b1
> + /* DISP1_DATA21 */
> + MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x400130b1
> + /* DISP1_DATA22 */
> + MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x400130b1
> + /* DISP1_DATA23 */
> + MX6QDL_PAD_EIM_D27__GPIO3_IO27 0x400130b1
> + /* DI1_DISP_CLK */
> + MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x400130b1
> + /* SPDIF_IN */
> + MX6QDL_PAD_ENET_RX_ER__GPIO1_IO24 0x400130b1
> + /* SPDIF_OUT */
> + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x400130b1
> +
> + /* MikroBUS GPIO pin number 10 */
> + MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x400130b1
> + >;
> + };
> +
> + pinctrl_hummingboard2_ecspi2: hummingboard2-ecspi2grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
> + MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
> + MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
> + MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1 /* CS */
> + >;
> + };
> +
> + pinctrl_hummingboard2_gpio7_9: hummingboard2-gpio7_9 {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_CMD__GPIO7_IO09 0x80000000
> + >;
> + };
> +
> + pinctrl_hummingboard2_hdmi: hummingboard2-hdmi {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
> + >;
> + };
> +
> + pinctrl_hummingboard2_i2c1: hummingboard2-i2c1 {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_hummingboard2_i2c2: hummingboard2-i2c2 {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
> + MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_hummingboard2_i2c3: hummingboard2-i2c3 {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_hummingboard2_mipi: hummingboard2_mipi {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x4001b8b1
> + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x4001b8b1
> + MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
> + >;
> + };
> +
> + pinctrl_hummingboard2_pcie_reset: hummingboard2-pcie-reset {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT3__GPIO2_IO11 0x1b0b1
> + >;
> + };
> +
> + pinctrl_hummingboard2_pwm1: pwm1grp {
> + fsl,pins = <
> + MX6QDL_PAD_DISP0_DAT8__PWM1_OUT 0x1b0b1
> + >;
> + };
> +
> + pinctrl_hummingboard2_sgtl5000: hummingboard2-sgtl5000 {
> + fsl,pins = <
> + MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x130b0
> + MX6QDL_PAD_KEY_COL0__AUD5_TXC 0x130b0
> + MX6QDL_PAD_KEY_ROW0__AUD5_TXD 0x110b0
> + MX6QDL_PAD_KEY_COL1__AUD5_TXFS 0x130b0
> + MX6QDL_PAD_GPIO_5__CCM_CLKO1 0x130b0
> + >;
> + };
> +
> + pinctrl_hummingboard2_usbh1_vbus: hummingboard2-usbh1-vbus {
> + fsl,pins = <MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0>;
> + };
> +
> + pinctrl_hummingboard2_usbh2_vbus: hummingboard2-usbh2-vbus {
> + fsl,pins = <MX6QDL_PAD_SD4_DAT5__GPIO2_IO13 0x1b0b0>;
> + };
> +
> + pinctrl_hummingboard2_usbh3_vbus: hummingboard2-usbh3-vbus {
> + fsl,pins = <MX6QDL_PAD_SD4_CLK__GPIO7_IO10 0x1b0b0>;
> + };
> +
> + pinctrl_hummingboard2_usbotg_id: hummingboard2-usbotg-id {
> + /*
> + * Similar to pinctrl_usbotg_2, but we want it
> + * pulled down for a fixed host connection.
> + */
> + fsl,pins = <MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059>;
> + };
> +
> + pinctrl_hummingboard2_usbotg_vbus: hummingboard2-usbotg-vbus {
> + fsl,pins = <MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0>;
> + };
> +
> + pinctrl_hummingboard2_usdhc2_aux: hummingboard2-usdhc2-aux {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x13071
> + MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1b071
> + MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30 0x1b0b0
> + >;
> + };
> +
> + pinctrl_hummingboard2_usdhc2: hummingboard2-usdhc2 {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
> + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
> + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
> + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
> + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
> + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
> + >;
> + };
> +
> + pinctrl_hummingboard2_usdhc2_100mhz: hummingboard2-usdhc2-100mhz {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
> + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
> + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
> + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
> + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
> + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130b9
> + >;
> + };
> +
> + pinctrl_hummingboard2_usdhc2_200mhz: hummingboard2-usdhc2-200mhz {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170f9
> + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100f9
> + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170f9
> + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170f9
> + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170f9
> + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130f9
> + >;
> + };
> +
> + pinctrl_hummingboard2_usdhc3: hummingboard2-usdhc3 {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> + MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
> + MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
> + MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
> + MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
> + MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
> + >;
> + };
> +
> + pinctrl_hummingboard2_uart3: hummingboard2-uart3 {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D25__UART3_TX_DATA 0x1b0b1
> + MX6QDL_PAD_EIM_D24__UART3_RX_DATA 0x40013000
> + >;
> + };
> + };
> +};
> +
> +&ldb {
> + status = "disabled";
> +
> + lvds-channel@0 {
> + fsl,data-mapping = "spwg";
> + fsl,data-width = <18>;
> + };
> +};
> +
> +&pcie {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_pcie_reset>;
> + reset-gpio = <&gpio2 11 0>;
> + status = "okay";
> +};
> +
> +&pwm1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_pwm1>;
> + status = "okay";
> +};
> +
> +&pwm3 {
> + status = "disabled";
> +};
> +
> +&pwm4 {
> + status = "disabled";
> +};
> +
> +&ssi1 {
> + status = "okay";
> +};
> +
> +&usbh1 {
> + disable-over-current;
> + vbus-supply = <®_usbh1_vbus>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + disable-over-current;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_usbotg_id>;
> + vbus-supply = <®_usbotg_vbus>;
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <
> + &pinctrl_hummingboard2_usdhc2_aux
> + &pinctrl_hummingboard2_usdhc2
> + >;
> + pinctrl-1 = <
> + &pinctrl_hummingboard2_usdhc2_aux
> + &pinctrl_hummingboard2_usdhc2_100mhz
> + >;
> + pinctrl-2 = <
> + &pinctrl_hummingboard2_usdhc2_aux
> + &pinctrl_hummingboard2_usdhc2_200mhz
> + >;
> + mmc-pwrseq = <&usdhc2_pwrseq>;
> + cd-gpios = <&gpio1 4 0>;
> + status = "okay";
> +};
> +
> +&usdhc3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &pinctrl_hummingboard2_usdhc3
> + >;
> + vmmc-supply = <®_3p3v>;
> + vqmmc-supply = <®_3p3v>;
> + bus-width = <8>;
> + non-removable;
> + status = "okay";
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard2_uart3>;
> + status = "okay";
> +};
> --
> 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 v13 2/5] tee: generic TEE subsystem
From: Jens Wiklander @ 2017-01-23 8:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: valentin.manea, devicetree, javier, emmanuel.michel,
Greg Kroah-Hartman, Mark Rutland, Will Deacon, linux-kernel,
Wei Xu, Nishanth Menon, Jason Gunthorpe, Rob Herring, broonie,
Al Viro, Andrew F. Davis, Olof Johansson, Andrew Morton,
jean-michel.delorme, Michal Simek, linux-arm-kernel
In-Reply-To: <8436100.O3a8W3D0ph@wuerfel>
On Fri, Jan 20, 2017 at 05:47:40PM +0100, Arnd Bergmann wrote:
> On Thursday, January 19, 2017 5:45:43 PM CET Jens Wiklander wrote:
> >
> > On Wed, Jan 18, 2017 at 09:19:25PM +0100, Arnd Bergmann wrote:
> > > On Friday, November 18, 2016 3:51:37 PM CET Jens Wiklander wrote:
> > > > Initial patch for generic TEE subsystem.
> > > > This subsystem provides:
> > > > * Registration/un-registration of TEE drivers.
> > > > * Shared memory between normal world and secure world.
> > > > * Ioctl interface for interaction with user space.
> > > > * Sysfs implementation_id of TEE driver
> > > >
> > > > A TEE (Trusted Execution Environment) driver is a driver that interfaces
> > > > with a trusted OS running in some secure environment, for example,
> > > > TrustZone on ARM cpus, or a separate secure co-processor etc.
> > > >
> > > > The TEE subsystem can serve a TEE driver for a Global Platform compliant
> > > > TEE, but it's not limited to only Global Platform TEEs.
> > > >
> > > > This patch builds on other similar implementations trying to solve
> > > > the same problem:
> > > > * "optee_linuxdriver" by among others
> > > > Jean-michel DELORME<jean-michel.delorme@st.com> and
> > > > Emmanuel MICHEL <emmanuel.michel@st.com>
> > > > * "Generic TrustZone Driver" by Javier González <javier@javigon.com>
> > >
> > > Can you give an example for a system that would contain more than one
> > > TEE? I see that you support dynamic registration, and it's clear that
> > > there can be more than one type of TEE, but why would one have more
> > > than one at a time, and why not more than 32?
> >
> > I know that ST has systems where there's one TEE in TrustZone and
> > another TEE on a separate secure co-processor. If you have several TEEs
> > it's probably because they have different capabilities (performance
> > versus level of security). Just going beyond two or three different
> > levels of security with different TEEs sounds a bit extreme, so a
> > maximum of 32 or 16 should be fairly safe. If it turns out I'm wrong in
> > this assumption it's not that hard to correct it.
>
> Ok
>
> > >
> > > > + if (copy_from_user(&arg, uarg, sizeof(arg)))
> > > > + return -EFAULT;
> > > > +
> > > > + if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
> > > > + return -EINVAL;
> > > > +
> > > > + if (arg.num_params) {
> > > > + params = kcalloc(arg.num_params, sizeof(struct tee_param),
> > > > + GFP_KERNEL);
> > > > + if (!params)
> > > > + return -ENOMEM;
> > >
> > > It would be good to have an upper bound on the number of parameters
> > > to limit the size of the memory allocation here.
> >
> > This is already limited due to:
> >
> > The test with: buf.buf_len > TEE_MAX_ARG_SIZE
> >
> > And then another test that the number of parameters matches the buffer size
> > with: sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len
>
> Ok, makes sense.
>
> > >
> > > > +/**
> > > > + * struct tee_ioctl_param - parameter
> > > > + * @attr: attributes
> > > > + * @memref: a memory reference
> > > > + * @value: a value
> > > > + *
> > > > + * @attr & TEE_PARAM_ATTR_TYPE_MASK indicates if memref or value is used in
> > > > + * the union. TEE_PARAM_ATTR_TYPE_VALUE_* indicates value and
> > > > + * TEE_PARAM_ATTR_TYPE_MEMREF_* indicates memref. TEE_PARAM_ATTR_TYPE_NONE
> > > > + * indicates that none of the members are used.
> > > > + */
> > > > +struct tee_ioctl_param {
> > > > + __u64 attr;
> > > > + union {
> > > > + struct tee_ioctl_param_memref memref;
> > > > + struct tee_ioctl_param_value value;
> > > > + } u;
> > > > +};
> > > > +
> > > > +#define TEE_IOCTL_UUID_LEN 16
> > > > +
> > >
> > > Having a union in an ioctl argument seems odd. Have you considered
> > > using two different ioctl command numbers depending on the type?
> >
> > struct tee_ioctl_param is used as an array and some parameters can be
> > memrefs while other are values.
>
> Got it. I still think it's a bit awkward on the user ABI side.
> I also see that (unlike the in-kernel interface) tee_ioctl_param_memref
> and tee_ioctl_param_value are both defined in terms of three __u64
> members.
Actually the last member of struct tee_ioctl_param_memref is an __s64,
but that doesn't matter much one just have to be a little careful.
>
> How about simply using one format here and making this
>
> struct tee_ioctl_param {
> __u64 attr;
> __u64 a;
> __u64 b;
> __u64 c;
> };
>
> Given that you need a wrapper to set the pointer in memref anyway?
>
> Having an ioctl with a variable number of variable type arguments
> is really a weakness of the ABI, but I don't see a good way around
> it either, the above would just make it slightly more direct.
OK, I'll change.
>
> > > > +/**
> > > > + * struct tee_iocl_supp_send_arg - Send a response to a received request
> > > > + * @ret: [out] return value
> > > > + * @num_params [in] number of parameters following this struct
> > > > + */
> > > > +struct tee_iocl_supp_send_arg {
> > > > + __u32 ret;
> > > > + __u32 num_params;
> > > > + /*
> > > > + * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
> > > > + * which follows requires 8 byte alignment.
> > > > + *
> > > > + * Commented out element used to visualize the layout dynamic part
> > > > + * of the struct. This field is not available at all if
> > > > + * num_params == 0.
> > > > + *
> > > > + * struct tee_ioctl_param params[num_params];
> > > > + */
> > > > +} __aligned(8);
> > >
> > > I'd make that
> > >
> > > struct tee_ioctl_param params[0];
> > >
> > > as wel here, as I also commented in patch 3 that has a similar structure.
> >
> > I'm concerned that this may cause warnings when compiling for user space
> > depending on compiler and options. Am I too cautious here?
>
> See https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
>
> I actually misremembered it and the syntax I listed is GCC specific,
> but C99 allows "flexible arrays". I think there is no problem relying
> on C99 here, we already rely on C99 features elsewhere in headers.
OK, I'll change.
Thanks,
Jens
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Chris Packham @ 2017-01-23 8:18 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Mark Rutland, Thomas Petazzoni,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linus Walleij,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Kalyan Kinthada,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Laxman Dewangan, Sebastian Hesselbarth
In-Reply-To: <c873040cba1a4d5aa15dbaf3c5cc44e0@svr-chch-ex1.atlnz.lc>
On 20/01/17 10:10, Chris Packham wrote:
> On 19/01/17 23:03, Russell King - ARM Linux wrote:
>> On Fri, Jan 13, 2017 at 10:12:18PM +1300, Chris Packham wrote:
>>> +static struct mvebu_mpp_ctrl mv98dx3236_mpp_controls[] = {
>>> + MPP_FUNC_CTRL(0, 32, NULL, armada_xp_mpp_ctrl),
>>> +};
>>
>> As Linus has taken my mvebu pinctrl series, this will need to be
>> changed to "mvebu_mmio_mpp_ctrl" rather than "armada_xp_mpp_ctrl"
>> when it's merged.
>>
>
> OK I was thinking about rebasing my series so maybe it's time.
>
I noticed the mvebu pinctrl series isn't in Linus's (Torvalds) tree. Is
this on the cards for v4.10 or is it waiting for the next merge window?
In other words should I send v5 or my series now or wait for this to be
merged so I can rebase on top of it?
--
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/21] MIPS memblock: Discard bootmem allocator initialization
From: Marcin Nowakowski @ 2017-01-23 7:55 UTC (permalink / raw)
To: Serge Semin, ralf, paul.burton, rabinv, matt.redfearn,
james.hogan, alexander.sverdlin, robh+dt, frowand.list
Cc: Sergey.Semin, linux-mips, devicetree, linux-kernel
In-Reply-To: <1482113266-13207-11-git-send-email-fancer.lancer@gmail.com>
Hi Serge,
On 19.12.2016 03:07, Serge Semin wrote:
> Bootmem allocator initialization needs to be discarded.
> PFN limit constants are still in use by some subsystems, so they
> need to be properly initialized. The initialization is moved into
> a separate method and performed with help of commonly used
> platform-specific constants. It might me too simplified, but most
> of the kernel platforms do it the same way. Moreover it's much
> easier to debug it, when it's not that complicated.
>
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> ---
> arch/mips/kernel/setup.c | 193 ++++-------------------------
> 1 file changed, 21 insertions(+), 172 deletions(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index e746793..6562f55 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -626,6 +626,25 @@ static void __init request_crashkernel(struct resource *res) { }
> #endif /* !CONFIG_KEXEC */
>
> /*
> + * Calcualte PFN limits with respect to the defined memory layout
> + */
> +static void __init find_pfn_limits(void)
> +{
> + phys_addr_t ram_end = memblock_end_of_DRAM();
> +
> + min_low_pfn = ARCH_PFN_OFFSET;
> + max_low_pfn = PFN_UP(HIGHMEM_START);
This doesn't look right - as this may set max_low_pfn to more than the
actual physical memory size. In some cases this might be a serious
problem and it doesn't look like any other platform does that.
Even in MIPS code you can find uses of max_low_pfn that would be
seriously affected by this change (vpe loader with
CONFIG_MIPS_VPE_LOADER_TOM).
> + max_pfn = PFN_UP(ram_end);
> +#ifdef CONFIG_HIGHMEM
> + highstart_pfn = max_low_pfn;
> + highend_pfn = max_pfn <= highstart_pfn ? highstart_pfn : max_pfn;
> +#endif
> + pr_info("PFNs: low min %lu, low max %lu, high start %lu, high end %lu,"
> + "max %lu\n",
> + min_low_pfn, max_low_pfn, highstart_pfn, highend_pfn, max_pfn);
> +}
> +
> +/*
> * Initialize the bootmem allocator. It also setup initrd related data
> * if needed.
> */
I fully agree with you that the current initialisation code is really
complex and difficult to debug, but the modified one seems a bit too
simplified.
Regards,
Marcin
^ permalink raw reply
* Re: [PATCH 04/21] MIPS memblock: Alter user-defined memory parameter parser
From: Marcin Nowakowski @ 2017-01-23 7:55 UTC (permalink / raw)
To: Serge Semin, ralf, paul.burton, rabinv, matt.redfearn,
james.hogan, alexander.sverdlin, robh+dt, frowand.list
Cc: Sergey.Semin, linux-mips, devicetree, linux-kernel
In-Reply-To: <1482113266-13207-5-git-send-email-fancer.lancer@gmail.com>
Hi Serge,
On 19.12.2016 03:07, Serge Semin wrote:
> Both new memblock and boot_mem_map subsystems need to be fully
> cleared before a new memory region is added. So the early parser is
> correspondingly modified.
>
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> ---
> arch/mips/kernel/setup.c | 67 +++++++++++++++++-------------
> 1 file changed, 37 insertions(+), 30 deletions(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 9da6f8a..789aafe 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -229,6 +229,43 @@ static void __init print_memory_map(void)
> }
>
> /*
> + * Parse "mem=size@start" parameter rewriting a defined memory map
> + * We look for mem=size@start, where start and size are "value[KkMm]"
> + */
> +static int __init early_parse_mem(char *p)
> +{
> + static int usermem;
usermem variable seems unnecessary now and could easily be removed?
> + phys_addr_t start, size;
> +
> + start = PHYS_OFFSET;
> + size = memparse(p, &p);
> + if (*p == '@')
> + start = memparse(p + 1, &p);
> +
> + /*
> + * If a user specifies memory size, we blow away any automatically
> + * generated regions.
> + */
> + if (usermem == 0) {
> + phys_addr_t ram_start = memblock_start_of_DRAM();
> + phys_addr_t ram_end = memblock_end_of_DRAM() - ram_start;
> +
> + pr_notice("Discard memory layout %pa - %pa",
> + &ram_start, &ram_end);
missing \n in printk
> + memblock_remove(ram_start, ram_end - ram_start);
> + boot_mem_map.nr_map = 0;
> + usermem = 1;
> + }
> + pr_notice("Add userdefined memory region %08zx @ %pa",
> + (size_t)size, &start);
ditto
> + add_memory_region(start, size, BOOT_MEM_RAM);
> + return 0;
> +}
> +early_param("mem", early_parse_mem);
> +
> +/*
> * Manage initrd
> */
> #ifdef CONFIG_BLK_DEV_INITRD
> @@ -613,31 +650,6 @@ static void __init bootmem_init(void)
> * initialization hook for anything else was introduced.
> */
>
> -static int usermem __initdata;
> -
> -static int __init early_parse_mem(char *p)
> -{
> - phys_addr_t start, size;
> -
> - /*
> - * If a user specifies memory size, we
> - * blow away any automatically generated
> - * size.
> - */
> - if (usermem == 0) {
> - boot_mem_map.nr_map = 0;
> - usermem = 1;
> - }
> - start = 0;
> - size = memparse(p, &p);
> - if (*p == '@')
> - start = memparse(p + 1, &p);
> -
> - add_memory_region(start, size, BOOT_MEM_RAM);
> - return 0;
> -}
> -early_param("mem", early_parse_mem);
> -
> #ifdef CONFIG_PROC_VMCORE
> unsigned long setup_elfcorehdr, setup_elfcorehdr_size;
> static int __init early_parse_elfcorehdr(char *p)
> @@ -797,11 +809,6 @@ static void __init arch_mem_init(char **cmdline_p)
>
> parse_early_param();
>
> - if (usermem) {
> - pr_info("User-defined physical RAM map:\n");
> - print_memory_map();
> - }
> -
> bootmem_init();
> #ifdef CONFIG_PROC_VMCORE
> if (setup_elfcorehdr && setup_elfcorehdr_size) {
>
Regards,
Marcin
^ permalink raw reply
* Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to NO_BOOTMEM
From: Marcin Nowakowski @ 2017-01-23 7:55 UTC (permalink / raw)
To: Serge Semin, ralf-6z/3iImG2C8G8FEW9MqTrA,
paul.burton-1AXoQHu6uovQT0dZR+AlfA, rabinv-VrBV9hrLPhE,
matt.redfearn-1AXoQHu6uovQT0dZR+AlfA,
james.hogan-1AXoQHu6uovQT0dZR+AlfA,
alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w
Cc: Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1482113266-13207-1-git-send-email-fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Serge,
Thanks for this patch series, it's really useful. I've tested it on
Malta and Ci40 and it seems to work well (I've posted a few small
comments separately).
On 19.12.2016 03:07, Serge Semin wrote:
> Most of the modern platforms supported by linux kernel have already
> been cleaned up of old bootmem allocator by moving to nobootmem
> interface wrapping up the memblock. This patchset is the first
> attempt to do the similar improvement for MIPS for UMA systems
> only.
>
> Even though the porting was performed as much careful as possible
> there still might be problem with support of some platforms,
> especially Loonson3 or SGI IP27, which perform early memory manager
> initialization by their self.
> The patchset is split so individual patch being consistent in
> functional and buildable ways. But the MIPS early memory manager
> will work correctly only either with or without the whole set being
> applied. For the same reason a reviewer should not pay much attention
> to methods bootmem_init(), arch_mem_init(), paging_init() and
> mem_init() until they are fully refactored.
I'm not sure this can be merged that way? It would be up to Ralf to
decide, but it is generally expected that all intermediate patches not
only build, but also work correctly. I understand that this might be
difficult to achieve given the scale of changes required here.
> The patchset is applied on top of kernel v4.9.
Can you please work on cleaning up the issues discussed in the comments
so far as well as rebasing (and updating) the changes onto linux-next?
There are a few patches I made related to kexec and kernel relocation
that will force changes in your code (although I admit that the changes
I did for kexec/relocation were in some places unnecessarily complex
because of the mess in the bootmem handling in MIPS that you are now
trying to clean up).
Thanks,
Marcin
> Signed-off-by: Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Serge Semin (21):
> MIPS memblock: Unpin dts memblock sanity check method
> MIPS memblock: Add dts mem and reserved-mem callbacks
> MIPS memblock: Alter traditional add_memory_region() method
> MIPS memblock: Alter user-defined memory parameter parser
> MIPS memblock: Alter initrd memory reservation method
> MIPS memblock: Alter kexec-crashkernel parameters parser
> MIPS memblock: Alter elfcorehdr parameters parser
> MIPS memblock: Move kernel parameters parser into individual method
> MIPS memblock: Move kernel memory reservation to individual method
> MIPS memblock: Discard bootmem allocator initialization
> MIPS memblock: Add memblock sanity check method
> MIPS memblock: Add memblock print outs in debug
> MIPS memblock: Add memblock allocator initialization
> MIPS memblock: Alter IO resources initialization method
> MIPS memblock: Alter weakened MAAR initialization method
> MIPS memblock: Alter paging initialization method
> MIPS memblock: Alter high memory freeing method
> MIPS memblock: Slightly improve buddy allocator init method
> MIPS memblock: Add print out method of kernel virtual memory layout
> MIPS memblock: Add free low memory test method call
> MIPS memblock: Deactivate old bootmem allocator
>
> arch/mips/Kconfig | 2 +-
> arch/mips/kernel/prom.c | 32 +-
> arch/mips/kernel/setup.c | 958 +++++++++++++++--------------
> arch/mips/mm/init.c | 234 ++++---
> drivers/of/fdt.c | 47 +-
> include/linux/of_fdt.h | 1 +
> 6 files changed, 739 insertions(+), 535 deletions(-)
>
--
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: [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC
From: Chris Packham @ 2017-01-23 7:53 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Michael Turquette, Rob Herring, Mark Rutland,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170121004819.GA8801@codeaurora.org>
On 21/01/17 13:48, Stephen Boyd wrote:
> On 01/13, Chris Packham wrote:
>> @@ -158,6 +170,14 @@ static const struct coreclk_soc_desc axp_coreclks = {
>> .num_ratios = ARRAY_SIZE(axp_coreclk_ratios),
>> };
>>
>> +static const struct coreclk_soc_desc mv98dx3236_coreclks = {
>> + .get_tclk_freq = mv98dx3236_get_tclk_freq,
>> + .get_cpu_freq = mv98dx3236_get_cpu_freq,
>> + .get_clk_ratio = NULL,
>> + .ratios = NULL,
>> + .num_ratios = 0,
>
> Are these intentionally initialized to 0 explicitly? Otherwise we
> could leave them out and it's all the same.
>
No reason, just didn't remove the unused members when copying the
armada-xp example above.
>> +};
>> +
>> /*
>> * Clock Gating Control
>> */
> [..]
>> @@ -243,5 +245,30 @@ static void __init of_cpu_clk_setup(struct device_node *node)
>> iounmap(clock_complex_base);
>> }
>>
>> +/* Use this function to call the generic setup with the correct
>> + * clock operation
>> + */
>> +static void __init of_cpu_clk_setup(struct device_node *node)
>> +{
>> + _of_cpu_clk_setup(node, &cpu_ops);
>> +}
>> +
>> CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
>> of_cpu_clk_setup);
>> +
>> +/* Define the clock and operations for the mv98dx3236 - it cannot perform
>> + * any operations.
>> + */
>> +static const struct clk_ops mv98dx3236_cpu_ops = {
>> + .recalc_rate = NULL,
>> + .round_rate = NULL,
>> + .set_rate = NULL,
>
> But clk_set_rate() works silently? Why not just register a clk
> provider that returns a NULL pointer? Then there isn't any
> structure to maintain?
>
Not 100% sure what you mean. Something like this?
+static void __init of_mv98dx3236_cpu_clk_setup(struct device_node *node)
+{
+ of_clk_add_provider(node, of_clk_src_simple_get, NULL);
+}
Seems to work as expected (i.e. does nothing, kernel boots/runs).
--
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] ARM: dts: vf610-zii-dev: add EEPROM entry to Rev C
From: Shawn Guo @ 2017-01-23 7:38 UTC (permalink / raw)
To: Vivien Didelot
Cc: linux-arm-kernel, Mark Rutland, devicetree, andrew,
Andrey Smirnov, linux-kernel, Stefan Agner, Russell King,
Rob Herring, kernel, Sascha Hauer, Nikita Yushchenko, cphealy
In-Reply-To: <20170112230620.1735-1-vivien.didelot@savoirfairelinux.com>
On Thu, Jan 12, 2017 at 06:06:20PM -0500, Vivien Didelot wrote:
> The ZII Dev Rev C board has EEPROMs hanging the 88E6390 Ethernet switch
> chips. Add an "eeprom-length" property to allow access from ethtool.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v9 0/4] arm64: arch_timer: Add workaround for hisilicon-161010101 erratum
From: Ding Tianhong @ 2017-01-23 7:36 UTC (permalink / raw)
To: Mark Rutland, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, Daniel Lezcano, Thomas Gleixner
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, marc.zyngier-5wv7dgnIgG8,
stuart.yoder-3arQi8VN3Tc, linuxarm-hv44wF8Li93QT0dZR+AlfA,
oss-fOR+EgIDQEHk1uMJSBkQmQ, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170120150428.GC22152@leverpostej>
On 2017/1/20 23:04, Mark Rutland wrote:
> On Thu, Jan 19, 2017 at 09:35:12PM +0800, Ding Tianhong wrote:
>> Ding Tianhong (4):
>> arm64: arch_timer: Add device tree binding for hisilicon-161010101
>> erratum
>> arm64: arch_timer: Introduce a generic erratum handing mechanism for
>> fsl-a008585
>> arm64: arch_timer: Work around Erratum Hisilicon-161010101
>> arm64: arch timer: Add timer erratum property for Hip05-d02 and
>> Hip06-d03
>>
>> Documentation/admin-guide/kernel-parameters.txt | 9 --
>> Documentation/arm64/silicon-errata.txt | 43 +++---
>> .../devicetree/bindings/arm/arch_timer.txt | 6 +
>> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
>> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
>> arch/arm64/include/asm/arch_timer.h | 38 ++----
>> drivers/clocksource/Kconfig | 18 +++
>> drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------
>> 8 files changed, 171 insertions(+), 95 deletions(-)
>
> I've picked these up (with a few local cleanups), given that some local
> testing, and pushed the result to a branch [1] on my git repo.
>
> There are likely to be clashes with the arm64 tree (e.g. for
> silicon-errata.txt), and we're also likely to have more arch timer
> updates shortly for the GTDT stuff, so I think the best bet is for both
> arm64 and the clocksource tree to pull that branch for v4.11.
>
> Alternatively, we could take this all through the arm64 tree, if the
> clocksource maintainers are happy with that.
>
> Thoughts?
>
Hi Mark:
It is really a great milestone now, Thanks for the help, and I will still wait
for Marc's new opinion for this version, hoping no need to change anything else. :)
Thanks
Ding
> Thanks,
> Mark.
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arch-timer/hisi-161010101
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> .
>
--
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
* [RFC][PATCH] ASoC: add simple-graph-card document
From: Kuninori Morimoto @ 2017-01-23 7:33 UTC (permalink / raw)
To: Rob Herring, Mark Brown, Linux-DT, Linux-ALSA
In-Reply-To: <87wpdm1cyq.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Hi Rob, Mark
I created OF-graph base simple sound card.
I want to post this patch-set, but it depends many things.
Thus, before posting patch-set, I would like to know
OF-graph sound DT binding was OK or not.
Can you give me comments ?
---
.../bindings/sound/simple-graph-card.txt | 140 +++++++++++++++++++++
1 file changed, 140 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/simple-graph-card.txt
diff --git a/Documentation/devicetree/bindings/sound/simple-graph-card.txt b/Documentation/devicetree/bindings/sound/simple-graph-card.txt
new file mode 100644
index 0000000..4b29284
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/simple-graph-card.txt
@@ -0,0 +1,140 @@
+Simple-Graph-Card:
+
+Simple-Graph-Card specifies audio DAI connections of SoC <-> codec.
+It is based on common bindings for device graphs.
+see ${LINUX}/Documentation/devicetree/bindings/graph.txt
+
+Basically, Simple-Graph-Card property is same as Simple-Card.
+see ${LINUX}/Documentation/devicetree/bindings/sound/simple-card.txt
+
+Below are same as Simple-Card.
+
+- simple-audio-card,name
+- simple-audio-card,format
+- simple-audio-card,frame-master
+- simple-audio-card,bitclock-master
+- simple-audio-card,bitclock-inversion
+- simple-audio-card,frame-inversion
+- simple-audio-card,dai-tdm-slot-num
+- simple-audio-card,dai-tdm-slot-width
+- clocks / system-clock-frequency
+
+These should be implemented
+- simple-audio-card,widgets
+- simple-audio-card,routing
+- simple-audio-card,mclk-fs
+- simple-audio-card,hp-det-gpio
+- simple-audio-card,mic-det-gpio
+
+Required properties:
+
+- compatible : "asoc-simple-graph-card";
+
+Optional properties:
+
+- dais : Sound DAI phandle list if Card has
+ multi DAI. see Example
+
+Each ports
+
+- port@0 : CPU setting
+- port@1 : Codec setting
+
+Example: Single DAI case
+
+ sound_card: sound {
+ compatible = "asoc-simple-graph-card";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ sound0_in: endpoint {
+ remote-endpoint = <&rsnd_port0>;
+
+ simple-audio-card,format = "left_j";
+ simple-audio-card,bitclock-master = <&rsnd_port0>;
+ simple-audio-card,frame-master = <&rsnd_port0>;
+ };
+ };
+ port@1 {
+ sound0_out: endpoint {
+ remote-endpoint = <&ak4613_port>;
+ };
+ };
+ };
+ };
+
+
+Example: Multi DAI case
+
+ sound_dai0: sound_dai@0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ sound0_in: endpoint {
+ remote-endpoint = <&rsnd_port0>;
+
+ simple-audio-card,format = "left_j";
+ simple-audio-card,bitclock-master = <&rsnd_port0>;
+ simple-audio-card,frame-master = <&rsnd_port0>;
+ };
+ };
+ port@1 {
+ sound0_out: endpoint {
+ remote-endpoint = <&ak4613_port>;
+ };
+ };
+ };
+ };
+
+ sound_dai1: sound_dai@1 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ sound1_in: endpoint {
+ remote-endpoint = <&rsnd_port1>;
+
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&rsnd_port1>;
+ simple-audio-card,frame-master = <&rsnd_port1>;
+ };
+ };
+ port@1 {
+ sound1_out: endpoint {
+ remote-endpoint = <&rcar_dw_hdmi0_snd_in>;
+ };
+ };
+ };
+ };
+
+ sound_dai2: sound_dai@2 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ sound2_in: endpoint {
+ remote-endpoint = <&rsnd_port2>;
+
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&rsnd_port2>;
+ simple-audio-card,frame-master = <&rsnd_port2>;
+ };
+ };
+ port@1 {
+ sound2_out: endpoint {
+ remote-endpoint = <&rcar_dw_hdmi1_snd_in>;
+ };
+ };
+ };
+ };
+
+ rsnd_ak4613: sound {
+ compatible = "asoc-simple-graph-card";
+
+ dais = <&sound_dai0
+ &sound_dai1
+ &sound_dai2>;
+ };
--
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
* Re: [PATCH v4 3/3] arm64: dts: freescale: ls2088a: Add DTS support for FSL's LS2088A SoC
From: Shawn Guo @ 2017-01-23 7:27 UTC (permalink / raw)
To: Abhimanyu Saini
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, scott.wood-3arQi8VN3Tc,
stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Priyanka Jain,
Ashish Kumar
In-Reply-To: <1484114979-4664-4-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
On Wed, Jan 11, 2017 at 11:39:39AM +0530, Abhimanyu Saini wrote:
> This patch adds the device tree support for FSL LS2088A SoC based on
> ARMv8 architecture.
>
> Following levels of DTSI/DTS files have been created for the LS2088A
> SoC family:
>
> - fsl-ls2088a.dtsi:
> DTS-Include file for FSL LS2088A SoC.
>
> - fsl-ls2088a-qds.dts:
> DTS file for FSL LS2088A QDS board.
>
> - fsl-ls2088a-rdb.dts:
> DTS file for FSL LS2088A RDB board.
>
> Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
> ---
> Changes for v4:
> - Incorporated Shawn's comments by reorganizing
> DTSI, moving all include definations to the top
> - add missing files
> Changes for v2:
> - reorganize LS2088A device tree to use common
> nodes from LS2080A device trees.
>
> arch/arm64/boot/dts/freescale/Makefile | 2 +
> arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts | 65 +++++++++
> arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts | 65 +++++++++
> arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 153 ++++++++++++++++++++++
> 4 files changed, 285 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 6602718..854868e 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -5,6 +5,8 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
> new file mode 100644
> index 0000000..a48145a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
> @@ -0,0 +1,65 @@
> +/*
> + * Device Tree file for Freescale LS2088A QDS Board.
> + *
> + * Copyright (C) 2016-17, Freescale Semiconductor
> + *
> + * Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library 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 library 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "fsl-ls2088a.dtsi"
Shouldn't you include fsl-ls208xa-qds.dtsi here as well?
Shawn
> +
> +/ {
> + model = "Freescale Layerscape 2088A QDS Board";
> + compatible = "fsl,ls2088a-qds", "fsl,ls2088a";
> +
> + aliases {
> + serial0 = &serial0;
> + serial1 = &serial1;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +#include "fsl-ls208xa-qds.dtsi"
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
> new file mode 100644
> index 0000000..cc8c068
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
> @@ -0,0 +1,65 @@
> +/*
> + * Device Tree file for Freescale LS2088A RDB Board.
> + *
> + * Copyright (C) 2016-17, Freescale Semiconductor
> + *
> + * Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library 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 library 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "fsl-ls2088a.dtsi"
> +
> +/ {
> + model = "Freescale Layerscape 2088A RDB Board";
> + compatible = "fsl,ls2088a-rdb", "fsl,ls2088a";
> +
> + aliases {
> + serial0 = &serial0;
> + serial1 = &serial1;
> + };
> +
> + chosen {
> + stdout-path = "serial1:115200n8";
> + };
> +};
> +
> +#include "fsl-ls208xa-rdb.dtsi"
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
> new file mode 100644
> index 0000000..b418fca
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
> @@ -0,0 +1,153 @@
> +/*
> + * Device Tree Include file for Freescale Layerscape-2088A family SoC.
> + *
> + * Copyright (C) 2016-17, Freescale Semiconductor
> + *
> + * Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library 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 library 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "fsl-ls208xa.dtsi"
> +
> +&cpu {
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x0>;
> + clocks = <&clockgen 1 0>;
> + next-level-cache = <&cluster0_l2>;
> + #cooling-cells = <2>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x1>;
> + clocks = <&clockgen 1 0>;
> + next-level-cache = <&cluster0_l2>;
> + };
> +
> + cpu2: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x100>;
> + clocks = <&clockgen 1 1>;
> + next-level-cache = <&cluster1_l2>;
> + #cooling-cells = <2>;
> + };
> +
> + cpu3: cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x101>;
> + clocks = <&clockgen 1 1>;
> + next-level-cache = <&cluster1_l2>;
> + };
> +
> + cpu4: cpu@200 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x200>;
> + clocks = <&clockgen 1 2>;
> + next-level-cache = <&cluster2_l2>;
> + #cooling-cells = <2>;
> + };
> +
> + cpu5: cpu@201 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x201>;
> + clocks = <&clockgen 1 2>;
> + next-level-cache = <&cluster2_l2>;
> + };
> +
> + cpu6: cpu@300 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x300>;
> + clocks = <&clockgen 1 3>;
> + next-level-cache = <&cluster3_l2>;
> + #cooling-cells = <2>;
> + };
> +
> + cpu7: cpu@301 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x301>;
> + clocks = <&clockgen 1 3>;
> + next-level-cache = <&cluster3_l2>;
> + };
> +
> + cluster0_l2: l2-cache0 {
> + compatible = "cache";
> + };
> +
> + cluster1_l2: l2-cache1 {
> + compatible = "cache";
> + };
> +
> + cluster2_l2: l2-cache2 {
> + compatible = "cache";
> + };
> +
> + cluster3_l2: l2-cache3 {
> + compatible = "cache";
> + };
> +};
> +
> +&pcie1 {
> + ranges = <0x81000000 0x0 0x00000000 0x20 0x00010000 0x0 0x00010000
> + 0x82000000 0x0 0x40000000 0x20 0x40000000 0x0 0x40000000>;
> +};
> +
> +&pcie2 {
> + ranges = <0x81000000 0x0 0x00000000 0x28 0x00010000 0x0 0x00010000
> + 0x82000000 0x0 0x40000000 0x28 0x40000000 0x0 0x40000000>;
> +};
> +
> +&pcie3 {
> + ranges = <0x81000000 0x0 0x00000000 0x30 0x00010000 0x0 0x00010000
> + 0x82000000 0x0 0x40000000 0x30 0x40000000 0x0 0x40000000>;
> +};
> +
> +&pcie4 {
> + ranges = <0x81000000 0x0 0x00000000 0x38 0x00010000 0x0 0x00010000
> + 0x82000000 0x0 0x40000000 0x38 0x40000000 0x0 0x40000000>;
> +};
> --
> 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
* Re: [PATCH v6 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Mike Looijmans @ 2017-01-23 7:26 UTC (permalink / raw)
To: Kedareswara rao Appana, robh+dt, mark.rutland, dan.j.williams,
vinod.koul, michal.simek, soren.brinkmann, appanad,
moritz.fischer, laurent.pinchart, luis, Jose.Abreu
Cc: dmaengine, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1484372155-19423-3-git-send-email-appanad@xilinx.com>
On 14-01-17 06:35, Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w.
> For example h/w is configured for n number of frames, user
> Submits n number of frames and triggered the DMA using issue_pending API.
>
> In the current driver flow we are submitting one frame at a time,
> But we should submit all the n number of frames at one time
> As the h/w is configured for n number of frames.
The hardware can always handle a single frame submission, by using the "park"
bit. This would make a good "cyclic" implementation too (using vdma as
framebuffer).
It could also handle all cases for "k" frames where n%k==0 (n is a multiple of
k) by simply replicating the frame pointers.
>
> This patch fixes this issue.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Jose Abreu <joabreu@synopsys.com>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v6:
> ---> Added Rob Acked-by
> ---> Updated commit message as suggested by Vinod.
> Changes for v5:
> ---> Updated xlnx,fstore-config property to xlnx,fstore-enable
> and updated description as suggested by Rob.
> Changes for v4:
> ---> Add Check for framestore configuration on Transmit case as well
> as suggested by Jose Abreu.
> ---> Modified the dev_dbg checks to dev_warn checks as suggested
> by Jose Abreu.
> Changes for v3:
> ---> Added Checks for frame store configuration. If frame store
> Configuration is not present at the h/w level and user
> Submits less frames added debug prints in the driver as relevant.
> Changes for v2:
> ---> Fixed race conditions in the driver as suggested by Jose Abreu
> ---> Fixed unnecessray if else checks in the vdma_start_transfer
> as suggested by Laurent Pinchart.
>
> .../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 2 +
> drivers/dma/xilinx/xilinx_dma.c | 78 +++++++++++++++-------
> 2 files changed, 57 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> index a2b8bfa..e951c09 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> @@ -66,6 +66,8 @@ Optional child node properties:
> Optional child node properties for VDMA:
> - xlnx,genlock-mode: Tells Genlock synchronization is
> enabled/disabled in hardware.
> +- xlnx,fstore-enable: boolean; if defined, it indicates that controller
> + supports frame store configuration.
> Optional child node properties for AXI DMA:
> -dma-channels: Number of dma channels in child node.
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 5eeea57..edb5b71 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -322,6 +322,7 @@ struct xilinx_dma_tx_descriptor {
> * @genlock: Support genlock mode
> * @err: Channel has errors
> * @idle: Check for channel idle
> + * @has_fstoreen: Check for frame store configuration
> * @tasklet: Cleanup work after irq
> * @config: Device configuration info
> * @flush_on_fsync: Flush on Frame sync
> @@ -353,6 +354,7 @@ struct xilinx_dma_chan {
> bool genlock;
> bool err;
> bool idle;
> + bool has_fstoreen;
> struct tasklet_struct tasklet;
> struct xilinx_vdma_config config;
> bool flush_on_fsync;
> @@ -990,6 +992,27 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> if (list_empty(&chan->pending_list))
> return;
>
> + /*
> + * Note: When VDMA is built with default h/w configuration
> + * User should submit frames upto H/W configured.
> + * If users submits less than h/w configured
> + * VDMA engine tries to write to a invalid location
> + * Results undefined behaviour/memory corruption.
> + *
> + * If user would like to submit frames less than h/w capable
> + * On S2MM side please enable debug info 13 at the h/w level
> + * On MM2S side please enable debug info 6 at the h/w level
> + * It will allows the frame buffers numbers to be modified at runtime.
> + */
> + if (!chan->has_fstoreen &&
> + chan->desc_pendingcount < chan->num_frms) {
> + dev_warn(chan->dev, "Frame Store Configuration is not enabled at the\n");
> + dev_warn(chan->dev, "H/w level enable Debug info 13 or 6 at the h/w level\n");
> + dev_warn(chan->dev, "OR Submit the frames upto h/w Capable\n\r");
> +
> + return;
> + }
> +
> desc = list_first_entry(&chan->pending_list,
> struct xilinx_dma_tx_descriptor, node);
> tail_desc = list_last_entry(&chan->pending_list,
> @@ -1052,25 +1075,38 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> if (chan->has_sg) {
> dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
> tail_segment->phys);
> + list_splice_tail_init(&chan->pending_list, &chan->active_list);
> + chan->desc_pendingcount = 0;
> } else {
> struct xilinx_vdma_tx_segment *segment, *last = NULL;
> - int i = 0;
> + int i = 0, j = 0;
>
> if (chan->desc_submitcount < chan->num_frms)
> i = chan->desc_submitcount;
>
> - list_for_each_entry(segment, &desc->segments, node) {
> - if (chan->ext_addr)
> - vdma_desc_write_64(chan,
> - XILINX_VDMA_REG_START_ADDRESS_64(i++),
> - segment->hw.buf_addr,
> - segment->hw.buf_addr_msb);
> - else
> - vdma_desc_write(chan,
> - XILINX_VDMA_REG_START_ADDRESS(i++),
> - segment->hw.buf_addr);
> -
> - last = segment;
> + for (j = 0; j < chan->num_frms; ) {
> + list_for_each_entry(segment, &desc->segments, node) {
> + if (chan->ext_addr)
> + vdma_desc_write_64(chan,
> + XILINX_VDMA_REG_START_ADDRESS_64(i++),
> + segment->hw.buf_addr,
> + segment->hw.buf_addr_msb);
> + else
> + vdma_desc_write(chan,
> + XILINX_VDMA_REG_START_ADDRESS(i++),
> + segment->hw.buf_addr);
> +
> + last = segment;
> + }
> + list_del(&desc->node);
> + list_add_tail(&desc->node, &chan->active_list);
> + j++;
> + if (list_empty(&chan->pending_list) ||
> + (i == chan->num_frms))
> + break;
> + desc = list_first_entry(&chan->pending_list,
> + struct xilinx_dma_tx_descriptor,
> + node);
> }
>
> if (!last)
> @@ -1081,20 +1117,14 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
> last->hw.stride);
> vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
> - }
>
> - chan->idle = false;
> - if (!chan->has_sg) {
> - list_del(&desc->node);
> - list_add_tail(&desc->node, &chan->active_list);
> - chan->desc_submitcount++;
> - chan->desc_pendingcount--;
> + chan->desc_submitcount += j;
> + chan->desc_pendingcount -= j;
> if (chan->desc_submitcount == chan->num_frms)
> chan->desc_submitcount = 0;
> - } else {
> - list_splice_tail_init(&chan->pending_list, &chan->active_list);
> - chan->desc_pendingcount = 0;
> }
> +
> + chan->idle = false;
> }
>
> /**
> @@ -1342,6 +1372,7 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
>
> chan->err = false;
> chan->idle = true;
> + chan->desc_submitcount = 0;
>
> return err;
> }
> @@ -2320,6 +2351,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> has_dre = of_property_read_bool(node, "xlnx,include-dre");
>
> chan->genlock = of_property_read_bool(node, "xlnx,genlock-mode");
> + chan->has_fstoreen = of_property_read_bool(node, "xlnx,fstore-enable");
>
> err = of_property_read_u32(node, "xlnx,datawidth", &value);
> if (err) {
>
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 00/12] Add basic code support for imx6sll
From: Jacky Bai @ 2017-01-23 7:18 UTC (permalink / raw)
To: Shawn Guo
Cc: mturquette@baylibre.com, sboyd@codeaurora.org, robh+dt@kernel.org,
mark.rutland@arm.com, linus.walleij@linaro.org,
devicetree@vger.kernel.org, kernel@pengutronix.de,
daniel.lezcano@linaro.org, linux-gpio@vger.kernel.org,
p.zabel@pengutronix.de, jacky.baip@gmail.com, Fabio Estevam,
tglx@linutronix.de, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170123061034.GE5662@dragon>
> From: Shawn Guo [mailto:shawnguo@kernel.org]
>
> On Tue, Dec 27, 2016 at 05:47:38PM +0800, Bai Ping wrote:
> > The i.MX 6SoloLiteLite application processors are NXP's latest
> > additions to a growing family of multimedia-focused products offering
> > high-performance processing optimized for lowest power consumption.
> > The i.MX 6SoloLiteLite processors feature NXP's advanced
> > implementation of the ARM Cortex-A9 core, which can be interfaced with
> > LPDDR3 and LPDDR2 DRAM memory devices.
> >
> > i.MX6SLL is a new SOC of the i.MX6 family, shares many common modules,
> > so most of the MSL code can be resued from i.MX6 serious SOC.
> >
> >
> > change for V2:
> > - address comments in dts and dtsi from Fabio.
> > - split the doc update into two patch, fix typo.
> > - address comments in clock driver, add necessary 'const'qualifier.
> >
> > Bai Ping (12):
> > ARM: imx: Add basic msl support for imx6sll
> > driver: clocksource: add gpt timer for imx6sll
> > Document: dt: binding: imx: update clock doc for imx6sll
> > driver: clk: imx: Add clock driver for imx6sll
> > Document: dt: binding: imx: update pinctrl doc for imx6sll
> > driver: pinctrl: imx: Add pinctrl driver support for imx6sll
> > ARM: dts: imx: Add basic dtsi for imx6sll
> > ARM: dts: imx: Add imx6sll EVK board dts support
> > ARM: debug: Add low level debug support for imx6sll
> > ARM: imx: Add suspend/resume support for imx6sll
> > ARM: imx: correct i.mx6sll dram io low power mode
> > ARM: configs: enable imx6sll support in defconfig
>
> I do not think you need to necessarily put them into a series, since they will go
> through different sub-system maintainers. If there are dependencies
> between them, you should manage to get the prerequisite parts get merged
> first.
ok, got it.
>
> Shawn
^ permalink raw reply
* Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn
From: Julia Lawall @ 2017-01-23 7:18 UTC (permalink / raw)
To: Guenter Roeck
Cc: Joe Perches, Florian Fainelli, linux-kernel, Rob Herring,
Mark Rutland, Jean Delvare, Jonathan Corbet,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:HARDWARE MONITORING, open list:DOCUMENTATION
In-Reply-To: <637f229a-cfbb-938e-4700-89b180c8b2c0@roeck-us.net>
On Sun, 22 Jan 2017, Guenter Roeck wrote:
> On 01/22/2017 10:43 PM, Joe Perches wrote:
> > On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:
> > > We have a device reference, utilize it instead of pr_warn().
> >
> > There is at least one more hwmon to convert in applesmc.c
> >
> > Perhaps a coccinelle script?
> >
> > Two questions for Julia Lawall:
> >
> > o is there a better way to do this than repeat the blocks
> > one for each replacement
> > o can struct device * dev be made an arbitrary identifier
>
> Definitely yes here; otherwise you only catch the ones named 'dev'.
> Did you try "identifier dev;" ?
Definitely do that.
>
> The type of fn is irrelevant; you don't need to specify it.
Agreed.
> There is also the case where 'struct device *dev' is a local variable
>
> fn(...) {
> ...
> struct device *dev = e;
> <...
> ...>
> }
Here, you don't need the fn(...) { ... } part. It would also be good to
say:
expression e != NULL;
dev could also be initialized:
@@
struct device *dev;
expression e != NULL;
expression e1;
@@
dev = e;
<...
-
+
...>
? dev = e1; // stop when dev is reinitialized, to avoid a double match
The rules can all be merged together with a disjunction:
(
- pr_emerg
+ dev_emerg
|
- pr_crit
+ dev_crit // fill in all cases
)
(
+ dev,
...)
julia
> or when it isn't but is still available
>
> fn (..., struct \(platform_device\|i2c_device\|spi_device\) *pdev, ...) {
> }
>
> >
> > $ cat dev_printk.cocci
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > - pr_emerg(
> > + dev_emerg(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > - pr_crit(
> > + dev_crit(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > - pr_alert(
> > + dev_alert(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > - pr_err(
> > + dev_err(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > - pr_notice(
> > + dev_notice(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > - pr_warn(
> > + dev_warn(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > - pr_info(
> > + dev_info(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > - pr_debug(
> > + dev_dbg(dev,
> > ...);
> > ...>
> > }
> >
> >
>
>
^ permalink raw reply
* RE: [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc for imx6sll
From: Jacky Bai @ 2017-01-23 7:17 UTC (permalink / raw)
To: Shawn Guo, Linus Walleij
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Sascha Hauer, Fabio Estevam, Daniel Lezcano, Thomas Gleixner,
Philipp Zabel, linux-clk, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
jacky.baip@gmail.com, Anson Huang
In-Reply-To: <20170123060454.GD5662@dragon>
> From: Shawn Guo [mailto:shawnguo@kernel.org]
> > >>
> > >> > Another thing is that we can use a pins-tool program developed by
> > >> > NXP to generate the pinctrl configuration code that can be used
> > >> > directly in dts. This tiny program can avoid pin function
> > >> > conflict. As on i.MX, there are so may pins, each pin can be used for up 8
> function.
> > >> > Configuring the pins is a time-consuming work. This tools is
> > >> > very useful for
> > >> customer to generate the dts code.
> > >>
> > >> I understand, but every silicon vendor has such a tool, all are
> > >> different, proprietary and unfriendly to programmers and open
> > >> source developers, who need to understand how the hardware is
> > >> working without magic tools and secret data sheets to fix bugs.
> > >>
> > >> For the people working with maintaining the code it is paramount
> > >> that DTS files are self-descriptive.
> > >
> > > OK. Thanks for your comments. Adding generic-pinconf in imx
> > > pinctrl needs some time to finish and the legacy method still need be here
> even if generic-pinconf is added.
> > > Do you plan to pick this legacy binding patch for now?
> >
> > As I said earlier:
> >
> > > atleast I need an indication from one of the i.MX maintainers how
> > > they want to proceed.
>
> Sorry for being late for the discussion.
>
> To be honest, I did not really expect so many i.MX6 variants coming to us. Just
> out of curiosity, are there any more in the pipeline to come, or is this the last
> known one?
>
AFAIK, this should be the last variant of i.MX6. But not the last one of i.MX family.
> I understand that there are now more generic support available at pinctrl core
> level for us to use than the time we initial designed i.MX pinctrl driver. But I
> intend to agree with Jacky that imx6sll can be supported by the existing driver,
> since it doesn't require any additional driver changes.
>
> If any new generation of i.MX family require changes on the existing pinctrl
> driver, we should probably push back for a redesign to use generic support as
> much as possible. @Jacky, how does i.MX8 pinctrl look like? How same or
> different as/from i.MX6 pinctrl?
>
i.MX8 kernel support is in development stage. The code has not been finalized.
For now, i.MX8 shares most of the pinctrl code with i.MX6 and use the same pinconfig method.
> Just my opinion.
>
> Shawn
^ permalink raw reply
* Re: [PATCH v2 1/1] ARM: dts: add Armadeus Systems OPOS6UL and OPOS6ULDEV support
From: Shawn Guo @ 2017-01-23 7:02 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Sascha Hauer,
Fabio Estevam, Julien Boibessot
In-Reply-To: <1484055173-29943-1-git-send-email-sebastien.szymanski-d2DlULPkwbNWk0Htik3J/w@public.gmane.org>
On Tue, Jan 10, 2017 at 02:32:53PM +0100, Sébastien Szymanski wrote:
> OPOS6UL is an i.MX6UL based SoM.
> OPOS6ULDev is a carrier board for the OPOS6UL SoM.
>
> For more details see:
> http://www.opossom.com/english/products-processor_boards-opos6ul.html
> http://www.opossom.com/english/products-development_boards-opos6ul_dev.html
>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski-d2DlULPkwbNWk0Htik3J/w@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn
From: Guenter Roeck @ 2017-01-23 7:01 UTC (permalink / raw)
To: Joe Perches, Florian Fainelli, linux-kernel, Julia Lawall
Cc: Rob Herring, Mark Rutland, Jean Delvare, Jonathan Corbet,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:HARDWARE MONITORING, open list:DOCUMENTATION
In-Reply-To: <1485153837.12563.23.camel@perches.com>
On 01/22/2017 10:43 PM, Joe Perches wrote:
> On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:
>> We have a device reference, utilize it instead of pr_warn().
>
> There is at least one more hwmon to convert in applesmc.c
>
> Perhaps a coccinelle script?
>
> Two questions for Julia Lawall:
>
> o is there a better way to do this than repeat the blocks
> one for each replacement
> o can struct device * dev be made an arbitrary identifier
Definitely yes here; otherwise you only catch the ones named 'dev'.
Did you try "identifier dev;" ?
The type of fn is irrelevant; you don't need to specify it.
There is also the case where 'struct device *dev' is a local variable
fn(...) {
...
struct device *dev = e;
<...
...>
}
or when it isn't but is still available
fn (..., struct \(platform_device\|i2c_device\|spi_device\) *pdev, ...) {
}
>
> $ cat dev_printk.cocci
> @@
> identifier fn;
> type T;
> @@
>
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_emerg(
> + dev_emerg(dev,
> ...);
> ...>
> }
>
> @@
> identifier fn;
> type T;
> @@
>
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_crit(
> + dev_crit(dev,
> ...);
> ...>
> }
>
> @@
> identifier fn;
> type T;
> @@
>
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_alert(
> + dev_alert(dev,
> ...);
> ...>
> }
>
> @@
> identifier fn;
> type T;
> @@
>
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_err(
> + dev_err(dev,
> ...);
> ...>
> }
>
> @@
> identifier fn;
> type T;
> @@
>
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_notice(
> + dev_notice(dev,
> ...);
> ...>
> }
>
> @@
> identifier fn;
> type T;
> @@
>
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_warn(
> + dev_warn(dev,
> ...);
> ...>
> }
>
> @@
> identifier fn;
> type T;
> @@
>
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_info(
> + dev_info(dev,
> ...);
> ...>
> }
>
> @@
> identifier fn;
> type T;
> @@
>
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_debug(
> + dev_dbg(dev,
> ...);
> ...>
> }
>
>
^ 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