* [PATCH] dt: psci: Update DT bindings to support hierarchical PSCI states
From: Ulf Hansson @ 2017-12-28 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226221311.4vx7f3kmcvt5t6gt@rob-hp-laptop>
On 26 December 2017 at 23:13, Rob Herring <robh@kernel.org> wrote:
> On Fri, Dec 22, 2017 at 03:32:07PM +0100, Ulf Hansson wrote:
>> From: Lina Iyer <lina.iyer@linaro.org>
>>
>> Update DT bindings to represent hierarchical CPU and CPU domain idle states
>> for PSCI. Also update the PSCI examples to clearly show how flattened and
>> hierarchical idle states can be represented in DT.
>>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>>
>> For your information, I have picked up the work from Lina Iyer around the so
>> called CPU cluster idling series [1,2] and I working on new versions. However,
>> I decided to post the updates to the PSCI DT bindings first, as they will be
>> needed to be agreed upon before further changes can be done to the PSCI firmware
>> driver.
>>
>> Note, these bindings have been discussed over and over again, at LKML, but
>> especially also at various Linux conferences, like LPC and Linaro Connect. We
>> finally came to a conclusion and the changes we agreed upon, should be reflected
>> in this update.
>>
>> Of course, it's a while ago since the latest discussions, but hopefully people
>> don't have too hard time to remember.
>
> Vaguely...
>
>>
>> Kind regards
>> Uffe
>>
>> [1]
>> https://www.spinics.net/lists/arm-kernel/msg566200.html
>>
>> [2]
>> https://lwn.net/Articles/716300/
>>
>> ---
>> Documentation/devicetree/bindings/arm/psci.txt | 152 +++++++++++++++++++++++++
>> 1 file changed, 152 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
>> index a2c4f1d..5a8f11b 100644
>> --- a/Documentation/devicetree/bindings/arm/psci.txt
>> +++ b/Documentation/devicetree/bindings/arm/psci.txt
>> @@ -105,7 +105,159 @@ Case 3: PSCI v0.2 and PSCI v0.1.
>> ...
>> };
>>
>> +PSCI v1.0 onwards, supports OS-Initiated mode for powering off CPUs and CPU
>> +clusters from the firmware. For such topologies the PSCI firmware driver acts
>> +as pseudo-controller, which may be specified in the psci DT node. The
>> +definitions of the CPU and the CPU cluster topology, must conform to the domain
>> +idle state specification [3]. The domain idle states themselves, must be
>> +compatible with the defined 'domain-idle-state' binding [1], and also need to
>> +specify the arm,psci-suspend-param property for each idle state.
>> +
>> +DT allows representing CPU and CPU cluster idle states in two different ways -
>> +
>> +The flattened model as given in Example 1, lists CPU's idle states followed by
>> +the domain idle state that the CPUs may choose. This is the general practice
>> +followed in PSCI firmwares that support Platform Coordinated mode. Note that
>> +the idle states are all compatible with "arm,idle-state".
>> +
>> +Example 2 represents the hierarchical model of CPU and domain idle states.
>> +CPUs define their domain provider in their DT node. The domain controls the
>> +power to the CPU and possibly other h/w blocks that would be powered off when
>> +the CPU is powered off. The CPU's idle states may therefore be considered as
>> +the domain's idle states and have the compatible "arm,idle-state". Such domains
>> +may be embedded within another domain that represents common h/w blocks between
>> +these CPUs viz. the cluster. The idle states of the cluster would be
>> +represented as the domain's idle states. In order to use OS-Initiated mode of
>> +PSCI in the firmware, the hierarchical representation must be used.
>> +
>> +Example 1: Flattened representation of CPU and domain idle states
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + CPU0: cpu at 0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53", "arm,armv8";
>> + reg = <0x0>;
>> + enable-method = "psci";
>> + cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
>> + <&CLUSTER_PWR_DWN>;
>> + };
>> +
>> + CPU1: cpu at 1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a57", "arm,armv8";
>> + reg = <0x100>;
>> + enable-method = "psci";
>> + cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
>> + <&CLUSTER_PWR_DWN>;
>> + };
>> +
>> + idle-states {
>> + CPU_PWRDN: cpu_power_down{
>
> Use '-' rather than '_'. dtc has more warnings since last time...
Yes, I found this on a couple of more places and fixed them all.
>
>> + compatible = "arm,idle-state";
>> + arm,psci-suspend-param = <0x000001>;
>> + entry-latency-us = <10>;
>> + exit-latency-us = <10>;
>> + min-residency-us = <100>;
>> + };
>> +
>> + CLUSTER_RET: domain_ret {
>> + compatible = "arm,idle-state";
>> + arm,psci-suspend-param = <0x1000010>;
>> + entry-latency-us = <500>;
>> + exit-latency-us = <500>;
>> + min-residency-us = <2000>;
>> + };
>> +
>> + CLUSTER_PWR_DWN: domain_off {
>> + compatible = "arm,idle-state";
>> + arm,psci-suspend-param = <0x1000030>;
>> + entry-latency-us = <2000>;
>> + exit-latency-us = <2000>;
>> + min-residency-us = <6000>;
>> + };
>> + };
>> +
>> + psci {
>> + compatible = "arm,psci-0.2";
>> + method = "smc";
>> + };
>> +
>> +Example 2: Hierarchical representation of CPU and domain idle states
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + CPU0: cpu at 0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53", "arm,armv8";
>> + reg = <0x0>;
>> + enable-method = "psci";
>> + power-domains = <&CPU_PD0>;
>> + };
>> +
>> + CPU1: cpu at 1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a57", "arm,armv8";
>> + reg = <0x100>;
>> + enable-method = "psci";
>> + power-domains = <&CPU_PD1>;
>> + };
>> +
>> + idle-states {
>> + CPU_PWRDN: cpu_power_down{
>> + compatible = "arm,idle-state";
>> + arm,psci-suspend-param = <0x000001>;
>> + entry-latency-us = <10>;
>> + exit-latency-us = <10>;
>> + min-residency-us = <100>;
>> + };
>> +
>> + CLUSTER_RET: domain_ret {
>> + compatible = "domain-idle-state";
>> + arm,psci-suspend-param = <0x1000010>;
>> + entry-latency-us = <500>;
>> + exit-latency-us = <500>;
>> + min-residency-us = <2000>;
>> + };
>> +
>> + CLUSTER_PWR_DWN: domain_off {
>> + compatible = "domain-idle-state";
>> + arm,psci-suspend-param = <0x1000030>;
>> + entry-latency-us = <2000>;
>> + exit-latency-us = <2000>;
>> + min-residency-us = <6000>;
>> + };
>> + };
>> + };
>> +
>> + psci {
>> + compatible = "arm,psci-1.0";
>> + method = "smc";
>> +
>> + CPU_PD0: cpu-pd at 0 {
>
> A unit address without reg property is now a warning.
There is currently no need for reg property, so let me replace this with:
CPU_PD0: cpu-pd0
>
>> + #power-domain-cells = <0>;
>> + domain-idle-states = <&CPU_PWRDN>;
>> + power-domains = <&CLUSTER_PD>;
>> + };
>> +
>> + CPU_PD1: cpu-pd at 1 {
>> + #power-domain-cells = <0>;
>> + domain-idle-states = <&CPU_PWRDN>;
>> + power-domains = <&CLUSTER_PD>;
>
> Could this node be a child of CLUSTER_PD rather than having a phandle?
> Doesn't matter so much here, but when you have 3 levels?
This follows existing bindings for power-domains as per
Documentation/devicetree/bindings/power/power_domain.txt. I guess it's
better to stick to that!?
>
>> + };
>
> These 2 nodes are identical, so why do you need both?
Each node represents a power domain, which contains devices (in this
case CPUs) that are specific to each power domain.
In other words, we are trying to describe the HW using a hierarchical layout.
>
>> +
>> + CLUSTER_PD: cluster-pd at 0 {
>> + #power-domain-cells = <0>;
>> + domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
>> + };
>> + };
>> +
>> [1] Kernel documentation - ARM idle states bindings
>> Documentation/devicetree/bindings/arm/idle-states.txt
>> [2] Power State Coordination Interface (PSCI) specification
>> http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
>> +[3]. PM Domains description
>> + Documentation/devicetree/bindings/power/power_domain.txt
>> --
>> 2.7.4
>>
Kind regards
Uffe
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: Fix power for USB Ethernet controller
From: Hauke Mehrtens @ 2017-12-28 12:52 UTC (permalink / raw)
To: linux-arm-kernel
The RTL8152B USB controller needs a 3.3 volt power supply which is
controlled by PAD20. Without this patch Linux will not see that there is
a device connected to the USB bus and the 2. USB port will not work.
I do not of a better solution to add a regulator to a USB device.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
index 32a6d312422e..1d5db0e0bd12 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
@@ -47,13 +47,15 @@
model = "Xunlong Orange Pi R1";
compatible = "xunlong,orangepi-r1", "allwinner,sun8i-h2-plus";
- /delete-node/ reg_vcc_wifi;
-
aliases {
ethernet1 = &rtl8189etv;
};
};
+®_vcc_wifi {
+ regulator-always-on;
+};
+
&ohci1 {
/*
* RTL8152B USB-Ethernet adapter is connected to USB1,
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: dts: sun8i: add support for Orange Pi R1
From: Hauke Mehrtens @ 2017-12-28 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171112124129.15844-1-icenowy@aosc.io>
Hi,
I tried this device tree file with my Orange Pi R1 and then the Ethernet
chip connected to the USB controller is not working. When I set PAD 20
to high the device is found on the USB bus.
On 11/12/2017 01:41 PM, Icenowy Zheng wrote:
> Orange Pi R1 is a board design based on Orange Pi Zero, with XR819 Wi-Fi
> chip replaced by RTL8189ETV Wi-Fi module and the USB Type-A jack
> replaced by an onboard USB RTL8152B USB-Ethernet adapter.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 73 +++++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..3c139c63098f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -949,6 +949,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-a83t-bananapi-m3.dtb \
> sun8i-a83t-cubietruck-plus.dtb \
> sun8i-a83t-tbs-a711.dtb \
> + sun8i-h2-plus-orangepi-r1.dtb \
> sun8i-h2-plus-orangepi-zero.dtb \
> sun8i-h3-bananapi-m2-plus.dtb \
> sun8i-h3-beelink-x2.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> new file mode 100644
> index 000000000000..32a6d312422e
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> @@ -0,0 +1,73 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/* Orange Pi R1 is based on Orange Pi Zero design */
> +#include "sun8i-h2-plus-orangepi-zero.dts"
> +
> +/ {
> + model = "Xunlong Orange Pi R1";
> + compatible = "xunlong,orangepi-r1", "allwinner,sun8i-h2-plus";
> +
> + /delete-node/ reg_vcc_wifi;
I remove this line.
> +
> + aliases {
> + ethernet1 = &rtl8189etv;
> + };
> +};
> +
I add this:
®_vcc_wifi {
regulator-always-on;
};
This regulator should be connected to the USB device, but this is not in
device tree because it should be automatically probed.
> +&ohci1 {
> + /*
> + * RTL8152B USB-Ethernet adapter is connected to USB1,
> + * and it's a USB 2.0 device. So the OHCI1 controller
> + * can be left disabled.
> + */
> + status = "disabled";
> +};
> +
> +&mmc1 {
> + vmmc-supply = <®_vcc3v3>;
> + vqmmc-supply = <®_vcc3v3>;
> +
> + rtl8189etv: sdio_wifi at 1 {
> + reg = <1>;
> + };
> +};
>
^ permalink raw reply
* [PATCH 1/2] clk: rename clk_core_get_boundaries() to clk_hw_get_boundaries() and expose
From: Alexander Kochetkov @ 2017-12-28 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227010638.GP7997@codeaurora.org>
Initial thread here:
https://www.spinics.net/lists/linux-clk/msg21682.html
> 27 ???. 2017 ?., ? 4:06, Stephen Boyd <sboyd@codeaurora.org> ???????(?):
>
> Are these limits the min/max limits that the parent clk can
> output at? Or the min/max limits that software has constrained on
> the clk?
>
Don?t know how to answer. For example, parent can output 768MHz,
but some IP work unstable with that parent rate. This issues was observed by
me and I didn?t get official confirmation from rockchip. So, I limit
such clock to 192MHz using clk_set_max_rate(). May be I have to limit clk rate
using another approach.
Anybody from rockchip can confirm that? Or may be contact me clarifying details?
> I haven't looked in detail at this
> rockchip_fractional_approximation() code, but it shouldn't be
> doing the work of both the child rate determination and the
> parent rate determination in one place. It should work with the
> parent to figure out the rate the parent can provide and then
> figure out how to achieve the desired rate from there.
Here is clock tree:
clock rate
----- ----
xin24m 24000000
pll_gpll 768000000
gpll 768000000
i2s_src 768000000
i2s0_pre 192000000
i2s0_frac 16384000
sclk_i2s0 16384000
I limit i2s0_pre rate to 192MHz in order to I2S IP work properly.
rockchip_fractional_approximation() get called for i2s0_frac.
if i2s0_pre rate is 20x times less than i2s0_frac, than rockchip_fractional_approximation()
tries to set i2s0_pre rate to i2s_src rate. It tries to increase it?s parent rate in order
to maximise relation between nominator and denominator.
If I convert rockchip_fractional_approximation() to rockchip_determine_rate(), than I get
min=0, max=192MHz limits inside rockchip_determine_rate(). May be there should be
new logic inside clk framework based on some new clk flags, that will provide max=768MHz
for rockchip_determine_rate().
Also found, that rockchip_fractional_approximation() increase parents rate unconditionally
without taking into account CLK_SET_RATE_PARENT flag.
Stephen, thanks a lot for deep description of determine_rate() background. I?ll taking some
time thinking about possible solutions.
Regards,
Alexander.
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Ard Biesheuvel @ 2017-12-28 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228120531.xhcb4dg2qu2z5ssp@gmail.com>
On 28 December 2017 at 12:05, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> Annoyingly, we need this because there is a single instance of a
>> special section that ends up in the EFI stub code: we build lib/sort.c
>> again as a EFI libstub object, and given that sort() is exported, we
>> end up with a ksymtab section in the EFI stub. The sort() thing has
>> caused issues before [0], so perhaps I should just clone sort.c into
>> drivers/firmware/efi/libstub and get rid of that hack.
>>
>> [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29f9007b3182ab3f328a31da13e6b1c9072f7a95
>
> If the root problem is early bootstrap code randomly using generic facility that
> isn't __init, then we should definitely improve tooling to at least detect these
> problems.
>
> As bootstrap code gets improved (KASLR, more complex decompression, etc. etc.) we
> keep using new bits of generic facilities...
>
> So this should definitely not be hidden by open coding that function (which has
> various other disadvantages as well), but should be turned from silent breakage
> either into non-breakage (and do so not only for sort() but for other generic
> functions as well), or should be turned into a build failure.
>
We already have safeguards in place to ensure that the arm64 EFI stub
(which is essentially the same executable as the kernel proper) only
pulls in code that has been made available to it explicitly. That is
why sort.c is recompiled for the EFI stub, as well as all other C code
that is shared between the stub and the kernel. We also have a build
time check to ensure that the resulting code does not rely on absolute
symbol references, which will be invalid in the UEFI execution
context.
So the only problem is that unneeded ksymtab/kcrctab sections, which
affected ARM for obscure reasons; typically, they just take up some
space. On x86, the kaslr code deals with a similar issue by
#define'ing _LINUX_EXPORT_H before including linux/export.h, which
also gets rid of these sections, but I was a bit reluctant to copy
that pattern. Perhaps we should enhance linux/export.h for reasons
such as these by adding a macro that nops out EXPORT_SYMBOL()
declarations?
^ permalink raw reply
* [PATCH 0/3] [v11] pinctrl: qcom: add support for sparse GPIOs
From: Linus Walleij @ 2017-12-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227020142.GZ7997@codeaurora.org>
On Wed, Dec 27, 2017 at 3:01 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 12/21, Linus Walleij wrote:
>> Hi Timur,
>>
>> thank you for your perseverance. I am sorry that I am sometimes not
>> fast to respond :(
>>
>> On Wed, Dec 20, 2017 at 8:10 PM, Timur Tabi <timur@codeaurora.org> wrote:
>>
>> > Patch 1 reverts an old patch that triggers a get_direction of every
>> > pin upon init, without attempting to request the pins first. The
>> > direction is already being queried when the pin is requested.
>> >
>> > Patch 2 adds support to pinctrl-msm for "unavailable" GPIOs.
>>
>> I have applied both of these to the pinctrl "devel" branch so we
>> can see if all is fine.
>>
>> They have Stephen's ACK so I am happy with them, I am just
>> still slightly worried about possible regressions because of
>> patch 1.
>>
>> > Patch 3 extends that support to pinctrl-qdf2xxx. A recent ACPI change
>> > on QDF2400 platforms blocks access to most pins, so the driver can only
>> > register a subset.
>>
>> I see this one is still under discussion.
>>
>> If nothing drastic happens with patch 1/2 in linux-next
>> it should be fine if you just resend this single patch in subsequent
>> submissions.
>>
>
> If we go with my suggestion, patch 2 is not necessary and should
> be dropped.
OK I have reverted it.
> The different approaches come down to expressing
> which pins are available through the gpio valid mask, or through
> the npins field of the msm pinctrl driver. Also, my approach
> covers more than just GPIOs, it covers irqs and adjusts the
> pinctrl pin request function so that pinctrl can't request
> unavailable pins.
I agree, this is better.
Would even patch 1 be needed after this? Maybe I should
revert that too. Leaving that code in has the upside of showing
the actual initial directions of GPIO lines even if they have
not been requested, in e.g. debugfs.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/4] ASoC: mediatek: fix error handling in mt2701_afe_pcm_dev_probe()
From: Ryder Lee @ 2017-12-28 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18b7f0ec484300af795b1873efab96e51393459c.1514190169.git.ryder.lee@mediatek.com>
Sorry, please ignore this series. I will send new ones later.
On Mon, 2017-12-25 at 16:28 +0800, Ryder Lee wrote:
> Fix unbalanced error handling path which will get incorrect counts
> if probe failed. The .remove() should be adjusted accordingly.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 23 ++++++++++-------------
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> index 8fda182..b3f6f73 100644
> --- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> +++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> @@ -1591,8 +1591,12 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, afe);
> pm_runtime_enable(&pdev->dev);
> - if (!pm_runtime_enabled(&pdev->dev))
> - goto err_pm_disable;
> + if (!pm_runtime_enabled(&pdev->dev)) {
> + ret = mt2701_afe_runtime_resume(&pdev->dev);
> + if (ret)
> + goto err_pm_disable;
> + }
> +
> pm_runtime_get_sync(&pdev->dev);
>
> ret = snd_soc_register_platform(&pdev->dev, &mtk_afe_pcm_platform);
> @@ -1610,16 +1614,12 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
> goto err_dai_component;
> }
>
> - mt2701_afe_runtime_resume(&pdev->dev);
> -
> return 0;
>
> err_dai_component:
> - snd_soc_unregister_component(&pdev->dev);
> -
> -err_platform:
> snd_soc_unregister_platform(&pdev->dev);
> -
> +err_platform:
> + pm_runtime_put_sync(&pdev->dev);
> err_pm_disable:
> pm_runtime_disable(&pdev->dev);
>
> @@ -1628,17 +1628,14 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
>
> static int mt2701_afe_pcm_dev_remove(struct platform_device *pdev)
> {
> - struct mtk_base_afe *afe = platform_get_drvdata(pdev);
> -
> + pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> if (!pm_runtime_status_suspended(&pdev->dev))
> mt2701_afe_runtime_suspend(&pdev->dev);
> - pm_runtime_put_sync(&pdev->dev);
>
> snd_soc_unregister_component(&pdev->dev);
> snd_soc_unregister_platform(&pdev->dev);
> - /* disable afe clock */
> - mt2701_afe_disable_clock(afe);
> +
> return 0;
> }
>
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Ingo Molnar @ 2017-12-28 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-wRtfnGfrEjuxR5YkCpZM-nQHZShROEdbcEh=fSiWf5A@mail.gmail.com>
* Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Annoyingly, we need this because there is a single instance of a
> special section that ends up in the EFI stub code: we build lib/sort.c
> again as a EFI libstub object, and given that sort() is exported, we
> end up with a ksymtab section in the EFI stub. The sort() thing has
> caused issues before [0], so perhaps I should just clone sort.c into
> drivers/firmware/efi/libstub and get rid of that hack.
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29f9007b3182ab3f328a31da13e6b1c9072f7a95
If the root problem is early bootstrap code randomly using generic facility that
isn't __init, then we should definitely improve tooling to at least detect these
problems.
As bootstrap code gets improved (KASLR, more complex decompression, etc. etc.) we
keep using new bits of generic facilities...
So this should definitely not be hidden by open coding that function (which has
various other disadvantages as well), but should be turned from silent breakage
either into non-breakage (and do so not only for sort() but for other generic
functions as well), or should be turned into a build failure.
Thanks,
Ingo
^ permalink raw reply
* v4.15: camera problems on n900
From: Pavel Machek @ 2017-12-28 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227211718.favif66afztygfje@kekkonen.localdomain>
On Wed 2017-12-27 23:17:19, Sakari Ailus wrote:
> On Wed, Dec 27, 2017 at 10:05:43PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
> > seconds, but then I get repeated oopses.
> >
> > On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
> > camera does not start.
> >
> > Any ideas what might be wrong there?
>
> What kind of oopses do you get?
Haven't seen the oopses yet; maybe they are only on linux-next?
Anyway, bisect so far:
# bad: [fb3f95c11904adf26c2bd86fe1b1613c921710b5] Config for v4.15-rc0.5
# good: [c213cf57c2f15ee226c14dd7157caa334c3ef7c8] Make config similar to n950 case. Still works on n900.
git bisect start 'mini-v4.15' 'mini-v4.14'
# good: [06410bdec961a55e78e01d4fda199f709a84e17f] Merge /data/l/clean-cg into mini-v4.14
git bisect good 06410bdec961a55e78e01d4fda199f709a84e17f
# bad: [fc35c1966e1372a21a88f6655279361e2f92713f] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
git bisect bad fc35c1966e1372a21a88f6655279361e2f92713f
# good: [bebc6082da0a9f5d47a1ea2edc099bf671058bd4] Linux 4.14
git bisect good bebc6082da0a9f5d47a1ea2edc099bf671058bd4
# good: [5bbcc0f595fadb4cac0eddc4401035ec0bd95b09] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good 5bbcc0f595fadb4cac0eddc4401035ec0bd95b09
# bad: [5b0e2cb020085efe202123162502e0b551e49a0e] Merge tag 'powerpc-4.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
git bisect bad 5b0e2cb020085efe202123162502e0b551e49a0e
# good: [f150891fd9878ef0d9197c4e8451ce67c3bdd014] Merge tag 'exynos-drm-next-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
git bisect good f150891fd9878ef0d9197c4e8451ce67c3bdd014
# good: [93ea0eb7d77afab34657715630d692a78b8cea6a] Merge tag 'leaks-4.15-rc1' of git://github.com/tcharding/linux
git bisect good 93ea0eb7d77afab34657715630d692a78b8cea6a
# bad: [2bf16b7a73caf3435f782e4170cfe563675e10f9] Merge tag 'char-misc-4.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect bad 2bf16b7a73caf3435f782e4170cfe563675e10f9
# good: [ef674997e49760137ca9a90aac41a9922ac399b2] media: staging: atomisp: Convert timers to use timer_setup()
git bisect good ef674997e49760137ca9a90aac41a9922ac399b2
# good: [b1cb7372fa822af6c06c8045963571d13ad6348b] dvb_frontend: don't use-after-free the frontend struct
git bisect good b1cb7372fa822af6c06c8045963571d13ad6348b
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171228/413292c1/attachment.sig>
^ permalink raw reply
* [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero
From: Hanjun Guo @ 2017-12-28 11:24 UTC (permalink / raw)
To: linux-arm-kernel
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.
Reported-by: Lei Li <lious.lilei@hisilicon.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Xuefeng Wang <wxf.wang@hisilicon.com>
---
Not sure if this is the right direction, this patch has a obvious
side effect that a mapped address with 4K will not back to 2M. I may
miss something and just wrong, so this is just a RFC version, comments
are welcomed.
lib/ioremap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/ioremap.c b/lib/ioremap.c
index b808a39..4e6f19a 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -89,7 +89,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr,
do {
next = pmd_addr_end(addr, end);
- if (ioremap_pmd_enabled() &&
+ if (ioremap_pmd_enabled() && pmd_none(*pmd) &&
((next - addr) == PMD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
if (pmd_set_huge(pmd, phys_addr + addr, prot))
@@ -115,7 +115,7 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr,
do {
next = pud_addr_end(addr, end);
- if (ioremap_pud_enabled() &&
+ if (ioremap_pud_enabled() && pud_none(*pud) &&
((next - addr) == PUD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PUD_SIZE)) {
if (pud_set_huge(pud, phys_addr + addr, prot))
@@ -141,7 +141,7 @@ static inline int ioremap_p4d_range(pgd_t *pgd, unsigned long addr,
do {
next = p4d_addr_end(addr, end);
- if (ioremap_p4d_enabled() &&
+ if (ioremap_p4d_enabled() && p4d_none(*p4d) &&
((next - addr) == P4D_SIZE) &&
IS_ALIGNED(phys_addr + addr, P4D_SIZE)) {
if (p4d_set_huge(p4d, phys_addr + addr, prot))
--
1.7.12.4
^ permalink raw reply related
* [PATCH 1/3] phy: phy-mtk-tphy: use auto instead of force to bypass utmi signals
From: Kishon Vijay Abraham I @ 2017-12-28 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff2797a0487a0b30a2292c2685dedcbbfeead293.1512647458.git.chunfeng.yun@mediatek.com>
On Thursday 07 December 2017 05:23 PM, Chunfeng Yun wrote:
> When system is running, if usb2 phy is forced to bypass utmi signals,
> all PLL will be turned off, and it can't detect device connection
> anymore, so replace force mode with auto mode which can bypass utmi
> signals automatically if no device attached for normal flow.
> But keep the force mode to fix RX sensitivity degradation issue.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
merged this series.
Thanks
Kishon
> ---
> drivers/phy/mediatek/phy-mtk-tphy.c | 19 +++++++------------
> 1 file changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c b/drivers/phy/mediatek/phy-mtk-tphy.c
> index fb8aba4..5d9d7f3 100644
> --- a/drivers/phy/mediatek/phy-mtk-tphy.c
> +++ b/drivers/phy/mediatek/phy-mtk-tphy.c
> @@ -440,9 +440,9 @@ static void u2_phy_instance_init(struct mtk_tphy *tphy,
> u32 index = instance->index;
> u32 tmp;
>
> - /* switch to USB function. (system register, force ip into usb mode) */
> + /* switch to USB function, and enable usb pll */
> tmp = readl(com + U3P_U2PHYDTM0);
> - tmp &= ~P2C_FORCE_UART_EN;
> + tmp &= ~(P2C_FORCE_UART_EN | P2C_FORCE_SUSPENDM);
> tmp |= P2C_RG_XCVRSEL_VAL(1) | P2C_RG_DATAIN_VAL(0);
> writel(tmp, com + U3P_U2PHYDTM0);
>
> @@ -502,10 +502,8 @@ static void u2_phy_instance_power_on(struct mtk_tphy *tphy,
> u32 index = instance->index;
> u32 tmp;
>
> - /* (force_suspendm=0) (let suspendm=1, enable usb 480MHz pll) */
> tmp = readl(com + U3P_U2PHYDTM0);
> - tmp &= ~(P2C_FORCE_SUSPENDM | P2C_RG_XCVRSEL);
> - tmp &= ~(P2C_RG_DATAIN | P2C_DTM0_PART_MASK);
> + tmp &= ~(P2C_RG_XCVRSEL | P2C_RG_DATAIN | P2C_DTM0_PART_MASK);
> writel(tmp, com + U3P_U2PHYDTM0);
>
> /* OTG Enable */
> @@ -540,7 +538,6 @@ static void u2_phy_instance_power_off(struct mtk_tphy *tphy,
>
> tmp = readl(com + U3P_U2PHYDTM0);
> tmp &= ~(P2C_RG_XCVRSEL | P2C_RG_DATAIN);
> - tmp |= P2C_FORCE_SUSPENDM;
> writel(tmp, com + U3P_U2PHYDTM0);
>
> /* OTG Disable */
> @@ -548,18 +545,16 @@ static void u2_phy_instance_power_off(struct mtk_tphy *tphy,
> tmp &= ~PA6_RG_U2_OTG_VBUSCMP_EN;
> writel(tmp, com + U3P_USBPHYACR6);
>
> - /* let suspendm=0, set utmi into analog power down */
> - tmp = readl(com + U3P_U2PHYDTM0);
> - tmp &= ~P2C_RG_SUSPENDM;
> - writel(tmp, com + U3P_U2PHYDTM0);
> - udelay(1);
> -
> tmp = readl(com + U3P_U2PHYDTM1);
> tmp &= ~(P2C_RG_VBUSVALID | P2C_RG_AVALID);
> tmp |= P2C_RG_SESSEND;
> writel(tmp, com + U3P_U2PHYDTM1);
>
> if (tphy->pdata->avoid_rx_sen_degradation && index) {
> + tmp = readl(com + U3P_U2PHYDTM0);
> + tmp &= ~(P2C_RG_SUSPENDM | P2C_FORCE_SUSPENDM);
> + writel(tmp, com + U3P_U2PHYDTM0);
> +
> tmp = readl(com + U3D_U2PHYDCR0);
> tmp &= ~P2C_RG_SIF_U2PLL_FORCE_ON;
> writel(tmp, com + U3D_U2PHYDCR0);
>
^ permalink raw reply
* [PATCH] PCI: exynos: remove redundant code in exynos_pcie_establish_link
From: Pankaj Dubey @ 2017-12-28 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <533c6579-065f-100a-9a8f-c852ad4d0398@samsung.com>
Hi Jaehoon,
On 12/28/2017 03:28 PM, Jaehoon Chung wrote:
> Hi Pankaj,
>
> On 12/28/2017 06:50 PM, Pankaj Dubey wrote:
>> Hi Jingoo,
>>
>>
>> On 12/21/2017 10:01 PM, Jingoo Han wrote:
>>> On Tuesday, October 10, 2017 9:46 AM, Pankaj Dubey wrote:
>>>> Hi Jingoo,
>>>>
>>>>
>>>> On 10/09/2017 09:50 PM, Jingoo Han wrote:
>>>>> On Monday, October 9, 2017 10:44 AM, Krzysztof Kozlowski wrote:
>>>>>> On Mon, Oct 9, 2017 at 4:14 PM, Pankaj Dubey <pankaj.dubey@samsung.com>
>>>>>> wrote:
>>>>>>> From: Anvesh Salveru <anvesh.s@samsung.com>
>>>>>>>
>>>>>>> In exynos_pcie_establish_link if driver is not using generic phy,
>>>>>>> we are resetting PHY twice, which is redundant, so this patch removes
>>>>>> Hi Pankaj,
>>>>>>
>>>>>> This lacks the information why it is redundant.
>>>>> (I resend this mail, because email address of pci list was corrupted.)
>>>> Thanks, somehow I typed wrong email id.
>>>>> I think so, too.
>>>>>
>>>>> Did you test this code on some boards with Exynos PCIe?
>>>>> Or did hardware engineers confirm this?
>>>>> Please add more information on this patch.
>>>> I have replied reason behind this patch in reply to Krzysztof, hope I am
>>>> able to
>>>> explain logic behind this change.
>>>>
>>>> I do not have access to Exynos5440 PCIe, and this PHY_COMMON_RESET is not
>>>> applicable to other Exynos SoC which I have with me, so I can't test
>>>> this change,
>>>> but if you see the change it is an obvious change, before introducing
>>>> generic phy
>>>> support to this driver PHY_COMMON_RESET was programmed only once, then
>>>> in case platform is not using PHY it suppose to be done only once during
>>>> linkup.
>>>> I am not sure when Jaehoon introduced this patch, he verified this on
>>>> Exynos5440 or
>>>> not. We are just trying to make the logic as it was before without
>>>> affecting anything.
>>>>
>>>> Thanks,
>>>> Pankaj Dubey
>>>>> Best regards,
>>>>> Jingoo Han
>>>>>
>>>>>>> repeated lines of code for PHY reset.
>>>>>>>
>>>>>>> Signed-off-by: Anvesh Salveru <anvesh.s@samsung.com>
>>>>>> Your Signed-off-by is needed here.
>>> Sorry for being late.
>>> I checked that this patch is right.
>>>
>>> Can you send this patch again with your Signed-off-by?
>>> Also, you can add my Acked-by to your new patch.
>>>
>>> Acked-by: Jingoo Han <jingoohan1@gmail.com>
>> Thanks for review and ack.
>> Will resubmit the patch along with my Signed-off-by and your Acked-by.
> Maybe it will be removed with my patch.
>
> https://patchwork.ozlab.org/patch/853119/
>
> Because of my personal reason, i can't send the email to Bjorn's account..so i removed his account from cc.
> Sorry.
As per submission date, we have submitted it first, so it should
be taken in that order, but I I am fine with any of the patch, so I will
leave this on Bjorn.
Thanks,
Pankaj Dubey
> Best Regards,
> Jaehoon Chung
>
>> Thanks,
>> Pankaj Dubey
>>> Best regards,
>>> Jingoo Han
>>>
>>>>>> Best regards,
>>>>>> Krzysztof
>>>>>>
>>>>>>> ---
>>>>>>> drivers/pci/dwc/pci-exynos.c | 7 -------
>>>>>>> 1 file changed, 7 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-
>>>> exynos.c
>>>>>>> index 5596fde..85d2f4b 100644
>>>>>>> --- a/drivers/pci/dwc/pci-exynos.c
>>>>>>> +++ b/drivers/pci/dwc/pci-exynos.c
>>>>>>> @@ -423,13 +423,6 @@ static int exynos_pcie_establish_link(struct
>>>>>> exynos_pcie *ep)
>>>>>>> exynos_pcie_deassert_phy_reset(ep);
>>>>>>> exynos_pcie_power_on_phy(ep);
>>>>>>> exynos_pcie_init_phy(ep);
>>>>>>> -
>>>>>>> - /* pulse for common reset */
>>>>>>> - exynos_pcie_writel(ep->mem_res->block_base, 1,
>>>>>>> - PCIE_PHY_COMMON_RESET);
>>>>>>> - udelay(500);
>>>>>>> - exynos_pcie_writel(ep->mem_res->block_base, 0,
>>>>>>> - PCIE_PHY_COMMON_RESET);
>>>>>>> }
>>>>>>>
>>>>>>> /* pulse for common reset */
>>>>>>> --
>>>>>>> 2.7.4
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
^ permalink raw reply
* [PATCH net-next 1/6] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2017-12-28 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228072053.GA27336@lunn.ch>
Hi Andrew,
On Thu, Dec 28, 2017 at 08:20:53AM +0100, Andrew Lunn wrote:
> On Wed, Dec 27, 2017 at 11:14:41PM +0100, Antoine Tenart wrote:
> > This patch adds one more generic PHY mode to the phy_mode enum, to allow
> > configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
> > callback.
> >
> > Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> > ---
> > include/linux/phy/phy.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> > index 4f8423a948d5..70459a28f3a1 100644
> > --- a/include/linux/phy/phy.h
> > +++ b/include/linux/phy/phy.h
> > @@ -28,6 +28,7 @@ enum phy_mode {
> > PHY_MODE_USB_DEVICE,
> > PHY_MODE_USB_OTG,
> > PHY_MODE_SGMII,
> > + PHY_MODE_SGMII_2_5G,
> > PHY_MODE_10GKR,
> > PHY_MODE_UFS_HS_A,
> > PHY_MODE_UFS_HS_B,
>
> There was a discussion maybe last month about adding 2.5G SGMII. I
> would prefer 2500SGMII. Putting the number first makes it uniform with
> the other defines, 1000BASEX, 25000BASEX, 10GKR.
Good to know. I wasn't completely sure how to name this mode properly,
but I'm fine with PHY_MODE_2500SGMII. I'll update the patches and send a
v2 (without the dt part).
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] PCI: imx6: Add PHY reference clock source support
From: Richard Zhu @ 2017-12-28 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514369154-21105-1-git-send-email-ilya@compulab.co.il>
Hi Ilya:
I think the "ocsillator" in the binding document should be oscillator.
Thanks.
Best Regards
Richard
Best Regards
hongxing zhu
Linux BSP team
Office: 86-21-28937189
Email: hongxing.zhu at nxp.com
-----Original Message-----
From: Ilya Ledvich [mailto:ilya at compulab.co.il]
Sent: Wednesday, December 27, 2017 6:06 PM
To: Richard Zhu <hongxing.zhu@nxp.com>; Lucas Stach <l.stach@pengutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>; linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Ilya Ledvich <ilya@compulab.co.il>
Subject: [PATCH] PCI: imx6: Add PHY reference clock source support
i.MX7D variant of the IP can use either Crystal Oscillator input or internal clock input as a Reference Clock input for PCIe PHY.
Add support for an optional property 'pcie-phy-refclk-internal'.
If present then an internal clock input is used as PCIe PHY reference clock source. By default an external oscillator input is still used.
Verified on Compulab SBC-iMX7 Single Board Computer.
Signed-off-by: Ilya Ledvich <ilya@compulab.co.il>
---
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 5 +++++
drivers/pci/dwc/pci-imx6.c | 8 +++++++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
index 7b1e48b..f9cf11e 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -50,6 +50,11 @@ Additional required properties for imx7d-pcie:
- "pciephy"
- "apps"
+Additional optional properties for imx7d-pcie:
+- pcie-phy-refclk-internal: If present then an internal PLL input is
+used as
+ PCIe PHY reference clock source. By default an external ocsillator
+input
+ is used.
+
Example:
pcie at 0x01000000 {
diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c index b734835..a616192 100644
--- a/drivers/pci/dwc/pci-imx6.c
+++ b/drivers/pci/dwc/pci-imx6.c
@@ -61,6 +61,7 @@ struct imx6_pcie {
u32 tx_swing_low;
int link_gen;
struct regulator *vpcie;
+ bool pciephy_refclk_sel;
};
/* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */ @@ -474,7 +475,9 @@ static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
switch (imx6_pcie->variant) {
case IMX7D:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
- IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
+ IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
+ imx6_pcie->pciephy_refclk_sel ?
+ IMX7D_GPR12_PCIE_PHY_REFCLK_SEL : 0);
break;
case IMX6SX:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, @@ -840,6 +843,9 @@ static int imx6_pcie_probe(struct platform_device *pdev)
imx6_pcie->vpcie = NULL;
}
+ imx6_pcie->pciephy_refclk_sel =
+ of_property_read_bool(node, "pcie-phy-refclk-internal");
+
platform_set_drvdata(pdev, imx6_pcie);
ret = imx6_add_pcie_port(imx6_pcie, pdev);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Antoine Tenart @ 2017-12-28 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228074623.GA28444@lunn.ch>
Hi Andrew,
On Thu, Dec 28, 2017 at 08:46:23AM +0100, Andrew Lunn wrote:
> On Wed, Dec 27, 2017 at 10:24:01PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> > >
> > > +&cps_eth2 {
> > > + /* CPS Lane 5 */
> > > + status = "okay";
> > > + phy-mode = "2500base-x";
> > > + /* Generic PHY, providing serdes lanes */
> > > + phys = <&cps_comphy5 2>;
> > > +};
> > > +
> >
> > This is wrong. This lane is connected to a SFP cage which can support
> > more than just 2500base-X. Tying it in this way to 2500base-X means
> > that this port does not support conenctions at 1000base-X, despite
> > that's one of the most popular and more standardised speeds.
> >
>
> I agree with Russell here. SFP modules are hot pluggable, and support
> a range of interface modes. You need to query what the SFP module is
> in order to know how to configure the SERDES interface. The phylink
> infrastructure does that for you.
Sure, I understand. We'll be able to support such interfaces only when
the phylink PPv2 support lands in.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Antoine Tenart @ 2017-12-28 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227231959.GU10595@n2100.armlinux.org.uk>
Hi Russell,
On Wed, Dec 27, 2017 at 11:20:00PM +0000, Russell King - ARM Linux wrote:
> On Wed, Dec 27, 2017 at 11:42:52PM +0100, Antoine Tenart wrote:
> >
> > What do you suggest to describe this in the dt, to enable a port using
> > the current PPv2 driver?
>
> I don't - I'm merely pointing out that you're bodging support for the
> SFP cage rather than productively discussing phylink for mvpp2.
>
> As far as I remember, the discussion stalled at this point:
>
> - You think there's modes that mvpp2 supports that are not supportable
> if you use phylink.
>
> - I've described what phylink supports, and I've asked you for details
> about what you can't support.
That's not what I remembered. You had some valid points, and others
related to PHY modes the driver wasn't supporting before the phylink
transition. My understanding of this was that you wanted a full
featured support while I only wanted to convert the already supported
modes.
> Unfortunately, no details have been forthcoming, and no further
> discussion has occurred - the ball is entirely in your court to
> progress this issue since I requested information from you and that
> is where things seem to have stalled.
>
> The result is that, with your patch, you're locking the port to 2.5G
> speeds, meaning that only 4.3Mbps Fibrechannel SFPs can be used with
> the port, and it can only be used with another device that supports
> 2.5G speeds. You can't use a copper RJ45 module, and you can't use
> a standard 1000base-X module either in this configuration.
You're probably right about not wanting this dt patch. The non-dt
patches still are relevant regardless of phylink being supported in the
PPv2 driver. I'll send a v2 without the dt parts.
Regarding the phylink patch it's stalled for now as I have other
priorities, but I do agree it's a topic that needs to be worked on for a
proper support. I initially made a patch to be nice as it was mentioned
on a previous series, but given the feedback I got I decided to delay it
until my other tasks were completed.
So let's delay the fourth interface support on the mcbin for now.
> What I'm most concerned about, given the bindings for comphy that
> have been merged, is that Free Electrons is pushing forward seemingly
> with no regard to the requirement that the serdes lanes are dynamically
> reconfigurable, and that's a basic requirement for SFP, and for the
> 88x3310 PHYs on the Macchiatobin platform.
The main idea behind the comphy driver is to provide a way to
reconfigure the serdes lanes at runtime. Could you develop what are
blocking points to properly support SFP, regarding the current comphy
support?
Thanks,
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] PCI: exynos: remove redundant code in exynos_pcie_establish_link
From: Jaehoon Chung @ 2017-12-28 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cd0c5923-899c-0652-20ce-7f08f4bf32e1@samsung.com>
Hi Pankaj,
On 12/28/2017 06:50 PM, Pankaj Dubey wrote:
> Hi Jingoo,
>
>
> On 12/21/2017 10:01 PM, Jingoo Han wrote:
>> On Tuesday, October 10, 2017 9:46 AM, Pankaj Dubey wrote:
>>> Hi Jingoo,
>>>
>>>
>>> On 10/09/2017 09:50 PM, Jingoo Han wrote:
>>>> On Monday, October 9, 2017 10:44 AM, Krzysztof Kozlowski wrote:
>>>>> On Mon, Oct 9, 2017 at 4:14 PM, Pankaj Dubey <pankaj.dubey@samsung.com>
>>>>> wrote:
>>>>>> From: Anvesh Salveru <anvesh.s@samsung.com>
>>>>>>
>>>>>> In exynos_pcie_establish_link if driver is not using generic phy,
>>>>>> we are resetting PHY twice, which is redundant, so this patch removes
>>>>> Hi Pankaj,
>>>>>
>>>>> This lacks the information why it is redundant.
>>>> (I resend this mail, because email address of pci list was corrupted.)
>>> Thanks, somehow I typed wrong email id.
>>>> I think so, too.
>>>>
>>>> Did you test this code on some boards with Exynos PCIe?
>>>> Or did hardware engineers confirm this?
>>>> Please add more information on this patch.
>>> I have replied reason behind this patch in reply to Krzysztof, hope I am
>>> able to
>>> explain logic behind this change.
>>>
>>> I do not have access to Exynos5440 PCIe, and this PHY_COMMON_RESET is not
>>> applicable to other Exynos SoC which I have with me, so I can't test
>>> this change,
>>> but if you see the change it is an obvious change, before introducing
>>> generic phy
>>> support to this driver PHY_COMMON_RESET was programmed only once, then
>>> in case platform is not using PHY it suppose to be done only once during
>>> linkup.
>>> I am not sure when Jaehoon introduced this patch, he verified this on
>>> Exynos5440 or
>>> not. We are just trying to make the logic as it was before without
>>> affecting anything.
>>>
>>> Thanks,
>>> Pankaj Dubey
>>>> Best regards,
>>>> Jingoo Han
>>>>
>>>>>> repeated lines of code for PHY reset.
>>>>>>
>>>>>> Signed-off-by: Anvesh Salveru <anvesh.s@samsung.com>
>>>>> Your Signed-off-by is needed here.
>> Sorry for being late.
>> I checked that this patch is right.
>>
>> Can you send this patch again with your Signed-off-by?
>> Also, you can add my Acked-by to your new patch.
>>
>> Acked-by: Jingoo Han <jingoohan1@gmail.com>
>
> Thanks for review and ack.
> Will resubmit the patch along with my Signed-off-by and your Acked-by.
Maybe it will be removed with my patch.
https://patchwork.ozlab.org/patch/853119/
Because of my personal reason, i can't send the email to Bjorn's account..so i removed his account from cc.
Sorry.
Best Regards,
Jaehoon Chung
>
> Thanks,
> Pankaj Dubey
>> Best regards,
>> Jingoo Han
>>
>>>>> Best regards,
>>>>> Krzysztof
>>>>>
>>>>>> ---
>>>>>> drivers/pci/dwc/pci-exynos.c | 7 -------
>>>>>> 1 file changed, 7 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-
>>> exynos.c
>>>>>> index 5596fde..85d2f4b 100644
>>>>>> --- a/drivers/pci/dwc/pci-exynos.c
>>>>>> +++ b/drivers/pci/dwc/pci-exynos.c
>>>>>> @@ -423,13 +423,6 @@ static int exynos_pcie_establish_link(struct
>>>>> exynos_pcie *ep)
>>>>>> exynos_pcie_deassert_phy_reset(ep);
>>>>>> exynos_pcie_power_on_phy(ep);
>>>>>> exynos_pcie_init_phy(ep);
>>>>>> -
>>>>>> - /* pulse for common reset */
>>>>>> - exynos_pcie_writel(ep->mem_res->block_base, 1,
>>>>>> - PCIE_PHY_COMMON_RESET);
>>>>>> - udelay(500);
>>>>>> - exynos_pcie_writel(ep->mem_res->block_base, 0,
>>>>>> - PCIE_PHY_COMMON_RESET);
>>>>>> }
>>>>>>
>>>>>> /* pulse for common reset */
>>>>>> --
>>>>>> 2.7.4
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
>
>
^ permalink raw reply
* [PATCH] PCI: exynos: remove redundant code in exynos_pcie_establish_link
From: Pankaj Dubey @ 2017-12-28 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000101d37a79$2bdb4c20$8391e460$@gmail.com>
Hi Jingoo,
On 12/21/2017 10:01 PM, Jingoo Han wrote:
> On Tuesday, October 10, 2017 9:46 AM, Pankaj Dubey wrote:
>> Hi Jingoo,
>>
>>
>> On 10/09/2017 09:50 PM, Jingoo Han wrote:
>>> On Monday, October 9, 2017 10:44 AM, Krzysztof Kozlowski wrote:
>>>> On Mon, Oct 9, 2017 at 4:14 PM, Pankaj Dubey <pankaj.dubey@samsung.com>
>>>> wrote:
>>>>> From: Anvesh Salveru <anvesh.s@samsung.com>
>>>>>
>>>>> In exynos_pcie_establish_link if driver is not using generic phy,
>>>>> we are resetting PHY twice, which is redundant, so this patch removes
>>>> Hi Pankaj,
>>>>
>>>> This lacks the information why it is redundant.
>>> (I resend this mail, because email address of pci list was corrupted.)
>> Thanks, somehow I typed wrong email id.
>>> I think so, too.
>>>
>>> Did you test this code on some boards with Exynos PCIe?
>>> Or did hardware engineers confirm this?
>>> Please add more information on this patch.
>> I have replied reason behind this patch in reply to Krzysztof, hope I am
>> able to
>> explain logic behind this change.
>>
>> I do not have access to Exynos5440 PCIe, and this PHY_COMMON_RESET is not
>> applicable to other Exynos SoC which I have with me, so I can't test
>> this change,
>> but if you see the change it is an obvious change, before introducing
>> generic phy
>> support to this driver PHY_COMMON_RESET was programmed only once, then
>> in case platform is not using PHY it suppose to be done only once during
>> linkup.
>> I am not sure when Jaehoon introduced this patch, he verified this on
>> Exynos5440 or
>> not. We are just trying to make the logic as it was before without
>> affecting anything.
>>
>> Thanks,
>> Pankaj Dubey
>>> Best regards,
>>> Jingoo Han
>>>
>>>>> repeated lines of code for PHY reset.
>>>>>
>>>>> Signed-off-by: Anvesh Salveru <anvesh.s@samsung.com>
>>>> Your Signed-off-by is needed here.
> Sorry for being late.
> I checked that this patch is right.
>
> Can you send this patch again with your Signed-off-by?
> Also, you can add my Acked-by to your new patch.
>
> Acked-by: Jingoo Han <jingoohan1@gmail.com>
Thanks for review and ack.
Will resubmit the patch along with my Signed-off-by and your Acked-by.
Thanks,
Pankaj Dubey
> Best regards,
> Jingoo Han
>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>>> ---
>>>>> drivers/pci/dwc/pci-exynos.c | 7 -------
>>>>> 1 file changed, 7 deletions(-)
>>>>>
>>>>> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-
>> exynos.c
>>>>> index 5596fde..85d2f4b 100644
>>>>> --- a/drivers/pci/dwc/pci-exynos.c
>>>>> +++ b/drivers/pci/dwc/pci-exynos.c
>>>>> @@ -423,13 +423,6 @@ static int exynos_pcie_establish_link(struct
>>>> exynos_pcie *ep)
>>>>> exynos_pcie_deassert_phy_reset(ep);
>>>>> exynos_pcie_power_on_phy(ep);
>>>>> exynos_pcie_init_phy(ep);
>>>>> -
>>>>> - /* pulse for common reset */
>>>>> - exynos_pcie_writel(ep->mem_res->block_base, 1,
>>>>> - PCIE_PHY_COMMON_RESET);
>>>>> - udelay(500);
>>>>> - exynos_pcie_writel(ep->mem_res->block_base, 0,
>>>>> - PCIE_PHY_COMMON_RESET);
>>>>> }
>>>>>
>>>>> /* pulse for common reset */
>>>>> --
>>>>> 2.7.4
>>>>>
>>>
>>>
>>>
>
>
>
>
^ permalink raw reply
* [PATCH] ARM: imx: introduce imx_l2c310_write_sec
From: Peng Fan @ 2017-12-28 9:35 UTC (permalink / raw)
To: linux-arm-kernel
Some PL310 registers could only be wrote in secure world, so
introduce imx_l2c310_write_sec to support Linux running in
non-secure world.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Dong Aisheng <aisheng.dong@nxp.com>
---
arch/arm/mach-imx/system.c | 21 +++++++++++++++++++--
include/soc/imx/imx_sip_smc.h | 23 +++++++++++++++++++++++
2 files changed, 42 insertions(+), 2 deletions(-)
create mode 100644 include/soc/imx/imx_sip_smc.h
diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
index c06af650e6b1..86ce9f590777 100644
--- a/arch/arm/mach-imx/system.c
+++ b/arch/arm/mach-imx/system.c
@@ -23,11 +23,13 @@
#include <linux/delay.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <soc/imx/imx_sip_smc.h>
#include <asm/system_misc.h>
#include <asm/proc-fns.h>
#include <asm/mach-types.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/outercache.h>
#include "common.h"
#include "hardware.h"
@@ -35,6 +37,9 @@
static void __iomem *wdog_base;
static struct clk *wdog_clk;
static int wcr_enable = (1 << 2);
+#ifdef CONFIG_CACHE_L2X0
+static void __iomem *l2x0_base;
+#endif
/*
* Reset the system. It is called by machine_restart().
@@ -92,9 +97,15 @@ void __init imx1_reset_init(void __iomem *base)
#endif
#ifdef CONFIG_CACHE_L2X0
+void imx_l2c310_write_sec(unsigned long val, unsigned int reg)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_SMC_L2C310, val, reg, 0, 0, 0, 0, 0, &res);
+}
+
void __init imx_init_l2cache(void)
{
- void __iomem *l2x0_base;
struct device_node *np;
unsigned int val;
@@ -102,6 +113,9 @@ void __init imx_init_l2cache(void)
if (!np)
return;
+ if (of_find_compatible_node(NULL, NULL, "linaro,optee-tz"))
+ outer_cache.write_sec = imx_l2c310_write_sec;
+
l2x0_base = of_iomap(np, 0);
if (!l2x0_base)
goto put_node;
@@ -117,7 +131,10 @@ void __init imx_init_l2cache(void)
val &= ~L310_PREFETCH_CTRL_OFFSET_MASK;
val |= 15;
- writel_relaxed(val, l2x0_base + L310_PREFETCH_CTRL);
+ if (outer_cache.write_sec)
+ outer_cache.write_sec(val, L310_PREFETCH_CTRL);
+ else
+ writel_relaxed(val, l2x0_base + L310_PREFETCH_CTRL);
}
iounmap(l2x0_base);
diff --git a/include/soc/imx/imx_sip_smc.h b/include/soc/imx/imx_sip_smc.h
new file mode 100644
index 000000000000..61a493278169
--- /dev/null
+++ b/include/soc/imx/imx_sip_smc.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright 2017 NXP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __IMX_SIP_SMC_H_
+#define __IMX_SIP_SMC_H_
+
+#include <linux/arm-smccc.h>
+
+#define IMX_SIP_SMC_VAL(func) ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_SIP, \
+ (func))
+
+#define IMX_L2C310 0x1
+
+#define IMX_SIP_SMC_L2C310 IMX_SIP_SMC_VAL(IMX_L2C310)
+
+#endif
--
2.14.1
^ permalink raw reply related
* [PATCH 2/2] ARM: multi_v7_defconfig: Enable OP-TEE
From: Peng Fan @ 2017-12-28 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514453660-15373-1-git-send-email-peng.fan@nxp.com>
Enable OP-TEE for multi_v7_defconfig
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Rask Ingemann Lambertsen <rask@formelder.dk>
Cc: Valentin Rothberg <valentinrothberg@gmail.com>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Dong Aisheng <aisheng.dong@nxp.com>
---
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 085c7cd4ecdf..91679b507796 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -863,6 +863,8 @@ CONFIG_PHY_TEGRA_XUSB=y
CONFIG_OMAP_USB2=y
CONFIG_TI_PIPE3=y
CONFIG_NVMEM_SUNXI_SID=y
+CONFIG_TEE=y
+CONFIG_OPTEE=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_BCM47XX_NVRAM=y
CONFIG_BCM47XX_SPROM=y
--
2.14.1
^ permalink raw reply related
* [PATCH 1/2] ARM: multi_v7_defconfig: select CONFIG_RTC_DRV_SNVS
From: Peng Fan @ 2017-12-28 9:34 UTC (permalink / raw)
To: linux-arm-kernel
Select CONFIG_RTC_DRV_SNVS for i.MX6 to use RTC to wakeup system
Patch generated with:
make ARCH=arm multi_v7_defconfig
select CONFIG_RTC_DRV_SNVS
make savedefconfig
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Rask Ingemann Lambertsen <rask@formelder.dk>
Cc: Valentin Rothberg <valentinrothberg@gmail.com>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Dong Aisheng <aisheng.dong@nxp.com>
---
arch/arm/configs/multi_v7_defconfig | 324 +++++++++++++++---------------------
1 file changed, 132 insertions(+), 192 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 61509c4b769f..085c7cd4ecdf 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1,5 +1,4 @@
CONFIG_SYSVIPC=y
-CONFIG_FHANDLE=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
@@ -11,13 +10,7 @@ CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_CMDLINE_PARTITION=y
-CONFIG_ARCH_MULTI_V7=y
-# CONFIG_ARCH_MULTI_V5 is not set
-# CONFIG_ARCH_MULTI_V4 is not set
CONFIG_ARCH_VIRT=y
-CONFIG_ARCH_ALPINE=y
-CONFIG_ARCH_ARTPEC=y
-CONFIG_MACH_ARTPEC6=y
CONFIG_ARCH_MVEBU=y
CONFIG_MACH_ARMADA_370=y
CONFIG_MACH_ARMADA_375=y
@@ -25,6 +18,9 @@ CONFIG_MACH_ARMADA_38X=y
CONFIG_MACH_ARMADA_39X=y
CONFIG_MACH_ARMADA_XP=y
CONFIG_MACH_DOVE=y
+CONFIG_ARCH_ALPINE=y
+CONFIG_ARCH_ARTPEC=y
+CONFIG_MACH_ARTPEC6=y
CONFIG_ARCH_AT91=y
CONFIG_SOC_SAMA5D2=y
CONFIG_SOC_SAMA5D3=y
@@ -33,9 +29,9 @@ CONFIG_ARCH_BCM=y
CONFIG_ARCH_BCM_CYGNUS=y
CONFIG_ARCH_BCM_HR2=y
CONFIG_ARCH_BCM_NSP=y
-CONFIG_ARCH_BCM_21664=y
-CONFIG_ARCH_BCM_281XX=y
CONFIG_ARCH_BCM_5301X=y
+CONFIG_ARCH_BCM_281XX=y
+CONFIG_ARCH_BCM_21664=y
CONFIG_ARCH_BCM2835=y
CONFIG_ARCH_BCM_63XX=y
CONFIG_ARCH_BRCMSTB=y
@@ -47,9 +43,9 @@ CONFIG_ARCH_DIGICOLOR=y
CONFIG_ARCH_HIGHBANK=y
CONFIG_ARCH_HISI=y
CONFIG_ARCH_HI3xxx=y
-CONFIG_ARCH_HIX5HD2=y
CONFIG_ARCH_HIP01=y
CONFIG_ARCH_HIP04=y
+CONFIG_ARCH_HIX5HD2=y
CONFIG_ARCH_KEYSTONE=y
CONFIG_ARCH_MESON=y
CONFIG_ARCH_MXC=y
@@ -61,8 +57,9 @@ CONFIG_SOC_IMX6SL=y
CONFIG_SOC_IMX6SX=y
CONFIG_SOC_IMX6UL=y
CONFIG_SOC_IMX7D=y
-CONFIG_SOC_VF610=y
CONFIG_SOC_LS1021A=y
+CONFIG_SOC_VF610=y
+CONFIG_ARCH_MEDIATEK=y
CONFIG_ARCH_OMAP3=y
CONFIG_ARCH_OMAP4=y
CONFIG_SOC_OMAP5=y
@@ -70,7 +67,6 @@ CONFIG_SOC_AM33XX=y
CONFIG_SOC_AM43XX=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARCH_QCOM=y
-CONFIG_ARCH_MEDIATEK=y
CONFIG_ARCH_MSM8X60=y
CONFIG_ARCH_MSM8960=y
CONFIG_ARCH_MSM8974=y
@@ -101,10 +97,6 @@ CONFIG_ARCH_SH73A0=y
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_SIRF=y
CONFIG_ARCH_TEGRA=y
-CONFIG_ARCH_TEGRA_2x_SOC=y
-CONFIG_ARCH_TEGRA_3x_SOC=y
-CONFIG_ARCH_TEGRA_114_SOC=y
-CONFIG_ARCH_TEGRA_124_SOC=y
CONFIG_ARCH_UNIPHIER=y
CONFIG_ARCH_U8500=y
CONFIG_MACH_HREFV60=y
@@ -113,19 +105,13 @@ CONFIG_ARCH_VEXPRESS=y
CONFIG_ARCH_VEXPRESS_TC2_PM=y
CONFIG_ARCH_WM8850=y
CONFIG_ARCH_ZYNQ=y
-CONFIG_TRUSTED_FOUNDATIONS=y
-CONFIG_PCI=y
-CONFIG_PCI_HOST_GENERIC=y
CONFIG_PCI_KEYSTONE=y
-CONFIG_PCI_MSI=y
CONFIG_PCI_MVEBU=y
CONFIG_PCI_TEGRA=y
CONFIG_PCI_RCAR_GEN2=y
CONFIG_PCIE_RCAR=y
-CONFIG_PCIEPORTBUS=y
CONFIG_SMP=y
CONFIG_NR_CPUS=16
-CONFIG_HIGHPTE=y
CONFIG_CMA=y
CONFIG_SECCOMP=y
CONFIG_ARM_APPENDED_DTB=y
@@ -139,14 +125,14 @@ CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
+CONFIG_CPUFREQ_DT=y
CONFIG_ARM_IMX6Q_CPUFREQ=y
CONFIG_QORIQ_CPUFREQ=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
-CONFIG_NEON=y
-CONFIG_KERNEL_MODE_NEON=y
CONFIG_ARM_ZYNQ_CPUIDLE=y
CONFIG_ARM_EXYNOS_CPUIDLE=y
+CONFIG_KERNEL_MODE_NEON=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
@@ -164,22 +150,12 @@ CONFIG_IPV6_MIP6=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_NET_DSA=m
-CONFIG_NET_SWITCHDEV=y
CONFIG_CAN=y
-CONFIG_CAN_RAW=y
-CONFIG_CAN_BCM=y
-CONFIG_CAN_DEV=y
CONFIG_CAN_AT91=m
-CONFIG_CAN_RCAR=m
+CONFIG_CAN_SUN4I=y
CONFIG_CAN_XILINXCAN=y
+CONFIG_CAN_RCAR=m
CONFIG_CAN_MCP251X=y
-CONFIG_NET_DSA_BCM_SF2=m
-CONFIG_B53=m
-CONFIG_B53_SPI_DRIVER=m
-CONFIG_B53_MDIO_DRIVER=m
-CONFIG_B53_MMAP_DRIVER=m
-CONFIG_B53_SRAB_DRIVER=m
-CONFIG_CAN_SUN4I=y
CONFIG_BT=m
CONFIG_BT_MRVL=m
CONFIG_BT_MRVL_SDIO=m
@@ -194,7 +170,6 @@ CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=64
CONFIG_OMAP_OCP2SCP=y
CONFIG_SIMPLE_PM_BUS=y
-CONFIG_SUNXI_RSB=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
@@ -225,7 +200,6 @@ CONFIG_ISL29003=y
CONFIG_EEPROM_AT24=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
-CONFIG_SCSI_MULTI_LUN=y
CONFIG_ATA=y
CONFIG_SATA_AHCI=y
CONFIG_SATA_AHCI_PLATFORM=y
@@ -240,7 +214,11 @@ CONFIG_SATA_MV=y
CONFIG_SATA_RCAR=y
CONFIG_NETDEVICES=y
CONFIG_VIRTIO_NET=y
-CONFIG_HIX5HD2_GMAC=y
+CONFIG_B53_SPI_DRIVER=m
+CONFIG_B53_MDIO_DRIVER=m
+CONFIG_B53_MMAP_DRIVER=m
+CONFIG_B53_SRAB_DRIVER=m
+CONFIG_NET_DSA_BCM_SF2=m
CONFIG_SUN4I_EMAC=y
CONFIG_MACB=y
CONFIG_BCMGENET=m
@@ -248,6 +226,8 @@ CONFIG_BGMAC_BCMA=y
CONFIG_SYSTEMPORT=m
CONFIG_NET_CALXEDA_XGMAC=y
CONFIG_GIANFAR=y
+CONFIG_HIX5HD2_GMAC=y
+CONFIG_E1000E=y
CONFIG_IGB=y
CONFIG_MV643XX_ETH=y
CONFIG_MVNETA=y
@@ -257,48 +237,46 @@ CONFIG_R8169=y
CONFIG_SH_ETH=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
-CONFIG_STMMAC_PLATFORM=y
CONFIG_DWMAC_DWC_QOS_ETH=y
CONFIG_TI_CPSW=y
CONFIG_XILINX_EMACLITE=y
CONFIG_AT803X_PHY=y
-CONFIG_MARVELL_PHY=y
-CONFIG_SMSC_PHY=y
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
-CONFIG_REALTEK_PHY=y
+CONFIG_MARVELL_PHY=y
CONFIG_MICREL_PHY=y
-CONFIG_FIXED_PHY=y
+CONFIG_REALTEK_PHY=y
CONFIG_ROCKCHIP_PHY=y
+CONFIG_SMSC_PHY=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8152=m
CONFIG_USB_USBNET=y
CONFIG_USB_NET_SMSC75XX=y
CONFIG_USB_NET_SMSC95XX=y
CONFIG_BRCMFMAC=m
-CONFIG_RT2X00=m
-CONFIG_RT2800USB=m
CONFIG_MWIFIEX=m
CONFIG_MWIFIEX_SDIO=m
+CONFIG_RT2X00=m
+CONFIG_RT2800USB=m
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_QT1070=m
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_TEGRA=y
-CONFIG_KEYBOARD_SPEAR=y
+CONFIG_KEYBOARD_SAMSUNG=m
CONFIG_KEYBOARD_ST_KEYSCAN=y
+CONFIG_KEYBOARD_SPEAR=y
CONFIG_KEYBOARD_CROS_EC=m
-CONFIG_KEYBOARD_SAMSUNG=m
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_MOUSE_CYAPA=m
CONFIG_MOUSE_ELAN_I2C=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ATMEL_MXT=m
CONFIG_TOUCHSCREEN_MMS114=m
+CONFIG_TOUCHSCREEN_WM97XX=m
CONFIG_TOUCHSCREEN_ST1232=m
CONFIG_TOUCHSCREEN_STMPE=y
CONFIG_TOUCHSCREEN_SUN4I=y
-CONFIG_TOUCHSCREEN_WM97XX=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_MAX77693_HAPTIC=m
CONFIG_INPUT_MAX8997_HAPTIC=m
@@ -311,13 +289,12 @@ CONFIG_SERIAL_8250_DW=y
CONFIG_SERIAL_8250_EM=y
CONFIG_SERIAL_8250_MT6577=y
CONFIG_SERIAL_8250_UNIPHIER=y
+CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_SERIAL_ATMEL=y
CONFIG_SERIAL_ATMEL_CONSOLE=y
CONFIG_SERIAL_ATMEL_TTYAT=y
-CONFIG_SERIAL_BCM63XX=y
-CONFIG_SERIAL_BCM63XX_CONSOLE=y
CONFIG_SERIAL_MESON=y
CONFIG_SERIAL_MESON_CONSOLE=y
CONFIG_SERIAL_SAMSUNG=y
@@ -335,9 +312,10 @@ CONFIG_SERIAL_MSM=y
CONFIG_SERIAL_MSM_CONSOLE=y
CONFIG_SERIAL_VT8500=y
CONFIG_SERIAL_VT8500_CONSOLE=y
-CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
+CONFIG_SERIAL_BCM63XX=y
+CONFIG_SERIAL_BCM63XX_CONSOLE=y
CONFIG_SERIAL_XILINX_PS_UART=y
CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
CONFIG_SERIAL_FSL_LPUART=y
@@ -346,11 +324,10 @@ CONFIG_SERIAL_CONEXANT_DIGICOLOR=y
CONFIG_SERIAL_CONEXANT_DIGICOLOR_CONSOLE=y
CONFIG_SERIAL_ST_ASC=y
CONFIG_SERIAL_ST_ASC_CONSOLE=y
-CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_ST=y
CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_DAVINCI=y
-CONFIG_I2C_MUX=y
CONFIG_I2C_ARB_GPIO_CHALLENGE=m
CONFIG_I2C_MUX_PCA954x=y
CONFIG_I2C_MUX_PINCTRL=y
@@ -358,11 +335,11 @@ CONFIG_I2C_DEMUX_PINCTRL=y
CONFIG_I2C_AT91=m
CONFIG_I2C_BCM2835=y
CONFIG_I2C_CADENCE=y
+CONFIG_I2C_DAVINCI=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_DIGICOLOR=m
CONFIG_I2C_EMEV2=m
CONFIG_I2C_GPIO=m
-CONFIG_I2C_EXYNOS5=y
CONFIG_I2C_IMX=m
CONFIG_I2C_MV64XXX=y
CONFIG_I2C_RIIC=y
@@ -406,7 +383,6 @@ CONFIG_SPI_SPIDEV=y
CONFIG_SPMI=y
CONFIG_PINCTRL_AS3722=y
CONFIG_PINCTRL_PALMAS=y
-CONFIG_PINCTRL_BCM2835=y
CONFIG_PINCTRL_APQ8064=y
CONFIG_PINCTRL_APQ8084=y
CONFIG_PINCTRL_IPQ8064=y
@@ -416,24 +392,32 @@ CONFIG_PINCTRL_MSM8X74=y
CONFIG_PINCTRL_MSM8916=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
-CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_GPIO_DAVINCI=y
CONFIG_GPIO_DWAPB=y
CONFIG_GPIO_EM=y
CONFIG_GPIO_RCAR=y
+CONFIG_GPIO_SYSCON=y
CONFIG_GPIO_UNIPHIER=y
CONFIG_GPIO_XILINX=y
CONFIG_GPIO_ZYNQ=y
CONFIG_GPIO_PCA953X=y
CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_GPIO_PCF857X=y
-CONFIG_GPIO_TWL4030=y
CONFIG_GPIO_PALMAS=y
-CONFIG_GPIO_SYSCON=y
CONFIG_GPIO_TPS6586X=y
CONFIG_GPIO_TPS65910=y
+CONFIG_GPIO_TWL4030=y
+CONFIG_POWER_AVS=y
+CONFIG_ROCKCHIP_IODOMAIN=y
+CONFIG_POWER_RESET_AS3722=y
+CONFIG_POWER_RESET_GPIO=y
+CONFIG_POWER_RESET_GPIO_RESTART=y
+CONFIG_POWER_RESET_ST=y
+CONFIG_POWER_RESET_KEYSTONE=y
+CONFIG_POWER_RESET_RMOBILE=y
CONFIG_BATTERY_ACT8945A=y
CONFIG_BATTERY_SBS=y
+CONFIG_AXP20X_POWER=m
CONFIG_BATTERY_MAX17040=m
CONFIG_BATTERY_MAX17042=m
CONFIG_CHARGER_MAX14577=m
@@ -441,15 +425,6 @@ CONFIG_CHARGER_MAX77693=m
CONFIG_CHARGER_MAX8997=m
CONFIG_CHARGER_MAX8998=m
CONFIG_CHARGER_TPS65090=y
-CONFIG_AXP20X_POWER=m
-CONFIG_POWER_RESET_AS3722=y
-CONFIG_POWER_RESET_GPIO=y
-CONFIG_POWER_RESET_GPIO_RESTART=y
-CONFIG_POWER_RESET_KEYSTONE=y
-CONFIG_POWER_RESET_RMOBILE=y
-CONFIG_POWER_RESET_ST=y
-CONFIG_POWER_AVS=y
-CONFIG_ROCKCHIP_IODOMAIN=y
CONFIG_SENSORS_IIO_HWMON=y
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_LM95245=y
@@ -457,12 +432,10 @@ CONFIG_SENSORS_NTC_THERMISTOR=m
CONFIG_SENSORS_PWM_FAN=m
CONFIG_SENSORS_INA2XX=m
CONFIG_CPU_THERMAL=y
-CONFIG_BRCMSTB_THERMAL=m
CONFIG_ROCKCHIP_THERMAL=y
CONFIG_RCAR_THERMAL=y
CONFIG_ARMADA_THERMAL=y
-CONFIG_DAVINCI_WATCHDOG=m
-CONFIG_EXYNOS_THERMAL=m
+CONFIG_BRCMSTB_THERMAL=m
CONFIG_ST_THERMAL_MEMMAP=y
CONFIG_WATCHDOG=y
CONFIG_DA9063_WATCHDOG=m
@@ -470,18 +443,22 @@ CONFIG_XILINX_WATCHDOG=y
CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_AT91SAM9X_WATCHDOG=y
CONFIG_SAMA5D4_WATCHDOG=y
+CONFIG_DW_WATCHDOG=y
+CONFIG_DAVINCI_WATCHDOG=m
CONFIG_ORION_WATCHDOG=y
-CONFIG_ST_LPC_WATCHDOG=y
CONFIG_SUNXI_WATCHDOG=y
CONFIG_IMX2_WDT=y
+CONFIG_ST_LPC_WATCHDOG=y
CONFIG_TEGRA_WATCHDOG=m
CONFIG_MESON_WATCHDOG=y
-CONFIG_DW_WATCHDOG=y
CONFIG_DIGICOLOR_WATCHDOG=y
-CONFIG_BCM2835_WDT=y
CONFIG_BCM47XX_WDT=y
-CONFIG_BCM7038_WDT=m
+CONFIG_BCM2835_WDT=y
CONFIG_BCM_KONA_WDT=y
+CONFIG_BCM7038_WDT=m
+CONFIG_BCMA_HOST_SOC=y
+CONFIG_BCMA_DRIVER_GMAC_CMN=y
+CONFIG_BCMA_DRIVER_GPIO=y
CONFIG_MFD_ACT8945A=y
CONFIG_MFD_AS3711=y
CONFIG_MFD_AS3722=y
@@ -489,7 +466,6 @@ CONFIG_MFD_ATMEL_FLEXCOM=y
CONFIG_MFD_ATMEL_HLCDC=m
CONFIG_MFD_BCM590XX=y
CONFIG_MFD_AC100=y
-CONFIG_MFD_AXP20X=y
CONFIG_MFD_AXP20X_I2C=y
CONFIG_MFD_AXP20X_RSB=y
CONFIG_MFD_CROS_EC=m
@@ -502,10 +478,10 @@ CONFIG_MFD_MAX77693=m
CONFIG_MFD_MAX8907=y
CONFIG_MFD_MAX8997=y
CONFIG_MFD_MAX8998=y
-CONFIG_MFD_RK808=y
CONFIG_MFD_PM8XXX=y
CONFIG_MFD_QCOM_RPM=y
CONFIG_MFD_SPMI_PMIC=y
+CONFIG_MFD_RK808=y
CONFIG_MFD_SEC_CORE=y
CONFIG_MFD_STMPE=y
CONFIG_MFD_PALMAS=y
@@ -514,20 +490,17 @@ CONFIG_MFD_TPS65217=y
CONFIG_MFD_TPS65218=y
CONFIG_MFD_TPS6586X=y
CONFIG_MFD_TPS65910=y
-CONFIG_REGULATOR_ACT8945A=y
-CONFIG_REGULATOR_AB8500=y
CONFIG_REGULATOR_ACT8865=y
+CONFIG_REGULATOR_ACT8945A=y
CONFIG_REGULATOR_ANATOP=y
+CONFIG_REGULATOR_AB8500=y
CONFIG_REGULATOR_AS3711=y
CONFIG_REGULATOR_AS3722=y
CONFIG_REGULATOR_AXP20X=y
CONFIG_REGULATOR_BCM590XX=y
CONFIG_REGULATOR_DA9210=y
CONFIG_REGULATOR_FAN53555=y
-CONFIG_REGULATOR_RK808=y
CONFIG_REGULATOR_GPIO=y
-CONFIG_MFD_SYSCON=y
-CONFIG_POWER_RESET_SYSCON=y
CONFIG_REGULATOR_LP872X=y
CONFIG_REGULATOR_MAX14577=m
CONFIG_REGULATOR_MAX8907=y
@@ -541,7 +514,8 @@ CONFIG_REGULATOR_PALMAS=y
CONFIG_REGULATOR_PBIAS=y
CONFIG_REGULATOR_PWM=y
CONFIG_REGULATOR_QCOM_RPM=y
-CONFIG_REGULATOR_QCOM_SMD_RPM=y
+CONFIG_REGULATOR_QCOM_SMD_RPM=m
+CONFIG_REGULATOR_RK808=y
CONFIG_REGULATOR_S2MPS11=y
CONFIG_REGULATOR_S5M8767=y
CONFIG_REGULATOR_TI_ABB=y
@@ -560,18 +534,17 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y
CONFIG_MEDIA_USB_SUPPORT=y
-CONFIG_USB_VIDEO_CLASS=y
-CONFIG_USB_GSPCA=y
+CONFIG_USB_VIDEO_CLASS=m
CONFIG_V4L_PLATFORM_DRIVERS=y
CONFIG_SOC_CAMERA=m
CONFIG_SOC_CAMERA_PLATFORM=m
-CONFIG_VIDEO_RCAR_VIN=m
-CONFIG_VIDEO_ATMEL_ISI=m
CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS=m
CONFIG_VIDEO_S5P_FIMC=m
CONFIG_VIDEO_S5P_MIPI_CSIS=m
CONFIG_VIDEO_EXYNOS_FIMC_LITE=m
CONFIG_VIDEO_EXYNOS4_FIMC_IS=m
+CONFIG_VIDEO_RCAR_VIN=m
+CONFIG_VIDEO_ATMEL_ISI=m
CONFIG_V4L_MEM2MEM_DRIVERS=y
CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
@@ -582,17 +555,13 @@ CONFIG_VIDEO_STI_DELTA=m
CONFIG_VIDEO_RENESAS_JPU=m
CONFIG_VIDEO_RENESAS_VSP1=m
CONFIG_V4L_TEST_DRIVERS=y
+CONFIG_VIDEO_VIVID=m
# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
CONFIG_VIDEO_ADV7180=m
CONFIG_VIDEO_ML86V7667=m
CONFIG_DRM=y
-CONFIG_DRM_I2C_ADV7511=m
-CONFIG_DRM_I2C_ADV7511_AUDIO=y
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
-CONFIG_DRM_DUMB_VGA_DAC=m
-CONFIG_DRM_NXP_PTN3460=m
-CONFIG_DRM_PARADE_PS8622=m
CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_EXYNOS=m
CONFIG_DRM_EXYNOS_FIMD=y
@@ -610,19 +579,22 @@ CONFIG_DRM_RCAR_DU=m
CONFIG_DRM_RCAR_LVDS=y
CONFIG_DRM_SUN4I=m
CONFIG_DRM_TEGRA=y
+CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_PANEL_SAMSUNG_LD9040=m
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
-CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_DUMB_VGA_DAC=m
+CONFIG_DRM_NXP_PTN3460=m
+CONFIG_DRM_PARADE_PS8622=m
+CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_I2C_ADV7511_AUDIO=y
CONFIG_DRM_STI=m
-CONFIG_DRM_VC4=y
+CONFIG_DRM_VC4=m
CONFIG_FB_ARMCLCD=y
CONFIG_FB_EFI=y
CONFIG_FB_WM8505=y
CONFIG_FB_SH_MOBILE_LCDC=y
CONFIG_FB_SIMPLE=y
CONFIG_FB_SH_MOBILE_MERAM=y
-CONFIG_BACKLIGHT_LCD_SUPPORT=y
-CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=m
CONFIG_BACKLIGHT_PWM=y
CONFIG_BACKLIGHT_AS3711=y
@@ -653,7 +625,7 @@ CONFIG_SND_SOC_SMDK_WM8994_PCM=m
CONFIG_SND_SOC_SNOW=m
CONFIG_SND_SOC_SH4_FSI=m
CONFIG_SND_SOC_RCAR=m
-CONFIG_SND_SIMPLE_SCU_CARD=m
+CONFIG_SND_SOC_STI=m
CONFIG_SND_SUN4I_CODEC=m
CONFIG_SND_SOC_TEGRA=m
CONFIG_SND_SOC_TEGRA20_I2S=m
@@ -668,48 +640,39 @@ CONFIG_SND_SOC_TEGRA_MAX98090=m
CONFIG_SND_SOC_AK4642=m
CONFIG_SND_SOC_SGTL5000=m
CONFIG_SND_SOC_SPDIF=m
-CONFIG_SND_SOC_WM8978=m
-CONFIG_SND_SOC_STI=m
CONFIG_SND_SOC_STI_SAS=m
-CONFIG_SND_SIMPLE_CARD=m
+CONFIG_SND_SOC_WM8978=m
+CONFIG_SND_SIMPLE_SCU_CARD=m
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_MVEBU=y
-CONFIG_USB_XHCI_RCAR=m
CONFIG_USB_XHCI_TEGRA=m
CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_MSM=m
-CONFIG_USB_EHCI_EXYNOS=y
-CONFIG_USB_EHCI_TEGRA=y
CONFIG_USB_EHCI_HCD_STI=y
-CONFIG_USB_EHCI_HCD_PLATFORM=y
-CONFIG_USB_ISP1760=y
+CONFIG_USB_EHCI_TEGRA=y
+CONFIG_USB_EHCI_EXYNOS=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_STI=y
-CONFIG_USB_OHCI_HCD_PLATFORM=y
CONFIG_USB_OHCI_EXYNOS=m
CONFIG_USB_R8A66597_HCD=m
CONFIG_USB_RENESAS_USBHS=m
CONFIG_USB_STORAGE=y
CONFIG_USB_UAS=m
CONFIG_USB_MUSB_HDRC=m
-CONFIG_USB_MUSB_SUNXI=m
CONFIG_USB_DWC3=y
CONFIG_USB_DWC2=y
-CONFIG_USB_HSIC_USB3503=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_ISP1760=y
+CONFIG_USB_HSIC_USB3503=y
CONFIG_AB8500_USB=y
-CONFIG_KEYSTONE_USB_PHY=y
CONFIG_USB_GPIO_VBUS=y
CONFIG_USB_ISP1301=y
-CONFIG_USB_MSM_OTG=m
CONFIG_USB_MXS_PHY=y
CONFIG_USB_GADGET=y
CONFIG_USB_FSL_USB2=y
CONFIG_USB_RENESAS_USBHS_UDC=m
-CONFIG_USB_ETH=m
CONFIG_MMC=y
CONFIG_MMC_BLOCK_MINORS=16
CONFIG_MMC_ARMMMCI=y
@@ -721,21 +684,20 @@ CONFIG_MMC_SDHCI_OF_ESDHC=y
CONFIG_MMC_SDHCI_ESDHC_IMX=y
CONFIG_MMC_SDHCI_DOVE=y
CONFIG_MMC_SDHCI_TEGRA=y
+CONFIG_MMC_SDHCI_S3C=y
CONFIG_MMC_SDHCI_PXAV3=y
CONFIG_MMC_SDHCI_SPEAR=y
-CONFIG_MMC_SDHCI_S3C=y
CONFIG_MMC_SDHCI_S3C_DMA=y
CONFIG_MMC_SDHCI_BCM_KONA=y
+CONFIG_MMC_MESON_MX_SDIO=y
CONFIG_MMC_SDHCI_ST=y
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
CONFIG_MMC_ATMELMCI=y
CONFIG_MMC_SDHCI_MSM=y
-CONFIG_MMC_MESON_MX_SDIO=y
CONFIG_MMC_MVSDIO=y
CONFIG_MMC_SDHI=y
CONFIG_MMC_DW=y
-CONFIG_MMC_DW_PLTFM=y
CONFIG_MMC_DW_EXYNOS=y
CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SH_MMCIF=y
@@ -773,93 +735,88 @@ CONFIG_RTC_DRV_MAX77686=y
CONFIG_RTC_DRV_RK808=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_BQ32K=m
-CONFIG_RTC_DRV_PALMAS=y
-CONFIG_RTC_DRV_ST_LPC=y
CONFIG_RTC_DRV_TWL4030=y
+CONFIG_RTC_DRV_PALMAS=y
CONFIG_RTC_DRV_TPS6586X=y
CONFIG_RTC_DRV_TPS65910=y
CONFIG_RTC_DRV_S35390A=m
CONFIG_RTC_DRV_RX8581=m
CONFIG_RTC_DRV_EM3027=y
+CONFIG_RTC_DRV_S5M=m
CONFIG_RTC_DRV_DA9063=m
CONFIG_RTC_DRV_EFI=m
CONFIG_RTC_DRV_DIGICOLOR=m
-CONFIG_RTC_DRV_S5M=m
CONFIG_RTC_DRV_S3C=m
CONFIG_RTC_DRV_PL031=y
CONFIG_RTC_DRV_AT91RM9200=m
CONFIG_RTC_DRV_AT91SAM9=m
CONFIG_RTC_DRV_VT8500=y
-CONFIG_RTC_DRV_SUN6I=y
CONFIG_RTC_DRV_SUNXI=y
CONFIG_RTC_DRV_MV=y
CONFIG_RTC_DRV_TEGRA=y
+CONFIG_RTC_DRV_SNVS=y
+CONFIG_RTC_DRV_ST_LPC=y
CONFIG_DMADEVICES=y
-CONFIG_DW_DMAC=y
CONFIG_AT_HDMAC=y
CONFIG_AT_XDMAC=y
+CONFIG_DMA_BCM2835=y
+CONFIG_DMA_OMAP=y
+CONFIG_DMA_SUN6I=y
CONFIG_FSL_EDMA=y
+CONFIG_IMX_DMA=y
+CONFIG_IMX_SDMA=y
CONFIG_MV_XOR=y
+CONFIG_MXS_DMA=y
+CONFIG_PL330_DMA=y
+CONFIG_SIRF_DMA=y
+CONFIG_STE_DMA40=y
+CONFIG_ST_FDMA=m
CONFIG_TEGRA20_APB_DMA=y
+CONFIG_TI_EDMA=y
+CONFIG_XILINX_DMA=y
+CONFIG_QCOM_BAM_DMA=y
+CONFIG_DW_DMAC=y
CONFIG_SH_DMAE=y
CONFIG_RCAR_DMAC=y
CONFIG_RENESAS_USB_DMAC=m
-CONFIG_STE_DMA40=y
-CONFIG_SIRF_DMA=y
-CONFIG_TI_EDMA=y
-CONFIG_PL330_DMA=y
-CONFIG_IMX_SDMA=y
-CONFIG_IMX_DMA=y
-CONFIG_MXS_DMA=y
-CONFIG_DMA_BCM2835=y
-CONFIG_DMA_OMAP=y
-CONFIG_QCOM_BAM_DMA=y
-CONFIG_XILINX_DMA=y
-CONFIG_DMA_SUN6I=y
-CONFIG_ST_FDMA=m
+CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_MMIO=y
CONFIG_STAGING=y
-CONFIG_SENSORS_ISL29018=y
-CONFIG_SENSORS_ISL29028=y
CONFIG_MFD_NVEC=y
CONFIG_KEYBOARD_NVEC=y
CONFIG_SERIO_NVEC_PS2=y
CONFIG_NVEC_POWER=y
CONFIG_NVEC_PAZ00=y
-CONFIG_BCMA=y
-CONFIG_BCMA_HOST_SOC=y
-CONFIG_BCMA_DRIVER_GMAC_CMN=y
-CONFIG_BCMA_DRIVER_GPIO=y
-CONFIG_QCOM_GSBI=y
-CONFIG_QCOM_PM=y
-CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD_RPM=y
-CONFIG_QCOM_SMP2P=y
-CONFIG_QCOM_SMSM=y
-CONFIG_QCOM_WCNSS_CTRL=m
-CONFIG_ROCKCHIP_PM_DOMAINS=y
-CONFIG_COMMON_CLK_QCOM=y
-CONFIG_QCOM_CLK_RPM=y
-CONFIG_CHROME_PLATFORMS=y
CONFIG_STAGING_BOARD=y
CONFIG_CROS_EC_CHARDEV=m
CONFIG_COMMON_CLK_MAX77686=y
CONFIG_COMMON_CLK_RK808=m
CONFIG_COMMON_CLK_S2MPS11=m
+CONFIG_COMMON_CLK_QCOM=y
+CONFIG_QCOM_CLK_RPM=y
CONFIG_APQ_MMCC_8084=y
CONFIG_MSM_GCC_8660=y
CONFIG_MSM_MMCC_8960=y
CONFIG_MSM_MMCC_8974=y
-CONFIG_HWSPINLOCK_QCOM=y
+CONFIG_BCM2835_MBOX=y
CONFIG_ROCKCHIP_IOMMU=y
CONFIG_TEGRA_IOMMU_GART=y
CONFIG_TEGRA_IOMMU_SMMU=y
CONFIG_REMOTEPROC=m
CONFIG_ST_REMOTEPROC=m
CONFIG_RPMSG_VIRTIO=m
+CONFIG_RASPBERRYPI_POWER=y
+CONFIG_QCOM_GSBI=y
+CONFIG_QCOM_PM=y
+CONFIG_QCOM_SMD_RPM=m
+CONFIG_QCOM_WCNSS_CTRL=m
+CONFIG_ROCKCHIP_PM_DOMAINS=y
+CONFIG_ARCH_TEGRA_2x_SOC=y
+CONFIG_ARCH_TEGRA_3x_SOC=y
+CONFIG_ARCH_TEGRA_114_SOC=y
+CONFIG_ARCH_TEGRA_124_SOC=y
CONFIG_PM_DEVFREQ=y
CONFIG_ARM_TEGRA_DEVFREQ=m
-CONFIG_MEMORY=y
-CONFIG_EXTCON=y
CONFIG_TI_AEMIF=y
CONFIG_IIO=y
CONFIG_IIO_SW_TRIGGER=y
@@ -871,48 +828,46 @@ CONFIG_VF610_ADC=m
CONFIG_XILINX_XADC=y
CONFIG_MPU3050_I2C=y
CONFIG_CM36651=m
+CONFIG_SENSORS_ISL29018=y
+CONFIG_SENSORS_ISL29028=y
CONFIG_AK8975=y
-CONFIG_RASPBERRYPI_POWER=y
CONFIG_IIO_HRTIMER_TRIGGER=y
CONFIG_PWM=y
CONFIG_PWM_ATMEL=m
CONFIG_PWM_ATMEL_HLCDC_PWM=m
CONFIG_PWM_ATMEL_TCB=m
+CONFIG_PWM_BCM2835=y
+CONFIG_PWM_BRCMSTB=m
CONFIG_PWM_FSL_FTM=m
CONFIG_PWM_RENESAS_TPU=y
CONFIG_PWM_ROCKCHIP=m
CONFIG_PWM_SAMSUNG=m
+CONFIG_PWM_STI=y
CONFIG_PWM_SUN4I=y
CONFIG_PWM_TEGRA=y
CONFIG_PWM_VT8500=y
+CONFIG_KEYSTONE_IRQ=y
+CONFIG_PHY_SUN4I_USB=y
+CONFIG_PHY_SUN9I_USB=y
CONFIG_PHY_HIX5HD2_SATA=y
-CONFIG_E1000E=y
-CONFIG_PWM_STI=y
-CONFIG_PWM_BCM2835=y
-CONFIG_PWM_BRCMSTB=m
-CONFIG_OMAP_USB2=y
-CONFIG_TI_PIPE3=y
-CONFIG_PHY_BERLIN_USB=y
CONFIG_PHY_BERLIN_SATA=y
+CONFIG_PHY_BERLIN_USB=y
+CONFIG_PHY_QCOM_APQ8064_SATA=m
+CONFIG_PHY_RCAR_GEN2=m
CONFIG_PHY_ROCKCHIP_DP=m
CONFIG_PHY_ROCKCHIP_USB=y
-CONFIG_PHY_QCOM_APQ8064_SATA=m
+CONFIG_PHY_SAMSUNG_USB2=m
CONFIG_PHY_MIPHY28LP=y
-CONFIG_PHY_RCAR_GEN2=m
CONFIG_PHY_STIH407_USB=y
-CONFIG_PHY_SUN4I_USB=y
-CONFIG_PHY_SUN9I_USB=y
-CONFIG_PHY_SAMSUNG_USB2=m
CONFIG_PHY_TEGRA_XUSB=y
-CONFIG_PHY_BRCM_SATA=y
-CONFIG_NVMEM=y
+CONFIG_OMAP_USB2=y
+CONFIG_TI_PIPE3=y
CONFIG_NVMEM_SUNXI_SID=y
-CONFIG_BCM2835_MBOX=y
CONFIG_RASPBERRYPI_FIRMWARE=y
-CONFIG_EFI_VARS=m
-CONFIG_EFI_CAPSULE_LOADER=m
CONFIG_BCM47XX_NVRAM=y
CONFIG_BCM47XX_SPROM=y
+CONFIG_EFI_VARS=m
+CONFIG_EFI_CAPSULE_LOADER=m
CONFIG_EXT4_FS=y
CONFIG_AUTOFS4_FS=y
CONFIG_MSDOS_FS=y
@@ -920,7 +875,6 @@ CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_UBIFS_FS=y
-CONFIG_TMPFS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_LZO=y
CONFIG_SQUASHFS_XZ=y
@@ -936,13 +890,7 @@ CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_UTF8=y
CONFIG_PRINTK_TIME=y
-CONFIG_DEBUG_FS=y
CONFIG_MAGIC_SYSRQ=y
-CONFIG_LOCKUP_DETECTOR=y
-CONFIG_CPUFREQ_DT=y
-CONFIG_KEYSTONE_IRQ=y
-CONFIG_HW_RANDOM=y
-CONFIG_HW_RANDOM_ST=y
CONFIG_CRYPTO_USER=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
@@ -951,27 +899,19 @@ CONFIG_CRYPTO_USER_API_AEAD=m
CONFIG_CRYPTO_DEV_MARVELL_CESA=m
CONFIG_CRYPTO_DEV_EXYNOS_RNG=m
CONFIG_CRYPTO_DEV_S5P=m
+CONFIG_CRYPTO_DEV_ATMEL_AES=m
+CONFIG_CRYPTO_DEV_ATMEL_TDES=m
+CONFIG_CRYPTO_DEV_ATMEL_SHA=m
CONFIG_CRYPTO_DEV_SUN4I_SS=m
CONFIG_CRYPTO_DEV_ROCKCHIP=m
CONFIG_ARM_CRYPTO=y
-CONFIG_CRYPTO_SHA1_ARM=m
CONFIG_CRYPTO_SHA1_ARM_NEON=m
CONFIG_CRYPTO_SHA1_ARM_CE=m
CONFIG_CRYPTO_SHA2_ARM_CE=m
-CONFIG_CRYPTO_SHA256_ARM=m
CONFIG_CRYPTO_SHA512_ARM=m
CONFIG_CRYPTO_AES_ARM=m
CONFIG_CRYPTO_AES_ARM_BS=m
CONFIG_CRYPTO_AES_ARM_CE=m
-CONFIG_CRYPTO_CHACHA20_NEON=m
-CONFIG_CRYPTO_CRC32_ARM_CE=m
-CONFIG_CRYPTO_CRCT10DIF_ARM_CE=m
CONFIG_CRYPTO_GHASH_ARM_CE=m
-CONFIG_CRYPTO_DEV_ATMEL_AES=m
-CONFIG_CRYPTO_DEV_ATMEL_TDES=m
-CONFIG_CRYPTO_DEV_ATMEL_SHA=m
-CONFIG_VIDEO_VIVID=m
-CONFIG_VIRTIO=y
-CONFIG_VIRTIO_PCI=y
-CONFIG_VIRTIO_PCI_LEGACY=y
-CONFIG_VIRTIO_MMIO=y
+CONFIG_CRYPTO_CRC32_ARM_CE=m
+CONFIG_CRYPTO_CHACHA20_NEON=m
--
2.14.1
^ permalink raw reply related
* [PATCH V3] ARM: imx: use outer_disable/resume for low power
From: Peng Fan @ 2017-12-28 9:09 UTC (permalink / raw)
To: linux-arm-kernel
Use outer_disable/resume for suspend/resume and low power idle.
With the two APIs used, code could be easy to extend to introduce
l2c_write_sec for i.MX platforms when moving Linux Kernel
runs in non-secure world.
The cache sync operation and l2c310_early_resume in suspend-imx6.S
are kept. According to PL310 TRM for dormant mode: "The external
power controller asserts the reset. Ensure the cache controller
is placed back into run mode prior to the L1 masters.". So keep
l2c310_early_resume.
Another reason is alought L2 controller lose power, L2 memory not lose
power. If l2c310_early_resume removed, outer_resume will do invalidation
which may corrupt data. To keep safe, the cache sync operation is also
kept.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Russell King <linux@armlinux.org.uk>
---
V3:
Continue fix 6SX low power idle. Because L2 memory not lose power,
outer_disable seems not clearly flush all the data or flush l1 -> flush l2
->cache sync must be followed, outer_resume will invalidate
the cache, which corrupt data and cause issues. So in V3, only
add outer_disable/resume to make it simple.
Add more commit log.
Based on Shawn/for-next.
V2:
Fix 6SX booting. The V1 patch does not take 6SX low power idle into
consideration.
arch/arm/mach-imx/cpuidle-imx6sx.c | 2 ++
arch/arm/mach-imx/pm-imx6.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/mach-imx/cpuidle-imx6sx.c b/arch/arm/mach-imx/cpuidle-imx6sx.c
index c5a5c3a70ab1..b35841d133dc 100644
--- a/arch/arm/mach-imx/cpuidle-imx6sx.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sx.c
@@ -49,7 +49,9 @@ static int imx6sx_enter_wait(struct cpuidle_device *dev,
cpu_pm_enter();
cpu_cluster_pm_enter();
+ outer_disable();
cpu_suspend(0, imx6sx_idle_finish);
+ outer_resume();
cpu_cluster_pm_exit();
cpu_pm_exit();
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index ecdf071653d4..153a0afc7645 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -392,8 +392,10 @@ static int imx6q_pm_enter(suspend_state_t state)
imx6_enable_rbc(true);
imx_gpc_pre_suspend(true);
imx_anatop_pre_suspend();
+ outer_disable();
/* Zzz ... */
cpu_suspend(0, imx6q_suspend_finish);
+ outer_resume();
if (cpu_is_imx6q() || cpu_is_imx6dl())
imx_smp_prepare();
imx_anatop_post_resume();
--
2.14.1
^ permalink raw reply related
* [GIT PULL] Allwinner clock changes for 4.16
From: Chen-Yu Tsai @ 2017-12-28 8:25 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.16
for you to fetch changes up to e952ca3c6b2ffdfbf9618e4bd3e9aad1ff3f5eb4:
clk: sunxi-ng: sun8i: a83t: Use sigma-delta modulation for audio PLL (2017-12-08 10:08:32 +0100)
----------------------------------------------------------------
Allwinner clock changes for 4.16
Fixed-post-divider support is added for two types of our clocks.
This in turn is used to support odd clocks on some of our SoCs.
On the A64, the MMC module clocks have a hidden post-divider.
On the A83T, a post-divider is needed to support programming
sigma-delta modulation with known fixed parameters from the
BSP kernel for the audio PLL.
There's also a small cleanup to use the shorter PTR_ERR_OR_ZERO
macro in various functions.
----------------------------------------------------------------
Chen-Yu Tsai (5):
clk: sunxi-ng: Support fixed post-dividers on MP style clocks
clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks
clk: sunxi-ng: Support fixed post-dividers on NM style clocks
clk: sunxi-ng: sun8i: a83t: Add /2 fixed post divider to audio PLL
clk: sunxi-ng: sun8i: a83t: Use sigma-delta modulation for audio PLL
Vasyl Gomonovych (1):
clk: sunxi: Use PTR_ERR_OR_ZERO()
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 +++++++++++++++++++++++------------
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 18 +++++++++--
drivers/clk/sunxi-ng/ccu_mp.c | 20 ++++++++++--
drivers/clk/sunxi-ng/ccu_mp.h | 24 +++++++++++++++
drivers/clk/sunxi-ng/ccu_nm.c | 50 ++++++++++++++++++++++--------
drivers/clk/sunxi-ng/ccu_nm.h | 2 ++
drivers/clk/sunxi/clk-sun8i-apb0.c | 5 +--
7 files changed, 134 insertions(+), 42 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171228/6a97397e/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: pxa: ulpi: fix ulpi timeout and slowpath warn
From: Robert Jarzmik @ 2017-12-28 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226133253.11653-1-grinberg@compulab.co.il>
Igor Grinberg <grinberg@compulab.co.il> writes:
> Both cm-x300 and pxa3xx-ulpi use the plain clk_{en,dis}able() API.
> With the new clocking framework this results in warnings of type:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:714 clk_core_enable+0x90/0x9c
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc5-cm-x300+ #15
> Hardware name: CM-X300 module
> [<c001007c>] (unwind_backtrace) from [<c000df94>] (show_stack+0x10/0x14)
> [<c000df94>] (show_stack) from [<c00199a8>] (__warn+0xd8/0x100)
> [<c00199a8>] (__warn) from [<c0019a0c>] (warn_slowpath_null+0x3c/0x48)
> [<c0019a0c>] (warn_slowpath_null) from [<c024e8c0>] (clk_core_enable+0x90/0x9c)
> [<c024e8c0>] (clk_core_enable) from [<c024ea54>] (clk_core_enable_lock+0x18/0x2c)
> [<c024ea54>] (clk_core_enable_lock) from [<c0016994>] (cm_x300_u2d_init+0x4c/0xe8)
> [<c0016994>] (cm_x300_u2d_init) from [<c00163e0>] (pxa3xx_u2d_probe+0xe0/0x244)
> [<c00163e0>] (pxa3xx_u2d_probe) from [<c0283de0>] (platform_drv_probe+0x38/0x88)
> ...
> ------------[ cut here ]------------
> and alike...
>
> And finally, it results in:
> ------------[ cut here ]------------
> pxa310_ulpi_poll: ULPI access timed out!
> OTG transceiver init failed
> ------------[ cut here ]------------
>
> It might be that disabling the warning in kernel config would also do
> the job, but IMO a better solution would be to switch to
> clk_prepare_enable() and clk_disable_unprepare() APIs.
>
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Applied to pxa/for-next, thanks.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] clk: pxa: unbreak lookup of CLK_POUT
From: Robert Jarzmik @ 2017-12-28 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226133036.11432-1-grinberg@compulab.co.il>
Igor Grinberg <grinberg@compulab.co.il> writes:
> Since switching to clk drivers, the CLK_POUT cannot be searched for by
> clk_get() API and thus it returns with ENOENT.
> Register it with the clk_lookup and thus unbreak the users of it.
>
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cheers.
--
Robert
^ 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