* [PATCH v4 2/4] MAINTAINERS: add new entries for Armada 37xx cpufreq driver
From: Gregory CLEMENT @ 2017-12-14 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214150006.25438-1-gregory.clement@free-electrons.com>
This new driver belongs to the mvebu family, update the MAINTAINER file
to document it.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..98dcee849481 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1582,6 +1582,7 @@ F: arch/arm/boot/dts/kirkwood*
F: arch/arm/configs/mvebu_*_defconfig
F: arch/arm/mach-mvebu/
F: arch/arm64/boot/dts/marvell/armada*
+F: drivers/cpufreq/armada-37xx-cpufreq.c
F: drivers/cpufreq/mvebu-cpufreq.c
F: drivers/irqchip/irq-armada-370-xp.c
F: drivers/irqchip/irq-mvebu-*
--
2.15.1
^ permalink raw reply related
* [PATCH v4 1/4] dt-bindings: marvell: Add documentation for the North Bridge PM on Armada 37xx
From: Gregory CLEMENT @ 2017-12-14 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214150006.25438-1-gregory.clement@free-electrons.com>
Extend the documentation of the Armada 37xx SoC with the the North
Bridge Power Management component.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../devicetree/bindings/arm/marvell/armada-37xx.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
index 51336e5fc761..35c3c3460d17 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
@@ -14,3 +14,22 @@ following property before the previous one:
Example:
compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
+
+
+Power management
+----------------
+
+For power management (particularly DVFS and AVS), the North Bridge
+Power Management component is needed:
+
+Required properties:
+- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
+- reg : the register start and length for the North Bridge
+ Power Management
+
+Example:
+
+nb_pm: syscon at 14000 {
+ compatible = "marvell,armada-3700-nb-pm", "syscon";
+ reg = <0x14000 0x60>;
+}
--
2.15.1
^ permalink raw reply related
* [PATCH v4 0/4] Add CPU Frequency scaling support on Armada 37xx
From: Gregory CLEMENT @ 2017-12-14 15:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is the forth version of a series adding the CPU Frequency support
on Armada 37xx using DVFS. It is based on the initial work of Evan
Wang and Victor Gu.
This time the only change is fixing the last white space issues found
by Viresh. This was not mandatory but it is good to start with a clean
new file.
The last patch is for arm-soc the arm-soc subsystem through mvebu and
update the device tree to support the CPU frequency scaling.
An update on the CPU clock driver is needed in order to take into
account the DVFS setting. It's the purpose of an other series already
sent, but is no dependencies between the series (for building or at
runtime).
Thanks,
Gregory
Changelog:
v1 -> v2:
- using syscon instead of nb_pm for the binding of the North bridge
power management unit: reported by Rob Herring
- fix sorting inside the big LITTLE section for the Kconfig: reported
by Viresh Kumar
- fix the bogus freq calculation in armada37xx_cpufreq_driver_init,
bug reported by Andre Heider
- use dev_pm_opp_remove() on the previous opp if dev_pm_opp_add()
failed, reported by Viresh Kumar
- add the Tested-by flag from Andre Heider on "cpufreq: Add DVFS
support for Armada 37xx" patch
v2 -> v3:
- move patches "cpufreq: ARM: sort the Kconfig menu", " cpufreq:
sort the drivers in ARM part", "cpufreq: mvebu: Use
dev_pm_opp_remove()" in separate series
- add reviewed-by and acked-by flags on the commits
- use space instead of tab in the #define in the armada-37xx-cpufreq.c file.
v3 -> v4
- fix white space in the armada-37xx-cpufreq.c file.
Gregory CLEMENT (4):
dt-bindings: marvell: Add documentation for the North Bridge PM on
Armada 37xx
MAINTAINERS: add new entries for Armada 37xx cpufreq driver
cpufreq: Add DVFS support for Armada 37xx
arm64: dts: marvell: armada-37xx: add nodes allowing cpufreq support
.../bindings/arm/marvell/armada-37xx.txt | 19 ++
MAINTAINERS | 1 +
arch/arm64/boot/dts/marvell/armada-372x.dtsi | 1 +
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +
drivers/cpufreq/Kconfig.arm | 7 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/armada-37xx-cpufreq.c | 241 +++++++++++++++++++++
7 files changed, 277 insertions(+)
create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
--
2.15.1
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add ethernet mac controller
From: Jerome Brunet @ 2017-12-14 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214030242.113152-1-yixun.lan@amlogic.com>
On Thu, 2017-12-14 at 11:02 +0800, Yixun Lan wrote:
> Add DT info for the stmmac ethernet MAC which found in
> the Amlogic's Meson-AXG SoC, also describe the ethernet
> pinctrl & clock information here.
>
> This is tested in the S400 dev board which use a RTL8211F PHY,
> and the pins connect to the 'eth_rgmii_y_pins' group.
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
I think it would have been better to split this into 2 patches.
One adding the controller for axg, the other using it in the s400, but maybe
Kevin is OK with it...
>
> ---
> Changes in v2 since [1]:
> - rebase to kevin's v4.16/dt64 branch
> - add Neil's Reviewed-by
> - move clock info to board.dts instead of in soc.dtsi
> - drop "meson-axg-dwmac" compatible string, since we didn't use this
> we could re-add it later when we really need.
> - note: to make ethernet work properly,it depend on clock & pinctrl[2],
> to compile the DTS, the patch [3] is required.
> the code part will be taken via clock & pinctrl subsystem tree.
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005301.html
>
> [2]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005735.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005694.html
>
> [3]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005738.html
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 11 ++++++
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 50 ++++++++++++++++++++++++++
> 2 files changed, 61 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 70eca1f8736a..138de3bc7cc8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -20,3 +20,14 @@
> &uart_AO {
> status = "okay";
> };
> +
> +ðmac {
We try to keep nodes alphabetically ordered.
Please put ethmac before uart_A0
thx
>
>
With all the dependencies sorted out, it works
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
^ permalink raw reply
* [2/2] ARM: davinci: remove watchdog reset
From: Guenter Roeck @ 2017-12-14 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513012869-7647-3-git-send-email-david@lechnology.com>
On Mon, Dec 11, 2017 at 11:21:09AM -0600, David Lechner wrote:
> This removes the watchdog reset code. The reset has been moved to
> drivers/watchdog/davinci_wdt.c. The watchdog driver registers the reset
> with the kernel so defining a reset for each machine is no longer needed.
>
> Signed-off-by: David Lechner <david@lechnology.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
> ---
> arch/arm/mach-davinci/board-da830-evm.c | 1 -
> arch/arm/mach-davinci/board-da850-evm.c | 1 -
> arch/arm/mach-davinci/board-dm355-evm.c | 1 -
> arch/arm/mach-davinci/board-dm355-leopard.c | 1 -
> arch/arm/mach-davinci/board-dm365-evm.c | 1 -
> arch/arm/mach-davinci/board-dm644x-evm.c | 1 -
> arch/arm/mach-davinci/board-dm646x-evm.c | 2 -
> arch/arm/mach-davinci/board-mityomapl138.c | 1 -
> arch/arm/mach-davinci/board-neuros-osd2.c | 1 -
> arch/arm/mach-davinci/board-omapl138-hawk.c | 1 -
> arch/arm/mach-davinci/board-sffsdr.c | 1 -
> arch/arm/mach-davinci/clock.h | 3 --
> arch/arm/mach-davinci/da8xx-dt.c | 1 -
> arch/arm/mach-davinci/devices-da8xx.c | 13 -------
> arch/arm/mach-davinci/devices.c | 7 +---
> arch/arm/mach-davinci/include/mach/common.h | 1 -
> arch/arm/mach-davinci/include/mach/da8xx.h | 1 -
> arch/arm/mach-davinci/time.c | 57 -----------------------------
> 18 files changed, 1 insertion(+), 94 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
> index 2cc5426..7adf009 100644
> --- a/arch/arm/mach-davinci/board-da830-evm.c
> +++ b/arch/arm/mach-davinci/board-da830-evm.c
> @@ -642,5 +642,4 @@ MACHINE_START(DAVINCI_DA830_EVM, "DaVinci DA830/OMAP-L137/AM17x EVM")
> .init_machine = da830_evm_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = da8xx_restart,
> MACHINE_END
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 458f26d..8602d0d 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1485,6 +1485,5 @@ MACHINE_START(DAVINCI_DA850_EVM, "DaVinci DA850/OMAP-L138/AM18x EVM")
> .init_machine = da850_evm_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = da8xx_restart,
> .reserve = da8xx_rproc_reserve_cma,
> MACHINE_END
> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
> index 2b4d553..3c15cb7 100644
> --- a/arch/arm/mach-davinci/board-dm355-evm.c
> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
> @@ -420,5 +420,4 @@ MACHINE_START(DAVINCI_DM355_EVM, "DaVinci DM355 EVM")
> .init_machine = dm355_evm_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = davinci_restart,
> MACHINE_END
> diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c
> index 69399d7..3ebc89d 100644
> --- a/arch/arm/mach-davinci/board-dm355-leopard.c
> +++ b/arch/arm/mach-davinci/board-dm355-leopard.c
> @@ -275,5 +275,4 @@ MACHINE_START(DM355_LEOPARD, "DaVinci DM355 leopard")
> .init_machine = dm355_leopard_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = davinci_restart,
> MACHINE_END
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index e414cb9..3daeac7 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -778,6 +778,5 @@ MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM")
> .init_machine = dm365_evm_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = davinci_restart,
> MACHINE_END
>
> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
> index 6b26786..8d8c4ab 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> @@ -821,5 +821,4 @@ MACHINE_START(DAVINCI_EVM, "DaVinci DM644x EVM")
> .init_machine = davinci_evm_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = davinci_restart,
> MACHINE_END
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
> index b3b81a8..dafc852 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -804,7 +804,6 @@ MACHINE_START(DAVINCI_DM6467_EVM, "DaVinci DM646x EVM")
> .init_machine = evm_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = davinci_restart,
> MACHINE_END
>
> MACHINE_START(DAVINCI_DM6467TEVM, "DaVinci DM6467T EVM")
> @@ -815,6 +814,5 @@ MACHINE_START(DAVINCI_DM6467TEVM, "DaVinci DM6467T EVM")
> .init_machine = evm_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = davinci_restart,
> MACHINE_END
>
> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> index c930c31..f9a725a 100644
> --- a/arch/arm/mach-davinci/board-mityomapl138.c
> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
> @@ -574,5 +574,4 @@ MACHINE_START(MITYOMAPL138, "MityDSP-L138/MityARM-1808")
> .init_machine = mityomapl138_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = da8xx_restart,
> MACHINE_END
> diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
> index 925ada1..ff871a0 100644
> --- a/arch/arm/mach-davinci/board-neuros-osd2.c
> +++ b/arch/arm/mach-davinci/board-neuros-osd2.c
> @@ -231,5 +231,4 @@ MACHINE_START(NEUROS_OSD2, "Neuros OSD2")
> .init_machine = davinci_ntosd2_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = davinci_restart,
> MACHINE_END
> diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
> index c1277b3..bc8a747 100644
> --- a/arch/arm/mach-davinci/board-omapl138-hawk.c
> +++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
> @@ -338,6 +338,5 @@ MACHINE_START(OMAPL138_HAWKBOARD, "AM18x/OMAP-L138 Hawkboard")
> .init_machine = omapl138_hawk_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = da8xx_restart,
> .reserve = da8xx_rproc_reserve_cma,
> MACHINE_END
> diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
> index 4038de8..2922da9 100644
> --- a/arch/arm/mach-davinci/board-sffsdr.c
> +++ b/arch/arm/mach-davinci/board-sffsdr.c
> @@ -154,5 +154,4 @@ MACHINE_START(SFFSDR, "Lyrtech SFFSDR")
> .init_machine = davinci_sffsdr_init,
> .init_late = davinci_init_late,
> .dma_zone_size = SZ_128M,
> - .restart = davinci_restart,
> MACHINE_END
> diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
> index aea4f14..a0b559e 100644
> --- a/arch/arm/mach-davinci/clock.h
> +++ b/arch/arm/mach-davinci/clock.h
> @@ -131,9 +131,6 @@ void davinci_clk_enable(struct davinci_clk *clk);
> void davinci_clk_disable(struct davinci_clk *clk);
> int davinci_clk_register(struct davinci_clk *clk);
>
> -extern struct platform_device davinci_wdt_device;
> -extern void davinci_watchdog_reset(struct platform_device *);
> -
> static inline struct davinci_clk *to_davinci_clk(struct clk_hw *hw)
> {
> if (IS_ERR_OR_NULL(hw))
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index 3630f0a..ab199f4 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -100,7 +100,6 @@ DT_MACHINE_START(DA850_DT, "Generic DA850/OMAP-L138/AM18x")
> .init_machine = da850_init_machine,
> .dt_compat = da850_boards_compat,
> .init_late = davinci_init_late,
> - .restart = da8xx_restart,
> MACHINE_END
>
> #endif
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index 6724a8d..272e12e 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -371,19 +371,6 @@ static struct platform_device da8xx_wdt_device = {
> .resource = da8xx_watchdog_resources,
> };
>
> -void da8xx_restart(enum reboot_mode mode, const char *cmd)
> -{
> - struct device *dev;
> -
> - dev = bus_find_device_by_name(&platform_bus_type, NULL, "davinci-wdt");
> - if (!dev) {
> - pr_err("%s: failed to find watchdog device\n", __func__);
> - return;
> - }
> -
> - davinci_watchdog_reset(to_platform_device(dev));
> -}
> -
> int __init da8xx_register_watchdog(void)
> {
> return platform_device_register(&da8xx_wdt_device);
> diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
> index 3ae70f2..0edda40 100644
> --- a/arch/arm/mach-davinci/devices.c
> +++ b/arch/arm/mach-davinci/devices.c
> @@ -282,18 +282,13 @@ static struct resource wdt_resources[] = {
> },
> };
>
> -struct platform_device davinci_wdt_device = {
> +static struct platform_device davinci_wdt_device = {
> .name = "davinci-wdt",
> .id = -1,
> .num_resources = ARRAY_SIZE(wdt_resources),
> .resource = wdt_resources,
> };
>
> -void davinci_restart(enum reboot_mode mode, const char *cmd)
> -{
> - davinci_watchdog_reset(&davinci_wdt_device);
> -}
> -
> int davinci_init_wdt(void)
> {
> return platform_device_register(&davinci_wdt_device);
> diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
> index 69a0ad9..f0d5e858 100644
> --- a/arch/arm/mach-davinci/include/mach/common.h
> +++ b/arch/arm/mach-davinci/include/mach/common.h
> @@ -80,7 +80,6 @@ extern struct davinci_soc_info davinci_soc_info;
>
> extern void davinci_common_init(const struct davinci_soc_info *soc_info);
> extern void davinci_init_ide(void);
> -void davinci_restart(enum reboot_mode mode, const char *cmd);
> void davinci_init_late(void);
>
> #ifdef CONFIG_DAVINCI_RESET_CLOCKS
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index dd12e39..3481a0d 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -121,7 +121,6 @@ int da850_register_vpif_display
> (struct vpif_display_config *display_config);
> int da850_register_vpif_capture
> (struct vpif_capture_config *capture_config);
> -void da8xx_restart(enum reboot_mode mode, const char *cmd);
> void da8xx_rproc_reserve_cma(void);
> int da8xx_register_rproc(void);
> int da850_register_gpio(void);
> diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
> index 034f865..1bb991a 100644
> --- a/arch/arm/mach-davinci/time.c
> +++ b/arch/arm/mach-davinci/time.c
> @@ -80,13 +80,6 @@ enum {
> #define TGCR_UNRESET 0x1
> #define TGCR_RESET_MASK 0x3
>
> -#define WDTCR_WDEN_SHIFT 14
> -#define WDTCR_WDEN_DISABLE 0x0
> -#define WDTCR_WDEN_ENABLE 0x1
> -#define WDTCR_WDKEY_SHIFT 16
> -#define WDTCR_WDKEY_SEQ0 0xa5c6
> -#define WDTCR_WDKEY_SEQ1 0xda7e
> -
> struct timer_s {
> char *name;
> unsigned int id;
> @@ -409,53 +402,3 @@ void __init davinci_timer_init(void)
> for (i=0; i< ARRAY_SIZE(timers); i++)
> timer32_config(&timers[i]);
> }
> -
> -/* reset board using watchdog timer */
> -void davinci_watchdog_reset(struct platform_device *pdev)
> -{
> - u32 tgcr, wdtcr;
> - void __iomem *base;
> - struct clk *wd_clk;
> -
> - base = ioremap(pdev->resource[0].start, SZ_4K);
> - if (WARN_ON(!base))
> - return;
> -
> - wd_clk = clk_get(&pdev->dev, NULL);
> - if (WARN_ON(IS_ERR(wd_clk)))
> - return;
> - clk_prepare_enable(wd_clk);
> -
> - /* disable, internal clock source */
> - __raw_writel(0, base + TCR);
> -
> - /* reset timer, set mode to 64-bit watchdog, and unreset */
> - tgcr = 0;
> - __raw_writel(tgcr, base + TGCR);
> - tgcr = TGCR_TIMMODE_64BIT_WDOG << TGCR_TIMMODE_SHIFT;
> - tgcr |= (TGCR_UNRESET << TGCR_TIM12RS_SHIFT) |
> - (TGCR_UNRESET << TGCR_TIM34RS_SHIFT);
> - __raw_writel(tgcr, base + TGCR);
> -
> - /* clear counter and period regs */
> - __raw_writel(0, base + TIM12);
> - __raw_writel(0, base + TIM34);
> - __raw_writel(0, base + PRD12);
> - __raw_writel(0, base + PRD34);
> -
> - /* put watchdog in pre-active state */
> - wdtcr = __raw_readl(base + WDTCR);
> - wdtcr = (WDTCR_WDKEY_SEQ0 << WDTCR_WDKEY_SHIFT) |
> - (WDTCR_WDEN_ENABLE << WDTCR_WDEN_SHIFT);
> - __raw_writel(wdtcr, base + WDTCR);
> -
> - /* put watchdog in active state */
> - wdtcr = (WDTCR_WDKEY_SEQ1 << WDTCR_WDKEY_SHIFT) |
> - (WDTCR_WDEN_ENABLE << WDTCR_WDEN_SHIFT);
> - __raw_writel(wdtcr, base + WDTCR);
> -
> - /* write an invalid value to the WDKEY field to trigger
> - * a watchdog reset */
> - wdtcr = 0x00004000;
> - __raw_writel(wdtcr, base + WDTCR);
> -}
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Geert Uytterhoeven @ 2017-12-14 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXh_6FaV-SFGWxcBb1-NNGYngDrYnnWA=9Y6xmRAkcxqg@mail.gmail.com>
Hi Catalin, Will, Dave,
On Tue, Dec 12, 2017 at 11:20 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> During userspace (Debian jessie NFS root) boot on arm64:
>
> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x00000008,
> esr 0x92000004, in dash[aaaaadf77000+1a000]
> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
This is a quad Cortex A57.
> pstate: 80000000 (Nzcv daif -PAN -UAO)
> pc : 0xaaaaadf8a51c
> lr : 0xaaaaadf8ac08
> sp : 0000ffffcffeac00
> x29: 0000ffffcffeac00 x28: 0000aaaaadfa1000
> x27: 0000ffffcffebf7c x26: 0000ffffcffead20
> x25: 0000aaaacea1c5f0 x24: 0000000000000000
> x23: 0000aaaaadfa1000 x22: 0000aaaaadfa1000
> x21: 0000000000000000 x20: 0000000000000008
> x19: 0000000000000000 x18: 0000ffffcffeb500
> x17: 0000ffffa22babfc x16: 0000aaaaadfa1ae8
> x15: 0000ffffa2363588 x14: ffffffffffffffff
> x13: 0000000000000020 x12: 0000000000000010
> x11: 0101010101010101 x10: 0000aaaaadfa1000
> x9 : 00000000ffffff81 x8 : 0000aaaaadfa2000
> x7 : 0000000000000000 x6 : 0000000000000000
> x5 : 0000aaaaadfa2338 x4 : 0000aaaaadfa2000
> x3 : 0000aaaaadfa2338 x2 : 0000000000000000
> x1 : 0000aaaaadfa28b0 x0 : 0000aaaaadfa4c30
>
> Sometimes it happens with other processes, but the main address, esr, and
> pstate values are always the same.
>
> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
> releases, so the last time was two weeks ago), but never saw the issue
> before until today, so probably v4.15-rc1 is OK.
> Unfortunately it doesn't happen during every boot, which makes it
> cumbersome to bisect.
>
> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
> and even without today's arm64/for-next/core merged in, I still managed to
> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
> v4.15-rc3.
>
> Once, when the kernel message above wasn't shown, I got an error from
> userspace, which may be related:
> *** Error in `/bin/sh': free(): invalid pointer: 0x0000aaaadd970988 ***
With more boots (10 instead of 6) to declare a kernel good, I bisected this
to commit 9de52a755cfb6da5 ("arm64: fpsimd: Fix failure to restore FPSIMD
state after signals").
Reverting that commit on top of v4.15-rc3 fixed the issue for me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [RFC PATCH 7/7] ARM: dts: at91-sama5d2_xplained: remove gpios from pinmux
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
As we can setup the pin configuration of a GPIO through the gpiolib,
enable the pinmuxing strict mode and remove GPIOs from the pinmuxing.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 45 +++++------------------------
1 file changed, 7 insertions(+), 38 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 56de21de2779..9e0bf162e6bd 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -68,20 +68,16 @@
ahb {
usb0: gadget at 300000 {
- atmel,vbus-gpio = <&pioA PIN_PA31 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioA PIN_PA31 (GPIO_ACTIVE_LOW | GPIO_BIAS_PULL_UP)>;
status = "okay";
};
usb1: ohci at 400000 {
num-ports = <3>;
atmel,vbus-gpio = <0 /* &pioA PIN_PB9 GPIO_ACTIVE_HIGH */
- &pioA PIN_PB10 GPIO_ACTIVE_HIGH
+ &pioA PIN_PB10 (GPIO_ACTIVE_LOW | GPIO_BIAS_PULL_UP)
0
>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usb_default>;
status = "okay";
};
@@ -325,6 +321,7 @@
};
pinctrl at fc038000 {
+ atmel,use-strict-mode;
/*
* There is no real pinmux for ADC, if the pin
* is not requested by another peripheral then
@@ -412,18 +409,6 @@
bias-disable;
};
- pinctrl_key_gpio_default: key_gpio_default {
- pinmux = <PIN_PB9__GPIO>;
- bias-pull-up;
- };
-
- pinctrl_led_gpio_default: led_gpio_default {
- pinmux = <PIN_PB0__GPIO>,
- <PIN_PB5__GPIO>,
- <PIN_PB6__GPIO>;
- bias-pull-up;
- };
-
pinctrl_macb0_default: macb0_default {
pinmux = <PIN_PB14__GTXCK>,
<PIN_PB15__GTXEN>,
@@ -509,16 +494,6 @@
bias-disable;
};
- pinctrl_usb_default: usb_default {
- pinmux = <PIN_PB10__GPIO>;
- bias-disable;
- };
-
- pinctrl_usba_vbus: usba_vbus {
- pinmux = <PIN_PA31__GPIO>;
- bias-disable;
- };
-
pinctrl_pwm0_pwm2_default: pwm0_pwm2_default {
pinmux = <PIN_PB5__PWMH2>,
<PIN_PB6__PWML2>;
@@ -544,13 +519,9 @@
gpio_keys {
compatible = "gpio-keys";
-
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_key_gpio_default>;
-
bp1 {
label = "PB_USER";
- gpios = <&pioA PIN_PB9 GPIO_ACTIVE_LOW>;
+ gpios = <&pioA PIN_PB9 (GPIO_ACTIVE_LOW | GPIO_BIAS_PULL_UP)>;
linux,code = <0x104>;
wakeup-source;
};
@@ -558,24 +529,22 @@
leds {
compatible = "gpio-leds";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_led_gpio_default>;
status = "okay"; /* conflict with pwm0 */
red {
label = "red";
- gpios = <&pioA PIN_PB6 GPIO_ACTIVE_LOW>;
+ gpios = <&pioA PIN_PB6 (GPIO_ACTIVE_LOW | GPIO_BIAS_PULL_UP)>;
};
green {
label = "green";
- gpios = <&pioA PIN_PB5 GPIO_ACTIVE_LOW>;
+ gpios = <&pioA PIN_PB5 (GPIO_ACTIVE_LOW | GPIO_BIAS_PULL_UP)>;
};
blue {
label = "blue";
- gpios = <&pioA PIN_PB0 GPIO_ACTIVE_LOW>;
+ gpios = <&pioA PIN_PB0 (GPIO_ACTIVE_LOW | GPIO_BIAS_PULL_UP)>;
linux,default-trigger = "heartbeat";
};
};
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 6/7] pinctrl: at91-pio4: use strict mode if explicitly requested
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
Add a property to use pinmux strict mode. It corresponds to the
legacy behavior of the controller. It was not used because there
were no solution to configure (open drain, bias, etc) a pin
requested as a GPIO.
If the strict mode is used by default, it will break several boards.
The owner of a GPIO requested by a device is not the device itself
but the pinctrl. So there is an ownership mismatch since the owner
of the pinmuxing is the device which requested it. It will lead to
an error when requesting the GPIO.
By adding a DT property, we can enable it only for DTs which are
written correctly.
The gpio_request_enable operation is needed to mux the pin as a
GPIO but it has to be used only if strict mode is enabled. If not,
a pin muxed to a device may be muxed to a GPIO silently.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
.../bindings/pinctrl/atmel,at91-pio4-pinctrl.txt | 4 ++++
drivers/pinctrl/pinctrl-at91-pio4.c | 24 +++++++++++++++++++++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
index 61ac75706cc9..440cb5687b4e 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
@@ -11,6 +11,10 @@ Required properties:
- #interrupt-cells: should be two.
- gpio-controller: mark the device node as a gpio controller.
- #gpio-cells: should be two.
+Optional properties:
+- atmel,use-strict-mode: enable the pinmux strict mode which prevents
+simultaneous use of the same pin for GPIO and another function. It implies to
+not put a pin requested as a GPIO in the pinmux property.
Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
a general description of GPIO and interrupt bindings.
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
index 4b8dda770af8..6acbbcc9b4a6 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -358,6 +358,8 @@ static int atmel_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
}
static struct gpio_chip atmel_gpio_chip = {
+ .request = gpiochip_generic_request,
+ .free = gpiochip_generic_free,
.direction_input = atmel_gpio_direction_input,
.get = atmel_gpio_get,
.direction_output = atmel_gpio_direction_output,
@@ -644,7 +646,22 @@ static int atmel_pmx_set_mux(struct pinctrl_dev *pctldev,
return 0;
}
-static const struct pinmux_ops atmel_pmxops = {
+static int atmel_pmx_gpio_request_enable(struct pinctrl_dev *pctldev,
+ struct pinctrl_gpio_range *range,
+ unsigned offset)
+{
+ u32 conf;
+
+ conf = atmel_pin_config_read(pctldev, offset);
+ conf &= (~ATMEL_PIO_CFGR_FUNC_MASK);
+ atmel_pin_config_write(pctldev, offset, conf);
+
+ dev_dbg(pctldev->dev, "enable pin %u as GPIO\n", offset);
+
+ return 0;
+}
+
+static struct pinmux_ops atmel_pmxops = {
.get_functions_count = atmel_pmx_get_functions_count,
.get_function_name = atmel_pmx_get_function_name,
.get_function_groups = atmel_pmx_get_function_groups,
@@ -930,6 +947,11 @@ static int atmel_pinctrl_probe(struct platform_device *pdev)
atmel_pioctrl->nbanks = atmel_pioctrl_data->nbanks;
atmel_pioctrl->npins = atmel_pioctrl->nbanks * ATMEL_PIO_NPINS_PER_BANK;
+ if (of_property_read_bool(dev->of_node, "atmel,use-strict-mode")) {
+ atmel_pmxops.strict = true;
+ atmel_pmxops.gpio_request_enable = atmel_pmx_gpio_request_enable;
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "unable to get atmel pinctrl resource\n");
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 5/7] pinctrl: at91-pio4: allow the gpiolib to set pin configuration
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
Use gpiochip_generic_config to allow the gpiolib to set pin
configuration. Since it relies on .pin_config_set(), add it too.
For this controller, one pin is on group so we can use
atmel_conf_pin_config_group_set() function.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
drivers/pinctrl/pinctrl-at91-pio4.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
index b1ca838dd80a..4b8dda770af8 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -364,6 +364,7 @@ static struct gpio_chip atmel_gpio_chip = {
.set = atmel_gpio_set,
.to_irq = atmel_gpio_to_irq,
.base = 0,
+ .set_config = gpiochip_generic_config,
};
/* --- PINCTRL --- */
@@ -817,6 +818,7 @@ static void atmel_conf_pin_config_dbg_show(struct pinctrl_dev *pctldev,
}
static const struct pinconf_ops atmel_confops = {
+ .pin_config_set = atmel_conf_pin_config_group_set, /* In our case, a pin = a group */
.pin_config_group_get = atmel_conf_pin_config_group_get,
.pin_config_group_set = atmel_conf_pin_config_group_set,
.pin_config_dbg_show = atmel_conf_pin_config_dbg_show,
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 4/7] gpio: gpiolib: add bias support
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
If we want to setup the bias of a pin used as a GPIO, we have,
at least for some pin controllers, to declare it in the pinmuxing
in order to apply the configuration wanted.
If the pinmuxing strict mode is enabled, there is a conflict when
the device driver requests the GPIO. It is due to an ownership
mismatch. The device driver has requested the pin through the
pinctrl so the owner is the device. When the GPIO is requested,
there is a conflict because the owner of the GPIO is the pin
controller not the requester.
This patch provides a way to add the bias configuration to the
flags of a GPIO.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
drivers/gpio/gpiolib-of.c | 9 +++++++++
drivers/gpio/gpiolib.c | 34 ++++++++++++++++++++++++++++------
drivers/gpio/gpiolib.h | 3 +++
include/dt-bindings/gpio/gpio.h | 9 +++++++++
include/linux/gpio/machine.h | 3 +++
include/linux/of_gpio.h | 3 +++
6 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 67b1a7ff1e97..9c6da8c2e97c 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -158,6 +158,15 @@ struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
if (of_flags & OF_GPIO_TRANSITORY)
*flags |= GPIO_TRANSITORY;
+ if (of_flags & OF_GPIO_BIAS_PULL_UP)
+ *flags |= GPIO_BIAS_PULL_UP;
+
+ if (of_flags & OF_GPIO_BIAS_PULL_DOWN)
+ *flags |= GPIO_BIAS_PULL_DOWN;
+
+ if (of_flags & OF_GPIO_BIAS_DISABLE)
+ *flags |= GPIO_BIAS_DISABLE;
+
return desc;
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index c887602ca0ff..2caec626dcd5 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2133,7 +2133,7 @@ static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
{
struct gpio_chip *chip = desc->gdev->chip;
int status;
- unsigned long flags;
+ unsigned long flags, config = 0;
spin_lock_irqsave(&gpio_lock, flags);
@@ -2161,6 +2161,16 @@ static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
goto done;
}
}
+ if (chip->set_config) {
+ /* The following flags are exclusive. */
+ if (test_bit(FLAG_BIAS_PULL_UP, &desc->flags))
+ config |= pinconf_to_config_packed(PIN_CONFIG_BIAS_PULL_UP, 1);
+ else if (test_bit(FLAG_BIAS_PULL_DOWN, &desc->flags))
+ config |= pinconf_to_config_packed(PIN_CONFIG_BIAS_PULL_DOWN, 1);
+ else if (test_bit(FLAG_BIAS_DISABLE, &desc->flags))
+ config |= pinconf_to_config_packed(PIN_CONFIG_BIAS_DISABLE, 1);
+ chip->set_config(chip, gpio_chip_hwgpio(desc), config);
+ }
if (chip->get_direction) {
/* chip->get_direction may sleep */
spin_unlock_irqrestore(&gpio_lock, flags);
@@ -3587,6 +3597,16 @@ void gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
if (lflags & GPIO_OPEN_SOURCE)
set_bit(FLAG_OPEN_SOURCE, &desc->flags);
+ if (lflags & GPIO_BIAS_PULL_UP)
+ set_bit(FLAG_BIAS_PULL_UP, &desc->flags);
+
+ if (lflags & GPIO_BIAS_PULL_DOWN)
+ set_bit(FLAG_BIAS_PULL_DOWN, &desc->flags);
+
+ if (lflags & GPIO_BIAS_DISABLE)
+ set_bit(FLAG_BIAS_DISABLE, &desc->flags);
+}
+
int gpiod_process_flags(struct gpio_desc *desc, const char *con_id,
unsigned long lflags, enum gpiod_flags dflags)
{
@@ -3760,10 +3780,6 @@ struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
if (IS_ERR(desc))
return desc;
- ret = gpiod_request(desc, label);
- if (ret)
- return ERR_PTR(ret);
-
if (active_low)
lflags |= GPIO_ACTIVE_LOW;
@@ -3777,7 +3793,13 @@ struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
if (transitory)
lflags |= GPIO_TRANSITORY;
- ret = gpiod_configure_and_process_flags(desc, propname, lflags, dflags);
+ gpiod_configure_flags(desc, propname, lflags, dflags);
+
+ ret = gpiod_request(desc, label);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = gpiod_process_flags(desc, propname, lflags, dflags);
if (ret < 0) {
gpiod_put(desc);
return ERR_PTR(ret);
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index a03553d4be1c..381a7a1bf540 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -210,6 +210,9 @@ struct gpio_desc {
#define FLAG_USED_AS_IRQ 9 /* GPIO is connected to an IRQ */
#define FLAG_IS_HOGGED 11 /* GPIO is hogged */
#define FLAG_TRANSITORY 12 /* GPIO may lose value in sleep or reset */
+#define FLAG_BIAS_PULL_UP 13
+#define FLAG_BIAS_PULL_DOWN 14
+#define FLAG_BIAS_DISABLE 15
/* Connection label */
const char *label;
diff --git a/include/dt-bindings/gpio/gpio.h b/include/dt-bindings/gpio/gpio.h
index 2cc10ae4bbb7..28ccfce72c59 100644
--- a/include/dt-bindings/gpio/gpio.h
+++ b/include/dt-bindings/gpio/gpio.h
@@ -33,4 +33,13 @@
#define GPIO_PERSISTENT 0
#define GPIO_TRANSITORY 8
+/* Bit 4 express Bias Pull up */
+#define GPIO_BIAS_PULL_UP 16
+
+/* Bit 5 express Bias Pull down */
+#define GPIO_BIAS_PULL_DOWN 32
+
+/* Bit 6 express Bias Disable */
+#define GPIO_BIAS_DISABLE 64
+
#endif
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index b2f2dc638463..e0b6ac64871f 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -12,6 +12,9 @@ enum gpio_lookup_flags {
GPIO_OPEN_SOURCE = (1 << 2),
GPIO_PERSISTENT = (0 << 3),
GPIO_TRANSITORY = (1 << 3),
+ GPIO_BIAS_PULL_UP = (1 << 4),
+ GPIO_BIAS_PULL_DOWN = (1 << 5),
+ GPIO_BIAS_DISABLE = (1 << 6),
};
/**
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index f928c2df2bcd..1b025e6680ea 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -33,6 +33,9 @@ enum of_gpio_flags {
OF_GPIO_SINGLE_ENDED = BIT(1),
OF_GPIO_OPEN_DRAIN = BIT(2),
OF_GPIO_TRANSITORY = BIT(3),
+ OF_GPIO_BIAS_PULL_UP = BIT(4),
+ OF_GPIO_BIAS_PULL_DOWN = BIT(5),
+ OF_GPIO_BIAS_DISABLE = BIT(6),
};
#ifdef CONFIG_OF_GPIO
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 3/7] gpio: gpiolib: save GPIO flags in of_get_named_gpiod_flags
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
When we get a GPIO descriptor from the device device, the flags
are updated for the caller to know if the GPIO is active low or
high. After calling of_get_named_gpio_flags the next step is
usually calling gpiod_request which doesn't take flags as a
parameter.
Updating the flags of the GPIO descriptor will allow to configure
the GPIO when it will be requested.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
drivers/gpio/gpiolib-of.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 4a2b8d3397c7..67b1a7ff1e97 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -97,6 +97,8 @@ struct gpio_desc *of_get_named_gpiod_flags(struct device_node *np,
__func__, propname, np, index,
PTR_ERR_OR_ZERO(desc));
+ gpiod_configure_flags(desc, propname, *flags, 0);
+
out:
of_node_put(gpiospec.np);
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 2/7] gpio: gpiolib: split the gpiod_configure_flags function
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
The gpiod_configure_flags function doesn't only configure flags, it
also performs some processing. It implies that it should be called
after having requested the GPIO. Split configuration and processing
to allow flags configuration before requesting the GPIO. It is
needed if we want to set the pin configuration.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
drivers/gpio/gpiolib.c | 49 +++++++++++++++++++++++++++++++------------------
drivers/gpio/gpiolib.h | 7 ++++++-
2 files changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 0621baddfddc..c887602ca0ff 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -3564,23 +3564,9 @@ struct gpio_desc *__must_check gpiod_get_optional(struct device *dev,
EXPORT_SYMBOL_GPL(gpiod_get_optional);
-/**
- * gpiod_configure_flags - helper function to configure a given GPIO
- * @desc: gpio whose value will be assigned
- * @con_id: function within the GPIO consumer
- * @lflags: gpio_lookup_flags - returned from of_find_gpio() or
- * of_get_gpio_hog()
- * @dflags: gpiod_flags - optional GPIO initialization flags
- *
- * Return 0 on success, -ENOENT if no GPIO has been assigned to the
- * requested function and/or index, or another IS_ERR() code if an error
- * occurred while trying to acquire the GPIO.
- */
-int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
+void gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
unsigned long lflags, enum gpiod_flags dflags)
{
- int status;
-
if (lflags & GPIO_ACTIVE_LOW)
set_bit(FLAG_ACTIVE_LOW, &desc->flags);
@@ -3601,6 +3587,11 @@ int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
if (lflags & GPIO_OPEN_SOURCE)
set_bit(FLAG_OPEN_SOURCE, &desc->flags);
+int gpiod_process_flags(struct gpio_desc *desc, const char *con_id,
+ unsigned long lflags, enum gpiod_flags dflags)
+{
+ int status;
+
status = gpiod_set_transitory(desc, (lflags & GPIO_TRANSITORY));
if (status < 0)
return status;
@@ -3622,6 +3613,28 @@ int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
}
/**
+ * gpiod_configure_and_process_flags - helper function to configure a
+ * given GPIO
+ * @desc: gpio whose value will be assigned
+ * @con_id: function within the GPIO consumer
+ * @lflags: gpio_lookup_flags - returned from of_find_gpio() or
+ * of_get_gpio_hog()
+ * @dflags: gpiod_flags - optional GPIO initialization flags
+ *
+ * Return 0 on success, -ENOENT if no GPIO has been assigned to the
+ * requested function and/or index, or another IS_ERR() code if an error
+ * occurred while trying to acquire the GPIO.
+ */
+int gpiod_configure_and_process_flags(struct gpio_desc *desc,
+ const char *con_id,
+ unsigned long lflags,
+ enum gpiod_flags dflags)
+{
+ gpiod_configure_flags(desc, con_id, lflags, dflags);
+ return gpiod_process_flags(desc, con_id, lflags, dflags);
+}
+
+/**
* gpiod_get_index - obtain a GPIO from a multi-index GPIO function
* @dev: GPIO consumer, can be NULL for system-global GPIOs
* @con_id: function within the GPIO consumer
@@ -3675,7 +3688,7 @@ struct gpio_desc *__must_check gpiod_get_index(struct device *dev,
if (status < 0)
return ERR_PTR(status);
- status = gpiod_configure_flags(desc, con_id, lookupflags, flags);
+ status = gpiod_configure_and_process_flags(desc, con_id, lookupflags, flags);
if (status < 0) {
dev_dbg(dev, "setup of GPIO %s failed\n", con_id);
gpiod_put(desc);
@@ -3764,7 +3777,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
if (transitory)
lflags |= GPIO_TRANSITORY;
- ret = gpiod_configure_flags(desc, propname, lflags, dflags);
+ ret = gpiod_configure_and_process_flags(desc, propname, lflags, dflags);
if (ret < 0) {
gpiod_put(desc);
return ERR_PTR(ret);
@@ -3830,7 +3843,7 @@ int gpiod_hog(struct gpio_desc *desc, const char *name,
return status;
}
- status = gpiod_configure_flags(desc, name, lflags, dflags);
+ status = gpiod_configure_and_process_flags(desc, name, lflags, dflags);
if (status < 0) {
pr_err("setup of hog GPIO %s (chip %s, offset %d) failed, %d\n",
name, chip->label, hwnum, status);
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index 5e1f7cc6eeb6..a03553d4be1c 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -219,8 +219,13 @@ struct gpio_desc {
int gpiod_request(struct gpio_desc *desc, const char *label);
void gpiod_free(struct gpio_desc *desc);
-int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
+void gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
unsigned long lflags, enum gpiod_flags dflags);
+int gpiod_process_flags(struct gpio_desc *desc, const char *con_id,
+ unsigned long lflags, enum gpiod_flags dflags);
+int gpiod_configure_and_process_flags(struct gpio_desc *desc,
+ const char *con_id, unsigned long lflags,
+ enum gpiod_flags dflags);
int gpiod_hog(struct gpio_desc *desc, const char *name,
unsigned long lflags, enum gpiod_flags dflags);
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 1/7] gpio: of: use the BIT macro for of_gpio_flags
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
Use the BIT macro for the of_gpio_flags enumeration.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
include/linux/of_gpio.h | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index 18a7f03e1182..f928c2df2bcd 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -14,6 +14,7 @@
#ifndef __LINUX_OF_GPIO_H
#define __LINUX_OF_GPIO_H
+#include <linux/bitops.h>
#include <linux/compiler.h>
#include <linux/kernel.h>
#include <linux/errno.h>
@@ -28,10 +29,10 @@ struct device_node;
* Linux-specific in their .xlate callback. Though, 1:1 mapping is recommended.
*/
enum of_gpio_flags {
- OF_GPIO_ACTIVE_LOW = 0x1,
- OF_GPIO_SINGLE_ENDED = 0x2,
- OF_GPIO_OPEN_DRAIN = 0x4,
- OF_GPIO_TRANSITORY = 0x8,
+ OF_GPIO_ACTIVE_LOW = BIT(0),
+ OF_GPIO_SINGLE_ENDED = BIT(1),
+ OF_GPIO_OPEN_DRAIN = BIT(2),
+ OF_GPIO_TRANSITORY = BIT(3),
};
#ifdef CONFIG_OF_GPIO
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 0/7] gpiolib: add bias support
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is an attempt to add the bias configuration to the gpiolib since
I want and need to enable the pinmuxing strict mode to get an error if
I request a GPIO which is used by a peripheral.
I have not monitored the gpio mailing list for a while. Sorry I may have
missed some discussions about this topic. In this case, let me know which
threads I should read.
I have a memory of a discussion about the pinmux strict mode and the
constraints related to it. Several pin controllers can mux a pin as a GPIO
or as a peripheral. Doing both is not possible, so the strict mode may or
must be enabled. Unfortunately, to perform the pin configuration of the GPIO,
such as the bias (pull up, pull down, disabled), we have to declare this pin
in the pinmuxing. Doing this leads to a conflict when the device requests the
GPIO. The owner of the pin is the device which requested the pinmuxing whereas
the owner of the GPIO is the pin controller.
To solve this, there are two solutions:
- fix this owner mismatching. The owner of the GPIO must be the requester. It's
not difficult to solve this issue if we add the requester as a parameter when
the GPIO is requested but it impacts a lot of code.
- allow the gpiolib to set the pin configuration. I think the main issue
was code duplication. Since I have seen the introduction of
gpiochip_generic_config(), gpiod_set_debounce(), I suppose it's the way to go.
I have not introduced a gpiod_set_bias() because I think the only place to
setup this is in the device tree. It's useless to setup a bias pull up if there
is an external pull up on the board.
Ludovic Desroches (7):
gpio: of: use the BIT macro for of_gpio_flags
gpio: gpiolib: split the gpiod_configure_flags function
gpio: gpiolib: save GPIO flags in of_get_named_gpiod_flags
gpio: gpiolib: add bias support
pinctrl: at91-pio4: allow the gpiolib to set pin configuration
pinctrl: at91-pio4: use strict mode if explicitly requested
ARM: dts: remove gpio from pinmux
.../bindings/pinctrl/atmel,at91-pio4-pinctrl.txt | 4 ++
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 45 ++----------
drivers/gpio/gpiolib-of.c | 11 +++
drivers/gpio/gpiolib.c | 81 ++++++++++++++++------
drivers/gpio/gpiolib.h | 10 ++-
drivers/pinctrl/pinctrl-at91-pio4.c | 26 ++++++-
include/dt-bindings/gpio/gpio.h | 9 +++
include/linux/gpio/machine.h | 3 +
include/linux/of_gpio.h | 12 ++--
9 files changed, 134 insertions(+), 67 deletions(-)
--
2.12.2
^ permalink raw reply
* [PATCH v2 1/3] mmc: dt-bindings: add mmc support to MT7623 SoC
From: Sean Wang @ 2017-12-14 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86e53802-9bb4-35eb-66e1-f9a401e31863@gmail.com>
On Thu, 2017-12-14 at 12:16 +0100, Matthias Brugger wrote:
> Hi Ulf,
>
> On 12/07/2017 07:43 AM, sean.wang at mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > Add the devicetree binding for MT7623 SoC using MT2701 as the fallback.
> >
> > Cc: devicetree at vger.kernel.org
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> > Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > index 72d2a73..9b80176 100644
> > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > @@ -12,6 +12,8 @@ Required properties:
> > "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> > "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> > "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> > + "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
> > +
> > - reg: physical base address of the controller and length
> > - interrupts: Should contain MSDC interrupt number
> > - clocks: Should contain phandle for the clock feeding the MMC controller
> >
>
> Are you fine to take this patch through your branch, or shall I take it through
> mine?
>
> @Sean it seems you forgot to send this patch to Ulf as well. In the future
> please take care to send the patch to all relevant people and mailinglist.
>
Okay. I'll be. really sorry for the inconvenience
> Thanks,
> Matthias
>
^ permalink raw reply
* [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
From: Timur Tabi @ 2017-12-14 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214103027.GB697@e107981-ln.cambridge.arm.com>
On 12/14/17 4:30 AM, Lorenzo Pieralisi wrote:
>> I didn't want to put any ACPI code in amba-pl011.c, so putting it in spcr.c
>> made the most sense. I agree the global variable is ugly. If you have a
>> better idea, I'm all ears.
> I told you my idea. It could have been made easier by reusing the
> ACPI_DECLARE_PROBE_ENTRY() mechanism.
Sorry, I don't mean to be difficult, but when did you tell *me* this
idea of yours? I don't see any email from you to me that mentions
ACPI_DECLARE_PROBE_ENTRY(). I've never even heard of that macro before.
Please note that I'm not the original author of this code.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] arm64/sve: Report SVE to userspace via CPUID only if supported
From: Mark Rutland @ 2017-12-14 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513260094-9893-1-git-send-email-Dave.Martin@arm.com>
On Thu, Dec 14, 2017 at 02:01:34PM +0000, Dave Martin wrote:
> Currently, the SVE field in ID_AA64PFR0_EL1 is visible
> unconditionally to userspace via the CPU ID register emulation,
> irrespective of the kernel config. This means that if a kernel
> configured with CONFIG_ARM64_SVE=n is run on SVE-capable hardware,
> userspace will see SVE reported as present in the ID regs even
> though the kernel forbids execution of SVE instructions.
>
> This patch makes the exposure of the SVE field in ID_AA64PFR0_EL1
> conditional on CONFIG_ARM64_SVE=y.
>
> Since future architecture features are likely to encounter a
> similar requirement, this patch adds a suitable helper macros for
> use when declaring config-conditional ID register fields.
Makes sense to me; I can use this for pointer authentication fields.
> Fixes: 43994d824e84 ("arm64/sve: Detect SVE and activate runtime support")
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
>
> This patch is proposed as a fix for v4.15, since we don't want to create
> unintentional ABI by exposing the wrong thing to userspace in a full
> kernel release.
>
> arch/arm64/include/asm/cpufeature.h | 3 +++
> arch/arm64/kernel/cpufeature.c | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index ac67cfc..060e3a4 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -60,6 +60,9 @@ enum ftr_type {
> #define FTR_VISIBLE true /* Feature visible to the user space */
> #define FTR_HIDDEN false /* Feature is hidden from the user */
>
> +#define FTR_VISIBLE_IF_IS_ENABLED(config) \
> + (IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
> +
> struct arm64_ftr_bits {
> bool sign; /* Value is signed ? */
> bool visible;
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c5ba009..a73a592 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -145,7 +145,8 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> - ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
> + FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 08/12] mmc: sdhci-omap: Add support to override f_max and iodelay from pdata
From: Philippe Ombredanne @ 2017-12-14 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214130941.26666-9-kishon@ti.com>
Kishon,
On Thu, Dec 14, 2017 at 2:09 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> DRA74x EVM Rev H EVM comes with revision 2.0 silicon. However, earlier
> versions of EVM can come with either revision 1.1 or revision 1.0 of
> silicon.
>
> The device-tree file is written to support rev 2.0 of silicon.
> pdata-quirks are used to then override the settings needed for
> PG 1.1 silicon.
>
> PG 1.1 silicon has limitations w.r.t frequencies at which MMC1/2/3
> can operate as well as different IOdelay numbers.
>
> Add support in sdhci-omap driver to get platform data if available
> (added using pdata quirks) and override the data (max-frequency and
> iodelay data) obtained from device tree.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
<snip>
> --- /dev/null
> +++ b/include/linux/platform_data/sdhci-omap.h
> @@ -0,0 +1,35 @@
> +/**
> + * SDHCI Controller Platform Data for TI's OMAP SoCs
> + *
> + * Copyright (C) 2017 Texas Instruments
> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 of
> + * the License 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
Could you use the new SPDX tags instead of this fine and long boilerplate? See
Thomas doc for details [1]
[1] https://lkml.org/lkml/2017/12/4/934
Thanks!
PS: if you could spread the word out in your team too, this would be
much welcomed!
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH] arm64/sve: Report SVE to userspace via CPUID only if supported
From: Dave Martin @ 2017-12-14 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513260094-9893-1-git-send-email-Dave.Martin@arm.com>
Will, FYI -- sorry, forgot to Cc you.
Cheers
---Dave
On Thu, Dec 14, 2017 at 02:01:34PM +0000, Dave Martin wrote:
> Currently, the SVE field in ID_AA64PFR0_EL1 is visible
> unconditionally to userspace via the CPU ID register emulation,
> irrespective of the kernel config. This means that if a kernel
> configured with CONFIG_ARM64_SVE=n is run on SVE-capable hardware,
> userspace will see SVE reported as present in the ID regs even
> though the kernel forbids execution of SVE instructions.
>
> This patch makes the exposure of the SVE field in ID_AA64PFR0_EL1
> conditional on CONFIG_ARM64_SVE=y.
>
> Since future architecture features are likely to encounter a
> similar requirement, this patch adds a suitable helper macros for
> use when declaring config-conditional ID register fields.
>
> Fixes: 43994d824e84 ("arm64/sve: Detect SVE and activate runtime support")
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
> ---
>
> This patch is proposed as a fix for v4.15, since we don't want to create
> unintentional ABI by exposing the wrong thing to userspace in a full
> kernel release.
>
> arch/arm64/include/asm/cpufeature.h | 3 +++
> arch/arm64/kernel/cpufeature.c | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index ac67cfc..060e3a4 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -60,6 +60,9 @@ enum ftr_type {
> #define FTR_VISIBLE true /* Feature visible to the user space */
> #define FTR_HIDDEN false /* Feature is hidden from the user */
>
> +#define FTR_VISIBLE_IF_IS_ENABLED(config) \
> + (IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
> +
> struct arm64_ftr_bits {
> bool sign; /* Value is signed ? */
> bool visible;
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c5ba009..a73a592 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -145,7 +145,8 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> - ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
> + FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64/sve: Report SVE to userspace via CPUID only if supported
From: Dave Martin @ 2017-12-14 14:01 UTC (permalink / raw)
To: linux-arm-kernel
Currently, the SVE field in ID_AA64PFR0_EL1 is visible
unconditionally to userspace via the CPU ID register emulation,
irrespective of the kernel config. This means that if a kernel
configured with CONFIG_ARM64_SVE=n is run on SVE-capable hardware,
userspace will see SVE reported as present in the ID regs even
though the kernel forbids execution of SVE instructions.
This patch makes the exposure of the SVE field in ID_AA64PFR0_EL1
conditional on CONFIG_ARM64_SVE=y.
Since future architecture features are likely to encounter a
similar requirement, this patch adds a suitable helper macros for
use when declaring config-conditional ID register fields.
Fixes: 43994d824e84 ("arm64/sve: Detect SVE and activate runtime support")
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
---
This patch is proposed as a fix for v4.15, since we don't want to create
unintentional ABI by exposing the wrong thing to userspace in a full
kernel release.
arch/arm64/include/asm/cpufeature.h | 3 +++
arch/arm64/kernel/cpufeature.c | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index ac67cfc..060e3a4 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -60,6 +60,9 @@ enum ftr_type {
#define FTR_VISIBLE true /* Feature visible to the user space */
#define FTR_HIDDEN false /* Feature is hidden from the user */
+#define FTR_VISIBLE_IF_IS_ENABLED(config) \
+ (IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
+
struct arm64_ftr_bits {
bool sign; /* Value is signed ? */
bool visible;
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c5ba009..a73a592 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -145,7 +145,8 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
};
static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
+ FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
--
2.1.4
^ permalink raw reply related
* [PATCH v2 20/36] KVM: arm64: Don't save the host ELR_EL2 and SPSR_EL2 on VHE systems
From: Christoffer Dall @ 2017-12-14 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a5d687f6-478f-7436-58c0-932a4eaa466c@arm.com>
On Mon, Dec 11, 2017 at 10:44:59AM +0000, Marc Zyngier wrote:
> On 07/12/17 17:06, Christoffer Dall wrote:
> > On non-VHE systems we need to save the ELR_EL2 and SPSR_EL2 so that we
> > can return to the host in EL1 in the same state and location where we
> > issued a hypercall to EL2, but these registers don't contain anything
> > important on VHE, because all of the host runs in EL2. Therefore,
>
> If I may refine the rational: ELR_EL2 and SPSR_EL2 are not useful here
> because we never enter a guest as a result of an exception entry that
> would be directly handled by KVM. The kernel entry code already saves
> ELR_EL1/SPSR_EL1 on exception entry, which is enough.
>
Indeed, I was being a bit loosey-goosey here.
> > factor out these registers into separate save/restore functions, making
> > it easy to exclude them from the VHE world-switch path later on.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > arch/arm64/kvm/hyp/sysreg-sr.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
> > index a12112494f75..479de0f0dd07 100644
> > --- a/arch/arm64/kvm/hyp/sysreg-sr.c
> > +++ b/arch/arm64/kvm/hyp/sysreg-sr.c
> > @@ -71,6 +71,10 @@ static void __hyp_text __sysreg_save_el1_state(struct kvm_cpu_context *ctxt)
> > ctxt->gp_regs.sp_el1 = read_sysreg(sp_el1);
> > ctxt->gp_regs.elr_el1 = read_sysreg_el1(elr);
> > ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
> > +}
> > +
> > +static void __hyp_text __sysreg_save_el2_return_state(struct kvm_cpu_context *ctxt)
> > +{
> > ctxt->gp_regs.regs.pc = read_sysreg_el2(elr);
> > ctxt->gp_regs.regs.pstate = read_sysreg_el2(spsr);
> > }
> > @@ -80,6 +84,7 @@ void __hyp_text __sysreg_save_state_nvhe(struct kvm_cpu_context *ctxt)
> > __sysreg_save_el1_state(ctxt);
> > __sysreg_save_common_state(ctxt);
> > __sysreg_save_user_state(ctxt);
> > + __sysreg_save_el2_return_state(ctxt);
> > }
> >
> > void sysreg_save_host_state_vhe(struct kvm_cpu_context *ctxt)
> > @@ -93,6 +98,7 @@ void sysreg_save_guest_state_vhe(struct kvm_cpu_context *ctxt)
> > __sysreg_save_el1_state(ctxt);
> > __sysreg_save_common_state(ctxt);
> > __sysreg_save_user_state(ctxt);
> > + __sysreg_save_el2_return_state(ctxt);
> > }
> >
> > static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctxt)
> > @@ -137,6 +143,11 @@ static void __hyp_text __sysreg_restore_el1_state(struct kvm_cpu_context *ctxt)
> > write_sysreg(ctxt->gp_regs.sp_el1, sp_el1);
> > write_sysreg_el1(ctxt->gp_regs.elr_el1, elr);
> > write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
> > +}
> > +
> > +static void __hyp_text
> > +__sysreg_restore_el2_return_state(struct kvm_cpu_context *ctxt)
> > +{
> > write_sysreg_el2(ctxt->gp_regs.regs.pc, elr);
> > write_sysreg_el2(ctxt->gp_regs.regs.pstate, spsr);
> > }
> > @@ -146,6 +157,7 @@ void __hyp_text __sysreg_restore_state_nvhe(struct kvm_cpu_context *ctxt)
> > __sysreg_restore_el1_state(ctxt);
> > __sysreg_restore_common_state(ctxt);
> > __sysreg_restore_user_state(ctxt);
> > + __sysreg_restore_el2_return_state(ctxt);
> > }
> >
> > void sysreg_restore_host_state_vhe(struct kvm_cpu_context *ctxt)
> > @@ -159,6 +171,7 @@ void sysreg_restore_guest_state_vhe(struct kvm_cpu_context *ctxt)
> > __sysreg_restore_el1_state(ctxt);
> > __sysreg_restore_common_state(ctxt);
> > __sysreg_restore_user_state(ctxt);
> > + __sysreg_restore_el2_return_state(ctxt);
> > }
> >
> > static void __hyp_text __fpsimd32_save_state(struct kvm_cpu_context *ctxt)
> >
>
> Otherwise:
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 14/14] ARM: dts: keystone-k2g: Use sdhci-omap programming model
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
Use sdhci-omap programming model based on the generic sdhci
library for programming the MMC/SD controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/keystone-k2g.dtsi | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 8f313ff406b9..2c6da70eac38 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -349,14 +349,10 @@
};
mmc0: mmc at 23000000 {
- compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+ compatible = "ti,k2g-sdhci";
reg = <0x23000000 0x400>;
interrupts = <GIC_SPI 96 IRQ_TYPE_EDGE_RISING>;
- dmas = <&edma1 24 0>, <&edma1 25 0>;
- dma-names = "tx", "rx";
bus-width = <4>;
- ti,needs-special-reset;
- no-1-8-v;
max-frequency = <96000000>;
power-domains = <&k2g_pds 0xb>;
clocks = <&k2g_clks 0xb 1>, <&k2g_clks 0xb 2>;
@@ -365,14 +361,11 @@
};
mmc1: mmc at 23100000 {
- compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+ compatible = "ti,k2g-sdhci";
reg = <0x23100000 0x400>;
interrupts = <GIC_SPI 97 IRQ_TYPE_EDGE_RISING>;
- dmas = <&edma1 26 0>, <&edma1 27 0>;
- dma-names = "tx", "rx";
bus-width = <8>;
- ti,needs-special-reset;
- ti,non-removable;
+ non-removable;
max-frequency = <96000000>;
power-domains = <&k2g_pds 0xc>;
clocks = <&k2g_clks 0xc 1>, <&k2g_clks 0xc 2>;
--
2.11.0
^ permalink raw reply related
* [PATCH 13/14] ARM: dts: dra7: Use sdhci-omap programming model
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
Use sdhci-omap programming model based on the generic sdhci
library for programming the first 2 instances of eMMC/SD/SDIO
controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 3 +--
arch/arm/boot/dts/am57xx-idk-common.dtsi | 2 +-
arch/arm/boot/dts/dra7-evm.dts | 1 +
arch/arm/boot/dts/dra7.dtsi | 25 ++++++++++++++++---------
arch/arm/boot/dts/dra72-evm-common.dtsi | 2 +-
arch/arm/boot/dts/dra76-evm.dts | 3 ++-
6 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 50e7c3c0d111..44e6720bc939 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -444,8 +444,7 @@
vmmc-supply = <&vdd_3v3>;
vqmmc-supply = <&vdd_3v3>;
bus-width = <8>;
- ti,non-removable;
- cap-mmc-dual-data-rate;
+ non-removable;
};
&sata {
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 43cdf523a8a0..855c130afc69 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -423,7 +423,7 @@
vmmc-supply = <&v3_3d>;
vqmmc-supply = <&v3_3d>;
bus-width = <8>;
- ti,non-removable;
+ non-removable;
max-frequency = <96000000>;
};
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ef9c90daa74b..b5ec42f16efc 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -351,6 +351,7 @@
status = "okay";
vmmc-supply = <&evm_1v8_sw>;
bus-width = <8>;
+ non-removable;
pinctrl-names = "default", "hs", "ddr_1_8v-rev11", "ddr_1_8v", "hs200_1_8v-rev11", "hs200_1_8v";
pinctrl-0 = <&mmc2_pins_default>;
pinctrl-1 = <&mmc2_pins_hs>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ac9216293b7c..1acd77f29d0b 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1057,17 +1057,21 @@
};
mmc1: mmc at 4809c000 {
- compatible = "ti,omap4-hsmmc";
+ compatible = "ti,dra7-sdhci";
reg = <0x4809c000 0x400>;
interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mmc1";
- ti,dual-volt;
- ti,needs-special-reset;
- dmas = <&sdma_xbar 61>, <&sdma_xbar 62>;
- dma-names = "tx", "rx";
status = "disabled";
pbias-supply = <&pbias_mmc_reg>;
max-frequency = <192000000>;
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-ddr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+ cap-sd-highspeed;
+ mmc-ddr-1_8v;
+ cap-mmc-highspeed;
};
hdqw1w: 1w at 480b2000 {
@@ -1078,15 +1082,18 @@
};
mmc2: mmc at 480b4000 {
- compatible = "ti,omap4-hsmmc";
+ compatible = "ti,dra7-sdhci";
reg = <0x480b4000 0x400>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mmc2";
- ti,needs-special-reset;
- dmas = <&sdma_xbar 47>, <&sdma_xbar 48>;
- dma-names = "tx", "rx";
status = "disabled";
max-frequency = <192000000>;
+ cap-sd-highspeed;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+ mmc-hs200-1_8v;
+ mmc-ddr-1_8v;
+ cap-mmc-highspeed;
};
mmc3: mmc at 480ad000 {
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index 2e485a13dfd7..4f48f97c9c47 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -421,7 +421,7 @@
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins_default>;
bus-width = <8>;
- ti,non-removable;
+ non-removable;
max-frequency = <192000000>;
};
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 4dd8a5ac8fae..02c01cecc417 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -306,7 +306,7 @@
&mmc1 {
status = "okay";
vmmc-supply = <&vio_3v3_sd>;
- vmmc_aux-supply = <&ldo4_reg>;
+ vqmmc-supply = <&ldo4_reg>;
bus-width = <4>;
/*
* SDCD signal is not being used here - using the fact that GPIO mode
@@ -323,6 +323,7 @@
vmmc-supply = <&vio_1v8>;
vqmmc-supply = <&vio_1v8>;
bus-width = <8>;
+ non-removable;
pinctrl-names = "default", "hs", "ddr_1_8v", "hs200_1_8v";
pinctrl-0 = <&mmc2_pins_default>;
pinctrl-1 = <&mmc2_pins_hs>;
--
2.11.0
^ permalink raw reply related
* [PATCH 12/14] ARM: dts: am57xx-idk: Select pull down for mmc1_clk line in default mode
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.
According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Physical Layer Specification Version 5.00 February 22, 2016", the
host should hold CLK low for at least 5ms.
In order to keep the card line low during voltage switch, the pad mux of
mmc1_clk line should be configured to pull down.
This is specific to am57xx-idk (and not all dra72/dra74 based boards)
since mmc1_clk line in am57xx-idk is not connected to an external
pullup.
While at that change the order of header files in am571x-idk.dts and
am572x-idk.dts so that the modified pinctrl values in am57xx-idk-common
could take effect.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/am571x-idk.dts | 2 +-
arch/arm/boot/dts/am572x-idk.dts | 2 +-
arch/arm/boot/dts/am57xx-idk-common.dtsi | 11 +++++++++++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
index debf9464403e..c7d77acffa28 100644
--- a/arch/arm/boot/dts/am571x-idk.dts
+++ b/arch/arm/boot/dts/am571x-idk.dts
@@ -10,8 +10,8 @@
#include "dra72x.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
-#include "am57xx-idk-common.dtsi"
#include "dra72x-mmc-iodelay.dtsi"
+#include "am57xx-idk-common.dtsi"
/ {
model = "TI AM5718 IDK";
diff --git a/arch/arm/boot/dts/am572x-idk.dts b/arch/arm/boot/dts/am572x-idk.dts
index a578fe97ba3b..144376ad5f35 100644
--- a/arch/arm/boot/dts/am572x-idk.dts
+++ b/arch/arm/boot/dts/am572x-idk.dts
@@ -11,8 +11,8 @@
#include "dra74x.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
-#include "am57xx-idk-common.dtsi"
#include "dra74x-mmc-iodelay.dtsi"
+#include "am57xx-idk-common.dtsi"
/ {
model = "TI AM5728 IDK";
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 43a6d0590f7c..43cdf523a8a0 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -115,6 +115,17 @@
DRA7XX_CORE_IOPAD(0x37d4, MUX_MODE15 | PULL_UP) /* dcan1_rx.off */
>;
};
+
+ mmc1_pins_default: mmc1_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
};
&i2c1 {
--
2.11.0
^ permalink raw reply related
* [PATCH 11/14] ARM: dts: dra71-evm: Select pull down for mmc1_clk line in default mode
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.
According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Physical Layer Specification Version 5.00 February 22, 2016", the
host should hold CLK low for at least 5ms.
In order to keep the card line low during voltage switch, the pad mux of
mmc1_clk line should be configured to pull down.
This is specific only to dra71-evm (and not all dra72 based boards) since
mmc1_clk line in dra71-evm is not connected to an external pullup.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra71-evm.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
index 64363f75c01a..ebc4bbae981e 100644
--- a/arch/arm/boot/dts/dra71-evm.dts
+++ b/arch/arm/boot/dts/dra71-evm.dts
@@ -50,6 +50,19 @@
};
};
+&dra7_pmx_core {
+ mmc1_pins_default: mmc1_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+};
+
&i2c1 {
status = "okay";
clock-frequency = <400000>;
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox