* [PATCH 15/16] ARM: mvebu: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Jason Cooper <jason@lakedaemon.net>
CC: Andrew Lunn <andrew@lunn.ch>
CC: Gregory Clement <gregory.clement@free-electrons.com>
CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-mvebu/board-v7.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index ccca951..d7014a3 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -41,13 +41,9 @@ static void __iomem *scu_base;
*/
static void __init mvebu_scu_enable(void)
{
- struct device_node *np =
- of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
- if (np) {
- scu_base = of_iomap(np, 0);
+ scu_base = of_scu_get_base();
+ if (!IS_ERR(scu_base))
scu_enable(scu_base);
- of_node_put(np);
- }
}
void __iomem *mvebu_get_scu_base(void)
--
2.7.4
^ permalink raw reply related
* [PATCH 16/16] ARM: zx: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-zx/platsmp.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-zx/platsmp.c b/arch/arm/mach-zx/platsmp.c
index 0297f92..2788c34 100644
--- a/arch/arm/mach-zx/platsmp.c
+++ b/arch/arm/mach-zx/platsmp.c
@@ -44,13 +44,11 @@ static void __iomem *scu_base;
void __init zx_smp_prepare_cpus(unsigned int max_cpus)
{
struct device_node *np;
- unsigned long base = 0;
void __iomem *aonsysctrl_base;
void __iomem *sys_iram;
- base = scu_a9_get_base();
- scu_base = ioremap(base, SZ_256);
- if (!scu_base) {
+ scu_base = of_scu_get_base();
+ if (IS_ERR(scu_base)) {
pr_err("%s: failed to map scu\n", __func__);
return;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v1] ARM:dmaengine:sun6i:fix the uninitialized value for v_lli
From: Vinod Koul @ 2016-11-14 5:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102053112.GA8109@arx-xi>
On Wed, Nov 02, 2016 at 01:31:12PM +0800, Axl-zhang wrote:
> dma_pool_alloc does not initialize the value of the newly allocated
> block for the v_lli, and the uninitilize value make the tests failed
> which is on pine64 with dmatest.
> we can fix it just change the "|=" to "=" for the v_lli->cfg.
Applied after fixing the title. We dont need ARM.
Also spaces after each tag please..
--
~Vinod
^ permalink raw reply
* [PATCH v10 03/11] remoteproc: Update Kconfig setup to 'depends on REMOTEPROC'
From: Vinod Koul @ 2016-11-14 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103212439.GS25787@tuxbot>
On Thu, Nov 03, 2016 at 02:24:39PM -0700, Bjorn Andersson wrote:
> On Sat 08 Oct 05:52 PDT 2016, Peter Griffin wrote:
>
> > Make REMOTEPROC core a selectable kconfig option, and update
> > remoteproc client drivers to 'depends on' the core. This avoids
> > some nasty Kconfig recursive dependency issues. Also when using
> > menuconfig client drivers will be hidden until the core has been
> > enabled.
> >
> > Documentation/kbuild/kconfig-language.txt:
> >
> > Note:
> > select should be used with care. select will force
> > a symbol to a value without visiting the dependencies.
> > By abusing select you are able to select a symbol FOO even
> > if FOO depends on BAR that is not set.
> > In general use select only for non-visible symbols
> > (no prompts anywhere) and for symbols with no dependencies.
> > That will limit the usefulness but on the other hand avoid
> > the illegal configurations all over.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>
> Sorry, I missed this patch in the set - but spotted it in linux-next.
>
> I still don't like the change, but remoteproc has dependencies so I
> guess I have to pick it until we fix that.
>
> It's however not okay to take this patch through the DMA tree, as it
> effectively stops me from introducing any changes in the rproc tree.
> Further more, it's not based on v4.9, so it currently introduces another
> Kconfig dependency problem - that I can't fix in my tree without
> conflicting with Vinod's.
>
>
> So, Vinod, can you please drop this patch from your tree? I'll pick it
> up for now.
Sorry for the delay, b/w KS/LPC and travel, was slow on email.
I have dropped this one now..
--
~Vinod
^ permalink raw reply
* [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Vinod Koul @ 2016-11-14 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107135735.GA27280@griffinp-ThinkPad-X1-Carbon-2nd>
On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> >
> > As you now make changes to the entire remoteproc Kconfig file, rather
> > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > without providing Linus with a messy merge conflict.
> >
> > So the remoteproc parts now has to go through my tree.
>
> OK, I think the best approach is for Vinod to create an immutable
> branch with the entire fdma series on, and then both of you merge that branch into
> your respective trees.
my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
tag, please do let me know
>
> That way there won't be any conflicts and you can both accept further changes
> for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
> because they have dependencies on each other.
>
> I will send a v11 series in a moment which includes the feedback in this email
> and also include the additional fixes which Vinod has applied since the driver
> has been in linux-next.
WHY.. Stuff is already merged twice! Please send updated on top of already
merged code! This is how kernel developement is done...
--
~Vinod
^ permalink raw reply
* [PATCH v11 00/14] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
From: Vinod Koul @ 2016-11-14 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478542665-17089-1-git-send-email-peter.griffin@linaro.org>
On Mon, Nov 07, 2016 at 06:17:31PM +0000, Peter Griffin wrote:
> Hi Vinod and Bjorn,
>
> This patchset adds support for the Flexible Direct Memory Access (FDMA) core
> found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
> with a dedicated firmware. It is a general purpose DMA controller supporting
> 16 independent channels and data can be moved from memory to memory or between
> memory and paced latency critical real time targets.
>
> In reponse to Bjorn latest mail here https://lkml.org/lkml/2016/11/7/425 and
> here https://patchwork.kernel.org/patch/9368157/ I have created a v11
> incorporating the minor API update, and removed the unrelated change.
>
> As tthis series has been in linux-next for a while, some additional fixes
> have been submitted and applied by Vinod. I have included these as part of
> the v11 series as well.
>
> I believe the best route as described here
> https://www.spinics.net/lists/arm-kernel/msg541026.htmlforward is for Vinod
> to apply the whole series on an immutable branch which is then merged into
> both the dma and remoteproc trees.
As I said earlier and just to make it clear, am not taking this one. Please
send updates on top of already applied stuff
--
~Vinod
^ permalink raw reply
* [PATCH v3 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC.
From: Vinod Koul @ 2016-11-14 5:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107181457.GA3619@arx12>
On Tue, Nov 08, 2016 at 02:14:57AM +0800, Hao Zhang wrote:
> This adds documentation of the sun50i a64 dma binding compatible.
Please send a cover letter for patch series, and please post the series as a
thread (hint: git send-email does that quite well).
Lastly where is patch2/3??
--
~Vinod
^ permalink raw reply
* [PATCH V4] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Shawn Guo @ 2016-11-14 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478609017-2415-1-git-send-email-aford173@gmail.com>
On Tue, Nov 08, 2016 at 06:43:37AM -0600, aford173 at gmail.com wrote:
> From: Adam Ford <aford173@gmail.com>
>
> The system on module (SOM) specific portions are in the .dtsi
> while the baseboard specific portions are in the .dts file.
>
> V4: Forgot to fix the Wlcore property list and child node
> V3: Forgot to remove push buttons in V2, and change the
> enable-sdio-wakup to wakeup-source
> V2: Fix small bug and update style for 4.9 Kernel
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
<snip>
> + leds {
> + compatible = "gpio-leds";
> +
> + gen_led0 {
Please use hyphen instead of underscore in node name.
> + label = "cpu0";
> + gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "cpu0";
> + };
> +
> + gen_led1 {
> + label = "cpu1";
> + gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "cpu1";
> + };
> +
> + gen_led2 {
> + label = "heartbeat";
> + gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> +
> + gen_led3 {
> + label = "Always On";
> + gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "default-on";
> + };
> + };
<snip>
> + backlight_lcd: backlight-lcd {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_backlight>;
> + enable-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
> + pwms = <&pwm3 0 5000000>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> + };
> +
> +
One newline is enough.
> + lcd_display: display at di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "rgb565";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcd>;
> + status = "okay";
> +
> + display-timings {
> + native-mode = <&type15_timing>;
Have a newline between property list and child node.
> + type15_timing: type_15 {
Can we have a better node name for this? Also hyphen should be used in
node name.
> + clock-frequency = <9000000>;
> + hactive = <480>;
> + vactive = <272>;
> + hfront-porch = <3>;
> + hback-porch = <2>;
> + hsync-len = <42>;
> + vback-porch = <3>;
> + vfront-porch = <2>;
> + vsync-len = <11>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + de-active = <1>;
> + pixelclk-active = <0>;
> + };
> + };
> +
> + port at 0 {
> + reg = <0>;
> + display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + display_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> +
> + panel: panel {
> + compatible = "innolux,at043tn24", "simple-panel";
> + enable-gpios = <&gpio4 17 GPIO_ACTIVE_HIGH>;
> + backlight = <&backlight_lcd>;
Have a newline between property list and child node.
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&display_out>;
> + };
> + };
> + };
> +};
> +
> +&ipu1_di0_disp0 {
> + remote-endpoint = <&display_in>;
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm3>;
> + status = "okay";
> +};
> +
> +
Drop one newline.
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3>;
> + status = "okay";
> +};
> +
> +&usbh1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbh1>;
> + vbus-supply = <®_usb_h1_vbus>;
> + status = "okay";
> +};
> +
> +&usbh2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbh2>;
> + phy_type = "hsic";
> + disable-over-current;
> + status = "okay";
> +};
> +
> +&usbotg {
> + vbus-supply = <®_usb_otg_vbus>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbotg>;
> + disable-over-current;
> + status = "okay";
> +};
> +
> +&fec {
Please sort these labeled nodes alphabetically. The iomuxc can be an
exception, and we usually put it at the end of file to make the rest
easy to read.
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet>;
> + phy-mode = "rmii";
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
> + no-1-8-v;
> + keep-power-in-suspend;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + touchscreen: tsc2004 at 48 {
> + compatible = "ti,tsc2004";
> + vio-supply = <®_3v3>;
> + reg = <0x48>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_touchscreen>;
> + reset-gpios = <&gpio4 10 GPIO_ACTIVE_HIGH>;
> + interrupts-extended = <&gpio1 6 IRQ_TYPE_EDGE_RISING>;
> + touchscreen-fuzz-x = <4>;
> + touchscreen-fuzz-y = <7>;
> + touchscreen-fuzz-pressure = <2>;
> + touchscreen-size-x = <4096>;
> + touchscreen-size-y = <4096>;
> + touchscreen-max-pressure = <2048>;
> + ti,x-plate-ohms = <280>;
> + ti,esd-recovery-timeout-ms = <8000>;
> + };
> +};
> +
> +&pcie {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie>;
> + reset-gpio = <&gpio1 9 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_uart3: uart3grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D23__UART3_CTS_B 0x1b0b1
> + MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
> + MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
> + MX6QDL_PAD_EIM_EB3__UART3_RTS_B 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usbotg: usbotggrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0
> + >;
Bad indentation.
> + };
> +
> + pinctrl_usbh1: usbh1grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
> + >;
> + };
> +
> + pinctrl_usbh2: usbh2grp {
> + fsl,pins = <
> + MX6QDL_PAD_RGMII_TXC__USB_H2_DATA 0x13030
> + MX6QDL_PAD_RGMII_TX_CTL__USB_H2_STROBE 0x17030
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
> + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
> + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
> + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
> + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
> + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
> + >;
> + };
> +
> + pinctrl_enet: enetgrp {
Please sort these pinctrl entries alphabetically.
> + fsl,pins = <
> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> + MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
> + MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
> + MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
> + MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
> + MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpio_leds: gpioledsgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x130b0
> + MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x130b0
> + MX6QDL_PAD_EIM_D21__GPIO3_IO21 0x130b0
> + MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0
> + >;
> + };
> +
> + pinctrl_gpio_keys: gpio_keysgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D28__GPIO3_IO28 0x1b0b0
> + MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x1b0b0
> + MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x1b0b0
> + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x1b0b0
> + >;
> + };
> +
> + pinctrl_touchscreen: touchscreengrp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> + MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x1b0b0
> + >;
> + };
> +
> + pinctrl_pcie_reg: pciereggrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
> + >;
> + };
> +
> + pinctrl_pcie: pciegrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
> + MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
> + MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0
> + >;
> + };
> +
> + pinctrl_lcd: lcdgrp {
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
> + MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x100b0
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x10
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x10
> + MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04 0x10
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x10
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x10
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x10
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x10
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x10
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x10
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x10
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x10
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x10
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x10
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x10
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x10
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x10
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x10
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x10
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x10
> + >;
> + };
> +
> + pinctrl_backlight: backlightgrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x100b0
> + >;
Fix whitespace.
> + };
> +
> + pinctrl_pwm3: pwm3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
> + >;
> + };
> +};
> +
> +
Drop the end-of-file newlines.
> diff --git a/arch/arm/boot/dts/imx6qdl-logicpd.dtsi b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
> new file mode 100644
> index 0000000..ca266a3
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
> @@ -0,0 +1,331 @@
> +/*
> + * Copyright 2016 Logic PD
> + * This file is adapted from imx6qdl-sabresd.dtsi.
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
Please consider to use GPL/X11 dual licence for all new dts files.
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "imx6q.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path = &uart1;
> + };
> +
> + memory {
> + reg = <0x10000000 0x80000000>;
> + };
> +
> +
Unneeded newlines.
> +};
> +
> +/* Reroute power feeding the CPU to come from the external PMIC */
> +&cpu0 {
> + arm-supply = <&sw1a_reg>;
> + soc-supply = <&sw1c_reg>;
> +};
> +
> +®_arm
> +{
®_arm {
> + vin-supply = <&sw1a_reg>;
> +};
> +
> +®_soc
> +{
Ditto
> + vin-supply = <&sw1c_reg>;
> +};
> +
> +&clks {
> + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> + <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
> + <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
> +};
> +
> +&gpmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpmi_nand>;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c3>;
> + status = "okay";
> +
> + pmic: pfuze100 at 08 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <725000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vddcore";
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <725000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vddsoc";
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw2_reg: sw2 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "gen_3v3";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-name = "sw3a_vddr";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3b_reg: sw3b {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-name = "sw3b_vddr";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw4_reg: sw4 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "gen_rgmii";
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5150000>;
> + regulator-name = "gen_5v0";
> + };
> +
> +
Drop one newline.
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-name = "gen_vsns";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen1_reg: vgen1 {
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-name = "gen_1v5";
> + };
> +
> + vgen2_reg: vgen2 {
> + regulator-name = "vgen2";
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1550000>;
> + };
> +
> + vgen3_reg: vgen3 {
> + regulator-name = "gen_vadj_0";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + };
> +
> + vgen4_reg: vgen4 {
> + regulator-name = "gen_1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + vgen5_reg: vgen5 {
> + regulator-name = "gen_adj_1";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vgen6_reg: vgen6 {
> + regulator-name = "gen_2v5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + regulator-always-on;
> + };
> + };
> + };
> +
> + temp_sense1: tmp102 at 49 {
> + compatible = "ti,tmp102";
> + reg = <0x49>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tempsense>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + temp_sense0: tmp102 at 4a {
> + compatible = "ti,tmp102";
> + reg = <0x4a>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + user_eeprom: at24 at 52 {
> + compatible = "atmel,24c64";
> + pagesize = <32>;
> + reg = <0x52>;
> + };
> +
> + mfg_eeprom: at24 at 51 {
> + compatible = "atmel,24c64";
> + pagesize = <32>;
> + read-only;
> + reg = <0x51>;
> + };
> +};
> +
> +&iomuxc {
> + pinctrl_gpmi_nand: gpminandgrp {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_CLE__NAND_CLE 0x0b0b1
> + MX6QDL_PAD_NANDF_ALE__NAND_ALE 0x0b0b1
> + MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0x0b0b1
> + MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0x0b000
> + MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0x0b0b1
> + MX6QDL_PAD_SD4_CMD__NAND_RE_B 0x0b0b1
> + MX6QDL_PAD_SD4_CLK__NAND_WE_B 0x0b0b1
> + MX6QDL_PAD_NANDF_D0__NAND_DATA00 0x0b0b1
> + MX6QDL_PAD_NANDF_D1__NAND_DATA01 0x0b0b1
> + MX6QDL_PAD_NANDF_D2__NAND_DATA02 0x0b0b1
> + MX6QDL_PAD_NANDF_D3__NAND_DATA03 0x0b0b1
> + MX6QDL_PAD_NANDF_D4__NAND_DATA04 0x0b0b1
> + MX6QDL_PAD_NANDF_D5__NAND_DATA05 0x0b0b1
> + MX6QDL_PAD_NANDF_D6__NAND_DATA06 0x0b0b1
> + MX6QDL_PAD_NANDF_D7__NAND_DATA07 0x0b0b1
> + >;
> + };
> +
> + pinctrl_i2c3: i2c3grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_DAT6__UART1_RX_DATA 0x1b0b1
> + MX6QDL_PAD_SD3_DAT7__UART1_TX_DATA 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1
> + MX6QDL_PAD_SD4_DAT5__UART2_RTS_B 0x1b0b1
> + MX6QDL_PAD_SD4_DAT6__UART2_CTS_B 0x1b0b1
> + MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071
> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071
> + >;
> + };
> +
> + pinctrl_usdhc3: usdhc3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
> + MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x1f0b0
> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> + MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0
> + MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1f0b0
> + >;
> + };
> +
> + pinctrl_tempsense: tempsensegrp {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0
> + >;
> + };
> +};
> +
> +&snvs_poweroff {
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2>;
> + status = "okay";
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + cd-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>;
> + keep-power-in-suspend;
> + wakeup-source;
> + status = "okay";
> +};
> +
> +&usdhc3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc3>;
> + non-removable;
> + keep-power-in-suspend;
> + wakeup-source;
> + vmmc-supply = <&sw2_reg>;
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
Have a newline between property list and child node.
> + wlcore: wlcore at 0 {
> + compatible = "ti,wl1837";
> + reg = <0>;
> + interrupt-parent = <&gpio7>;
> + interrupts = <1 GPIO_ACTIVE_HIGH>;
> + };
> +};
Shawn
^ permalink raw reply
* [PATCH] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Dmitry Torokhov @ 2016-11-14 5:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113183407.12848-1-hdegoede@redhat.com>
Hi Hans,
On Sun, Nov 13, 2016 at 07:34:07PM +0100, Hans de Goede wrote:
> commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
> adds bma180 chip-ids to the input bma150 driver, assuming that they are
> 100% compatible, but the bma180 is not compatible with the bma150 at all,
> it has 14 bits resolution instead of 10, and it has quite different
> control registers too.
>
> Treating the bma180 as a bma150 wrt its data registers will just result
> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
> registers are a different story. Things happen to just work but supporting
> that certainly does not make treating the bma180 the same as the bma150
> right.
>
> Since some setups depend on the evdev interface the bma150 driver offers
> on top of the bma180, we cannot simply remove the bma180 ids.
>
> So this commit only removes the bma180 id when the bma180 iio driver,
> which does treat the bma180 properly, is enabled.
>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/input/misc/bma150.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
> index b0d4453..9fa1c9a 100644
> --- a/drivers/input/misc/bma150.c
> +++ b/drivers/input/misc/bma150.c
> @@ -539,7 +539,11 @@ static int bma150_probe(struct i2c_client *client,
> }
>
> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
> + if (chip_id != BMA150_CHIP_ID
> +#ifndef CONFIG_BMA180
> + && chip_id != BMA180_CHIP_ID
> +#endif
Does not this break if bma180 is compiled as module? I'd rather we did
if (chip_id != BMA150_CHIP_ID &&
(IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
...
> + ) {
> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
> return -EINVAL;
> }
> @@ -643,7 +647,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>
> static const struct i2c_device_id bma150_id[] = {
> { "bma150", 0 },
> +#ifndef CONFIG_BMA180
#if !IS_ENABLED(CONFIG_BMA180)
> { "bma180", 0 },
> +#endif
> { "smb380", 0 },
> { "bma023", 0 },
> { }
> --
> 2.9.3
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH V3 1/2] ARM: imx: mmdc perf function support i.MX6QP
From: Shawn Guo @ 2016-11-14 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478539849-10834-1-git-send-email-Frank.Li@nxp.com>
On Mon, Nov 07, 2016 at 11:30:48AM -0600, Frank Li wrote:
> i.MX6QP added new register bit PROFILE_SEL in MADPCR0.
> need set it at perf start.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH V3 2/2] ARM: dts: add new compatible stream for i.MX6QP mmdc
From: Shawn Guo @ 2016-11-14 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478539849-10834-2-git-send-email-Frank.Li@nxp.com>
On Mon, Nov 07, 2016 at 11:30:49AM -0600, Frank Li wrote:
> MMDC has a slightly different programming model between imx6q and imx6qp
> in terms of perf support, it's exactly same for suspend support, so we
> have fsl,imx6q-mmdc here to save patching suspend driver with the new
> compatible.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
s/stream/string in subject.
I fixed it up and applied the patch.
Shawn
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Shawn Guo @ 2016-11-14 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478584614-12054-2-git-send-email-peter.chen@nxp.com>
On Tue, Nov 08, 2016 at 01:56:52PM +0800, Peter Chen wrote:
> It is the 10th processor in the well-known imx6 series, and derived
> from imx6ul but cost optimized. The more information about imx6ull
> can be found at:
>
> http://www.nxp.com/products/microcontrollers-and-processors/
> arm-processors/i.mx-applications-processors/i.mx-6-processors
> /i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
> :i.MX6ULL
>
> In this patch, for SoC part, the imx6ull.dtsi includes imx6ul.dtsi;
> for board part (imx6ul/imx6ull 14x14 evk), it has a common board
> file imx6u-14x14-evk.dtsi, and this file is included by both
> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/imx6u-14x14-evk.dtsi | 487 ++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 479 +------------------------------
What's the real change between imx6u-14x14-evk.dtsi and
imx6ul-14x14-evk.dts? Instead of renaming the file, I would like to
have imx6ull-14x14-evk.dts include imx6ul-14x14-evk.dts directly, if we
can work out the difference within imx6ull-14x14-evk.dts.
Shawn
> arch/arm/boot/dts/imx6ull-14x14-evk.dts | 55 ++++
> arch/arm/boot/dts/imx6ull-pinfunc.h | 56 ++++
> arch/arm/boot/dts/imx6ull.dtsi | 43 +++
> 6 files changed, 644 insertions(+), 479 deletions(-)
> create mode 100644 arch/arm/boot/dts/imx6u-14x14-evk.dtsi
> create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
> create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
> create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
^ permalink raw reply
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: AKASHI Takahiro @ 2016-11-14 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111031903.GB15997@arm.com>
On Fri, Nov 11, 2016 at 11:19:04AM +0800, Dennis Chen wrote:
> On Fri, Nov 11, 2016 at 11:50:50AM +0900, AKASHI Takahiro wrote:
> > Will,
> > (+ Cc: Dennis)
> >
> > On Thu, Nov 10, 2016 at 05:27:20PM +0000, Will Deacon wrote:
> > > On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote:
> > > > Add memblock_cap_memory_range() which will remove all the memblock regions
> > > > except the range specified in the arguments.
> > > >
> > > > This function, like memblock_mem_limit_remove_map(), will not remove
> > > > memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> > > > later as "device memory."
> > > > See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> > > > address the mem limit issue").
> > > >
> > > > This function is used, in a succeeding patch in the series of arm64 kdump
> > > > suuport, to limit the range of usable memory, System RAM, on crash dump
> > > > kernel.
> > > > (Please note that "mem=" parameter is of little use for this purpose.)
> > > >
> > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > Cc: linux-mm at kvack.org
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > ---
> > > > include/linux/memblock.h | 1 +
> > > > mm/memblock.c | 28 ++++++++++++++++++++++++++++
> > > > 2 files changed, 29 insertions(+)
> > > >
> > > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > > > index 5b759c9..0e770af 100644
> > > > --- a/include/linux/memblock.h
> > > > +++ b/include/linux/memblock.h
> > > > @@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
> > > > phys_addr_t memblock_end_of_DRAM(void);
> > > > void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > > > void memblock_mem_limit_remove_map(phys_addr_t limit);
> > > > +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > > > bool memblock_is_memory(phys_addr_t addr);
> > > > int memblock_is_map_memory(phys_addr_t addr);
> > > > int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
> > > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > > index 7608bc3..eb53876 100644
> > > > --- a/mm/memblock.c
> > > > +++ b/mm/memblock.c
> > > > @@ -1544,6 +1544,34 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > > > (phys_addr_t)ULLONG_MAX);
> > > > }
> > > >
> > > > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > > > +{
> > > > + int start_rgn, end_rgn;
> > > > + int i, ret;
> > > > +
> > > > + if (!size)
> > > > + return;
> > > > +
> > > > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > > > + &start_rgn, &end_rgn);
> > > > + if (ret)
> > > > + return;
> > > > +
> > > > + /* remove all the MAP regions */
> > > > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > + memblock_remove_region(&memblock.memory, i);
> > > > +
> > > > + for (i = start_rgn - 1; i >= 0; i--)
> > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > + memblock_remove_region(&memblock.memory, i);
> > > > +
> > > > + /* truncate the reserved regions */
> > > > + memblock_remove_range(&memblock.reserved, 0, base);
> > > > + memblock_remove_range(&memblock.reserved,
> > > > + base + size, (phys_addr_t)ULLONG_MAX);
> > > > +}
> > >
> > > This duplicates a bunch of the logic in memblock_mem_limit_remove_map. Can
> > > you not implement that in terms of your new, more general, function? e.g.
> > > by passing base == 0, and size == limit?
> >
> > Obviously it's possible.
> > I actually talked to Dennis before about merging them,
> > but he was against my idea.
> >
> Oops! I thought we have reached agreement in the thread:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/442817.html
> So feel free to do that as Will'll do
OK, but I found that the two functions have a bit different semantics
in clipping memory range, in particular, when the range [base,base+size)
goes across several regions with a gap.
(This does not happen in my arm64 kdump, though.)
That is, 'limit' in memblock_mem_limit_remove_map() means total size of
available memory, while 'size' in memblock_cap_memory_range() indicates
the size of _continuous_ memory range.
So I added an extra argument, exact, to a common function to specify
distinct behaviors. Confusing? Please see the patch below.
If nobody objects to this merge, I will submit a whole patchset of kdump
again.
Thanks,
-Takahiro AKASHI
===8<===
include/linux/memblock.h | 1 +
mm/memblock.c | 91 +++++++++++++++++++++++++++++++++++-------------
2 files changed, 68 insertions(+), 24 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5b759c9..0e770af 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
phys_addr_t memblock_end_of_DRAM(void);
void memblock_enforce_memory_limit(phys_addr_t memory_limit);
void memblock_mem_limit_remove_map(phys_addr_t limit);
+void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
bool memblock_is_memory(phys_addr_t addr);
int memblock_is_map_memory(phys_addr_t addr);
int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..5f849a9 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1473,9 +1473,10 @@ phys_addr_t __init_memblock memblock_end_of_DRAM(void)
return (memblock.memory.regions[idx].base + memblock.memory.regions[idx].size);
}
-static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit)
+static phys_addr_t __init_memblock __find_max_addr(phys_addr_t min,
+ phys_addr_t limit)
{
- phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX;
+ phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX, base, size;
struct memblock_region *r;
/*
@@ -1484,11 +1485,22 @@ static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit)
* of those regions, max_addr will keep original value ULLONG_MAX
*/
for_each_memblock(memory, r) {
- if (limit <= r->size) {
- max_addr = r->base + limit;
+ if (min >= r->base + r->size)
+ continue;
+
+ if (r->base <= min) {
+ base = min;
+ size = r->base + r->size - min;
+ } else {
+ base = r->base;
+ size = r->size;
+ }
+
+ if (limit <= size) {
+ max_addr = base + limit;
break;
}
- limit -= r->size;
+ limit -= size;
}
return max_addr;
@@ -1501,7 +1513,7 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
if (!limit)
return;
- max_addr = __find_max_addr(limit);
+ max_addr = __find_max_addr(0, limit);
/* @limit exceeds the total size of the memory, do nothing */
if (max_addr == (phys_addr_t)ULLONG_MAX)
@@ -1514,34 +1526,65 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
(phys_addr_t)ULLONG_MAX);
}
-void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+/*
+ * __memblock_cap_memory_range - cap memblock regions
+ * @base: lowest address to clip
+ * @size: size of memory range
+ * @exact: true or false
+ *
+ * If @exact is true, the exact range [@base, @base+ at size) of memory with
+ * kernel direct mapping is clipped from memblock.memory. Otherwise, total
+ * of @size of memory is clipped starting from @base.
+ */
+static void __init __memblock_cap_memory_range(phys_addr_t base,
+ phys_addr_t size, bool exact)
{
- struct memblock_type *type = &memblock.memory;
- phys_addr_t max_addr;
- int i, ret, start_rgn, end_rgn;
+ int start_rgn, end_rgn;
+ int i, ret;
- if (!limit)
+ if (!size)
return;
- max_addr = __find_max_addr(limit);
+ if (!exact) {
+ phys_addr_t max_addr;
- /* @limit exceeds the total size of the memory, do nothing */
- if (max_addr == (phys_addr_t)ULLONG_MAX)
- return;
+ max_addr = __find_max_addr(base, size);
+ /* @size exceeds the total size of the memory, do nothing */
+ if (max_addr == (phys_addr_t)ULLONG_MAX)
+ return;
+
+ /* recalc the size to clip the exact range [@base, max_addr) */
+ size = max_addr - base;
+ }
- ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX,
- &start_rgn, &end_rgn);
+ ret = memblock_isolate_range(&memblock.memory, base, size,
+ &start_rgn, &end_rgn);
if (ret)
return;
- /* remove all the MAP regions above the limit */
- for (i = end_rgn - 1; i >= start_rgn; i--) {
- if (!memblock_is_nomap(&type->regions[i]))
- memblock_remove_region(type, i);
- }
+ /* remove all the other MAP regions */
+ for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ for (i = start_rgn - 1; i >= 0; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
/* truncate the reserved regions */
- memblock_remove_range(&memblock.reserved, max_addr,
- (phys_addr_t)ULLONG_MAX);
+ memblock_remove_range(&memblock.reserved, 0, base);
+ memblock_remove_range(&memblock.reserved,
+ base + size, (phys_addr_t)ULLONG_MAX);
+}
+
+void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+{
+ __memblock_cap_memory_range(0, limit, false);
+}
+
+void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
+{
+ __memblock_cap_memory_range(base, size, true);
}
static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
--
2.10.0
===>8===
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > > Will
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: Add level for cpu dt node for exynos7
From: Alim Akhtar @ 2016-11-14 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc5aJi9nVv4rd3pB_dkkoJWUjmkEyXF2Kxtp+6Y7VZdWg@mail.gmail.com>
Hi Krzysztof,
On 11/13/2016 12:43 AM, Krzysztof Kozlowski wrote:
> On Sat, Nov 12, 2016 at 6:00 PM, Alim Akhtar <alim.akhtar@gmail.com> wrote:
>> Hi Javier,
>>
>> On Sat, Nov 12, 2016 at 7:54 PM, Javier Martinez Canillas
>> <javier@osg.samsung.com> wrote:
>>> Hello Alim,
>>>
>>> On 11/12/2016 07:17 AM, Alim Akhtar wrote:
>>>> This patch adds level for cpu dt node, so that these levels can be used
>>>
>>> Do you mean s/level/label here? I'm asking because you are using level
>>> consistently in the subject line and commit message but I'm not sure
>>> what it means in this context.
>>>
>>
>> Ah!! my bad. Its __label__. If required, will respin.
>> Thanks for review.
>
> I think there is no need of respin because this should be squashed
> with previous patch. This is quite small and there are no functional
> changes here (labels are transparent, except of course conflict
> cases). Without the 2/2, this patch does not have much sense yet.
>
The reason why I kept the _label_ changes are separate patch is to keep
git bisect happy. If you think there won't be a case for that, then lets
merge the two in single patch.
Let me know if you want me to respin or you will take care.
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 5:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114054833.GG3310@dragon>
Best regards,
Peter Chen
>-----Original Message-----
>From: Shawn Guo [mailto:shawnguo at kernel.org]
>Sent: Monday, November 14, 2016 1:49 PM
>To: Peter Chen <peter.chen@nxp.com>
>Cc: sboyd at codeaurora.org; mturquette at baylibre.com; linux-arm-
>kernel at lists.infradead.org; kernel at pengutronix.de; devicetree at vger.kernel.org;
>robh+dt at kernel.org; Fabio Estevam <fabio.estevam@nxp.com>;
>mark.rutland at arm.com; linux-clk at vger.kernel.org
>Subject: Re: [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
>
>On Tue, Nov 08, 2016 at 01:56:52PM +0800, Peter Chen wrote:
>> It is the 10th processor in the well-known imx6 series, and derived
>> from imx6ul but cost optimized. The more information about imx6ull can
>> be found at:
>>
>> http://www.nxp.com/products/microcontrollers-and-processors/
>> arm-processors/i.mx-applications-processors/i.mx-6-processors
>> /i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
>> :i.MX6ULL
>>
>> In this patch, for SoC part, the imx6ull.dtsi includes imx6ul.dtsi;
>> for board part (imx6ul/imx6ull 14x14 evk), it has a common board file
>> imx6u-14x14-evk.dtsi, and this file is included by both
>> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts.
>>
>> Signed-off-by: Peter Chen <peter.chen@nxp.com>
>> ---
>> arch/arm/boot/dts/Makefile | 3 +-
>> arch/arm/boot/dts/imx6u-14x14-evk.dtsi | 487
>> ++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 479
>> +------------------------------
>
>What's the real change between imx6u-14x14-evk.dtsi and imx6ul-14x14-evk.dts?
>Instead of renaming the file, I would like to have imx6ull-14x14-evk.dts include
>imx6ul-14x14-evk.dts directly, if we can work out the difference within imx6ull-
>14x14-evk.dts.
>
The main difference is compatible string, I can't include two compatible strings in one dts file,
the dts build will fail for that.
imx6ull-14x14-evk.dts
/ {
model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
};
imx6ul-14x14-evk.dts
/ {
model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";
};
Peter
^ permalink raw reply
* [PATCH 09/16] ARM: BCM: use generic API for enabling SCU
From: Florian Fainelli @ 2016-11-14 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-10-git-send-email-pankaj.dubey@samsung.com>
Le 13/11/2016 ? 21:02, Pankaj Dubey a ?crit :
> Now as we have of_scu_enable which takes care of mapping
> scu base from DT, lets use it.
>
> CC: Florian Fainelli <f.fainelli@gmail.com>
> CC: Ray Jui <rjui@broadcom.com>
> CC: Scott Branden <sbranden@broadcom.com>
> CC: bcm-kernel-feedback-list at broadcom.com
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Let me know if I need to pick this and submit via ARM SoC pull requests,
thanks!
--
Florian
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Jisheng Zhang @ 2016-11-14 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-2-git-send-email-pankaj.dubey@samsung.com>
Hi Pankaj,
On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:
> Many platforms are duplicating code for enabling SCU, lets add
> common code to enable SCU by parsing SCU device node so the duplication
> in each platform can be avoided.
>
> CC: Krzysztof Kozlowski <krzk@kernel.org>
> CC: Jisheng Zhang <jszhang@marvell.com>
> CC: Russell King <linux@armlinux.org.uk>
> CC: Dinh Nguyen <dinguyen@opensource.altera.com>
> CC: Patrice Chotard <patrice.chotard@st.com>
> CC: Linus Walleij <linus.walleij@linaro.org>
> CC: Liviu Dudau <liviu.dudau@arm.com>
> CC: Ray Jui <rjui@broadcom.com>
> CC: Stephen Warren <swarren@wwwdotorg.org>
> CC: Heiko Stuebner <heiko@sntech.de>
> CC: Shawn Guo <shawnguo@kernel.org>
> CC: Michal Simek <michal.simek@xilinx.com>
> CC: Wei Xu <xuwei5@hisilicon.com>
> CC: Andrew Lunn <andrew@lunn.ch>
> CC: Jun Nie <jun.nie@linaro.org>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/include/asm/smp_scu.h | 4 +++
> arch/arm/kernel/smp_scu.c | 56 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 60 insertions(+)
>
> diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> index bfe163c..fdeec07 100644
> --- a/arch/arm/include/asm/smp_scu.h
> +++ b/arch/arm/include/asm/smp_scu.h
> @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, unsigned int mode)
>
> #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> void scu_enable(void __iomem *scu_base);
> +void __iomem *of_scu_get_base(void);
> +int of_scu_enable(void);
> #else
> static inline void scu_enable(void __iomem *scu_base) {}
> +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> +static inline int of_scu_enable(void) {return 0; }
> #endif
>
> #endif
> diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> index 72f9241..d0ac3ed 100644
> --- a/arch/arm/kernel/smp_scu.c
> +++ b/arch/arm/kernel/smp_scu.c
> @@ -10,6 +10,7 @@
> */
> #include <linux/init.h>
> #include <linux/io.h>
> +#include <linux/of_address.h>
>
> #include <asm/smp_plat.h>
> #include <asm/smp_scu.h>
> @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
> */
> flush_cache_all();
> }
> +
> +static const struct of_device_id scu_match[] = {
> + { .compatible = "arm,cortex-a9-scu", },
> + { .compatible = "arm,cortex-a5-scu", },
> + { }
> +};
> +
> +/*
> + * Helper API to get SCU base address
> + * In case platform DT do not have SCU node, or iomap fails
> + * this call will fallback and will try to map via call to
> + * scu_a9_get_base.
> + * This will return ownership of scu_base to the caller
> + */
> +void __iomem *of_scu_get_base(void)
> +{
> + unsigned long base = 0;
> + struct device_node *np;
> + void __iomem *scu_base;
> +
> + np = of_find_matching_node(NULL, scu_match);
could we check np before calling of_iomap()?
> + scu_base = of_iomap(np, 0);
> + of_node_put(np);
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base via DT\n", __func__);
For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
what does it mean, but it may confuse normal users. In current version,
berlin doesn't complain like this for non-ca9 SoCs
> + if (scu_a9_has_base()) {
> + base = scu_a9_get_base();
> + scu_base = ioremap(base, SZ_4K);
> + }
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base\n", __func__);
ditto
> + return IOMEM_ERR_PTR(-ENOMEM);
> + }
> + }
> + return scu_base;
> +}
> +
> +/*
> + * Enable SCU via mapping scu_base DT
> + * If scu_base mapped successfully scu will be enabled and in case of
> + * failure if will return non-zero error code
> + */
> +int of_scu_enable(void)
> +{
> + void __iomem *scu_base;
> +
> + scu_base = of_scu_get_base();
> + if (!IS_ERR(scu_base)) {
> + scu_enable(scu_base);
> + iounmap(scu_base);
> + return 0;
> + }
> + return PTR_ERR(scu_base);
> +}
> +
> #endif
>
> /*
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Shawn Guo @ 2016-11-14 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB14509BFD0CBA838BC1EA7D598BBC0@HE1PR04MB1450.eurprd04.prod.outlook.com>
On Mon, Nov 14, 2016 at 05:59:01AM +0000, Peter Chen wrote:
> The main difference is compatible string, I can't include two compatible strings in one dts file,
> the dts build will fail for that.
>
> imx6ull-14x14-evk.dts
> / {
> model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
> compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
> };
>
> imx6ul-14x14-evk.dts
> / {
> model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
> compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";
> };
I created imx6ull-14x14-evk.dts like below, and DTC seems happy with it.
#include "imx6ul-14x14-evk.dts"
/ {
model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
};
Shawn
^ permalink raw reply
* [RESEND][PATCH 6/6] arm64: Add DTS support for FSL's LS2088A SoC
From: Shawn Guo @ 2016-11-14 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478597664-14799-7-git-send-email-abhimanyu.saini@nxp.com>
On Tue, Nov 08, 2016 at 03:04:24PM +0530, Abhimanyu Saini wrote:
> This patch adds the device tree support for FSL LS2088A SoC based on
> ARMv8 architecture.
>
> Following levels of DTSI/DTS files have been created for the LS2088A
> SoC family:
>
> - fsl-ls2088a.dtsi:
> DTS-Include file for FSL LS2088A SoC.
>
> - fsl-ls2088a-qds.dts:
> DTS file for FSL LS2088A QDS board.
>
> - fsl-ls2088a-rdb.dts:
> DTS file for FSL LS2088A RDB board.
I compared the following files.
fsl-ls2088a.dtsi vs. fsl-ls2080a.dtsi
fsl-ls2088a-qds.dtsi vs. fsl-ls2080a-qds.dtsi
fsl-ls2088a-rdb.dtsi vs. fsl-ls2080a-rdb.dtsi
They are basically identical except a couple of small changes. Can we
do something to have these SoCs share the dts files at some level to
avoid maintaining duplicated files?
Shawn
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 2 +
> arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts | 211 +++++++
> arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts | 166 +++++
> arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 703 ++++++++++++++++++++++
> 4 files changed, 1082 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114061311.GA14956@dragon>
>On Mon, Nov 14, 2016 at 05:59:01AM +0000, Peter Chen wrote:
>> The main difference is compatible string, I can't include two
>> compatible strings in one dts file, the dts build will fail for that.
>>
>> imx6ull-14x14-evk.dts
>> / {
>> model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
>> compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull"; };
>>
>> imx6ul-14x14-evk.dts
>> / {
>> model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
>> compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul"; };
>
>I created imx6ull-14x14-evk.dts like below, and DTC seems happy with it.
>
>#include "imx6ul-14x14-evk.dts"
>
>/ {
> model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
> compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull"; };
>
Thanks for trying it, the problem why my dtc building fail is I have two
" /dts-v1/;" at dts file (one is from imx6ul-14x14-evk.dts) . I will follow your suggestion.
Peter
^ permalink raw reply
* [PATCH] arm: imx6qp: correct LDB clock inputs
From: Shawn Guo @ 2016-11-14 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108165536.19656-1-l.stach@pengutronix.de>
On Tue, Nov 08, 2016 at 05:55:36PM +0100, Lucas Stach wrote:
> On i.MX6QP the LDB clock tree has changed to move the clk gate
> before the divider, to prevent clock glitches propagating downstream.
>
> A consequence of this change is that the clk divider is now the
> parent of the LDB inputs. Reflect this change in the devicetree
> to allow the LDB driver to properly configure the display clocks.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx7d-pinfunc: fix UART pinmux defines
From: Shawn Guo @ 2016-11-14 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109024456.1832-1-stefan@agner.ch>
On Tue, Nov 08, 2016 at 06:44:56PM -0800, Stefan Agner wrote:
> The UART pinmux defines for the pins which are part of the LPSR
> pinmux controller are wrong: Output signals configure the input
> sel value and the pinmux defines allow not to distinguish between
> DCE/DTE mode. Follow the usual pattern using DTE/DCE as part of
> the define to denote the two UART configuration options.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid
From: Shawn Guo @ 2016-11-14 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478709850-9361-1-git-send-email-andrew.smirnov@gmail.com>
On Wed, Nov 09, 2016 at 08:44:10AM -0800, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
I updated subject prefix a bit and applied the patch.
Shawn
^ permalink raw reply
* [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid
From: Stefan Agner @ 2016-11-14 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478709850-9361-1-git-send-email-andrew.smirnov@gmail.com>
On 2016-11-09 17:44, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.
FWIW, r3p2 is also the revision according to the cache registers...
Acked-by: Stefan Agner <stefan@agner.ch>
--
Stefan
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/mach-imx/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 9155b63..936c59d 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -557,7 +557,6 @@ config SOC_VF610
> bool "Vybrid Family VF610 support"
> select ARM_GIC if ARCH_MULTI_V7
> select PINCTRL_VF610
> - select PL310_ERRATA_769419 if CACHE_L2X0
>
> help
> This enables support for Freescale Vybrid VF610 processor.
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Jisheng Zhang @ 2016-11-14 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114141251.7ea86e7a@xhacker>
On Mon, 14 Nov 2016 14:12:51 +0800 Jisheng Zhang wrote:
> Hi Pankaj,
>
> On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:
>
> > Many platforms are duplicating code for enabling SCU, lets add
> > common code to enable SCU by parsing SCU device node so the duplication
> > in each platform can be avoided.
> >
> > CC: Krzysztof Kozlowski <krzk@kernel.org>
> > CC: Jisheng Zhang <jszhang@marvell.com>
> > CC: Russell King <linux@armlinux.org.uk>
> > CC: Dinh Nguyen <dinguyen@opensource.altera.com>
> > CC: Patrice Chotard <patrice.chotard@st.com>
> > CC: Linus Walleij <linus.walleij@linaro.org>
> > CC: Liviu Dudau <liviu.dudau@arm.com>
> > CC: Ray Jui <rjui@broadcom.com>
> > CC: Stephen Warren <swarren@wwwdotorg.org>
> > CC: Heiko Stuebner <heiko@sntech.de>
> > CC: Shawn Guo <shawnguo@kernel.org>
> > CC: Michal Simek <michal.simek@xilinx.com>
> > CC: Wei Xu <xuwei5@hisilicon.com>
> > CC: Andrew Lunn <andrew@lunn.ch>
> > CC: Jun Nie <jun.nie@linaro.org>
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> > ---
> > arch/arm/include/asm/smp_scu.h | 4 +++
> > arch/arm/kernel/smp_scu.c | 56 ++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 60 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> > index bfe163c..fdeec07 100644
> > --- a/arch/arm/include/asm/smp_scu.h
> > +++ b/arch/arm/include/asm/smp_scu.h
> > @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, unsigned int mode)
> >
> > #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> > void scu_enable(void __iomem *scu_base);
> > +void __iomem *of_scu_get_base(void);
> > +int of_scu_enable(void);
> > #else
> > static inline void scu_enable(void __iomem *scu_base) {}
> > +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> > +static inline int of_scu_enable(void) {return 0; }
> > #endif
> >
> > #endif
> > diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> > index 72f9241..d0ac3ed 100644
> > --- a/arch/arm/kernel/smp_scu.c
> > +++ b/arch/arm/kernel/smp_scu.c
> > @@ -10,6 +10,7 @@
> > */
> > #include <linux/init.h>
> > #include <linux/io.h>
> > +#include <linux/of_address.h>
> >
> > #include <asm/smp_plat.h>
> > #include <asm/smp_scu.h>
> > @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
> > */
> > flush_cache_all();
> > }
> > +
> > +static const struct of_device_id scu_match[] = {
> > + { .compatible = "arm,cortex-a9-scu", },
> > + { .compatible = "arm,cortex-a5-scu", },
> > + { }
> > +};
> > +
> > +/*
> > + * Helper API to get SCU base address
> > + * In case platform DT do not have SCU node, or iomap fails
> > + * this call will fallback and will try to map via call to
> > + * scu_a9_get_base.
> > + * This will return ownership of scu_base to the caller
> > + */
> > +void __iomem *of_scu_get_base(void)
> > +{
> > + unsigned long base = 0;
> > + struct device_node *np;
> > + void __iomem *scu_base;
> > +
> > + np = of_find_matching_node(NULL, scu_match);
>
> could we check np before calling of_iomap()?
>
> > + scu_base = of_iomap(np, 0);
> > + of_node_put(np);
> > + if (!scu_base) {
> > + pr_err("%s failed to map scu_base via DT\n", __func__);
>
> For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> what does it mean, but it may confuse normal users. In current version,
> berlin doesn't complain like this for non-ca9 SoCs
oops, I just realized that the non-ca9 berlin arm SoC version isn't upstreamed.
Below is the draft version I planed. Basically speaking, the code tries to
find "arm,cortex-a9-scu" node from DT, if can't, we think we don't need to
worry about SCU. Is there any elegant solution for my situation?
Thanks,
Jisheng
------------8<-------------------
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -56,22 +56,25 @@ static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
void __iomem *vectors_base;
np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
- scu_base = of_iomap(np, 0);
- of_node_put(np);
- if (!scu_base)
- return;
+ if (np) {
+ scu_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (!scu_base)
+ return;
+ scu_enable(scu_base);
+ iounmap(scu_base);
+ }
np = of_find_compatible_node(NULL, NULL, "marvell,berlin-cpu-ctrl");
cpu_ctrl = of_iomap(np, 0);
of_node_put(np);
if (!cpu_ctrl)
- goto unmap_scu;
+ return;
vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
if (!vectors_base)
- goto unmap_scu;
+ return;
- scu_enable(scu_base);
flush_cache_all();
/*
@@ -87,8 +90,6 @@ static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
writel(virt_to_phys(secondary_startup), vectors_base + SW_RESET_ADDR);
iounmap(vectors_base);
-unmap_scu:
- iounmap(scu_base);
}
static struct smp_operations berlin_smp_ops __initdata = {
>
> > + if (scu_a9_has_base()) {
> > + base = scu_a9_get_base();
> > + scu_base = ioremap(base, SZ_4K);
> > + }
> > + if (!scu_base) {
> > + pr_err("%s failed to map scu_base\n", __func__);
>
> ditto
>
> > + return IOMEM_ERR_PTR(-ENOMEM);
> > + }
> > + }
> > + return scu_base;
> > +}
> > +
> > +/*
> > + * Enable SCU via mapping scu_base DT
> > + * If scu_base mapped successfully scu will be enabled and in case of
> > + * failure if will return non-zero error code
> > + */
> > +int of_scu_enable(void)
> > +{
> > + void __iomem *scu_base;
> > +
> > + scu_base = of_scu_get_base();
> > + if (!IS_ERR(scu_base)) {
> > + scu_enable(scu_base);
> > + iounmap(scu_base);
> > + return 0;
> > + }
> > + return PTR_ERR(scu_base);
> > +}
> > +
> > #endif
> >
> > /*
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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