* [PATCH] crypto: arm/speck - fix building in Thumb2 mode
From: Eric Biggers @ 2018-06-18 22:33 UTC (permalink / raw)
To: linux-arm-kernel
Building the kernel with CONFIG_THUMB2_KERNEL=y and
CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
arch/arm/crypto/speck-neon-core.S: Assembler messages:
arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here -- `bic sp,#0xf'
arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here -- `bic sp,#0xf'
arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here -- `bic sp,#0xf'
arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here -- `bic sp,#0xf'
The problem is that the 'bic' instruction can't operate on the 'sp'
register in Thumb2 mode. Fix it by using a temporary register. This
isn't in the main loop, so the performance difference is negligible.
This also matches what aes-neonbs-core.S does.
Reported-by: Stefan Agner <stefan@agner.ch>
Fixes: ede9622162fa ("crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS")
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
arch/arm/crypto/speck-neon-core.S | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/crypto/speck-neon-core.S b/arch/arm/crypto/speck-neon-core.S
index 3c1e203e53b9..57caa742016e 100644
--- a/arch/arm/crypto/speck-neon-core.S
+++ b/arch/arm/crypto/speck-neon-core.S
@@ -272,9 +272,11 @@
* Allocate stack space to store 128 bytes worth of tweaks. For
* performance, this space is aligned to a 16-byte boundary so that we
* can use the load/store instructions that declare 16-byte alignment.
+ * For Thumb2 compatibility, don't do the 'bic' directly on 'sp'.
*/
- sub sp, #128
- bic sp, #0xf
+ sub r12, sp, #128
+ bic r12, #0xf
+ mov sp, r12
.if \n == 64
// Load first tweak
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH 1/2] ARM: imx: add standby mode suspend for i.MX6SLL
From: Shawn Guo @ 2018-06-19 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527732369-19740-1-git-send-email-Anson.Huang@nxp.com>
On Thu, May 31, 2018 at 10:06:08AM +0800, Anson Huang wrote:
> Add standby mode suspend for i.MX6SLL, when
> linux kernel suspend, SoC will enter STOP mode
> with ARM core power on.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied both, thanks.
^ permalink raw reply
* [PATCH V2 1/3] ARM: imx: add L2 page power control for GPC
From: Shawn Guo @ 2018-06-19 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527993226-19587-1-git-send-email-Anson.Huang@nxp.com>
On Sun, Jun 03, 2018 at 10:33:44AM +0800, Anson Huang wrote:
> Some platforms like i.MX6UL/i.MX6SLL have L2
> page power control in GPC, it needs to be
> disabled if ARM is power gated and L2 is NOT
> flushed, add GPC interface to control it.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx53-qsb: Let the codec control MCLK pinctrl
From: Shawn Guo @ 2018-06-19 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528160209-2849-1-git-send-email-festevam@gmail.com>
On Mon, Jun 04, 2018 at 09:56:49PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> sgtl5000 codec needs MCLK clock to be present so that it can
> successfully read/write via I2C.
>
> In the case of imx53-qsb, MCLK is provided via
> MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK pad.
>
> Move the MCLK pinctrl from hog group to the codec group, so that the
> codec clock can be present prior to reading the codec ID.
Are you saying that pins in hog group hasn't been set up yet when codec
driver probes?
Shawn
>
> This avoids the following sgtl5000 probe error:
>
> sgtl5000 1-000a: Error reading chip id -6
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx53-qsb-common.dtsi | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx53-qsb-common.dtsi b/arch/arm/boot/dts/imx53-qsb-common.dtsi
> index ef7658a..7423d46 100644
> --- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
> +++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
> @@ -153,7 +153,6 @@
> imx53-qsb {
> pinctrl_hog: hoggrp {
> fsl,pins = <
> - MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 0x80000000
> MX53_PAD_GPIO_8__GPIO1_8 0x80000000
> MX53_PAD_PATA_DATA14__GPIO2_14 0x80000000
> MX53_PAD_PATA_DATA15__GPIO2_15 0x80000000
> @@ -180,6 +179,12 @@
> >;
> };
>
> + pinctrl_codec: codecgrp {
> + fsl,pins = <
> + MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 0x1c4
> + >;
> + };
> +
> pinctrl_esdhc1: esdhc1grp {
> fsl,pins = <
> MX53_PAD_SD1_DATA0__ESDHC1_DAT0 0x1d5
> @@ -310,6 +315,8 @@
> sgtl5000: codec at a {
> compatible = "fsl,sgtl5000";
> reg = <0x0a>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_codec>;
> #sound-dai-cells = <0>;
> VDDA-supply = <®_3p2v>;
> VDDIO-supply = <®_3p2v>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2] mtd: atmel-quadspi: add suspend/resume hooks
From: Marek Vasut @ 2018-06-19 1:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0be344a2-9878-2b92-9436-bc2f4d4fd6e0@microchip.com>
On 06/18/2018 02:00 PM, Claudiu Beznea wrote:
>
>
> On 18.06.2018 12:53, Marek Vasut wrote:
>> On 06/18/2018 11:49 AM, Boris Brezillon wrote:
>>> Hi Claudiu,
>>>
>>> The subject prefix should be "mtd: spi-nor: atmel-quadspi: ". No need
>>> to send a new version just for that, I'll fix it when applying the
>>> patch.
>>>
> Hi Boris,
>
> Thank you!
>
>>> Looks good otherwise. Marek, any objection? If not, can you add your
>>> Acked-by?
>>
>> Will this work if you have ie. ubifs mounted on that QSPI NOR and you
>> suspect and resume during IO ? I think it would, but just curious if
>> there could be some problem.
>
> Hi Marek,
>
> I tested only with read/writes while suspending, simple scripts, but not
> having ubifs mounted on QSPI NOR. I will double check also with ubifs
> mounted on QSPI NOR and come back with the results.
Thanks. I think it's gonna be OK, but let's just be sure.
Make sure to disable 4K sector support when fiddling with UBI/UBIFS on
QSPI NOR.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 15/20] dts: arm: imx7{d,s}: Update coresight binding for hardware ports
From: Shawn Guo @ 2018-06-19 2:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528235011-30691-16-git-send-email-suzuki.poulose@arm.com>
Hi Stefan,
Can you take a look at the patch? Thanks.
Shawn
On Tue, Jun 05, 2018 at 10:43:26PM +0100, Suzuki K Poulose wrote:
> Switch to the updated coresight bindings.
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> arch/arm/boot/dts/imx7d.dtsi | 5 ++++-
> arch/arm/boot/dts/imx7s.dtsi | 41 ++++++++++++++++++++++++++++++-----------
> 2 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 200714e..5faff17 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -87,7 +87,9 @@
>
> port {
> etm1_out_port: endpoint {
> + direction = <1>;
> remote-endpoint = <&ca_funnel_in_port1>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -174,8 +176,9 @@
> port at 1 {
> reg = <1>;
> ca_funnel_in_port1: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&etm1_out_port>;
> + coresight,hwid = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 4d42335..8e90915 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -151,23 +151,28 @@
> port at 0 {
> reg = <0>;
> replicator_out_port0: endpoint {
> + direction = <1>;
> remote-endpoint = <&tpiu_in_port>;
> + coresight,hwid = <0>;
> };
> };
>
> port at 1 {
> reg = <1>;
> replicator_out_port1: endpoint {
> + direction = <1>;
> remote-endpoint = <&etr_in_port>;
> + coresight,hwid = <1>;
> };
> };
>
> /* replicator input port */
> port at 2 {
> - reg = <0>;
> + reg = <2>;
> replicator_in_port0: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&etf_out_port>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -203,16 +208,19 @@
> port at 0 {
> reg = <0>;
> ca_funnel_in_port0: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&etm0_out_port>;
> + coresight,hwid = <0>;
> };
> };
>
> /* funnel output port */
> port at 2 {
> - reg = <0>;
> + reg = <2>;
> ca_funnel_out_port0: endpoint {
> + direction = <1>;
> remote-endpoint = <&hugo_funnel_in_port0>;
> + coresight,hwid = <0>;
> };
> };
>
> @@ -229,7 +237,9 @@
>
> port {
> etm0_out_port: endpoint {
> + direction = <1>;
> remote-endpoint = <&ca_funnel_in_port0>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -248,22 +258,26 @@
> port at 0 {
> reg = <0>;
> hugo_funnel_in_port0: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&ca_funnel_out_port0>;
> + coresight,hwid = <0>;
> };
> };
>
> port at 1 {
> reg = <1>;
> hugo_funnel_in_port1: endpoint {
> - slave-mode; /* M4 input */
> + direction = <0>; /* M4 input */
> + coresight,hwid = <1>;
> };
> };
>
> port at 2 {
> - reg = <0>;
> + reg = <2>;
> hugo_funnel_out_port0: endpoint {
> + direction = <1>;
> remote-endpoint = <&etf_in_port>;
> + coresight,hwid = <0>;
> };
> };
>
> @@ -284,15 +298,18 @@
> port at 0 {
> reg = <0>;
> etf_in_port: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&hugo_funnel_out_port0>;
> + coresight,hwid = <0>;
> };
> };
>
> port at 1 {
> - reg = <0>;
> + reg = <1>;
> etf_out_port: endpoint {
> + direction = <1>;
> remote-endpoint = <&replicator_in_port0>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -306,8 +323,9 @@
>
> port {
> etr_in_port: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&replicator_out_port1>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -320,8 +338,9 @@
>
> port {
> tpiu_in_port: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&replicator_out_port1>;
> + coresight,hwid = <0>;
> };
> };
> };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] ARM: dts: imx6: RDU2: correct touchscreen axis inversion
From: Shawn Guo @ 2018-06-19 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606093045.9215-1-l.stach@pengutronix.de>
On Wed, Jun 06, 2018 at 11:30:45AM +0200, Lucas Stach wrote:
> The RMI4 touchscreen driver applied inversion and axis swap in the
> wrong order, violating the DT binding for those properties. This is
> fixed now, so correct the RDU2 DT to apply the inversion to the
> correct axis.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: i.MX6: imx6dl-mamoj: Add parallel display support
From: Shawn Guo @ 2018-06-19 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607134748.2970-1-jagan@amarulasolutions.com>
On Thu, Jun 07, 2018 at 07:17:46PM +0530, Jagan Teki wrote:
> This patch adds parallel display support for i.MX6DL Mamoj board
> along with relevant backlight through pwm.
>
> LCD power sequence is added by 'Michael Trimarchi'.
>
> Signed-off-by: Simone CIANNI <simone.cianni@bticino.it>
> Signed-off-by: Raffaele RECALCATI <raffaele.recalcati@bticino.it>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes for v2:
> - collect Fabio r-w-b tag
>
> arch/arm/boot/dts/imx6dl-mamoj.dts | 185 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 185 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-mamoj.dts b/arch/arm/boot/dts/imx6dl-mamoj.dts
> index 6b2d29138bed..ed9050c5dbcc 100644
> --- a/arch/arm/boot/dts/imx6dl-mamoj.dts
> +++ b/arch/arm/boot/dts/imx6dl-mamoj.dts
> @@ -6,11 +6,133 @@
>
> /dts-v1/;
>
> +#include <dt-bindings/gpio/gpio.h>
> #include "imx6dl.dtsi"
>
> / {
> model = "BTicino i.MX6DL Mamoj board";
> compatible = "bticino,imx6dl-mamoj", "fsl,imx6dl";
> +
> + backlight_lcd: backlight-lcd {
> + compatible = "pwm-backlight";
> + pwms = <&pwm3 0 25000>; /* 25000ns -> 40kHz */
> + brightness-levels = <0 4 8 16 32 64 128 160 192 224 255>;
> + default-brightness-level = <7>;
> + };
> +
> + lcd_display: disp0 {
'display' for node name.
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "rgb24";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1_lcdif>;
> + status = "okay";
> +
> + port at 0 {
> + reg = <0>;
> +
> + lcd_display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <&lcd_panel_in>;
> + };
> + };
> + };
> +
> + panel-lcd {
> + compatible = "rocktech,rk070er9427";
> + backlight = <&backlight_lcd>;
> + power-supply = <®_lcd_lr>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcd_power>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <&lcd_display_out>;
> + };
> + };
> + };
> +
> + reg_lcd_3v3: regulator-lcd-dvdd {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-dvdd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 1 0>;
> + enable-active-high;
> + startup-delay-us = <21000>;
> + };
> +
> + reg_lcd_power: regulator-lcd-power {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-enable";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 6 0>;
> + enable-active-high;
> + vin-supply = <®_lcd_3v3>;
> + };
> +
> + reg_lcd_vgl: regulator-lcd-vgl {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-vgl";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio2 20 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <6000>;
> + enable-active-high;
> + vin-supply = <®_lcd_power>;
> + };
> +
> + reg_lcd_vgh: regulator-lcd-vgh {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-vgh";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 31 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <6000>;
> + enable-active-high;
> + vin-supply = <®_lcd_avdd>;
> + };
> +
> + reg_lcd_vcom: regulator-lcd-vcom {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-vcom";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio4 14 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <11000>;
> + enable-active-high;
> + vin-supply = <®_lcd_vgh>;
> + };
> +
> + reg_lcd_lr: regulator-lcd-lr {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-lr";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + vin-supply = <®_lcd_vcom>;
> + };
> +
> + reg_lcd_avdd: regulator-lcd-avdd {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-avdd";
> + regulator-min-microvolt = <10280000>;
> + regulator-max-microvolt = <10280000>;
> + gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <6000>;
> + enable-active-high;
> + vin-supply = <®_lcd_vgl>;
> + };
> };
>
> &fec {
> @@ -147,6 +269,16 @@
> };
> };
>
> +&ipu1_di0_disp0 {
> + remote-endpoint = <&lcd_display_in>;
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm3>;
> + status = "okay";
> +};
> +
> &uart3 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart3>;
> @@ -200,6 +332,59 @@
> >;
> };
>
> + pinctrl_ipu1_lcdif: pinctrlipu1lcdif { /* parallel port 24-bit */
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10 /* VDOUT_PCLK */
> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x10
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x10 /* VDOUT_HSYNC */
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x10 /* VDOUT_VSYNC */
> + MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04 0x80000000 /* VDOUT_RESET */
Use a proper configuration value rather than relying on what
firmware/reset gives.
> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 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
> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x10
> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x10
> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x10
> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x10
> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x10
> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x10
> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x10
> + >;
> + };
> +
> + pinctrl_lcd_power: lcd_power {
The node name and above pinctrlipu1lcdif is not consistent to other
pinctrl nodes.
Shawn
> + fsl,pins = <
> + MX6QDL_PAD_EIM_DA1__GPIO3_IO01 0x40013058 /* EN_LCD33V */
> + MX6QDL_PAD_SD4_DAT5__GPIO2_IO13 0x4001b0b0 /* EN_AVDD */
> + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x40013058 /* ENVGH */
> + MX6QDL_PAD_EIM_A18__GPIO2_IO20 0x40013058 /* ENVGL */
> + MX6QDL_PAD_EIM_DA6__GPIO3_IO06 0x40013058 /* LCD_POWER */
> + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x40013058 /* EN_VCOM_LCD */
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x40013058 /* LCD_L_R */
> + MX6QDL_PAD_EIM_DA2__GPIO3_IO02 0x40013058 /* LCD_U_D */
> + >;
> + };
> +
> + pinctrl_pwm3: pwm3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
> + >;
> + };
> +
> pinctrl_uart3: uart3grp {
> fsl,pins = <
> MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
> --
> 2.14.3
>
^ permalink raw reply
* [PATCH v2 3/4] ARM: dts: i.MX6: imx6dl-mamoj: Add Wifi support
From: Shawn Guo @ 2018-06-19 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607134748.2970-2-jagan@amarulasolutions.com>
On Thu, Jun 07, 2018 at 07:17:47PM +0530, Jagan Teki wrote:
> Add TI WL18XX Wifi for BTicino i.MX6DL board.
>
> Signed-off-by: Simone CIANNI <simone.cianni@bticino.it>
> Signed-off-by: Raffaele RECALCATI <raffaele.recalcati@bticino.it>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes for v2:
> - collect Fabio r-w-b tag
>
> arch/arm/boot/dts/imx6dl-mamoj.dts | 53 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-mamoj.dts b/arch/arm/boot/dts/imx6dl-mamoj.dts
> index ed9050c5dbcc..5034b086035f 100644
> --- a/arch/arm/boot/dts/imx6dl-mamoj.dts
> +++ b/arch/arm/boot/dts/imx6dl-mamoj.dts
> @@ -133,6 +133,18 @@
> enable-active-high;
> vin-supply = <®_lcd_vgl>;
> };
> +
> + reg_wl18xx_vmmc: regulator-wl18xx-vmcc {
> + compatible = "regulator-fixed";
> + regulator-name = "vwl1807";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wlan>;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + gpio = <&gpio6 21 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <70000>;
> + enable-active-high;
> + };
> };
>
> &fec {
> @@ -285,6 +297,30 @@
> status = "okay";
> };
>
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + bus-width = <4>;
> + vmmc-supply = <®_wl18xx_vmmc>;
> + no-1-8-v;
> + non-removable;
> + wakeup-source;
> + keep-power-in-suspend;
> + cap-power-off-card;
> + max-frequency = <25000000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + wlcore: wlcore at 2 {
> + compatible = "ti,wl1837";
> + reg = <2>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
> + tcxo-clock-frequency = <26000000>;
> + };
> +};
> +
> &usdhc3 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc3>;
> @@ -392,6 +428,17 @@
> >;
> };
>
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17069
> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10079
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17069
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17069
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17069
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17069
> + >;
> + };
> +
> pinctrl_usdhc3: usdhc3grp {
> fsl,pins = <
> MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> @@ -406,4 +453,10 @@
> MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
> >;
> };
> +
> + pinctrl_wlan: wlan {
To be consistent on naming style, 'wlangrp' might be better.
Shawn
> + fsl,pins = <
> + MX6QDL_PAD_RGMII_TD1__GPIO6_IO21 0x4001b0b0
> + >;
> + };
> };
> --
> 2.14.3
>
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: i.MX6: imx6dl-mamoj: Add usb host and device support
From: Shawn Guo @ 2018-06-19 2:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607134748.2970-3-jagan@amarulasolutions.com>
On Thu, Jun 07, 2018 at 07:17:48PM +0530, Jagan Teki wrote:
> From: Michael Trimarchi <michael@amarulasolutions.com>
>
> Add USB host and device support for BTicino i.MX6DL Mamoj board.
>
> Signed-off-by: Simone CIANNI <simone.cianni@bticino.it>
> Signed-off-by: Raffaele RECALCATI <raffaele.recalcati@bticino.it>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes for v2:
> - collect Fabio r-w-b tag
>
> arch/arm/boot/dts/imx6dl-mamoj.dts | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-mamoj.dts b/arch/arm/boot/dts/imx6dl-mamoj.dts
> index 5034b086035f..a727e1471006 100644
> --- a/arch/arm/boot/dts/imx6dl-mamoj.dts
> +++ b/arch/arm/boot/dts/imx6dl-mamoj.dts
> @@ -134,6 +134,17 @@
> vin-supply = <®_lcd_vgl>;
> };
>
> + reg_usb_host: regulator-usb-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usbhost-vbus";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbhost>;
> + regulator-min-microvolt = <50000000>;
> + regulator-max-microvolt = <50000000>;
> + gpio = <&gpio6 6 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> reg_wl18xx_vmmc: regulator-wl18xx-vmcc {
> compatible = "regulator-fixed";
> regulator-name = "vwl1807";
> @@ -297,6 +308,16 @@
> status = "okay";
> };
>
> +&usbh1 {
> + vbus-supply = <®_usb_host>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + dr_mode = "peripheral";
> + status = "okay";
> +};
> +
> &usdhc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc1>;
> @@ -428,6 +449,12 @@
> >;
> };
>
> + pinctrl_usbhost: usbhost {
usbhostgrp.
Shawn
> + fsl,pins = <
> + MX6QDL_PAD_EIM_A23__GPIO6_IO06 0x4001b0b0
> + >;
> + };
> +
> pinctrl_usdhc1: usdhc1grp {
> fsl,pins = <
> MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17069
> --
> 2.14.3
>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx6dl: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support
From: Shawn Guo @ 2018-06-19 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607135133.3104-1-jagan@amarulasolutions.com>
On Thu, Jun 07, 2018 at 07:21:31PM +0530, Jagan Teki wrote:
> i.CoreM6 1.5 is an another i.CoreM6 QDL cpu modules which can be connected
> to EDIMM starter kit design with eMMC and MIPI-CSI interfaces suitable for
> Android and video capture application.
>
> notable features:
> CPU NXP i.MX6 S/DL/D/Q, Up to 4 x Cortex-A9 at 800MHz
> Memory Up to 2 GB DDR3-1066
> Video Interfaces Up to 1 Parallel Up to 2 LVDS HDMI 1.4
> port 8 bit CSI INPUT MIPI-CSI INPUT
> 1 x 10/100 Ethernet interface, 2 x USB, 1 x PCIe, 1 x I2S etc
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Shawn Guo @ 2018-06-19 2:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1be8dc197f842d3be31a15315594a25c8ad8f298.1529309235.git.leonard.crestez@nxp.com>
On Mon, Jun 18, 2018 at 11:15:44AM +0300, Leonard Crestez wrote:
> The following sensors are on I2C3 on the baseboard:
> * isil,isl29023 light sensor
> * fsl,mag3110 magnetometer
> * fsl,mma8451 accelerometer
>
> Added under i2cmux/i2c at 1 because they're not otherwise accessible.
>
> These are all supported by iio with following configs:
> * CONFIG_SENSORS_ISL29018
> * CONFIG_MAG3110
> * CONFIG_MMA8452
>
> Tested with raw reads from iio sysfs.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Applied both, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx7d-sdb: Remove duplicate regulator-can2-3v3
From: Shawn Guo @ 2018-06-19 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <abacbb7485b0c9b908eae8ae87be9d8e0eab87b3.1529327283.git.leonard.crestez@nxp.com>
On Mon, Jun 18, 2018 at 04:11:09PM +0300, Leonard Crestez wrote:
> Two different regulators are defined with the same name and label but
> distinct properties.
>
> The first definition was added with the first board dts and the second
> was added when upstream added flexcan support.
>
> Looking at schematics it is indeed gpio2 14 connected to the STB pin of
> the CAN transceiver so remove the first definition.
>
> The second definition entirely overrides the first so this already
> worked and this patch results in no DTB change, just a cleanup.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Jin, Yanjiang @ 2018-06-19 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92ff5220-f863-4edc-bc9f-bd802d2efa9c@arm.com>
> -----Original Message-----
> From: kexec [mailto:kexec-bounces at lists.infradead.org] On Behalf Of James
> Morse
> Sent: 2018?6?15? 0:17
> To: Bhupesh Sharma <bhsharma@redhat.com>
> Cc: Mark Rutland <mark.rutland@arm.com>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>; Catalin Marinas <catalin.marinas@arm.com>;
> Kexec Mailing List <kexec@lists.infradead.org>; Will Deacon
> <will.deacon@arm.com>; AKASHI Takahiro <takahiro.akashi@linaro.org>;
> Bhupesh SHARMA <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
> kernel at lists.infradead.org>
> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
> linear region
>
> Hi Bhupesh,
>
> On 14/06/18 08:53, Bhupesh Sharma wrote:
> > On Wed, Jun 13, 2018 at 3:59 PM, James Morse <james.morse@arm.com>
> wrote:
> >> On 13/06/18 06:16, Bhupesh Sharma wrote:
> >>> On Tue, Jun 12, 2018 at 3:42 PM, James Morse <james.morse@arm.com>
> wrote:
> >>>> If I've followed this properly: the problem is that to generate the
> >>>> ELF headers in the post-kdump vmcore, at kdump-load-time
> >>>> kexec-tools has to guess the virtual addresses of the 'System RAM' regions
> it can see in /proc/iomem.
> >>>>
> >>>> The problem you are hitting is an invisible hole at the beginning
> >>>> of RAM, meaning user-space's guess_phys_to_virt() is off by the size of this
> hole.
> >>>>
> >>>> Isn't KASLR a special case for this? You must have to correct for
> >>>> that after kdump has happened, based on an elf-note in the vmcore. Can't
> we always do this?
> >>>
> >>> No, I hit this issue both for the KASLR and non-KASLR boot cases.
> >>
> >> Because in both cases there is a hole at the beginning of the
> >> linear-map. KASLR is a special-case of this as the kernel adds a
> >> variable sized hole to do the randomization.
> >>
> >> Surely treating this as one case makes your user-space code simpler.
> >
> > Ok.
> >
> >>> Fixing this in kernel space seems better to me as the definition of
> >>
> >> Is there a kernel bug? Changing the definitions of internal kernel
> >> variables for the benefit of code digging in /proc/kcore|/dev/mem isn't going
> to fly.
> >
> > Indeed, I am not advocating to change the kernel space code just to
> > suit the user-space tools. However in this particular case the
> > 'memstart_addr' and PHY_OFFSET value are computed as 0 which IMO
>
> (What is PHY_OFFSET? I assume you mean PHYS_OFFSET, which is the same as
> memstart_addr ... why do you quote them together?)
>
>
> > is
> > not the real representation of the start of System RAM as the 1st
> > memory block available in Linux starts from 2MB [as confirmed by the
> > 'memblock_start_of_DRAM()' value of 0x200000] and indicated by
> > '/proc/iomem':
> >
> > # head -1 /proc/iomem
> > 00200000-0021ffff : reserved
>
> You have assumptions about what memstart_addr is based on its name. Names
> of kernel variables get further from their actual use over time.
>
> The purpose of this variable isn't to store where a hypothetical-lowest-page of
> memory would be in the linear map. The kernel doesn't have a handy variable for
> this, because on-one needs to know.
>
>
> > I think reading the kernel code and finding 'memstart_addr' and
> > PHY_OFFSET as 0, one gets the notion
>
> notion -> assumption based on the name
>
> It's just a name. Anyone reading this should grep for how the value is used.
> It's added/subtracted from addresses as part of phys_to_virt()/virt_to_phs(). It
> must be some kind of offset. What does it mean on its own? Probably nothing.
>
>
> > that the base of System RAM starts from 0, which is incorrect in the
> > above case as it starts from 2MB as the 1st block is of the type
> > EfiReservedMemType
>
> What will they assume if the value is negative?
>
> [...]
>
> > So, either we should have a uniform way of representing the virtual
> > base of the linear range
>
> What needs to know this? RAM will be somewhere between PAGE_OFFSET and
> the top of the address space. Anyone who wants to know where has a specific
> page in mind, phys_to_virt() or page_address() tell them where their page is.
>
>
> > or we should rather look at removing the PAGE_OFFSET usage from the
> > kernel (or atleast the confusing comment from 'memory.h')
>
> This?:
> | PAGE_OFFSET - the virtual address of the start of the linear map
>
> Nothing here says its the virtual address of any particular physical page. Its the
> start of the region of VA space that holds the 1:1 mapping of RAM. Its value is
> generated at compile time, we have no idea where RAM will be until we boot,
> how could this be the address of any particular page?
>
>
> > BTW adding 'p2v_offset' as an elf-note seems like a good idea. If this
> > seems suitable, I can try and spin patch(es) using this approach (both
> > for the kernel and user-space tools).
>
> You seem to be using this for user-space phys_to_virt() based on values found in
> /proc/iomem. This should give you what you want, and isolate your user-space
> from the kernel's unexpected naming of variables.
I don't know could I simplify this problem?
Let's ignore what memstart_addr represents here, we just want to implement phys_to_virt() in an userspace applications(kexec-tools or others).
ARM64 Kernel has a below definition:
#define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
So userspace app must know PHYS_OFFSET(equal to memstart_addr now). Seems this is very simple, but memstart_addr has gone through several operations in arm64_memblock_init() depends on different Kernel configurations, so userspace app needs to know many additional definitions as following:
memblock_start_of_DRAM(), (ifdef CONFIG_SPARSEMEM_VMEMMAP), ARM64_MEMSTART_SHIFT, SECTION_SIZE_BITS, PAGE_OFFSET, memblock_end_of_DRAM(),
IS_ENABLED(CONFIG_RANDOMIZE_BASE), memstart_offset_seed.
It is hard to know all above in kexec-tools now. Originally I planned to read memstart_addr's value from "/dev/mem", but someone thought not all Kernels enable "/dev/mem", we'd better find a more generic approach. So we want to get some suggestions from ARM kernel community.
Can we export this variable in Kernel side through sysconf() or other similar methods? Or someone can provide an effect way to get memstart_addr's value?
Thanks,
Yanjiang
>
> I'd suggest a 64bit offset that is added to a physical address to get where in the
> linear map this page would be, if its mapped.
>
>
> Thanks,
>
> James
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.
^ permalink raw reply
* [PATCH] arm64: dts: freescale: Update to use SPDX identifiers
From: Shawn Guo @ 2018-06-19 3:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528828122-9276-1-git-send-email-leoyang.li@nxp.com>
On Tue, Jun 12, 2018 at 01:28:42PM -0500, Li Yang wrote:
> Replace license text with corresponding SPDX identifiers and update the
> format of existing SPDX identifiers to follow the new guideline
> Documentation/process/license-rules.rst.
>
> Note that some of the files mentioned X11 license previously but the
> license text actually matches MIT license.
>
> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 1/2] arm64: dts: uniphier: add headphone detect gpio for LD20 global board
From: Katsuhiro Suzuki @ 2018-06-19 4:11 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds GPIO for headphone detection on LD20 global board.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
index 6a074a20c924..38b75998e2dd 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
@@ -60,6 +60,7 @@
&i2s_port4
&spdif_port0
&comp_spdif_port0>;
+ hp-det-gpio = <&gpio UNIPHIER_GPIO_PORT(15, 0) GPIO_ACTIVE_LOW>;
};
spdif-out {
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: uniphier: add headphone detect gpio for LD11 global board
From: Katsuhiro Suzuki @ 2018-06-19 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619041153.6668-1-suzuki.katsuhiro@socionext.com>
This patch adds GPIO for headphone detection on LD11 global board.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
index 798882cccbd6..e5bda40b3ec6 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
@@ -60,6 +60,7 @@
&i2s_port4
&spdif_port0
&comp_spdif_port0>;
+ hp-det-gpio = <&gpio UNIPHIER_GPIO_PORT(15, 0) GPIO_ACTIVE_LOW>;
};
spdif-out {
--
2.17.1
^ permalink raw reply related
* [PATCH] arm64: dts: uniphier: fix widget name of headphone for LD11/LD20 boards
From: Katsuhiro Suzuki @ 2018-06-19 4:12 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes wrong name of headphone widget for receiving events
of insert/remove headphone plug from simple-card or audio-graph-card.
If we use wrong widget name then we get warning messages such as
"asoc-audio-graph-card sound: ASoC: DAPM unknown pin Headphones"
when the plug is inserted or removed from headphone jack.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 2 +-
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
index e5bda40b3ec6..7cc3f6dd93d9 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
@@ -54,7 +54,7 @@
sound {
compatible = "audio-graph-card";
label = "UniPhier LD11";
- widgets = "Headphone", "Headphone Jack";
+ widgets = "Headphone", "Headphones";
dais = <&i2s_port2
&i2s_port3
&i2s_port4
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
index 38b75998e2dd..575be4ab0072 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
@@ -54,7 +54,7 @@
sound {
compatible = "audio-graph-card";
label = "UniPhier LD20";
- widgets = "Headphone", "Headphone Jack";
+ widgets = "Headphone", "Headphones";
dais = <&i2s_port2
&i2s_port3
&i2s_port4
--
2.17.1
^ permalink raw reply related
* [PATCH v2] dmaengine: ti: omap-dma: Fix OMAP1510 incorrect residue_granularity
From: Vinod @ 2018-06-19 4:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605165957.29616-1-jmkrzyszt@gmail.com>
On 05-06-18, 18:59, Janusz Krzysztofik wrote:
> Commit 0198d7bb8a0c ("ASoC: omap-mcbsp: Convert to use the sdma-pcm
> instead of omap-pcm") resulted in broken audio playback on OMAP1510
> (discovered on Amstrad Delta).
>
> When running on OMAP1510, omap-pcm used to obtain DMA offset from
> snd_dmaengine_pcm_pointer_no_residue() based on DMA interrupt triggered
> software calculations instead of snd_dmaengine_pcm_pointer() which
> depended on residue value calculated from omap_dma_get_src_pos().
> Similar code path is still available in now used
> sound/soc/soc-generic-dmaengine-pcm.c but it is not triggered.
>
> It was verified already before that omap_get_dma_src_pos() from
> arch/arm/plat-omap/dma.c didn't work correctly for OMAP1510 - see
> commit 1bdd7419910c ("ASoC: OMAP: fix OMAP1510 broken PCM pointer
> callback") for details. Apparently the same applies to its successor,
> omap_dma_get_src_pos() from drivers/dma/ti/omap-dma.c.
>
> On the other hand, snd_dmaengine_pcm_pointer_no_residue() is described
> as depreciated and discouraged for use in new drivers because of its
> unreliable accuracy. However, it seems the only working option for
> OPAM1510 now, as long as a software calculated residue is not
> implemented as OMAP1510 fallback in omap-dma.
>
> Using snd_dmaengine_pcm_pointer_no_residue() code path instead of
> snd_dmaengine_pcm_pointer() in sound/soc/soc-generic-dmaengine-pcm.c
> can be triggered in two ways:
> - by passing pcm->flags |= SND_DMAENGINE_PCM_FLAG_NO_RESIDUE from
> sound/soc/omap/sdma-pcm.c,
> - by passing dma_caps.residue_granularity =
> DMA_RESIDUE_GRANULARITY_DESCRIPTOR from DMA engine.
>
> Let's do the latter.
>
> Created and tested against next-20180531 tag from linux-next tree.
This is not useful for log.
I have stripped this and applied
--
~Vinod
^ permalink raw reply
* [PATCH] MAINTAINERS: Update email-id of Sinan Kaya
From: Vinod @ 2018-06-19 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528983482-31028-1-git-send-email-okaya@codeaurora.org>
On 14-06-18, 09:37, Sinan Kaya wrote:
> I'm no longer with QCOM. I am still interested in maintaining or reviewing
> PCI/DMA engine patches. Update email-id to an active one.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH] serial: mps2-uart: Initialize early console
From: Guenter Roeck @ 2018-06-19 4:54 UTC (permalink / raw)
To: linux-arm-kernel
The early console code for mps2-uart assumes that the serial hardware is
enabled for transmit when the system boots. However, this is not the case
after reset. This results in a hang in mps2_early_putchar() if the serial
transmitter is not enabled by a boot loader or ROM monitor.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/tty/serial/mps2-uart.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
index 9f8f63719126..0743a0551ce1 100644
--- a/drivers/tty/serial/mps2-uart.c
+++ b/drivers/tty/serial/mps2-uart.c
@@ -448,6 +448,14 @@ static struct console mps2_uart_console = {
#define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
+static void mps2_early_init(struct uart_port *port)
+{
+ u8 control = readb(port->membase + UARTn_CTRL);
+
+ control |= UARTn_CTRL_TX_ENABLE;
+ writeb(control, port->membase + UARTn_CTRL);
+}
+
static void mps2_early_putchar(struct uart_port *port, int ch)
{
while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
@@ -469,6 +477,7 @@ static int __init mps2_early_console_setup(struct earlycon_device *device,
if (!device->port.membase)
return -ENODEV;
+ mps2_early_init(&device->port);
device->con->write = mps2_early_write;
return 0;
--
2.7.4
^ permalink raw reply related
* [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation
From: Guenter Roeck @ 2018-06-19 5:07 UTC (permalink / raw)
To: linux-arm-kernel
Modern assemblers may take the ISA into account when resolving local
symbols. This can result in bad address calculations when using badr
in the wrong location since the offset + 1 may be added twice, resulting
in an even address target for THUMB instructions. This in turn results
in an exception at (destination address + 2).
Unhandled exception: IPSR = 00000006 LR = fffffff1
CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
Hardware name: MPS2 (Device Tree Support)
PC is at ret_fast_syscall+0x2/0x58
LR is at tty_ioctl+0x2a5/0x528
pc : [<21009002>] lr : [<210d1535>] psr: 4000000b
sp : 21825fa8 ip : 0000001c fp : 21a95892
r10: 00000000 r9 : 21824000 r8 : 210091c0
r7 : 00000036 r6 : 21ae1ee0 r5 : 00000000 r4 : 21ae1f3c
r3 : 00000000 r2 : 3d9adc25 r1 : 00000000 r0 : 00000000
xPSR: 4000000b
CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
Hardware name: MPS2 (Device Tree Support)
[<2100bd8d>] (unwind_backtrace) from [<2100b13b>] (show_stack+0xb/0xc)
[<2100b13b>] (show_stack) from [<2100b87b>] (__invalid_entry+0x4b/0x4c)
Fix the problem by using a logical or instead of an addition. This is
less efficient but guaranteed to work.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
RFC: I don't really like this, but my ARM assembler knowledge is quite
limited. Just dropping the "+ 1" from badr doesn't work because some
other code needs it (the image hangs completely if I try that).
Ultimately I don't even know if the invoke_syscall macro should just
have used adr instead of badr (but then how did this ever work ?).
Seen with various toolchains based on gcc 7.x and binutils 2.30 when
building and testing MPS2 images.
arch/arm/include/asm/assembler.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 0cd4dccbae78..24c87ff2060f 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -195,7 +195,8 @@
.irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
.macro badr\c, rd, sym
#ifdef CONFIG_THUMB2_KERNEL
- adr\c \rd, \sym + 1
+ adr\c \rd, \sym
+ orr \rd, #1
#else
adr\c \rd, \sym
#endif
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] net: emaclite: Balance braces in else statement
From: Radhey Shyam Pandey @ 2018-06-19 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <644296b273a76469baf641dd712c7a5451cd34fe.camel@perches.com>
> -----Original Message-----
> From: Joe Perches [mailto:joe at perches.com]
> Sent: Monday, June 18, 2018 9:33 PM
> To: Radhey Shyam Pandey <radheys@xilinx.com>; davem at davemloft.net;
> andrew at lunn.ch; Michal Simek <michals@xilinx.com>
> Cc: netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH 2/5] net: emaclite: Balance braces in else statement
>
> On Mon, 2018-06-18 at 17:20 +0530, Radhey Shyam Pandey wrote:
> > Remove else as it is not required with if doing a return.
> > Fixes below checkpatch warning.
>
> > WARNING: else is not generally useful after a break or return
>
> checkpatch is stupid and doesn't understand code flow.
> Always try to improve code flow instead of merely
> following brainless instructions from a script.
>
> So:
>
> > diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> []
> > @@ -569,13 +569,11 @@ static void xemaclite_tx_handler(struct net_device
> *dev)
> > (u8 *) lp->deferred_skb->data,
> > lp->deferred_skb->len) != 0)
> > return;
> > - else {
> > - dev->stats.tx_bytes += lp->deferred_skb->len;
> > - dev_kfree_skb_irq(lp->deferred_skb);
> > - lp->deferred_skb = NULL;
> > - netif_trans_update(dev); /* prevent tx timeout */
> > - netif_wake_queue(dev);
> > - }
> > + dev->stats.tx_bytes += lp->deferred_skb->len;
> > + dev_kfree_skb_irq(lp->deferred_skb);
> > + lp->deferred_skb = NULL;
> > + netif_trans_update(dev); /* prevent tx timeout */
> > + netif_wake_queue(dev);
> > }
> > }
>
> If you really want to redo this function, perhaps something like:
Thanks for the review. Yes, In v2 I will refactor the code to have
failure path return early.
>
> static void xemaclite_tx_handler(struct net_device *dev)
> {
> struct net_local *lp = netdev_priv(dev);
>
> dev->stats.tx_packets++;
>
> if (!lp->deferred_skb)
> return;
>
> if (xemaclite_send_data(lp, (u8 *)lp->deferred_skb->data,
> lp->deferred_skb->len))
> return;
>
> dev->stats.tx_bytes += lp->deferred_skb->len;
> dev_kfree_skb_irq(lp->deferred_skb);
> lp->deferred_skb = NULL;
> netif_trans_update(dev); /* prevent tx timeout */
> netif_wake_queue(dev);
> }
>
> > @@ -1052,13 +1050,13 @@ static bool get_bool(struct platform_device
> *ofdev, const char *s)
> > {
> > u32 *p = (u32 *)of_get_property(ofdev->dev.of_node, s, NULL);
> >
> > - if (p) {
> > + if (p)
> > return (bool)*p;
> > - } else {
> > - dev_warn(&ofdev->dev, "Parameter %s not found,"
> > +
> > + dev_warn(&ofdev->dev, "Parameter %s not found,"
> > "defaulting to false\n", s);
> > - return false;
> > - }
> > +
> > + return false;
> > }
>
> And this function has backward logic as the failure paths
> are the ones that should return early or use a goto.
>
> Perhaps something like:
Yes, will change it.
>
> static bool get_bool(struct platform_device *ofdev, const char *s)
> {
> u32 *p = (u32 *)of_get_property(ofdev->dev.of_node, s, NULL);
>
> if (!p) {
> dev_warn(&ofdev->dev,
> "Parameter '%s' not found, defaulting to false\n", s);
> return false;
> }
>
> return *p;
> }
^ permalink raw reply
* [PATCH] crypto: arm/speck - fix building in Thumb2 mode
From: Ard Biesheuvel @ 2018-06-19 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618223323.130072-1-ebiggers@google.com>
On 19 June 2018 at 00:33, Eric Biggers <ebiggers@google.com> wrote:
> Building the kernel with CONFIG_THUMB2_KERNEL=y and
> CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
>
> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>
> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here -- `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here -- `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here -- `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here -- `bic sp,#0xf'
>
> The problem is that the 'bic' instruction can't operate on the 'sp'
> register in Thumb2 mode. Fix it by using a temporary register. This
> isn't in the main loop, so the performance difference is negligible.
> This also matches what aes-neonbs-core.S does.
>
> Reported-by: Stefan Agner <stefan@agner.ch>
> Fixes: ede9622162fa ("crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS")
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> arch/arm/crypto/speck-neon-core.S | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/crypto/speck-neon-core.S b/arch/arm/crypto/speck-neon-core.S
> index 3c1e203e53b9..57caa742016e 100644
> --- a/arch/arm/crypto/speck-neon-core.S
> +++ b/arch/arm/crypto/speck-neon-core.S
> @@ -272,9 +272,11 @@
> * Allocate stack space to store 128 bytes worth of tweaks. For
> * performance, this space is aligned to a 16-byte boundary so that we
> * can use the load/store instructions that declare 16-byte alignment.
> + * For Thumb2 compatibility, don't do the 'bic' directly on 'sp'.
> */
> - sub sp, #128
> - bic sp, #0xf
> + sub r12, sp, #128
> + bic r12, #0xf
> + mov sp, r12
>
> .if \n == 64
> // Load first tweak
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
^ permalink raw reply
* [PATCH v2] ARM: dts: imx6sx: fix irq for pcie bridge
From: Shawn Guo @ 2018-06-19 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615074129.16931-1-o.rempel@pengutronix.de>
On Fri, Jun 15, 2018 at 09:41:29AM +0200, Oleksij Rempel wrote:
> Use the correct IRQ line for the MSI controller in the PCIe host
> controller. Apparently a different IRQ line is used compared to other
> i.MX6 variants. Without this change MSI IRQs aren't properly propagated
> to the upstream interrupt controller.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Added the following Fixes tag and applied as a fix.
Fixes: b1d17f68e5c5 ("ARM: dts: imx: add initial imx6sx device tree source")
Shawn
^ 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