* [PATCH] ARM: OMAP1: DMA: Correct the number of logical channels
From: Aaro Koskinen @ 2017-01-05 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103112234.19097-1-peter.ujfalusi@ti.com>
Hi,
On Tue, Jan 03, 2017 at 01:22:34PM +0200, Peter Ujfalusi wrote:
> OMAP1510, OMAP5910 and OMAP310 have only 9 logical channels.
> OMAP1610, OMAP5912, OMAP1710, OMAP730, and OMAP850 have 16 logical channels
> available.
>
> The wired 17 for the lch_count must have been used to cover the 16 + 1
> dedicated LCD channel, in reality we can only use 9 or 16 channels.
>
> The d->chan_count is not used by the omap-dma stack, so we can skip the
> setup. chan_count was configured to the number of logical channels and not
> the actual number of physical channels anyways.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
> ---
> arch/arm/mach-omap1/dma.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> index f6ba589cd312..c821c1d5610e 100644
> --- a/arch/arm/mach-omap1/dma.c
> +++ b/arch/arm/mach-omap1/dma.c
> @@ -32,7 +32,6 @@
> #include "soc.h"
>
> #define OMAP1_DMA_BASE (0xfffed800)
> -#define OMAP1_LOGICAL_DMA_CH_COUNT 17
>
> static u32 enable_1510_mode;
>
> @@ -348,8 +347,6 @@ static int __init omap1_system_dma_init(void)
> goto exit_iounmap;
> }
>
> - d->lch_count = OMAP1_LOGICAL_DMA_CH_COUNT;
> -
> /* Valid attributes for omap1 plus processors */
> if (cpu_is_omap15xx())
> d->dev_caps = ENABLE_1510_MODE;
> @@ -366,13 +363,14 @@ static int __init omap1_system_dma_init(void)
> d->dev_caps |= CLEAR_CSR_ON_READ;
> d->dev_caps |= IS_WORD_16;
>
> - if (cpu_is_omap15xx())
> - d->chan_count = 9;
> - else if (cpu_is_omap16xx() || cpu_is_omap7xx()) {
> - if (!(d->dev_caps & ENABLE_1510_MODE))
> - d->chan_count = 16;
> + /* available logical channels */
> + if (cpu_is_omap15xx()) {
> + d->lch_count = 9;
> + } else {
> + if (d->dev_caps & ENABLE_1510_MODE)
> + d->lch_count = 9;
> else
> - d->chan_count = 9;
> + d->lch_count = 16;
> }
>
> p = dma_plat_info;
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Aaro Koskinen as TI omap1 SoC co-maintainer
From: Aaro Koskinen @ 2017-01-05 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105214101.30286-1-tony@atomide.com>
Hi,
On Thu, Jan 05, 2017 at 01:41:01PM -0800, Tony Lindgren wrote:
> Aaro has been doing a great job making sure mach-omap1 stays working
> with the mainline kernel. So let's add Aaro as omap1 co-maintainer to
> the MAINTAINERS file.
>
> Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
> ---
> MAINTAINERS | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8933,7 +8933,20 @@ M: Josh Poimboeuf <jpoimboe@redhat.com>
> S: Supported
> F: tools/objtool/
>
> -OMAP SUPPORT
> +OMAP1 SUPPORT
> +M: Aaro Koskinen <aaro.koskinen@iki.fi>
> +M: Tony Lindgren <tony@atomide.com>
> +L: linux-omap at vger.kernel.org
> +Q: http://patchwork.kernel.org/project/linux-omap/list/
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
> +S: Maintained
> +F: arch/arm/mach-omap1/
> +F: arch/arm/plat-omap/
> +F: arch/arm/configs/omap1_defconfig
> +F: drivers/i2c/busses/i2c-omap.c
> +F: include/linux/i2c-omap.h
> +
> +OMAP2+ SUPPORT
> M: Tony Lindgren <tony@atomide.com>
> L: linux-omap at vger.kernel.org
> W: http://www.muru.com/linux/omap/
> @@ -8941,8 +8954,8 @@ W: http://linux.omap.com/
> Q: http://patchwork.kernel.org/project/linux-omap/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
> S: Maintained
> -F: arch/arm/*omap*/
> -F: arch/arm/configs/omap1_defconfig
> +F: arch/arm/mach-omap2/
> +F: arch/arm/plat-omap/
> F: arch/arm/configs/omap2plus_defconfig
> F: drivers/i2c/busses/i2c-omap.c
> F: drivers/irqchip/irq-omap-intc.c
> --
> 2.11.0
^ permalink raw reply
* [PATCH v2] soc: ti: Drop wait from wkup_m3_rproc_boot_thread
From: Sarangdhar Joshi @ 2017-01-05 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <482666d0-7915-ead2-c514-2651a4967a43@ti.com>
On 01/05/2017 01:08 PM, Suman Anna wrote:
> On 01/03/2017 05:41 PM, Sarangdhar Joshi wrote:
>> The function wkup_m3_rproc_boot_thread waits for
>> asynchronous firmware loading to parse the resource table
>> before calling rproc_boot(). However, as the resource table
>> parsing has been moved to rproc_boot(), there's no need to
>> wait for the asynchronous firmware loading completion.
>> So, drop this.
>>
>> CC: Dave Gerlach <d-gerlach@ti.com>
>> CC: Suman Anna <s-anna@ti.com>
>> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>
> + Tony and Santosh, not sure who is picking up the wkup_m3 related patches.
>
> Only one minor nit, I would prefer the patch subject to start with
> soc: ti: wkup_m3_ipc: ....
Sure, will update the subject line.
Regards,
Sarang
>
> Tested-by: Suman Anna <s-anna@ti.com>
>
> regards
> Suman
>
>> ---
>>
>> This patch seems to be doing an independent clean up now. Hence
>> removing it from the series.
>>
>> drivers/soc/ti/wkup_m3_ipc.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
>> index 8823cc8..8bfa44b 100644
>> --- a/drivers/soc/ti/wkup_m3_ipc.c
>> +++ b/drivers/soc/ti/wkup_m3_ipc.c
>> @@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
>> struct device *dev = m3_ipc->dev;
>> int ret;
>>
>> - wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
>> -
>> init_completion(&m3_ipc->sync_complete);
>>
>> ret = rproc_boot(m3_ipc->rproc);
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3] soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
From: Sarangdhar Joshi @ 2017-01-05 22:00 UTC (permalink / raw)
To: linux-arm-kernel
The function wkup_m3_rproc_boot_thread waits for asynchronous
firmware loading to parse the resource table before calling
rproc_boot(). However, as the resource table parsing has been
moved to rproc_boot(), there's no need to wait for the
asynchronous firmware loading completion. So, drop this.
CC: Dave Gerlach <d-gerlach@ti.com>
CC: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
This patch seems to be doing an independent clean up now. Hence
removing it from the series.
Changes from v2:
* Updated the subject line as per Suman's comment
drivers/soc/ti/wkup_m3_ipc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
index 8823cc8..8bfa44b 100644
--- a/drivers/soc/ti/wkup_m3_ipc.c
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
struct device *dev = m3_ipc->dev;
int ret;
- wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
-
init_completion(&m3_ipc->sync_complete);
ret = rproc_boot(m3_ipc->rproc);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v2] soc: ti: Drop wait from wkup_m3_rproc_boot_thread
From: Tony Lindgren @ 2017-01-05 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d98575a9-1863-88f0-d417-ae894db2dc55@oracle.com>
* Santosh Shilimkar <santosh.shilimkar@oracle.com> [170105 13:18]:
>
>
> On 1/5/2017 1:08 PM, Suman Anna wrote:
> > On 01/03/2017 05:41 PM, Sarangdhar Joshi wrote:
> > > The function wkup_m3_rproc_boot_thread waits for
> > > asynchronous firmware loading to parse the resource table
> > > before calling rproc_boot(). However, as the resource table
> > > parsing has been moved to rproc_boot(), there's no need to
> > > wait for the asynchronous firmware loading completion.
> > > So, drop this.
> > >
> > > CC: Dave Gerlach <d-gerlach@ti.com>
> > > CC: Suman Anna <s-anna@ti.com>
> > > CC: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> >
> > + Tony and Santosh, not sure who is picking up the wkup_m3 related patches.
> >
> I think Tony has queued patches for wakeup_m3 before.
Sure I can queue it.
Thanks,
Tony
^ permalink raw reply
* [PATCH 3/6] clk: sunxi-ng: Add H5 clocks
From: Maxime Ripard @ 2017-01-05 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161226162518.5367-4-icenowy@aosc.xyz>
On Tue, Dec 27, 2016 at 12:25:15AM +0800, Icenowy Zheng wrote:
> Add the H5 CCU clocks set based on the H3 one.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Is there any difference with H3's?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/c4135864/attachment.sig>
^ permalink raw reply
* [PATCH 1/6] drivers: pinctrl: add driver for Allwinner H5 SoC
From: Maxime Ripard @ 2017-01-05 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161226162518.5367-2-icenowy@aosc.xyz>
On Tue, Dec 27, 2016 at 12:25:13AM +0800, Icenowy Zheng wrote:
> Based on the Allwinner H5 datasheet and the pinctrl driver of the
> backward-compatible H3 this introduces the pin multiplex assignments for
> the H5 SoC.
>
> H5 introduced some more pin functions (e.g. three more groups of TS
> pins, and one more groups of SIM pins) than H3.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
> drivers/pinctrl/sunxi/Kconfig | 4 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c | 551 +++++++++++++++++++++
> 4 files changed, 557 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index c931fb1c01a6..2fd688c8dbdb 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -23,6 +23,7 @@ Required properties:
> "allwinner,sun8i-h3-pinctrl"
> "allwinner,sun8i-h3-r-pinctrl"
> "allwinner,sun50i-a64-pinctrl"
> + "allwinner,sun50i-h5-r-pinctrl"
You're using a different compatible in your driver.
> "nextthing,gr8-pinctrl"
>
> - reg: Should contain the register physical address and length for the
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index bff1ffc6f01e..e9c47e8b2ee0 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -76,4 +76,8 @@ config PINCTRL_SUN50I_A64
> bool
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_H5
> + bool
> + select PINCTRL_SUNXI
> +
> endif
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 95f93d0561fc..bab215d25440 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -17,5 +17,6 @@ obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3_R) += pinctrl-sun8i-h3-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H5) += pinctrl-sun50i-h5.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
> new file mode 100644
> index 000000000000..67a55df37782
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
> @@ -0,0 +1,551 @@
> +/*
> + * Allwinner H5 SoC pinctrl driver.
> + *
> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
> + *
> + * Based on pinctrl-sun8i-h3.c, which is:
> + * Copyright (C) 2015 Jens Kuske <jenskuske@gmail.com>
> + *
> + * Based on pinctrl-sun8i-a23.c, which is:
> + * Copyright (C) 2014 Chen-Yu Tsai <wens@csie.org>
> + * Copyright (C) 2014 Maxime Ripard <maxime.ripard@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun50i_h5_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* TX */
> + SUNXI_FUNCTION(0x3, "jtag"), /* MS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PA_EINT0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RX */
> + SUNXI_FUNCTION(0x3, "jtag"), /* CK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PA_EINT1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RTS */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /* PA_EINT2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* CTS */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)), /* PA_EINT3 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)), /* PA_EINT4 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* RX */
> + SUNXI_FUNCTION(0x3, "pwm0"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)), /* PA_EINT5 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* PWREN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)), /* PA_EINT6 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)), /* PA_EINT7 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* DATA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)), /* PA_EINT8 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* RST */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)), /* PA_EINT9 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* DET */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)), /* PA_EINT10 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SCK */
> + SUNXI_FUNCTION(0x3, "di"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)), /* PA_EINT11 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SDA */
> + SUNXI_FUNCTION(0x3, "di"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 12)), /* PA_EINT12 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spi1"), /* CS */
> + SUNXI_FUNCTION(0x3, "uart3"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 13)), /* PA_EINT13 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spi1"), /* CLK */
> + SUNXI_FUNCTION(0x3, "uart3"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 14)), /* PA_EINT14 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spi1"), /* MOSI */
> + SUNXI_FUNCTION(0x3, "uart3"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 15)), /* PA_EINT15 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spi1"), /* MISO */
> + SUNXI_FUNCTION(0x3, "uart3"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 16)), /* PA_EINT16 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spdif"), /* OUT */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 17)), /* PA_EINT17 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 18),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s0"), /* SYNC */
> + SUNXI_FUNCTION(0x3, "i2c1"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 18)), /* PA_EINT18 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 19),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s0"), /* CLK */
> + SUNXI_FUNCTION(0x3, "i2c1"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 19)), /* PA_EINT19 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 20),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s0"), /* DOUT */
> + SUNXI_FUNCTION(0x3, "sim"), /* VPPEN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 20)), /* PA_EINT20 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 21),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s0"), /* DIN */
> + SUNXI_FUNCTION(0x3, "sim"), /* VPPPP */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 21)), /* PA_EINT21 */
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> + SUNXI_FUNCTION(0x3, "spi0")), /* MOSI */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* ALE */
> + SUNXI_FUNCTION(0x3, "spi0"), /* MISO */
> + SUNXI_FUNCTION(0x4, "mmc2")), /* DS */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CLE */
> + SUNXI_FUNCTION(0x3, "spi0")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE1 */
> + SUNXI_FUNCTION(0x3, "spi0")), /* CS */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE0 */
> + SUNXI_FUNCTION(0x4, "spi0")), /* MISO */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RE */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RB0 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* CMD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0")), /* RB1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ0 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ1 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ2 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ3 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D3 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ4 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D4 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ5 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D5 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ6 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ7 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D7 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQS */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* RST */
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXD3 */
> + SUNXI_FUNCTION(0x3, "di"), /* TX */
> + SUNXI_FUNCTION(0x4, "ts2")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXD2 */
> + SUNXI_FUNCTION(0x3, "di"), /* RX */
> + SUNXI_FUNCTION(0x4, "ts2")), /* ERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXD1 */
> + SUNXI_FUNCTION(0x4, "ts2")), /* SYNC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXD0 */
> + SUNXI_FUNCTION(0x4, "ts2")), /* DVLD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXCK */
> + SUNXI_FUNCTION(0x4, "ts2")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXCTL/RXDV */
> + SUNXI_FUNCTION(0x4, "ts2")), /* D1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXERR */
> + SUNXI_FUNCTION(0x4, "ts2")), /* D2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXD3 */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D3 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXD2 */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D4 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* ERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXD1 */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D5 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* SYNC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXD0 */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D6 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* DVLD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* CRS */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D7 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXCK */
> + SUNXI_FUNCTION(0x4, "sim")), /* PWREN */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXCTL/TXEN */
> + SUNXI_FUNCTION(0x4, "sim")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXERR */
> + SUNXI_FUNCTION(0x4, "sim")), /* DATA */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* CLKIN/COL */
> + SUNXI_FUNCTION(0x4, "sim")), /* RST */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* MDC */
> + SUNXI_FUNCTION(0x4, "sim")), /* DET */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac")), /* MDIO */
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* PCLK */
> + SUNXI_FUNCTION(0x3, "ts0")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* MCLK */
> + SUNXI_FUNCTION(0x3, "ts0")), /* ERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* HSYNC */
> + SUNXI_FUNCTION(0x3, "ts0")), /* SYNC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* VSYNC */
> + SUNXI_FUNCTION(0x3, "ts0")), /* DVLD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D0 */
> + SUNXI_FUNCTION(0x3, "ts0")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D1 */
> + SUNXI_FUNCTION(0x3, "ts0")), /* D1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D2 */
> + SUNXI_FUNCTION(0x3, "ts0")), /* D2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D3 */
> + SUNXI_FUNCTION(0x3, "ts0"), /* D3 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D4 */
> + SUNXI_FUNCTION(0x3, "ts0"), /* D4 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* ERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D5 */
> + SUNXI_FUNCTION(0x3, "ts0"), /* D5 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* SYNC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D6 */
> + SUNXI_FUNCTION(0x3, "ts0"), /* D6 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* DVLD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D7 */
> + SUNXI_FUNCTION(0x3, "ts"), /* D7 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* SCK */
> + SUNXI_FUNCTION(0x3, "i2c2")), /* SCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* SDA */
> + SUNXI_FUNCTION(0x3, "i2c2")), /* SDA */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "sim")), /* VPPEN */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "sim")), /* VPPPP */
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D1 */
> + SUNXI_FUNCTION(0x3, "jtag")), /* MS */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D0 */
> + SUNXI_FUNCTION(0x3, "jtag")), /* DI */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CLK */
> + SUNXI_FUNCTION(0x3, "uart0")), /* TX */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CMD */
> + SUNXI_FUNCTION(0x3, "jtag")), /* DO */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D3 */
> + SUNXI_FUNCTION(0x3, "uart0")), /* RX */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D2 */
> + SUNXI_FUNCTION(0x3, "jtag")), /* CK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out")),
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 0)), /* PG_EINT0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CMD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 1)), /* PG_EINT1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 2)), /* PG_EINT2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 3)), /* PG_EINT3 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 4)), /* PG_EINT4 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)), /* PG_EINT5 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 6)), /* PG_EINT6 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 7)), /* PG_EINT7 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)), /* PG_EINT8 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)), /* PG_EINT9 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s1"), /* SYNC */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)), /* PG_EINT10 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)), /* PG_EINT11 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s1"), /* DOUT */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)), /* PG_EINT12 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s1"), /* DIN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)), /* PG_EINT13 */
> +};
> +
> +static const struct sunxi_pinctrl_desc sun50i_h5_pinctrl_data = {
> + .pins = sun50i_h5_pins,
> + .npins = ARRAY_SIZE(sun50i_h5_pins),
> + .irq_banks = 2,
> + .irq_read_needs_mux = true
> +};
> +
> +static int sun50i_h5_pinctrl_probe(struct platform_device *pdev)
> +{
> + return sunxi_pinctrl_init(pdev,
> + &sun50i_h5_pinctrl_data);
> +}
> +
> +static const struct of_device_id sun50i_h5_pinctrl_match[] = {
> + { .compatible = "allwinner,sun50i-h5-pinctrl", },
> + {}
> +};
> +
> +static struct platform_driver sun50i_h5_pinctrl_driver = {
> + .probe = sun50i_h5_pinctrl_probe,
> + .driver = {
> + .name = "sun50i-h5-pinctrl",
> + .of_match_table = sun50i_h5_pinctrl_match,
> + },
> +};
> +builtin_platform_driver(sun50i_h5_pinctrl_driver);
This also looks very much like the H3. I'll post a patchset during the
weekend to avoid duplicating those drivers. This was initially done
for the sun5i, but it very much applies here.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/ebb21db0/attachment-0001.sig>
^ permalink raw reply
* [PATCH] net: phy: dp83867: fix irq generation
From: Florian Fainelli @ 2017-01-05 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105204807.25990-1-grygorii.strashko@ti.com>
On 01/05/2017 12:48 PM, Grygorii Strashko wrote:
> For proper IRQ generation by DP83867 phy the INT/PWDN pin has to be
> programmed as an interrupt output instead of a Powerdown input in
> Configuration Register 3 (CFG3), Address 0x001E, bit 7 INT_OE = 1. The
> current driver doesn't do this and as result IRQs will not be generated by
> DP83867 phy even if they are properly configured in DT.
>
> Hence, fix IRQ generation by properly configuring CFG3.INT_OE bit and
> ensure that Link Status Change (LINK_STATUS_CHNG_INT) and Auto-Negotiation
> Complete (AUTONEG_COMP_INT) interrupt are enabled. After this the DP83867
> driver will work properly in interrupt enabled mode.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> drivers/net/phy/dp83867.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
> index 1b63924..e84ae08 100644
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@ -29,6 +29,7 @@
> #define MII_DP83867_MICR 0x12
> #define MII_DP83867_ISR 0x13
> #define DP83867_CTRL 0x1f
> +#define DP83867_CFG3 0x1e
>
> /* Extended Registers */
> #define DP83867_RGMIICTL 0x0032
> @@ -98,6 +99,8 @@ static int dp83867_config_intr(struct phy_device *phydev)
> micr_status |=
> (MII_DP83867_MICR_AN_ERR_INT_EN |
> MII_DP83867_MICR_SPEED_CHNG_INT_EN |
> + MII_DP83867_MICR_AUTONEG_COMP_INT_EN |
> + MII_DP83867_MICR_LINK_STS_CHNG_INT_EN |
> MII_DP83867_MICR_DUP_MODE_CHNG_INT_EN |
> MII_DP83867_MICR_SLEEP_MODE_CHNG_INT_EN);
>
> @@ -214,6 +217,13 @@ static int dp83867_config_init(struct phy_device *phydev)
> }
> }
>
> + /* Enable Interrupt output INT_OE in CFG3 register */
> + if (phy_interrupt_is_valid(phydev)) {
> + val = phy_read(phydev, DP83867_CFG3);
> + val |= BIT(7);
> + phy_write(phydev, DP83867_CFG3, val);
> + }
Don't you need to clear that bit in the case phy_interrupt_is_valid()
returns false?
Other than that:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH 6/6] arm64: dts: sunxi: add support for the Orange Pi PC 2 board
From: Maxime Ripard @ 2017-01-05 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161226171156.11605-3-icenowy@aosc.xyz>
On Tue, Dec 27, 2016 at 01:11:56AM +0800, Icenowy Zheng wrote:
> From: Andre Przywara <andre.przywara@arm.com>
>
> The Orange Pi PC 2 is a typical single board computer using the
> Allwinner H5 SoC. Apart from the usual suspects it features three
> separately driven USB ports and a Gigabit Ethernet port.
> Also it has a SPI NOR flash soldered, from which the board can boot
> from. This enables the SBC to behave like a "real computer" with
> built-in firmware.
>
> Add the board specific .dts file, which includes the H5 .dtsi and
> enables the peripherals that we support so far.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 183 +++++++++++++++++++++
> 2 files changed, 184 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 1e29a5ae8282..b26bb46b934c 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,4 +1,5 @@
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> new file mode 100644
> index 000000000000..a29ca6b274bb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun50i-h5.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> + model = "Xunlong Orange Pi PC 2";
> + compatible = "xunlong,orangepi-pc2", "allwinner,sun50i-h5";
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_opc>, <&leds_r_opc>;
There's no need to declare the LED GPIO in pinctrl.
> +
> + pwr_led {
> + label = "orangepi:green:pwr";
> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + status_led {
> + label = "orangepi:red:status";
> + gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + r_gpio_keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&sw_r_opc>;
Ditto
> +
> + sw4 {
> + label = "sw4";
> + linux,code = <BTN_0>;
> + gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ehci2 {
> + status = "okay";
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
> +
> +&ir {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ir_pins_a>;
> + status = "okay";
> +};
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
Ditto
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> + cd-inverted;
Do you need both the GPIO flag and the cd-inverted one?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/59c73b72/attachment.sig>
^ permalink raw reply
* [arm:clearfog 25/65] htmldocs: drivers/net/phy/phy.c:278: warning: No description found for parameter 'speed'
From: kbuild test robot @ 2017-01-05 22:19 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git clearfog
head: a0b3b7ea35687eaa7b1836bcdbbe10daf034c621
commit: b73483caa6bece0e854d064bb931dc25f84c935e [25/65] net: phy: improve phylib correctness for non-autoneg settings
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'speed'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'duplex'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'supported'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'speed'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'duplex'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'supported'
vim +/speed +278 drivers/net/phy/phy.c
b73483ca Russell King 2017-01-05 262 break;
b73483ca Russell King 2017-01-05 263 }
b73483ca Russell King 2017-01-05 264 }
b73483ca Russell King 2017-01-05 265 }
00db8189 Andy Fleming 2005-07-30 266
b73483ca Russell King 2017-01-05 267 if (!match && !exact)
b73483ca Russell King 2017-01-05 268 match = last;
00db8189 Andy Fleming 2005-07-30 269
b73483ca Russell King 2017-01-05 270 return match;
00db8189 Andy Fleming 2005-07-30 271 }
00db8189 Andy Fleming 2005-07-30 272
b3df0da8 Randy Dunlap 2007-03-06 273 /**
b3df0da8 Randy Dunlap 2007-03-06 274 * phy_find_valid - find a PHY setting that matches the requested features mask
00db8189 Andy Fleming 2005-07-30 275 */
b73483ca Russell King 2017-01-05 276 static const struct phy_setting *
b73483ca Russell King 2017-01-05 277 phy_find_valid(int speed, int duplex, u32 supported)
00db8189 Andy Fleming 2005-07-30 @278 {
b73483ca Russell King 2017-01-05 279 unsigned long mask = supported;
00db8189 Andy Fleming 2005-07-30 280
b73483ca Russell King 2017-01-05 281 return phy_lookup_setting(speed, duplex, &mask, BITS_PER_LONG, false);
00db8189 Andy Fleming 2005-07-30 282 }
00db8189 Andy Fleming 2005-07-30 283
b3df0da8 Randy Dunlap 2007-03-06 284 /**
54da5a8b Guenter Roeck 2015-02-17 285 * phy_check_valid - check if there is a valid PHY setting which matches
54da5a8b Guenter Roeck 2015-02-17 286 * speed, duplex, and feature mask
:::::: The code at line 278 was first introduced by commit
:::::: 00db8189d984d6c51226dafbbe4a667ce9b7d5da This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.
:::::: TO: Andy Fleming <afleming@freescale.com>
:::::: CC: Jeff Garzik <jgarzik@pobox.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6421 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170106/f92d6b9a/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
From: Steve Longerbeam @ 2017-01-05 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8c09060-dd6b-f495-da7d-b1f9fad79b89@mentor.com>
On 01/04/2017 04:33 AM, Vladimir Zapolskiy wrote:
>
>> +
>> + camera: ov5642 at 3c {
> ov5642: camera at 3c
done.
>> + pwdn-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; /* SD1_DAT0 */
>> + reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>; /* SD1_DAT1 */
> Comments about SD1_* pad names are redundant.
sure, removed.
>> + status = "disabled";
> Why is it disabled here?
It's explained in the header. I don't yet have the OV5642 module for
the sabresd for testing, so it is disabled for now.
>> +
>> + mipi_camera: ov5640 at 3c {
> ov5640: camera at 3c
done.
>
>> + pwdn-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; /* SD1_DAT2 */
>> + reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; /* SD1_CLK */
> Comments about SD1_* pad names are redundant.
removed.
>> +
>> + pinctrl_ipu1_csi0: ipu1grp-csi0 {
> Please rename the node name to ipu1csi0grp.
>
> Please add new pin control groups preserving the alphanimerical order.
done and done.
Steve
^ permalink raw reply
* [PATCH V6 05/10] acpi: apei: handle SEA notification type for ARMv8
From: Baicar, Tyler @ 2017-01-05 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58594E62.3050003@arm.com>
On 12/20/2016 8:29 AM, James Morse wrote:
> Hi Tyler,
>
> On 07/12/16 21:48, Tyler Baicar wrote:
>> ARM APEI extension proposal added SEA (Synchrounous External
>> Abort) notification type for ARMv8.
>> Add a new GHES error source handling function for SEA. If an error
>> source's notification type is SEA, then this function can be registered
>> into the SEA exception handler. That way GHES will parse and report
>> SEA exceptions when they occur.
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 2acbc60..66ab3fd 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -767,6 +771,62 @@ static struct notifier_block ghes_notifier_sci = {
>> .notifier_call = ghes_notify_sci,
>> };
>>
>> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
>> +static LIST_HEAD(ghes_sea);
>> +
>> +static int ghes_notify_sea(struct notifier_block *this,
>> + unsigned long event, void *data)
>> +{
>> + struct ghes *ghes;
>> + int ret = NOTIFY_DONE;
>> +
>> + rcu_read_lock();
>> + list_for_each_entry_rcu(ghes, &ghes_sea, list) {
>> + if (!ghes_proc(ghes))
>> + ret = NOTIFY_OK;
>> + }
>> + rcu_read_unlock();
>> +
>> + return ret;
>> +}
> What stops this from being re-entrant?
>
> ghes_copy_tofrom_phs() takes the ghes_ioremap_lock_irq spinlock, but there is
> nothing to stop a subsequent instruction fetch or memory access causing another
> (maybe different) Synchronous External Abort which deadlocks trying to take the
> same lock.
>
> ghes_notify_sea() looks to be based on ghes_notify_sci(), which (if I've found
> the right part of the ACPI spec) is a level-low interrupt. spin_lock_irqsave()
> would mask interrupts so there is no risk of a different notification firing on
> the same CPU, (it looks like they are almost all ultimately an irq).
>
> NMI is the odd one out because its not maskable like this, but ghes_notify_nmi()
> has:
>> if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
>> return ret;
> To ensure there is only ever one thread poking around in this code.
>
> What happens if a system describes two GHES sources, one using an irq the other
> SEA? The SEA error can interrupt the irq error while its holding the above lock.
> I guess this is also why all the NMI code in that file is separate.
>
>
> Thanks,
>
> James
Hi James,
Let me see if I'm following you right :)
I should use spin_lock_irqsave() in ghes_notify_sea() to avoid
ghes_notify_sci() from
interrupting this process and potentially causing the deadlock?
This race condition does seem valid. We are using the same
acknowledgment for all our
HEST table entries, so our firmware will not populate more than one
entry at a time. That
gets us around this race condition.
Thanks,
Tyler
--
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 v2 09/19] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
From: Steve Longerbeam @ 2017-01-05 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <acbdc873-3166-f56d-e6d1-948becb1a57c@mentor.com>
On 01/04/2017 04:41 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> +
>> + camera: adv7180 at 21 {
> adv7180: camera at 21
done.
>>
>> + pinctrl_ipu1_csi0: ipu1grp-csi0 {
> Please rename node name to ipu1csi0grp.
done.
Steve
^ permalink raw reply
* [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC
From: Maxime Ripard @ 2017-01-05 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYQhfid3VRcaj=7as_+Zg=pX3Svp9FJ_W_Ft8nVuoZqKQ@mail.gmail.com>
On Fri, Dec 30, 2016 at 01:55:44PM +0100, Linus Walleij wrote:
> On Mon, Dec 26, 2016 at 3:33 PM, Andr? Przywara <andre.przywara@arm.com> wrote:
>
> > So while this patch technically looks correct, I was wondering if we
> > should really explore the possibility of making the whole of sunxi
> > pinctrl DT controlled.
> > I brought this up a while ago, but people weren't overly enthusiastic
> > about it, though their argument weren't really convincing to me[1].
> >
> > So:
> > As this "driver" here is basically a table linking GPIO bit settings
> > (the actual mux value) to names and every pin we care about needs to be
> > enumerated in the DT anyway, why not just add something like:
> > allwinner,pinmux = <4>;
> > to each pin(group) in the DT and get rid of this "driver" file here
> > entirely?
>
> I'm open to that if you can use pinctrl-single which is in the kernel
> for this purpose only, and is used with both OMAPs and HiSilicon.
I'm not open to that, and I'm getting tired of discussing it over and
over again. Andre, if you want to be convinced again, please read the
last discussion we had on this topic.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/98ba8d71/attachment.sig>
^ permalink raw reply
* next-20170105 build: 4 failures 3 warnings (next-20170105)
From: Stephen Rothwell @ 2017-01-05 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105195546.wnmjwh4hazqiyodf@sirena.org.uk>
Hi Mark,
On Thu, 5 Jan 2017 19:55:46 +0000 Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Jan 05, 2017 at 12:07:08PM +0000, Build bot for Mark Brown wrote:
>
> Since sometime over the Christmas vacation all arm64 configs have been
> failing to build due to:
>
> > ../arch/arm64/include/asm/setup.h:14:29: error: redefinition of 'kaslr_offset'
>
> (same error repeating a different number of times for each config).
> This is an interaction between Andrew's -current tree and Linus' tree.
> Andrew's tree has "arm64: setup: introduce kaslr_offset()"
> (1a339a14b1f2c7 in current -next) and Linus' tree has a commit
> 7ede8665f27cde7d with the same title but a modified version that went to
> Linus through Will. In the version in Andrew's tree kaslr_offset() is
> defined in asm/setup.h while in the version in Linus' tree it is
> instead defined in asm/memory.h so -next ends up with two definitions of
> that function causing the build errors.
>
> I guess the commit in Andrew's tree should be dropped now, reverting it
> fixes the builds for me.
OK, I have now dropped the initial part of akpm's -current tree that
was sent to Linus (including the above commit). Sorry for not noticing
earlier.
Andrew, this means that your tree in linux-next now contains:
a63a9bb7abd2 ipc/sem: add hysteresis
07be42f325e3 ipc/sem.c: avoid using spin_unlock_wait()
6d3a63124caa scripts/gdb: add lx-fdtdump command
138d8657d5ff kdump, vmcoreinfo: report actual value of phys_base
67dbc87b155b lib: Add CRC64 ECMA module
30daa67dc769 mm/vmstat.c: walk the zone in pageblock_nr_pages steps
d5419fdf6ed6 mm/page_owner: align with pageblock_nr pages
6eb902b75775 z3fold: fix locking issues
2fb167a08fa3 z3fold: fix header size related issues
c7f6417f13f6 z3fold: discourage use of pages that weren't compacted
8e40c9ecad02 z3fold: use per-page spinlock
9d759ab4feec mm/z3fold.c: extend compaction function
e22149b524d9 mm/z3fold.c: make pages_nr atomic
cb9a2fb0a835 mm/z3fold.c: limit first_num to the actual range of possible buddy indexes
1411714ceeee mm, page_alloc: avoid page_to_pfn() when merging buddies
794cc4aa50dc mm, page_alloc: don't convert pfn to idx when merging
8c0ff3c42376 mm-throttle-show_mem-from-warn_alloc-fix
e4974bce6cc7 mm: throttle show_mem() from warn_alloc()
4b2de28ffcd0 tmpfs: change shmem_mapping() to test shmem_aops
1143ed06c725 kernel-watchdog-prevent-false-hardlockup-on-overloaded-system-fix
6904a50482ee kernel/watchdog: prevent false hardlockup on overloaded system
04a26c045475 block: restore /proc/partitions to not display non-partitionable removable devices
409d7387f7be ocfs2: fix crash caused by stale lvb with fsdlm plugin
27040ecd9fbb ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix
c19202b8a963 ocfs2: old mle put and release after the function dlm_add_migration_mle called
d82c60f3a069 scripts/spelling.txt: add several more common spelling mistakes
af85e2db2cba arm: arch/arm/include/asm/page.h needs personality.h
3da3cb66bb1b mm/thp/pagecache/collapse: free the pte page table on collapse for thp page cache.
3180061bc2fd mm/thp/pagecache: only withdraw page table after a successful deposit
(merge linux-next - akpm stuff)
4453f4fde106 scripts/spelling.txt: add "followings" pattern and fix typo instances
f1c251fd2f4a scripts/spelling.txt: add "therfore" pattern and fix typo instances
09029516eb46 scripts/spelling.txt: add "overwriten" pattern and fix typo instances
a1d75390cb06 scripts/spelling.txt: add "overwritting" pattern and fix typo instances
174def646afe scripts/spelling.txt: add "deintialize(d)" pattern and fix typo instances
a3475e364975 scripts/spelling.txt: add "disassocation" pattern and fix typo instances
f8fa89870426 scripts/spelling.txt: add "omited" pattern and fix typo instances
a907cffe94c0 scripts/spelling.txt: add "explictely" pattern and fix typo instances
382a878623a8 scripts/spelling.txt: add "applys" pattern and fix typo instances
b349d54c456a scripts/spelling.txt: add "configuartion" pattern and fix typo instances
38bfb6e670f4 scripts/spelling.txt: add "overrided" pattern and fix typo instances
5453cfe4dc41 scripts/spelling.txt: add "overide" pattern and fix typo instances
4ad56706176e scripts/spelling.txt: add "disble(d)" pattern and fix typo instances
342f1c20e5c5 scripts/spelling.txt: add "comsume(r)" pattern and fix typo instances
4787ac5086e0 scripts/spelling.txt: add "intialise(d)" pattern and fix typo instances
46283934f6ae scripts/spelling.txt: add "initialiazation" pattern and fix typo instances
df8e7e0a5bc4 scripts/spelling.txt: add "intialization" pattern and fix typo instances
2f336b08f6f0 scripts/spelling.txt: add "unneded" pattern and fix typo instances
33faac7f1266 scripts/spelling.txt: add "neded" pattern and fix typo instances
c0c9925ac473 scripts/spelling.txt: add "againt" pattern and fix typo instances
f6efcac2efe0 scripts/spelling.txt: add "embeded" pattern and fix typo instances
7590c4f7f34b scripts/spelling.txt: add "varible" pattern and fix typo instances
36b857060ad7 scripts/spelling.txt: add "efective" pattern and fix typo instances
268f025aa99f scripts/spelling.txt: add "algined" pattern and fix typo instances
9fc9398d752e scripts/spelling.txt: add "aligment" pattern and fix typo instances
7b2467807cbc scripts/spelling.txt: add "partiton" pattern and fix typo instances
fea25f1f9e37 scripts/spelling.txt: add "an one" pattern and fix typo instances
84860c6996c9 scripts/spelling.txt: add "an union" pattern and fix typo instances
a9a1e595ac30 scripts/spelling.txt: add "an user" pattern and fix typo instances
4bde980b9c4a scripts/spelling.txt: add "swithc" pattern and fix typo instances
f19ed214ee17 scripts/spelling.txt: add "swith" pattern and fix typo instances
0f401b986050 reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr-checkpatch-fixes
6bfd1dd54e38 idr: support storing NULL in the IDR
9b54b6ba4a61 Reimplement IDR and IDA using the radix tree
6dde86413add fs: add i_blocksize()
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH 1/2] ARM: dts: da850: Add usb device node
From: David Lechner @ 2017-01-05 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165920.29809-2-ahaslam@baylibre.com>
Hi Sekhar,
On 11/21/2016 10:59 AM, Axel Haslam wrote:
> Add the usb1 device node for the da850 soc.
> This will allow boards to use the usb1 port
> when booting through DT.
>
> Signed-off-by: Axel Haslam <ahaslam@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 1bb1f6d..fbd50d6 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -406,6 +406,14 @@
> >;
> status = "disabled";
> };
> + usb1: usb at 225000 {
> + compatible = "ti,da830-ohci";
> + reg = <0x225000 0x1000>;
> + interrupts = <59>;
> + phys = <&usb_phy 1>;
> + phy-names = "usb-phy";
> + status = "disabled";
> + };
> gpio: gpio at 226000 {
> compatible = "ti,dm6441-gpio";
> gpio-controller;
>
This patch can be pickup up now. I have just tested with next-20171015 +
linux-davinci/master.
^ permalink raw reply
* [PATCHv2 0/2] Memblock cleanup plus memory removal fix
From: Laura Abbott @ 2017-01-05 23:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v2 of the series to make sanity_check_meminfo (renamed in this series)
more readable and less error prone and fix an existing bug. v1 failed in that it
re-introduced a previously fixed bug. Hopefully this version does better.
As a reminder, During the course of
https://marc.info/?l=linux-arm-kernel&m=148145259511248, Grygorii Strashko
reminded me of another issue where I proposed a patch but never followed up on
it. The patch in
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/296978.html
did some cleanup and renaming of sanity_check_meminfo. I think this makes the
code more readable so I'd like to resurect it and rebase my fix
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/474060.html
on top of it.
Laura Abbott (2):
arm: Cleanup sanity_check_meminfo
arm: Adjust memory boundaries after reservations
arch/arm/kernel/setup.c | 12 ++++++++--
arch/arm/mm/mmu.c | 62 +++++++++++++++++--------------------------------
arch/arm/mm/nommu.c | 8 +++----
3 files changed, 35 insertions(+), 47 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCHv2 1/2] arm: Cleanup sanity_check_meminfo
From: Laura Abbott @ 2017-01-05 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483657274-11346-1-git-send-email-labbott@redhat.com>
The logic for sanity_check_meminfo has become difficult to
follow. Clean up the code so it's more obvious what the code
is actually trying to do. Additionally, meminfo is now removed
so rename the function to better describe it's purpose.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v2: Fixed code so b9a019899f61 ("ARM: 8590/1: sanity_check_meminfo():
avoid overflow on vmalloc_limit") should stay fixed. The casting and assignment
still seem ugly. Also corrected the size for memblock_remove with
!CONFIG_HIGHMEM (found by inspection, memblock was handling it properly).
---
arch/arm/kernel/setup.c | 4 +--
arch/arm/mm/mmu.c | 65 ++++++++++++++++++-------------------------------
arch/arm/mm/nommu.c | 8 +++---
3 files changed, 30 insertions(+), 47 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 34e3f3c..8a8051c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -81,7 +81,7 @@ __setup("fpe=", fpe_setup);
extern void init_default_cache_policy(unsigned long);
extern void paging_init(const struct machine_desc *desc);
extern void early_paging_init(const struct machine_desc *);
-extern void sanity_check_meminfo(void);
+extern void adjust_lowmem_bounds(void);
extern enum reboot_mode reboot_mode;
extern void setup_dma_zone(const struct machine_desc *desc);
@@ -1093,7 +1093,7 @@ void __init setup_arch(char **cmdline_p)
setup_dma_zone(mdesc);
xen_early_init();
efi_init();
- sanity_check_meminfo();
+ adjust_lowmem_bounds();
arm_memblock_init(mdesc);
early_ioremap_reset();
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4001dd1..ce5123b 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1152,13 +1152,11 @@ early_param("vmalloc", early_vmalloc);
phys_addr_t arm_lowmem_limit __initdata = 0;
-void __init sanity_check_meminfo(void)
+void __init adjust_lowmem_bounds(void)
{
phys_addr_t memblock_limit = 0;
- int highmem = 0;
u64 vmalloc_limit;
struct memblock_region *reg;
- bool should_use_highmem = false;
/*
* Let's use our own (unoptimized) equivalent of __pa() that is
@@ -1172,43 +1170,19 @@ void __init sanity_check_meminfo(void)
for_each_memblock(memory, reg) {
phys_addr_t block_start = reg->base;
phys_addr_t block_end = reg->base + reg->size;
- phys_addr_t size_limit = reg->size;
- if (reg->base >= vmalloc_limit)
- highmem = 1;
- else
- size_limit = vmalloc_limit - reg->base;
-
- if (!IS_ENABLED(CONFIG_HIGHMEM) || cache_is_vipt_aliasing()) {
-
- if (highmem) {
- pr_notice("Ignoring RAM at %pa-%pa (!CONFIG_HIGHMEM)\n",
- &block_start, &block_end);
- memblock_remove(reg->base, reg->size);
- should_use_highmem = true;
- continue;
- }
-
- if (reg->size > size_limit) {
- phys_addr_t overlap_size = reg->size - size_limit;
-
- pr_notice("Truncating RAM at %pa-%pa",
- &block_start, &block_end);
- block_end = vmalloc_limit;
- pr_cont(" to -%pa", &block_end);
- memblock_remove(vmalloc_limit, overlap_size);
- should_use_highmem = true;
- }
- }
-
- if (!highmem) {
- if (block_end > arm_lowmem_limit) {
- if (reg->size > size_limit)
- arm_lowmem_limit = vmalloc_limit;
- else
- arm_lowmem_limit = block_end;
- }
+ if (reg->base < vmalloc_limit) {
+ if (block_end > arm_lowmem_limit)
+ /*
+ * Compare as u64 to ensure vmalloc_limit does
+ * not get truncated. block_end should always
+ * fit in phys_addr_t so there should be no
+ * issue with assignment.
+ */
+ arm_lowmem_limit = min_t(u64,
+ vmalloc_limit,
+ block_end);
/*
* Find the first non-pmd-aligned page, and point
@@ -1233,9 +1207,6 @@ void __init sanity_check_meminfo(void)
}
}
- if (should_use_highmem)
- pr_notice("Consider using a HIGHMEM enabled kernel.\n");
-
high_memory = __va(arm_lowmem_limit - 1) + 1;
/*
@@ -1248,6 +1219,18 @@ void __init sanity_check_meminfo(void)
if (!memblock_limit)
memblock_limit = arm_lowmem_limit;
+ if (!IS_ENABLED(CONFIG_HIGHMEM) || cache_is_vipt_aliasing()) {
+ if (memblock_end_of_DRAM() > arm_lowmem_limit) {
+ phys_addr_t end = memblock_end_of_DRAM();
+
+ pr_notice("Ignoring RAM at %pa-%pa\n",
+ &memblock_limit, &end);
+ pr_notice("Consider using a HIGHMEM enabled kernel.\n");
+
+ memblock_remove(memblock_limit, end - memblock_limit);
+ }
+ }
+
memblock_set_current_limit(memblock_limit);
}
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967..13a25d6 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -85,7 +85,7 @@ static unsigned long irbar_read(void)
}
/* MPU initialisation functions */
-void __init sanity_check_meminfo_mpu(void)
+void __init adjust_lowmem_bounds_mpu(void)
{
phys_addr_t phys_offset = PHYS_OFFSET;
phys_addr_t aligned_region_size, specified_mem_size, rounded_mem_size;
@@ -274,7 +274,7 @@ void __init mpu_setup(void)
}
}
#else
-static void sanity_check_meminfo_mpu(void) {}
+static void adjust_lowmem_bounds_mpu(void) {}
static void __init mpu_setup(void) {}
#endif /* CONFIG_ARM_MPU */
@@ -295,10 +295,10 @@ void __init arm_mm_memblock_reserve(void)
#endif
}
-void __init sanity_check_meminfo(void)
+void __init adjust_lowmem_bounds(void)
{
phys_addr_t end;
- sanity_check_meminfo_mpu();
+ adjust_lowmem_bounds_mpu();
end = memblock_end_of_DRAM();
high_memory = __va(end - 1) + 1;
memblock_set_current_limit(end);
--
2.7.4
^ permalink raw reply related
* [PATCHv2 2/2] arm: Adjust memory boundaries after reservations
From: Laura Abbott @ 2017-01-05 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483657274-11346-1-git-send-email-labbott@redhat.com>
adjust_lowmem_bounds is responsible for setting up the boundary for
lowmem/hihgmme. This needs to be setup before memblock reservations can
occur. At the time memblock reservations can occur, memory can also be
removed from the system. The lowmem/highmem boundary and end of memory
may be affected by this but it is currently not recalculated. On some
systems this may be harmless, on o thers this may result in incorrect
ranges being passed to the main memory allocator. Correct this by
recalculating the lowmem/highmem boundary after all reservations have
been made.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v2: Rebased for changes in sanity_check_meminfo cleanup
---
arch/arm/kernel/setup.c | 8 ++++++++
arch/arm/mm/mmu.c | 9 ++++++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 8a8051c..4625115 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1093,8 +1093,16 @@ void __init setup_arch(char **cmdline_p)
setup_dma_zone(mdesc);
xen_early_init();
efi_init();
+ /*
+ * Make sure the calcualtion for lowmem/highmem is set appropriately
+ * before reserving/allocating any mmeory
+ */
adjust_lowmem_bounds();
arm_memblock_init(mdesc);
+ /*
+ * Memory may have been removed so recalculate the bounds.
+ */
+ adjust_lowmem_bounds();
early_ioremap_reset();
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index ce5123b..7ca6910 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1157,6 +1157,7 @@ void __init adjust_lowmem_bounds(void)
phys_addr_t memblock_limit = 0;
u64 vmalloc_limit;
struct memblock_region *reg;
+ phys_addr_t lowmem_limit = 0;
/*
* Let's use our own (unoptimized) equivalent of __pa() that is
@@ -1173,14 +1174,14 @@ void __init adjust_lowmem_bounds(void)
if (reg->base < vmalloc_limit) {
- if (block_end > arm_lowmem_limit)
+ if (block_end > lowmem_limit)
/*
* Compare as u64 to ensure vmalloc_limit does
* not get truncated. block_end should always
* fit in phys_addr_t so there should be no
* issue with assignment.
*/
- arm_lowmem_limit = min_t(u64,
+ lowmem_limit = min_t(u64,
vmalloc_limit,
block_end);
@@ -1201,12 +1202,14 @@ void __init adjust_lowmem_bounds(void)
if (!IS_ALIGNED(block_start, PMD_SIZE))
memblock_limit = block_start;
else if (!IS_ALIGNED(block_end, PMD_SIZE))
- memblock_limit = arm_lowmem_limit;
+ memblock_limit = lowmem_limit;
}
}
}
+ arm_lowmem_limit = lowmem_limit;
+
high_memory = __va(arm_lowmem_limit - 1) + 1;
/*
--
2.7.4
^ permalink raw reply related
* [PATCHv2 1/5] clk: mvebu: support for 98DX3236 SoC
From: Chris Packham @ 2017-01-05 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105135302.GB25333@leverpostej>
On 06/01/17 03:01, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 04:36:37PM +1300, Chris Packham wrote:
>> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
>> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
>>
>> The clock gating options are a subset of those on the Armada XP.
>>
>> The core clock divider is different to the Armada XP also.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>> Changes in v2:
>> - Update devicetree binding documentation for new compatible string
>>
>> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
>> drivers/clk/mvebu/Makefile | 2 +-
>> drivers/clk/mvebu/armada-xp.c | 42 +++++
>> drivers/clk/mvebu/clk-cpu.c | 33 +++-
>> drivers/clk/mvebu/mv98dx3236-corediv.c | 207 +++++++++++++++++++++
>> 5 files changed, 281 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/clk/mvebu/mv98dx3236-corediv.c
>
>
> It looks like you also need to update
> Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt for the
> addition of "marvell,mv98dx3236-corediv-clock".
Will do.
>
>>
>> diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
>> index 99c214660bdc..7f28506eaee7 100644
>> --- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
>> +++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
>> @@ -3,6 +3,7 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms
>> Required properties:
>> - compatible : shall be one of the following:
>> "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
>> + "marvell,mv98dx3236-cpu-clock" - cpu clocks for 98DX3236 SoC
>> - reg : Address and length of the clock complex register set, followed
>> by address and length of the PMU DFS registers
>> - #clock-cells : should be set to 1.
>
> [...]
>
>> +static void __init mv98dx3236_corediv_clk_init(struct device_node *node)
>> +{
>> + struct clk_init_data init;
>> + struct clk_corediv *corediv;
>> + struct clk **clks;
>> + void __iomem *base;
>> + const __be32 *off;
>> + const char *parent_name;
>> + const char *clk_name;
>> + int len;
>> + struct device_node *dfx_node;
>> +
>> + dfx_node = of_parse_phandle(node, "base", 0);
>> + if (WARN_ON(!dfx_node))
>
> What's going on here? The existing bingings don't mention a "base"
> phandle, and nothing was added to describe it.
>
>> + return;
>> +
>> + off = of_get_property(node, "reg", &len);
>> + if (WARN_ON(!off))
>> + return;
>
> Please don't use of_get_property directly; generally you should use the
> existing higher-level helpers like of_proeprty_read_u32().
>
>> +
>> + base = of_iomap(dfx_node, 0);
>> + if (WARN_ON(!base))
>> + return;
>> +
>> + of_node_put(dfx_node);
>> +
>> + parent_name = of_clk_get_parent_name(node, 0);
>> +
>> + clk_data.clk_num = 1;
>> +
>> + /* clks holds the clock array */
>> + clks = kcalloc(clk_data.clk_num, sizeof(struct clk *),
>> + GFP_KERNEL);
>> + if (WARN_ON(!clks))
>> + goto err_unmap;
>> + /* corediv holds the clock specific array */
>> + corediv = kcalloc(clk_data.clk_num, sizeof(struct clk_corediv),
>> + GFP_KERNEL);
>> + if (WARN_ON(!corediv))
>> + goto err_free_clks;
>> +
>> + spin_lock_init(&corediv->lock);
>> +
>> + of_property_read_string_index(node, "clock-output-names",
>> + 0, &clk_name);
>> +
>> + init.num_parents = 1;
>> + init.parent_names = &parent_name;
>> + init.name = clk_name;
>> + init.ops = &ops;
>> + init.flags = 0;
>> +
>> + corediv[0].reg = (void *)((int)base + be32_to_cpu(*off));
>
> I don't understand this, but I guess this has something to do with that
> base phandle. Is the corediv clock a sub-component of some "base" clock?
> I don't think this binding is the best way of describing that.
Actually once I've got things setup correctly via the dts I only need
some minor modification to mvebu/clk-corediv.c to handle the differences
in the bit fields used.
>
> Thanks,
> Mark.
>
^ permalink raw reply
* [PATCH] ARM: hw_breakpoint: blacklist Scorpion CPUs
From: Stephen Boyd @ 2017-01-05 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483637556-3974-1-git-send-email-mark.rutland@arm.com>
On 01/05, Mark Rutland wrote:
> On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
> undefined instruction trap within write_wb_reg. This is because Scorpion
> CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
> the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
> watchpoint registers are treated as undefined.
>
> It's possible to trigger similar crashes later on from userspace, by
> requesting the kernel to install a breakpoint or watchpoint, as we can
> go idle at any point between the reset of the debug registers and their
> later use. This has always been the case.
>
> Given that this has always been broken, no-one has complained until now,
> and there is no clear workaround, disable hardware breakpoints and
> watchpoints on Scorpion to avoid these issues.
I believe the workaround is to read DBGPRSR after exit from WFI?
I'm fine with the blacklisting approach though.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reported-by: Linus Walleij <linus.walleij@linaro.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: stable at vger.kernel.org
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Russell King - ARM Linux @ 2017-01-05 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com>
On Mon, Nov 28, 2016 at 09:54:28AM -0800, Florian Fainelli wrote:
> If we start supporting generic "enable", "disable" type of properties
> with values that map directly to register definitions of the HW, we
> leave too much room for these properties to be utilized to implement a
> specific policy, and this is not acceptable.
Another concern with this patch is that the existing phylib "set_eee"
code is horribly buggy - it just translates the modes from userspace
into the register value and writes them directly to the register with
no validation. So it's possible to set modes in the register that the
hardware doesn't support, and have them advertised to the link partner.
I have a patch which fixes that, restricting (as we do elsewhere) the
advert according to the EEE supported capabilities retrieved from the
PCS - maybe the problem here is that the PCS doesn't support support
EEE in 1000baseT mode?
Out of interest, which PHY is used on this platform?
On the SolidRun boards, they're using AR8035, and have suffered this
occasional link drop problem. What has been found is that it seems to
be to do with the timing parameters, and it seemed to only be 1000bT
that was affected. I don't remember off hand exactly which or what
the change was they made to stabilise it though, but I can probabily
find out tomorrow.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 2/5] drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
From: André Przywara @ 2017-01-05 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105175746.fq6crpc3krz7tzxi@lukather>
On 05/01/17 17:57, Maxime Ripard wrote:
> Hi Rob,
>
> On Wed, Jan 04, 2017 at 08:07:50AM -0600, Rob Herring wrote:
>> On Mon, Jan 02, 2017 at 11:03:43PM +0000, Andre Przywara wrote:
>>> From: Maxime Ripard <maxime.ripard@free-electrons.com>
>>>
>>> Unlike the A64 user manual reports, the third MMC controller on the
>>> A64 (and the only one capable of 8-bit HS400 eMMC transfers) has a
>>> DMA buffer size limit of 8KB (much like the very old Allwinner SoCs).
>>> This does not affect the other two controllers, so introduce a new
>>> DT compatible string to let the driver use different settings for that
>>> particular device. This will also help to enable the high-speed transfer
>>> modes of that controller later.
>>>
>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
>>> drivers/mmc/host/sunxi-mmc.c | 7 +++++++
>>> 2 files changed, 8 insertions(+)
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> Some kind of a digression on this: we have three MMC controllers on
> this SoC. Like this patch shows, the third one is clearly different,
> and supports both more modes, a wider bus, and specific quirks. We
> need a new compatible for this one, everything's perfect.
>
> However, the other two are mostly the same, but seems to need
> different tuning parameters to get more performances out of the
> controller (but this is unclear yet). How do we usually deal with
> that?
I guess you wanted to hear Rob's opinion ;-), but "get more performance"
sounds like we add one (or more) properties to tune those values.
If I get this right, it works with default values, but is sub-optimal?
Cheers,
Andre.
^ permalink raw reply
* [PATCH v2 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Russell King - ARM Linux @ 2017-01-06 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-4-f.fainelli@gmail.com>
On Thu, Jan 05, 2017 at 11:29:52AM -0800, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
> dsa: Document new binding"). The legacy binding node is kept included, but is
> marked disabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Booted here on clearfog, and tested traffic passes between two lan
ports, and a lan port and the cpu port... and generally still seems
to work as a switch. All seems well on the face of it.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
> ---
> arch/arm/boot/dts/armada-388-clearfog.dts | 65 +++++++++++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
> index 71ce201c903e..40ec6d768669 100644
> --- a/arch/arm/boot/dts/armada-388-clearfog.dts
> +++ b/arch/arm/boot/dts/armada-388-clearfog.dts
> @@ -351,6 +351,8 @@
> };
>
> dsa at 0 {
> + status = "disabled";
> +
> compatible = "marvell,dsa";
> dsa,ethernet = <ð1>;
> dsa,mii-bus = <&mdio>;
> @@ -444,3 +446,66 @@
> status = "disabled";
> };
> };
> +
> +&mdio {
> + status = "okay";
> +
> + switch at 4 {
> + compatible = "marvell,mv88e6085";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <4>;
> + pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
> + pinctrl-names = "default";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + label = "lan5";
> + };
> +
> + port at 1 {
> + reg = <1>;
> + label = "lan4";
> + };
> +
> + port at 2 {
> + reg = <2>;
> + label = "lan3";
> + };
> +
> + port at 3 {
> + reg = <3>;
> + label = "lan2";
> + };
> +
> + port at 4 {
> + reg = <4>;
> + label = "lan1";
> + };
> +
> + port at 5 {
> + reg = <5>;
> + label = "cpu";
> + ethernet = <ð1>;
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> +
> + port at 6 {
> + /* 88E1512 external phy */
> + reg = <6>;
> + label = "lan6";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> +};
> --
> 2.9.3
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCHv2 2/2] arm: Adjust memory boundaries after reservations
From: Russell King - ARM Linux @ 2017-01-06 0:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483657274-11346-3-git-send-email-labbott@redhat.com>
Only comments are to do with the comments...
On Thu, Jan 05, 2017 at 03:01:14PM -0800, Laura Abbott wrote:
>
> adjust_lowmem_bounds is responsible for setting up the boundary for
> lowmem/hihgmme. This needs to be setup before memblock reservations can
highmem
> occur. At the time memblock reservations can occur, memory can also be
> removed from the system. The lowmem/highmem boundary and end of memory
> may be affected by this but it is currently not recalculated. On some
> systems this may be harmless, on o thers this may result in incorrect
others
> ranges being passed to the main memory allocator. Correct this by
> recalculating the lowmem/highmem boundary after all reservations have
> been made.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v2: Rebased for changes in sanity_check_meminfo cleanup
> ---
> arch/arm/kernel/setup.c | 8 ++++++++
> arch/arm/mm/mmu.c | 9 ++++++---
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8a8051c..4625115 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -1093,8 +1093,16 @@ void __init setup_arch(char **cmdline_p)
> setup_dma_zone(mdesc);
> xen_early_init();
> efi_init();
> + /*
> + * Make sure the calcualtion for lowmem/highmem is set appropriately
calculation
> + * before reserving/allocating any mmeory
> + */
> adjust_lowmem_bounds();
> arm_memblock_init(mdesc);
> + /*
> + * Memory may have been removed so recalculate the bounds.
> + */
Single line comments should be... /* blah */
> + adjust_lowmem_bounds();
>
> early_ioremap_reset();
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index ce5123b..7ca6910 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1157,6 +1157,7 @@ void __init adjust_lowmem_bounds(void)
> phys_addr_t memblock_limit = 0;
> u64 vmalloc_limit;
> struct memblock_region *reg;
> + phys_addr_t lowmem_limit = 0;
>
> /*
> * Let's use our own (unoptimized) equivalent of __pa() that is
> @@ -1173,14 +1174,14 @@ void __init adjust_lowmem_bounds(void)
>
>
> if (reg->base < vmalloc_limit) {
> - if (block_end > arm_lowmem_limit)
> + if (block_end > lowmem_limit)
> /*
> * Compare as u64 to ensure vmalloc_limit does
> * not get truncated. block_end should always
> * fit in phys_addr_t so there should be no
> * issue with assignment.
> */
> - arm_lowmem_limit = min_t(u64,
> + lowmem_limit = min_t(u64,
> vmalloc_limit,
> block_end);
>
> @@ -1201,12 +1202,14 @@ void __init adjust_lowmem_bounds(void)
> if (!IS_ALIGNED(block_start, PMD_SIZE))
> memblock_limit = block_start;
> else if (!IS_ALIGNED(block_end, PMD_SIZE))
> - memblock_limit = arm_lowmem_limit;
> + memblock_limit = lowmem_limit;
> }
>
> }
> }
>
> + arm_lowmem_limit = lowmem_limit;
> +
> high_memory = __va(arm_lowmem_limit - 1) + 1;
>
> /*
> --
> 2.7.4
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
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