* [PATCH v2 7/9] ARM: dts: imx7d-pico: Extend peripherals support
From: Otavio Salvador @ 2018-12-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Shawn Guo,
Sascha Hauer, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Fabio Estevam
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
From: Fabio Estevam <festevam@gmail.com>
This extends the peripherals supported by the imx7d-pico.dtsi. It
adds:
- I2C2
- Flexcan (flexcan1 and flexcan2 ports)
- USDHC1
- UART (6 and 7 ports)
- PWM (4 ports)
- eCSPI3
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2:
- replace fsl,uart-has-rtscts with uart-has-rtscts
arch/arm/boot/dts/imx7d-pico.dtsi | 183 ++++++++++++++++++++++++++++++
1 file changed, 183 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi
index 417f034fb354..3fd595a71202 100644
--- a/arch/arm/boot/dts/imx7d-pico.dtsi
+++ b/arch/arm/boot/dts/imx7d-pico.dtsi
@@ -78,6 +78,13 @@
assigned-clock-rates = <0>, <32768>;
};
+&ecspi3 {
+ cs-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+};
+
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
@@ -103,6 +110,18 @@
};
};
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+ status = "okay";
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can2>;
+ status = "okay";
+};
+
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
@@ -110,6 +129,12 @@
status = "okay";
};
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
&i2c4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c4>;
@@ -215,6 +240,29 @@
status = "okay";
};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+ status = "okay";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+ status = "okay";
+};
+
+&pwm4 { /* Backlight */
+ status = "okay";
+};
+
&uart5 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart5>;
@@ -223,6 +271,24 @@
status = "okay";
};
+&uart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart6>;
+ assigned-clocks = <&clks IMX7D_UART6_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&uart7 { /* Bluetooth */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ assigned-clocks = <&clks IMX7D_UART7_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
&usbotg1 {
vbus-supply = <®_usb_otg1_vbus>;
status = "okay";
@@ -234,6 +300,21 @@
status = "okay";
};
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ tuning-step = <2>;
+ vmmc-supply = <®_3p3v>;
+ wakeup-source;
+ no-1-8-v;
+ keep-power-in-suspend;
+ status = "okay";
+};
+
&usdhc2 { /* Wifi SDIO */
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc2 &pinctrl_wifi_clk>;
@@ -268,6 +349,15 @@
};
&iomuxc {
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX7D_PAD_I2C1_SCL__ECSPI3_MISO 0x2
+ MX7D_PAD_I2C1_SDA__ECSPI3_MOSI 0x2
+ MX7D_PAD_I2C2_SCL__ECSPI3_SCLK 0x2
+ MX7D_PAD_I2C2_SDA__GPIO4_IO11 0x14
+ >;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX7D_PAD_UART1_TX_DATA__I2C1_SDA 0x4000007f
@@ -275,6 +365,13 @@
>;
};
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX7D_PAD_UART2_TX_DATA__I2C2_SDA 0x4000007f
+ MX7D_PAD_UART2_RX_DATA__I2C2_SCL 0x4000007f
+ >;
+ };
+
pinctrl_enet1: enet1grp {
fsl,pins = <
MX7D_PAD_SD2_CD_B__ENET1_MDIO 0x3
@@ -295,6 +392,20 @@
>;
};
+ pinctrl_can1: can1frp {
+ fsl,pins = <
+ MX7D_PAD_SAI1_RX_DATA__FLEXCAN1_RX 0x59
+ MX7D_PAD_SAI1_TX_BCLK__FLEXCAN1_TX 0x59
+ >;
+ };
+
+ pinctrl_can2: can2frp {
+ fsl,pins = <
+ MX7D_PAD_SAI1_TX_SYNC__FLEXCAN2_RX 0x59
+ MX7D_PAD_SAI1_TX_DATA__FLEXCAN2_TX 0x59
+ >;
+ };
+
pinctrl_i2c4: i2c4grp {
fsl,pins = <
MX7D_PAD_SAI1_RX_BCLK__I2C4_SDA 0x4000007f
@@ -302,6 +413,24 @@
>;
};
+ pinctrl_pwm1: pwm1 {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO08__PWM1_OUT 0x7f
+ >;
+ };
+
+ pinctrl_pwm2: pwm2 {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO09__PWM2_OUT 0x7f
+ >;
+ };
+
+ pinctrl_pwm3: pwm3 {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO10__PWM3_OUT 0x7f
+ >;
+ };
+
pinctrl_reg_wlreg_on: regregongrp {
fsl,pins = <
MX7D_PAD_ECSPI1_SCLK__GPIO4_IO16 0x59
@@ -324,12 +453,66 @@
>;
};
+ pinctrl_uart6: uart6grp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA08__UART6_DCE_RX 0x79
+ MX7D_PAD_EPDC_DATA09__UART6_DCE_TX 0x79
+ MX7D_PAD_EPDC_DATA10__UART6_DCE_RTS 0x79
+ MX7D_PAD_EPDC_DATA11__UART6_DCE_CTS 0x79
+ >;
+ };
+
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <
+ MX7D_PAD_ECSPI2_MOSI__UART7_DCE_TX 0x79
+ MX7D_PAD_ECSPI2_SCLK__UART7_DCE_RX 0x79
+ MX7D_PAD_ECSPI2_SS0__UART7_DCE_CTS 0x79
+ MX7D_PAD_ECSPI2_MISO__UART7_DCE_RTS 0x79
+ >;
+ };
+
pinctrl_usbotg1_pwr: usbotg_pwr {
fsl,pins = <
MX7D_PAD_UART3_TX_DATA__GPIO4_IO5 0x14
>;
};
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x59
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x19
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x59
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x59
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x59
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x59
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x15
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x5a
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x1a
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5a
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5a
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5a
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5a
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x15
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x5b
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x1b
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5b
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5b
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5b
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5b
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x15
+ >;
+ };
+
pinctrl_usdhc2: usdhc2grp {
fsl,pins = <
MX7D_PAD_SD2_CMD__SD2_CMD 0x59
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 9/9] ARM: dts: imx7d-pico: Add the imx7d-pico-hobbit variant
From: Otavio Salvador @ 2018-12-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Shawn Guo,
Sascha Hauer, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Fabio Estevam
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
From: Fabio Estevam <festevam@gmail.com>
The imx7d-pico-hobbit contains a imx7d-pico SoM and a hobbit baseboard.
Add support for it.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx7d-pico-hobbit.dts | 105 ++++++++++++++++++++++++
2 files changed, 106 insertions(+)
create mode 100644 arch/arm/boot/dts/imx7d-pico-hobbit.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1d6d916c2195..5c7dc0b4aaa8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -572,6 +572,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-colibri-emmc-eval-v3.dtb \
imx7d-colibri-eval-v3.dtb \
imx7d-nitrogen7.dtb \
+ imx7d-pico-hobbit.dtb \
imx7d-pico-pi.dtb \
imx7d-sbc-imx7.dtb \
imx7d-sdb.dtb \
diff --git a/arch/arm/boot/dts/imx7d-pico-hobbit.dts b/arch/arm/boot/dts/imx7d-pico-hobbit.dts
new file mode 100644
index 000000000000..7b2198a9372c
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-pico-hobbit.dts
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+//
+// Copyright 2017 NXP
+
+#include "imx7d-pico.dtsi"
+
+/ {
+ model = "TechNexion PICO-IMX7D Board using Hobbit baseboard";
+ compatible = "technexion,imx7d-pico-hobbit", "fsl,imx7d";
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led {
+ label = "gpio-led";
+ gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "imx7-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&dailink_master>;
+ simple-audio-card,frame-master = <&dailink_master>;
+ simple-audio-card,cpu {
+ sound-dai = <&sai1>;
+ };
+
+ dailink_master: simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ };
+ };
+};
+
+&i2c1 {
+ sgtl5000: codec@a {
+ #sound-dai-cells = <0>;
+ reg = <0x0a>;
+ compatible = "fsl,sgtl5000";
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ VDDA-supply = <®_2p5v>;
+ VDDIO-supply = <®_vref_1v8>;
+ };
+};
+
+&i2c4 {
+ status = "okay";
+
+ adc081c: adc@50 {
+ compatible = "ti,adc081c";
+ reg = <0x50>;
+ vref-supply = <®_3p3v>;
+ };
+};
+
+&ecspi3 {
+ ads7846@0 {
+ reg = <0>;
+ compatible = "ti,ads7846";
+ interrupt-parent = <&gpio2>;
+ interrupts = <7 0>;
+ spi-max-frequency = <1000000>;
+ pendown-gpio = <&gpio2 7 0>;
+ vcc-supply = <®_3p3v>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <4095>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4095>;
+ ti,pressure-max = /bits/ 16 <1024>;
+ ti,x-plate-ohms = /bits/ 16 <90>;
+ ti,y-plate-ohms = /bits/ 16 <90>;
+ ti,debounce-max = /bits/ 16 <70>;
+ ti,debounce-tol = /bits/ 16 <3>;
+ ti,debounce-rep = /bits/ 16 <2>;
+ ti,settle-delay-usec = /bits/ 16 <150>;
+ wakeup-source;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA00__GPIO2_IO0 0x14
+ MX7D_PAD_EPDC_DATA01__GPIO2_IO1 0x14
+ MX7D_PAD_EPDC_DATA02__GPIO2_IO2 0x14
+ MX7D_PAD_EPDC_DATA03__GPIO2_IO3 0x14
+ MX7D_PAD_EPDC_DATA05__GPIO2_IO5 0x14
+ MX7D_PAD_EPDC_DATA12__GPIO2_IO12 0x14
+ MX7D_PAD_EPDC_DATA07__GPIO2_IO7 0x14
+ >;
+ };
+
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA13__GPIO2_IO13 0x14
+ >;
+ };
+};
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 2/5] devfreq: add support for suspend/resume of a devfreq device
From: Lukasz Luba @ 2018-12-06 10:13 UTC (permalink / raw)
To: Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pm, devicetree
Cc: mark.rutland, len.brown, tony.luck, keescook, b.zolnierkie,
gregkh, anton, rjw, robh+dt, tjakobi, kyungmin.park, myungjoo.ham,
kgene, pavel, ccross, krzk, m.szyprowski
In-Reply-To: <5C0878C0.4060500@samsung.com>
Hi Chanwoo,
On 12/6/18 2:17 AM, Chanwoo Choi wrote:
> Hi Lukasz,
>
> On 2018년 12월 05일 20:05, Lukasz Luba wrote:
>> The patch prepares devfreq device for handling suspend/resume
>> functionality. The new fields will store needed information during this
>> process. Devfreq framework handles opp-suspend DT entry and there is no
>> need of modyfications in the drivers code. It uses atomic variables to
>> make sure no race condition affects the process.
>>
>> Suggested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
>> Suggested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>> ---
>> drivers/devfreq/devfreq.c | 47 +++++++++++++++++++++++++++++++++++++++++------
>> include/linux/devfreq.h | 7 +++++++
>> 2 files changed, 48 insertions(+), 6 deletions(-)
>
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Thank you for the review and comments for the whole patch series.
Regards,
Lukasz
>
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index a9fd61b..46517b6 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -316,6 +316,10 @@ static int devfreq_set_target(struct devfreq *devfreq, unsigned long new_freq,
>> "Couldn't update frequency transition information.\n");
>>
>> devfreq->previous_freq = new_freq;
>> +
>> + if (devfreq->suspend_freq)
>> + devfreq->resume_freq = cur_freq;
>> +
>> return err;
>> }
>>
>> @@ -667,6 +671,9 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> }
>> devfreq->max_freq = devfreq->scaling_max_freq;
>>
>> + devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
>> + atomic_set(&devfreq->suspend_count, 0);
>> +
>> dev_set_name(&devfreq->dev, "devfreq%d",
>> atomic_inc_return(&devfreq_no));
>> err = device_register(&devfreq->dev);
>> @@ -867,14 +874,28 @@ EXPORT_SYMBOL(devm_devfreq_remove_device);
>> */
>> int devfreq_suspend_device(struct devfreq *devfreq)
>> {
>> + int ret;
>> +
>> if (!devfreq)
>> return -EINVAL;
>>
>> - if (!devfreq->governor)
>> + if (atomic_inc_return(&devfreq->suspend_count) > 1)
>> return 0;
>>
>> - return devfreq->governor->event_handler(devfreq,
>> - DEVFREQ_GOV_SUSPEND, NULL);
>> + if (devfreq->governor) {
>> + ret = devfreq->governor->event_handler(devfreq,
>> + DEVFREQ_GOV_SUSPEND, NULL);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + if (devfreq->suspend_freq) {
>> + ret = devfreq_set_target(devfreq, devfreq->suspend_freq, 0);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + return 0;
>> }
>> EXPORT_SYMBOL(devfreq_suspend_device);
>>
>> @@ -888,14 +909,28 @@ EXPORT_SYMBOL(devfreq_suspend_device);
>> */
>> int devfreq_resume_device(struct devfreq *devfreq)
>> {
>> + int ret;
>> +
>> if (!devfreq)
>> return -EINVAL;
>>
>> - if (!devfreq->governor)
>> + if (atomic_dec_return(&devfreq->suspend_count) >= 1)
>> return 0;
>>
>> - return devfreq->governor->event_handler(devfreq,
>> - DEVFREQ_GOV_RESUME, NULL);
>> + if (devfreq->resume_freq) {
>> + ret = devfreq_set_target(devfreq, devfreq->resume_freq, 0);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + if (devfreq->governor) {
>> + ret = devfreq->governor->event_handler(devfreq,
>> + DEVFREQ_GOV_RESUME, NULL);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + return 0;
>> }
>> EXPORT_SYMBOL(devfreq_resume_device);
>>
>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>> index e4963b0..d985199 100644
>> --- a/include/linux/devfreq.h
>> +++ b/include/linux/devfreq.h
>> @@ -131,6 +131,9 @@ struct devfreq_dev_profile {
>> * @scaling_min_freq: Limit minimum frequency requested by OPP interface
>> * @scaling_max_freq: Limit maximum frequency requested by OPP interface
>> * @stop_polling: devfreq polling status of a device.
>> + * @suspend_freq: frequency of a device set during suspend phase.
>> + * @resume_freq: frequency of a device set in resume phase.
>> + * @suspend_count: suspend requests counter for a device.
>> * @total_trans: Number of devfreq transitions
>> * @trans_table: Statistics of devfreq transitions
>> * @time_in_state: Statistics of devfreq states
>> @@ -167,6 +170,10 @@ struct devfreq {
>> unsigned long scaling_max_freq;
>> bool stop_polling;
>>
>> + unsigned long suspend_freq;
>> + unsigned long resume_freq;
>> + atomic_t suspend_count;
>> +
>> /* information for device frequency transition */
>> unsigned int total_trans;
>> unsigned int *trans_table;
>>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 05/25] kasan: add CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS
From: Andrey Konovalov @ 2018-12-06 10:19 UTC (permalink / raw)
To: Max Filippov
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION,
Catalin Marinas, Will Deacon, Paul Lawrence,
Linux Memory Management List, Alexander Potapenko, Chintan Pandya,
Christoph Lameter, Ingo Molnar, Jacob Bramley, Ruben Ayrapetyan,
Mark Brand, kasan-dev, linux-sparse, Geert Uytterhoeven,
Linux ARM, Andrey Ryabinin, Dave Martin, Evgenii Stepanov,
Vishwath Mohan, Arnd Bergmann, Linux Kbuild mailing list,
Marc Zyngier, Ramana Radhakrishnan, Mike Rapoport, Dmitry Vyukov,
Kostya Serebryany, Jann Horn, Ard Biesheuvel, Greg Kroah-Hartman,
Nick Desaulniers, LKML, Eric W . Biederman, Lee Smith,
Andrew Morton, Kirill A. Shutemov
In-Reply-To: <CAMo8BfK5aEGae--xvboLxMXTe1orA7kmLR_uFNCqC6M-a=Om5Q@mail.gmail.com>
On Tue, Dec 4, 2018 at 11:24 PM Max Filippov <jcmvbkbc@gmail.com> wrote:
>
> Hello,
>
> On Tue, Nov 27, 2018 at 9:00 AM Andrey Konovalov <andreyknvl@google.com> wrote:
> >
> > This commit splits the current CONFIG_KASAN config option into two:
> > 1. CONFIG_KASAN_GENERIC, that enables the generic KASAN mode (the one
> > that exists now);
> > 2. CONFIG_KASAN_SW_TAGS, that enables the software tag-based KASAN mode.
>
> [...]
>
> > --- a/lib/Kconfig.kasan
> > +++ b/lib/Kconfig.kasan
> > @@ -1,35 +1,95 @@
> > +# This config refers to the generic KASAN mode.
> > config HAVE_ARCH_KASAN
> > bool
> >
> > +config HAVE_ARCH_KASAN_SW_TAGS
> > + bool
> > +
> > +config CC_HAS_KASAN_GENERIC
> > + def_bool $(cc-option, -fsanitize=kernel-address)
> > +
> > +config CC_HAS_KASAN_SW_TAGS
> > + def_bool $(cc-option, -fsanitize=kernel-hwaddress)
> > +
> > if HAVE_ARCH_KASAN
> >
> > config KASAN
> > - bool "KASan: runtime memory debugger"
> > + bool "KASAN: runtime memory debugger"
> > + help
> > + Enables KASAN (KernelAddressSANitizer) - runtime memory debugger,
> > + designed to find out-of-bounds accesses and use-after-free bugs.
> > + See Documentation/dev-tools/kasan.rst for details.
>
> Perhaps KASAN should depend on
> CC_HAS_KASAN_GENERIC || CC_HAS_KASAN_SW_TAGS,
> otherwise make all*config may enable KASAN
> for a compiler that does not have any -fsanitize=kernel-*address
> support, resulting in build failures like this:
> http://kisskb.ellerman.id.au/kisskb/buildresult/13606170/log/
Will fix in v13, thanks!
>
> --
> Thanks.
> -- Max
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to kasan-dev@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/CAMo8BfK5aEGae--xvboLxMXTe1orA7kmLR_uFNCqC6M-a%3DOm5Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 23/25] kasan, arm64: select HAVE_ARCH_KASAN_SW_TAGS
From: Andrey Konovalov @ 2018-12-06 10:19 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION,
Catalin Marinas, Paul Lawrence, Linux Memory Management List,
Alexander Potapenko, Chintan Pandya, Christoph Lameter,
Ingo Molnar, Jacob Bramley, Ruben Ayrapetyan, Mark Brand,
kasan-dev, linux-sparse, Geert Uytterhoeven, Linux ARM,
Andrey Ryabinin, Dave Martin, Evgenii Stepanov, Vishwath Mohan,
Arnd Bergmann, Linux Kbuild mailing list, Marc Zyngier,
Ramana Radhakrishnan, Mike Rapoport, Dmitry Vyukov,
Kostya Serebryany, Jann Horn, Ard Biesheuvel, Greg Kroah-Hartman,
Nick Desaulniers, LKML, Eric W . Biederman, Lee Smith,
Andrew Morton, Kirill A. Shutemov
In-Reply-To: <20181129180134.GA4318@arm.com>
On Thu, Nov 29, 2018 at 7:01 PM Will Deacon <will.deacon@arm.com> wrote:
>
> On Tue, Nov 27, 2018 at 05:55:41PM +0100, Andrey Konovalov wrote:
> > Now, that all the necessary infrastructure code has been introduced,
> > select HAVE_ARCH_KASAN_SW_TAGS for arm64 to enable software tag-based
> > KASAN mode.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> > arch/arm64/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 787d7850e064..8b331dcfb48e 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -111,6 +111,7 @@ config ARM64
> > select HAVE_ARCH_JUMP_LABEL
> > select HAVE_ARCH_JUMP_LABEL_RELATIVE
> > select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
> > + select HAVE_ARCH_KASAN_SW_TAGS if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
>
> Can you do if HAVE_ARCH_KASAN instead?
Will do in v13, thanks!
>
> Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] PCI: imx: Add support for i.MX8MQ
From: Lucas Stach @ 2018-12-06 10:23 UTC (permalink / raw)
To: Andrey Smirnov, linux-pci
Cc: A.s. Dong, Mark Rutland, Richard Zhu, Rob Herring, linux-kernel,
Fabio Estevam, devicetree, linux-imx, bhelgaas, Leonard Crestez,
cphealy, linux-arm-kernel
In-Reply-To: <20181206073545.10967-4-andrew.smirnov@gmail.com>
Am Mittwoch, den 05.12.2018, 23:35 -0800 schrieb Andrey Smirnov:
> Add code needed to support i.MX8MQ variant.
>
> Cc: bhelgaas@google.com
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: cphealy@gmail.com
> Cc: l.stach@pengutronix.de
> > Cc: Leonard Crestez <leonard.crestez@nxp.com>
> > Cc: "A.s. Dong" <aisheng.dong@nxp.com>
> > Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-imx@nxp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> .../bindings/pci/fsl,imx6q-pcie.txt | 6 +-
> drivers/pci/controller/dwc/Kconfig | 2 +-
> drivers/pci/controller/dwc/pci-imx6.c | 85 +++++++++++++++++--
> 3 files changed, 86 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index f37494d5a7be..40b46d11e7e7 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -9,6 +9,7 @@ Required properties:
> > - "fsl,imx6sx-pcie",
> > - "fsl,imx6qp-pcie"
> > - "fsl,imx7d-pcie"
> > + - "fsl,imx8mq-pcie"
> - reg: base address and length of the PCIe controller
> - interrupts: A list of interrupt outputs of the controller. Must contain an
> entry for each entry in the interrupt-names property.
> @@ -43,7 +44,7 @@ Additional required properties for imx6sx-pcie:
> > - "pcie_inbound_axi"
> - power-domains: Must be set to a phandle pointing to the PCIE_PHY power domain
>
> -Additional required properties for imx7d-pcie:
> +Additional required properties for imx7d-pcie and imx8mq-pcie:
> - power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
> - resets: Must contain phandles to PCIe-related reset lines exposed by SRC
> IP block
> @@ -52,6 +53,9 @@ Additional required properties for imx7d-pcie:
> > - "apps"
> > - "turnoff"
>
> +Additional required properties for imx8mq-pcie:
> +- fsl,controller-id: Logical ID of a given PCIE controller. PCIE1 is 0, PCIE2 is 1;
> +
> Example:
>
> > pcie@01000000 {
> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> index 91b0194240a5..2b139acccf32 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -90,7 +90,7 @@ config PCI_EXYNOS
>
> config PCI_IMX6
> > bool "Freescale i.MX6 PCIe controller"
> > - depends on SOC_IMX6Q || (ARM && COMPILE_TEST)
> > + depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
> > depends on PCI_MSI_IRQ_DOMAIN
> > select PCIE_DW_HOST
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 3c3002861d25..326f71698ac2 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -8,6 +8,7 @@
> > * Author: Sean Cross <xobs@kosagi.com>
> */
>
> +#include <linux/bitfield.h>
> #include <linux/clk.h>
> #include <linux/delay.h>
> #include <linux/gpio.h>
> @@ -30,6 +31,11 @@
>
> #include "pcie-designware.h"
>
> > +#define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
> > +#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN BIT(10)
> > +#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE BIT(11)
> > +#define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE GENMASK(11, 8)
> +
> > #define to_imx6_pcie(x) dev_get_drvdata((x)->dev)
>
> enum imx6_pcie_variants {
> @@ -37,6 +43,7 @@ enum imx6_pcie_variants {
> > IMX6SX,
> > IMX6QP,
> > IMX7D,
> > + IMX8MQ,
> };
>
> struct imx6_pcie {
> @@ -48,6 +55,7 @@ struct imx6_pcie {
> > > struct clk *pcie_inbound_axi;
> > > struct clk *pcie;
> > > struct regmap *iomuxc_gpr;
> > > + u32 controller_id;
> > > struct reset_control *pciephy_reset;
> > > struct reset_control *apps_reset;
> > > struct reset_control *turnoff_reset;
> @@ -245,7 +253,8 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
> {
> > u32 tmp;
>
> > - if (imx6_pcie->variant == IMX7D)
> > + if (imx6_pcie->variant == IMX7D ||
> > + imx6_pcie->variant == IMX8MQ)
> > return;
>
> > pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, &tmp);
> @@ -261,6 +270,7 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
> > pcie_phy_write(imx6_pcie, PHY_RX_OVRD_IN_LO, tmp);
> }
>
> +#ifdef CONFIG_ARM
> /* Added for PCI abort handling */
> static int imx6q_pcie_abort_handler(unsigned long addr,
> > unsigned int fsr, struct pt_regs *regs)
> @@ -294,6 +304,7 @@ static int imx6q_pcie_abort_handler(unsigned long addr,
>
> > return 1;
> }
> +#endif
>
> static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
> {
> @@ -301,6 +312,7 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
>
> > switch (imx6_pcie->variant) {
> > case IMX7D:
> > + case IMX8MQ: /* FALLTHROUGH */
> > reset_control_assert(imx6_pcie->pciephy_reset);
> > reset_control_assert(imx6_pcie->apps_reset);
> > break;
> @@ -339,6 +351,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> {
> > struct dw_pcie *pci = imx6_pcie->pci;
> > struct device *dev = pci->dev;
> > + unsigned int offset;
> > int ret = 0;
>
> > switch (imx6_pcie->variant) {
> @@ -369,6 +382,29 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> > break;
> > case IMX7D:
> > break;
> > + case IMX8MQ:
> > + switch (imx6_pcie->controller_id) {
> > + case 0:
> > + offset = IOMUXC_GPR14;
> > + break;
> > + case 1:
> > + offset = IOMUXC_GPR16;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> +
> > + /*
> > + * Set the over ride low and enabled
> > + * make sure that REF_CLK is turned on.
> > + */
> > + regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > + IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> > + 0);
> > + regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > + IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> > + IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> > + break;
> > }
>
> > return ret;
> @@ -445,6 +481,9 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
> > }
>
> > switch (imx6_pcie->variant) {
> > + case IMX8MQ:
> > + reset_control_deassert(imx6_pcie->pciephy_reset);
> > + break;
> > case IMX7D:
> > reset_control_deassert(imx6_pcie->pciephy_reset);
> > imx7d_pcie_wait_for_phy_pll_lock(imx6_pcie);
> @@ -482,7 +521,34 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
>
> static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
> {
> > + unsigned int mask, val, offset;
> +
> > + mask = IMX6Q_GPR12_DEVICE_TYPE;
> > + val = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, PCI_EXP_TYPE_ROOT_PORT);
> +
> > switch (imx6_pcie->variant) {
> > + case IMX8MQ:
> > + switch (imx6_pcie->controller_id) {
> > + case 0:
> > + offset = IOMUXC_GPR14;
> > + break;
> > + case 1:
> > + offset = IOMUXC_GPR16;
> > + mask = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE;
> > + val = FIELD_PREP(IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
> > + PCI_EXP_TYPE_ROOT_PORT);
> > + break;
> > + default:
> > + return;
> > + }
> > + /*
> > + * TODO: Currently this code assumes external
> > + * oscillator is being used
> > + */
> > + regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> > + IMX8MQ_GPR_PCIE_REF_USE_PAD,
> > + IMX8MQ_GPR_PCIE_REF_USE_PAD);
> > + break;
> > case IMX7D:
> > regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> > IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
> @@ -518,8 +584,7 @@ static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
> > break;
> > }
>
> > - regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> > - IMX6Q_GPR12_DEVICE_TYPE, PCI_EXP_TYPE_ROOT_PORT << 12);
> > + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, mask, val);
> }
>
> static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
> @@ -528,7 +593,8 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
> > int mult, div;
> > u32 val;
>
> > - if (imx6_pcie->variant == IMX7D)
> > + if (imx6_pcie->variant == IMX7D ||
> > + imx6_pcie->variant == IMX8MQ)
> > return 0;
>
> > switch (phy_rate) {
> @@ -616,6 +682,7 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
> > IMX6Q_GPR12_PCIE_CTL_2);
> > break;
> > case IMX7D:
> > > + case IMX8MQ: /* FALLTHROUGH */
> > reset_control_deassert(imx6_pcie->apps_reset);
> > break;
> > }
> @@ -870,6 +937,10 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> > imx6_pcie->variant =
> > (enum imx6_pcie_variants)of_device_get_match_data(dev);
>
> > + if (of_property_read_u32(node, "fsl,controller-id",
> > + &imx6_pcie->controller_id))
> > + imx6_pcie->controller_id = 0;
> +
> > dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
> > if (IS_ERR(pci->dbi_base))
> @@ -921,7 +992,8 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> > return PTR_ERR(imx6_pcie->pcie_inbound_axi);
> > }
> > break;
> > - case IMX7D:
> > + case IMX8MQ:
> > > + case IMX7D: /* FALLTHROUGH */
> > imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
> > "pciephy");
> > if (IS_ERR(imx6_pcie->pciephy_reset)) {
> @@ -1011,6 +1083,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
> > { .compatible = "fsl,imx6sx-pcie", .data = (void *)IMX6SX, },
> > { .compatible = "fsl,imx6qp-pcie", .data = (void *)IMX6QP, },
> > { .compatible = "fsl,imx7d-pcie", .data = (void *)IMX7D, },
> > + { .compatible = "fsl,imx8mq-pcie", .data = (void *)IMX8MQ, } ,
> > {},
> };
>
> @@ -1027,6 +1100,7 @@ static struct platform_driver imx6_pcie_driver = {
>
> static int __init imx6_pcie_init(void)
> {
> +#ifdef CONFIG_ARM
> > /*
> > * Since probe() can be deferred we need to make sure that
> > * hook_fault_code is not called after __init memory is freed
> @@ -1036,6 +1110,7 @@ static int __init imx6_pcie_init(void)
> > */
> > hook_fault_code(8, imx6q_pcie_abort_handler, SIGBUS, 0,
> > "external abort on non-linefetch");
> +#endif
>
> > return platform_driver_register(&imx6_pcie_driver);
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Krzysztof Kozlowski @ 2018-12-06 10:24 UTC (permalink / raw)
To: linux
Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
Morten.Rasmussen, Qais.Yousef, dietmar.eggemann, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20181206100052.GR30658@n2100.armlinux.org.uk>
On Thu, 6 Dec 2018 at 11:01, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
>
> On Thu, Dec 06, 2018 at 10:32:56AM +0100, Marek Szyprowski wrote:
> > Hi All,
> >
> > On 2018-11-06 13:39, Russell King wrote:
> > > In big.Little systems, some CPUs require the Spectre workarounds in
> > > paths such as the context switch, but other CPUs do not. In order
> > > to handle these differences, we need per-CPU vtables.
> > >
> > > We are unable to use the kernel's per-CPU variables to support this
> > > as per-CPU is not initialised at times when we need access to the
> > > vtables, so we have to use an array indexed by logical CPU number.
> > >
> > > We use an array-of-pointers to avoid having function pointers in
> > > the kernel's read/write .data section.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> >
> > Today I've noticed that this patch (which has landed in v4.20-rc3 as
> > commit 383fb3ee8024) causes regression in CPU hotplug and suspend/resume
> > handling on Samsung Exynos4412 SoC (4*CortexA9 SMP). After putting any
> > non-zero CPU offline, it is no longer possible to get it online again.
> > Same in system suspend/resume - after s2r cycle, only CPU0 is online.
> > The regression can be observed on Hardkernel's Odroid U3 and Samsung
> > Trats2 boards.
> >
> > Any idea how to fix this issue?
>
> This is getting _really_ annoying. I send the patches out, I ask for
> people to test, they seem to ignore the patches, and then they later
> report problems. This is the _second_ time that this has happened,
> both times with Exynos, the first time it caused the patches to miss
> the merge window. Given that Spectre has to deal with every kernel
> entry path, wouldn't it be logical to test every form of entry - boot,
> CPU hotplug, suspend/resume etc?
>
> Sorry, but at this point I have little sympathy.
No one here was accusing anyone so there is really no reason from your
side to respond such.
You sent v2 when I was on holiday. When I returned, I had one day for
response/testing and it ended up sent to Linus for v4.20-rc3. Pretty
late in RC cycle to send fix for something not broken during merge
window... but it happens. We just reported a problem and asked about
help in debugging. Really there is no need to feel blamed for
anything...
We have automated testing setups for linux-next but... linux-next is a
lot of times unbootable. These days - DMA. Before - multiple times NFS
was failing (which my setup uses). Other cases I do not even
remember... and we spend significant time on bisecting these little
breaks all over the kernel so we could test linux-next. The point is
that patch really has to stay in linux-next for some time so the
systems will be able to test it. If you leave it there for two weeks,
then you might hit "unbootable period of linux-next". At least that's
my impression.
> I've no idea based on what you've supplied given that the SoC
> maintainers are responsible for writing the code to deal with hotplug
> etc, and Exynos's code there is something of a maze. It's not clear
> which bits are being used. I think you at the very least need to debug
> to find out whether the problem is at CPU down or CPU up.
>
> From the ARM architecture point of view, for Cortex A9, all the
> processor function instances should be identical. The only difference
> as a result of the patch is that we'll be calling smp_processor_id()
> early (which should be fine), and indirecting through the cpu_vtable[]
> array rather than merely dereferencing the processor struct.
>
> What about checking dmesg - messages from offline CPUs do not appear
> on the console(s) but are still logged in the kernel log.
>
> You could try making PROC_VTABLE() the same as PROC_TABLE() (iow,
> always access cpu_vtable[0]) to see whether it's the smp_processor_id()
> that's causing your problem or not. If it is, then try and work out
> which of the processor functions is causing it by restoring
> PROC_VTABLE() and then switching each from PROC_VTABLE() to
> PROC_TABLE() until it does work.
Thanks for hints!
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 8/9] ARM: dts: imx7d-pico-pi: Extend peripherals support
From: Otavio Salvador @ 2018-12-06 10:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Otavio Salvador, Shawn Guo,
Sascha Hauer, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Fabio Estevam
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
From: Fabio Estevam <festevam@gmail.com>
This adds following peripherals for the imx7d-pico-pi as:
- LED
- Touchscreen
- GPIO
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None
arch/arm/boot/dts/imx7d-pico-pi.dts | 56 +++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-pico-pi.dts b/arch/arm/boot/dts/imx7d-pico-pi.dts
index 039c17066fe0..70bea95c06d8 100644
--- a/arch/arm/boot/dts/imx7d-pico-pi.dts
+++ b/arch/arm/boot/dts/imx7d-pico-pi.dts
@@ -8,6 +8,17 @@
model = "TechNexion PICO-IMX7D Board and PI baseboard";
compatible = "technexion,imx7d-pico-pi", "fsl,imx7d";
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led {
+ label = "gpio-led";
+ gpios = <&gpio2 6 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "imx7-sgtl5000";
@@ -35,3 +46,48 @@
VDDIO-supply = <®_vref_1v8>;
};
};
+
+&i2c4 {
+ polytouch: touchscreen@38 {
+ compatible = "edt,edt-ft5x06";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touchscreen>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA00__GPIO2_IO0 0x14
+ MX7D_PAD_EPDC_DATA01__GPIO2_IO1 0x14
+ MX7D_PAD_EPDC_DATA02__GPIO2_IO2 0x14
+ MX7D_PAD_EPDC_DATA03__GPIO2_IO3 0x14
+ MX7D_PAD_EPDC_DATA05__GPIO2_IO5 0x14
+ MX7D_PAD_EPDC_DATA12__GPIO2_IO12 0x14
+ MX7D_PAD_EPDC_DATA07__GPIO2_IO7 0x14
+ >;
+ };
+
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA06__GPIO2_IO6 0x14
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA04__GPIO2_IO4 0x14
+ MX7D_PAD_EPDC_DATA13__GPIO2_IO13 0x14
+ >;
+ };
+
+};
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 17/34] dt-bindings: arm: Convert TI davinci board/soc bindings to json-schema
From: Sekhar Nori @ 2018-12-06 10:28 UTC (permalink / raw)
To: Rob Herring, devicetree, linux-kernel
Cc: Mark Rutland, Kumar Gala, arm, Sean Hudson, Kevin Hilman,
Frank Rowand, Grant Likely, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20181203213223.16986-18-robh@kernel.org>
On 04/12/18 3:02 AM, Rob Herring wrote:
> Convert TI Davinci SoC bindings to DT schema format using json-schema.
>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS
From: Lucas Stach @ 2018-12-06 10:28 UTC (permalink / raw)
To: Andrey Smirnov, linux-pci
Cc: A.s. Dong, Richard Zhu, linux-kernel, linux-imx, bhelgaas,
Leonard Crestez, cphealy, linux-arm-kernel
In-Reply-To: <20181206074555.19579-1-andrew.smirnov@gmail.com>
Am Mittwoch, den 05.12.2018, 23:45 -0800 schrieb Andrey Smirnov:
> Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
> produces a system where built-in PCIE bridge (16c3:abcd) isn't bound
> to pcieport driver. This, in turn, results in a PCIE bus that is
> capable of enumerating attached PCIE device, but lacks functional
> interrupt support.
This is odd. AFAIK PCI port services are a totally optional thing and
them being absent should not lead to a non-functional PCI bus. So I
would really like to see some deeper analysis what is going on here.
Regards,
Lucas
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
>
> Assuming this is a reasonable dependency, shold this be done to more
> than just i.MX6 driver?
>
> drivers/pci/controller/dwc/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> index 2b139acccf32..44ededbeab85 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -92,6 +92,7 @@ config PCI_IMX6
> > bool "Freescale i.MX6 PCIe controller"
> > depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
> > depends on PCI_MSI_IRQ_DOMAIN
> > + depends on PCIEPORTBUS
> > select PCIE_DW_HOST
>
> config PCIE_SPEAR13XX
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 20/25] kasan, arm64: add brk handler for inline instrumentation
From: Andrey Konovalov @ 2018-12-06 10:31 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION,
Catalin Marinas, Paul Lawrence, Linux Memory Management List,
Alexander Potapenko, Chintan Pandya, Christoph Lameter,
Ingo Molnar, Jacob Bramley, Ruben Ayrapetyan, Mark Brand,
kasan-dev, linux-sparse, Geert Uytterhoeven, Linux ARM,
Andrey Ryabinin, Dave Martin, Evgenii Stepanov, Vishwath Mohan,
Arnd Bergmann, Linux Kbuild mailing list, Marc Zyngier,
Ramana Radhakrishnan, Mike Rapoport, Dmitry Vyukov,
Kostya Serebryany, Jann Horn, Ard Biesheuvel, Greg Kroah-Hartman,
Nick Desaulniers, LKML, Eric W . Biederman, Lee Smith,
Andrew Morton, Kirill A. Shutemov
In-Reply-To: <20181129180138.GB4318@arm.com>
On Thu, Nov 29, 2018 at 7:01 PM Will Deacon <will.deacon@arm.com> wrote:
>
> On Tue, Nov 27, 2018 at 05:55:38PM +0100, Andrey Konovalov wrote:
> > Tag-based KASAN inline instrumentation mode (which embeds checks of shadow
> > memory into the generated code, instead of inserting a callback) generates
> > a brk instruction when a tag mismatch is detected.
> >
> > This commit adds a tag-based KASAN specific brk handler, that decodes the
> > immediate value passed to the brk instructions (to extract information
> > about the memory access that triggered the mismatch), reads the register
> > values (x0 contains the guilty address) and reports the bug.
> >
> > Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> > arch/arm64/include/asm/brk-imm.h | 2 +
> > arch/arm64/kernel/traps.c | 68 +++++++++++++++++++++++++++++++-
> > include/linux/kasan.h | 3 ++
> > 3 files changed, 71 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h
> > index ed693c5bcec0..2945fe6cd863 100644
> > --- a/arch/arm64/include/asm/brk-imm.h
> > +++ b/arch/arm64/include/asm/brk-imm.h
> > @@ -16,10 +16,12 @@
> > * 0x400: for dynamic BRK instruction
> > * 0x401: for compile time BRK instruction
> > * 0x800: kernel-mode BUG() and WARN() traps
> > + * 0x9xx: tag-based KASAN trap (allowed values 0x900 - 0x9ff)
> > */
> > #define FAULT_BRK_IMM 0x100
> > #define KGDB_DYN_DBG_BRK_IMM 0x400
> > #define KGDB_COMPILED_DBG_BRK_IMM 0x401
> > #define BUG_BRK_IMM 0x800
> > +#define KASAN_BRK_IMM 0x900
> >
> > #endif
> > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > index 5f4d9acb32f5..04bdc53716ef 100644
> > --- a/arch/arm64/kernel/traps.c
> > +++ b/arch/arm64/kernel/traps.c
> > @@ -35,6 +35,7 @@
> > #include <linux/sizes.h>
> > #include <linux/syscalls.h>
> > #include <linux/mm_types.h>
> > +#include <linux/kasan.h>
> >
> > #include <asm/atomic.h>
> > #include <asm/bug.h>
> > @@ -284,10 +285,14 @@ void arm64_notify_die(const char *str, struct pt_regs *regs,
> > }
> > }
> >
> > -void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
> > +void __arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
> > {
> > regs->pc += size;
> > +}
> >
> > +void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
> > +{
> > + __arm64_skip_faulting_instruction(regs, size);
> > /*
> > * If we were single stepping, we want to get the step exception after
> > * we return from the trap.
> > @@ -959,7 +964,7 @@ static int bug_handler(struct pt_regs *regs, unsigned int esr)
> > }
> >
> > /* If thread survives, skip over the BUG instruction and continue: */
> > - arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
> > + __arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
>
> Why do you want to avoid the single-step logic here? Given that we're
> skipping over the brk instruction, why wouldn't you want that to trigger
> a step exception if single-step is enabled?
I was asked to do that, see the discussion here:
https://www.spinics.net/lists/linux-mm/msg146575.html
https://www.spinics.net/lists/linux-mm/msg148215.html
https://www.spinics.net/lists/linux-mm/msg148367.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: imx6qdl-sabresd: Use GPIO_ACTIVE_HIGH for regulators
From: Fabio Estevam @ 2018-12-06 10:36 UTC (permalink / raw)
To: shawnguo; +Cc: Fabio Estevam, linux-arm-kernel
Passing GPIO_ACTIVE_HIGH as GPIO flags for the GPIO controlled
regulator improves the readability, so use it instead of the
hardcoded number.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 187548d..8930aec 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -22,7 +22,7 @@
regulator-name = "usb_otg_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
- gpio = <&gpio3 22 0>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
enable-active-high;
vin-supply = <&swbst_reg>;
};
@@ -32,7 +32,7 @@
regulator-name = "usb_h1_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
- gpio = <&gpio1 29 0>;
+ gpio = <&gpio1 29 GPIO_ACTIVE_HIGH>;
enable-active-high;
vin-supply = <&swbst_reg>;
};
@@ -40,7 +40,7 @@
reg_audio: regulator-audio {
compatible = "regulator-fixed";
regulator-name = "wm8962-supply";
- gpio = <&gpio4 10 0>;
+ gpio = <&gpio4 10 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
@@ -51,7 +51,7 @@
regulator-name = "MPCIE_3V3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
- gpio = <&gpio3 19 0>;
+ gpio = <&gpio3 19 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 0/9] Improvements for i.MX7D PICO SoM and its baseboards
From: Otavio Salvador @ 2018-12-06 10:44 UTC (permalink / raw)
To: Otavio Salvador
Cc: Mark Rutland, devicetree, Sascha Hauer, Kernel development list,
Rob Herring, NXP Linux Team, Sascha Hauer, Fabio Estevam,
Shawn Guo, linux-arm-kernel
In-Reply-To: <20181206100905.15053-1-otavio@ossystems.com.br>
On Thu, Dec 6, 2018 at 8:09 AM Otavio Salvador <otavio@ossystems.com.br> wrote:
>
> This patchset rework the imx7d-pico SoM, its Pi baseboard
> and add the Hobbit baseboard support as well.
>
> Changes in v2:
> - replace fsl,uart-has-rtscts with uart-has-rtscts
>
> Fabio Estevam (8):
> ARM: dts: imx7d-pico: Do not harcode the memory size
> ARM: dts: imx7d-pico: Switch to SPDX identifier
> ARM: dts: imx7d-pico-pi: Move SoM related part to imx7d-pico.dtsi
I did the rebase; one thing worth mentioning is that I have "ARM: dts:
imx7d-pico: Describe the Wifi clock" which is in your fixes tree.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 7/7] mm: better document PG_reserved
From: David Hildenbrand @ 2018-12-06 10:46 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-s390, Michal Hocko, yi.z.zhang, Stephen Rothwell,
Alexander Duyck, Dan Williams, linux-kernel, Pavel Tatashin,
linux-mm, linux-m68k, linux-mediatek, Miles Chen, Anthony Yznaga,
linux-riscv, linuxppc-dev, Andrew Morton, linux-arm-kernel
In-Reply-To: <35689ede-d86e-d692-adae-bc2f1adfb2ab@redhat.com>
On 05.12.18 19:13, David Hildenbrand wrote:
> On 05.12.18 18:32, Matthew Wilcox wrote:
>> On Wed, Dec 05, 2018 at 04:05:12PM +0100, David Hildenbrand wrote:
>>> On 05.12.18 15:35, Matthew Wilcox wrote:
>>>> On Wed, Dec 05, 2018 at 01:28:51PM +0100, David Hildenbrand wrote:
>>>>> I don't see a reason why we have to document "Some of them might not even
>>>>> exist". If there is a user, we should document it. E.g. for balloon
>>>>> drivers we now use PG_offline to indicate that a page might currently
>>>>> not be backed by memory in the hypervisor. And that is independent from
>>>>> PG_reserved.
>>>>
>>>> I think you're confused by the meaning of "some of them might not even
>>>> exist". What this means is that there might not be memory there; maybe
>>>> writes to that memory will be discarded, or maybe they'll cause a machine
>>>> check. Maybe reads will return ~0, or 0, or cause a machine check.
>>>> We just don't know what's there, and we shouldn't try touching the memory.
>>>
>>> If there are users, let's document it. And I need more details for that :)
>>>
>>> 1. machine check: if there is a HW error, we set PG_hwpoison (except
>>> ia64 MCA, see the list)
>>>
>>> 2. Writes to that memory will be discarded
>>>
>>> Who is the user of that? When will we have such pages right now?
>>>
>>> 3. Reads will return ~0, / 0?
>>>
>>> I think this is a special case of e.g. x86? But where do we have that,
>>> are there any user?
>>
>> When there are gaps in the physical memory. As in, if you put that
>> physical address on the bus (or in a packet), no device will respond
>> to it. Look:
>>
>> 00000000-00000fff : Reserved
>> 00001000-00057fff : System RAM
>> 00058000-00058fff : Reserved
>> 00059000-0009dfff : System RAM
>> 0009e000-000fffff : Reserved
>>
>> Those examples I gave are examples of how various different architectures
>> respond to "no device responded to this memory access".
>>
>
> Okay, so for this memory we will have
> a) vmmaps
> b) Memory block devices
> c) A sections that is online
>
> So essentially "Gaps in physical memory" which is part of a online section.
>
> This might be a candidate for PG_offline as well.
>
> Thanks for the info, I'll try to find out how such things are handled.
> In general I assume this memory has to be readable, because otherwise
> kdump and friends would crash already when trying to dump?
>
So I finally understood how physical memory holes in online sections are
handled when dumping. They won't be dumped because the list of dumpable
chunks (contained in /proc/kcore and after a crash /proc/vmcore) is
built using walk_system_ram_range(). So anything not listed as RAM will
be ignored.
I will update the documentation, describing that if we have an online
section that is not completely IORESOURCE_SYSTEM_RAM, that the physical
memory gaps will also be set to PG_reserved.
Trying to touch this memory is indeed dangerous, luckily dumping is
properly handled.
I'll think about if marking these ranges as PG_offline might make sense
(and if it can be easily added). Then we directly know when seeing that
page type that we should not touch it. Ever.
That hint was really helpful :)
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity
From: Giulio Benetti @ 2018-12-06 11:00 UTC (permalink / raw)
To: Jonathan Liu
Cc: dri-devel, Maxime Ripard, Chen-Yu Tsai, linux-arm-kernel,
linux-kernel
In-Reply-To: <CANwerB3Zr9axz+1rwCnNpLsX-xcOhOKEY4MT53v1+vzd99KRMg@mail.gmail.com>
Hi Jonathan,
Il 06/12/2018 08:29, Jonathan Liu ha scritto:
> Hi Giulio,
>
> On Thu, 15 Feb 2018 at 17:54, Giulio Benetti
> <giulio.benetti@micronovasrl.com> wrote:
>>
>> Differently from other Lcd signals, HSYNC and VSYNC signals
>> result inverted if their bits are cleared to 0.
>>
>> Invert their settings of IO_POL register.
>>
>> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
>> ---
>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index 3c15cf2..aaf911a 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
>> SUN4I_TCON0_BASIC3_H_SYNC(hsync));
>>
>> /* Setup the polarity of the various signals */
>> - if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
>> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
>> val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
>>
>> - if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
>> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
>> val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
>>
>> regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
>
> I am running Linux 4.19.6 and noticed with Olimex LCD-OLinuXino-7TS 7"
> LCD touchscreen (Innolux AT070TN92) connected to Olimex
> A20-OLinuXino-MICRO that the image does not display correctly after
> this change.
> The image is shifted to the right.
>
> Reverting the change results in the image being displayed correctly on
> the screen.
>
> I have in the device tree a "panel" node with compatible =
> "innolux,at070tn92" which uses the timings in
> drivers/gpu/drm/panel/panel-simple.c.
>
> Any ideas?
Checking Display Datasheet:
https://www.olimex.com/Products/Retired/A13-LCD7-TS/resources/S700-AT070TN92.pdf
Page 13 section 3.3.2 you can see it needs active low VS and HS.
You can refer to this Thread and check scope captures about VS and HS
versus TCON0_IOPOL register:
https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html
There should be something that wrongly sets one of these or both:
mode->flags |= DRM_MODE_FLAG_PHSYNC;
and/or
mode->flags |= DRM_MODE_FLAG_PVSYNC;
Checked in panel-simple.c but it's not there.
At the moment I don't have a board to check it with me, I'll try to do
it soon, but I'm full with other work at the moment.
If you have the chance to debug you could try to find in which point
mode->flags gets changed with those 2 flags.
When the problem came out I've noticed the same thing for u-boot too but
it's been decided to not patch it because in that case every single
sunxi defconfig had to be changed from:
CONFIG_VIDEO_LCD_MODE="...,sync:3,..."
to:
CONFIG_VIDEO_LCD_MODE="...,sync:0,..."
and it would have been a great mess, probably not worth it:
https://lists.denx.de/pipermail/u-boot/2018-February/321405.html
So keep in mind that TCON driver works differently for HS and
VS(inverted) polarity in u-boot and linux.
Hope to work this out soon.
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v11 6/7] arm64: dts: ls1046a: add qdma device tree nodes
From: Peng Ma @ 2018-12-06 11:04 UTC (permalink / raw)
To: Shawn Guo
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Wen He,
linux-kernel@vger.kernel.org, Leo Li, zw@zh-kernel.org,
vkoul@kernel.org, robh+dt@kernel.org, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181206010531.GR3987@dragon>
Hi Shawn,
Thanks for your review , I have used GIC_SPI and IRQ_TYPE_xxx to my dtsi, please check and review.
Best Regard,
Peng
>-----Original Message-----
>From: Shawn Guo <shawnguo@kernel.org>
>Sent: 2018年12月6日 9:06
>To: Peng Ma <peng.ma@nxp.com>
>Cc: vkoul@kernel.org; robh+dt@kernel.org; mark.rutland@arm.com; Leo Li
><leoyang.li@nxp.com>; dan.j.williams@intel.com; zw@zh-kernel.org;
>dmaengine@vger.kernel.org; devicetree@vger.kernel.org;
>linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>linuxppc-dev@lists.ozlabs.org; Wen He <wen.he_1@nxp.com>
>Subject: Re: [v11 6/7] arm64: dts: ls1046a: add qdma device tree nodes
>
>On Tue, Oct 30, 2018 at 10:36:03AM +0800, Peng Ma wrote:
>> add the qDMA device tree nodes for LS1046A devices.
>>
>> Signed-off-by: Wen He <wen.he_1@nxp.com>
>> Signed-off-by: Peng Ma <peng.ma@nxp.com>
>> ---
>> change in v11:
>> - no
>>
>> arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 21
>+++++++++++++++++++++
>> 1 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> index ef83786..dc65318 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
>> @@ -704,6 +704,27 @@
>> <0000 0 0 4 &gic GIC_SPI 154
>IRQ_TYPE_LEVEL_HIGH>;
>> };
>>
>> + qdma: dma-controller@8380000 {
>> + compatible = "fsl,ls1046a-qdma", "fsl,ls1021a-qdma";
>> + reg = <0x0 0x8380000 0x0 0x1000>, /* Controller regs */
>> + <0x0 0x8390000 0x0 0x10000>, /* Status regs */
>> + <0x0 0x83a0000 0x0 0x40000>; /* Block regs */
>> + interrupts = <0 153 0x4>,
>> + <0 39 0x4>,
>> + <0 40 0x4>,
>> + <0 41 0x4>,
>> + <0 42 0x4>;
>
>Use GIC_SPI and IRQ_TYPE_xxx defines.
>
>Shawn
>
>> + interrupt-names = "qdma-error", "qdma-queue0",
>> + "qdma-queue1", "qdma-queue2", "qdma-queue3";
>> + dma-channels = <8>;
>> + block-number = <1>;
>> + block-offset = <0x10000>;
>> + fsl,dma-queues = <2>;
>> + status-sizes = <64>;
>> + queue-sizes = <64 64>;
>> + big-endian;
>> + };
>> +
>> };
>>
>> reserved-memory {
>> --
>> 1.7.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] ARM: dts: Add support for Liebherr's BK4 device (vf610 based)
From: Fabio Estevam @ 2018-12-06 11:09 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Sascha Hauer, linux-kernel, Stefan Agner, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20181206092255.2359f7e6@jawa>
On Thu, Dec 6, 2018 at 6:23 AM Lukasz Majewski <lukma@denx.de> wrote:
> At the time of development - I've checked my NXP related patches with
> W=1 passed to make. No warnings observed then.
In linux-next the warning happens without W=1.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 20/25] kasan, arm64: add brk handler for inline instrumentation
From: Will Deacon @ 2018-12-06 11:11 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION,
Catalin Marinas, Paul Lawrence, Linux Memory Management List,
Alexander Potapenko, Chintan Pandya, Christoph Lameter,
Ingo Molnar, Jacob Bramley, Ruben Ayrapetyan, Mark Brand,
kasan-dev, linux-sparse, Geert Uytterhoeven, Linux ARM,
Andrey Ryabinin, Dave Martin, Evgenii Stepanov, Vishwath Mohan,
Arnd Bergmann, Linux Kbuild mailing list, Marc Zyngier,
Ramana Radhakrishnan, Mike Rapoport, Dmitry Vyukov,
Kostya Serebryany, Jann Horn, Ard Biesheuvel, Greg Kroah-Hartman,
Nick Desaulniers, LKML, Eric W . Biederman, Lee Smith,
Andrew Morton, Kirill A. Shutemov
In-Reply-To: <CAAeHK+zVzWJ7RBsX88SOsebq0a40ypuawYFd4w4woFSHuximOw@mail.gmail.com>
On Thu, Dec 06, 2018 at 11:31:43AM +0100, Andrey Konovalov wrote:
> On Thu, Nov 29, 2018 at 7:01 PM Will Deacon <will.deacon@arm.com> wrote:
> >
> > On Tue, Nov 27, 2018 at 05:55:38PM +0100, Andrey Konovalov wrote:
> > > Tag-based KASAN inline instrumentation mode (which embeds checks of shadow
> > > memory into the generated code, instead of inserting a callback) generates
> > > a brk instruction when a tag mismatch is detected.
> > >
> > > This commit adds a tag-based KASAN specific brk handler, that decodes the
> > > immediate value passed to the brk instructions (to extract information
> > > about the memory access that triggered the mismatch), reads the register
> > > values (x0 contains the guilty address) and reports the bug.
> > >
> > > Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
> > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > > ---
> > > arch/arm64/include/asm/brk-imm.h | 2 +
> > > arch/arm64/kernel/traps.c | 68 +++++++++++++++++++++++++++++++-
> > > include/linux/kasan.h | 3 ++
> > > 3 files changed, 71 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h
> > > index ed693c5bcec0..2945fe6cd863 100644
> > > --- a/arch/arm64/include/asm/brk-imm.h
> > > +++ b/arch/arm64/include/asm/brk-imm.h
> > > @@ -16,10 +16,12 @@
> > > * 0x400: for dynamic BRK instruction
> > > * 0x401: for compile time BRK instruction
> > > * 0x800: kernel-mode BUG() and WARN() traps
> > > + * 0x9xx: tag-based KASAN trap (allowed values 0x900 - 0x9ff)
> > > */
> > > #define FAULT_BRK_IMM 0x100
> > > #define KGDB_DYN_DBG_BRK_IMM 0x400
> > > #define KGDB_COMPILED_DBG_BRK_IMM 0x401
> > > #define BUG_BRK_IMM 0x800
> > > +#define KASAN_BRK_IMM 0x900
> > >
> > > #endif
> > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > > index 5f4d9acb32f5..04bdc53716ef 100644
> > > --- a/arch/arm64/kernel/traps.c
> > > +++ b/arch/arm64/kernel/traps.c
> > > @@ -35,6 +35,7 @@
> > > #include <linux/sizes.h>
> > > #include <linux/syscalls.h>
> > > #include <linux/mm_types.h>
> > > +#include <linux/kasan.h>
> > >
> > > #include <asm/atomic.h>
> > > #include <asm/bug.h>
> > > @@ -284,10 +285,14 @@ void arm64_notify_die(const char *str, struct pt_regs *regs,
> > > }
> > > }
> > >
> > > -void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
> > > +void __arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
> > > {
> > > regs->pc += size;
> > > +}
> > >
> > > +void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
> > > +{
> > > + __arm64_skip_faulting_instruction(regs, size);
> > > /*
> > > * If we were single stepping, we want to get the step exception after
> > > * we return from the trap.
> > > @@ -959,7 +964,7 @@ static int bug_handler(struct pt_regs *regs, unsigned int esr)
> > > }
> > >
> > > /* If thread survives, skip over the BUG instruction and continue: */
> > > - arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
> > > + __arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
> >
> > Why do you want to avoid the single-step logic here? Given that we're
> > skipping over the brk instruction, why wouldn't you want that to trigger
> > a step exception if single-step is enabled?
>
> I was asked to do that, see the discussion here:
>
> https://www.spinics.net/lists/linux-mm/msg146575.html
> https://www.spinics.net/lists/linux-mm/msg148215.html
> https://www.spinics.net/lists/linux-mm/msg148367.html
Aha, but we subsequently fixed the underlying problem in commit
9478f1927e6e ("arm64: only advance singlestep for user instruction traps").
You were on cc, but I appreciate it's not clear that it was related to this.
Anyway, you can just call arm64_skip_faulting_instruction() as you were
doing and there's no need for this refactoring.
Please could you spin a new version so that akpm can replace the one which
he has queued?
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] irqchip/irq-imx-gpcv2: Remove unused code
From: Lucas Stach @ 2018-12-06 11:10 UTC (permalink / raw)
To: Andrey Smirnov, Marc Zyngier
Cc: A.s. Dong, Richard Zhu, Jason Cooper, linux-kernel, linux-imx,
Thomas Gleixner, Leonard Crestez, cphealy, linux-arm-kernel
In-Reply-To: <20181206073125.7255-2-andrew.smirnov@gmail.com>
Am Mittwoch, den 05.12.2018, 23:31 -0800 schrieb Andrey Smirnov:
> Varaible 'reg' in imx_gpcv2_irq_set_wake() has no users. Remove it.
>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: cphealy@gmail.com
> Cc: l.stach@pengutronix.de
> > Cc: Leonard Crestez <leonard.crestez@nxp.com>
> > Cc: "A.s. Dong" <aisheng.dong@nxp.com>
> > Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-imx@nxp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/irqchip/irq-imx-gpcv2.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
> index 4760307ab43f..cbed00319315 100644
> --- a/drivers/irqchip/irq-imx-gpcv2.c
> +++ b/drivers/irqchip/irq-imx-gpcv2.c
> @@ -73,11 +73,9 @@ static int imx_gpcv2_irq_set_wake(struct irq_data *d, unsigned int on)
> > struct gpcv2_irqchip_data *cd = d->chip_data;
> > unsigned int idx = d->hwirq / 32;
> > unsigned long flags;
> > - void __iomem *reg;
> > u32 mask, val;
>
> > raw_spin_lock_irqsave(&cd->rlock, flags);
> > - reg = cd->gpc_base + cd->cpu2wakeup + idx * 4;
> > mask = 1 << d->hwirq % 32;
> > val = cd->wakeup_sources[idx];
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/5] irqchip/irq-imx-gpcv2: Share reg offset calculation code
From: Lucas Stach @ 2018-12-06 11:11 UTC (permalink / raw)
To: Andrey Smirnov, Marc Zyngier
Cc: A.s. Dong, Richard Zhu, Jason Cooper, linux-kernel, linux-imx,
Thomas Gleixner, Leonard Crestez, cphealy, linux-arm-kernel
In-Reply-To: <20181206073125.7255-3-andrew.smirnov@gmail.com>
Am Mittwoch, den 05.12.2018, 23:31 -0800 schrieb Andrey Smirnov:
> Move identical offset calculation code into a small helper function
> and make use of it in the rest of the code.
>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: cphealy@gmail.com
> Cc: l.stach@pengutronix.de
> > Cc: Leonard Crestez <leonard.crestez@nxp.com>
> > Cc: "A.s. Dong" <aisheng.dong@nxp.com>
> > Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-imx@nxp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Nice cleanup!
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/irqchip/irq-imx-gpcv2.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
> index cbed00319315..b262ba8b2652 100644
> --- a/drivers/irqchip/irq-imx-gpcv2.c
> +++ b/drivers/irqchip/irq-imx-gpcv2.c
> @@ -28,6 +28,11 @@ struct gpcv2_irqchip_data {
>
> static struct gpcv2_irqchip_data *imx_gpcv2_instance;
>
> +static void __iomem *gpcv2_idx_to_reg(struct gpcv2_irqchip_data *cd, int i)
> +{
> > + return cd->gpc_base + cd->cpu2wakeup + i * 4;
> +}
> +
> static int gpcv2_wakeup_source_save(void)
> {
> > struct gpcv2_irqchip_data *cd;
> @@ -39,7 +44,7 @@ static int gpcv2_wakeup_source_save(void)
> > return 0;
>
> > for (i = 0; i < IMR_NUM; i++) {
> > - reg = cd->gpc_base + cd->cpu2wakeup + i * 4;
> > + reg = gpcv2_idx_to_reg(cd, i);
> > cd->saved_irq_mask[i] = readl_relaxed(reg);
> > writel_relaxed(cd->wakeup_sources[i], reg);
> > }
> @@ -50,17 +55,14 @@ static int gpcv2_wakeup_source_save(void)
> static void gpcv2_wakeup_source_restore(void)
> {
> > struct gpcv2_irqchip_data *cd;
> > - void __iomem *reg;
> > int i;
>
> > cd = imx_gpcv2_instance;
> > if (!cd)
> > return;
>
> > - for (i = 0; i < IMR_NUM; i++) {
> > - reg = cd->gpc_base + cd->cpu2wakeup + i * 4;
> > - writel_relaxed(cd->saved_irq_mask[i], reg);
> > - }
> > + for (i = 0; i < IMR_NUM; i++)
> > + writel_relaxed(cd->saved_irq_mask[i], gpcv2_idx_to_reg(cd, i));
> }
>
> static struct syscore_ops imx_gpcv2_syscore_ops = {
> @@ -97,7 +99,7 @@ static void imx_gpcv2_irq_unmask(struct irq_data *d)
> > u32 val;
>
> > raw_spin_lock(&cd->rlock);
> > - reg = cd->gpc_base + cd->cpu2wakeup + d->hwirq / 32 * 4;
> > + reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
> > val = readl_relaxed(reg);
> > val &= ~(1 << d->hwirq % 32);
> > writel_relaxed(val, reg);
> @@ -113,7 +115,7 @@ static void imx_gpcv2_irq_mask(struct irq_data *d)
> > u32 val;
>
> > raw_spin_lock(&cd->rlock);
> > - reg = cd->gpc_base + cd->cpu2wakeup + d->hwirq / 32 * 4;
> > + reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
> > val = readl_relaxed(reg);
> > val |= 1 << (d->hwirq % 32);
> > writel_relaxed(val, reg);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/5] irqchip/irq-imx-gpcv2: Make use of BIT() macro
From: Lucas Stach @ 2018-12-06 11:12 UTC (permalink / raw)
To: Andrey Smirnov, Marc Zyngier
Cc: A.s. Dong, Richard Zhu, Jason Cooper, linux-kernel, linux-imx,
Thomas Gleixner, Leonard Crestez, cphealy, linux-arm-kernel
In-Reply-To: <20181206073125.7255-4-andrew.smirnov@gmail.com>
Am Mittwoch, den 05.12.2018, 23:31 -0800 schrieb Andrey Smirnov:
> Convert all instances of 1 << x to BIT(x) for consistency with other
> kernel code.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: cphealy@gmail.com
> Cc: l.stach@pengutronix.de
> Cc: Leonard Crestez <leonard.crestez@nxp.com>
> Cc: "A.s. Dong" <aisheng.dong@nxp.com>
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-imx@nxp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/irqchip/irq-imx-gpcv2.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-
> imx-gpcv2.c
> index b262ba8b2652..077d56b3183a 100644
> --- a/drivers/irqchip/irq-imx-gpcv2.c
> +++ b/drivers/irqchip/irq-imx-gpcv2.c
> @@ -78,7 +78,7 @@ static int imx_gpcv2_irq_set_wake(struct irq_data
> *d, unsigned int on)
> u32 mask, val;
>
> raw_spin_lock_irqsave(&cd->rlock, flags);
> - mask = 1 << d->hwirq % 32;
> + mask = BIT(d->hwirq % 32);
> val = cd->wakeup_sources[idx];
>
> cd->wakeup_sources[idx] = on ? (val & ~mask) : (val | mask);
> @@ -101,7 +101,7 @@ static void imx_gpcv2_irq_unmask(struct irq_data
> *d)
> raw_spin_lock(&cd->rlock);
> reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
> val = readl_relaxed(reg);
> - val &= ~(1 << d->hwirq % 32);
> + val &= ~BIT(d->hwirq % 32);
> writel_relaxed(val, reg);
> raw_spin_unlock(&cd->rlock);
>
> @@ -117,7 +117,7 @@ static void imx_gpcv2_irq_mask(struct irq_data
> *d)
> raw_spin_lock(&cd->rlock);
> reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
> val = readl_relaxed(reg);
> - val |= 1 << (d->hwirq % 32);
> + val |= BIT(d->hwirq % 32);
> writel_relaxed(val, reg);
> raw_spin_unlock(&cd->rlock);
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: allwinner: a64-amarula-relic: Add OV5640 camera node
From: Jagan Teki @ 2018-12-06 11:13 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Michael Trimarchi, Maxime Ripard,
linux-kernel, Rob Herring, Yong Deng, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media
In-Reply-To: <CAGb2v6441wV7PM6q=vF2cpJtP9BGdYjQQqNU54rqELNJ5YcmdQ@mail.gmail.com>
On Mon, Dec 3, 2018 at 3:55 PM Chen-Yu Tsai <wens@csie.org> wrote:
>
> On Mon, Dec 3, 2018 at 6:08 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > Amarula A64-Relic board by default bound with OV5640 camera,
> > so add support for it with below pin information.
> >
> > - PE13, PE12 via i2c-gpio bitbanging
> > - CLK_CSI_MCLK as external clock
> > - PE1 as external clock pin muxing
> > - DLDO3 as vcc-csi supply
> > - DLDO3 as AVDD supply
> > - ALDO1 as DOVDD supply
> > - ELDO3 as DVDD supply
> > - PE14 gpio for reset pin
> > - PE15 gpio for powerdown pin
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > .../allwinner/sun50i-a64-amarula-relic.dts | 54 +++++++++++++++++++
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 ++
> > 2 files changed, 59 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > index 6cb2b7f0c817..9ac6d773188b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > @@ -22,6 +22,41 @@
> > stdout-path = "serial0:115200n8";
> > };
> >
> > + i2c-csi {
> > + compatible = "i2c-gpio";
> > + sda-gpios = <&pio 4 13 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> > + scl-gpios = <&pio 4 12 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
>
> FYI our hardware doesn't do open drain.
True, but the kernel is enforcing it seems, from the change from [1].
does that mean Linux use open drain even though hardware doens't have?
or did I miss anything?
[ 3.659235] gpio-141 (sda): enforced open drain please flag it
properly in DT/ACPI DSDT/board file
[ 3.679954] gpio-140 (scl): enforced open drain please flag it
properly in DT/ACPI DSDT/board file
[ 3.814878] i2c-gpio i2c-csi: using lines 141 (SDA) and 140 (SCL)
>
> > + i2c-gpio,delay-us = <5>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ov5640: camera@3c {
> > + compatible = "ovti,ov5640";
> > + reg = <0x3c>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&csi_mclk_pin>;
> > + clocks = <&ccu CLK_CSI_MCLK>;
> > + clock-names = "xclk";
> > +
> > + AVDD-supply = <®_dldo3>;
> > + DOVDD-supply = <®_aldo1>;
>
> DOVDD is the supply for I/O. You say it is ALDO1 here.
>
> > + DVDD-supply = <®_eldo3>;
> > + reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */
> > + powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */
> > +
> > + port {
> > + ov5640_ep: endpoint {
> > + remote-endpoint = <&csi_ep>;
> > + bus-width = <8>;
> > + hsync-active = <1>; /* Active high */
> > + vsync-active = <0>; /* Active low */
> > + data-active = <1>; /* Active high */
> > + pclk-sample = <1>; /* Rising */
> > + };
> > + };
> > + };
> > + };
> > +
> > wifi_pwrseq: wifi-pwrseq {
> > compatible = "mmc-pwrseq-simple";
> > clocks = <&rtc 1>;
> > @@ -30,6 +65,25 @@
> > };
> > };
> >
> > +&csi {
> > + vcc-csi-supply = <®_dldo3>;
>
> But here you say the SoC-side pins are driven from DLDO3.
>
> This is a somewhat odd mismatch.
>
> Regardless, the ov5640 driver enables all three regulators at probe time.
> Shouldn't that be enough to get the I2C bus working? The pin voltage
> supply does not belong here.
It is working w/o supplying PE group, but I think that may be reason
of supplying similar regulator via DOVDD on sensor side. But we need
to make sure the pin-group must be powered right like DSI, HDMI? if
yes may be we do something via power-domain driver like other SoC's
does or do we have any other option.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpio/gpiolib.c?id=f926dfc112bc6cf41d7068ee5e3f261e13a5bec8
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: clearfog-gt-8k: describe mini-PCIe CON2 USB
From: Baruch Siach @ 2018-12-06 11:19 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: Baruch Siach, Russell King, linux-arm-kernel
Enable the USB3 peripheral that is wired to CON2 on the Clearfog GT-8K
board.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
index dfb26661a88e..5b4a9609e31f 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
@@ -282,6 +282,10 @@
vqmmc-supply = <&v_3_3>;
};
+&cp0_usb3_1 {
+ status = "okay";
+};
+
&cp1_pinctrl {
/*
* MPP Bus:
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64/mm: use correct operators for string comparison in cache.S
From: Dave Martin @ 2018-12-06 11:20 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Robin Murphy, linux-arm-kernel, Ard Biesheuvel
In-Reply-To: <20181203174506.GA28497@arm.com>
On Mon, Dec 03, 2018 at 05:45:06PM +0000, Will Deacon wrote:
> On Mon, Dec 03, 2018 at 02:22:14PM +0100, Ard Biesheuvel wrote:
> > On Mon, 3 Dec 2018 at 14:11, Robin Murphy <robin.murphy@arm.com> wrote:
> > > On 01/12/2018 11:01, Ard Biesheuvel wrote:
> > > > The GAS directives that are currently being used in dcache_by_line_op
> > > > rely on assembler behavior that is not documented, and probably not
> > > > guaranteed to produce the correct behavior going forward.
> > > >
> > > > Currently, we end up with some undefined symbols in cache.o:
> > > >
> > > > $ nm arch/arm64/mm/cache.o
> > > > ...
> > > > U civac
> > > > ...
> > > > U cvac
> > > > U cvap
> > > > U cvau
> > > >
> > > > This is due to the fact that the comparisons used to select the
> > > > operation type in the dcache_by_line_op macro are comparing symbols
> > > > not strings, and even though it seems that GAS is doing the right
> > > > thing here (undefined symbols by the same name are equal to each
> > > > other), it seems unwise to rely on this.
> > > >
> > > > So let's provide some definitions that are guaranteed to be distinct,
> > > > and make them local so they don't pollute the gobal symbol space.
> > >
> > > Rather than making the unintended symbol comparisons work properly, can
> > > we not just implement the string comparisons that were supposed to be?
> > > Superficially, the diff below seems to still generate the desired output
> > > (although as always there's probably some subtlety I'm missing).
> > >
> > > Robin.
> > >
> > > ----->8-----
> > >
> > > diff --git a/arch/arm64/include/asm/assembler.h
> > > b/arch/arm64/include/asm/assembler.h
> > > index 6142402c2eb4..2c5f4825fee3 100644
> > > --- a/arch/arm64/include/asm/assembler.h
> > > +++ b/arch/arm64/include/asm/assembler.h
> > > @@ -383,13 +383,13 @@ alternative_endif
> > > sub \tmp2, \tmp1, #1
> > > bic \kaddr, \kaddr, \tmp2
> > > 9998:
> > > - .if (\op == cvau || \op == cvac)
> > > + .if ("\op" == "cvau" || "\op" == "cvac")
> > > alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
> > > dc \op, \kaddr
> > > alternative_else
> > > dc civac, \kaddr
> > > alternative_endif
> > > - .elseif (\op == cvap)
> > > + .elseif ("\op" == "cvap")
(Whatever this looks like, it's still comparing symbols someone probably
already pointed that out. Oh, and the () are redundant. This isn't C,
but, meh.)
> > > alternative_if ARM64_HAS_DCPOP
> > > sys 3, c7, c12, 1, \kaddr // dc cvap
> > > alternative_else
> > >
> >
> > Looking at the GAS info pages, I find
> >
> > "Operators" are arithmetic functions, like '+' or '%'.
> > "Arguments" are symbols, numbers or subexpressions.
> > An "expression" specifies an address or numeric value.
> >
> > so even if the comparison works as expected, I'm hesitant to rely on
> > it to work as expected on any version of GAS or any other assembler
> > claiming to implement the GAS asm dialect.
> >
> > We could change the logic to .ifc, which is defined to operate on string, i.e.,
>
> That looks better to me, although I'm not sure why you're inverted the logic
> here:
>
> > .ifnc \op, civac
> > .ifnc \op, cvap
>
> What am I missing?
I vote for the .ifc approach.
Note, the current works-by-accident approach using == has the odd side-
effect of spitting out undefined symbol references in the .o file. It
seems that isn't breaking the link, but I wonder whether there are any
side-effects we're not aware of.
If we don't like the inverted logic, there is always
.set .L__foo_\@, 0
.ifc \op, civac
.set .L__foo_\@, 1
.endif
.ifc \op, cvap
.set .L__foo_\@, 1
.endif
.if .L__foo_\@
// ...
.endif
which is ugly. Either way, the logic could be wrapped as a helper:
.macro if_string_is_either str, cmp1, cmp2, insn:vararg
.ifnc "\str","\cmp1"
.ifnc "\str","\cmp2"
.exitm
.endif
.endif
\insn
.endm
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [v12 1/3] arm: dts: ls1021a: add qdma device tree nodes
From: Peng Ma @ 2018-12-06 11:18 UTC (permalink / raw)
To: vkoul, shawnguo
Cc: mark.rutland, devicetree, Wen He, Peng Ma, linux-kernel,
leoyang.li, robh+dt, linux-arm-kernel
add the qDMA device tree nodes for LS1021A devices.
Signed-off-by: Wen He <wen.he_1@nxp.com>
Signed-off-by: Peng Ma <peng.ma@nxp.com>
---
change in v12:
- no
arch/arm/boot/dts/ls1021a.dtsi | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index bdd6e66..b3d7807 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -812,5 +812,25 @@
#size-cells = <1>;
ranges = <0x0 0x0 0x10010000 0x10000>;
};
+
+ qdma: dma-controller@8390000 {
+ compatible = "fsl,ls1021a-qdma";
+ reg = <0x0 0x8388000 0x0 0x1000>, /* Controller regs */
+ <0x0 0x8389000 0x0 0x1000>, /* Status regs */
+ <0x0 0x838a000 0x0 0x2000>; /* Block regs */
+ interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "qdma-error",
+ "qdma-queue0", "qdma-queue1";
+ dma-channels = <8>;
+ block-number = <1>;
+ block-offset = <0x1000>;
+ fsl,dma-queues = <2>;
+ status-sizes = <64>;
+ queue-sizes = <64 64>;
+ big-endian;
+ };
+
};
};
--
1.7.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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