* [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq
From: Tony Lindgren @ 2017-12-20 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219004811.GA216620@google.com>
Hi,
* Brian Norris <briannorris@chromium.org> [171219 00:50]:
> On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote:
>
> Did this problem ever get resolved? To be clear, I believe the problem
> at hand is:
>
> (a) in suspend/resume (not runtime PM; we may not even have runtime PM
> support for most PCI devices)
It seems it should be enough to implement runtime PM in the PCI
controller. Isn't each PCI WAKE# line is wired from each PCI device
to the PCI controller?
Then the PCI controller can figure out from which PCI device the
WAKE# came from.
> Options I can think of:
> (1) implement runtime PM callbacks for all PCI devices, where we clear
> any PME status and ensure WAKE# stops asserting [1]
I don't think this is needed, it should be enough to have just
the PCI controller implement runtime PM :)
Regards,
Tony
^ permalink raw reply
* [GIT PULL] arm64: Updates of aarch64 DTS files for v4.15-next
From: Matthias Brugger @ 2017-12-20 19:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, hi Arnd,
Please take the patches below into consideration.
Thanks a lot,
Matthias
---
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/matthias.bgg/linux.git
tags/v4.15-next-dts32
for you to fetch changes up to a227cf4dfd74a873857c9cc017100168d01539ed:
dt-bindings: ARM: Mediatek: Fix ethsys documentation (2017-12-20 18:10:12 +0100)
----------------------------------------------------------------
- add reset cells mt2701 and mt7623 ethsys
- update mmc nodes for mt7623
- mt7623 change mmc card detection pin to active low
- mt7623 set unit address to lower case
----------------------------------------------------------------
Mathieu Malaterre (1):
arm: mt7: dts: Remove leading 0x and 0s from bindings notation
Matthias Brugger (3):
arm: dts: mt7623: Update ethsys binding
arm: dts: mt2701: Add reset-cells
dt-bindings: ARM: Mediatek: Fix ethsys documentation
Sean Wang (2):
arm: dts: mt7623: update mmc related nodes with the appropriate fallback
arm: dts: mt7623: fix card detection issue on bananapi-r2
Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
arch/arm/boot/dts/mt2701.dtsi | 2 ++
arch/arm/boot/dts/mt7623.dtsi | 5 +++--
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
arch/arm/boot/dts/mt7623n-rfb-nand.dts | 2 +-
5 files changed, 8 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
From: Michael Turquette @ 2017-12-20 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06b927e4-ed1b-9e1a-becf-e2818e7efe6d@gmail.com>
Quoting Matthias Brugger (2017-12-20 09:13:12)
>
>
> On 12/19/2017 02:32 AM, Stephen Boyd wrote:
> > On 12/14, Matthias Brugger wrote:
> >> Hi Stephen, Michael,
> >>
> >> On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> >>> The ethsys registers a reset controller, so we need to specify a
> >>> reset cell. This patch fixes the documentation.
> >>>
> >>> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> >>> ---
> >>> Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> index 7aa3fa167668..6cc7840ff37a 100644
> >>> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> @@ -20,4 +20,5 @@ ethsys: clock-controller at 1b000000 {
> >>> compatible = "mediatek,mt2701-ethsys", "syscon";
> >>> reg = <0 0x1b000000 0 0x1000>;
> >>> #clock-cells = <1>;
> >>> + #reset-cells = <1>;
> >>> };
> >>>
> >>
> >> Will you take this patch through the clk tree, or shall I take it through my SoC
> >> tree?
> >>
> >
> > It's resets, we are clk maintainers. I'm clkfused.
> >
> > You can take it, along with my
> >
> > Acked-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > if you like/expect conflicts.
> >
>
> These are resets in the clock IP-block. I'll take it through my branch, I don't
> expect any conflicts.
Sounds good to me.
Best regards,
Mike
>
> Regards,
> Matthias
^ permalink raw reply
* [PATCH 1/2] arm64: dts: exynos: Use lower case hex addresses in node unit addresses
From: Krzysztof Kozlowski @ 2017-12-20 19:27 UTC (permalink / raw)
To: linux-arm-kernel
Convert all hex addresses in node unit addresses to lower case to
fix warnings like:
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dtb: Warning (simple_bus_reg):
Node /soc/video-scaler at 13C00000 simple-bus unit address format error, expected "13c00000"
Conversion was done using sed:
$ sed -e 's/@\([a-zA-Z0-9_-]*\) {/@\L\1 {/' -i arch/arm64/boot/dts/exynos/*.dts*
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 8 ++++----
arch/arm64/boot/dts/exynos/exynos7.dtsi | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 1962b8074349..0ba5df825eff 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -994,7 +994,7 @@
reg = <0x145f0000 0x1038>;
};
- gsc_0: video-scaler at 13C00000 {
+ gsc_0: video-scaler at 13c00000 {
compatible = "samsung,exynos5433-gsc";
reg = <0x13c00000 0x1000>;
interrupts = <GIC_SPI 297 IRQ_TYPE_LEVEL_HIGH>;
@@ -1008,7 +1008,7 @@
power-domains = <&pd_gscl>;
};
- gsc_1: video-scaler at 13C10000 {
+ gsc_1: video-scaler at 13c10000 {
compatible = "samsung,exynos5433-gsc";
reg = <0x13c10000 0x1000>;
interrupts = <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>;
@@ -1022,7 +1022,7 @@
power-domains = <&pd_gscl>;
};
- gsc_2: video-scaler at 13C20000 {
+ gsc_2: video-scaler at 13c20000 {
compatible = "samsung,exynos5433-gsc";
reg = <0x13c20000 0x1000>;
interrupts = <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>;
@@ -1049,7 +1049,7 @@
power-domains = <&pd_mscl>;
};
- mfc: codec at 152E0000 {
+ mfc: codec at 152e0000 {
compatible = "samsung,exynos5433-mfc";
reg = <0x152E0000 0x10000>;
interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 9a3fbed1765a..3504837b1d43 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -103,7 +103,7 @@
#size-cells = <1>;
ranges;
- pdma0: pdma at 10E10000 {
+ pdma0: pdma at 10e10000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x10E10000 0x1000>;
interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
@@ -114,7 +114,7 @@
#dma-requests = <32>;
};
- pdma1: pdma at 10EB0000 {
+ pdma1: pdma at 10eb0000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x10EB0000 0x1000>;
interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: exynos: Fix typo in MSCL clock controller unit address
From: Krzysztof Kozlowski @ 2017-12-20 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220192702.32515-1-krzk@kernel.org>
Fix typo in unit address of MSCL clock controller (the reg entry is
correct).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 0ba5df825eff..3e8311c60d1b 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -468,7 +468,7 @@
clocks = <&xxti>, <&cmu_mif CLK_SCLK_BUS_PLL_ATLAS>;
};
- cmu_mscl: clock-controller at 105d0000 {
+ cmu_mscl: clock-controller at 150d0000 {
compatible = "samsung,exynos5433-cmu-mscl";
reg = <0x150d0000 0x1000>;
#clock-cells = <1>;
--
2.11.0
^ permalink raw reply related
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-20 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219050113.GF28046@linaro.org>
On Tue, Dec 19, 2017 at 10:31 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>>
>> [snip..]
>>
>> [ 0.000000] linux,usable-memory-range base e800000, size 20000000
>> [ 0.000000] - e800000 , 20000000
>> [ 0.000000] linux,usable-memory-range base 396c0000, size a0000
>> [ 0.000000] - 396c0000 , a0000
>> [ 0.000000] linux,usable-memory-range base 39770000, size 40000
>> [ 0.000000] - 39770000 , 40000
>> [ 0.000000] linux,usable-memory-range base 398a0000, size 20000
>> [ 0.000000] - 398a0000 , 20000
>> [ 0.000000] initrd not fully accessible via the linear mapping --
>> please check your bootloader ...
>
> This is an odd message coming from:
> |void __init arm64_memblock_init(void)
> |...
> |
> | if (WARN(base < memblock_start_of_DRAM() ||
> | base + size > memblock_start_of_DRAM() +
> | linear_region_size,
> | "initrd not fully accessible via the linear mapping -- please check your bootloader ...\n")) {
>
> Can you confirm how the condition breaks here?
> I suppose
> base: 0xfe70000
> size: 0x13c0000
> memblock_start_of_DRAM(): 0xe800000
> according to the information you gave me.
Indeed, the first check 'base < memblock_start_of_DRAM()' in the
following check fails:
if (WARN(base < memblock_start_of_DRAM() ||
base + size > memblock_start_of_DRAM() +
linear_region_size,
Here are the values I am seeing on this board using the kernel and
kexec-tools which have been modified to append the
'linux,usable-memory-range' with the acpi reclaim regions:
base=fe70000,
size=13c0000,
memblock_start_of_DRAM=39620000
linear_region_size=800000000000
I suspect that the holes introduced by kexec-tools inside
'arm64_load_other_segments()' in 'kexec/arch/arm64/kexec-arm64.c' (see
the code leg below):
/* Put the other segments after the image. */
hole_min = image_base + arm64_mem.image_size;
if (info->kexec_flags & KEXEC_ON_CRASH)
hole_max = crash_reserved_mem.end;
else
hole_max = ULONG_MAX;
should be updated to introduce appropriate handling of the acpi reclaim regions.
I am not aware of the background of this handling in the kexec-tools.
Do you think this can be at fault, Akashi?
Regards,
Bhupesh
>
>> [ 0.000000] ------------[ cut here ]------------
>> [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/init.c:597
>> arm64_memblock_init+0x210/0x484
>> [ 0.000000] Modules linked in:
>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.0+ #7
>> [ 0.000000] task: ffff000008d05580 task.stack: ffff000008cc0000
>> [ 0.000000] PC is at arm64_memblock_init+0x210/0x484
>> [ 0.000000] LR is at arm64_memblock_init+0x210/0x484
>> [ 0.000000] pc : [<ffff000008b76984>] lr : [<ffff000008b76984>]
>> pstate: 600000c5
>> [ 0.000000] sp : ffff000008ccfe80
>> [ 0.000000] x29: ffff000008ccfe80 x28: 000000000f370018
>> [ 0.000000] x27: 0000000011230000 x26: 00000000013b0000
>> [ 0.000000] x25: 000000000fe80000 x24: ffff000008cf3000
>> [ 0.000000] x23: ffff000008ec0000 x22: ffff000009680000
>> [ 0.000000] x21: ffff000008afa000 x20: ffff000008080000
>> [ 0.000000] x19: ffff000008afa000 x18: 000000000c283806
>> [ 0.000000] x17: 0000000000000000 x16: ffff000008d05580
>> [ 0.000000] x15: 000000002be00842 x14: 79206b6365686320
>> [ 0.000000] x13: 657361656c70202d x12: 2d20676e69707061
>> [ 0.000000] x11: 6d207261656e696c x10: 2065687420616976
>> [ 0.000000] x9 : 00000000000000f4 x8 : ffff000008517414
>> [ 0.000000] x7 : 746f6f622072756f x6 : 000000000000000d
>> [ 0.000000] x5 : ffff000008c96360 x4 : 0000000000000001
>> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000000
>> [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000056
>> [ 0.000000] Call trace:
>> [ 0.000000] Exception stack(0xffff000008ccfd40 to 0xffff000008ccfe80)
>> [ 0.000000] fd40: 0000000000000056 0000000000000000
>> 0000000000000000 0000000000000000
>> [ 0.000000] fd60: 0000000000000001 ffff000008c96360
>> 000000000000000d 746f6f622072756f
>> [ 0.000000] fd80: ffff000008517414 00000000000000f4
>> 2065687420616976 6d207261656e696c
>> [ 0.000000] fda0: 2d20676e69707061 657361656c70202d
>> 79206b6365686320 000000002be00842
>> [ 0.000000] fdc0: ffff000008d05580 0000000000000000
>> 000000000c283806 ffff000008afa000
>> [ 0.000000] fde0: ffff000008080000 ffff000008afa000
>> ffff000009680000 ffff000008ec0000
>> [ 0.000000] fe00: ffff000008cf3000 000000000fe80000
>> 00000000013b0000 0000000011230000
>> [ 0.000000] fe20: 000000000f370018 ffff000008ccfe80
>> ffff000008b76984 ffff000008ccfe80
>> [ 0.000000] fe40: ffff000008b76984 00000000600000c5
>> ffff00000959b7a8 ffff000008ec0000
>> [ 0.000000] fe60: ffffffffffffffff 0000000000000005
>> ffff000008ccfe80 ffff000008b76984
>> [ 0.000000] [<ffff000008b76984>] arm64_memblock_init+0x210/0x484
>> [ 0.000000] [<ffff000008b7398c>] setup_arch+0x1b8/0x5f4
>> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
>> [ 0.000000] random: get_random_bytes called from
>> print_oops_end_marker+0x50/0x6c with crng_init=0
>> [ 0.000000] ---[ end trace 0000000000000000 ]---
>> [ 0.000000] Reserving 4KB of memory at 0x2e7f0000 for elfcorehdr
>> [ 0.000000] cma: Failed to reserve 512 MiB
>> [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate
>> 0x0000000000010000 bytes below 0x0000000000000000.
>> [ 0.000000]
>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G W
>> ------------ 4.14.0+ #7
>> [ 0.000000] Call trace:
>> [ 0.000000] [<ffff000008088da8>] dump_backtrace+0x0/0x23c
>> [ 0.000000] [<ffff000008089008>] show_stack+0x24/0x2c
>> [ 0.000000] [<ffff0000087f647c>] dump_stack+0x84/0xa8
>> [ 0.000000] [<ffff0000080cfd44>] panic+0x138/0x2a0
>> [ 0.000000] [<ffff000008b95c88>] memblock_alloc_base+0x44/0x4c
>> [ 0.000000] [<ffff000008b95cbc>] memblock_alloc+0x2c/0x38
>> [ 0.000000] [<ffff000008b772dc>] early_pgtable_alloc+0x20/0x74
>> [ 0.000000] [<ffff000008b7755c>] paging_init+0x28/0x544
>> [ 0.000000] [<ffff000008b73990>] setup_arch+0x1bc/0x5f4
>> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
>> [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to
>> allocate 0x0000000000010000 bytes below 0x0000000000000000.
>> [ 0.000000]
>>
>> I guess it is because of the 1G alignment requirement between the
>> kernel image and the initrd and how we populate the holes between the
>> kernel image, segments (including dtb) and the initrd from the
>> kexec-tools.
>>
>> Akashi, any pointers on this will be helpful as well.
>>
>> Regards,
>> Bhupesh
>>
>>
>> >> >
>> >> > Regards,
>> >> > Bhupesh
>> >> >
>> >> > >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>> >> > >> via a kernel command line parameter, "memmap=".
>> >> > >>
>> >> > _______________________________________________
>> >> > kexec mailing list -- kexec at lists.fedoraproject.org
>> >> > To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* [GIT PULL 2/5] soc/tegra: Changes for v4.16-rc1
From: Dmitry Osipenko @ 2017-12-20 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-2-thierry.reding@gmail.com>
On 20.12.2017 22:18, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.16-soc
>
> for you to fetch changes up to c641ec6eab8587a78160d37f085a5ed6e542ca88:
>
> soc/tegra: pmc: Consolidate Tegra186 support (2017-12-13 13:06:44 +0100)
>
Could you please include these patches
https://patchwork.ozlabs.org/project/linux-tegra/list/?series=9215 ?
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-20 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-gmbWdZ7rxp5qGrtSBQ7dM=3FqF-Pw=J0LaL=oKTMg4w@mail.gmail.com>
On Tue, Dec 19, 2017 at 6:39 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 19 December 2017 at 07:09, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
>> On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
>>> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
>>> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>>> > > On 13 December 2017 at 12:16, AKASHI Takahiro
>>> > > <takahiro.akashi@linaro.org> wrote:
>>> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>>> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
>>> > > >> <takahiro.akashi@linaro.org> wrote:
>>> > > >> > Bhupesh, Ard,
>>> > > >> >
>>> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>>> > > >> >> Hi Ard, Akashi
>>> > > >> >>
>>> > > >> > (snip)
>>> > > >> >
>>> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>>> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>>> > > >> >> identify its own usable memory and exclude, at its boot time, any
>>> > > >> >> other memory areas that are part of the panicked kernel's memory.
>>> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>>> > > >> >> , for details)
>>> > > >> >
>>> > > >> > Right.
>>> > > >> >
>>> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>>> > > >> >> with the crashkernel memory range:
>>> > > >> >>
>>> > > >> >> /* add linux,usable-memory-range */
>>> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>>> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>>> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>>> > > >> >> address_cells, size_cells);
>>> > > >> >>
>>> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
>>> > > >> >> , for details)
>>> > > >> >>
>>> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>>> > > >> >> they are marked as System RAM or as RESERVED. As,
>>> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
>>> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>>> > > >> >>
>>> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
>>> > > >> >> ACPI memory and crashes while trying to access the same:
>>> > > >> >>
>>> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>>> > > >> >> -r`.img --reuse-cmdline -d
>>> > > >> >>
>>> > > >> >> [snip..]
>>> > > >> >>
>>> > > >> >> Reserved memory range
>>> > > >> >> 000000000e800000-000000002e7fffff (0)
>>> > > >> >>
>>> > > >> >> Coredump memory ranges
>>> > > >> >> 0000000000000000-000000000e7fffff (0)
>>> > > >> >> 000000002e800000-000000003961ffff (0)
>>> > > >> >> 0000000039d40000-000000003ed2ffff (0)
>>> > > >> >> 000000003ed60000-000000003fbfffff (0)
>>> > > >> >> 0000001040000000-0000001ffbffffff (0)
>>> > > >> >> 0000002000000000-0000002ffbffffff (0)
>>> > > >> >> 0000009000000000-0000009ffbffffff (0)
>>> > > >> >> 000000a000000000-000000affbffffff (0)
>>> > > >> >>
>>> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>>> > > >> >> memory cap'ing passed to the crash kernel inside
>>> > > >> >> 'arch/arm64/mm/init.c' (see below):
>>> > > >> >>
>>> > > >> >> static void __init fdt_enforce_memory_region(void)
>>> > > >> >> {
>>> > > >> >> struct memblock_region reg = {
>>> > > >> >> .size = 0,
>>> > > >> >> };
>>> > > >> >>
>>> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>>> > > >> >>
>>> > > >> >> if (reg.size)
>>> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>>> > > >> >> comment this out */
>>> > > >> >> }
>>> > > >> >
>>> > > >> > Please just don't do that. It can cause a fatal damage on
>>> > > >> > memory contents of the *crashed* kernel.
>>> > > >> >
>>> > > >> >> 5). Both the above temporary solutions fix the problem.
>>> > > >> >>
>>> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
>>> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>>> > > >> >> fail.
>>> > > >> >>
>>> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>>> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>>> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>>> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>>> > > >> >> dt node 'linux,usable-memory-range'
>>> > > >> >
>>> > > >> > I still don't understand why we need to carry over the information
>>> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>>> > > >> > such regions are free to be reused by the kernel after some point of
>>> > > >> > initialization. Why does crash dump kernel need to know about them?
>>> > > >> >
>>> > > >>
>>> > > >> Not really. According to the UEFI spec, they can be reclaimed after
>>> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>>> > > >> no longer needs them. Of course, in order to be able to boot a kexec
>>> > > >> kernel, those regions needs to be preserved, which is why they are
>>> > > >> memblock_reserve()'d now.
>>> > > >
>>> > > > For my better understandings, who is actually accessing such regions
>>> > > > during boot time, uefi itself or efistub?
>>> > > >
>>> > >
>>> > > No, only the kernel. This is where the ACPI tables are stored. For
>>> > > instance, on QEMU we have
>>> > >
>>> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>>> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>>> > > 01000013)
>>> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>>> > > BXPC 00000001)
>>> > >
>>> > > covered by
>>> > >
>>> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>>> > > ...
>>> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>>> >
>>> > OK. I mistakenly understood those regions could be freed after exiting
>>> > UEFI boot services.
>>> >
>>> > >
>>> > > >> So it seems that kexec does not honour the memblock_reserve() table
>>> > > >> when booting the next kernel.
>>> > > >
>>> > > > not really.
>>> > > >
>>> > > >> > (In other words, can or should we skip some part of ACPI-related init code
>>> > > >> > on crash dump kernel?)
>>> > > >> >
>>> > > >>
>>> > > >> I don't think so. And the change to the handling of ACPI reclaim
>>> > > >> regions only revealed the bug, not created it (given that other
>>> > > >> memblock_reserve regions may be affected as well)
>>> > > >
>>> > > > As whether we should honor such reserved regions over kexec'ing
>>> > > > depends on each one's specific nature, we will have to take care one-by-one.
>>> > > > As a matter of fact, no information about "reserved" memblocks is
>>> > > > exposed to user space (via proc/iomem).
>>> > > >
>>> > >
>>> > > That is why I suggested (somewhere in this thread?) to not expose them
>>> > > as 'System RAM'. Do you think that could solve this?
>>> >
>>> > Memblock-reserv'ing them is necessary to prevent their corruption and
>>> > marking them under another name in /proc/iomem would also be good in order
>>> > not to allocate them as part of crash kernel's memory.
>>> >
>>> > But I'm not still convinced that we should export them in useable-
>>> > memory-range to crash dump kernel. They will be accessed through
>>> > acpi_os_map_memory() and so won't be required to be part of system ram
>>> > (or memblocks), I guess.
>>> > -> Bhupesh?
>>>
>>> I forgot how arm64 kernel retrieve the memory ranges and initialize
>>> them. If no "e820" like interfaces shouldn't kernel reinitialize all
>>> the memory according to the efi memmap? For kdump kernel anything other
>>> than usable memory (which is from the dt node instead) should be
>>> reinitialized according to efi passed info, no?
>>
>> All the regions exported in efi memmap will be added to memblock.memory
>> in (u)efi_init() and then trimmed down to the exact range specified as
>> usable-memory-range by fdt_enforce_memory_region().
>>
>> Now I noticed that the current fdt_enforce_memory_region() may not work well
>> with multiple entries in usable-memory-range.
>>
>
> In any case, the root of the problem is that memory regions lose their
> 'memory' annotation due to the way the memory map is mangled before
> being supplied to the kexec kernel.
>
> Would it be possible to classify all memory that we want to hide from
> the kexec kernel as NOMAP instead? That way, it will not be mapped
> implicitly, but will still be mapped cacheable by acpi_os_ioremap(),
> so this seems to be the most appropriate way to deal with the host
> kernel's memory contents.
Hmm. wouldn't appending the acpi reclaim regions to
'linux,usable-memory-range' in the dtb being passed to the crashkernel
be better? Because its indirectly achieving a similar objective
(although may be a subset of all System RAM regions on the primary
kernel's memory).
I am not aware of the background about the current kexec-tools
implementation where we add only the crashkernel range to the dtb
being passed to the crashkernel.
Probably Akashi can answer better, as to how we arrived at this design
approach and why we didn't want to expose all System RAM regions (i.e.
! NOMPAP regions) to the crashkernel.
I am suspecting that some issues were seen/meet when the System RAM (!
NOMAP regions) were exposed to the crashkernel, and that's why we
finalized on this design approach, but this is something which is just
my guess.
Regards,
Bhupesh
>>> >
>>> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>>> > via a kernel command line parameter, "memmap=".
>>>
>>> memmap= is only used in old kexec-tools, now we are passing them via
>>> e820 table.
>>
>> Thanks. I remember that you have explained it before.
>>
>> -Takahiro AKASHI
>>
>>> [snip]
>>>
>>> Thanks
>>> Dave
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: mtd: add Marvell NAND controller documentation
From: Rob Herring @ 2017-12-20 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219132942.27433-2-miquel.raynal@free-electrons.com>
On Tue, Dec 19, 2017 at 02:29:38PM +0100, Miquel Raynal wrote:
> Document the legacy and the new bindings for Marvell NAND controller.
>
> The pxa3xx_nand.c driver does only support legacy bindings, which are
> incomplete and inaccurate. A rework of this controller (called
> marvell_nand.c) does support both.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> .../devicetree/bindings/mtd/marvell-nand.txt | 123 +++++++++++++++++++++
> 1 file changed, 123 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/marvell-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/marvell-nand.txt b/Documentation/devicetree/bindings/mtd/marvell-nand.txt
> new file mode 100644
> index 000000000000..aa6a1ed045b2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/marvell-nand.txt
> @@ -0,0 +1,123 @@
> +Marvell NAND Flash Controller (NFC)
> +
> +Required properties:
> +- compatible: can be one of the following:
> + * "marvell,armada-8k-nand-controller"
> + * "marvell,armada370-nand-controller"
> + * "marvell,pxa3xx-nand-controller"
> + * "marvell,armada-8k-nand" (deprecated)
> + * "marvell,armada370-nand" (deprecated)
> + * "marvell,pxa3xx-nand" (deprecated)
> + Compatibles marked deprecated support only the old bindings described
> + at the bottom.
> +- reg: NAND flash controller memory area.
> +- #address-cells: shall be set to 1. Encode the NAND CS.
> +- #size-cells: shall be set to 0.
> +- interrupts: shall define the NAND controller interrupt.
> +- clocks: shall reference the NAND controller clock.
> +- marvell,system-controller: Set to retrieve the syscon node that handles
> + NAND controller related registers (only required with the
> + "marvell,armada-8k-nand[-controller]" compatibles).
> +
> +Optional properties:
> +- label: see partition.txt. New platforms shall omit this property.
> +- dmas: shall reference DMA channel associated to the NAND controller.
> + This property is only used with "marvell,pxa3xx-nand[-controller]"
> + compatible strings.
> +- dma-names: shall be "rxtx".
> + This property is only used with "marvell,pxa3xx-nand[-controller]"
> + compatible strings.
> +
> +Optional children nodes:
> +Children nodes represent the available NAND chips.
> +
> +Required properties:
> +- reg: shall contain the native Chip Select ids (0-3)
> +- marvell,rb: shall contain the native Ready/Busy ids (0-1)
We already have at least 2 other <vendor>,rb properties. Let's not add a
3rd and make a common one instead.
> +
> +Optional properties:
> +- marvell,nand-keep-config: orders the driver not to take the timings
> + from the core and leaving them completely untouched. Bootloader
> + timings will then be used.
> +- label: MTD name.
> +- nand-on-flash-bbt: see nand.txt.
> +- nand-ecc-mode: see nand.txt. Will use hardware ECC if not specified.
> +- nand-ecc-algo: see nand.txt. This property may be added when using
> + hardware ECC for clarification but will be ignored by the driver
> + because ECC mode is chosen depending on the page size and the strength
> + required by the NAND chip. This value may be overwritten with
> + nand-ecc-strength property.
If not used, then drop it.
> +- nand-ecc-strength: see nand.txt.
> +- nand-ecc-step-size: see nand.txt. This has no effect and will be
> + ignored by the driver when using hardware ECC because Marvell's NAND
> + flash controller does use fixed strength (1-bit for Hamming, 16-bit
> + for BCH), so the step size will shrink or grow in order to fit the
> + required strength. Step sizes are not completely random for all and
> + follow certain patterns described in AN-379, "Marvell SoC NFC ECC".
Same here.
> +
> +See Documentation/devicetree/bindings/mtd/nand.txt for more details on
> +generic bindings.
> +
> +
> +Example:
> +nand_controller: nand-controller at d0000 {
> + compatible = "marvell,armada370-nand-controller";
> + reg = <0xd0000 0x54>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&coredivclk 0>;
> +
> + nand at 0 {
> + reg = <0>;
> + label = "main-storage";
> + marvell,rb = <0>;
> + nand-ecc-mode = "hw";
> + marvell,nand-keep-config;
> + nand-on-flash-bbt;
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition at 0 {
> + label = "Rootfs";
> + reg = <0x00000000 0x40000000>;
> + };
> + };
> + };
> +};
> +
> +
> +Note on legacy bindings: One can find, in not-updated device trees,
> +bindings slightly differents than described above with other properties
s/differents/different/
> +described below as well as the partitions node at the root of a so
> +called "nand" node (without clear controller/chip separation).
> +
> +Legacy properties:
> +- marvell,nand-enable-arbiter: To enable the arbiter, all boards blindly
> + used it, this bit was set by the bootloader for many boards and even if
> + it is marked reserved in several datasheets, it might be needed to set
> + it (otherwise it is harmless) so whether or not this property is set,
> + the bit is selected by the driver.
> +- num-cs: Number of chip-select lines to use, all boards blindly set 1
> + to this and for a reason, other values would have failed. The value of
> + this property is ignored.
> +
> +Example:
> +
> + nand0: nand at 43100000 {
> + compatible = "marvell,pxa3xx-nand";
> + reg = <0x43100000 90>;
> + interrupts = <45>;
> + dmas = <&pdma 97 0>;
> + dma-names = "rxtx";
> + #address-cells = <1>;
> + marvell,nand-keep-config;
> + marvell,nand-enable-arbiter;
> + num-cs = <1>;
> + /* Partitions (optional) */
> + };
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH v2 4/5] dt-bindings: mtd: remove pxa3xx NAND controller documentation
From: Rob Herring @ 2017-12-20 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219132942.27433-5-miquel.raynal@free-electrons.com>
On Tue, Dec 19, 2017 at 02:29:41PM +0100, Miquel Raynal wrote:
> The deprecated pxa3xx_nand.c driver does not exist anymore, it has been
> replaced by marvell_nand.c which has its own up-to-date documentation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> .../devicetree/bindings/mtd/pxa3xx-nand.txt | 50 ----------------------
> 1 file changed, 50 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Rob Herring @ 2017-12-20 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219135719.9531-2-miquel.raynal@free-electrons.com>
On Tue, Dec 19, 2017 at 02:57:09PM +0100, Miquel Raynal wrote:
> From: Baruch Siach <baruch@tkos.co.il>
>
> Add compatible strings for AP806 and CP110 that are part of the Armada
> 8k/7k line of SoCs.
>
> Add a note on the differences in the size of the control area in
> different bindings. This is an existing difference between the Armada
> 375 binding and the other boards already supported. The new AP806 and
> CP110 bindings are similar to the existing Armada 375 in this regard.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> [<miquel.raynal@free-electrons.com>: reword, additional details]
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> .../devicetree/bindings/thermal/armada-thermal.txt | 37 +++++++++++++++-------
> 1 file changed, 25 insertions(+), 12 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 05/15] devicetree: bindings: Document qcom,hfpll
From: Rob Herring @ 2017-12-20 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513698900-10638-6-git-send-email-sricharan@codeaurora.org>
On Tue, Dec 19, 2017 at 09:24:50PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> Adds bindings document for qcom,hfpll instantiated within
> the Krait processor subsystem as separate register region.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,hfpll.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
"dt-bindings: " is the preferred subject prefix. Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 10/15] devicetree: bindings: Document qcom,kpss-gcc
From: Rob Herring @ 2017-12-20 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513698900-10638-11-git-send-email-sricharan@codeaurora.org>
On Tue, Dec 19, 2017 at 09:24:55PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> The ACC and GCC regions present in KPSSv1 contain registers to
> control clocks and power to each Krait CPU and L2. Documenting
> the bindings here.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 7 +++++
> .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt | 32 ++++++++++++++++++++++
> 2 files changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 12/15] devicetree: bindings: Document qcom,krait-cc
From: Rob Herring @ 2017-12-20 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513698900-10638-13-git-send-email-sricharan@codeaurora.org>
On Tue, Dec 19, 2017 at 09:24:57PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> The Krait clock controller controls the krait CPU and the L2 clocks
> consisting a primary mux and secondary mux. Add document for that.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,krait-cc.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Rob Herring @ 2017-12-20 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0d8147a-46e1-0787-ae37-9c1ef957d190@codeaurora.org>
On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
> Hi Viresh,
>
> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
> > On 19-12-17, 21:25, Sricharan R wrote:
> >> + cpu at 0 {
> >> + compatible = "qcom,krait";
> >> + enable-method = "qcom,kpss-acc-v1";
> >> + device_type = "cpu";
> >> + reg = <0>;
> >> + qcom,acc = <&acc0>;
> >> + qcom,saw = <&saw0>;
> >> + clocks = <&kraitcc 0>;
> >> + clock-names = "cpu";
> >> + cpu-supply = <&smb208_s2a>;
> >> + operating-points-v2 = <&cpu_opp_table>;
> >> + };
> >> +
> >> + qcom,pvs {
> >> + qcom,pvs-format-a;
> >> + };
> >
> > Not sure what Rob is going to say on that :)
> >
>
> Yes. Would be good to know the best way.
Seems like this should be a property of an efuse node either implied by
the compatible or a separate property. What determines format A vs. B?
Rob
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
From: Rob Herring @ 2017-12-20 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-3-f.fainelli@gmail.com>
On Tue, Dec 19, 2017 at 11:22:40AM -0800, Florian Fainelli wrote:
> Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose
> compatible string is actually brcm,bcm<chip-id>-cpu-biu-ctrl. Also
> document in the binding the fallback property
> ("brcm,brcmstb-cpu-biu-ctrl") and update the example accordingly.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> .../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4 0/4] rtc: add mxc driver for i.MX53 SRTC
From: Alexandre Belloni @ 2017-12-20 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218115133.16371-1-linux-kernel-dev@beckhoff.com>
On 18/12/2017 at 12:51:29 +0100, linux-kernel-dev at beckhoff.com wrote:
> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>
> Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
>
> This is driver enables support for the low power domain SRTC features:
> - 32-bit MSB of non-rollover time counter
> - 32-bit alarm register
>
> Select the new config option RTC_DRV_MXC_V2 to build this driver
>
> Based on:
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-mxc_v2.c?h=imx_2.6.35_11.09.01
>
> Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
>
Applied 1/4 and 3/4, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Robert Jarzmik @ 2017-12-20 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218092535.2ca1fe13@xps13>
Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
> Hello Robert,
>
> On Mon, 18 Dec 2017 08:11:35 +0100
> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
>> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>>
>> >> Robert, it would be great if you could also do more testing on PXA
>> >> and validate this driver. If needed, a branch ready to be tested is
>> >> available at [3]. It is based on nand/next and has all the changes
>> >> brought by the previously mentionned series as well as this one.
>> >
>> > Robert, do you think you'll have some time to test Miquel's branch
>> > on your PXA boards? Miquel already tested on one of these boards
>> > (CM-X300), but we'd like to have other testers. Also feel free to
>> > review the driver if have the time.
>> >
>> > Thanks,
>> >
>> > Boris
>>
>> Hi Boris and Miquel,
>>
>> I have applied the whole serie to linux-next yesterday.
>>
>> A boot attempt on my zylonite with my old defconfig (with the new
>> Marvell NAND config activated) yields to :
>> - this message
>> [ 3.136818] marvell-nfc pxa3xx-nand: could not identify the nand
>> chip [ 3.143874] marvell-nfc: probe of pxa3xx-nand failed with
>> error -22
>> - then my board hangs
>>
>> Is there something to be done to improve the trace level so that you
>> can guess what's happening ?
>
> Thank you very much for testing this.
>
> Could you please try this branch [1] instead of linux-next + the
> patches?
>
> Also, can you please add #define DEBUG in marvell_nand.c + nand_base.c,
> it should help us figuring out what is wrong.
Done, same result, the dmesg is in [1].
Cheers.
--
Robert
[1] Kernel output
Loading ARM Linux zImage '/mnt/tftp/zImage_jenkins'
commandline: ram=64M console=ttyS0,115200 ip=dhcp root=/dev/nfs nfsroot=/home/none/nfsroot/zylonite,v3,tcp earlycon mtdparts=pxa3xx_nand-0:128k at 0(TIMH)ro,128k at 128k(OBMI)ro,768k at 256k(barebox),256k at 1024k(barebox-env),12M at 1280k(kernel),38016k at 13568k(root)
arch_number: 1233
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.15.0-rc1-00041-g4dc0195 (jenkins at belgarath) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29)) #721 PREEMPT Wed Dec 20 22:15:08 CET 2017
[ 0.000000] CPU: XScale-V3 based processor [69056891] revision 1 (ARMv5TE), cr=0000397f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: PXA3xx Platform Development Kit (aka Zylonite)
[ 0.000000] Ignoring tag cmdline (using the default kernel command line)
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] RO Mode clock: 0.00MHz
[ 0.000000] Run Mode clock: 0.00MHz
[ 0.000000] Turbo Mode clock: 0.00MHz
[ 0.000000] System bus clock: 0.00MHz
[ 0.000000] On node 0 totalpages: 16384
[ 0.000000] Normal zone: 128 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 16384 pages, LIFO batch:3
[ 0.000000] random: fast init done
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: root=/dev/ram0 ip=192.168.1.232:192.168.1.5::255.255.255.0::eth0:on console=ttyS0,115200 mem=64M mtdparts=pxa3xx_nand-0:128k at 0(TIMH)ro,128k at 128k(OBMI)ro,768k at 256k(barebox),256k at 1024k(barebox-env),12M at 1280k(kernel),38016k at 13568k(root) ubi.mtd=5 earlycon=pxa,io,0xf6200000,115200n8 debug no_console_suspend
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Memory: 56856K/65536K available (4225K kernel code, 202K rwdata, 972K rodata, 2396K init, 102K bss, 8680K reserved, 0K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc04289e8 (4227 kB)
[ 0.000000] .init : 0xc053f000 - 0xc0796000 (2396 kB)
[ 0.000000] .data : 0xc0796000 - 0xc07c8bec ( 203 kB)
[ 0.000000] .bss : 0xc07c8bec - 0xc07e25fc ( 103 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] NR_IRQS: 16, nr_irqs: 336, preallocated irqs: 336
[ 0.000000] RJK: parent_rate=13000000, xl=8, xn=1
[ 0.000069] sched_clock: 32 bits at 3250kHz, resolution 307ns, wraps every 660764198758ns
[ 0.000267] clocksource: oscr0: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 588080137591 ns
[ 0.002142] Console: colour dummy device 80x30
[ 0.002302] Calibrating delay loop... 103.83 BogoMIPS (lpj=519168)
[ 0.081019] pid_max: default: 32768 minimum: 301
[ 0.081860] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.081960] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.085178] CPU: Testing write buffer coherency: ok
[ 0.089002] Setting up static identity map for 0x80008200 - 0x80008260
[ 0.089962] Hierarchical SRCU implementation.
[ 0.102994] devtmpfs: initialized
[ 0.113882] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.114023] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 0.116361] NET: Registered protocol family 16
[ 0.119175] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.389891] Advanced Linux Sound Architecture Driver Initialized.
[ 0.394261] clocksource: Switched to clocksource oscr0
[ 0.552465] NET: Registered protocol family 2
[ 0.559531] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.559757] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.559938] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.560478] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.560660] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.561794] NET: Registered protocol family 1
[ 0.563834] RPC: Registered named UNIX socket transport module.
[ 0.563934] RPC: Registered udp transport module.
[ 0.563988] RPC: Registered tcp transport module.
[ 0.564046] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.503938] Initialise system trusted keyrings
[ 2.506180] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[ 2.510083] NFS: Registering the id_resolver key type
[ 2.510312] Key type id_resolver registered
[ 2.510374] Key type id_legacy registered
[ 2.516887] Key type asymmetric registered
[ 2.516991] Asymmetric key parser 'x509' registered
[ 2.517149] io scheduler noop registered
[ 2.517213] io scheduler deadline registered
[ 2.517601] io scheduler cfq registered (default)
[ 2.517671] io scheduler mq-deadline registered
[ 2.517732] io scheduler kyber registered
[ 2.577937] pxa-dma pxa-dma.0: initialized 32 channels on 100 requestors
[ 2.581363] pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 38, base_baud = 928571) is a UART1
[ 3.056921] console [ttyS0] enabled
[ 3.063284] pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 37, base_baud = 928571) is a UART2
[ 3.076187] pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 36, base_baud = 928571) is a UART3
[ 3.091759] nand: executing subop:
[ 3.097924] nand: ->CMD [0xff]
[ 3.101830] nand: ->WAITRDY [max 250 ms]
[ 3.106998] marvell-nfc pxa3xx-nand:
[ 3.106998] NDCR: 0x90079fff
[ 3.106998] NDCB0: 0x00a000ff
[ 3.106998] NDCB1: 0x00000000
[ 3.106998] NDCB2: 0x00000000
[ 3.106998] NDCB3: 0x00000000
[ 3.126261] nand: executing subop:
[ 3.129732] nand: ->CMD [0x90]
[ 3.133605] nand: ->ADDR [1 cyc: 00]
[ 3.138275] nand: ->DATA_IN [2 B, force 8-bit]
[ 3.143276] marvell-nfc pxa3xx-nand:
[ 3.143276] NDCR: 0x90079fff
[ 3.143276] NDCB0: 0x00610090
[ 3.143276] NDCB1: 0x00000000
[ 3.143276] NDCB2: 0x00000000
[ 3.143276] NDCB3: 0x00000000
[ 3.162111] nand: executing subop:
[ 3.165754] nand: ->CMD [0x90]
[ 3.169644] nand: ->ADDR [1 cyc: 00]
[ 3.173945] nand: ->DATA_IN [8 B, force 8-bit]
[ 3.179056] marvell-nfc pxa3xx-nand:
[ 3.179056] NDCR: 0x90079fff
[ 3.179056] NDCB0: 0x00610090
[ 3.179056] NDCB1: 0x00000000
[ 3.179056] NDCB2: 0x00000000
[ 3.179056] NDCB3: 0x00000000
[ 3.197729] nand: executing subop:
[ 3.201185] nand: ->CMD [0x90]
[ 3.205207] nand: ->ADDR [1 cyc: 20]
[ 3.209519] nand: ->DATA_IN [4 B, force 8-bit]
[ 3.214626] marvell-nfc pxa3xx-nand:
[ 3.214626] NDCR: 0x90079fff
[ 3.214626] NDCB0: 0x00610090
[ 3.214626] NDCB1: 0x00000020
[ 3.214626] NDCB2: 0x00000000
[ 3.214626] NDCB3: 0x00000000
[ 3.233249] nand: executing subop:
[ 3.236837] nand: ->CMD [0x90]
[ 3.240719] nand: ->ADDR [1 cyc: 40]
[ 3.245158] nand: ->DATA_IN [5 B, force 8-bit]
[ 3.250133] marvell-nfc pxa3xx-nand:
[ 3.250133] NDCR: 0x90079fff
[ 3.250133] NDCB0: 0x00610090
[ 3.250133] NDCB1: 0x00000040
[ 3.250133] NDCB2: 0x00000000
[ 3.250133] NDCB3: 0x00000000
[ 3.268756] nand: device found, Manufacturer ID: 0x20, Chip ID: 0xba
[ 3.275239] nand: ST Micro pxa3xx-nand
[ 3.279028] nand: bus width 8 instead of 16 bits
[ 3.283651] nand: No NAND device found
[ 3.287582] marvell-nfc pxa3xx-nand: could not identify the nand chip
[ 3.294466] marvell-nfc: probe of pxa3xx-nand failed with error -22
^ permalink raw reply
* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Boris Brezillon @ 2017-12-20 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y3lxccr7.fsf@belgarion.home>
On Wed, 20 Dec 2017 22:26:04 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
>
> > Hello Robert,
> >
> > On Mon, 18 Dec 2017 08:11:35 +0100
> > Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> >
> >> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
> >>
> >> >> Robert, it would be great if you could also do more testing on PXA
> >> >> and validate this driver. If needed, a branch ready to be tested is
> >> >> available at [3]. It is based on nand/next and has all the changes
> >> >> brought by the previously mentionned series as well as this one.
> >> >
> >> > Robert, do you think you'll have some time to test Miquel's branch
> >> > on your PXA boards? Miquel already tested on one of these boards
> >> > (CM-X300), but we'd like to have other testers. Also feel free to
> >> > review the driver if have the time.
> >> >
> >> > Thanks,
> >> >
> >> > Boris
> >>
> >> Hi Boris and Miquel,
> >>
> >> I have applied the whole serie to linux-next yesterday.
> >>
> >> A boot attempt on my zylonite with my old defconfig (with the new
> >> Marvell NAND config activated) yields to :
> >> - this message
> >> [ 3.136818] marvell-nfc pxa3xx-nand: could not identify the nand
> >> chip [ 3.143874] marvell-nfc: probe of pxa3xx-nand failed with
> >> error -22
> >> - then my board hangs
> >>
> >> Is there something to be done to improve the trace level so that you
> >> can guess what's happening ?
> >
> > Thank you very much for testing this.
> >
> > Could you please try this branch [1] instead of linux-next + the
> > patches?
> >
> > Also, can you please add #define DEBUG in marvell_nand.c + nand_base.c,
> > it should help us figuring out what is wrong.
>
> Done, same result, the dmesg is in [1].
Looks like there is a mismatch on the nand bus width detected by the
core and the one declared by the driver. Can you try with the following
diff applied?
Thanks,
Boris
--->8---
diff --git a/drivers/mtd/nand/marvell_nand.c b/drivers/mtd/nand/marvell_nand.c
index c618ccb22a61..ddd6a07888e2 100644
--- a/drivers/mtd/nand/marvell_nand.c
+++ b/drivers/mtd/nand/marvell_nand.c
@@ -2481,6 +2481,7 @@ static int marvell_nand_chip_init(struct device *dev, struct marvell_nfc *nfc,
*/
chip->ecc.mode = NAND_ECC_HW;
+ chip->options |= NAND_BUSWIDTH_AUTO;
ret = nand_scan_ident(mtd, marvell_nand->nsels, NULL);
if (ret) {
dev_err(dev, "could not identify the nand chip\n");
^ permalink raw reply related
* [PATCH] arm64: dts: stratix10: fix SPI settings
From: thor.thayer at linux.intel.com @ 2017-12-20 21:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Thor Thayer <thor.thayer@linux.intel.com>
Correct the SPI Master node settings.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index 7c9bdc7ab50b..367bc00be802 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -248,7 +248,9 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0xffda4000 0x1000>;
- interrupts = <0 101 4>;
+ interrupts = <0 99 4>;
+ resets = <&rst SPIM0_RESET>;
+ reg-io-width = <4>;
num-chipselect = <4>;
bus-num = <0>;
status = "disabled";
@@ -259,7 +261,9 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0xffda5000 0x1000>;
- interrupts = <0 102 4>;
+ interrupts = <0 100 4>;
+ resets = <&rst SPIM1_RESET>;
+ reg-io-width = <4>;
num-chipselect = <4>;
bus-num = <0>;
status = "disabled";
--
2.7.4
^ permalink raw reply related
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Rob Herring @ 2017-12-20 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219210523.10428-1-kevans91@ksu.edu>
On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> thermal calibration data, add node to describe it.
>
> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> supported in an external driver for FreeBSD.
>
> Signed-off-by: Kyle Evans <kevans91@ksu.edu>
> ---
>
> Changes in v2:
> - remove bogus "From:" line in commit text; no functional change
>
> Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
> arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
> 2 files changed, 6 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 02/20] dt-bindings: gpio: Add ASPEED constants
From: Rob Herring @ 2017-12-20 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220032328.30584-3-joel@jms.id.au>
On Wed, Dec 20, 2017 at 01:53:10PM +1030, Joel Stanley wrote:
> These are used to by the device tree to map pin numbers to constants
> required by the GPIO bindings.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> --
> v3:
> - Remove dtsi includes from this patch, they will come later
> ---
> include/dt-bindings/gpio/aspeed-gpio.h | 49 ++++++++++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 0/4] vf610-zii-dev updates
From: Russell King - ARM Linux @ 2017-12-20 23:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
These patches update the DT for the ZII VF610 boards.
The first patch fixes complaints at boot about missing DMAs on rev C
boards, particularly for the SPI interface. This is because edma1 is
not enabled. This seems to be a regression from the 4.10 era.
The second patch fixes an interrupt storm during boot on rev B boards,
which causes boot to take 80+ seconds - this seems to be a long
standing issue since the DT description was first added. The PTB28
pin is definitely GPIO 98, and GPIO 98 is definitely part of the
gpio3 block, not the gpio2 block. Since GPIO 66 (which is the
corresponding GPIO in gpio2) is low, and the IRQ trigger is level-low,
this causes an interrupt storm.
The last two patches add an explicit description of the PHYs that are
actually connected to the switch - the 88e1545 is a quad PHY, and
without describing the MDIO bus, DSA assumes that any PHYs it can
discover are present for the switch. As only the first three PHYs
are connected, this leads the 4th port to believe it is connected to
the 4th PHY when the fixed-link definition is (eventually) removed.
Head this off by providing the proper descriptions, and as we have
them, also describe the interrupts for these PHYs.
Note, however, that the interrupt description is not quite correct -
the 88e1545 PHYs all share one interrupt line, and there is a register
in the PHY which can be used to demux the interrupt to the specific
PHY. However, in this description, we ignore the demux register, and
just share the interrupt between the PHYs. That much is fine, but
the pinmuxing becomes problematical - if we describe the same pinmux
settings for each PHY for the interrupt line, the 2nd/3rd PHYs fail.
This has no known solution. Suggestions welcome.
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 34 ++++++++++++++++++++++++++++++-
arch/arm/boot/dts/vf610-zii-dev.dtsi | 4 ++++
2 files changed, 37 insertions(+), 1 deletion(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/4] ARM: dts: vf610-zii-dev: enable edma1
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220231108.GJ10595@n2100.armlinux.org.uk>
EDMA1 is required for the SPI controller used on the ZII boards to be
functional. Enable EDMA1.
Fixes: 14c416336820 ("ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/vf610-zii-dev.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi b/arch/arm/boot/dts/vf610-zii-dev.dtsi
index 6b58d3a97992..aadd36db0092 100644
--- a/arch/arm/boot/dts/vf610-zii-dev.dtsi
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -96,6 +96,10 @@
status = "okay";
};
+&edma1 {
+ status = "okay";
+};
+
&esdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_esdhc1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: vf610-zii-dev-rev-b: fix interrupt for GPIO expander
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220231108.GJ10595@n2100.armlinux.org.uk>
The interrupt specification for the GPIO expander is wrong - the
expander is wired to PTB28, which is GPIO98. GPIO98 is on gpio chip
3, not 2.
In addition, the device is missing a required property. Interrupt
controllers must have the "interrupt-controller" property specified.
Add this.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index acdf12ad0622..ede8649ba515 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -371,7 +371,8 @@
reg = <0x22>;
gpio-controller;
#gpio-cells = <2>;
- interrupt-parent = <&gpio2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio3>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox