* [RESEND PATCH v3 2/2] ARM: dts: imx6ul: Add DTS for liteBoard
From: Marcin Niestroj @ 2016-09-30 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930093626.3843-1-m.niestroj@grinn-global.com>
liteBoard is a development board which uses liteSOM as its base.
Hardware specification:
* liteSOM (i.MX6UL, DRAM, eMMC)
* Ethernet PHY (id 0)
* USB host (usb_otg1)
* MicroSD slot (uSDHC1)
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes v2 -> v3: none
Changes v1 -> v2:
* Use dual license
* Fix typo "defaullt" -> "default"
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-liteboard.dts | 153 +++++++++++++++++++++++++++++++++
2 files changed, 154 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-liteboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52..b149313 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
imx6sx-sdb.dtb
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
+ imx6ul-liteboard.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-liteboard.dts b/arch/arm/boot/dts/imx6ul-liteboard.dts
new file mode 100644
index 0000000..f2e04f2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-liteboard.dts
@@ -0,0 +1,153 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include "imx6ul-litesom.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteBoard";
+ compatible = "grinn,imx6ul-liteboard", "grinn,imx6ul-litesom",
+ "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usb_otg1_vbus: usb_otg1_regulator {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_otg1_vbus>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 8 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10071
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usb_otg1_vbus: usb_otg1_vbus {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x79
+ >;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+ };
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usbotg1 {
+ vbus-supply = <®_usb_otg1_vbus>;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ keep-power-in-suspend;
+ wakeup-source;
+ status = "okay";
+};
--
2.10.0
^ permalink raw reply related
* [RESEND PATCH v3 1/2] ARM: dts: imx6ul: Add DTS for liteSOM module
From: Marcin Niestroj @ 2016-09-30 9:36 UTC (permalink / raw)
To: linux-arm-kernel
This is a SOM (System on Module), so it will be part of another boards.
Hence, this is a "dtsi" file that will be included from another device
tree files.
Hardware specification:
* Freescale i.MX6UL SoC
* up to 512 MB RAM
* eMMC on uSDHC2
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes v2 -> v3:
* Remove cpu0 supplies (arm-supply, soc-supply), as they were already
set in imx6ul.dtsi file (reported by S?bastien Szymanski)
Changes v1 -> v2:
* Use dual license
arch/arm/boot/dts/imx6ul-litesom.dtsi | 82 +++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-litesom.dtsi
diff --git a/arch/arm/boot/dts/imx6ul-litesom.dtsi b/arch/arm/boot/dts/imx6ul-litesom.dtsi
new file mode 100644
index 0000000..461292d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-litesom.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include "imx6ul.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteSOM";
+ compatible = "grinn,imx6ul-litesom", "fsl,imx6ul";
+
+ memory {
+ reg = <0x80000000 0x20000000>;
+ };
+};
+
+&iomuxc {
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10069
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17059
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17059
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17059
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17059
+ MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x17059
+ >;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ no-1-8-v;
+ non-removable;
+ keep-power-in-suspend;
+ wakeup-source;
+ bus-width = <8>;
+ status = "okay";
+};
--
2.10.0
^ permalink raw reply related
* [PATCH 2/6] ARM: dts: da850: add a node for the LCD controller
From: Sekhar Nori @ 2016-09-30 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475166715-7857-3-git-send-email-bgolaszewski@baylibre.com>
On Thursday 29 September 2016 10:01 PM, Bartosz Golaszewski wrote:
> From: Karl Beldan <kbeldan@baylibre.com>
>
> Add a disabled LCDC node to be reused in device trees including
> da850.dtsi for boards equipped with tilcdc enabled.
>
> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> [Bartosz: added the commit description]
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index f79e1b9..9f39296 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -399,6 +399,14 @@
> <&edma0 0 1>;
> dma-names = "tx", "rx";
> };
> +
> + lcdc: lcdc at 213000 {
node name should be generic per the ePAPR so please use "display".
> + compatible = "ti,am33xx-tilcdc";
Can you please introduce a da850 specific compatible. Something like:
compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
Even if you dont use it in the driver today, please have it in the .dts
I am pretty sure there will be some da850 specific tweak required for
the LCDC at some point. Having a compatible already in place will make
migration easier. You will have to document the compatible though.
This will affect 1/6 too.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc
From: Bartosz Golaszewski @ 2016-09-30 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929190736.vgd3xylzm2nh32l4@gobelin>
2016-09-29 21:07 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> Hi,
>
> On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote:
>> Default memory settings of da850 do not meet the throughput/latency
>> requirements of tilcdc. This results in the image displayed being
>> incorrect and the following warning being displayed by the LCDC
>> drm driver:
>>
>> tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>
>> Reconfigure the LCDC priority to the highest. This is a workaround
>> for the da850-lcdk board which has the LCD controller enabled in
>> the device tree, but a long-term, system-wide fix is needed for
>> all davinci boards.
>>
>> This patch has been modified for mainline linux. It comes from a
>> downstream TI release for da850[1].
>>
>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>>
>> [1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>
> FWIW, the quirks could be applied conditionnally depending on the lcdc
> node presence in the DT, a bit like:
> https://github.com/kbeldan/linux/commit/cf15572ffef8e8a0d8110b3f6b29bd401d0538be
> https://github.com/kbeldan/linux/commit/07e4fff9958bc1625a96791dce284c163fbe9c43
>
>
> Regards,
> Karl
Hi Karl,
I decided to post the simplest possible way of this to get the lcdc
working upstream. In parallel I'm working on a system-wide way of
applying such quirks not only limited to device tree nodes' presence.
Thanks for the info!
Best regards,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH v4 2/2] arm64 Kconfig: Select gigantic page
From: Yisheng Xie @ 2016-09-30 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475227569-63446-1-git-send-email-xieyisheng1@huawei.com>
Arm64 supports gigantic page after
commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
however, it can only be allocated at boottime and can't be freed.
This patch selects ARCH_HAS_GIGANTIC_PAGE to make gigantic pages
can be allocated and freed at runtime for arch arm64.
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f..92217f6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -9,6 +9,7 @@ config ARM64
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
+ select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_KCOV
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
--
1.7.12.4
^ permalink raw reply related
* [PATCH v4 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
From: Yisheng Xie @ 2016-09-30 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475227569-63446-1-git-send-email-xieyisheng1@huawei.com>
Avoid making ifdef get pretty unwieldy if many ARCHs support gigantic page.
No functional change with this patch.
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Suggested-by: Michal Hocko <mhocko@suse.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
---
arch/s390/Kconfig | 1 +
arch/x86/Kconfig | 1 +
fs/Kconfig | 3 +++
mm/hugetlb.c | 2 +-
4 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c109f07..74a9e45 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -71,6 +71,7 @@ config S390
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
+ select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_KCOV
select ARCH_HAS_SG_CHAIN
select ARCH_HAVE_NMI_SAFE_CMPXCHG
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2a1f0ce..aa0b26a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -28,6 +28,7 @@ config X86
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_GCOV_PROFILE_ALL
+ select ARCH_HAS_GIGANTIC_PAGE if X86_64
select ARCH_HAS_KCOV if X86_64
select ARCH_HAS_PMEM_API if X86_64
select ARCH_HAS_MMIO_FLUSH
diff --git a/fs/Kconfig b/fs/Kconfig
index 2bc7ad7..b938205 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -199,6 +199,9 @@ config HUGETLBFS
config HUGETLB_PAGE
def_bool HUGETLBFS
+config ARCH_HAS_GIGANTIC_PAGE
+ bool
+
source "fs/configfs/Kconfig"
source "fs/efivarfs/Kconfig"
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 87e11d8..8488dcc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1022,7 +1022,7 @@ static int hstate_next_node_to_free(struct hstate *h, nodemask_t *nodes_allowed)
((node = hstate_next_node_to_free(hs, mask)) || 1); \
nr_nodes--)
-#if (defined(CONFIG_X86_64) || defined(CONFIG_S390)) && \
+#if defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) && \
((defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || \
defined(CONFIG_CMA))
static void destroy_compound_gigantic_page(struct page *page,
--
1.7.12.4
^ permalink raw reply related
* [PATCH v4 0/2] arm64/hugetlb: enable gigantic page
From: Yisheng Xie @ 2016-09-30 9:26 UTC (permalink / raw)
To: linux-arm-kernel
changelog
=========
v3->v4:
add changelog in the cover leter to make the change history more clear.
v2->v3:
change the Kconfig file to avoid comile warning when select
ARCH_HAS_GIGANTIC_PAGE with !CONFIG_HUGETLB_PAGE
v1->v2:
introduce the ARCH_HAS_GIGANTIC_PAGE as Michal Hocko <mhocko@suse.com> suggested
Arm64 supports different size of gigantic page which can be seen from:
commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
commit 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
So I tried to use this function by adding hugepagesz=1G in kernel
parameters, with CONFIG_CMA=y. However, when I
echo xx > \
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
it failed with the following info:
-bash: echo: write error: Invalid argument
This is a v4 patchset which make gigantic page can be
allocated and freed at runtime for arch arm64,
with CONFIG_CMA=y or other related configs is enabled.
You can see the former discussions at:
https://lkml.org/lkml/2016/8/18/310
https://lkml.org/lkml/2016/8/21/410
https://lkml.org/lkml/2016/8/22/319
Yisheng Xie (2):
mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
arm64 Kconfig: Select gigantic page
arch/arm64/Kconfig | 1 +
arch/s390/Kconfig | 1 +
arch/x86/Kconfig | 1 +
fs/Kconfig | 3 +++
mm/hugetlb.c | 2 +-
5 files changed, 7 insertions(+), 1 deletion(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes
From: Brian Kim @ 2016-09-30 9:17 UTC (permalink / raw)
To: linux-arm-kernel
Enable both gxbb USB controller and add a 5V regulator for the OTG port
VBUS
Signed-off-by: Brian Kim <brian.kim@hardkernel.com>
---
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 8d89edc..997c671 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -64,6 +64,18 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ usb_pwr: regulator-usb-pwrs {
+ compatible = "regulator-fixed";
+
+ regulator-name = "USB_PWR";
+
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ gpio = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
leds {
compatible = "gpio-leds";
blue {
@@ -149,6 +161,23 @@
pinctrl-names = "default";
};
+&usb0_phy {
+ status = "okay";
+ phy-supply = <&usb_pwr>;
+};
+
+&usb1_phy {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
/* SD */
&sd_emmc_b {
status = "okay";
--
2.7.4
^ permalink raw reply related
* [PATCH v2] arm64: make rpm failed due to incorrect path to Image.gz
From: Will Deacon @ 2016-09-30 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930070325.GA3834@localhost.localdomain>
On Fri, Sep 30, 2016 at 12:03:26AM -0700, Vadim Lomovtsev wrote:
> [Adding Will Deacon]
> Sorry, should do this at the very beginning. (
>
> On Thu, Sep 29, 2016 at 07:46:07AM -0700, Vadim Lomovtsev wrote:
> > The "make rpm" and "make rpm-pkg" commands for arm64 platform
> > are broken due to rpmbuild couldn't find Image.gz file at
> > default location (which is kernel src root):
> > cp: cannot stat 'Image.gz': No such file or directory
> > error: Bad exit status from /var/tmp/rpm-tmp.ocFBmP (%install)
> >
> > While the correct path to arm64 kernel image file
> > is "arch/arm64/boot/Image.gz".
> >
> > The exact file name (Image.gz) is stored at KBUILD_IMAGE variable
> > and read by rpmbuild with "make image_name" command at
> > install phase after kernel build is complete.
> >
> > Accordingly to Michal's Marek comment the KBUILD_IMAGE
> > variable has to be set to point to actual file.
> >
> > Since the KBUILD_IMAGE variable is used in general cases of
> > build we need to prevent other build types breakage by changing it.
> >
> > The solution is to add to arch/arm64/Makefie extra target "image_name"
> > with dependency "KBUILD_IMAGE:=<proper path to Image.gz file>".
> > Thus it will allow to set proper path to Image.gz file only for
> > the "image_name" build target and this exact value will be picked up
> > while rpm build install phase.
> >
> > Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> > ---
> > arch/arm64/Makefile | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index ab51aed..09926d3 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -101,6 +101,8 @@ all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
> >
> > boot := arch/arm64/boot
> >
> > +image_name: KBUILD_IMAGE :=$(boot)/$(KBUILD_IMAGE)
> > +
> > Image: vmlinux
> > $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
It might be worth fixing the other architectures that just set KBUILD_IMAGE
to the filename too. Then you could remove the bodge from
scripts/package/builddeb that tries to support both formats.
Will
^ permalink raw reply
* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Uwe Kleine-König @ 2016-09-30 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930085801.21497-3-richard.genoud@gmail.com>
Hello Richard,
On Fri, Sep 30, 2016 at 10:58:00AM +0200, Richard Genoud wrote:
> Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
> hardware handshake is enabled") broke the hardware handshake when GPIOs
> were used.
>
> Hardware handshake with GPIOs used to work before this commit because
> the CRTSCTS flag (termios->c_cflag) was set, but not the
> ATMEL_US_USMODE_HWHS flag (controller register) ; so hardware handshake
> enabled, but not handled by the controller.
What does the HWHS flag control? What if only RTS is a gpio and CTS is
not? Or the other way round?
What is the problematic setup? I guess it's RTS and CTS are gpios and
with that setting ATMEL_US_USMODE_HWHS is wrong? What happens if that
happens?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v6 3/3] pci:add support aer/pme interrupts with none MSI/MSI-X/INTx mode
From: Po Liu @ 2016-09-30 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475226697-7709-1-git-send-email-po.liu@nxp.com>
On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
When chip support the aer/pme interrupts with none MSI/MSI-X/INTx mode,
maybe there is interrupt line for aer pme etc. Search the interrupt
number in the fdt file. Then fixup the dev->irq with it.
Signed-off-by: Po Liu <po.liu@nxp.com>
---
changes for v6:
- modify bindings for "aer""pme";
- changing to the hood method to implement the aer pme interrupt;
- add pme interrupt in the same way;
.../devicetree/bindings/pci/layerscape-pci.txt | 13 +++++--
arch/arm/kernel/bios32.c | 43 ++++++++++++++++++++++
arch/arm64/kernel/pci.c | 43 ++++++++++++++++++++++
drivers/pci/pcie/portdrv_core.c | 31 +++++++++++++++-
include/linux/pci.h | 1 +
5 files changed, 126 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 41e9f55..51ed49e 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -18,8 +18,12 @@ Required properties:
- reg: base addresses and lengths of the PCIe controller
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
-- interrupt-names: Must include the following entries:
- "intr": The interrupt that is asserted for controller interrupts
+- interrupt-names: It could include the following entries:
+ "aer": Asserted for aer interrupt when chip support the aer interrupt with
+ none MSI/MSI-X/INTx mode,but there is interrupt line for aer.
+ "pme": Asserted for pme interrupt when chip support the pme interrupt with
+ none MSI/MSI-X/INTx mode,but there is interrupt line for pme.
+ ......
- fsl,pcie-scfg: Must include two entries.
The first entry must be a link to the SCFG device node
The second entry must be '0' or '1' based on physical PCIe controller index.
@@ -35,8 +39,9 @@ Example:
reg = <0x00 0x03400000 0x0 0x00010000 /* controller registers */
0x40 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
- interrupt-names = "intr";
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>, /* aer interrupt */
+ <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* pme interrupt */
+ interrupt-names = "aer", "pme";
fsl,pcie-scfg = <&scfg 0>;
#address-cells = <3>;
#size-cells = <2>;
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 2f0e077..d2f4869 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -11,6 +11,8 @@
#include <linux/slab.h>
#include <linux/init.h>
#include <linux/io.h>
+#include <linux/of_irq.h>
+#include <linux/pcieport_if.h>
#include <asm/mach-types.h>
#include <asm/mach/map.h>
@@ -64,6 +66,47 @@ void pcibios_report_status(u_int status_mask, int warn)
}
/*
+ * Check device tree if the service interrupts are there
+ */
+int pcibios_check_service_irqs(struct pci_dev *dev, int *irqs, int mask)
+{
+ int ret, count = 0;
+ struct device_node *np = NULL;
+
+ if (dev->bus->dev.of_node)
+ np = dev->bus->dev.of_node;
+
+ if (np == NULL)
+ return 0;
+
+ if (!IS_ENABLED(CONFIG_OF_IRQ))
+ return 0;
+
+ /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
+ * request irq for aer
+ */
+ if (mask & PCIE_PORT_SERVICE_AER) {
+ ret = of_irq_get_byname(np, "aer");
+ if (ret > 0) {
+ irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
+ count++;
+ }
+ }
+
+ if (mask & PCIE_PORT_SERVICE_PME) {
+ ret = of_irq_get_byname(np, "pme");
+ if (ret > 0) {
+ irqs[PCIE_PORT_SERVICE_PME_SHIFT] = ret;
+ count++;
+ }
+ }
+
+ /* TODO: add more service interrupts if there it is in the device tree*/
+
+ return count;
+}
+
+/*
* We don't use this to fix the device, but initialisation of it.
* It's not the correct use for this, but it works.
* Note that the arbiter/ISA bridge appears to be buggy, specifically in
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index acf3872..4a3c61a 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -17,6 +17,8 @@
#include <linux/mm.h>
#include <linux/of_pci.h>
#include <linux/of_platform.h>
+#include <linux/of_irq.h>
+#include <linux/pcieport_if.h>
#include <linux/pci.h>
#include <linux/pci-acpi.h>
#include <linux/pci-ecam.h>
@@ -55,6 +57,47 @@ int pcibios_alloc_irq(struct pci_dev *dev)
}
/*
+ * Check device tree if the service interrupts are there
+ */
+int pcibios_check_service_irqs(struct pci_dev *dev, int *irqs, int mask)
+{
+ int ret, count = 0;
+ struct device_node *np = NULL;
+
+ if (dev->bus->dev.of_node)
+ np = dev->bus->dev.of_node;
+
+ if (np == NULL)
+ return 0;
+
+ if (!IS_ENABLED(CONFIG_OF_IRQ))
+ return 0;
+
+ /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
+ * request irq for aer
+ */
+ if (mask & PCIE_PORT_SERVICE_AER) {
+ ret = of_irq_get_byname(np, "aer");
+ if (ret > 0) {
+ irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
+ count++;
+ }
+ }
+
+ if (mask & PCIE_PORT_SERVICE_PME) {
+ ret = of_irq_get_byname(np, "pme");
+ if (ret > 0) {
+ irqs[PCIE_PORT_SERVICE_PME_SHIFT] = ret;
+ count++;
+ }
+ }
+
+ /* TODO: add more service interrupts if there it is in the device tree*/
+
+ return count;
+}
+
+/*
* raw_pci_read/write - Platform-specific PCI config space access.
*/
int raw_pci_read(unsigned int domain, unsigned int bus,
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index e9270b4..34b6dae 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -44,6 +44,19 @@ static void release_pcie_device(struct device *dev)
}
/**
+ * pcibios_check_service_irqs - check irqs in the device tree
+ * @dev: PCI Express port to handle
+ * @irqs: Array of irqs to populate
+ * @mask: Bitmask of port capabilities returned by get_port_device_capability()
+ *
+ * Return value: 0 means no service irqs in the device tree
+ *
+ */
+int __weak pcibios_check_service_irqs(struct pci_dev *dev, int *irqs, int mask)
+{
+ return 0;
+}
+/**
* pcie_port_msix_add_entry - add entry to given array of MSI-X entries
* @entries: Array of MSI-X entries
* @new_entry: Index of the entry to add to the array
@@ -200,6 +213,21 @@ static int pcie_port_enable_msix(struct pci_dev *dev, int *vectors, int mask)
static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
{
int i, irq = -1;
+ int ret;
+
+ /* Check if some platforms owns independent irq pins for AER/PME etc.
+ * Some platforms may own independent AER/PME interrupts and set
+ * them in the device tree file.
+ */
+ for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
+ irqs[i] = -1;
+
+ ret = pcibios_check_service_irqs(dev, irqs, mask);
+ if (ret) {
+ if (dev->irq)
+ irq = dev->irq;
+ goto no_msi;
+ }
/*
* If MSI cannot be used for PCIe PME or hotplug, we have to use
@@ -226,7 +254,8 @@ static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
no_msi:
for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
- irqs[i] = irq;
+ if (irqs[i] == -1)
+ irqs[i] = irq;
irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1;
if (irq < 0)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2599a98..c80f2d0 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1793,6 +1793,7 @@ void pcibios_release_device(struct pci_dev *dev);
void pcibios_penalize_isa_irq(int irq, int active);
int pcibios_alloc_irq(struct pci_dev *dev);
void pcibios_free_irq(struct pci_dev *dev);
+int pcibios_check_service_irqs(struct pci_dev *dev, int *irqs, int mask);
#ifdef CONFIG_HIBERNATE_CALLBACKS
extern struct dev_pm_ops pcibios_pm_ops;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v6 2/3] arm64/dts-ls1043-ls2080: add pcie aer/pme interrupt-name property in the dts
From: Po Liu @ 2016-09-30 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475226697-7709-1-git-send-email-po.liu@nxp.com>
Some platforms(NXP Layerscape for example) aer/pme interrupts was not
MSI/MSI-X/INTx but using interrupt line independently. This patch
add "aer", "pme" interrupt-names for aer/pme interrupt.
With the interrupt-names "aer", "pme" code could probe aer/pme interrupt
line for pcie root port, replace the aer/pme interrupt service irqs.
This is intend to fixup the Layerscape platforms which aer/pmes interrupts
was not MSI/MSI-X/INTx, but using interrupt line independently.
Since the interrupt-names "intr" never been used. Remove it.
Signed-off-by: Po Liu <po.liu@nxp.com>
---
changes for v6:
- add remove "intr" interrupt reason.
- add "pme" interrupt.
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 18 +++++++++---------
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 16 ++++++++--------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..654071d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -527,9 +527,9 @@
reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
0x40 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 118 0x4>, /* controller interrupt */
- <0 117 0x4>; /* PME interrupt */
- interrupt-names = "intr", "pme";
+ interrupts = <0 117 0x4>, /* PME interrupt */
+ <0 118 0x4>; /* aer interrupt */
+ interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -552,9 +552,9 @@
reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
0x48 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 128 0x4>,
- <0 127 0x4>;
- interrupt-names = "intr", "pme";
+ interrupts = <0 127 0x4>,
+ <0 128 0x4>;
+ interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -577,9 +577,9 @@
reg = <0x00 0x03600000 0x0 0x00100000 /* controller registers */
0x50 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 162 0x4>,
- <0 161 0x4>;
- interrupt-names = "intr", "pme";
+ interrupts = <0 161 0x4>,
+ <0 162 0x4>;
+ interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 21023a3..58844e8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -583,8 +583,8 @@
reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
0x10 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 108 0x4>; /* Level high type */
- interrupt-names = "intr";
+ interrupts = <0 108 0x4>; /* aer interrupt */
+ interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -607,8 +607,8 @@
reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
0x12 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 113 0x4>; /* Level high type */
- interrupt-names = "intr";
+ interrupts = <0 113 0x4>; /* aer interrupt */
+ interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -631,8 +631,8 @@
reg = <0x00 0x03600000 0x0 0x00100000 /* controller registers */
0x14 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 118 0x4>; /* Level high type */
- interrupt-names = "intr";
+ interrupts = <0 118 0x4>; /* aer interrupt */
+ interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -655,8 +655,8 @@
reg = <0x00 0x03700000 0x0 0x00100000 /* controller registers */
0x16 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 123 0x4>; /* Level high type */
- interrupt-names = "intr";
+ interrupts = <0 123 0x4>; /* aer interrupt */
+ interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v6 1/3] arm/dts-ls1021: add pcie aer/pme interrupt-name property in the dts
From: Po Liu @ 2016-09-30 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473741659-17618-3-git-send-email-po.liu@nxp.com>
NXP arm aer/pme interrupts was not MSI/MSI-X/INTx but using interrupt
line independently. This patch add a "aer" "pme" interrupt-names for
aer/pme interrupts.
With the interrupt-names "aer","pme" code could probe aer/pme interrupt
line for pcie root port, replace the aer/pme interrupt service irqs.
This patch is intend to fixup the Layerscape platforms which aer/pme
interrupt was not MSI/MSI-X/INTx, but using interrupt line independently.
Since the interrupt-names "intr" never been used. Remove it.
Signed-off-by: Po Liu <po.liu@nxp.com>
---
changes for v6:
- add remove "intr" reason;
- add "pme" interrupt;
arch/arm/boot/dts/ls1021a.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..9b3cb3b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -634,7 +634,9 @@
reg = <0x00 0x03400000 0x0 0x00010000 /* controller registers */
0x40 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+ interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
+ interrupt-names = "pme", "aer";
fsl,pcie-scfg = <&scfg 0>;
#address-cells = <3>;
#size-cells = <2>;
@@ -657,7 +659,9 @@
reg = <0x00 0x03500000 0x0 0x00010000 /* controller registers */
0x48 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
+ interrupt-names = "pme", "aer";
fsl,pcie-scfg = <&scfg 1>;
#address-cells = <3>;
#size-cells = <2>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: CK Hu @ 2016-09-30 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475225778.25044.35.camel@mtksdaap41>
Hi, HS:
One comment inline
On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> Hi CK,
>
> Please see my inline reply.
>
> On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > Hi, HS:
> >
> > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > > CMDQ is used to help write registers with critical time limitation,
> > > such as updating display configuration during the vblank. It controls
> > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > Currently, CMDQ only supports display related hardwares, but we expect
> > > it can be extended to other hardwares for future requirements.
> > >
> > > Signed-off-by: HS Liao <hs.liao@mediatek.com>
> > > Signed-off-by: CK Hu <ck.hu@mediatek.com>
> > > ---
> >
> > [snip...]
> >
> > > +
> > > +struct cmdq_task {
> > > + struct cmdq *cmdq;
> > > + struct list_head list_entry;
> > > + void *va_base;
> > > + dma_addr_t pa_base;
> > > + size_t cmd_buf_size; /* command occupied size */
> > > + size_t buf_size; /* real buffer size */
> > > + bool finalized;
> > > + struct cmdq_thread *thread;
> >
> > I think thread info could be removed from cmdq_task. Only
> > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > task->thread and caller of both function has the thread info. So you
> > could just pass thread info into these two function and remove thread
> > info in cmdq_task.
>
> This modification will remove 1 pointer but add 2 pointers. Moreover,
> more pointers will need to be delivered between functions for future
> extension. IMHO, it would be better to keep thread pointer inside
> cmdq_task.
>
> > > + struct cmdq_task_cb cb;
> >
> > I think this callback function is equal to mailbox client tx_done
> > callback. It's better to use already-defined interface rather than
> > creating your own.
>
> This is because CMDQ driver allows different callback functions for
> different tasks, but mailbox only allows one callback function per
> channel. But, I think I can add a wrapper for tx_done to call CMDQ
> callback functions. So, I will use tx_done in CMDQ v15.
Up to now, one callback function for one channel is enough for DRM. So
'different callback function for different sent-message' looks like an
advanced function. Maybe you should not include it in first patch.
Regards,
CK
>
> > > +};
> > > +
> >
> > [snip...]
> >
> > > +
> > > +static int cmdq_suspend(struct device *dev)
> > > +{
> > > + struct cmdq *cmdq = dev_get_drvdata(dev);
> > > + struct cmdq_thread *thread;
> > > + int i;
> > > + bool task_running = false;
> > > +
> > > + mutex_lock(&cmdq->task_mutex);
> > > + cmdq->suspended = true;
> > > + mutex_unlock(&cmdq->task_mutex);
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
> > > + thread = &cmdq->thread[i];
> > > + if (!list_empty(&thread->task_busy_list)) {
> > > + mod_timer(&thread->timeout, jiffies + 1);
> > > + task_running = true;
> > > + }
> > > + }
> > > +
> > > + if (task_running) {
> > > + dev_warn(dev, "exist running task(s) in suspend\n");
> > > + msleep(20);
> >
> > Why sleep here? It looks like a recovery but could 20ms recovery
> > something? I think warning message is enough because you see the warning
> > message, and you fix the bug, so no need to recovery anything.
>
> My purpose is context switch to finish timer's work.
> I will replace it by schedule().
>
> > > + }
> > > +
> > > + clk_unprepare(cmdq->clock);
> > > + return 0;
> > > +}
> > > +
> >
> > Regards,
> > CK
>
> Thanks,
> HS
>
>
^ permalink raw reply
* [PATCH v5 01/14] drivers: iommu: add FWNODE_IOMMU fwnode type
From: Lorenzo Pieralisi @ 2016-09-30 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3178073.UTpgCTN6if@vostro.rjw.lan>
On Thu, Sep 29, 2016 at 10:59:40PM +0200, Rafael J. Wysocki wrote:
> On Thursday, September 29, 2016 03:15:20 PM Lorenzo Pieralisi wrote:
> > Hi Rafael,
> >
> > On Fri, Sep 09, 2016 at 03:23:30PM +0100, Lorenzo Pieralisi wrote:
> > > On systems booting with a device tree, every struct device is
> > > associated with a struct device_node, that represents its DT
> > > representation. The device node can be used in generic kernel
> > > contexts (eg IRQ translation, IOMMU streamid mapping), to
> > > retrieve the properties associated with the device and carry
> > > out kernel operation accordingly. Owing to the 1:1 relationship
> > > between the device and its device_node, the device_node can also
> > > be used as a look-up token for the device (eg looking up a device
> > > through its device_node), to retrieve the device in kernel paths
> > > where the device_node is available.
> > >
> > > On systems booting with ACPI, the same abstraction provided by
> > > the device_node is required to provide look-up functionality.
> > >
> > > Therefore, mirroring the approach implemented in the IRQ domain
> > > kernel layer, this patch adds an additional fwnode type FWNODE_IOMMU.
> > >
> > > This patch also implements a glue kernel layer that allows to
> > > allocate/free FWNODE_IOMMU fwnode_handle structures and associate
> > > them with IOMMU devices.
> > >
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
> > > Cc: Joerg Roedel <joro@8bytes.org>
> > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > ---
> > > include/linux/fwnode.h | 1 +
> > > include/linux/iommu.h | 25 +++++++++++++++++++++++++
> > > 2 files changed, 26 insertions(+)
> > >
> > > diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
> > > index 8516717..6e10050 100644
> > > --- a/include/linux/fwnode.h
> > > +++ b/include/linux/fwnode.h
> > > @@ -19,6 +19,7 @@ enum fwnode_type {
> > > FWNODE_ACPI_DATA,
> > > FWNODE_PDATA,
> > > FWNODE_IRQCHIP,
> > > + FWNODE_IOMMU,
> >
> > This patch provides groundwork for this series and it is key for
> > the rest of it, basically the point here is that we need a fwnode
> > to differentiate platform devices created out of static ACPI tables
> > entries (ie IORT), that represent IOMMU components.
> >
> > The corresponding device is not an ACPI device (I could fabricate one as
> > it is done for other static tables entries eg FADT power button, but I
> > do not necessarily see the reason for doing that given that all we need
> > the fwnode for is a token identifier), so FWNODE_ACPI does not apply
> > here.
> >
> > Please let me know if it is reasonable how I sorted this out (it
> > is basically identical to IRQCHIP, just another enum entry), the
> > remainder of the code depends on this.
>
> I'm not familiar with the use case, so I don't see anything unreasonable
> in it.
The use case is pretty simple: on ARM SMMU devices are platform devices.
When booting with DT they are identified through an of_node and related
FWNODE_OF type. When booting with ACPI, the ARM SMMU platform devices,
to be equivalent to DT booting path, should be created out of static
IORT table entries (that's how we describe SMMUs); we need to create
a fwnode "token" to associate with those platform devices and that's
not a FWNODE_ACPI (that is for an ACPI device firmware object, here we
really do not need one), so this patch.
> If you're asking about whether or not I mind adding more fwnode types in
> principle, then no, I don't. :-)
Yes, that's what I was asking, the only point that bugs me is that for
both FWNODE_IRQCHIP and FWNODE_IOMMU the fwnode is just a "token" (ie a
valid pointer) used for look-up and the type in the fwnode_handle is
mostly there for error checking, I was wondering if we could create a
specific fwnode_type for this specific usage (eg FWNODE_TAG and then add
a type to it as part of its container struct) instead of adding an enum
value per subsystem - it seems there are other fwnode types in the
pipeline :), so I am asking:
lkml.kernel.org/r/3D1468514043-21081-3-git-send-email-minyard at acm.org
If it is ok for you and Joerg I will go ahead with current patch
keeping in mind that the above should not be that complicated to
implement if we deem it reasonable.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH v14 4/4] CMDQ: save more energy in idle
From: Matthias Brugger @ 2016-09-30 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475225766.25044.33.camel@mtksdaap41>
On 09/30/2016 10:56 AM, Horng-Shyang Liao wrote:
> On Fri, 2016-09-23 at 17:28 +0800, Horng-Shyang Liao wrote:
>> On Thu, 2016-09-22 at 13:22 +0530, Jassi Brar wrote:
>>> On Mon, Sep 5, 2016 at 7:14 AM, HS Liao <hs.liao@mediatek.com> wrote:
>>>> Use clk_disable_unprepare instead of clk_disable to save more energy
>>>> when CMDQ is idle.
>>>>
>>>> Signed-off-by: HS Liao <hs.liao@mediatek.com>
>>>> ---
>>>> drivers/mailbox/mtk-cmdq.c | 54 +++++++++++++++++++++++++++++++++++++++-------
>>>
>>> The driver is introduced by second patch of the set, so it makes sense
>>> to merge this patch into patch 2/4.
>>
>> Hi Jassi,
>>
>> Could you take a look at previous discussion between Matthias and me?
>> http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05239.html
>> His basic idea is to simplify first working version.
>> Therefore, I move some code to this patch.
>>
Well what I wanted to say is, that right now this driver is quite a big
beast and this makes it difficult to review. So my idea was to just
submit the most basic version of this driver.
Any improvements on the driver should be sent in follow-up patches after
the basic driver got merged. That was my idea.
Regards,
Matthias
^ permalink raw reply
* [PATCHv4 3/3] tty/serial: at91: fix hardware handshake on SAM9x5 (without GPIOs)
From: Richard Genoud @ 2016-09-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930085801.21497-1-richard.genoud@gmail.com>
Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
hardware handshake is enabled") broke the hardware handshake on SAM9x5
platforms.
On Atmel platforms, the USART can only handle the handware handshake
(ATMEL_US_USMODE_HWHS) if FIFOs or PDC are used.
Thus, ATMEL_US_USMODE_HWHS mode should only be used in this case.
For SAM9x5, there's no FIFOs nor PDC for the USART, so the mode should
be ATMEL_US_USMODE_NORMAL and the RTS pin should be controlled by the
driver.
NB: -stable is not Cced because it doesn't cleanly apply on 4.1+
Tested on SAM9G35-CM with and without DMA
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
---
drivers/tty/serial/atmel_serial.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index b01b68ece35c..4d033e6af44a 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2131,19 +2131,23 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
port->rs485.delay_rts_after_send);
mode |= ATMEL_US_USMODE_RS485;
} else if ((termios->c_cflag & CRTSCTS) &&
- !mctrl_gpio_use_rtscts(atmel_port->gpios)) {
+ !mctrl_gpio_use_rtscts(atmel_port->gpios) &&
+ (atmel_use_pdc_rx(port) || atmel_use_fifo(port))) {
/*
- * RS232 with hardware handshake (RTS/CTS)
- * handled by the controller.
+ * Automatic hardware handshake (RTS/CTS) only work with
+ * FIFOs or PDC.
+ * Meaning that on SAM9x5 the controller can't handle
+ * the hardware handshake (no FIFOs nor PDC on these platforms).
*/
- if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
- dev_info(port->dev, "not enabling hardware flow control because DMA is used");
- termios->c_cflag &= ~CRTSCTS;
- } else {
- mode |= ATMEL_US_USMODE_HWHS;
- }
+ mode |= ATMEL_US_USMODE_HWHS;
} else {
- /* RS232 without hardware handshake or controlled by GPIOs */
+ /*
+ * Other cases are:
+ * - RS232 without hardware handshake
+ * - RS232 with hardware handshake and:
+ * - controller unable to handle CTS/RTS by itself
+ * - or CTS/RTS handled by GPIOs
+ */
mode |= ATMEL_US_USMODE_NORMAL;
}
^ permalink raw reply related
* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Richard Genoud @ 2016-09-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930085801.21497-1-richard.genoud@gmail.com>
Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
hardware handshake is enabled") broke the hardware handshake when GPIOs
were used.
Hardware handshake with GPIOs used to work before this commit because
the CRTSCTS flag (termios->c_cflag) was set, but not the
ATMEL_US_USMODE_HWHS flag (controller register) ; so hardware handshake
enabled, but not handled by the controller.
This commit restores this behaviour.
NB: -stable is not Cced because it doesn't cleanly apply on 4.1+
and it will also need previous commit:
"serial: mctrl_gpio: implement mctrl_gpio_use_rtscts"
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
---
drivers/tty/serial/atmel_serial.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index fd8aa1f4ba78..b01b68ece35c 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2130,8 +2130,12 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
atmel_uart_writel(port, ATMEL_US_TTGR,
port->rs485.delay_rts_after_send);
mode |= ATMEL_US_USMODE_RS485;
- } else if (termios->c_cflag & CRTSCTS) {
- /* RS232 with hardware handshake (RTS/CTS) */
+ } else if ((termios->c_cflag & CRTSCTS) &&
+ !mctrl_gpio_use_rtscts(atmel_port->gpios)) {
+ /*
+ * RS232 with hardware handshake (RTS/CTS)
+ * handled by the controller.
+ */
if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
dev_info(port->dev, "not enabling hardware flow control because DMA is used");
termios->c_cflag &= ~CRTSCTS;
@@ -2139,7 +2143,7 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
mode |= ATMEL_US_USMODE_HWHS;
}
} else {
- /* RS232 without hadware handshake */
+ /* RS232 without hardware handshake or controlled by GPIOs */
mode |= ATMEL_US_USMODE_NORMAL;
}
^ permalink raw reply related
* [PATCHv4 1/3] serial: mctrl_gpio: implement mctrl_gpio_use_rtscts
From: Richard Genoud @ 2016-09-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930085801.21497-1-richard.genoud@gmail.com>
This function returns true if CTS and RTS are used as GPIOs.
Some drivers (like atmel_serial) needs to know if the flow control is
handled by the controller or by GPIOs.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
---
drivers/tty/serial/serial_mctrl_gpio.c | 7 +++++++
drivers/tty/serial/serial_mctrl_gpio.h | 10 ++++++++++
2 files changed, 17 insertions(+)
diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c
index d2da6aa7f27d..38e6e784faa2 100644
--- a/drivers/tty/serial/serial_mctrl_gpio.c
+++ b/drivers/tty/serial/serial_mctrl_gpio.c
@@ -72,6 +72,13 @@ struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
}
EXPORT_SYMBOL_GPL(mctrl_gpio_to_gpiod);
+bool mctrl_gpio_use_rtscts(struct mctrl_gpios *gpios)
+{
+ return mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS) &&
+ mctrl_gpio_to_gpiod(gpios, UART_GPIO_RTS);
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_use_rtscts);
+
unsigned int mctrl_gpio_get(struct mctrl_gpios *gpios, unsigned int *mctrl)
{
enum mctrl_gpio_idx i;
diff --git a/drivers/tty/serial/serial_mctrl_gpio.h b/drivers/tty/serial/serial_mctrl_gpio.h
index fa000bcff217..c34269733c62 100644
--- a/drivers/tty/serial/serial_mctrl_gpio.h
+++ b/drivers/tty/serial/serial_mctrl_gpio.h
@@ -101,6 +101,11 @@ void mctrl_gpio_enable_ms(struct mctrl_gpios *gpios);
*/
void mctrl_gpio_disable_ms(struct mctrl_gpios *gpios);
+/*
+ * Return true if both CTS and RTS are used with GPIOs
+ */
+bool mctrl_gpio_use_rtscts(struct mctrl_gpios *gpios);
+
#else /* GPIOLIB */
static inline
@@ -152,6 +157,11 @@ static inline void mctrl_gpio_disable_ms(struct mctrl_gpios *gpios)
{
}
+static inline bool mctrl_gpio_use_rtscts(struct mctrl_gpios *gpios)
+{
+ return false;
+}
+
#endif /* GPIOLIB */
#endif
^ permalink raw reply related
* [PATCHv4 0/3] Fix hardware handshake on SAM9x5 platforms
From: Richard Genoud @ 2016-09-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
Since commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
hardware handshake is enabled"), hardware handshake is not working
anymore on SAM9x5/SAMA5D3/SAM9 platforms.
The first two patches fix the hardware handshake when CTS/RTS pins are
handled by GPIOs.
The last patch fixes hardware handshake when CTS/RTS pins are not GPIOs.
Changes since v3:
- remove superfuous #include <linux/err.h> (thanks to Uwe)
- rebase on next-20160930
Changes since v2:
- remove IS_ERR_OR_NULL() test in patch 1/3 as Uwe suggested.
- fix typos in patch 2/3
- rebase on next-20160927
- simplify the logic in patch 3/3.
Changes since v1:
- Correct patch 1 with the error found by kbuild.
- Add Alexandre's Acked-by on patch 2
- Rewrite patch 3 logic in the light of the on-going discussion
with Cyrille and Alexandre.
NB: patch 2 NEEDS patch 1 to compile.
Richard Genoud (3):
serial: mctrl_gpio: implement mctrl_gpio_use_rtscts
tty/serial: at91: fix hardware handshake with GPIOs
tty/serial: at91: fix hardware handshake on SAM9x5 (without GPIOs)
drivers/tty/serial/atmel_serial.c | 26 +++++++++++++++++---------
drivers/tty/serial/serial_mctrl_gpio.c | 7 +++++++
drivers/tty/serial/serial_mctrl_gpio.h | 10 ++++++++++
3 files changed, 34 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: Horng-Shyang Liao @ 2016-09-30 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475204778.13398.28.camel@mtksdaap41>
Hi CK,
Please see my inline reply.
On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> Hi, HS:
>
> On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > CMDQ is used to help write registers with critical time limitation,
> > such as updating display configuration during the vblank. It controls
> > Global Command Engine (GCE) hardware to achieve this requirement.
> > Currently, CMDQ only supports display related hardwares, but we expect
> > it can be extended to other hardwares for future requirements.
> >
> > Signed-off-by: HS Liao <hs.liao@mediatek.com>
> > Signed-off-by: CK Hu <ck.hu@mediatek.com>
> > ---
>
> [snip...]
>
> > +
> > +struct cmdq_task {
> > + struct cmdq *cmdq;
> > + struct list_head list_entry;
> > + void *va_base;
> > + dma_addr_t pa_base;
> > + size_t cmd_buf_size; /* command occupied size */
> > + size_t buf_size; /* real buffer size */
> > + bool finalized;
> > + struct cmdq_thread *thread;
>
> I think thread info could be removed from cmdq_task. Only
> cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> task->thread and caller of both function has the thread info. So you
> could just pass thread info into these two function and remove thread
> info in cmdq_task.
This modification will remove 1 pointer but add 2 pointers. Moreover,
more pointers will need to be delivered between functions for future
extension. IMHO, it would be better to keep thread pointer inside
cmdq_task.
> > + struct cmdq_task_cb cb;
>
> I think this callback function is equal to mailbox client tx_done
> callback. It's better to use already-defined interface rather than
> creating your own.
This is because CMDQ driver allows different callback functions for
different tasks, but mailbox only allows one callback function per
channel. But, I think I can add a wrapper for tx_done to call CMDQ
callback functions. So, I will use tx_done in CMDQ v15.
> > +};
> > +
>
> [snip...]
>
> > +
> > +static int cmdq_suspend(struct device *dev)
> > +{
> > + struct cmdq *cmdq = dev_get_drvdata(dev);
> > + struct cmdq_thread *thread;
> > + int i;
> > + bool task_running = false;
> > +
> > + mutex_lock(&cmdq->task_mutex);
> > + cmdq->suspended = true;
> > + mutex_unlock(&cmdq->task_mutex);
> > +
> > + for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
> > + thread = &cmdq->thread[i];
> > + if (!list_empty(&thread->task_busy_list)) {
> > + mod_timer(&thread->timeout, jiffies + 1);
> > + task_running = true;
> > + }
> > + }
> > +
> > + if (task_running) {
> > + dev_warn(dev, "exist running task(s) in suspend\n");
> > + msleep(20);
>
> Why sleep here? It looks like a recovery but could 20ms recovery
> something? I think warning message is enough because you see the warning
> message, and you fix the bug, so no need to recovery anything.
My purpose is context switch to finish timer's work.
I will replace it by schedule().
> > + }
> > +
> > + clk_unprepare(cmdq->clock);
> > + return 0;
> > +}
> > +
>
> Regards,
> CK
Thanks,
HS
^ permalink raw reply
* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: Horng-Shyang Liao @ 2016-09-30 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474622898.21723.26.camel@mtksdaap41>
On Fri, 2016-09-23 at 17:28 +0800, Horng-Shyang Liao wrote:
> Hi Jassi,
>
> Please see my inline reply.
>
> On Thu, 2016-09-22 at 13:47 +0530, Jassi Brar wrote:
> > On Mon, Sep 5, 2016 at 7:14 AM, HS Liao <hs.liao@mediatek.com> wrote:
> [...]
> > > +struct cmdq_base *cmdq_register_device(struct device *dev)
> > > +{
> > > + struct cmdq_base *cmdq_base;
> > > + struct resource res;
> > > + int subsys;
> > > + u32 base;
> > > +
> > > + if (of_address_to_resource(dev->of_node, 0, &res))
> > > + return NULL;
> > > + base = (u32)res.start;
> > > +
> > > + subsys = cmdq_subsys_base_to_id(base >> 16);
> > > + if (subsys < 0)
> > > + return NULL;
> > > +
> > > + cmdq_base = devm_kmalloc(dev, sizeof(*cmdq_base), GFP_KERNEL);
> > > + if (!cmdq_base)
> > > + return NULL;
> > > + cmdq_base->subsys = subsys;
> > > + cmdq_base->base = base;
> > > +
> > > + return cmdq_base;
> > > +}
> > > +EXPORT_SYMBOL(cmdq_register_device);
> > > +
> > > +struct cmdq_client *cmdq_mbox_create(struct device *dev, int index)
> > > +{
> > > + struct cmdq_client *client;
> > > +
> > > + client = kzalloc(sizeof(*client), GFP_KERNEL);
> > > + client->client.dev = dev;
> > > + client->client.tx_block = false;
> > > + client->chan = mbox_request_channel(&client->client, index);
> > > + return client;
> > > +}
> > > +EXPORT_SYMBOL(cmdq_mbox_create);
> > > +
> > > +int cmdq_task_create(struct device *dev, struct cmdq_task **task_ptr)
> > > +{
> > > + struct cmdq_task *task;
> > > + int err;
> > > +
> > > + task = kzalloc(sizeof(*task), GFP_KERNEL);
> > > + if (!task)
> > > + return -ENOMEM;
> > > + task->cmdq = dev_get_drvdata(dev);
> > > + err = cmdq_task_realloc_cmd_buffer(task, PAGE_SIZE);
> > > + if (err < 0) {
> > > + kfree(task);
> > > + return err;
> > > + }
> > > + *task_ptr = task;
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_create);
> > > +
> > > +static int cmdq_task_append_command(struct cmdq_task *task, enum cmdq_code code,
> > > + u32 arg_a, u32 arg_b)
> > > +{
> > > + u64 *cmd_ptr;
> > > + int err;
> > > +
> > > + if (WARN_ON(task->finalized))
> > > + return -EBUSY;
> > > + if (unlikely(task->cmd_buf_size + CMDQ_INST_SIZE > task->buf_size)) {
> > > + err = cmdq_task_realloc_cmd_buffer(task, task->buf_size * 2);
> > > + if (err < 0)
> > > + return err;
> > > + }
> > > + cmd_ptr = task->va_base + task->cmd_buf_size;
> > > + (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> > > + task->cmd_buf_size += CMDQ_INST_SIZE;
> > > + return 0;
> > > +}
> > > +
> > > +int cmdq_task_write(struct cmdq_task *task, u32 value, struct cmdq_base *base,
> > > + u32 offset)
> > > +{
> > > + u32 arg_a = ((base->base + offset) & CMDQ_ARG_A_WRITE_MASK) |
> > > + (base->subsys << CMDQ_SUBSYS_SHIFT);
> > > + return cmdq_task_append_command(task, CMDQ_CODE_WRITE, arg_a, value);
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_write);
> > > +
> > > +int cmdq_task_write_mask(struct cmdq_task *task, u32 value,
> > > + struct cmdq_base *base, u32 offset, u32 mask)
> > > +{
> > > + u32 offset_mask = offset;
> > > + int err;
> > > +
> > > + if (mask != 0xffffffff) {
> > > + err = cmdq_task_append_command(task, CMDQ_CODE_MASK, 0, ~mask);
> > > + if (err < 0)
> > > + return err;
> > > + offset_mask |= CMDQ_WRITE_ENABLE_MASK;
> > > + }
> > > + return cmdq_task_write(task, value, base, offset_mask);
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_write_mask);
> > > +
> > > +static const u32 cmdq_event_value[CMDQ_MAX_EVENT] = {
> > > + /* Display start of frame(SOF) events */
> > > + [CMDQ_EVENT_DISP_OVL0_SOF] = 11,
> > > + [CMDQ_EVENT_DISP_OVL1_SOF] = 12,
> > > + [CMDQ_EVENT_DISP_RDMA0_SOF] = 13,
> > > + [CMDQ_EVENT_DISP_RDMA1_SOF] = 14,
> > > + [CMDQ_EVENT_DISP_RDMA2_SOF] = 15,
> > > + [CMDQ_EVENT_DISP_WDMA0_SOF] = 16,
> > > + [CMDQ_EVENT_DISP_WDMA1_SOF] = 17,
> > > + /* Display end of frame(EOF) events */
> > > + [CMDQ_EVENT_DISP_OVL0_EOF] = 39,
> > > + [CMDQ_EVENT_DISP_OVL1_EOF] = 40,
> > > + [CMDQ_EVENT_DISP_RDMA0_EOF] = 41,
> > > + [CMDQ_EVENT_DISP_RDMA1_EOF] = 42,
> > > + [CMDQ_EVENT_DISP_RDMA2_EOF] = 43,
> > > + [CMDQ_EVENT_DISP_WDMA0_EOF] = 44,
> > > + [CMDQ_EVENT_DISP_WDMA1_EOF] = 45,
> > > + /* Mutex end of frame(EOF) events */
> > > + [CMDQ_EVENT_MUTEX0_STREAM_EOF] = 53,
> > > + [CMDQ_EVENT_MUTEX1_STREAM_EOF] = 54,
> > > + [CMDQ_EVENT_MUTEX2_STREAM_EOF] = 55,
> > > + [CMDQ_EVENT_MUTEX3_STREAM_EOF] = 56,
> > > + [CMDQ_EVENT_MUTEX4_STREAM_EOF] = 57,
> > > + /* Display underrun events */
> > > + [CMDQ_EVENT_DISP_RDMA0_UNDERRUN] = 63,
> > > + [CMDQ_EVENT_DISP_RDMA1_UNDERRUN] = 64,
> > > + [CMDQ_EVENT_DISP_RDMA2_UNDERRUN] = 65,
> > > +};
> > > +
> > > +int cmdq_task_wfe(struct cmdq_task *task, enum cmdq_event event)
> > > +{
> > > + u32 arg_b;
> > > +
> > > + if (event >= CMDQ_MAX_EVENT || event < 0)
> > > + return -EINVAL;
> > > +
> > > + /*
> > > + * WFE arg_b
> > > + * bit 0-11: wait value
> > > + * bit 15: 1 - wait, 0 - no wait
> > > + * bit 16-27: update value
> > > + * bit 31: 1 - update, 0 - no update
> > > + */
> > > + arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
> > > + return cmdq_task_append_command(task, CMDQ_CODE_WFE,
> > > + cmdq_event_value[event], arg_b);
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_wfe);
> > > +
> > > +int cmdq_task_clear_event(struct cmdq_task *task, enum cmdq_event event)
> > > +{
> > > + if (event >= CMDQ_MAX_EVENT || event < 0)
> > > + return -EINVAL;
> > > +
> > > + return cmdq_task_append_command(task, CMDQ_CODE_WFE,
> > > + cmdq_event_value[event], CMDQ_WFE_UPDATE);
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_clear_event);
> > > +
> > > +static int cmdq_task_finalize(struct cmdq_task *task)
> > > +{
> > > + int err;
> > > +
> > > + if (task->finalized)
> > > + return 0;
> > > +
> > > + /* insert EOC and generate IRQ for each command iteration */
> > > + err = cmdq_task_append_command(task, CMDQ_CODE_EOC, 0, CMDQ_EOC_IRQ_EN);
> > > + if (err < 0)
> > > + return err;
> > > +
> > > + /* JUMP to end */
> > > + err = cmdq_task_append_command(task, CMDQ_CODE_JUMP, 0, CMDQ_JUMP_PASS);
> > > + if (err < 0)
> > > + return err;
> > > +
> > > + task->finalized = true;
> > > + return 0;
> > > +}
> > > +
> > > +int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task *task,
> > > + cmdq_async_flush_cb cb, void *data)
> > > +{
> > > + struct cmdq *cmdq = task->cmdq;
> > > + int err;
> > > +
> > > + mutex_lock(&cmdq->task_mutex);
> > > + if (cmdq->suspended) {
> > > + dev_err(cmdq->mbox.dev, "%s is called after suspended\n",
> > > + __func__);
> > > + mutex_unlock(&cmdq->task_mutex);
> > > + return -EPERM;
> > > + }
> > > +
> > > + err = cmdq_task_finalize(task);
> > > + if (err < 0) {
> > > + mutex_unlock(&cmdq->task_mutex);
> > > + return err;
> > > + }
> > > +
> > > + INIT_LIST_HEAD(&task->list_entry);
> > > + task->cb.cb = cb;
> > > + task->cb.data = data;
> > > + task->pa_base = dma_map_single(cmdq->mbox.dev, task->va_base,
> > > + task->cmd_buf_size, DMA_TO_DEVICE);
> > > +
> > > + mbox_send_message(client->chan, task);
> > > + /* We can send next task immediately, so just call txdone. */
> > > + mbox_client_txdone(client->chan, 0);
> > > + mutex_unlock(&cmdq->task_mutex);
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_flush_async);
> > > +
> > > +struct cmdq_flush_completion {
> > > + struct completion cmplt;
> > > + bool err;
> > > +};
> > > +
> > > +static void cmdq_task_flush_cb(struct cmdq_cb_data data)
> > > +{
> > > + struct cmdq_flush_completion *cmplt = data.data;
> > > +
> > > + cmplt->err = data.err;
> > > + complete(&cmplt->cmplt);
> > > +}
> > > +
> > > +int cmdq_task_flush(struct cmdq_client *client, struct cmdq_task *task)
> > > +{
> > > + struct cmdq_flush_completion cmplt;
> > > + int err;
> > > +
> > > + init_completion(&cmplt.cmplt);
> > > + err = cmdq_task_flush_async(client, task, cmdq_task_flush_cb, &cmplt);
> > > + if (err < 0)
> > > + return err;
> > > + wait_for_completion(&cmplt.cmplt);
> > > + return cmplt.err ? -EFAULT : 0;
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_flush);
> > > +
> > > +void cmdq_mbox_free(struct cmdq_client *client)
> > > +{
> > > + mbox_free_channel(client->chan);
> > > + kfree(client);
> > > +}
> > > +EXPORT_SYMBOL(cmdq_mbox_free);
> > > +
> > All these exported functions implement the protocol, so should not be
> > a part of this controller driver. That should go into
> > drivers/soc/mediatek/
> >
> > The controller driver (mtk-cmdq.c) should implement mainly the
> > mbox_chan_ops and mbox.of_xlate.
> >
>
> I can do that, but I would like to confirm with Matthias in advance.
>
> [...]
> > > + cmdq->irq = irq_of_parse_and_map(node, 0);
> > >
> > why not, cmdq->irq = platform_get_irq(pdev, 0);
>
> Will do
>
> [...]
> > > +static struct platform_driver cmdq_drv = {
> > > + .probe = cmdq_probe,
> > > + .remove = cmdq_remove,
> > > + .driver = {
> > > + .name = "mtk_cmdq",
> > > + .owner = THIS_MODULE,
> > >
> > please remove the unnecessary .owner field.
>
> Will do
>
> > > + .pm = &cmdq_pm_ops,
> > > + .of_match_table = cmdq_of_ids,
> > > + }
> > > +};
> > > +
> > > +builtin_platform_driver(cmdq_drv);
> > > diff --git a/include/linux/mailbox/mtk-cmdq.h b/include/linux/mailbox/mtk-cmdq.h
> > > new file mode 100644
> > > index 0000000..c3c924d
> > > --- /dev/null
> > > +++ b/include/linux/mailbox/mtk-cmdq.h
> > >
> > The api implemented is Mediateck proprietary, so I think it should be
> > include/linux/soc/mediatek/cmdq.h
> >
> >
> > > @@ -0,0 +1,180 @@
> > > +/*
> > > + * Copyright (c) 2015 MediaTek Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + */
> > > +
> > > +#ifndef __MTK_CMDQ_H__
> > > +#define __MTK_CMDQ_H__
> > > +
> > > +#include <linux/mailbox_client.h>
> > > +#include <linux/mailbox_controller.h>
> > >
> > Clients should not need to include mailbox_controller.h
>
> This is because client needs to know controller's dev.
>
> Please see my CMDQ v13.
> http://www.spinics.net/lists/kernel/msg2327867.html
> I add mailbox_controller.h for client to get controller's dev,
> so I can remove a node reference in device tree.
>
> Should I revert the modification of CMDQ v13?
Hi Jassi,
CMDQ clients don't need to know controller device before flush,
and CMDQ driver can get controller device by itself in flushing flow.
So, I think mailbox_controller.h can be removed from here,
and CMDQ v13 doesn't need to be reverted, either.
I will update this part in CMDQ v15.
Thanks,
HS
> > > +#include <linux/platform_device.h>
> > > +#include <linux/types.h>
> > > +
> > > +/* display events in command queue(CMDQ) */
> > > +enum cmdq_event {
> > > + /* Display start of frame(SOF) events */
> > > + CMDQ_EVENT_DISP_OVL0_SOF,
> > >
> > you may want to explicitly initialise the first element.
>
> Will do
>
> > > + CMDQ_EVENT_DISP_OVL1_SOF,
> > > + CMDQ_EVENT_DISP_RDMA0_SOF,
> > > + CMDQ_EVENT_DISP_RDMA1_SOF,
> > > + CMDQ_EVENT_DISP_RDMA2_SOF,
> > > + CMDQ_EVENT_DISP_WDMA0_SOF,
> > > + CMDQ_EVENT_DISP_WDMA1_SOF,
> > > + /* Display end of frame(EOF) events */
> > > + CMDQ_EVENT_DISP_OVL0_EOF,
> > > + CMDQ_EVENT_DISP_OVL1_EOF,
> > > + CMDQ_EVENT_DISP_RDMA0_EOF,
> > > + CMDQ_EVENT_DISP_RDMA1_EOF,
> > > + CMDQ_EVENT_DISP_RDMA2_EOF,
> > > + CMDQ_EVENT_DISP_WDMA0_EOF,
> > > + CMDQ_EVENT_DISP_WDMA1_EOF,
> > > + /* Mutex end of frame(EOF) events */
> > > + CMDQ_EVENT_MUTEX0_STREAM_EOF,
> > > + CMDQ_EVENT_MUTEX1_STREAM_EOF,
> > > + CMDQ_EVENT_MUTEX2_STREAM_EOF,
> > > + CMDQ_EVENT_MUTEX3_STREAM_EOF,
> > > + CMDQ_EVENT_MUTEX4_STREAM_EOF,
> > > + /* Display underrun events */
> > > + CMDQ_EVENT_DISP_RDMA0_UNDERRUN,
> > > + CMDQ_EVENT_DISP_RDMA1_UNDERRUN,
> > > + CMDQ_EVENT_DISP_RDMA2_UNDERRUN,
> > > + /* Keep this at the end */
> > > + CMDQ_MAX_EVENT,
> > > +};
> > > +
>
> Thanks,
> HS
>
>
> Hi Matthias,
>
> Do you agree with Jassi's comments about moving parts of code back to
> soc/mediatek/ ?
> If I do it, the part in soc/mediatek/ will be similar to a library.
> Could you tell me a good way to handle this situation?
>
> Thanks,
> HS
Hi Matthias,
Do you have any suggestion about moving parts of code back to
soc/mediatek/ ?
Thanks,
HS
^ permalink raw reply
* [PATCH v14 4/4] CMDQ: save more energy in idle
From: Horng-Shyang Liao @ 2016-09-30 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474622885.21723.25.camel@mtksdaap41>
On Fri, 2016-09-23 at 17:28 +0800, Horng-Shyang Liao wrote:
> On Thu, 2016-09-22 at 13:22 +0530, Jassi Brar wrote:
> > On Mon, Sep 5, 2016 at 7:14 AM, HS Liao <hs.liao@mediatek.com> wrote:
> > > Use clk_disable_unprepare instead of clk_disable to save more energy
> > > when CMDQ is idle.
> > >
> > > Signed-off-by: HS Liao <hs.liao@mediatek.com>
> > > ---
> > > drivers/mailbox/mtk-cmdq.c | 54 +++++++++++++++++++++++++++++++++++++++-------
> >
> > The driver is introduced by second patch of the set, so it makes sense
> > to merge this patch into patch 2/4.
>
> Hi Jassi,
>
> Could you take a look at previous discussion between Matthias and me?
> http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05239.html
> His basic idea is to simplify first working version.
> Therefore, I move some code to this patch.
>
> Thanks,
> HS
>
Hi Jassi,
What do you think about our previous discussion?
Thanks,
HS
^ permalink raw reply
* [PATCH 1/4] mfd: ti_am335x_tscadc: store physical address
From: Mugunthan V N @ 2016-09-30 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927194045.GK21388@dell>
On Wednesday 28 September 2016 01:10 AM, Lee Jones wrote:
> On Wed, 21 Sep 2016, Mugunthan V N wrote:
>
>> store the physical address of the device in its priv to use it
>> for DMA addressing in the client drivers.
>>
>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> ---
>> drivers/mfd/ti_am335x_tscadc.c | 1 +
>> include/linux/mfd/ti_am335x_tscadc.h | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
>> index c8f027b..0f3fab4 100644
>> --- a/drivers/mfd/ti_am335x_tscadc.c
>> +++ b/drivers/mfd/ti_am335x_tscadc.c
>> @@ -183,6 +183,7 @@ static int ti_tscadc_probe(struct platform_device *pdev)
>> tscadc->irq = err;
>>
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + tscadc->tscadc_phys_base = res->start;
>
> This is unusual. Can't you use a virt_to_phys() variant instead?
>
I tried using virt_to_phys(), but its not working for me.
Also saw many drivers uses like this to get physical address
("git grep -n " res->start;" drivers/*").
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: enable CONFIG_EFI
From: Jon Hunter @ 2016-09-30 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473949700-12814-1-git-send-email-ard.biesheuvel@linaro.org>
Hi Ard,
On 15/09/16 15:28, Ard Biesheuvel wrote:
> This enables CONFIG_EFI for multi_v7_defconfig, which adds support for
> booting via EFI, and for the EFI framebuffer as builtin options. It
> also enables the EFI rtc, the EFI variable pseudo-filesystem and the
> EFI capsule loader as modules.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> We have been happily booting multi_v7_defconfig+CONFIG_EFI=y kernels on
> kernelci for months now, so please consider enabling this by default.
> The increase in compressed kernel footprint is ~30 KB, for the uncompressed
> kernel it's ~10 KB, some of which is .init code.
After this patch was applied the Tegra automated building for
multi_v7_defconfig has been failing on -next [0]. The error I am seeing
is as follows ...
STUBCPY drivers/firmware/efi/libstub/lib-sort.stub.o
00000000 R_ARM_ABS32 sort
00000004 R_ARM_ABS32 __ksymtab_strings
drivers/firmware/efi/libstub/lib-sort.stub.o: absolute symbol references
not allowed in the EFI stub
make[4]: *** [drivers/firmware/efi/libstub/lib-sort.stub.o] Error 1
make[3]: *** [drivers/firmware/efi/libstub] Error 2
make[2]: *** [drivers/firmware/efi] Error 2
make[1]: *** [drivers/firmware] Error 2
make: *** [drivers] Error 2
The toolchain this builder uses (which is quite old admittedly) is ...
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
I am not seeing this error on other machines but for the life of me, I
cannot figure out why this one is failing. Any thoughts?
Cheers
Jon
[0] http://nvtb.github.io/linux-next/
--
nvpublic
^ 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