* [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
* [PATCH v2 0/2] phy: rockchip-inno-usb2: correct 480MHz clk_ops callbacks and stable time
From: William Wu @ 2016-11-14 7:01 UTC (permalink / raw)
To: linux-arm-kernel
This series try to correct the 480MHz output clock of USB2 PHY
clk_ops callback and fix the delay time. It aims to make the
480MHz clock more sensible and stable.
Tested on rk3366/rk3399 EVB board.
William Wu (2):
phy: rockchip-inno-usb2: correct clk_ops callback
phy: rockchip-inno-usb2: correct 480MHz output clock stable time
drivers/phy/phy-rockchip-inno-usb2.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--
2.0.0
^ permalink raw reply
* [PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback
From: William Wu @ 2016-11-14 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479106911-16049-1-git-send-email-wulf@rock-chips.com>
Since we needs to delay ~1ms to wait for 480MHz output clock
of USB2 PHY to become stable after turn on it, the delay time
is pretty long for something that's supposed to be "atomic"
like a clk_enable(). Consider that clk_enable() will disable
interrupt and that a 1ms interrupt latency is not sensible.
The 480MHz output clock should be handled in prepare callbacks
which support gate a clk if the operation may sleep.
Signed-off-by: William Wu <wulf@rock-chips.com>
---
drivers/phy/phy-rockchip-inno-usb2.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
index ac20310..365e077 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -153,7 +153,7 @@ static inline bool property_enabled(struct rockchip_usb2phy *rphy,
return tmp == reg->enable;
}
-static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -172,7 +172,7 @@ static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
return 0;
}
-static void rockchip_usb2phy_clk480m_disable(struct clk_hw *hw)
+static void rockchip_usb2phy_clk480m_unprepare(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -181,7 +181,7 @@ static void rockchip_usb2phy_clk480m_disable(struct clk_hw *hw)
property_enable(rphy, &rphy->phy_cfg->clkout_ctl, false);
}
-static int rockchip_usb2phy_clk480m_enabled(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepared(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -197,9 +197,9 @@ rockchip_usb2phy_clk480m_recalc_rate(struct clk_hw *hw,
}
static const struct clk_ops rockchip_usb2phy_clkout_ops = {
- .enable = rockchip_usb2phy_clk480m_enable,
- .disable = rockchip_usb2phy_clk480m_disable,
- .is_enabled = rockchip_usb2phy_clk480m_enabled,
+ .prepare = rockchip_usb2phy_clk480m_prepare,
+ .unprepare = rockchip_usb2phy_clk480m_unprepare,
+ .is_prepared = rockchip_usb2phy_clk480m_prepared,
.recalc_rate = rockchip_usb2phy_clk480m_recalc_rate,
};
--
2.0.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox