* [RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
From: zhongjiang @ 2016-12-14 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725151-20549-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the
fuctions should not be use. therefore, we add the dependency.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..694ca73 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -640,6 +640,7 @@ config SYS_SUPPORTS_HUGETLBFS
config ARCH_WANT_HUGE_PMD_SHARE
def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
+ depends on HUGETLB_PAGE
config ARCH_HAS_CACHE_LINE_SIZE
def_bool y
--
1.8.3.1
^ permalink raw reply related
* [PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method
From: gabriel.fernandez at st.com @ 2016-12-14 14:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
Clock and reset controller use same compatible strings (same IP).
Since commit 989eafd0b609 ("clk: core: Avoid double initialization of
clocks") the OF core flags clock controllers registered with the
CLK_OF_DECLARE() macro as OF_POPULATED, so platform devices with the same
compatible string will not be registered.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
drivers/clk/clk-stm32f4.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 11174a5..0f5ab9b 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -1325,5 +1325,5 @@ static void __init stm32f4_rcc_init(struct device_node *np)
kfree(clks);
iounmap(base);
}
-CLK_OF_DECLARE(stm32f42xx_rcc, "st,stm32f42xx-rcc", stm32f4_rcc_init);
-CLK_OF_DECLARE(stm32f46xx_rcc, "st,stm32f469-rcc", stm32f4_rcc_init);
+CLK_OF_DECLARE_DRIVER(stm32f42xx_rcc, "st,stm32f42xx-rcc", stm32f4_rcc_init);
+CLK_OF_DECLARE_DRIVER(stm32f46xx_rcc, "st,stm32f469-rcc", stm32f4_rcc_init);
--
1.9.1
^ permalink raw reply related
* [PATCH] dt-bindings: mfd: stm32f429: Add QSPI & DSI constants into DT include file
From: gabriel.fernandez at st.com @ 2016-12-14 14:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
It will be used by clock and reset drivers, and DT bindings.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
include/dt-bindings/mfd/stm32f4-rcc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
index e98942d..315f6c3 100644
--- a/include/dt-bindings/mfd/stm32f4-rcc.h
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -40,6 +40,7 @@
/* AHB3 */
#define STM32F4_RCC_AHB3_FMC 0
+#define STM32F4_RCC_AHB3_QSPI 1
#define STM32F4_AHB3_RESET(bit) (STM32F4_RCC_AHB3_##bit + (0x18 * 8))
#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + (0x38 * 8))
@@ -91,6 +92,7 @@
#define STM32F4_RCC_APB2_SPI6 21
#define STM32F4_RCC_APB2_SAI1 22
#define STM32F4_RCC_APB2_LTDC 26
+#define STM32F4_RCC_APB2_DSI 27
#define STM32F4_APB2_RESET(bit) (STM32F4_RCC_APB2_##bit + (0x24 * 8))
#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + (0x44 * 8))
--
1.9.1
^ permalink raw reply related
* [PATCH] pinctrl: stm32: activate strict mux mode
From: gabriel.fernandez at st.com @ 2016-12-14 14:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This activates strict mode muxing for the STM32 pin controllers,
as these do not allow GPIO and functions to use the same pin
simultaneously.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
drivers/pinctrl/stm32/pinctrl-stm32.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index efc4371..c983a1e 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -631,6 +631,7 @@ static int stm32_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
.get_function_groups = stm32_pmx_get_func_groups,
.set_mux = stm32_pmx_set_mux,
.gpio_set_direction = stm32_pmx_gpio_set_direction,
+ .strict = true,
};
/* Pinconf functions */
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a3179721-3a0e-651b-f422-c08463aae7e6@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>
> Hello Bartlomiej,
>
> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >> Hello Bartlomiej,
> >
> > Hi,
> >
> >> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>> cooling maps to account for new OPPs.
> >>>
> >>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>
> >>> Tested on Odroid-XU3 and XU3 Lite.
> >>>
> >>> Cc: Doug Anderson <dianders@chromium.org>
> >>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>> Cc: Andreas Faerber <afaerber@suse.de>
> >>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>> ---
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -118,7 +118,7 @@
> >>> /*
> >>> * When reaching cpu_alert3, reduce CPU
> >>> * by 2 steps. On Exynos5422/5800 that would
> >>> - * be: 1600 MHz and 1100 MHz.
> >>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>> */
> >>> map3 {
> >>> trip = <&cpu_alert3>;
> >>> @@ -131,16 +131,16 @@
> >>>
> >>> /*
> >>> * When reaching cpu_alert4, reduce CPU
> >>> - * further, down to 600 MHz (11 steps for big,
> >>> - * 7 steps for LITTLE).
> >>> + * further, down to 600 MHz (13 steps for big,
> >>> + * 8 steps for LITTLE).
> >>> */
> >>> - map5 {
> >>> + cooling_map5: map5 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu0 3 7>;
> >>> + cooling-device = <&cpu0 3 8>;
> >>> };
> >>> - map6 {
> >>> + cooling_map6: map6 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu4 3 11>;
> >>> + cooling-device = <&cpu4 3 13>;
> >>> };
> >>> };
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -21,6 +21,23 @@
> >>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>> };
> >>>
> >>> +&cluster_a15_opp_table {
> >>> + /delete-node/opp at 2000000000;
> >>> + /delete-node/opp at 1900000000;
> >>> +};
> >>> +
> >>> +&cluster_a7_opp_table {
> >>> + /delete-node/opp at 1400000000;
> >>> +};
> >>> +
> >>
> >> I think that a comment in the DTS why these operating points aren't available
> >> in this board will make more clear why the nodes are being deleted.
> >
> > Ok, I will add these comments in the next patch revision.
> >
> >>> +&cooling_map5 {
> >>> + cooling-device = <&cpu0 3 7>;
> >>> +};
> >>> +
> >>> +&cooling_map6 {
> >>> + cooling-device = <&cpu4 3 11>;
> >>> +};
> >>> +
> >>> &pwm {
> >>> /*
> >>> * PWM 0 -- fan
> >>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -146,6 +146,10 @@
> >>> vdd-supply = <&ldo9_reg>;
> >>> };
> >>>
> >>> +&cluster_a7_opp_table {
> >>> + /delete-property/opp at 1400000000;
> >>> +};
> >>> +
> >>> &cpu0 {
> >>> cpu-supply = <&buck2_reg>;
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -24,6 +24,16 @@
> >>> };
> >>>
> >>> &cluster_a15_opp_table {
> >>> + opp at 2000000000 {
> >>> + opp-hz = /bits/ 64 <2000000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> + opp at 1900000000 {
> >>> + opp-hz = /bits/ 64 <1900000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> opp at 1700000000 {
> >>> opp-microvolt = <1250000>;
> >>> };
> >>> @@ -85,6 +95,11 @@
> >>> };
> >>>
> >>
> >> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >> INT rail would need to be scaled up as well since there's a maximum voltage
> >> difference between the ARM and INT rails before the system becomes unstable:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >> https://lkml.org/lkml/2014/5/2/419
> >>
> >> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >> the maximum voltage skew is between a limit. But that never made to mainline:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >> https://lkml.org/lkml/2014/4/29/28
> >>
> >> Did that change and there's infrastructure in mainline now to cope with that?
> >> If that's the case, I think it would be good to mention in the commit message.
> >
> > I was not aware of this limitation and AFAIK mainline has currently
> > no code to handle it. I also cannot find any code to handle this in
>
> Yes, that's what I thought as well but maybe I was missing something.
>
> > Hardkernel's vendor kernel for Odroid-XU3 board.
> >
> > Do you know whether this problem exists also on Exynos5422/5800
> > SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> > regulator code also on Exynos5800 SoC based Peach Pi board but was
> > the problem actually present on this board?
> >
>
> My understanding is that this problem is present in 5420/5422/5800
> but I have no way to confirm this. I'm just guessing from the info
> in the ChromiumOS vendor tree.
>
> If you look at the commit that added the regulator-locker driver,
> the test says to be done in a Peach Pi so it seems the problem is
> not restricted to only Exynos5420:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>
> > [ I added Arjun to Cc:, maybe he can help in explaining this issue
> > (unfortunately Inderpal's email is no longer working). ]
> >
>
> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
Abhilash's email is also no longer valid.. :(
> > Please also note that on Exynos5422/5800 SoCs the same ARM rail
> > voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> > IOW if the problem exists it is already present in the mainline
> > kernel.
> >
>
> Ah, I only looked at your patch and I didn't compare the voltage levels
> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>
> I wonder if the voltage levels in your patch are correct then, since the
> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>
> /*
> * Default ASV table
> */
> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> 1362500, /* L0 2100 */
> 1312500, /* L1 2000 */
> 1275000, /* L2 1900 */
> 1225000, /* L3 1800 */
> 1200000, /* L4 1700 */
>
> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
I think that the above voltages are original ones for Exynos5420
(not for Exynos5422/5800).
The voltages in my patch were taken from Hardkernel's kernel for
Odroid-XU3:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1250000, /* L4 2000 */
1250000, /* L5 1900 */
1250000, /* L6 1800 */
...
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* jemalloc testsuite stalls in memset
From: Andreas Schwab @ 2016-12-14 14:34 UTC (permalink / raw)
To: linux-arm-kernel
When running the jemalloc-4.4.0 testsuite on aarch64 with glibc 2.24 the
test/unit/junk test hangs in memset:
(gdb) r
Starting program: /tmp/jemalloc/jemalloc-4.4.0/test/unit/junk
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
test_junk_small: pass
test_junk_large: pass
^C
Program received signal SIGINT, Interrupt.
memset () at ../sysdeps/aarch64/memset.S:91
91 str q0, [dstin]
(gdb) x/i $pc
=> 0xffffb7ddf54c <memset+140>: str q0, [x0]
x0 is pointing to the start of this mmap'd block:
0xffffb7400000 0xffffb7600000 0x200000 0x0
Any attempt to contine execution or step over the insn still causes the
process to hang here. Only after accessing the memory through the
debugger the test successfully continues to completion.
The kernel has been configured with transparent hugepages.
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_TRANSPARENT_HUGE_PAGECACHE=y
This issue has been bisected to commit
b8d3c4c3009d42869dc03a1da0efc2aa687d0ab4 ("mm/huge_memory.c: don't split
THP page when MADV_FREE syscall is called").
Andreas.
--
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3539351.vsrnVhEgRT@amdc3058>
Hello Bartlomiej,
On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>
>> Hello Bartlomiej,
>>
>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>> Hello Bartlomiej,
>>>
>>> Hi,
>>>
>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>> cooling maps to account for new OPPs.
>>>>>
>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>
>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>
>>>>> Cc: Doug Anderson <dianders@chromium.org>
>>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>>>> Cc: Andreas Faerber <afaerber@suse.de>
>>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -118,7 +118,7 @@
>>>>> /*
>>>>> * When reaching cpu_alert3, reduce CPU
>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>> */
>>>>> map3 {
>>>>> trip = <&cpu_alert3>;
>>>>> @@ -131,16 +131,16 @@
>>>>>
>>>>> /*
>>>>> * When reaching cpu_alert4, reduce CPU
>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>> - * 7 steps for LITTLE).
>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>> + * 8 steps for LITTLE).
>>>>> */
>>>>> - map5 {
>>>>> + cooling_map5: map5 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu0 3 7>;
>>>>> + cooling-device = <&cpu0 3 8>;
>>>>> };
>>>>> - map6 {
>>>>> + cooling_map6: map6 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu4 3 11>;
>>>>> + cooling-device = <&cpu4 3 13>;
>>>>> };
>>>>> };
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -21,6 +21,23 @@
>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>> };
>>>>>
>>>>> +&cluster_a15_opp_table {
>>>>> + /delete-node/opp at 2000000000;
>>>>> + /delete-node/opp at 1900000000;
>>>>> +};
>>>>> +
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-node/opp at 1400000000;
>>>>> +};
>>>>> +
>>>>
>>>> I think that a comment in the DTS why these operating points aren't available
>>>> in this board will make more clear why the nodes are being deleted.
>>>
>>> Ok, I will add these comments in the next patch revision.
>>>
>>>>> +&cooling_map5 {
>>>>> + cooling-device = <&cpu0 3 7>;
>>>>> +};
>>>>> +
>>>>> +&cooling_map6 {
>>>>> + cooling-device = <&cpu4 3 11>;
>>>>> +};
>>>>> +
>>>>> &pwm {
>>>>> /*
>>>>> * PWM 0 -- fan
>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -146,6 +146,10 @@
>>>>> vdd-supply = <&ldo9_reg>;
>>>>> };
>>>>>
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-property/opp at 1400000000;
>>>>> +};
>>>>> +
>>>>> &cpu0 {
>>>>> cpu-supply = <&buck2_reg>;
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -24,6 +24,16 @@
>>>>> };
>>>>>
>>>>> &cluster_a15_opp_table {
>>>>> + opp at 2000000000 {
>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> + opp at 1900000000 {
>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> opp at 1700000000 {
>>>>> opp-microvolt = <1250000>;
>>>>> };
>>>>> @@ -85,6 +95,11 @@
>>>>> };
>>>>>
>>>>
>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>> https://lkml.org/lkml/2014/5/2/419
>>>>
>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>> https://lkml.org/lkml/2014/4/29/28
>>>>
>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>> If that's the case, I think it would be good to mention in the commit message.
>>>
>>> I was not aware of this limitation and AFAIK mainline has currently
>>> no code to handle it. I also cannot find any code to handle this in
>>
>> Yes, that's what I thought as well but maybe I was missing something.
>>
>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>
>>> Do you know whether this problem exists also on Exynos5422/5800
>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>> the problem actually present on this board?
>>>
>>
>> My understanding is that this problem is present in 5420/5422/5800
>> but I have no way to confirm this. I'm just guessing from the info
>> in the ChromiumOS vendor tree.
>>
>> If you look at the commit that added the regulator-locker driver,
>> the test says to be done in a Peach Pi so it seems the problem is
>> not restricted to only Exynos5420:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>> (unfortunately Inderpal's email is no longer working). ]
>>>
>>
>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>
> Abhilash's email is also no longer valid.. :(
>
Yes, I noticed that as well :(
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>>
>>
>> Ah, I only looked at your patch and I didn't compare the voltage levels
>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>
>> I wonder if the voltage levels in your patch are correct then, since the
>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>
>> /*
>> * Default ASV table
>> */
>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>> 1362500, /* L0 2100 */
>> 1312500, /* L1 2000 */
>> 1275000, /* L2 1900 */
>> 1225000, /* L3 1800 */
>> 1200000, /* L4 1700 */
>>
>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>
> I think that the above voltages are original ones for Exynos5420
> (not for Exynos5422/5800).
>
In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
> The voltages in my patch were taken from Hardkernel's kernel for
> Odroid-XU3:
>
> /*
> * ASV group voltage table
> */
> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> ...
> 1250000, /* L4 2000 */
> 1250000, /* L5 1900 */
> 1250000, /* L6 1800 */
> ...
>
> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>
In general I prefer to use the ChromiumOS tree as a reference instead of the
HardKernel one, since the former is in a much better shape IMHO.
I think is worth to check in a kernel tree in http://opensource.samsung.com/
for a product that's Exynos5422/5800 based.
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT
From: Ard Biesheuvel @ 2016-12-14 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725151-20549-2-git-send-email-zhongjiang@huawei.com>
On 14 December 2016 at 14:19, zhongjiang <zhongjiang@huawei.com> wrote:
> From: zhong jiang <zhongjiang@huawei.com>
>
> I think that CONT_PTE_SHIFT is more reasonable even if they are some
> value. and the patch is not any functional change.
>
This may be the case for 64k pages, but not for 16k pages, and I
actually think add_default_hugepagesz() could be made unconditional,
given that both 64k on 4k kernels and 2 MB on 16k kernels are useful
hugepage sizes that are not otherwise available by default.
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/mm/hugetlbpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 2e49bd2..0a4c97b 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -323,7 +323,7 @@ static __init int setup_hugepagesz(char *opt)
> static __init int add_default_hugepagesz(void)
> {
> if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL)
> - hugetlb_add_hstate(CONT_PMD_SHIFT);
> + hugetlb_add_hstate(CONT_PTE_SHIFT);
> return 0;
> }
> arch_initcall(add_default_hugepagesz);
> --
> 1.8.3.1
>
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Emmanuel Vadot @ 2016-12-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel
The node name for the power seq pin is mmc2 at 0 like the mmc2_pins_a one.
This makes the original node (mmc2_pins_a) scrapped out of the dtb and
result in a unusable eMMC if U-Boot didn't configured the pins to the
correct functions.
Changes since v1:
* Rename the node mmc2-rst-pin
Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
index 5ea4915..10d3074 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
@@ -56,7 +56,7 @@
};
&pio {
- mmc2_pins_nrst: mmc2 at 0 {
+ mmc2_pins_nrst: mmc2-rst-pin {
allwinner,pins = "PC16";
allwinner,function = "gpio_out";
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
--
2.9.2
^ permalink raw reply related
* [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.
From: Rob (William) Rice @ 2016-12-14 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612110810.BEVbRp0B%fengguang.wu@intel.com>
I will rebase to Herbert's latest when I submit v3 to address Mark
Rutland's DT comments (and any others that come in).
Rob
On 12/10/2016 7:14 PM, kbuild test robot wrote:
> Hi Rob,
>
> [auto build test ERROR on cryptodev/master]
> [also build test ERROR on v4.9-rc8]
> [cannot apply to next-20161209]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Rob-Rice/crypto-brcm-DT-documentation-for-Broadcom-SPU-driver/20161202-010038
> base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: Input tree has errors, aborting (use -f to force output)
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCHv6] support for AD5820 camera auto-focus coil
From: Tony Lindgren @ 2016-12-14 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612141438.16603@pali>
* Pali Roh?r <pali.rohar@gmail.com> [161214 05:38]:
> On Monday 08 August 2016 23:41:32 Pavel Machek wrote:
> > On Mon 2016-08-08 11:09:56, Sakari Ailus wrote:
> > > On Fri, Aug 05, 2016 at 12:26:11PM +0200, Pavel Machek wrote:
> > > > This adds support for AD5820 autofocus coil, found for example in
> > > > Nokia N900 smartphone.
> > >
> > > Thanks, Pavel!
> > >
> > > Let's use V4L2_CID_FOCUS_ABSOLUTE, as is in the patch. If we get
> > > something better in the future, we'll switch to that then.
> > >
> > > I've applied this to ad5820 branch in my tree.
> >
> > Thanks. If I understands things correctly, both DTS patch and this
> > patch are waiting in your tree, so we should be good to go for 4.9
> > (unless some unexpected problems surface)?
> >
> > Best regards,
> > Pavel
>
> Was DTS patch merged into 4.9? At least I do not see updated that dts
> file omap3-n900.dts in linus tree...
If it's not in current mainline or next, it's off my radar so sounds
like I've somehow missed it and needs resending..
Tony
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Tony Lindgren @ 2016-12-14 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214133158.mwvs574l4otbc7hf@earth>
* Sebastian Reichel <sre@kernel.org> [161214 05:32]:
> Hi Pali & Pavel,
>
> On Wed, Dec 14, 2016 at 01:53:23PM +0100, Pavel Machek wrote:
> > > > [ 220.248596] tty ttyO1: Radio packet sent
> > > > [ 220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > [ 220.272949] tty ttyO1: wakeup received: 1 -> 0
> > > > [ 221.283477] tty ttyO1: radio packet timeout!
> > > > [ 221.283630] enqueue: hu c304cc80 skb cd4a9b40
> > > > [ 223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
> > > > pavel at n900:~$
> > >
> > > In log are still some failures, but ... is bluetooth working now?
>
> I could scan for devices. The code is still racy, though. It's
> most likely related to the newly introduced idle code. (Without
> sending the BT module to correctly idle the bcm2048 does not
> work correctly at all)
>
> I was quite busy the last few weeks and did not manage to find
> much time for kernel work. Now I will first have to catch up
> with my power-supply tree.
>
> > It is... for Sebastian. I'm playing with camera now.
> >
> > > I see that you applied this patch:
> > > https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/commit/?id=051aa3fbf03ac770d8344690f5a936a7f04c6884
> > >
> > > Looks like that pinmux is in DTS file incorrect. Can somebody verify it?
> > > Maybe Tony?
> >
> > Yes, it is. Sebastian was pretty certain about that.
>
> Yes, I'm certain. The bootloader enables the pullup resistors.
> Note, that the wrong DTS entry is not in mainline. My bluetooth
> branch has a fixed DTS patch instead of a fixup patch on top of
> the broken one:
>
> https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=nokia-bluetooth-dev&id=6b63c111a979d100cfbdd76cb4a6bbadace35216
Maybe send it so we can merge it as a fix during the early -rc
cycle?
Regards,
Tony
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-14 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214145724.42745-1-manu@bidouilliste.com>
On Wed, Dec 14, 2016 at 03:57:24PM +0100, Emmanuel Vadot wrote:
> The node name for the power seq pin is mmc2 at 0 like the mmc2_pins_a one.
> This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> result in a unusable eMMC if U-Boot didn't configured the pins to the
> correct functions.
>
> Changes since v1:
> * Rename the node mmc2-rst-pin
That changelog should be after the ---. Removed it and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/2918b004/attachment.sig>
^ permalink raw reply
* [PATCH v2 01/11] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Chen-Yu Tsai @ 2016-12-14 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-2-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This replaces calls to of_device_is_compatible to check data field of
> of_device_id matched when probing the driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Chen-Yu Tsai @ 2016-12-14 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-3-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
> and minimum current delivered by the VBUS power supply.
>
> This adds the register used by the VBUS power supply driver to the range
> of volatile and writeable regs ranges.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> added in v2
>
> drivers/mfd/axp20x.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be..6ee2cc6 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
>
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
This is already covered by the previous entry.
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> };
>
> static const struct regmap_range axp20x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
And I'm not sure why you specify it as volatile? The PMIC doesn't change any
of the bits in this register on its own.
Same for the AXP22x bits. So basically I think you don't need this patch.
ChenYu
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
> @@ -91,11 +93,13 @@ static const struct regmap_access_table axp20x_volatile_table = {
> /* AXP22x ranges are shared with the AXP809, as they cover the same range */
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
>
> static const struct regmap_range axp22x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
> regmap_reg_range(AXP20X_FG_RES, AXP20X_FG_RES),
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v2 03/11] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Chen-Yu Tsai @ 2016-12-14 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-4-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> AXP20X and AXP22X PMICs allow setting the min voltage and max current of
> VBUS power supply. This adds entries in sysfs to allow to do so.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Sebastian Reichel @ 2016-12-14 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214151056.GX4920@atomide.com>
Hi Tony,
On Wed, Dec 14, 2016 at 07:10:56AM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <sre@kernel.org> [161214 05:32]:
> > Hi Pali & Pavel,
> >
> > On Wed, Dec 14, 2016 at 01:53:23PM +0100, Pavel Machek wrote:
> > > > > [ 220.248596] tty ttyO1: Radio packet sent
> > > > > [ 220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > > [ 220.272949] tty ttyO1: wakeup received: 1 -> 0
> > > > > [ 221.283477] tty ttyO1: radio packet timeout!
> > > > > [ 221.283630] enqueue: hu c304cc80 skb cd4a9b40
> > > > > [ 223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
> > > > > pavel at n900:~$
> > > >
> > > > In log are still some failures, but ... is bluetooth working now?
> >
> > I could scan for devices. The code is still racy, though. It's
> > most likely related to the newly introduced idle code. (Without
> > sending the BT module to correctly idle the bcm2048 does not
> > work correctly at all)
> >
> > I was quite busy the last few weeks and did not manage to find
> > much time for kernel work. Now I will first have to catch up
> > with my power-supply tree.
> >
> > > It is... for Sebastian. I'm playing with camera now.
> > >
> > > > I see that you applied this patch:
> > > > https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/commit/?id=051aa3fbf03ac770d8344690f5a936a7f04c6884
> > > >
> > > > Looks like that pinmux is in DTS file incorrect. Can somebody verify it?
> > > > Maybe Tony?
> > >
> > > Yes, it is. Sebastian was pretty certain about that.
> >
> > Yes, I'm certain. The bootloader enables the pullup resistors.
> > Note, that the wrong DTS entry is not in mainline. My bluetooth
> > branch has a fixed DTS patch instead of a fixup patch on top of
> > the broken one:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=nokia-bluetooth-dev&id=6b63c111a979d100cfbdd76cb4a6bbadace35216
>
> Maybe send it so we can merge it as a fix during the early -rc
> cycle?
Sorry if I was not clear enough: mainline does *not* contain
incorrect DT information. My bluetooth RFC patches did. So
this can go into the kernel once the driver is there and
the binding got accepted.
Alternatively I can prepare a patch, which just adds the
cts/rts pinmux for the bluetooth UART, but it's not very
useful on its own.
-- Sebastian
-------------- 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/20161214/5d0c089d/attachment.sig>
^ permalink raw reply
* Linux crashes when trying to online secondary core
From: Mason @ 2016-12-14 16:01 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm seeing Linux v4.9 crash (dereferencing NULL) when I try to online
the secondary core, after putting it offline.
Perhaps commit 00c1d17aab513d3b8117fb84644eba39434b33e4 is relevant?
You will find below:
1) the full boot log
2) the defconfig I used
Note #1: I added the following patch for debugging purpose:
diff --git a/arch/arm/mach-tango/platsmp.c b/arch/arm/mach-tango/platsmp.c
index 98c62a4a8623..c6865935f21b 100644
--- a/arch/arm/mach-tango/platsmp.c
+++ b/arch/arm/mach-tango/platsmp.c
@@ -5,8 +5,14 @@
static int tango_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
+ int ret;
+ printk("%s from %pf\n", __func__, __builtin_return_address(0));
+ ret =
tango_set_aux_boot_addr(virt_to_phys(secondary_startup));
+ printk("tango_set_aux_boot_addr=%d\n", ret);
+ ret =
tango_start_aux_core(cpu);
+ printk("tango_start_aux_core=%d\n", ret);
return 0;
}
Note #2: Linux runs as untrusted OS (trustzone thing). Trusted OS
is called armor. Sometimes armor and Linux print to the console
at the same time, which explains some hard-to-read output.
## Booting kernel from Legacy Image at 84001000 ...
Image Name: Linux-4.9.0
Created: 2016-12-14 14:31:44 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6903791 Bytes = 6.6 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
SMC called with a0=0x00000000 a1=0x00000000 a2=0x00000000 a3=0x20100000 0x00000102
SMC called with a0=0x00000000 a1=0x00000000 a2=0x00000000 a3=0x00000064 0x00000102
SMC called with a0=0x00000001 a1=0x00000102 a2=0xd0804730 a3=0xc0119380 0x00000102
SMC called with a0=0x80101500 a1=0x00000105 a2=0x00000000 a3=0x00000000 0x00000105
SMC called with a0=0x00000001 a1=0x00000104 a2=0x00000000 a3=0x00000000 0x00000104
[0][flow/smc_handler.c:127] waking up CPU1
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.0 (me at misti.france.sdesigns.com) (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #143 SMP PREEMPT Wed Dec 14 15:31:39 CET 2016
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] On node 0 totalpages: 65536
[ 0.000000] free_area_init_node: node 0, pgdat c0b20f00, node_mem_map cfdf9000
[ 0.000000] Normal zone: 512 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 65536 pages, LIFO batch:15
[ 0.000000] percpu: Embedded 14 pages/cpu @cfdd6000 s25728 r8192 d23424 u57344
[ 0.000000] pcpu-alloc: s25728 r8192 d23424 u57344 alloc=14*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
[ 0.000000] Kernel command line: console=ttyS0,115200 mem=256M debug no_console_suspend
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Memory: 249108K/262144K available (4096K kernel code, 134K rwdata, 872K rodata, 5120K init, 231K bss, 13036K reserved, 0K cma-reserved, 0K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff800000 ( 752 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0500000 (5088 kB)
[ 0.000000] .init : 0xc0600000 - 0xc0b00000 (5120 kB)
[ 0.000000] .data : 0xc0b00000 - 0xc0b21800 ( 134 kB)
[ 0.000000] .bss : 0xc0b21800 - 0xc0b5b680 ( 232 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Build-time adjustment of leaf fanout to 32.
[ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 4 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x72860401
[ 0.000000] clocksource: tango-xtal: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 70787423951 ns
[ 0.000004] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 79536431085ns
[ 0.000012] Switching to timer-based delay loop, resolution 37ns
[ 0.000256] Console: colour dummy device 80x30
[ 0.000278] Calibrating delay loop (skipped), value calculated using timer frequency.. 54.25 BogoMIPS (lpj=90000)
[ 0.000289] pid_max: default: 32768 minimum: 301
[ 0.000393] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000400] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000896] CPU: Testing write buffer coherency: ok
[ 0.001133] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.001178] Setting up static identity map for 0x80100000 - 0x80100058
[ 0.056732] tango_boot_secondary from __cpu_up
[ 0.063938] tango_set_aux_boot_addr=0
[ 0.075101] tango_start_aux_core=0
[ 0.075229] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.075319] Brought up 2 CPUs
[ 0.075330] SMP: Total of 2 processors activated (108.50 BogoMIPS).
[ 0.075337] CPU: All CPU(s) started in SVC mode.
[ 0.075951] devtmpfs: initialized
[ 0.077370] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.077819] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns
[ 0.078226] NET: Registered protocol family 16
[ 0.078999] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.080104] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.080116] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.094156] SCSI subsystem initialized
[ 0.094678] usbcore: registered new interface driver usbfs
[ 0.094788] usbcore: registered new interface driver hub
[ 0.094887] usbcore: registered new device driver usb
[ 0.096948] clocksource: Switched to clocksource tango-xtal
[ 0.110399] NET: Registered protocol family 2
[ 0.110923] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.110949] TCP bind hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.110977] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.111051] UDP hash table entries: 256 (order: 1, 8192 bytes)
[ 0.111082] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[ 0.111239] NET: Registered protocol family 1
[ 0.111623] RPC: Registered named UNIX socket transport module.
[ 0.111631] RPC: Registered udp transport module.
[ 0.111636] RPC: Registered tcp transport module.
[ 0.111641] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.310427] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
[ 0.311930] futex hash table entries: 512 (order: 3, 32768 bytes)
[ 0.312759] workingset: timestamp_bits=30 max_order=16 bucket_order=0
[ 0.313862] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 0.313883] io scheduler noop registered
[ 0.313891] io scheduler deadline registered
[ 0.313920] io scheduler cfq registered (default)
[ 0.315331] tangox-dma 290a0.dma: SMP86xx DMA with 2 channels, 1 slaves
[ 0.397789] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
[ 0.399218] console [ttyS0] disabled
[ 0.399291] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[ 0.961466] console [ttyS0] enabled
[ 0.972296] loop: module loaded
[ 0.976476] libphy: Fixed MDIO Bus: probed
[ 0.990487] libphy: nb8800-mii: probed
[ 0.999534] nb8800 26000.ethernet eth0: MAC address 00:16:e8:43:2f:80
[ 1.006218] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.012991] usbcore: registered new interface driver usb-storage
[ 1.072811] ci_hdrc ci_hdrc.0: doesn't support gadget
[ 1.077917] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 1.082851] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[ 1.100296] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[ 1.106586] hub 1-0:1.0: USB hub found
[ 1.110424] hub 1-0:1.0: 1 port detected
[ 1.169474] ci_hdrc ci_hdrc.1: doesn't support gadget
[ 1.174577] ci_hdrc ci_hdrc.1: EHCI Host Controller
[ 1.179510] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
[ 1.196962] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[ 1.203147] hub 2-0:1.0: USB hub found
[ 1.206980] hub 2-0:1.0: 1 port detected
[ 1.212967] tangox-wdt 1fd00.watchdog: SMP86xx/SMP87xx watchdog registered
[ 1.221059] sdhci: Secure Digital Host Controller Interface driver
[ 1.227316] sdhci: Copyright(c) Pierre Ossman
[ 1.231703] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.237845] usbcore: registered new interface driver usbhid
[ 1.243463] usbhid: USB HID core driver
[ 1.247645] NET: Registered protocol family 17
[ 1.252201] Registering SWP/SWPB emulation handler
[ 1.266305] Freeing unused kernel memory: 5120K (c0600000 - c0b00000)
Starting logging: OK
Initializing random number generator... [ 1.359367] random: dd: uninitialized urandom read (512 bytes read)
done.
Starting network: OK
Starting telnetd: OK
Welcome to Buildroot
buildroot login: root
#
# echo 0 > /sys/devices/system/cpu/cpu1/online
SMC called with a0=[0x00000001 a1=0x00000 121 a2=0x000 00005 a3 =0xc01193b4 70x000000121
[1][flow/suspend.c:39]. CPU 1 die:3 jumping to post-boot WFE4
4187] CPU1: shutdown
SMC called with a0=0x00000001 a1=0x00000122 a2=0x00000000 a3=0x00000000 0x00000122
[0][flow/suspend.c:82] Killing core1
armor+++ armor: core 1 booted, entering wfe...
#
# echo 1 > /sys/devices/system/cpu/cpu1/online
[ 86.924294] tango_boot_secondary from __cpu_up
SMC called with a0=0x80101500 a1=0x00000105 a2=0x00000000 a3=0x00000000 0x00000105
[ 86.936275] tango_set_aux_boot_addr=0
SMC called with a0=0x00000001 a1=0x00000104 a2=0x00000000 a3=0x00000000 0x00000104
[0][flow/smc_handler.c:127] waking up CPU1
[ 86.9[ 8516.92512662]2] U Unnaabbllee tto ho ahnandledle kerkernenell NULL pointer dereference at virtual address 00000000
[ 86.951266] pgd = c0004000
[ 86.951271] [00000000] *pgd=00000000
[ 86.951280] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 86.951285] Modules linked in:
[ 86.951292] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.0 #143
[ 86.951294] Hardware name: Sigma Tango DT
[ 86.951297] task: cf85b140 task.stack: cf85e000
[ 86.951312] PC is at tick_broadcast_setup_oneshot+0x18/0x134
[ 86.951319] LR is at debug_smp_processor_id+0x20/0x24
[ 86.951324] pc : [<c0187394>] lr : [<c030f0a4>] psr: 200001d3
[ 86.951324] sp : cf85fe90 ip : cf85fe80 fp : cf85fecc
[ 86.951326] r10: 00000000 r9 : c05016d4 r8 : 400001d3
[ 86.951329] r7 : 00000000 r6 : cfde8f80 r5 : 00000000 r4 : 00000001
[ 86.951331] r3 : cf85e000 r2 : 00000002 r1 : c057d620 r0 : 00000001
[ 86.951335] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
[ 86.951338] Control: 10c5387d Table: 8000404a DAC: 00000051
[ 86.951340] Process swapper/1 (pid: 0, stack limit = 0xcf85e210)
[ 86.951344] Stack: (0xcf85fe90 to 0xcf860000)
[ 86.951348] fe80: cf85fedc cf85fea0 c0b482dc 400001d3
[ 86.951354] fea0: cfde8f80 00000001 00000001 cfde8f80 00000000 400001d3 c05016d4 00000000
[ 86.951359] fec0: cf85fef4 cf85fed0 c01875f4 c0187388 cfde8f80 cfde78f0 00000001 00000000
[ 86.951364] fee0: 00000001 c05016d4 cf85ff2c cf85fef8 c0186318 c01874bc cf85ff14 cf85ff08
[ 86.951369] ff00: c0b0c150 cfde78f0 cfde8f80 00000001 00000000 a00001d3 00000001 00000000
[ 86.951374] ff20: cf85ff4c cf85ff30 c0186544 c01862bc c0b0c150 c0b0c150 c0b0c168 cfde8f80
[ 86.951379] ff40: cf85ff74 cf85ff50 c01852ec c018648c cfde4244 00000060 c0b07cf8 00000001
[ 86.951385] ff60: 0f3a5000 00000001 cf85ff84 cf85ff78 c03fcf10 c0185294 cf85ffb4 cf85ff88
[ 86.951390] ff80: c011c588 c03fceb4 00000000 cfde4244 00000060 00000001 c0a3f244 0f3a5000
[ 86.951395] ffa0: 413fc090 00000000 cf85ffdc cf85ffb8 c011e10c c011c53c c0b0d198 00000001
[ 86.951400] ffc0: 10c0387d c0b21ae8 8000406a 413fc090 cf85fff4 cf85ffe0 c010dd6c c011e0bc
[ 86.951405] ffe0: 8f84006a 00000051 00000000 cf85fff8 8010158c c010dc88 8f34eea9 0607fa8b
[ 86.951408] Backtrace:
[ 86.951417] [<c018737c>] (tick_broadcast_setup_oneshot) from [<c01875f4>] (tick_device_uses_broadcast+0x144/0x1a8)
[ 86.951423] r10:00000000 r9:c05016d4 r8:400001d3 r7:00000000 r6:cfde8f80 r5:00000001
[ 86.951425] r4:00000001
[ 86.951431] [<c01874b0>] (tick_device_uses_broadcast) from [<c0186318>] (tick_setup_device+0x68/0x110)
[ 86.951437] r9:c05016d4 r8:00000001 r7:00000000 r6:00000001 r5:cfde78f0 r4:cfde8f80
[ 86.951443] [<c01862b0>] (tick_setup_device) from [<c0186544>] (tick_check_new_device+0xc4/0xe8)
[ 86.951448] r10:00000000 r9:00000001 r8:a00001d3 r7:00000000 r6:00000001 r5:cfde8f80
[ 86.951450] r4:cfde78f0
[ 86.951457] [<c0186480>] (tick_check_new_device) from [<c01852ec>] (clockevents_register_device+0x64/0x11c)
[ 86.951461] r7:cfde8f80 r6:c0b0c168 r5:c0b0c150 r4:c0b0c150
[ 86.951472] [<c0185288>] (clockevents_register_device) from [<c03fcf10>] (dummy_timer_starting_cpu+0x68/0x70)
[ 86.951478] r9:00000001 r8:0f3a5000 r7:00000001 r6:c0b07cf8 r5:00000060 r4:cfde4244
[ 86.951490] [<c03fcea8>] (dummy_timer_starting_cpu) from [<c011c588>] (cpuhp_invoke_callback+0x58/0x120)
[ 86.951497] [<c011c530>] (cpuhp_invoke_callback) from [<c011e10c>] (notify_cpu_starting+0x5c/0x6c)
[ 86.951503] r10:00000000 r9:413fc090 r8:0f3a5000 r7:c0a3f244 r6:00000001 r5:00000060
[ 86.951505] r4:cfde4244 r3:00000000
[ 86.951511] [<c011e0b0>] (notify_cpu_starting) from [<c010dd6c>] (secondary_start_kernel+0xf0/0x164)
[ 86.951516] r9:413fc090 r8:8000406a r7:c0b21ae8 r6:10c0387d r5:00000001 r4:c0b0d198
[ 86.951524] [<c010dc7c>] (secondary_start_kernel) from [<8010158c>] (0x8010158c)
[ 86.951526] r5:00000051 r4:8f84006a
[ 86.951532] Code: e24cb004 e24dd014 e1a05000 eb061f3b (e5952000)
[ 86.951537] ---[ end trace b9e15a7104bf60a3 ]---
[ 86.951543] Kernel panic - not syncing: Attempted to kill the idle task!
[ 86.962632] CPU0: stopping
[ 86.962638] CPU: 0 PID: 928 Comm: sh Tainted: G D 4.9.0 #143
[ 86.962640] Hardware name: Sigma Tango DT
[ 86.962643] Backtrace:
[ 86.962659] [<c010b9c4>] (dump_backtrace) from [<c010bc80>] (show_stack+0x18/0x1c)
[ 86.962664] r7:60000193 r6:c0b10914 r5:00000000 r4:c0b10914
[ 86.962674] [<c010bc68>] (show_stack) from [<c02f574c>] (dump_stack+0x80/0x94)
[ 86.962680] [<c02f56cc>] (dump_stack) from [<c010e1f4>] (handle_IPI+0x1a0/0x1b4)
[ 86.962685] r7:00000000 r6:00000004 r5:00000000 r4:c0a42ec4
[ 86.962690] [<c010e054>] (handle_IPI) from [<c01014ec>] (gic_handle_irq+0x90/0x94)
[ 86.962695] r9:d0803100 r8:d0802100 r7:cfbb7bb8 r6:d080210c r5:c0b03348 r4:c0b10b70
[ 86.962700] [<c010145c>] (gic_handle_irq) from [<c010c7cc>] (__irq_svc+0x6c/0xa8)
[ 86.962703] Exception stack(0xcfbb7bb8 to 0xcfbb7c00)
[ 86.962706] 7ba0: 00000000 60000093
[ 86.962711] 7bc0: 00000000 60000013 c0b26880 c0b43ca0 00000000 00000026 00000000 00000073
[ 86.962717] 7be0: 00002248 cfbb7c74 cfbb7b40 cfbb7c08 c04dc3d0 c0163780 60000013 ffffffff
[ 86.962722] r9:cfbb6000 r8:00000000 r7:cfbb7bec r6:ffffffff r5:60000013 r4:c0163780
[ 86.962732] [<c0163490>] (console_unlock) from [<c0163d40>] (vprintk_emit+0x2ac/0x4a8)
[ 86.962738] r10:00000000 r9:c0b23d20 r8:c0b0b03c r7:00000004 r6:00000002 r5:00000000
[ 86.962740] r4:00000016
[ 86.962746] [<c0163a94>] (vprintk_emit) from [<c01640dc>] (vprintk_default+0x28/0x30)
[ 86.962751] r10:00000000 r9:00000001 r8:c0b21ae8 r7:cf85b140 r6:c05a7a54 r5:c01640b4
[ 86.962753] r4:cfbb7d14
[ 86.962764] [<c01640b4>] (vprintk_default) from [<c01a7df8>] (printk+0x74/0x7c)
[ 86.962772] [<c01a7d88>] (printk) from [<c011949c>] (tango_boot_secondary+0x68/0x70)
[ 86.962776] r3:60000500 r2:00000003 r1:00000000 r0:c057376c
[ 86.962779] r5:00000001 r4:00000001
[ 86.962784] [<c0119434>] (tango_boot_secondary) from [<c010d9bc>] (__cpu_up+0xb0/0x144)
[ 86.962787] r5:00000001 r4:c0b21af8
[ 86.962792] [<c010d90c>] (__cpu_up) from [<c011d128>] (bringup_cpu+0x28/0xa8)
[ 86.962797] r9:00000001 r8:00000030 r7:00000001 r6:c0b086a8 r5:00000001 r4:cf85b140
[ 86.962804] [<c011d100>] (bringup_cpu) from [<c011c588>] (cpuhp_invoke_callback+0x58/0x120)
[ 86.962806] r5:00000001 r4:cfde4244
[ 86.962813] [<c011c530>] (cpuhp_invoke_callback) from [<c011c784>] (cpuhp_up_callbacks+0x2c/0xdc)
[ 86.962819] r10:00000000 r9:cfde4244 r8:00000030 r7:00000000 r6:00000000 r5:00000001
[ 86.962821] r4:cfde4244 r3:00000000
[ 86.962827] [<c011c758>] (cpuhp_up_callbacks) from [<c011dd38>] (_cpu_up+0xb0/0x10c)
[ 86.962832] r9:cfde4244 r8:0f3a5000 r7:00000097 r6:00000000 r5:00000001 r4:c0a3f244
[ 86.962837] [<c011dc88>] (_cpu_up) from [<c011de0c>] (do_cpu_up+0x78/0xa0)
[ 86.962842] r9:00000000 r8:00000000 r7:cec32540 r6:cfde4044 r5:00000097 r4:00000001
[ 86.962847] [<c011dd94>] (do_cpu_up) from [<c011de48>] (cpu_up+0x14/0x18)
[ 86.962849] r5:cfde4010 r4:c036154c
[ 86.962862] [<c011de34>] (cpu_up) from [<c0361560>] (cpu_subsys_online+0x14/0x18)
[ 86.962869] [<c036154c>] (cpu_subsys_online) from [<c035cb14>] (device_online+0x6c/0x90)
[ 86.962874] [<c035caa8>] (device_online) from [<c035cba8>] (online_store+0x70/0x7c)
[ 86.962878] r7:cec32540 r6:cfbb7f80 r5:00000002 r4:cfde4010
[ 86.962883] [<c035cb38>] (online_store) from [<c035a3d4>] (dev_attr_store+0x20/0x2c)
[ 86.962886] r5:00000002 r4:c035cb38
[ 86.962894] [<c035a3b4>] (dev_attr_store) from [<c024ac2c>] (sysfs_kf_write+0x48/0x4c)
[ 86.962897] r5:00000002 r4:c035a3b4
[ 86.962903] [<c024abe4>] (sysfs_kf_write) from [<c024a3e8>] (kernfs_fop_write+0xf8/0x1f8)
[ 86.962905] r5:00000002 r4:cf9d2b80
[ 86.962916] [<c024a2f0>] (kernfs_fop_write) from [<c01e3bd4>] (__vfs_write+0x34/0x120)
[ 86.962922] r10:00000000 r9:cfbb6000 r8:c0107d64 r7:00000002 r6:cfbb7f80 r5:c024a2f0
[ 86.962924] r4:cf9cd780
[ 86.962930] [<c01e3ba0>] (__vfs_write) from [<c01e4a68>] (vfs_write+0xac/0x170)
[ 86.962936] r9:cfbb6000 r8:c0107d64 r7:cfbb7f80 r6:00e0a408 r5:cf9cd780 r4:00000002
[ 86.962942] [<c01e49bc>] (vfs_write) from [<c01e5868>] (SyS_write+0x4c/0xa8)
[ 86.962947] r9:cfbb6000 r8:c0107d64 r7:00000002 r6:00e0a408 r5:cf9cd780 r4:cf9cd780
[ 86.962955] [<c01e581c>] (SyS_write) from [<c0107ba0>] (ret_fast_syscall+0x0/0x3c)
[ 86.962959] r7:00000004 r6:b6effd60 r5:00e0a408 r4:00000002
[ 87.718648] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
CONFIG_CROSS_COMPILE="arm-linux-gnueabihf-"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_ARCH_TANGO=y
# CONFIG_ARM_ERRATA_643719 is not set
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_HZ_300=y
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
# CONFIG_COMPACTION is not set
# CONFIG_ATAGS is not set
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_CMDLINE="console=ttyS0,115200 mem=256M"
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPUFREQ_DT=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_IPV6 is not set
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_MTD=y
CONFIG_MTD_TESTS=m
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_TANGO=m
CONFIG_MTD_UBI=m
CONFIG_BLK_DEV_LOOP=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_NETDEVICES=y
CONFIG_NET_VENDOR_AURORA=y
CONFIG_AURORA_NB8800=y
CONFIG_AT803X_PHY=y
# CONFIG_USB_NET_DRIVERS is not set
# CONFIG_WLAN is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=1
CONFIG_SERIAL_8250_RUNTIME_UARTS=1
CONFIG_SERIAL_8250_RT288X=y
CONFIG_SERIAL_OF_PLATFORM=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_XLR=y
CONFIG_GPIOLIB=y
CONFIG_THERMAL=y
CONFIG_CPU_THERMAL=y
CONFIG_TANGO_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_TANGOX_WATCHDOG=y
CONFIG_FB=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_OF_ARASAN=y
CONFIG_DMADEVICES=y
CONFIG_TANGO_DMA=y
CONFIG_PHY_TANGO_USB=y
CONFIG_EXT4_FS=y
CONFIG_FUSE_FS=m
CONFIG_VFAT_FS=m
CONFIG_TMPFS=y
CONFIG_UBIFS_FS=m
CONFIG_NFS_FS=y
# CONFIG_NFS_V2 is not set
CONFIG_ROOT_NFS=y
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_UTF8=m
CONFIG_PRINTK_TIME=y
# CONFIG_FTRACE is not set
# CONFIG_ARM_UNWIND is not set
# CONFIG_CRYPTO_ECHAINIV is not set
Regards.
^ permalink raw reply related
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Tony Lindgren @ 2016-12-14 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214155208.ocs4vw77expduefr@earth>
* Sebastian Reichel <sre@kernel.org> [161214 07:52]:
> On Wed, Dec 14, 2016 at 07:10:56AM -0800, Tony Lindgren wrote:
> > Maybe send it so we can merge it as a fix during the early -rc
> > cycle?
>
> Sorry if I was not clear enough: mainline does *not* contain
> incorrect DT information. My bluetooth RFC patches did. So
> this can go into the kernel once the driver is there and
> the binding got accepted.
Oh OK good to hear.
> Alternatively I can prepare a patch, which just adds the
> cts/rts pinmux for the bluetooth UART, but it's not very
> useful on its own.
OK sounds like no rush until other pieces are ready.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ee4321d6-dcc9-4de7-c376-6b169d160322@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
> >>
> >> Hello Bartlomiej,
> >>
> >> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >>>> Hello Bartlomiej,
> >>>
> >>> Hi,
> >>>
> >>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>>>> cooling maps to account for new OPPs.
> >>>>>
> >>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>>>
> >>>>> Tested on Odroid-XU3 and XU3 Lite.
> >>>>>
> >>>>> Cc: Doug Anderson <dianders@chromium.org>
> >>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>>>> Cc: Andreas Faerber <afaerber@suse.de>
> >>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>>>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>>>
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -118,7 +118,7 @@
> >>>>> /*
> >>>>> * When reaching cpu_alert3, reduce CPU
> >>>>> * by 2 steps. On Exynos5422/5800 that would
> >>>>> - * be: 1600 MHz and 1100 MHz.
> >>>>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>>>> */
> >>>>> map3 {
> >>>>> trip = <&cpu_alert3>;
> >>>>> @@ -131,16 +131,16 @@
> >>>>>
> >>>>> /*
> >>>>> * When reaching cpu_alert4, reduce CPU
> >>>>> - * further, down to 600 MHz (11 steps for big,
> >>>>> - * 7 steps for LITTLE).
> >>>>> + * further, down to 600 MHz (13 steps for big,
> >>>>> + * 8 steps for LITTLE).
> >>>>> */
> >>>>> - map5 {
> >>>>> + cooling_map5: map5 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu0 3 7>;
> >>>>> + cooling-device = <&cpu0 3 8>;
> >>>>> };
> >>>>> - map6 {
> >>>>> + cooling_map6: map6 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu4 3 11>;
> >>>>> + cooling-device = <&cpu4 3 13>;
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -21,6 +21,23 @@
> >>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>>>> };
> >>>>>
> >>>>> +&cluster_a15_opp_table {
> >>>>> + /delete-node/opp at 2000000000;
> >>>>> + /delete-node/opp at 1900000000;
> >>>>> +};
> >>>>> +
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-node/opp at 1400000000;
> >>>>> +};
> >>>>> +
> >>>>
> >>>> I think that a comment in the DTS why these operating points aren't available
> >>>> in this board will make more clear why the nodes are being deleted.
> >>>
> >>> Ok, I will add these comments in the next patch revision.
> >>>
> >>>>> +&cooling_map5 {
> >>>>> + cooling-device = <&cpu0 3 7>;
> >>>>> +};
> >>>>> +
> >>>>> +&cooling_map6 {
> >>>>> + cooling-device = <&cpu4 3 11>;
> >>>>> +};
> >>>>> +
> >>>>> &pwm {
> >>>>> /*
> >>>>> * PWM 0 -- fan
> >>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -146,6 +146,10 @@
> >>>>> vdd-supply = <&ldo9_reg>;
> >>>>> };
> >>>>>
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-property/opp at 1400000000;
> >>>>> +};
> >>>>> +
> >>>>> &cpu0 {
> >>>>> cpu-supply = <&buck2_reg>;
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -24,6 +24,16 @@
> >>>>> };
> >>>>>
> >>>>> &cluster_a15_opp_table {
> >>>>> + opp at 2000000000 {
> >>>>> + opp-hz = /bits/ 64 <2000000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> + opp at 1900000000 {
> >>>>> + opp-hz = /bits/ 64 <1900000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> opp at 1700000000 {
> >>>>> opp-microvolt = <1250000>;
> >>>>> };
> >>>>> @@ -85,6 +95,11 @@
> >>>>> };
> >>>>>
> >>>>
> >>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >>>> INT rail would need to be scaled up as well since there's a maximum voltage
> >>>> difference between the ARM and INT rails before the system becomes unstable:
> >>>>
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >>>> https://lkml.org/lkml/2014/5/2/419
> >>>>
> >>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >>>> the maximum voltage skew is between a limit. But that never made to mainline:
> >>>>
> >>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >>>> https://lkml.org/lkml/2014/4/29/28
> >>>>
> >>>> Did that change and there's infrastructure in mainline now to cope with that?
> >>>> If that's the case, I think it would be good to mention in the commit message.
> >>>
> >>> I was not aware of this limitation and AFAIK mainline has currently
> >>> no code to handle it. I also cannot find any code to handle this in
> >>
> >> Yes, that's what I thought as well but maybe I was missing something.
> >>
> >>> Hardkernel's vendor kernel for Odroid-XU3 board.
> >>>
> >>> Do you know whether this problem exists also on Exynos5422/5800
> >>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> >>> regulator code also on Exynos5800 SoC based Peach Pi board but was
> >>> the problem actually present on this board?
> >>>
> >>
> >> My understanding is that this problem is present in 5420/5422/5800
> >> but I have no way to confirm this. I'm just guessing from the info
> >> in the ChromiumOS vendor tree.
> >>
> >> If you look at the commit that added the regulator-locker driver,
> >> the test says to be done in a Peach Pi so it seems the problem is
> >> not restricted to only Exynos5420:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> >>
> >>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> >>> (unfortunately Inderpal's email is no longer working). ]
> >>>
> >>
> >> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> >
> > Abhilash's email is also no longer valid.. :(
> >
>
> Yes, I noticed that as well :(
>
> >>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> >>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> >>> IOW if the problem exists it is already present in the mainline
> >>> kernel.
> >>>
> >>
> >> Ah, I only looked at your patch and I didn't compare the voltage levels
> >> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
> >>
> >> I wonder if the voltage levels in your patch are correct then, since the
> >> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
> >>
> >> /*
> >> * Default ASV table
> >> */
> >> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> >> 1362500, /* L0 2100 */
> >> 1312500, /* L1 2000 */
> >> 1275000, /* L2 1900 */
> >> 1225000, /* L3 1800 */
> >> 1200000, /* L4 1700 */
> >>
> >> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> >
> > I think that the above voltages are original ones for Exynos5420
> > (not for Exynos5422/5800).
> >
>
> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
This seems suboptimal (or maybe even incorrect as Exynos5422/5800
SoCs also use different clock divider values for clocks related to
CPU clock than Exynos5420 SoC).
Anyway, I can drop Peach Pi support from my patch for now if you want.
> > The voltages in my patch were taken from Hardkernel's kernel for
> > Odroid-XU3:
> >
> > /*
> > * ASV group voltage table
> > */
> > static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> > ...
> > 1250000, /* L4 2000 */
> > 1250000, /* L5 1900 */
> > 1250000, /* L6 1800 */
> > ...
> >
> > https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
> >
>
> In general I prefer to use the ChromiumOS tree as a reference instead of the
> HardKernel one, since the former is in a much better shape IMHO.
I generally agree, OTOH Hardkernel's tree is based on Samsung's
vendor trees and additionally it contains all low-level hardware
details for Odroid-XU3 board (not present in ChromiumOS tree).
> I think is worth to check in a kernel tree in http://opensource.samsung.com/
> for a product that's Exynos5422/5800 based.
I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
S5 which is Exynos5422 based) and it uses 50mV lower voltages for
1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
identical to the ones used by HardKernel's tree,
drivers/cpufreq/exynos5422-eagle-cpufreq.c:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1200000, /* L4 2000 */
1200000, /* L5 1900 */
1200000, /* L6 1800 */
1200000, /* L7 1700 */
1200000, /* L8 1600 */
1100000, /* L9 1500 */
1100000, /* L10 1400 */
1100000, /* L11 1300 */
1000000, /* L12 1200 */
1000000, /* L13 1100 */
1000000, /* L14 1000 */
1000000, /* L15 900 */
900000, /* L16 800 */
900000, /* L17 700 */
900000, /* L18 600 */
900000, /* L19 500 */
900000, /* L20 400 */
900000, /* L22 300 */
900000, /* L22 200 */
};
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Chen-Yu Tsai @ 2016-12-14 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-5-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> v2:
> - adding small explanation on AXP223 variation compared to the AXP221,
>
> Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> index f1d7bee..ba8d35f 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> @@ -3,6 +3,11 @@ AXP20x USB power supply
> Required Properties:
> -compatible: One of: "x-powers,axp202-usb-power-supply"
> "x-powers,axp221-usb-power-supply"
> + "x-powers,axp223-usb-power-supply"
> +
> +The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight
> +variations such as the former being able to set the VBUS power supply max
> +current to 100mA, unlike the latter.
I actually wanted this in the commit log, but this works too.
Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> This node is a subnode of the axp20x PMIC.
>
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH 1/1] arm64: Correcting format specifier for printing 64 bit addresses
From: Paolo Bonzini @ 2016-12-14 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206161116.GD4816@cbox>
On 06/12/2016 17:11, Christoffer Dall wrote:
> + kvm_err("Unsupported guest CP%d access at: %08lx\n",
> + cp, *vcpu_pc(vcpu));
> + else
> + kvm_err("Unsupported guest CP%d access at: %016lx\n",
> + cp, *vcpu_pc(vcpu));
>
> It feels a bit much to me to have an if-statement to differentiate the
> number of leading zeros, so if it's important to always have fixed
> widths then I would just use %016lx in both cases.
Really, this is just a debugging message. Just use "0x%lx" and let's
stop bikeshedding. :)
Paolo
^ permalink raw reply
* [PATCH 2/2] FPGA: Add TS-7300 FPGA manager
From: Hartley Sweeten @ 2016-12-14 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1612120951520.3310@atull-730U3E-740U3E>
On Monday, December 12, 2016 9:02 AM, Alan Tull wrote:
> On Sun, 11 Dec 2016, Florian Fainelli wrote:
>> Add support for loading bitstreams on the Altera Cyclone II FPGA
>> populated on the TS-7300 board. This is done through the configuration
>> and data registers offered through a memory interface between the EP93xx
>> SoC and the FPGA.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Hi Florain,
>
> Thanks for submitting!
>
> How specific is this to the tx7300 board?
>
> I'm unclear about the programming method here. Are these registers
> exposed by the EP93xx? Is it possible that another cpu could access
> these two registers to configure the cyclone ii? Is this passive
> serial?
Alan,
>From the schematic, it appears that the Cyclone II FPGA is configured for
Fast AS programming. The glue chip (MAXII CLPD) on the board appears to
implement some kind of state machine to handle the FPGA programming
using two registers in the glue chip.
Hartley
^ permalink raw reply
* [PATCH v3 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
From: Hartley Sweeten @ 2016-12-14 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214023553.9377-2-f.fainelli@gmail.com>
On Tuesday, December 13, 2016 7:36 PM, Florian Fainelli wrote:
>
> Register the TS-7300 FPGA manager device drivers which allows us to load
> bitstreams into the on-board Altera Cyclone II FPGA.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/mach-ep93xx/ts72xx.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
For the ep93xx core change:
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [PATCH linux v1 0/4] Seven segment display support
From: Greg KH @ 2016-12-14 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac324946-41da-c090-a0ca-78155611bb7e@baylibre.com>
On Wed, Dec 14, 2016 at 02:12:41PM +0100, Neil Armstrong wrote:
> On 12/14/2016 01:56 PM, Greg KH wrote:
> > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> >> Natarajan wrote:
> >>
> >>> Documentation for the binding which provides an interface for adding clock,
> >>> data and clear signal GPIO lines to control seven segment display.
> >>>
> >>> The platform device driver provides an API for displaying on two 7-segment
> >>> displays, and implements the required bit-banging. The hardware assumed is
> >>> 74HC164 wired to two 7-segment displays.
> >>>
> >>> The character device driver implements the user-space API for letting a user
> >>> write to two 7-segment displays including any conversion methods necessary
> >>> to map the user input to two 7-segment displays.
> >>>
> >>> Adding clock, data and clear signal GPIO lines in the devicetree to control
> >>> seven segment display on zaius platform.
> >>>
> >>> The platform driver matches on the device tree node; the platform driver also
> >>> initializes the character device.
> >>>
> >>> Tested that the seven segment display works properly by writing to the
> >>> character device file on a EVB AST2500 board which also has 74HC164 wired
> >>> to two 7-segment displays.
> >>
> >> FWIW, I proposed a driver for seven segment displays back in 2013:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
> >>
> >> And the feedback from Greg KH was: we don't need a driver for that, do
> >> it from userspace. See:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
> >>
> >> So: good luck :-)
> >
> > Did anyone ever write a library for this type of thing?
> >
> > Again, I don't want to see one-off drivers for random devices like this
> > that should be able to all be controlled from userspace in a common
> > manner. Much like we did for fingerprint readers a long long time
> > ago...
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
> characters a simple and clean driver could achieve.
Great, then let's make an API that all devices of this type could use,
and not just take individual drivers that all have a custom char or
sysfs interface which requires custom userspace code to be able to drive
all of the different devices in a common way (i.e. a library would have
to be written anyways...)
thanks,
greg k-h
^ 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