* [GIT PULL v2 5/5] i.MX defconfig updates for 4.16
From: Shawn Guo @ 2018-01-06 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-5-git-send-email-shawnguo@kernel.org>
Changes for v2:
Drop savedefconfig changes from patch 'ARM: imx_v6_v7_defconfig: enable
CONFIG_CPU_FREQ_STAT'.
The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.16
for you to fetch changes up to 495a68d74dfe25f8d441e3493ba447fb1ed209f1:
ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT (2018-01-06 10:45:51 +0800)
----------------------------------------------------------------
i.MX defconfig updates for 4.16:
- Enable CPU_FREQ_STAT for cpufreq transtion statistics support.
- Enable SRTC driver RTC_DRV_MXC_V2 for i.MX53.
- Turn on a few drivers useful for DART-MX6 SoM support, SERDEV
bluetooth, SERIAL_DEV_BUS, WL18XX, and DEFAULT_ON LED Trigger.
----------------------------------------------------------------
Dong Aisheng (1):
ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT
Neil Armstrong (1):
ARM: imx_v6_v7_defconfig: Add missing config for DART-MX6 SoM
Patrick Bruenn (1):
ARM: imx_v6_v7_defconfig: enable RTC_DRV_MXC_V2
arch/arm/configs/imx_v6_v7_defconfig | 8 ++++++++
1 file changed, 8 insertions(+)
^ permalink raw reply
* [PATCH v3] ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT
From: Shawn Guo @ 2018-01-06 3:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514004660-32630-1-git-send-email-aisheng.dong@nxp.com>
From: Dong Aisheng <aisheng.dong@nxp.com>
It is very useful for user to retrieve cpufreq transtion statistics
and worth to be default enabled.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
---
Changes for v3:
Drop savedefconfig changes which should be a separate patch.
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 3b784ed12cc2..4cb9829fccd1 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -55,6 +55,7 @@ CONFIG_FORCE_MAX_ZONEORDER=14
CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
CONFIG_KEXEC=y
CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul
From: Anson Huang @ 2018-01-06 3:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0it+Gc5nTa5Vt8X8_OPHh6ndcQB3peAQA1SDsuQ2+FZKA@mail.gmail.com>
Hi, Rafael
Best Regards!
Anson Huang
> -----Original Message-----
> From: rjwysocki at gmail.com [mailto:rjwysocki at gmail.com] On Behalf Of Rafael
> J. Wysocki
> Sent: 2018-01-05 8:21 PM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; Linux
> PM <linux-pm@vger.kernel.org>; Linux Kernel Mailing List <linux-
> kernel at vger.kernel.org>; Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> Russell King - ARM Linux <linux@armlinux.org.uk>; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Viresh Kumar <viresh.kumar@linaro.org>; Jacky Bai
> <ping.bai@nxp.com>; A.s. Dong <aisheng.dong@nxp.com>
> Subject: Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for
> i.mx6ul
>
> On Tue, Jan 2, 2018 at 6:07 PM, Anson Huang <Anson.Huang@nxp.com> wrote:
> > Add 696MHz operating point for i.MX6UL, only for those parts with
> > speed grading fuse set to 2b'10 supports 696MHz operating point, so,
> > speed grading check is also added for i.MX6UL in this patch, the clock
> > tree for each operating point are as below:
> >
> > 696MHz:
> > pll1 696000000
> > pll1_bypass 696000000
> > pll1_sys 696000000
> > pll1_sw 696000000
> > arm 696000000
> > 528MHz:
> > pll2 528000000
> > pll2_bypass 528000000
> > pll2_bus 528000000
> > ca7_secondary_sel 528000000
> > step 528000000
> > pll1_sw 528000000
> > arm 528000000
> > 396MHz:
> > pll2_pfd2_396m 396000000
> > ca7_secondary_sel 396000000
> > step 396000000
> > pll1_sw 396000000
> > arm 396000000
> > 198MHz:
> > pll2_pfd2_396m 396000000
> > ca7_secondary_sel 396000000
> > step 396000000
> > pll1_sw 396000000
> > arm 198000000
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>
> This doesn't apply for me and in a nontrivial way.
>
> What kernel is it against?
I did it based on linux-next, it should be on linux-next-pm branch, I redo
the patch set V2 based on linux-next-pm, also redo the test,
sorry for the inconvenience.
Anson.
>
> > ---
> > drivers/cpufreq/imx6q-cpufreq.c | 46
> > ++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 45 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/imx6q-cpufreq.c
> > b/drivers/cpufreq/imx6q-cpufreq.c index d9b2c2d..cbda0cc 100644
> > --- a/drivers/cpufreq/imx6q-cpufreq.c
> > +++ b/drivers/cpufreq/imx6q-cpufreq.c
> > @@ -120,6 +120,10 @@ static int imx6q_set_target(struct cpufreq_policy
> *policy, unsigned int index)
> > clk_set_parent(secondary_sel_clk, pll2_pfd2_396m_clk);
> > clk_set_parent(step_clk, secondary_sel_clk);
> > clk_set_parent(pll1_sw_clk, step_clk);
> > + if (freq_hz > clk_get_rate(pll2_bus_clk)) {
> > + clk_set_rate(pll1_sys_clk, new_freq * 1000);
> > + clk_set_parent(pll1_sw_clk, pll1_sys_clk);
> > + }
> > } else {
> > clk_set_parent(step_clk, pll2_pfd2_396m_clk);
> > clk_set_parent(pll1_sw_clk, step_clk); @@ -244,6
> > +248,43 @@ static void imx6q_opp_check_speed_grading(struct device *dev)
> > of_node_put(np);
> > }
> >
> > +#define OCOTP_CFG3_6UL_SPEED_696MHZ 0x2
> > +
> > +static void imx6ul_opp_check_speed_grading(struct device *dev) {
> > + struct device_node *np;
> > + void __iomem *base;
> > + u32 val;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
> > + if (!np)
> > + return;
> > +
> > + base = of_iomap(np, 0);
> > + if (!base) {
> > + dev_err(dev, "failed to map ocotp\n");
> > + goto put_node;
> > + }
> > +
> > + /*
> > + * Speed GRADING[1:0] defines the max speed of ARM:
> > + * 2b'00: Reserved;
> > + * 2b'01: 528000000Hz;
> > + * 2b'10: 696000000Hz;
> > + * 2b'11: Reserved;
> > + * We need to set the max speed of ARM according to fuse map.
> > + */
> > + val = readl_relaxed(base + OCOTP_CFG3);
> > + val >>= OCOTP_CFG3_SPEED_SHIFT;
> > + val &= 0x3;
> > + if (val != OCOTP_CFG3_6UL_SPEED_696MHZ)
> > + if (dev_pm_opp_disable(dev, 696000000))
> > + dev_warn(dev, "failed to disable 696MHz OPP\n");
> > + iounmap(base);
> > +put_node:
> > + of_node_put(np);
> > +}
> > +
> > static int imx6q_cpufreq_probe(struct platform_device *pdev) {
> > struct device_node *np;
> > @@ -311,7 +352,10 @@ static int imx6q_cpufreq_probe(struct
> platform_device *pdev)
> > goto put_reg;
> > }
> >
> > - imx6q_opp_check_speed_grading(cpu_dev);
> > + if (of_machine_is_compatible("fsl,imx6ul"))
> > + imx6ul_opp_check_speed_grading(cpu_dev);
> > + else
> > + imx6q_opp_check_speed_grading(cpu_dev);
> >
> > /* Because we have added the OPPs here, we must free them */
> > free_opp = true;
> > --
> > 1.9.1
> >
^ permalink raw reply
* [GIT PULL 5/5] i.MX defconfig updates for 4.16
From: Shawn Guo @ 2018-01-06 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2bWz5n+Scy_pvaHo0AJ5w0cuY1Fyiidc0Ygk0=7AF5-A@mail.gmail.com>
Hi Arnd,
On Fri, Jan 05, 2018 at 06:06:26PM +0100, Arnd Bergmann wrote:
> On Wed, Jan 3, 2018 at 6:57 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> > The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
> >
> > Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.16
> >
> > for you to fetch changes up to 189114b47b1cfcc5da02db9bcafebd2042aa7ab8:
> >
> > ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT (2017-12-26 17:04:13 +0800)
> >
> > ----------------------------------------------------------------
> > i.MX defconfig updates for 4.16:
> > - Enable CPU_FREQ_STAT for cpufreq transtion statistics support.
> > - Enable SRTC driver RTC_DRV_MXC_V2 for i.MX53.
> > - Turn on a few drivers useful for DART-MX6 SoM support, SERDEV
> > bluetooth, SERIAL_DEV_BUS, WL18XX, and DEFAULT_ON LED Trigger.
> >
> > ----------------------------------------------------------------
> > Dong Aisheng (1):
> > ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT
>
> This commit looks a bit fishy, as it does multiple things:
>
> - add multitouch support
CONFIG_HID_MULTITOUCH is not a new option, but just got moved around.
> - move options around in the file that did not change
> - drop some options (AEABI, CMA, SOC_CAMERA_OV2640,
> SERIAL_DEV_CTRL_TTYPORT) for unknown reasons.
All these changes came from savedefconfig.
> Cleaning up is fine, but please don't mix that with functional changes.
> It's also fine to add multiple options at once in one patch, but when
> you use 'make savedefconfig', please check each option that
> gets dropped, some options might have gained new dependencies
> or got renamed but are still needed here.
Agreed. The savedefconfig change should really be a separate patch.
> Finally, it might be good to check if the newly added options should
> also be added to multi_v7_defconfig.
>
> Not pulled for now, I'd suggest you resend without the 'savedefconfig'
> cleanup, we can do that in a follow-up.
Sorry for giving you a hard time on this. I will rework it by adding
CONFIG_CPU_FREQ_STAT option only in that patch.
Shawn
^ permalink raw reply
* [PATCH v4 6/7] ARM: davinci: convert to common clock framework
From: David Lechner @ 2018-01-06 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8fcd9bf8-249b-7e0b-0e37-70f011ab1b7e@ti.com>
On 01/05/2018 04:42 AM, Sekhar Nori wrote:
> On Friday 05 January 2018 08:29 AM, David Lechner wrote:
>> On 01/04/2018 11:50 AM, David Lechner wrote:
>>> On 1/4/18 6:39 AM, Sekhar Nori wrote:
>
>>>> This is a pretty huge patch again and I hope it can be broken down.
>>>> Ideally one per SoC converted and then the unused code removal.
>>>>
>>>
>>> Will do.
>>
>> Well, I can do this, but I don't think it will compile or run. We can't
>> have the common clock framework and the legacy davinci clocks enabled at
>> the same time.
>
> I see. Can you at least hive off the code removal into a separate patch
> for next submission. I will then take a closer look at this.
>
I've realized that I can accomplish this if I use some #if 0/#endif blocks
temporarily if that sounds OK.
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxl: add internal ethernet PHY irq
From: Kevin Hilman @ 2018-01-06 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218102713.4506-1-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> Add the interrupt of the internal ethernet PHY
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Hi Kevin,
>
> This changes depends on the net-next changes adding interrupt support [0].
> It is really important that this change is not merged before its
> dependency.
>
> If it is merged before, instead of polling, the phy would wait for an
> interrupt which has not been configured and will never fire.
Thanks for the warning. I'll wait and merge these after -rc1 to be sure
of all dependencies.
Kevin
^ permalink raw reply
* [PATCH 3/3] arm64: tegra: remove tegra132 norrin's nonstandard 'backlight-boot-off'
From: Brian Norris @ 2018-01-06 0:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106004757.8239-1-briannorris@chromium.org>
This was used out-of-tree as a hack for resolving issues where some
systems expect the backlight to turn on automatically at boot, while
others expect to manage the backlight status via a DRM/panel driver.
Those issues have since been fixed upstream in pwm_bl.c without device
tree hacks, and so this un-documented property should no longer be
useful.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
arch/arm64/boot/dts/nvidia/tegra132-norrin.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts b/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
index a0385a386a3f..ba2e1b7c198e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
@@ -951,8 +951,6 @@
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
-
- backlight-boot-off;
};
clocks {
--
2.16.0.rc0.223.g4a4ac83678-goog
^ permalink raw reply related
* [PATCH 2/3] ARM: tegra: paz00: drop nonstandard 'backlight-boot-off'
From: Brian Norris @ 2018-01-06 0:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106004757.8239-1-briannorris@chromium.org>
This was used out-of-tree as a hack for resolving issues where some
systems expect the backlight to turn on automatically at boot, while
others expect to manage the backlight status via a DRM/panel driver.
Those issues have since been fixed upstream in pwm_bl.c without device
tree hacks, and so this un-documented property should no longer be
useful.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
arch/arm/boot/dts/tegra20-paz00.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 30436969adc0..12c63b23ed5e 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -504,8 +504,6 @@
brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 255>;
default-brightness-level = <10>;
-
- backlight-boot-off;
};
clocks {
--
2.16.0.rc0.223.g4a4ac83678-goog
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: rockchip: drop veyron's nonstandard 'backlight-boot-off'
From: Brian Norris @ 2018-01-06 0:47 UTC (permalink / raw)
To: linux-arm-kernel
This was used out-of-tree as a hack for resolving issues where some
systems expect the backlight to turn on automatically at boot, while
others expect to manage the backlight status via a DRM/panel driver.
Those issues have since been fixed upstream in pwm_bl.c without device
tree hacks, and so this un-documented property should no longer be
useful.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index d752a315f884..be487111d025 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -92,7 +92,6 @@
248 249 250 251 252 253 254 255>;
default-brightness-level = <128>;
enable-gpios = <&gpio7 RK_PA2 GPIO_ACTIVE_HIGH>;
- backlight-boot-off;
pinctrl-names = "default";
pinctrl-0 = <&bl_en>;
pwms = <&pwm0 0 1000000 0>;
--
2.16.0.rc0.223.g4a4ac83678-goog
^ permalink raw reply related
* [GIT PULL] Amlogic 64-bit DT changes for v4.16, round 3
From: Kevin Hilman @ 2018-01-06 0:26 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
A final round of 64-bit DT changes for Amlogic SoCs.
These were just waiting for the clock dependencies to land in the clock
tree which they now have. I've merged the same tag into this branch to
avoid any dependency issues.
Thanks,
Kevin
The following changes since commit 43b9f617b5f98f2f7abb508fef5e535e5fb66a41:
arm64: dts: meson-axg: add new reset DT node (2017-12-15 16:20:29 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-3
for you to fetch changes up to f6f6ac914b82402b910b783cd13bf72de067f69f:
ARM64: dts: meson-axg: enable ethernet for A113D S400 board (2018-01-05 15:27:31 -0800)
----------------------------------------------------------------
Another round of 64-bit DT changes for the new Amlogic SoCs. These
include IR, SPI and ethernet MAC support for the new AXG family SoCs.
----------------------------------------------------------------
Kevin Hilman (1):
Merge tag 'meson-clk-headers-for-v4.16-2' of git://github.com/BayLibre/clk-meson into v4.16/dt64
Qiufang Dai (1):
clk: meson-axg: add clocks dt-bindings required header
Sunny Luo (1):
ARM64: dts: meson-axg: add the SPICC controller
Yixun Lan (5):
dt-bindings: clock: add compatible variant for the Meson-AXG
arm64: dts: meson-axg: switch uart_ao clock to CLK81
ARM64: dts: meson-axg: enable IR controller
ARM64: dts: meson-axg: add ethernet mac controller
ARM64: dts: meson-axg: enable ethernet for A113D S400 board
Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt | 7 +++--
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 13 ++++++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
include/dt-bindings/clock/axg-clkc.h | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 251 insertions(+), 4 deletions(-)
create mode 100644 include/dt-bindings/clock/axg-clkc.h
^ permalink raw reply
* [PATCH v2 5/5] ARM64: dts: meson-axg: enable the UART_A controller
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
The UART_A is connected to a BT module on the S400 board.
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 9c1b78028ccb..d56894dbb209 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -14,6 +14,7 @@
aliases {
serial0 = &uart_AO;
+ serial1 = &uart_A;
};
};
@@ -24,6 +25,12 @@
pinctrl-names = "default";
};
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>;
+ pinctrl-names = "default";
+};
+
&uart_AO {
status = "okay";
pinctrl-0 = <&uart_ao_a_pins>;
--
2.15.1
^ permalink raw reply related
* [PATCH v2 4/5] ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
Explictly request the pinctrl info for the UART_AO_A controller,
otherwise we may need to rely on bootloader for the initialization.
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 447b98d30921..9c1b78028ccb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -26,6 +26,8 @@
&uart_AO {
status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
};
&ir {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
Describe the pinctrl info for the UART controller which is found
in the Meson-AXG SoCs.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 97 ++++++++++++++++++++++++++++++
1 file changed, 97 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 644d0f9eaf8c..1eb45781c850 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -448,6 +448,70 @@
function = "spi1";
};
};
+
+ uart_a_pins: uart_a {
+ mux {
+ groups = "uart_tx_a",
+ "uart_rx_a";
+ function = "uart_a";
+ };
+ };
+
+ uart_a_cts_rts_pins: uart_a_cts_rts {
+ mux {
+ groups = "uart_cts_a",
+ "uart_rts_a";
+ function = "uart_a";
+ };
+ };
+
+ uart_b_x_pins: uart_b_x {
+ mux {
+ groups = "uart_tx_b_x",
+ "uart_rx_b_x";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_x_cts_rts_pins: uart_b_x_cts_rts {
+ mux {
+ groups = "uart_cts_b_x",
+ "uart_rts_b_x";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_z_pins: uart_b_z {
+ mux {
+ groups = "uart_tx_b_z",
+ "uart_rx_b_z";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_z_cts_rts_pins: uart_b_z_cts_rts {
+ mux {
+ groups = "uart_cts_b_z",
+ "uart_rts_b_z";
+ function = "uart_b";
+ };
+ };
+
+ uart_ao_b_z_pins: uart_ao_b_z {
+ mux {
+ groups = "uart_ao_tx_b_z",
+ "uart_ao_rx_b_z";
+ function = "uart_ao_b_gpioz";
+ };
+ };
+
+ uart_ao_b_z_cts_rts_pins: uart_ao_b_z_cts_rts {
+ mux {
+ groups = "uart_ao_cts_b_z",
+ "uart_ao_rts_b_z";
+ function = "uart_ao_b_gpioz";
+ };
+ };
};
};
@@ -492,12 +556,45 @@
gpio-ranges = <&pinctrl_aobus 0 0 15>;
};
+
remote_input_ao_pins: remote_input_ao {
mux {
groups = "remote_input_ao";
function = "remote_input_ao";
};
};
+
+ uart_ao_a_pins: uart_ao_a {
+ mux {
+ groups = "uart_ao_tx_a",
+ "uart_ao_rx_a";
+ function = "uart_ao_a";
+ };
+ };
+
+ uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
+ mux {
+ groups = "uart_ao_cts_a",
+ "uart_ao_rts_a";
+ function = "uart_ao_a";
+ };
+ };
+
+ uart_ao_b_pins: uart_ao_b {
+ mux {
+ groups = "uart_ao_tx_b",
+ "uart_ao_rx_b";
+ function = "uart_ao_b";
+ };
+ };
+
+ uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
+ mux {
+ groups = "uart_ao_cts_b",
+ "uart_ao_rts_b";
+ function = "uart_ao_b";
+ };
+ };
};
pwm_AO_ab: pwm at 7000 {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/5] ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
When update the clock info for the UART controller in the EE domain,
the driver explicitly require 'pclk' in order to work properly.
With current logic of the code, the driver will go for the legacy clock probe
routine[1] if it find current compatible string match to 'amlogic,meson-uart',
which result in not requesting the 'pclk' clock, thus break the driver in the end.
[1] drivers/tty/serial/meson_uart.c:685
/* Use legacy way until all platforms switch to new bindings */
if (of_device_is_compatible(pdev->dev.of_node, "amlogic,meson-uart"))
ret = meson_uart_probe_clocks_legacy(pdev, port);
else
ret = meson_uart_probe_clocks(pdev, port);
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 70c776ef7aa7..644d0f9eaf8c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -164,17 +164,21 @@
};
uart_A: serial at 24000 {
- compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
+ compatible = "amlogic,meson-gx-uart";
reg = <0x0 0x24000 0x0 0x18>;
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
+ clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
};
uart_B: serial at 23000 {
- compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
+ compatible = "amlogic,meson-gx-uart";
reg = <0x0 0x23000 0x0 0x18>;
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
+ clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 1/5] ARM64: dts: meson: uart: fix address space range
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-1-yixun.lan@amlogic.com>
The address space range is actually 0x18, fixed here.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +++++-----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index a80632641b39..70c776ef7aa7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -165,14 +165,14 @@
uart_A: serial at 24000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
- reg = <0x0 0x24000 0x0 0x14>;
+ reg = <0x0 0x24000 0x0 0x18>;
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
uart_B: serial at 23000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
- reg = <0x0 0x23000 0x0 0x14>;
+ reg = <0x0 0x23000 0x0 0x18>;
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 6cb3c2a52baf..4ee2e7951482 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -235,14 +235,14 @@
uart_A: serial at 84c0 {
compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x84c0 0x0 0x14>;
+ reg = <0x0 0x84c0 0x0 0x18>;
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
uart_B: serial at 84dc {
compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x84dc 0x0 0x14>;
+ reg = <0x0 0x84dc 0x0 0x18>;
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
@@ -287,7 +287,7 @@
uart_C: serial at 8700 {
compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x8700 0x0 0x14>;
+ reg = <0x0 0x8700 0x0 0x18>;
interrupts = <GIC_SPI 93 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
@@ -404,14 +404,14 @@
uart_AO: serial at 4c0 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
- reg = <0x0 0x004c0 0x0 0x14>;
+ reg = <0x0 0x004c0 0x0 0x18>;
interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
uart_AO_B: serial at 4e0 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
- reg = <0x0 0x004e0 0x0 0x14>;
+ reg = <0x0 0x004e0 0x0 0x18>;
interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 0/5] ARM64: dts: meson-axg: UART DT updates
From: Yixun Lan @ 2018-01-06 0:10 UTC (permalink / raw)
To: linux-arm-kernel
HI Kevin
These are the UART DT updates for the Meson-AXG platform.
The patch 1 is a general fix.
Other patches are about adding clock & pinctrl info, then using them.
Last patch enable UART_A which connect to a BT module on the S400 board.
Note:
This series depend on previous UART_AO clock switch patch[1]
also, these patch request clocks, so they need the
tag:meson-clk-for-v4.16-2 from clk-meson's tree in order to compile.
Changes since v1 at [2]:
-- fix address range for all platform
-- squash patch 1, 3 (drop compatible & add clock)
-- fix typo in pinctrl info
-- add Jerome's Ack
[1]
http://lkml.kernel.org/r/20171215141741.175985-1-yixun.lan at amlogic.com
[2]
http://lkml.kernel.org/r/20180105095621.196472-1-yixun.lan at amlogic.com
Yixun Lan (5):
ARM64: dts: meson: uart: fix address space range
ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
ARM64: dts: meson-axg: uart: Add the pinctrl info description
ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A
ARM64: dts: meson-axg: enable the UART_A controller
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 9 ++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 109 ++++++++++++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +--
3 files changed, 119 insertions(+), 9 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Kevin Hilman @ 2018-01-05 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216035527.96952-2-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> Add DT info for the stmmac ethernet MAC which found in
> the Amlogic's Meson-AXG SoC, also describe the ethernet
> pinctrl & clock information here.
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Applied to v4.16/dt64,
Kevin
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller
From: Kevin Hilman @ 2018-01-05 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215144217.223593-1-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> From: Sunny Luo <sunny.luo@amlogic.com>
>
> Add DT info for the SPICC controller which found in
> the Amlogic's Meson-AXG SoC.
>
> Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Applied with Neil's tag.
Kevin
^ permalink raw reply
* [PATCH v8] arm64: dts: meson-axg: switch uart_ao clock to CLK81
From: Kevin Hilman @ 2018-01-05 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141741.175985-1-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> Switch the uart_ao pclk to CLK81 since the clock driver is ready.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Applied to v4.16/dt64 with Neil's tag.
Kevin
^ permalink raw reply
* [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero
From: Kani, Toshi @ 2018-01-05 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514460261-65222-1-git-send-email-guohanjun@huawei.com>
On Thu, 2017-12-28 at 19:24 +0800, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> When we using iounmap() to free the 4K mapping, it just clear the PTEs
> but leave P4D/PUD/PMD unchanged, also will not free the memory of page
> tables.
>
> This will cause issues on ARM64 platform (not sure if other archs have
> the same issue) for this case:
>
> 1. ioremap a 4K size, valid page table will build,
> 2. iounmap it, pte0 will set to 0;
> 3. ioremap the same address with 2M size, pgd/pmd is unchanged,
> then set the a new value for pmd;
> 4. pte0 is leaked;
> 5. CPU may meet exception because the old pmd is still in TLB,
> which will lead to kernel panic.
>
> Fix it by skip setting up the huge I/O mappings when p4d/pud/pmd is
> zero.
Hi Hanjun,
I tested the above steps on my x86 box, but was not able to reproduce
your kernel panic. On x86, a 4K vaddr gets allocated from a small
fragmented free range, whereas a 2MB vaddr is from a larger free range.
Their addrs have different alignments (4KB & 2MB) as well. So, the
steps did not lead to use a same pmd entry.
However, I agree that zero'd pte entries will be leaked when a pmd map
is set if they are present under the pmd.
I also tested your patch on my x86 box. Unfortunately, it effectively
disabled 2MB mappings. While a 2MB vaddr gets allocated from a larger
free range, it sill comes from a free range covered by zero'd pte
entries. So, it ends up with 4KB mappings with your changes.
I think we need to come up with other approach.
Thanks,
-Toshi
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox
From: Jiaying Liang @ 2018-01-05 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105153146.lgxlhfsql5tq2kn5@rob-hp-laptop>
> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: Friday, January 05, 2018 7:32 AM
> To: Jiaying Liang <jliang@xilinx.com>
> Cc: jassisinghbrar at gmail.com; michal.simek at xilinx.com;
> mark.rutland at arm.com; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; Jiaying Liang
> <jliang@xilinx.com>
> Subject: Re: [PATCH v3 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox
>
> On Thu, Jan 04, 2018 at 03:51:31PM -0800, Wendy Liang wrote:
> > Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block in
> > ZynqMP SoC used for the communication between various processor
> > systems.
> >
> > Signed-off-by: Wendy Liang <jliang@xilinx.com>
> > ---
> > .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 104
> +++++++++++++++++++++
> > 1 file changed, 104 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
>
> Please add acks and reviewed-by's when posting new versions.
[Wendy] Thanks, will add this in the next version.
^ permalink raw reply
* [PATCH] ASoC: rockchip: i2s: Support mono capture
From: Matthias Kaehlcke @ 2018-01-05 22:12 UTC (permalink / raw)
To: linux-arm-kernel
The Rockchip I2S controller only allows to configure even numbers of
capture channels. It is still possible to capture monophonic audio by
using dual-channel mode and ignoring the 'data' from the second
channel.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
sound/soc/rockchip/rockchip_i2s.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index 908211e1d6fc..cc22ab3d10dd 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -328,6 +328,7 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream *substream,
val |= I2S_CHN_4;
break;
case 2:
+ case 1:
val |= I2S_CHN_2;
break;
default:
@@ -460,7 +461,7 @@ static struct snd_soc_dai_driver rockchip_i2s_dai = {
},
.capture = {
.stream_name = "Capture",
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_192000,
.formats = (SNDRV_PCM_FMTBIT_S8 |
@@ -654,7 +655,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
}
if (!of_property_read_u32(node, "rockchip,capture-channels", &val)) {
- if (val >= 2 && val <= 8)
+ if (val >= 1 && val <= 8)
soc_dai->capture.channels_max = val;
}
--
2.16.0.rc0.223.g4a4ac83678-goog
^ permalink raw reply related
* [PATCH v5 3/9] ACPI: Enable PPTT support on ARM64
From: Rafael J. Wysocki @ 2018-01-05 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f0f8c79a-2ff2-abe9-4a16-79485f0a1e2c@arm.com>
On Fri, Jan 5, 2018 at 10:58 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Hi,
>
>
> On 12/13/2017 11:26 AM, Lorenzo Pieralisi wrote:
>>
>> On Fri, Dec 01, 2017 at 04:23:24PM -0600, Jeremy Linton wrote:
>>>
>>> Now that we have a PPTT parser, in preparation for its use
>>> on arm64, lets build it.
>>>
>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>> ---
>>> arch/arm64/Kconfig | 1 +
>>> drivers/acpi/Kconfig | 3 +++
>>> drivers/acpi/Makefile | 1 +
>>> 3 files changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index a93339f5178f..e62fd1e08c1f 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -7,6 +7,7 @@ config ARM64
>>> select ACPI_REDUCED_HARDWARE_ONLY if ACPI
>>> select ACPI_MCFG if ACPI
>>> select ACPI_SPCR_TABLE if ACPI
>>> + select ACPI_PPTT if ACPI
>>> select ARCH_CLOCKSOURCE_DATA
>>> select ARCH_HAS_DEBUG_VIRTUAL
>>> select ARCH_HAS_DEVMEM_IS_ALLOWED
>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>> index 46505396869e..df7aebf0af0e 100644
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -545,6 +545,9 @@ config ACPI_CONFIGFS
>>> if ARM64
>>> source "drivers/acpi/arm64/Kconfig"
>>> +
>>> +config ACPI_PPTT
>>> + bool
>>
>>
>> We need to make a choice here. Either PPTT is considered ARM64 only and
>> we move code and config to drivers/acpi/arm64/Kconfig or we leave it in
>> drivers/acpi/pptt.c and we add a Kconfig entry in drivers/acpi/Kconfig
>> (and we make pptt.c compile on !ARM64 - which is what it should be given
>> that there is nothing ARM64 specific in it).
>
>
> No one else has expressed and opinion about this here..
>
> So i'm not sure what to think.
>
> OTOH a lot of people didn't like it when I had it in the arm64 directory,
> which was my original opinion. It seems other people thought that at some
> point in the future other ACPI platforms would want to use it so putting it
> in the arm64 directory was a mistake.
In my view it may go directly into drivers/acpi/ for the time being.
That said, going forward it may be useful to add a special
subdirectory under drivers/acpi/ for these "table drivers" as we seem
to be acquiring them at alarming rate.
> So, I'm leaning towards leaving it like it is, under the assumption that
> when someone puts in the effort to verify it on another ACPI platform they
> can move the config option up 6 lines. In the meantime I don't think it
> should be enabled on platforms where it hasn't been tested or is basically
> blocked (cpu_cacheinfo->cpu_map_populated) from executing or there isn't
> currently any benefit.
Agreed.
Thanks,
Rafael
^ permalink raw reply
* [PATCH v5 3/9] ACPI: Enable PPTT support on ARM64
From: Jeremy Linton @ 2018-01-05 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213172647.GA3316@red-moon>
Hi,
On 12/13/2017 11:26 AM, Lorenzo Pieralisi wrote:
> On Fri, Dec 01, 2017 at 04:23:24PM -0600, Jeremy Linton wrote:
>> Now that we have a PPTT parser, in preparation for its use
>> on arm64, lets build it.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> arch/arm64/Kconfig | 1 +
>> drivers/acpi/Kconfig | 3 +++
>> drivers/acpi/Makefile | 1 +
>> 3 files changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index a93339f5178f..e62fd1e08c1f 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -7,6 +7,7 @@ config ARM64
>> select ACPI_REDUCED_HARDWARE_ONLY if ACPI
>> select ACPI_MCFG if ACPI
>> select ACPI_SPCR_TABLE if ACPI
>> + select ACPI_PPTT if ACPI
>> select ARCH_CLOCKSOURCE_DATA
>> select ARCH_HAS_DEBUG_VIRTUAL
>> select ARCH_HAS_DEVMEM_IS_ALLOWED
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 46505396869e..df7aebf0af0e 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -545,6 +545,9 @@ config ACPI_CONFIGFS
>>
>> if ARM64
>> source "drivers/acpi/arm64/Kconfig"
>> +
>> +config ACPI_PPTT
>> + bool
>
> We need to make a choice here. Either PPTT is considered ARM64 only and
> we move code and config to drivers/acpi/arm64/Kconfig or we leave it in
> drivers/acpi/pptt.c and we add a Kconfig entry in drivers/acpi/Kconfig
> (and we make pptt.c compile on !ARM64 - which is what it should be given
> that there is nothing ARM64 specific in it).
No one else has expressed and opinion about this here..
So i'm not sure what to think.
OTOH a lot of people didn't like it when I had it in the arm64
directory, which was my original opinion. It seems other people thought
that at some point in the future other ACPI platforms would want to use
it so putting it in the arm64 directory was a mistake.
So, I'm leaning towards leaving it like it is, under the assumption that
when someone puts in the effort to verify it on another ACPI platform
they can move the config option up 6 lines. In the meantime I don't
think it should be enabled on platforms where it hasn't been tested or
is basically blocked (cpu_cacheinfo->cpu_map_populated) from executing
or there isn't currently any benefit.
Hence I'm planning on leaving it as is until I get further clarity.
>
> Lorenzo
>
>> endif
>>
>> config TPS68470_PMIC_OPREGION
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 41954a601989..b6056b566df4 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -87,6 +87,7 @@ obj-$(CONFIG_ACPI_BGRT) += bgrt.o
>> obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
>> obj-$(CONFIG_ACPI_SPCR_TABLE) += spcr.o
>> obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
>> +obj-$(CONFIG_ACPI_PPTT) += pptt.o
>>
>> # processor has its own "processor." module_param namespace
>> processor-y := processor_driver.o
>> --
>> 2.13.5
>>
^ permalink raw reply
* [PATCH] mtd/nand/sunxi: Delete an error message for a failed memory allocation in sunxi_nand_chip_init()
From: SF Markus Elfring @ 2018-01-05 21:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 5 Jan 2018 22:27:09 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/mtd/nand/sunxi_nand.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 82244be3e766..ebfa130a9285 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -2019,10 +2019,8 @@ static int sunxi_nand_chip_init(struct device *dev, struct sunxi_nfc *nfc,
sizeof(*chip) +
(nsels * sizeof(struct sunxi_nand_chip_sel)),
GFP_KERNEL);
- if (!chip) {
- dev_err(dev, "could not allocate chip\n");
+ if (!chip)
return -ENOMEM;
- }
chip->nsels = nsels;
chip->selected = -1;
--
2.15.1
^ 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