* [PATCH v3 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
From: Paul Kocialkowski @ 2018-05-06 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180506214901.23429-1-contact@paulk.fr>
This adds support for the Ainol AW1, an A20-based 7" tablet from Ainol.
The following board-specific features are supported:
* LCD panel
* Backlight
* USB OTG
* Buttons
* Touchscreen (doesn't work without non-free firmware)
* Accelerometer
* Battery
The following are untested:
* Audio output
* Audio speakers
* USB via SPCI connector
The following are not supported:
* Wi-Fi
* Bluetooth
* NAND
* Audio via SPCI connector
* Audio via Bluetooth I2S
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts | 275 ++++++++++++++++++++++
2 files changed, 276 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..4a80971f2bc9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -946,6 +946,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31s-sinovoip-bpi-m2.dtb \
sun6i-a31s-yones-toptech-bs1078-v2.dtb
dtb-$(CONFIG_MACH_SUN7I) += \
+ sun7i-a20-ainol-aw1.dtb \
sun7i-a20-bananapi.dtb \
sun7i-a20-bananapi-m1-plus.dtb \
sun7i-a20-bananapro.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
new file mode 100644
index 000000000000..9a1d54a9f9a0
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
@@ -0,0 +1,275 @@
+/*
+ * Copyright (C) 2018 Paul Kocialkowski <contact@paulk.fr>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+ model = "Ainol AW1";
+ compatible = "ainol,ainol-aw1", "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <5>;
+ enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ };
+
+ panel: panel {
+ compatible = "innolux,at070tn90";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-supply = <&panel_power>;
+ backlight = <&backlight>;
+
+ port at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_panel>;
+ };
+ };
+ };
+
+ panel_power: panel_power {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&panel_power_pin>;
+ regulator-name = "panel-power";
+ regulator-min-microvolt = <10400000>;
+ regulator-max-microvolt = <10400000>;
+ gpio = <&pio 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
+ enable-active-high;
+ regulator-boot-on;
+ };
+};
+
+&codec {
+ allwinner,pa-gpios = <&pio 7 15 GPIO_ACTIVE_HIGH>; /* PH15 */
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&de {
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic at 34 {
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+
+ lis3dh: accelerometer at 18 {
+ compatible = "st,lis3dh-accel";
+ reg = <0x18>;
+ vdd-supply = <®_vcc3v3>;
+ vddio-supply = <®_vcc3v3>;
+ st,drdy-int-pin = <1>;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+ clock-frequency = <400000>;
+
+ gsl1680: touchscreen at 40 {
+ compatible = "silead,gsl1680";
+ reg = <0x40>;
+ interrupt-parent = <&pio>;
+ interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>; /* EINT21 (PH21) */
+ power-gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */
+ firmware-name = "gsl1680-ainol-aw1.fw";
+ touchscreen-size-x = <480>;
+ touchscreen-size-y = <800>;
+ touchscreen-swapped-x-y;
+ touchscreen-inverted-y;
+ silead,max-fingers = <5>;
+ };
+};
+
+&lradc {
+ vref-supply = <®_ldo2>;
+ status = "okay";
+
+ button at 571 {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ channel = <0>;
+ voltage = <571428>;
+ };
+
+ button at 761 {
+ label = "Volume Down";
+ linux,code = <KEY_VOLUMEDOWN>;
+ channel = <0>;
+ voltage = <761904>;
+ };
+
+ button at 952 {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ channel = <0>;
+ voltage = <952380>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+&pio {
+ panel_power_pin: panel_power_pin at 0 {
+ pins = "PH8";
+ function = "gpio_out";
+ };
+};
+
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pins_a>;
+ status = "okay";
+};
+
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd0_rgb666_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_panel: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ usb0_vbus_power-supply = <&usb_power_supply>;
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_usb1_vbus>;
+ usb2_vbus-supply = <®_usb2_vbus>;
+ status = "okay";
+};
+
+#include "axp209.dtsi"
+
+&battery_power_supply {
+ status = "okay";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+®_usb0_vbus {
+ status = "okay";
+};
+
+®_usb1_vbus {
+ status = "okay";
+};
+
+®_usb2_vbus {
+ status = "okay";
+};
+
+&usb_power_supply {
+ status = "okay";
+};
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx28-cfa10049: Remove unnecessary #address/#size-cells
From: Fabio Estevam @ 2018-05-07 1:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Remove unnecessary #address-cells/#size-cells to fix the following
DTC warnings:
arch/arm/boot/dts/imx28-cfa10049.dtb: Warning (avoid_unnecessary_addr_size): /gpio_keys: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx28-cfa10049.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 60e5c7f..f1c8315 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -398,8 +398,6 @@
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&rotary_btn_pins_cfa10049>;
- #address-cells = <1>;
- #size-cells = <0>;
rotary_button {
label = "rotary_button";
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx28-duckbill-2-enocean: Remove unnecessary #address/#size-cells
From: Fabio Estevam @ 2018-05-07 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525655020-31260-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Remove unnecessary #address-cells/#size-cells to fix the following
DTC warnings:
arch/arm/boot/dts/imx28-duckbill-2-enocean.dtb: Warning (avoid_unnecessary_addr_size): /gpio-keys: unnecessary #address-cells/#size-cells without "ranges" or child "reg" propert
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx28-duckbill-2-enocean.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-duckbill-2-enocean.dts b/arch/arm/boot/dts/imx28-duckbill-2-enocean.dts
index 7f8d40a..2221533 100644
--- a/arch/arm/boot/dts/imx28-duckbill-2-enocean.dts
+++ b/arch/arm/boot/dts/imx28-duckbill-2-enocean.dts
@@ -206,8 +206,6 @@
gpio-keys {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&enocean_button>;
--
2.7.4
^ permalink raw reply related
* [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs
From: Boqun Feng @ 2018-05-07 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180506121129.baacc4fxgr72rzex@gmail.com>
On Sun, May 6, 2018, at 8:11 PM, Ingo Molnar wrote:
>
> * Boqun Feng <boqun.feng@gmail.com> wrote:
>
> > > The only change I made beyond a trivial build fix is that I also added the release
> > > atomics variants explicitly:
> > >
> > > +#define atomic_cmpxchg_release(v, o, n) \
> > > + cmpxchg_release(&((v)->counter), (o), (n))
> > > +#define atomic64_cmpxchg_release(v, o, n) \
> > > + cmpxchg_release(&((v)->counter), (o), (n))
> > >
> > > It has passed a PowerPC cross-build test here, but no runtime tests.
> > >
> >
> > Do you have the commit at any branch in tip tree? I could pull it and
> > cross-build and check the assembly code of lib/atomic64_test.c, that way
> > I could verify whether we mess something up.
> >
> > > Does this patch look good to you?
> > >
> >
> > Yep!
>
> Great - I have pushed the commits out into the locking tree, they can be
> found in:
>
> git fetch git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> locking/core
>
Thanks! My compile test told me that we need to remove the definitions of
atomic_xchg and atomic64_xchg in ppc's asm/atomic.h: they are now
duplicate, and will prevent the generation of _release and _acquire in the
new logic.
If you need a updated patch for this from me, I could send later today.
(I don't have a handy environment for patch sending now, so...)
Other than this, the modification looks fine, the lib/atomic64_test.c
generated the same asm before and after the patches.
Regards,
Boqun
> The PowerPC preparatory commit from you is:
>
> 0476a632cb3a: locking/atomics/powerpc: Move cmpxchg helpers to asm/
> cmpxchg.h and define the full set of cmpxchg APIs
>
> Thanks,
>
> Ingo
^ permalink raw reply
* [PATCH v8 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64
From: Jia He @ 2018-05-07 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23b14717-0f4a-10f2-5118-7cb8445fbdab@oracle.com>
On 5/5/2018 12:53 AM, Pavel Tatashin Wrote:
>> I'm wondering, ain't simple enabling of config
>> DEFERRED_STRUCT_PAGE_INIT provide even better speed-up? If that is the
>> case then it seems like this series is not needed at all, right?
>> I am not sure why is this config optional. It looks like it could be
>> enabled by default or even unconditionally considering that with
>> commit c9e97a1997fb ("mm: initialize pages on demand during boot") the
>> deferred code is statically disabled after all the pages are
>> initialized.
> Hi Daniel,
>
> Currently, deferred struct pages are initialized in parallel only on NUMA machines. I would like to make a change to use all the available CPUs even on a single socket systems, but that is not there yet. So, I believe Jia's performance improvements are still relevant.
Thanks for the information. I checked the config in my armv8a server,
DEFERRED_STRUCT_PAGE_INIT has not been enabled yet.And my server is
single socket.
Cheers.
Jia
^ permalink raw reply
* [PATCH] ARM: dts: imx7s: Pass the 'fsl,sec-era' property
From: Shawn Guo @ 2018-05-07 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AVjFCad4PC20X5PqMuKGJQ2cOSBnqbGw+ngYCODL2vmQ@mail.gmail.com>
On Fri, May 04, 2018 at 01:31:52PM -0300, Fabio Estevam wrote:
> Hi Shawn,
>
> On Fri, May 4, 2018 at 4:19 AM, Shawn Guo <shawnguo@kernel.org> wrote:
>
> > The property is documented as optional in the bindings. Missing the
> > property shouldn't cause any fatal error, I guess.
>
> The CAAM drivers uses the era information in many places:
>
> drivers/crypto/caam/caamalg.c: if (ctrlpriv->era >= 6) {
> drivers/crypto/caam/caamalg.c: if (ctrlpriv->era < 3)
> drivers/crypto/caam/caamalg.c: if (priv->era >= 6 && uses_dkp)
> drivers/crypto/caam/caamalg_desc.c: if (era < 6) {
> drivers/crypto/caam/caamalg_desc.c: /* Class 2 operation */
> drivers/crypto/caam/caamalg_desc.c: if (era < 6) {
> drivers/crypto/caam/caamalg_desc.c: /* Class 2 operation */
> drivers/crypto/caam/caamalg_desc.c: if (era < 6) {
>
> If the era information is not provided the value of -524 (-ENOTSUPP)
> will be used, so all the above logic will not operate correctly.
>
> I have sent a patch that allows the era information to be retrieved
> via CAAM registers:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/crypto/caam/ctrl.c?h=next-20180424&id=654f2b937b389295581bcb4aa26011a63db7bc8f
>
> but this will only land in 4.18.
>
> In order to avoid i.MX7 to report the incorrect era information in
> 4.17 I suggest that this patch should be applied for 4.17-rc.
I applied it for 4.17, but still questioning whether it's reasonable to
have the property documented as optional in bindings, if missing the
property results in a non-functional driver.
Shawn
^ permalink raw reply
* [PATCH V7 1/7] ARM: dts: imx6sx-sabreauto: add PMIC support
From: Shawn Guo @ 2018-05-07 1:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525588093-29994-1-git-send-email-Anson.Huang@nxp.com>
On Sun, May 06, 2018 at 02:28:07PM +0800, Anson Huang wrote:
> Add pfuze100 support on i.MX6SX Sabre Auto board.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH 3/4] ARM: dts: imx27: use lable to override osc26m clock setting
From: Shawn Guo @ 2018-05-07 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5D1Dc9hh-o81fvy8PKNx_m8gdR9yW2w5Xumse1VFHFLTQ@mail.gmail.com>
On Fri, May 04, 2018 at 12:34:29PM -0300, Fabio Estevam wrote:
> Hi Shawn,
>
> On Thu, May 3, 2018 at 9:57 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> > Instead of copying the whole node hierarchy, let's define a label for
> > clock osc26m in soc dtsi and use it for overriding clock-frequency.
> >
> > Signed-off-by: Shawn Guo <shawnguo@kernel.org>
>
> In the Subject: s/lable/label
Fixed. Thanks, Fabio.
Shawn
^ permalink raw reply
* [PATCH -next] ASoC: fix return value check in mt6351_codec_driver_probe()
From: Wei Yongjun @ 2018-05-07 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In case of error, the function dev_get_regmap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
sound/soc/codecs/mt6351.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/mt6351.c b/sound/soc/codecs/mt6351.c
index e739f07..f73dcd7 100644
--- a/sound/soc/codecs/mt6351.c
+++ b/sound/soc/codecs/mt6351.c
@@ -1472,8 +1472,8 @@ static int mt6351_codec_driver_probe(struct platform_device *pdev)
priv->dev = &pdev->dev;
priv->regmap = dev_get_regmap(pdev->dev.parent, NULL);
- if (IS_ERR(priv->regmap))
- return PTR_ERR(priv->regmap);
+ if (!priv->regmap)
+ return -ENODEV;
dev_dbg(priv->dev, "%s(), dev name %s\n",
__func__, dev_name(&pdev->dev));
^ permalink raw reply related
* [PATCH -next] gpio: Fix return value check in owl_gpio_probe()
From: Wei Yongjun @ 2018-05-07 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In case of error, the function of_iomap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Fixes: d3654d38809c ("gpio: Add gpio driver for Actions OWL S900 SoC")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/gpio/gpio-owl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-owl.c b/drivers/gpio/gpio-owl.c
index 3546362..f35e80f 100644
--- a/drivers/gpio/gpio-owl.c
+++ b/drivers/gpio/gpio-owl.c
@@ -128,8 +128,8 @@ static int owl_gpio_probe(struct platform_device *pdev)
return -ENOMEM;
gpio->base = of_iomap(dev->of_node, 0);
- if (IS_ERR(gpio->base))
- return PTR_ERR(gpio->base);
+ if (!gpio->base)
+ return -ENOMEM;
/*
* Get the number of gpio's for this bank. If none specified,
^ permalink raw reply related
* [PATCH] ARM: dts: imx7s: Pass the 'fsl,sec-era' property
From: Fabio Estevam @ 2018-05-07 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507011710.GH3443@dragon>
On Sun, May 6, 2018 at 10:17 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> I applied it for 4.17, but still questioning whether it's reasonable to
> have the property documented as optional in bindings, if missing the
> property results in a non-functional driver.
Thanks Shawn. Yes, after my CAAM patch gets applied it will be a
proper optional property.
^ permalink raw reply
* [PATCH] pinctrl: mvebu: use correct MPP sel value for dev pins
From: Chris Packham @ 2018-05-07 2:25 UTC (permalink / raw)
To: linux-arm-kernel
The "dev" function is selected with the value 0x4 not 0x01.
Fixes: commit d7ae8f8dee7f ("pinctrl: mvebu: pinctrl driver for 98DX3236 SoC")
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 28b199796fae..5e828468e43d 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -437,34 +437,34 @@ static struct mvebu_mpp_mode mv98dx3236_mpp_modes[] = {
MPP_VAR_FUNCTION(0x4, "dev", "we0", V_98DX3236_PLUS)),
MPP_MODE(21,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad0", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad0", V_98DX3236_PLUS)),
MPP_MODE(22,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad1", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad1", V_98DX3236_PLUS)),
MPP_MODE(23,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad2", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad2", V_98DX3236_PLUS)),
MPP_MODE(24,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad3", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad3", V_98DX3236_PLUS)),
MPP_MODE(25,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad4", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad4", V_98DX3236_PLUS)),
MPP_MODE(26,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad5", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad5", V_98DX3236_PLUS)),
MPP_MODE(27,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad6", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad6", V_98DX3236_PLUS)),
MPP_MODE(28,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad7", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad7", V_98DX3236_PLUS)),
MPP_MODE(29,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "a0", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "a0", V_98DX3236_PLUS)),
MPP_MODE(30,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "a1", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "a1", V_98DX3236_PLUS)),
MPP_MODE(31,
MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
MPP_VAR_FUNCTION(0x1, "slv_smi", "mdc", V_98DX3236_PLUS),
--
2.17.0
^ permalink raw reply related
* [PATCH] arm64: export memblock_reserve()d regions via /proc/iomem
From: Akashi Takahiro @ 2018-05-07 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2708a0b0-72c7-b518-cced-a87b8a94ab79@arm.com>
James,
# I was off the last week.
On Wed, May 02, 2018 at 11:35:04AM +0100, James Morse wrote:
> Hi guys,
>
> On 25/04/18 14:22, James Morse wrote:
> > There has been some confusion around what is necessary to prevent kexec
> > overwriting important memory regions. memblock: reserve, or nomap?
> > Only memblock nomap regions are reported via /proc/iomem, kexec's
> > user-space doesn't know about memblock_reserve()d regions.
> >
> > Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory
> > as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved
> > and thus possible for kexec to overwrite with the new kernel or initrd.
> > But this was always broken, as the UEFI memory map is also reserved
> > and not marked as nomap.
> >
> > It turns out that while kexec-tools will pick up reserved sections in
> > iomem that look like:
> > | 80000000-dfffffff : System RAM
> > | 81000000-8158ffff : reserved
> >
> > The reserved section is ignored by its 'locate_hole()' code. To fix
> > this, we need to describe memblock_reserved() and nomap regions as
> > 'reserved' at the top level:
> > | 80000000-80ffffff : System RAM
> > | 81000000-8158ffff : reserved
> > | 81590000-dfffffff : System RAM
> >
> > To complicate matters, our existing named sections are described as
> > being part of 'System RAM', but they are also memblock_reserve()d.
> > We need to keep this in-case something is depending on it. To do this
> > involves walking memblock multiple times:
> >
> > First add the 'System RAM' sections that are memory and not-reserved.
> > These may be smaller than a page if part of the page is reserved. In
> > this case we want to describe the page as reserved, so we round these
> > regions down to the smallest page-size region, which may be empty.
> > (We round-up the memblock_reserved() regions to fill in the gaps).
> >
> > The boundaries for kernel_data are changed because paging_init() punches
> > holes in the _sdata -> _edata region, and this code can't add a named
> > region that crosses memblock_reserve()d<->normal-memory regions. The
> > new helpers will catch any more overlapping regions that occur.
> >
> > Lastly, we add the memblock_reserved() regions using
> > reserve_region_with_split(), which will fill in the gaps between the
> > existing named regions. (e.g. the regions occupied by the __init code).
> > This call uses the slab allocator, so has to run from an initcall.
>
> Re-reading Akashi's description of how kdump generates the ELF headers for
> /proc/vmcore, this change might break kdump, as now the memblock_reserved()
> regions may be missing from /proc/vmcore. (I'll test that).
I also tested your patch, and there seems to be something wrong.
Actually, crash utility fails to read the core:
crash-arm64: read error: kernel virtual address: ffff0000091fa998 \
type: "shadow_timekeeper xtime_sec"
crash-arm64: read error: kernel virtual address: ffff0000091fda48 \
type: "high_memory"
Meanwhile,
$ cat /proc/iomem
40000000-4007ffff : System RAM
40080000-40f5ffff : System RAM
40080000-40f5ffff : Kernel code
40f60000-4107ffff : reserved
41080000-411c9fff : System RAM
41080000-411c99ff : Kernel data
411ca000-4122ffff : reserved <=== (A)
41230000-483fffff : System RAM
48400000-583fffff : System RAM
48400000-583fffff : Crash kernel
58400000-5858ffff : System RAM
58590000-585effff : reserved
...
Adding some debug messages shows that "shadow_timekeeper" variable
belongs to the range (A), which is originally part of "Kernel data"
and should have been unmarked from "reserved" list.
> Unless there is a 'name' for a region that kexec-tools interprets as "don't
> overwrite this, but do include it in the ELF header", then we're stuck. We can't
> fix kexec without breaking kdump, we have to change user-space.
>
> Of the two, missing data from kdump vmcore would be preferable to failed-to-boot
> kexec.
Well, kexec has had this potential bug since the day One in mainline.
(we were then using "boot wrapper" instead of normal boot loaders though.)
Even if we accept your assertion above now, future new-comers may
"rediscover" a kdump bug and make a complaint time to time.
So I think that we would be better off fixing the issue right now
completely with accompanying user-space change.
Thanks,
-Takahiro AKASHI
> If we have to change user-space, I'd like to make use of the kernels
> ability to generate the ELF header itself, (e.g. kexec_file_load()).
>
>
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 30ad2f085d1f..e82c0d5c70f8 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -202,45 +202,135 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
>
> > static void __init request_standard_resources(void)
> > {
>
> [...]
>
> > + /*
> > + * We can't allocate memory while walking free memory, count the number
> > + * of struct resource's we will need. Round start/end to the smallest
> > + * page-size region as we round the reserved regions up.
> > + */
> > + for_each_free_mem_range(i, NUMA_NO_NODE, 0, &start, &end, NULL) {
>
> Nit: That 0 should be MEMBLOCK_NONE
>
>
>
> Thanks,
>
> James
>
^ permalink raw reply
* [PATCH -next] gpio: Fix return value check in owl_gpio_probe()
From: Manivannan Sadhasivam @ 2018-05-07 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525657224-88189-1-git-send-email-weiyongjun1@huawei.com>
Hi Wei,
Thanks for the patch.
On Mon, May 07, 2018 at 01:40:24AM +0000, Wei Yongjun wrote:
> In case of error, the function of_iomap() returns NULL pointer not
> ERR_PTR(). The IS_ERR() test in the return value check should be
> replaced with NULL test.
>
> Fixes: d3654d38809c ("gpio: Add gpio driver for Actions OWL S900 SoC")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/gpio/gpio-owl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-owl.c b/drivers/gpio/gpio-owl.c
> index 3546362..f35e80f 100644
> --- a/drivers/gpio/gpio-owl.c
> +++ b/drivers/gpio/gpio-owl.c
> @@ -128,8 +128,8 @@ static int owl_gpio_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> gpio->base = of_iomap(dev->of_node, 0);
> - if (IS_ERR(gpio->base))
> - return PTR_ERR(gpio->base);
> + if (!gpio->base)
> + return -ENOMEM;
>
Agree with the check here. But the return value should be -ENXIO?
Regards,
Mani
> /*
> * Get the number of gpio's for this bank. If none specified,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] drm/kms/mode: added a new helper for calculating videomode from crtc's display mode
From: Satendra Singh Thakur @ 2018-05-07 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87sh777o63.fsf@intel.com>
1.
-Added a new helper drm_display_mode_crtc_to_videomode
-This helper calculates mode parameters like
--horizontal front_porch, back_porch, sync length
--vertical front_porch, back_porch, sync length
-using crtc fields of struct drm_display_mode
-It uses following fields of crtc mode
--horizontal sync start/end, active and total length
--vertical sync start/end, active and total length
2.
-Most of the driver use user-supplied mode for calculating videomode
-However, few drivers use HW (crtc) mode for calculating videomode
-This helper will be useful for such drivers
3.
-Currently following drivers will be using this new helper
-arm hdlcd
-atmel hlcdc
-exynos 5433 decon
-exynos7 decon
-exynos fimd
4.
-This change reduces several redundant lines of code for many drivers
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Satendra Singh Thakur <satendra.t@samsung.com>
Acked-by: Madhur Verma <madhur.verma@samsung.com>
Cc: Hemanshu Srivastava <hemanshu.s@samsung.com>
---
v2: Removed Mr Jani from Reviewed-by field
drivers/gpu/drm/arm/hdlcd_crtc.c | 10 ++--------
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 ++-------
drivers/gpu/drm/drm_modes.c | 19 +++++++++++++++++++
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 22 ++++++++++------------
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 23 ++++++++++-------------
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 22 +++++++++-------------
include/drm/drm_modes.h | 2 ++
7 files changed, 54 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index cf5cbd6..5cec264 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -127,16 +127,10 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
struct drm_display_mode *m = &crtc->state->adjusted_mode;
- struct videomode vm;
+ struct videomode vm = {};
unsigned int polarities, err;
- vm.vfront_porch = m->crtc_vsync_start - m->crtc_vdisplay;
- vm.vback_porch = m->crtc_vtotal - m->crtc_vsync_end;
- vm.vsync_len = m->crtc_vsync_end - m->crtc_vsync_start;
- vm.hfront_porch = m->crtc_hsync_start - m->crtc_hdisplay;
- vm.hback_porch = m->crtc_htotal - m->crtc_hsync_end;
- vm.hsync_len = m->crtc_hsync_end - m->crtc_hsync_start;
-
+ drm_display_mode_crtc_to_videomode(m, &vm);
polarities = HDLCD_POLARITY_DATAEN | HDLCD_POLARITY_DATA;
if (m->flags & DRM_MODE_FLAG_PHSYNC)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d732810..fb298b8 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -76,17 +76,12 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c)
struct drm_display_mode *adj = &c->state->adjusted_mode;
struct atmel_hlcdc_crtc_state *state;
unsigned long mode_rate;
- struct videomode vm;
+ struct videomode vm = {};
unsigned long prate;
unsigned int cfg;
int div;
- vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
- vm.vback_porch = adj->crtc_vtotal - adj->crtc_vsync_end;
- vm.vsync_len = adj->crtc_vsync_end - adj->crtc_vsync_start;
- vm.hfront_porch = adj->crtc_hsync_start - adj->crtc_hdisplay;
- vm.hback_porch = adj->crtc_htotal - adj->crtc_hsync_end;
- vm.hsync_len = adj->crtc_hsync_end - adj->crtc_hsync_start;
+ drm_display_mode_crtc_to_videomode(adj, &vm);
regmap_write(regmap, ATMEL_HLCDC_CFG(1),
(vm.hsync_len - 1) | ((vm.vsync_len - 1) << 16));
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e82b61e..328f771 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -654,6 +654,25 @@ void drm_display_mode_to_videomode(const struct drm_display_mode *dmode,
vm->flags |= DISPLAY_FLAGS_DOUBLECLK;
}
EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
+/**
+ * drm_display_mode_crtc_to_videomode - fill in @vm using crtc fields of @dmode
+ * @dmode: drm_display_mode structure to use as source
+ * @vm: videomode structure to use as destination
+ *
+ * Fills out @vm using the crtc display mode specified in @dmode.
+ */
+void drm_display_mode_crtc_to_videomode(const struct drm_display_mode *dmode,
+ struct videomode *vm)
+{
+ vm->hfront_porch = dmode->crtc_hsync_start - dmode->crtc_hdisplay;
+ vm->hsync_len = dmode->crtc_hsync_end - dmode->crtc_hsync_start;
+ vm->hback_porch = dmode->crtc_htotal - dmode->crtc_hsync_end;
+ vm->vfront_porch = dmode->crtc_vsync_start - dmode->crtc_vdisplay;
+ vm->vsync_len = dmode->crtc_vsync_end - dmode->crtc_vsync_start;
+ vm->vback_porch = dmode->crtc_vtotal - dmode->crtc_vsync_end;
+
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_crtc_to_videomode);
/**
* drm_bus_flags_from_videomode - extract information about pixelclk and
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 1c330f2..2535ebb 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -20,6 +20,7 @@
#include <linux/of_gpio.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
+#include <video/videomode.h>
#include "exynos_drm_drv.h"
#include "exynos_drm_crtc.h"
@@ -225,26 +226,23 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
writel(val, ctx->addr + DECON_VIDTCON2);
if (!crtc->i80_mode) {
- int vbp = m->crtc_vtotal - m->crtc_vsync_end;
- int vfp = m->crtc_vsync_start - m->crtc_vdisplay;
+ struct videomode vm = {};
+ drm_display_mode_crtc_to_videomode(m, &vm);
if (interlaced)
- vbp = vbp / 2 - 1;
- val = VIDTCON00_VBPD_F(vbp - 1) | VIDTCON00_VFPD_F(vfp - 1);
+ vm.vback_porch = (vm.vback_porch >> 1) - 1;
+ val = VIDTCON00_VBPD_F(vm.vback_porch - 1) |
+ VIDTCON00_VFPD_F(vm.vfront_porch - 1);
writel(val, ctx->addr + DECON_VIDTCON00);
- val = VIDTCON01_VSPW_F(
- m->crtc_vsync_end - m->crtc_vsync_start - 1);
+ val = VIDTCON01_VSPW_F(vm.vsync_len - 1);
writel(val, ctx->addr + DECON_VIDTCON01);
- val = VIDTCON10_HBPD_F(
- m->crtc_htotal - m->crtc_hsync_end - 1) |
- VIDTCON10_HFPD_F(
- m->crtc_hsync_start - m->crtc_hdisplay - 1);
+ val = VIDTCON10_HBPD_F(vm.hback_porch - 1) |
+ VIDTCON10_HFPD_F(vm.hfront_porch - 1);
writel(val, ctx->addr + DECON_VIDTCON10);
- val = VIDTCON11_HSPW_F(
- m->crtc_hsync_end - m->crtc_hsync_start - 1);
+ val = VIDTCON11_HSPW_F(vm.hsync_len - 1);
writel(val, ctx->addr + DECON_VIDTCON11);
}
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3931d5e..5fdd093 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -25,6 +25,7 @@
#include <video/of_display_timing.h>
#include <video/of_videomode.h>
+#include <video/videomode.h>
#include "exynos_drm_crtc.h"
#include "exynos_drm_plane.h"
@@ -168,28 +169,24 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
return;
if (!ctx->i80_if) {
- int vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd;
+ struct videomode vm = {};
+
+ drm_display_mode_crtc_to_videomode(mode, &vm);
/* setup vertical timing values. */
- vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start;
- vbpd = mode->crtc_vtotal - mode->crtc_vsync_end;
- vfpd = mode->crtc_vsync_start - mode->crtc_vdisplay;
- val = VIDTCON0_VBPD(vbpd - 1) | VIDTCON0_VFPD(vfpd - 1);
+ val = VIDTCON0_VBPD(vm.vback_porch - 1) |
+ VIDTCON0_VFPD(vm.vfront_porch - 1);
writel(val, ctx->regs + VIDTCON0);
- val = VIDTCON1_VSPW(vsync_len - 1);
+ val = VIDTCON1_VSPW(vm.vsync_len - 1);
writel(val, ctx->regs + VIDTCON1);
/* setup horizontal timing values. */
- hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start;
- hbpd = mode->crtc_htotal - mode->crtc_hsync_end;
- hfpd = mode->crtc_hsync_start - mode->crtc_hdisplay;
-
- /* setup horizontal timing values. */
- val = VIDTCON2_HBPD(hbpd - 1) | VIDTCON2_HFPD(hfpd - 1);
+ val = VIDTCON2_HBPD(vm.hback_porch - 1) |
+ VIDTCON2_HFPD(vm.hfront_porch - 1);
writel(val, ctx->regs + VIDTCON2);
- val = VIDTCON3_HSPW(hsync_len - 1);
+ val = VIDTCON3_HSPW(vm.hsync_len - 1);
writel(val, ctx->regs + VIDTCON3);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index d42ae2b..c70b9ec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -25,6 +25,7 @@
#include <video/of_display_timing.h>
#include <video/of_videomode.h>
+#include <video/videomode.h>
#include <video/samsung_fimd.h>
#include <drm/exynos_drm.h>
@@ -463,7 +464,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
return;
}
} else {
- int vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd;
+ struct videomode vm = {};
u32 vidcon1;
/* setup polarity values */
@@ -474,24 +475,19 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
vidcon1 |= VIDCON1_INV_HSYNC;
writel(vidcon1, ctx->regs + driver_data->timing_base + VIDCON1);
+ drm_display_mode_crtc_to_videomode(mode, &vm);
/* setup vertical timing values. */
- vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start;
- vbpd = mode->crtc_vtotal - mode->crtc_vsync_end;
- vfpd = mode->crtc_vsync_start - mode->crtc_vdisplay;
- val = VIDTCON0_VBPD(vbpd - 1) |
- VIDTCON0_VFPD(vfpd - 1) |
- VIDTCON0_VSPW(vsync_len - 1);
+ val = VIDTCON0_VBPD(vm.vback_porch - 1) |
+ VIDTCON0_VFPD(vm.vfront_porch - 1) |
+ VIDTCON0_VSPW(vm.vsync_len - 1);
writel(val, ctx->regs + driver_data->timing_base + VIDTCON0);
/* setup horizontal timing values. */
- hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start;
- hbpd = mode->crtc_htotal - mode->crtc_hsync_end;
- hfpd = mode->crtc_hsync_start - mode->crtc_hdisplay;
- val = VIDTCON1_HBPD(hbpd - 1) |
- VIDTCON1_HFPD(hfpd - 1) |
- VIDTCON1_HSPW(hsync_len - 1);
+ val = VIDTCON1_HBPD(vm.hback_porch - 1) |
+ VIDTCON1_HFPD(vm.hfront_porch - 1) |
+ VIDTCON1_HSPW(vm.hsync_len - 1);
writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);
}
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 0d310be..9ac764b 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -473,6 +473,8 @@ void drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
void drm_display_mode_to_videomode(const struct drm_display_mode *dmode,
struct videomode *vm);
+void drm_display_mode_crtc_to_videomode(const struct drm_display_mode *dmode,
+ struct videomode *vm);
void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags);
int of_get_drm_display_mode(struct device_node *np,
struct drm_display_mode *dmode, u32 *bus_flags,
--
2.7.4
^ permalink raw reply related
* [PATCH v2 03/13] drm/kms/mode/exynos-dsi: using helper func drm_display_mode_to_videomode for calculating timing parameters
From: Satendra Singh Thakur @ 2018-05-07 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <920ac8d1-8d2d-1332-256d-21472f69fca5@arm.com>
To avoid duplicate logic for the same
Signed-off-by: Satendra Singh Thakur <satendra.t@samsung.com>
Acked-by: Madhur Verma <madhur.verma@samsung.com>
Cc: Hemanshu Srivastava <hemanshu.s@samsung.com>
---
v2: Removed Mr Robin from reviewed-by field
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7904ffa..7fe84fd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1490,17 +1490,8 @@ static void exynos_dsi_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
- struct videomode *vm = &dsi->vm;
- struct drm_display_mode *m = adjusted_mode;
-
- vm->hactive = m->hdisplay;
- vm->vactive = m->vdisplay;
- vm->vfront_porch = m->vsync_start - m->vdisplay;
- vm->vback_porch = m->vtotal - m->vsync_end;
- vm->vsync_len = m->vsync_end - m->vsync_start;
- vm->hfront_porch = m->hsync_start - m->hdisplay;
- vm->hback_porch = m->htotal - m->hsync_end;
- vm->hsync_len = m->hsync_end - m->hsync_start;
+
+ drm_display_mode_to_videomode(adjusted_mode, &dsi->vm);
}
static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = {
--
2.7.4
^ permalink raw reply related
* [PATCH v9 02/11] kexec_file: make kexec_image_post_load_cleanup_default() global
From: AKASHI Takahiro @ 2018-05-07 4:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbf66675-1671-32f9-1410-a76986becf85@arm.com>
On Tue, May 01, 2018 at 06:46:04PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > Change this function from static to global so that arm64 can implement
> > its own arch_kimage_file_post_load_cleanup() later using
> > kexec_image_post_load_cleanup_default().
>
> Do we need to call kexec_image_post_load_cleanup_default()? All it does is call
> the image-type fops->cleanup(), which you don't implement in this series.
>
> Is this just-in-case someone adds cleanup() later and is surprised only the
> arch-level helper is called?
Yes, we want not to miss two possibilities:
- some common clean-up code is added to kexec_image_post_load_cleanup_default()
- some format(i.e. Image)-specific clean-up code is added to fops->cleanup()
-Takahiro AKASHI
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory
From: AKASHI Takahiro @ 2018-05-07 5:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c830fe8-56d8-b43a-6265-43d31dffe61a@arm.com>
On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > On arm64, purugatory would do almosty nothing. So just invoke secondary
> > kernel directy by jumping into its entry code.
>
> (Nits: purgatory, almost, directly)
Oops, I think I ran spell before ...
>
> > While, in this case, cpu_soft_restart() must be called with dtb address
> > in the fifth argument, the behavior still stays compatible with kexec_load
> > case as long as the argument is null.
>
>
> > diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
> > index 8021b46c9743..391df91328ac 100644
> > --- a/arch/arm64/kernel/cpu-reset.S
> > +++ b/arch/arm64/kernel/cpu-reset.S
> > @@ -24,9 +24,9 @@
> > *
> > * @el2_switch: Flag to indicate a swich to EL2 is needed.
>
> (Nit: switch)
ditto
> > * @entry: Location to jump to for soft reset.
> > - * arg0: First argument passed to @entry.
> > - * arg1: Second argument passed to @entry.
> > - * arg2: Third argument passed to @entry.
> > + * arg0: First argument passed to @entry. (relocation list)
> > + * arg1: Second argument passed to @entry.(physcal kernel entry)
>
> (Nit: physical)
ditto
>
> > + * arg2: Third argument passed to @entry. (physical dtb address)
> > *
> > * Put the CPU into the same state as it would be if it had been reset, and
> > * branch to what would be the reset vector. It must be executed with the
> > diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> > index f76ea92dff91..f7dbba00be10 100644
> > --- a/arch/arm64/kernel/machine_kexec.c
> > +++ b/arch/arm64/kernel/machine_kexec.c
> > @@ -205,10 +205,17 @@ void machine_kexec(struct kimage *kimage)
> > * uses physical addressing to relocate the new image to its final
> > * position and transfers control to the image entry point when the
> > * relocation is complete.
> > + * In case of kexec_file_load syscall, we directly start the kernel,
> > + * skipping purgatory.
>
> We're not really skipping purgatory, purgatory doesn't exist! For regular kexec
> the image/payload we run is up to kexec-tools. For kexec_file_load its a
> kernel-image. Purgatory is a kexec-tools-ism.
You are right, but in general, purgatory is expected to exist by
generic kexec code and does exist on all architectures, kexec_load()
or kexec_file_load(), except arm64's kexec_file_load case.
So it would be nice to have some explicit notes here.
>
> > cpu_soft_restart(kimage != kexec_crash_image,
> > - reboot_code_buffer_phys, kimage->head, kimage->start, 0);
> > + reboot_code_buffer_phys, kimage->head, kimage->start,
> > +#ifdef CONFIG_KEXEC_FILE
> > + kimage->purgatory_info.purgatory_buf ?
> > + 0 : kimage->arch.dtb_mem);
> > +#else
> > + 0);
> > +#endif
>
> Where does kimage->arch.dtb_mem come from? This patch won't build until patch 8
> adds the config option, which is going to make bisecting any kexec side-effects
> tricky.
CONFIG_KEXEC_FILE is also used in patch #4, #5 and #6.
I don't know how we can fix this as the implementation is divided
into several patches.
(So bisecting doesn't work anyway.)
> purgatory_buf seems to only be set in kexec_purgatory_setup_kbuf(), called from
> kexec_load_purgatory(), which we don't use. How does this get a value?
>
> Would it be better to always use kimage->arch.dtb_mem, and ensure that is 0 for
> regular kexec (as we can't know where the dtb is)? (image_arg may then be a
> better name).
The problem is arch.dtb_mem is currently defined only if CONFIG_KEXEC_FILE.
So I would like to
- merge this patch with patch#8
- change the condition
#ifdef CONFIG_KEXEC_FILE
kimage->file_mode ? kimage->arch.dtb_mem : 0);
#else
0);
#endif
Thanks,
-Takahiro AKASHI
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
From: AKASHI Takahiro @ 2018-05-07 5:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <648656ef-1f1e-b0ac-581c-aba1e62f4eee@arm.com>
James,
On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > We need to prevent firmware-reserved memory regions, particularly EFI
> > memory map as well as ACPI tables, from being corrupted by loading
> > kernel/initrd (or other kexec buffers). We also want to support memory
> > allocation in top-down manner in addition to default bottom-up.
> > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > for available memory ranges in usable memblock list,
> > i.e. !NOMAP & !reserved,
>
> > instead of system resource tree.
>
> Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
> be safe in the EFI-memory-map/ACPI-tables case?
>
> It would be good to avoid having two ways of doing this, and I would like to
> avoid having extra arch code...
I know what you mean.
/proc/iomem or system resource is, in my opinion, not the best place to
describe memory usage of kernel but rather to describe *physical* hardware
layout. As we are still discussing about "reserved" memory, I don't want
to depend on it.
Along with memblock list, we will have more accurate control over memory
usage.
>
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > new file mode 100644
> > index 000000000000..f9ebf54ca247
> > --- /dev/null
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -0,0 +1,57 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * kexec_file for arm64
> > + *
> > + * Copyright (C) 2018 Linaro Limited
> > + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > + *
>
> > + * Most code is derived from arm64 port of kexec-tools
>
> How does kexec-tools walk memblock?
Will remove this comment from this patch.
Obviously, this comment is for the rest of the code which will be
added to succeeding patches (patch #5 and #7).
>
> > + */
> > +
> > +#define pr_fmt(fmt) "kexec_file: " fmt
> > +
> > +#include <linux/ioport.h>
> > +#include <linux/kernel.h>
> > +#include <linux/kexec.h>
> > +#include <linux/memblock.h>
> > +
> > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > + int (*func)(struct resource *, void *))
> > +{
> > + phys_addr_t start, end;
> > + struct resource res;
> > + u64 i;
> > + int ret = 0;
> > +
> > + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > + return func(&crashk_res, kbuf);
> > +
> > + if (kbuf->top_down)
> > + for_each_mem_range_rev(i, &memblock.memory, &memblock.reserved,
> > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > + &start, &end, NULL) {
>
> for_each_free_mem_range_reverse() is a more readable version of this helper.
OK. I used to use my own limited list of reserved memory instead of
memblock.reserved here to exclude verbose ranges.
> > + if (!memblock_is_map_memory(start))
> > + continue;
>
> Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.
Sure, I confirmed it.
>
> > + res.start = start;
> > + res.end = end;
> > + ret = func(&res, kbuf);
> > + if (ret)
> > + break;
> > + }
> > + else
> > + for_each_mem_range(i, &memblock.memory, &memblock.reserved,
> > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > + &start, &end, NULL) {
>
> for_each_free_mem_range()?
OK.
> > + if (!memblock_is_map_memory(start))
> > + continue;
> > +
> > + res.start = start;
> > + res.end = end;
> > + ret = func(&res, kbuf);
> > + if (ret)
> > + break;
> > + }
> > +
> > + return ret;
> > +}
> >
>
> With these changes, what we have is almost:
> arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> (the difference being powerpc doesn't yet support crash-kernels here)
>
> If the argument is walking memblock gives a better answer than the stringy
> walk_system_ram_res() thing, is there any mileage in moving this code into
> kexec_file.c, and using it if !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)?
>
> This would save arm64/powerpc having near-identical implementations.
> 32bit arm keeps memblock if it has kexec, so it may be useful there too if
> kexec_file_load() support is added.
Thanks. I've forgot ppc.
-Takahiro AKASHI
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver
From: Tomasz Figa @ 2018-05-07 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503090909.o3dyhukzs2y7em5z@tarshish>
Hi Baruch,
On Thu, May 3, 2018 at 6:09 PM Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Jacob,
> On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote:
> > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int on)
> > +{
> > + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd);
> > + int ret;
> > +
> > + v4l2_dbg(1, rkisp1_debug, &isp_dev->v4l2_dev, "s_power: %d\n",
on);
> > +
> > + if (on) {
> > + ret = pm_runtime_get_sync(isp_dev->dev);
> > + if (ret < 0)
> > + return ret;
> > +
> > + rkisp1_config_clk(isp_dev);
> > + } else {
> > + ret = pm_runtime_put(isp_dev->dev);
> I commented this line out to make more than one STREAMON work. Otherwise,
the
> second STREAMON hangs. I guess the bug is not this driver. Probably
something
> in drivers/soc/rockchip/pm_domains.c. Just noting that in case you or
someone
> on Cc would like to investigate it further.
> I tested v4.16-rc4 on the Tinkerboard.
Looks like that version doesn't include the IOMMU PM and clock handling
rework [1], which should fix a lot of runtime PM issues. FWIW, linux-next
seems to already include it.
[1] https://lkml.org/lkml/2018/3/23/44
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v4 5/9] iio: adc: at91-sama5d2_adc: add support for position and pressure channels
From: Eugen Hristev @ 2018-05-07 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180506175914.GL10960@piout.net>
On 06.05.2018 20:59, Alexandre Belloni wrote:
> Hi,
>
> On 06/05/2018 18:29:53+0100, Jonathan Cameron wrote:
>> On Mon, 30 Apr 2018 13:32:11 +0300
>> Eugen Hristev <eugen.hristev@microchip.com> wrote:
>>
>>> This implements the support for position and pressure for the included
>>> touchscreen support in the SAMA5D2 SOC ADC block.
>>> Two position channels are added and one for pressure.
>>> They can be read in raw format, or through a buffer.
>>> A normal use case is for a consumer driver to register a callback buffer
>>> for these channels.
>>> When the touchscreen channels are in the active scan mask,
>>> the driver will start the touchscreen sampling and push the data to the
>>> buffer.
>>>
>>> Some parts of this patch are based on initial original work by
>>> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
>>>
>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>> Looks good to me now.
>>
>> I'm assuming that once Dmitry and others are happy, I'll take the
>> series through the IIO tree. Will reply to the cover letter if the
>> rest of the patches look good to me to let everyone know that without
>> having to catch this comment down in here!
>>
>
> I'm planning to take both DT patches through the at91 tree once you take
> the DT bindings patches.
Please take into consideration that those DT patches do not build
stand-alone, they depend on
[PATCH v4 7/9] dt-bindings: iio: adc: at91-sama5d2_adc: add channel
specific consumer info
(the DT patches add an include statement of a file which is created in
this patch).
Thanks !
Eugen
>
>
^ permalink raw reply
* [PATCH -next v2] gpio: owl: Fix return value check in owl_gpio_probe()
From: Manivannan Sadhasivam @ 2018-05-07 6:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525674356-39189-1-git-send-email-weiyongjun1@huawei.com>
On Mon, May 07, 2018 at 06:25:56AM +0000, Wei Yongjun wrote:
> In case of error, the function of_iomap() returns NULL pointer not
> ERR_PTR(). The IS_ERR() test in the return value check should be
> replaced with NULL test.
>
> Fixes: d3654d38809c ("gpio: Add gpio driver for Actions OWL S900 SoC")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Thanks,
Mani
> ---
> v1 -> v2: return -ENXIO instead of -ENOMEM
> ---
> drivers/gpio/gpio-owl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-owl.c b/drivers/gpio/gpio-owl.c
> index 3546362..f35e80f 100644
> --- a/drivers/gpio/gpio-owl.c
> +++ b/drivers/gpio/gpio-owl.c
> @@ -128,8 +128,8 @@ static int owl_gpio_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> gpio->base = of_iomap(dev->of_node, 0);
> - if (IS_ERR(gpio->base))
> - return PTR_ERR(gpio->base);
> + if (!gpio->base)
> + return -ENXIO;
>
> /*
> * Get the number of gpio's for this bank. If none specified,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH -next v2] gpio: owl: Fix return value check in owl_gpio_probe()
From: Wei Yongjun @ 2018-05-07 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525657224-88189-1-git-send-email-weiyongjun1@huawei.com>
In case of error, the function of_iomap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Fixes: d3654d38809c ("gpio: Add gpio driver for Actions OWL S900 SoC")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
v1 -> v2: return -ENXIO instead of -ENOMEM
---
drivers/gpio/gpio-owl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-owl.c b/drivers/gpio/gpio-owl.c
index 3546362..f35e80f 100644
--- a/drivers/gpio/gpio-owl.c
+++ b/drivers/gpio/gpio-owl.c
@@ -128,8 +128,8 @@ static int owl_gpio_probe(struct platform_device *pdev)
return -ENOMEM;
gpio->base = of_iomap(dev->of_node, 0);
- if (IS_ERR(gpio->base))
- return PTR_ERR(gpio->base);
+ if (!gpio->base)
+ return -ENXIO;
/*
* Get the number of gpio's for this bank. If none specified,
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier
From: Shawn Guo @ 2018-05-07 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525189650-5826-1-git-send-email-festevam@gmail.com>
On Tue, May 01, 2018 at 12:47:29PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Adopt the SPDX license identifier headers to ease license compliance
> management.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver
From: Baruch Siach @ 2018-05-07 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAFQd5CvBv4hkE=PSHBJTYa9Lj0SyggxpMBEAYD=if0=T0uzHw@mail.gmail.com>
Hi Tomasz,
On Mon, May 07, 2018 at 06:13:27AM +0000, Tomasz Figa wrote:
> On Thu, May 3, 2018 at 6:09 PM Baruch Siach <baruch@tkos.co.il> wrote:
> > On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote:
> > > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int on)
> > > +{
> > > + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd);
> > > + int ret;
> > > +
> > > + v4l2_dbg(1, rkisp1_debug, &isp_dev->v4l2_dev, "s_power: %d\n",
> on);
> > > +
> > > + if (on) {
> > > + ret = pm_runtime_get_sync(isp_dev->dev);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + rkisp1_config_clk(isp_dev);
> > > + } else {
> > > + ret = pm_runtime_put(isp_dev->dev);
>
> > I commented this line out to make more than one STREAMON work. Otherwise,
> > the second STREAMON hangs. I guess the bug is not this driver. Probably
> > something in drivers/soc/rockchip/pm_domains.c. Just noting that in case
> > you or someone on Cc would like to investigate it further.
> >
> > I tested v4.16-rc4 on the Tinkerboard.
>
> Looks like that version doesn't include the IOMMU PM and clock handling
> rework [1], which should fix a lot of runtime PM issues. FWIW, linux-next
> seems to already include it.
>
> [1] https://lkml.org/lkml/2018/3/23/44
Thanks for the reference.
It looks like the iommu driver part is in Linus' tree already. The DT part is
in the v4.18-armsoc/dts32 branch of Heiko's tree. Am I missing anything?
Anyway, I'll take a look.
Thanks again,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ 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