* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Bhupesh Sharma @ 2020-06-01 21:02 UTC (permalink / raw)
To: John Donnelly
Cc: Prabhakar Kushwaha, Chen Zhou, Simon Horman, Devicetree List,
Baoquan He, Will Deacon, Linux Doc Mailing List, Catalin Marinas,
kexec mailing list, Linux Kernel Mailing List, Rob Herring,
Ingo Molnar, Arnd Bergmann, guohanjun, James Morse,
Thomas Gleixner, Prabhakar Kushwaha, RuiRui Yang,
linux-arm-kernel
In-Reply-To: <303695cc-d3ea-9f51-1489-07d27d4253d4@oracle.com>
Hi John,
On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
>
> Hi,
>
>
> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> > Hi Chen,
> >
> > On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
> >> This patch series enable reserving crashkernel above 4G in arm64.
> >>
> >> There are following issues in arm64 kdump:
> >> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> >> when there is no enough low memory.
> >> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> >> in this case, if swiotlb or DMA buffers are required, crash dump kernel
> >> will boot failure because there is no low memory available for allocation.
> >>
> >> To solve these issues, introduce crashkernel=X,low to reserve specified
> >> size low memory.
> >> Crashkernel=X tries to reserve memory for the crash dump kernel under
> >> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
> >> size low memory for crash kdump kernel devices firstly and then reserve
> >> memory above 4G.
> >>
> >> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
> >> is specified simultaneously, kernel should reserve specified size low memory
> >> for crash dump kernel devices. So there may be two crash kernel regions, one
> >> is below 4G, the other is above 4G.
> >> In order to distinct from the high region and make no effect to the use of
> >> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
> >> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
> >>
> >> Besides, we need to modify kexec-tools:
> >> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
> >>
> >> The previous changes and discussions can be retrieved from:
> >>
> >> Changes since [v7]
> >> - Move x86 CRASH_ALIGN to 2M
> >> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
> >> - Update Documentation/devicetree/bindings/chosen.txt
> >> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
> >> - Add Tested-by from Jhon and pk
> >>
> >> Changes since [v6]
> >> - Fix build errors reported by kbuild test robot.
> >>
> >> Changes since [v5]
> >> - Move reserve_crashkernel_low() into kernel/crash_core.c.
> >> - Delete crashkernel=X,high.
> >> - Modify crashkernel=X,low.
> >> If crashkernel=X,low is specified simultaneously, reserve spcified size low
> >> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
> >> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
> >> pass to crash dump kernel by DT property "linux,low-memory-range".
> >> - Update Documentation/admin-guide/kdump/kdump.rst.
> >>
> >> Changes since [v4]
> >> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
> >>
> >> Changes since [v3]
> >> - Add memblock_cap_memory_ranges back for multiple ranges.
> >> - Fix some compiling warnings.
> >>
> >> Changes since [v2]
> >> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
> >> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
> >> patch.
> >>
> >> Changes since [v1]:
> >> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
> >> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
> >> in fdt_enforce_memory_region().
> >> There are at most two crash kernel regions, for two crash kernel regions
> >> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
> >> and then remove the memory range in the middle.
> >>
> >> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
> >> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
> >> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
> >> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
> >> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
> >> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
> >> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
> >> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
> >>
> >> Chen Zhou (5):
> >> x86: kdump: move reserve_crashkernel_low() into crash_core.c
> >> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
> >> arm64: kdump: add memory for devices by DT property, low-memory-range
> >> kdump: update Documentation about crashkernel on arm64
> >> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
> >>
> > We are getting "warn_alloc" [1] warning during boot of kdump kernel
> > with bootargs as [2] of primary kernel.
> > This error observed on ThunderX2 ARM64 platform.
> >
> > It is observed with latest upstream tag (v5.7-rc3) with this patch set
> > and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> > Also **without** this patch-set
> > "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
> >
> > This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
> > More details discussed earlier in
> > https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
> > solution
> >
> > This patch-set is expected to solve similar kind of issue.
> > i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
> > observation should be considered/fixed. .
> >
> > --pk
> >
> > [1]
> > [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> > TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> > [ 30.367696] NET: Registered protocol family 16
> > [ 30.369973] swapper/0: page allocation failure: order:6,
> > mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> > [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
> > [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
> > TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> > [ 30.369984] Call trace:
> > [ 30.369989] dump_backtrace+0x0/0x1f8
> > [ 30.369991] show_stack+0x20/0x30
> > [ 30.369997] dump_stack+0xc0/0x10c
> > [ 30.370001] warn_alloc+0x10c/0x178
> > [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
> > [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> > [ 30.370008] alloc_page_interleave+0x24/0x98
> > [ 30.370011] alloc_pages_current+0xe4/0x108
> > [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> > [ 30.370020] do_one_initcall+0x54/0x228
> > [ 30.370027] kernel_init_freeable+0x228/0x2cc
> > [ 30.370031] kernel_init+0x1c/0x110
> > [ 30.370034] ret_from_fork+0x10/0x18
> > [ 30.370036] Mem-Info:
> > [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
> > [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
> > [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
> > [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
> > [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> > [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> > [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> > isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> > unstable:0kB all_unreclaimable? no
> > [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> > isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> > unstable:0kB all_unreclaimable? no
> > [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
> > reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> > present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
> > bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> > [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
> > high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> > present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
> > pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> > [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
> > high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> > present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
> > pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
> > [ 30.370104] lowmem_reserve[]: 0 0 0 0
> > [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> > [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> > 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
> > [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
> > (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
> > 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> > [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> > hugepages_surp=0 hugepages_size=1048576kB
> > [ 30.370130] 0 total pagecache pages
> > [ 30.370132] 0 pages in swap cache
> > [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
> > [ 30.370135] Free swap = 0kB
> > [ 30.370136] Total swap = 0kB
> > [ 30.370137] 2164609 pages RAM
> > [ 30.370139] 0 pages HighMem/MovableOnly
> > [ 30.370140] 612331 pages reserved
> > [ 30.370141] 0 pages hwpoisoned
> > [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
> > coherent allocation
>
>
> During my testing I saw the same error and Chen's solution corrected it .
Which combination you are using on your side? I am using Prabhakar's
suggested environment and can reproduce the issue
with or without Chen's crashkernel support above 4G patchset.
I am also using a ThunderX2 platform with latest makedumpfile code and
kexec-tools (with the suggested patch
<https://lists.infradead.org/pipermail/kexec/2020-May/025128.html>).
Thanks,
Bhupesh
^ permalink raw reply
* Re: [PATCH v4 07/10] PCI: qcom: Define some PARF params needed for ipq8064 SoC
From: Rob Herring @ 2020-06-01 21:04 UTC (permalink / raw)
To: Ansuel Smith
Cc: linux-pci, stable, Philipp Zabel, linux-kernel, devicetree,
Andy Gross, Stanimir Varbanov, Andrew Murray, linux-arm-msm,
Bjorn Helgaas, Rob Herring, Bjorn Andersson, Lorenzo Pieralisi,
Mark Rutland
In-Reply-To: <20200514200712.12232-8-ansuelsmth@gmail.com>
On Thu, 14 May 2020 22:07:08 +0200, Ansuel Smith wrote:
> Set some specific value for Tx De-Emphasis, Tx Swing and Rx equalization
> needed on some ipq8064 based device (Netgear R7800 for example). Without
> this the system locks on kernel load.
>
> Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver")
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> Cc: stable@vger.kernel.org # v4.5+
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 27 ++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and set tx term offset
From: Rob Herring @ 2020-06-01 21:08 UTC (permalink / raw)
To: Ansuel Smith
Cc: Bjorn Andersson, Sham Muthayyan, Andy Gross, Bjorn Helgaas,
Mark Rutland, Stanimir Varbanov, Lorenzo Pieralisi, Andrew Murray,
Philipp Zabel, linux-arm-msm, linux-pci, devicetree, linux-kernel
In-Reply-To: <20200514200712.12232-9-ansuelsmth@gmail.com>
On Thu, May 14, 2020 at 10:07:09PM +0200, Ansuel Smith wrote:
> Add tx term offset support to pcie qcom driver need in some revision of
> the ipq806x SoC. Ipq8064 have tx term offset set to 7. Ipq8064-v2 revision
> and ipq8065 have the tx term offset set to 0.
Seems like this should be 2 patches or why isn't 'Ipq8064 have tx term
offset set to 7' done in the prior patch? One tweak is needed for
stable, but this isn't?
>
> Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index f5398b0d270c..ab6f1bdd24c3 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -45,6 +45,9 @@
> #define PCIE_CAP_CPL_TIMEOUT_DISABLE 0x10
>
> #define PCIE20_PARF_PHY_CTRL 0x40
> +#define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK GENMASK(20, 16)
> +#define PHY_CTRL_PHY_TX0_TERM_OFFSET(x) ((x) << 16)
> +
> #define PCIE20_PARF_PHY_REFCLK 0x4C
> #define PHY_REFCLK_SSP_EN BIT(16)
> #define PHY_REFCLK_USE_PAD BIT(12)
> @@ -363,7 +366,8 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
> val &= ~BIT(0);
> writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
>
> - if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> + if (of_device_is_compatible(node, "qcom,pcie-ipq8064") |
> + of_device_is_compatible(node, "qcom,pcie-ipq8064-v2")) {
> writel(PCS_DEEMPH_TX_DEEMPH_GEN1(24) |
> PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(24) |
> PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(34),
> @@ -374,9 +378,18 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
> writel(PHY_RX0_EQ(4), pcie->parf + PCIE20_PARF_CONFIG_BITS);
> }
>
> + if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> + /* set TX termination offset */
> + val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> + val &= ~PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK;
> + val |= PHY_CTRL_PHY_TX0_TERM_OFFSET(7);
> + writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> + }
> +
> /* enable external reference clock */
> val = readl(pcie->parf + PCIE20_PARF_PHY_REFCLK);
> - val |= BIT(16);
> + val &= ~PHY_REFCLK_USE_PAD;
> + val |= PHY_REFCLK_SSP_EN;
> writel(val, pcie->parf + PCIE20_PARF_PHY_REFCLK);
>
> /* wait for clock acquisition */
> @@ -1452,6 +1465,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> static const struct of_device_id qcom_pcie_match[] = {
> { .compatible = "qcom,pcie-apq8084", .data = &ops_1_0_0 },
> { .compatible = "qcom,pcie-ipq8064", .data = &ops_2_1_0 },
> + { .compatible = "qcom,pcie-ipq8064-v2", .data = &ops_2_1_0 },
> { .compatible = "qcom,pcie-apq8064", .data = &ops_2_1_0 },
> { .compatible = "qcom,pcie-msm8996", .data = &ops_2_3_2 },
> { .compatible = "qcom,pcie-ipq8074", .data = &ops_2_3_3 },
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v4 10/10] PCI: qcom: Add Force GEN1 support
From: Rob Herring @ 2020-06-01 21:10 UTC (permalink / raw)
To: Ansuel Smith
Cc: linux-pci, Rob Herring, Andy Gross, linux-arm-msm, Mark Rutland,
Stanimir Varbanov, devicetree, Sham Muthayyan, Lorenzo Pieralisi,
linux-kernel, Bjorn Helgaas, Andrew Murray, Bjorn Andersson,
Philipp Zabel
In-Reply-To: <20200514200712.12232-11-ansuelsmth@gmail.com>
On Thu, 14 May 2020 22:07:11 +0200, Ansuel Smith wrote:
> From: Sham Muthayyan <smuthayy@codeaurora.org>
>
> Add Force GEN1 support needed in some ipq8064 board that needs to limit
> some PCIe line to gen1 for some hardware limitation. This is set by the
> max-link-speed binding and needed by some soc based on ipq8064. (for
> example Netgear R7800 router)
>
> Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 4/5] PCI: uniphier: Add iATU register support
From: Rob Herring @ 2020-06-01 21:32 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Masahiro Yamada, linux-pci, devicetree, linux-arm-kernel,
linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1589536743-6684-5-git-send-email-hayashi.kunihiko@socionext.com>
On Fri, May 15, 2020 at 06:59:02PM +0900, Kunihiko Hayashi wrote:
> This gets iATU register area from reg property. In Synopsis DWC version
> 4.80 or later, since iATU register area is separated from core register
> area, this area is necessary to get from DT independently.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index a8dda39..493f105 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -447,6 +447,13 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
> if (IS_ERR(priv->pci.dbi_base))
> return PTR_ERR(priv->pci.dbi_base);
>
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> + if (res) {
> + priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
This isn't config space, so this function shouldn't be used.
Use devm_platform_ioremap_resource_byname().
> + if (IS_ERR(priv->pci.atu_base))
> + priv->pci.atu_base = NULL;
> + }
> +
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
> priv->base = devm_ioremap_resource(dev, res);
Feel free to convert this one too.
> if (IS_ERR(priv->base))
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 0/3] media: rockchip: Introduce driver for the camera interface on PX30
From: Heiko Stübner @ 2020-06-01 21:38 UTC (permalink / raw)
To: Tomasz Figa
Cc: Maxime Chevallier, Helen Koike, Dafna Hirschfeld,
Mauro Carvalho Chehab, Robin Murphy, Rob Herring, Mark Rutland,
Hans Verkuil, Linux Media Mailing List, linux-devicetree
In-Reply-To: <CAAFQd5AVD+LhYZziqNUfga1sCp98MMu+ESgBMagS1n6++ae=pg@mail.gmail.com>
Hi Tomasz,
Am Montag, 1. Juni 2020, 20:45:14 CEST schrieb Tomasz Figa:
> On Fri, May 29, 2020 at 3:04 PM Maxime Chevallier
> <maxime.chevallier@bootlin.com> wrote:
> >
> > Hello everyone,
> >
> > Here's a V2 of the series adding very basic support for the camera interface on
> > the Rockchip PX30 SoC.
> >
> > Thanks to everyone that commented on the first series, your reviews were
> > very helpful :)
> >
> > This Camera Interface is also supported on other Rockchip SoC such as
> > the RK1808, RK3128, RK3288 and RK3288, but for now I've only been able to
> > test it on the PX30, using a PAL format.
>
> How does this hardware relate to the one handled by the rkisp1 driver
> that is available under staging/media/rkisp1? It was written with
> RK3399 in mind, but I have a loose recollection that the hardware in
> RK3288 was roughly the same.
(un-)educated guess would be that the rk3288 has both.
When introducing new IPs Rockchip often keeps the previous incarnation
around - probably as a fallback.
From a bit of digging around manuals and vendor-dtsi [0] I found:
in rk3288.dtsi both:
- isp: isp@ff910000
- cif_isp0: cif_isp@ff910000
- grf_con_disable_isp in GRF_SOC_CON6
- dphy_rx1_src_sel (1: isp, 0: csi host) in GRF_SOC_CON14
Heiko
[0] https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm/boot/dts/rk3288.dtsi
> +Helen Koike +Dafna Hirschfeld working on the rkisp1 driver.
>
> Best regards,
> Tomasz
>
> >
> > This driver is mostly based on the driver found in Rockchip's BSP, that
> > has been trimmed down to support the set of features that I was able to test,
> > that is pretty much a very basic one-frame capture and video streaming
> > with GStreamer.
> >
> > This first draft only supports the Parallel interface, although the
> > controller has support for BT656 and CSI2.
> >
> > Finally, this controller has an iommu that could be used in this driver,
> > but as of today I've not been able to get it to work.
> >
> > Any review is welcome.
> >
> > Thanks,
> >
> > Maxime
> >
> > --- Changes since V1 ---
> >
> > - Took reviews from Rob, Hans, Robin and Heiko into account :
> > - Renamed the clocks in the binding
> > - Fixed the DT schema compiling
> > - Fixed a few typos
> > - Used the clk bulk API
> > - Used the reset array API
> > - Changed a few helpers for more suitable ones
> > - Rebased on 5.7-rc7
> >
> >
> >
> > Maxime Chevallier (3):
> > media: dt-bindings: media: Document Rockchip CIF bindings
> > media: rockchip: Introduce driver for Rockhip's camera interface
> > arm64: dts: rockchip: Add the camera interface description of the PX30
> >
> > .../bindings/media/rockchip-cif.yaml | 100 ++
> > arch/arm64/boot/dts/rockchip/px30.dtsi | 12 +
> > drivers/media/platform/Kconfig | 13 +
> > drivers/media/platform/Makefile | 1 +
> > drivers/media/platform/rockchip/cif/Makefile | 3 +
> > drivers/media/platform/rockchip/cif/capture.c | 1170 +++++++++++++++++
> > drivers/media/platform/rockchip/cif/dev.c | 358 +++++
> > drivers/media/platform/rockchip/cif/dev.h | 213 +++
> > drivers/media/platform/rockchip/cif/regs.h | 256 ++++
> > 9 files changed, 2126 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
> > create mode 100644 drivers/media/platform/rockchip/cif/Makefile
> > create mode 100644 drivers/media/platform/rockchip/cif/capture.c
> > create mode 100644 drivers/media/platform/rockchip/cif/dev.c
> > create mode 100644 drivers/media/platform/rockchip/cif/dev.h
> > create mode 100644 drivers/media/platform/rockchip/cif/regs.h
> >
> > --
> > 2.25.4
> >
>
^ permalink raw reply
* Re: [PATCH v2 5/5] PCI: uniphier: Add error message when failed to get phy
From: Rob Herring @ 2020-06-01 21:43 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Masahiro Yamada, linux-pci, devicetree, linux-arm-kernel,
linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1589536743-6684-6-git-send-email-hayashi.kunihiko@socionext.com>
On Fri, May 15, 2020 at 06:59:03PM +0900, Kunihiko Hayashi wrote:
> Even if phy driver doesn't probe, the error message can't be distinguished
> from other errors. This displays error message caused by the phy driver
> explicitly.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index 493f105..7ae9688 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -468,8 +468,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
> return PTR_ERR(priv->rst);
>
> priv->phy = devm_phy_optional_get(dev, "pcie-phy");
> - if (IS_ERR(priv->phy))
> - return PTR_ERR(priv->phy);
> + if (IS_ERR(priv->phy)) {
> + ret = PTR_ERR(priv->phy);
> + dev_err(dev, "Failed to get phy (%d)\n", ret);
This will print an error on EPROBE_DEFERRED which isn't an error.
> + return ret;
> + }
>
> platform_set_drvdata(pdev, priv);
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCHv1 00/19] Improve SBS battery support
From: Sebastian Reichel @ 2020-06-01 21:57 UTC (permalink / raw)
To: Pavel Machek
Cc: Rob Herring, Greg Kroah-Hartman, Rafael J . Wysocki, linux-pm,
devicetree, linux-kernel, kernel
In-Reply-To: <20200529162704.GA3709@amd>
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
Hi,
On Fri, May 29, 2020 at 06:27:04PM +0200, Pavel Machek wrote:
> > This patchset improves support for SBS compliant batteries. Due to
> > the changes, the battery now exposes 32 power supply properties and
> > (un)plugging it generates a backtrace containing the following message
> > without the first patch in this series:
> >
> > ---------------------------
> > WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
> > add_uevent_var: too many keys
> > ---------------------------
> >
> > For references this is what an SBS battery status looks like after
> > the patch series has been applied:
> >
> > POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
> > POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000
>
> Is that correct, BTW? sounds like these should not be equal...
(Some) GE batteries have weird values stored in the SBS chip.
For example manufacturer and model name are swapped:
POWER_SUPPLY_MANUFACTURER=UR18650A
POWER_SUPPLY_MODEL_NAME=GEHC
I carefully checked manufacturer/model name when writing these
patches some time ago and came to the conclusion that the batteries
do report it the wrong way around.
I will have a look for the design voltages (which are not modified
by this patchset), but I expect this to be another GE specific thing.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-06-01 21:59 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Chen Zhou, Simon Horman, Devicetree List,
Baoquan He, Will Deacon, Linux Doc Mailing List, Catalin Marinas,
kexec mailing list, Linux Kernel Mailing List, Rob Herring,
Ingo Molnar, Arnd Bergmann, guohanjun, James Morse,
Thomas Gleixner, Prabhakar Kushwaha, RuiRui Yang,
linux-arm-kernel
In-Reply-To: <CACi5LpOZzdfEKUYAfYxtgeUbk9K6YFVUKLaGS8XoS0kForjH9A@mail.gmail.com>
Hi . See below !
> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>
> Hi John,
>
> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
>>
>> Hi,
>>
>>
>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
>>> Hi Chen,
>>>
>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>>
>>>> There are following issues in arm64 kdump:
>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>> when there is no enough low memory.
>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
>>>> will boot failure because there is no low memory available for allocation.
>>>>
>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>>> size low memory.
>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>>> size low memory for crash kdump kernel devices firstly and then reserve
>>>> memory above 4G.
>>>>
>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>>> is specified simultaneously, kernel should reserve specified size low memory
>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>>> is below 4G, the other is above 4G.
>>>> In order to distinct from the high region and make no effect to the use of
>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>>
>>>> Besides, we need to modify kexec-tools:
>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>>
>>>> The previous changes and discussions can be retrieved from:
>>>>
>>>> Changes since [v7]
>>>> - Move x86 CRASH_ALIGN to 2M
>>>> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
>>>> - Update Documentation/devicetree/bindings/chosen.txt
>>>> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
>>>> - Add Tested-by from Jhon and pk
>>>>
>>>> Changes since [v6]
>>>> - Fix build errors reported by kbuild test robot.
>>>>
>>>> Changes since [v5]
>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>>> - Delete crashkernel=X,high.
>>>> - Modify crashkernel=X,low.
>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>>
>>>> Changes since [v4]
>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>>
>>>> Changes since [v3]
>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>>> - Fix some compiling warnings.
>>>>
>>>> Changes since [v2]
>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>>> patch.
>>>>
>>>> Changes since [v1]:
>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>>> in fdt_enforce_memory_region().
>>>> There are at most two crash kernel regions, for two crash kernel regions
>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>>> and then remove the memory range in the middle.
>>>>
>>>> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
>>>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
>>>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
>>>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
>>>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
>>>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
>>>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
>>>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
>>>>
>>>> Chen Zhou (5):
>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
>>>> kdump: update Documentation about crashkernel on arm64
>>>> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
>>>>
>>> We are getting "warn_alloc" [1] warning during boot of kdump kernel
>>> with bootargs as [2] of primary kernel.
>>> This error observed on ThunderX2 ARM64 platform.
>>>
>>> It is observed with latest upstream tag (v5.7-rc3) with this patch set
>>> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
>>> Also **without** this patch-set
>>> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
>>>
>>> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
>>> More details discussed earlier in
>>> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
>>> solution
>>>
>>> This patch-set is expected to solve similar kind of issue.
>>> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
>>> observation should be considered/fixed. .
>>>
>>> --pk
>>>
>>> [1]
>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>> [ 30.367696] NET: Registered protocol family 16
>>> [ 30.369973] swapper/0: page allocation failure: order:6,
>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>> [ 30.369984] Call trace:
>>> [ 30.369989] dump_backtrace+0x0/0x1f8
>>> [ 30.369991] show_stack+0x20/0x30
>>> [ 30.369997] dump_stack+0xc0/0x10c
>>> [ 30.370001] warn_alloc+0x10c/0x178
>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
>>> [ 30.370008] alloc_page_interleave+0x24/0x98
>>> [ 30.370011] alloc_pages_current+0xe4/0x108
>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
>>> [ 30.370020] do_one_initcall+0x54/0x228
>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
>>> [ 30.370031] kernel_init+0x1c/0x110
>>> [ 30.370034] ret_from_fork+0x10/0x18
>>> [ 30.370036] Mem-Info:
>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
>>> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>> unstable:0kB all_unreclaimable? no
>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>> unstable:0kB all_unreclaimable? no
>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
>>> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
>>> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
>>> hugepages_surp=0 hugepages_size=1048576kB
>>> [ 30.370130] 0 total pagecache pages
>>> [ 30.370132] 0 pages in swap cache
>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
>>> [ 30.370135] Free swap = 0kB
>>> [ 30.370136] Total swap = 0kB
>>> [ 30.370137] 2164609 pages RAM
>>> [ 30.370139] 0 pages HighMem/MovableOnly
>>> [ 30.370140] 612331 pages reserved
>>> [ 30.370141] 0 pages hwpoisoned
>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
>>> coherent allocation
>>
>>
>> During my testing I saw the same error and Chen's solution corrected it .
>
> Which combination you are using on your side? I am using Prabhakar's
> suggested environment and can reproduce the issue
> with or without Chen's crashkernel support above 4G patchset.
>
> I am also using a ThunderX2 platform with latest makedumpfile code and
> kexec-tools (with the suggested patch
> <https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$ >).
>
> Thanks,
> Bhupesh
I did this activity 5 months ago and I have moved on to other activities. My DMA failures were related to PCI devices that could not be enumerated because low-DMA space was not available when crashkernel was moved above 4G; I don’t recall the exact platform.
For this failure ,
>>> DMA: failed to allocate 256 KiB pool for atomic
>>> coherent allocation
Is due to :
3618082c
("arm64 use both ZONE_DMA and ZONE_DMA32")
With the introduction of ZONE_DMA to support the Raspberry DMA
region below 1G, the crashkernel is placed in the upper 4G
ZONE_DMA_32 region. Since the crashkernel does not have access
to the ZONE_DMA region, it prints out call trace during bootup.
It is due to having this CONFIG item ON :
CONFIG_ZONE_DMA=y
Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
use the device tree to specify memory below 1G.
I would like to see Chen’s feature added , perhaps as EXPERIMENTAL, so we can get some configuration testing done on it. It corrects having a DMA zone in low memory while crash-kernel is above 4GB. This has been going on for a year now.
Thank you,
John.
( Note .. I am not on the all the kernel-dlist emails so this won’t be seen by everyone , - someone may have to bounce it )
^ permalink raw reply
* Re: [PATCH v3 04/20] arm64: dts: arm: vexpress: Move fixed devices out of bus node
From: Rob Herring @ 2020-06-01 23:12 UTC (permalink / raw)
To: André Przywara
Cc: Guenter Roeck, Sudeep Holla, Liviu Dudau, Lorenzo Pieralisi,
Mark Rutland, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <22687572-becf-7b4e-9759-cfba44677a1d@arm.com>
On Mon, Jun 1, 2020 at 4:15 AM André Przywara <andre.przywara@arm.com> wrote:
>
> On 28/05/2020 14:30, André Przywara wrote:
>
> Hi,
>
> > On 28/05/2020 03:48, Guenter Roeck wrote:
> >
> > Hi Guenter,
> >
> >> On Wed, May 13, 2020 at 11:30:00AM +0100, Andre Przywara wrote:
> >>> The devicetree compiler complains when DT nodes without a reg property
> >>> live inside a (simple) bus node:
> >>> Warning (simple_bus_reg): Node /bus@8000000/motherboard-bus/refclk32khz
> >>> missing or empty reg/ranges property
> >>>
> >>> Move the fixed clocks, the fixed regulator, the leds and the config bus
> >>> subtree to the root node, since they do not depend on any busses.
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>
> >> This patch results in tracebacks when booting the vexpress-a15 machine
> >> with vexpress-v2p-ca15-tc1 devicetree file in qemu. Reverting it as well
> >> as the subsequent patches affecting the same file (to avoid revert
> >> conflicts) fixes the problem.
> >
> > Many thanks for the heads up! I was able to reproduce it here. On the
> > first glance it looks like the UART is probed before the clocks now,
> > because the traversal of the changed DT leads to a different probe
> > order. I will look into how to fix this.
>
> Turned out to be a bit more complicated:
> The arm,vexpress,config-bus driver walks up the device tree to find a
> arm,vexpress,site property [1]. With this patch the first parent node
> with that property it finds is now the root node, with the wrong site ID
> (0xf instead of 0x0). So it queries the wrong clocks (those IDs are
> actually reserved there), and QEMU reports back "0", consequently [2].
> Finding a clock frequency in the range of [0, 0] won't get very far.
>
> Possible solutions are:
> 1) Just keep the mcc and its children at where it is in mainline right
> now, so *partly* reverting this patch. This has the problem of still
> producing a dtc warning, so kind of defeats the purpose of this patch.
>
> 2) Add a "arm,vexpress,site = <0>;" line to the "mcc" node itself.
> Works, but looks somewhat dodgy, as the mcc node should really be a
> child of the motherboard node, and we should not hack around this.
>
> 3) Dig deeper and fix the DT in a way that makes dtc happy. Might
> involve (dummy?) ranges or reg properties. My gut feeling is that
> arm,vexpress-sysreg,func should really have been "reg" in the first
> place, but that's too late to change now, anyway.
>
> I will post 2) as a fix if 3) turns out to be not feasible.
I would just do 1).
To some extent, the warnings are for avoiding poor design on new
bindings. We need a way to distinguish between existing boards and new
ones. Maybe dts needs to learn some warning disable annotations or we
need per target warning settings (DTC_FLAGS_foo.dtb ?). Or maybe this
check is just too strict.
Rob
^ permalink raw reply
* [PATCH] ARM: dts: omap4-droid4: Fix spi configuration and increase rate
From: Tony Lindgren @ 2020-06-02 0:19 UTC (permalink / raw)
To: linux-omap
Cc: Benoît Cousson, devicetree, maemo-leste, Merlijn Wajer,
Pavel Machek, Sebastian Reichel
We can currently sometimes get "RXS timed out" errors and "EOT timed out"
errors with spi transfers.
These errors can be made easy to reproduce by reading the cpcap iio
values in a loop while keeping the CPUs busy by also reading /dev/urandom.
The "RXS timed out" errors we can fix by adding spi-cpol and spi-cpha
in addition to the spi-cs-high property we already have.
The "EOT timed out" errors we can fix by increasing the spi clock rate
to 9.6 MHz. Looks similar MC13783 PMIC says it works at spi clock rates
up to 20 MHz, so let's assume we can pick any rate up to 20 MHz also
for cpcap.
Cc: maemo-leste@lists.dyne.org
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi b/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
--- a/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
+++ b/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
@@ -13,8 +13,10 @@ cpcap: pmic@0 {
#interrupt-cells = <2>;
#address-cells = <1>;
#size-cells = <0>;
- spi-max-frequency = <3000000>;
+ spi-max-frequency = <9600000>;
spi-cs-high;
+ spi-cpol;
+ spi-cpha;
cpcap_adc: adc {
compatible = "motorola,mapphone-cpcap-adc";
--
2.26.2
^ permalink raw reply
* Re: [PATCH v1 6/6] drm: panel-simple: add LOGIC Technologies panels
From: Doug Anderson @ 2020-06-02 0:30 UTC (permalink / raw)
To: Sam Ravnborg
Cc: dri-devel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Søren Andersen, Thierry Reding, Ville Syrjälä,
Bjorn Andersson, Sebastian Reichel
In-Reply-To: <20200601083309.712606-7-sam@ravnborg.org>
Hi,
On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> +static const struct drm_display_mode logictechno_lttd800480070_l6wh_rt_mode = {
> + .clock = 33000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 154,
> + .hsync_end = 800 + 154 + 3,
> + .htotal = 800 + 154 + 3 + 43,
> + .vdisplay = 480,
> + .vsync_start = 480 + 47,
> + .vsync_end = 480 + 47 + 3,
> + .vtotal = 480 + 47 + 3 + 20,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
This is different than the "typ" mode from the random spreadsheet I
found on the internet:
https://logictechno.com/wp-content/uploads/2016/11/LTTD800480070-L6WH-RT-v1.1.pdf
As per my other comments, I wonder how important "vrefresh" is and if
we should include it.
-Doug
^ permalink raw reply
* Re: [PATCH v1 4/6] drm: panel-simple: add Hitachi 3.5" QVGA panel
From: Doug Anderson @ 2020-06-02 0:30 UTC (permalink / raw)
To: Sam Ravnborg
Cc: dri-devel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Søren Andersen, Thierry Reding, Ville Syrjälä,
Bjorn Andersson, Sebastian Reichel
In-Reply-To: <20200601083309.712606-5-sam@ravnborg.org>
Hi,
On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> This panel is used on evaluation boards for Atmel at91sam9261 and
> at91sam6263.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 8624bb80108c..25c96639631f 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1813,6 +1813,32 @@ static const struct panel_desc hannstar_hsd100pxn1 = {
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> +static const struct drm_display_mode hitachi_tx09d71vm1cca_mode = {
> + .clock = 4965000,
This is the pixel clock in kHz, right? So it runs at almost 5 Terahertz?
> + .hdisplay = 240,
> + .hsync_start = 240 + 0,
> + .hsync_end = 240 + 0 + 5,
> + .htotal = 240 + 0 + 5 + 1,
> + .vdisplay = 320,
> + .vsync_start = 320 + 0,
> + .vsync_end = 320 + 0 + 1,
> + .vtotal = 320 + 0 + 1 + 1,
Some random datasheet I found has really different numbers. If the
numbers above are what everyone is using then I suppose it's fine,
just curious why the mismatch.
Also: should you provide "vrefresh"?
-Doug
^ permalink raw reply
* Re: [PATCH v1 2/6] drm: panel-simple: add Seiko 70WVW2T 7" simple panel
From: Doug Anderson @ 2020-06-02 0:31 UTC (permalink / raw)
To: Sam Ravnborg
Cc: dri-devel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Søren Andersen, Thierry Reding, Ville Syrjälä,
Bjorn Andersson, Sebastian Reichel
In-Reply-To: <20200601083309.712606-3-sam@ravnborg.org>
Hi,
On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> The Seiko 70WVW2T is a discontinued product, but may be used somewhere.
> Tested on a proprietary product.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Søren Andersen <san@skov.dk>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index b067f66cea0e..8624bb80108c 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3194,6 +3194,31 @@ static const struct panel_desc shelly_sca07010_bfn_lnn = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> };
>
> +static const struct drm_display_mode sii_70wvw2t_mode = {
> + .clock = 33000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 256,
> + .hsync_end = 800 + 256 + 0,
> + .htotal = 800 + 256 + 0 + 0,
> + .vdisplay = 480,
> + .vsync_start = 480 + 0,
> + .vsync_end = 480 + 0 + 0,
> + .vtotal = 480 + 0 + 0 + 45,
Important to have a "vrefresh"?
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +};
> +
> +static const struct panel_desc sii_70wvw2t = {
> + .modes = &sii_70wvw2t_mode,
> + .num_modes = 1,
Do we want "bpc = 6"?
> + .size = {
> + .width = 152,
> + .height = 91,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
Should this be a 666 format? Random internet-found data sheet says
262K colors...
^ permalink raw reply
* Re: [RFC PATCH v5 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
From: Chanwoo Choi @ 2020-06-02 0:50 UTC (permalink / raw)
To: Sylwester Nawrocki, Chanwoo Choi
Cc: Georgi Djakov, Krzysztof Kozlowski, Artur Świgoń,
MyungJoo Ham, inki.dae, Seung-Woo Kim, Bartlomiej Zolnierkiewicz,
Marek Szyprowski, linux-kernel, linux-samsung-soc, dri-devel,
linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <8a977716-9e0e-5daf-fb22-32d943da42e5@samsung.com>
Hi Sylwester,
On 6/1/20 7:04 PM, Sylwester Nawrocki wrote:
> Cc: Rob, devicetree ML
>
> On 31.05.2020 01:57, Chanwoo Choi wrote:
>> On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
>> <s.nawrocki@samsung.com> wrote:
>>>
>>> This patch adds registration of a child platform device for the exynos
>>> interconnect driver. It is assumed that the interconnect provider will
>>> only be needed when #interconnect-cells property is present in the bus
>>> DT node, hence the child device will be created only when such a property
>>> is present.
>>>
>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>>
>>> Changes for v5:
>>> - new patch.
>>> ---
>>> drivers/devfreq/exynos-bus.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 8fa8eb5..856e37d 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -24,6 +24,7 @@
>>>
>>> struct exynos_bus {
>>> struct device *dev;
>>> + struct platform_device *icc_pdev;
>>>
>>> struct devfreq *devfreq;
>>> struct devfreq_event_dev **edev;
>>> @@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
>>> if (ret < 0)
>>> dev_warn(dev, "failed to disable the devfreq-event devices\n");
>>>
>>> + platform_device_unregister(bus->icc_pdev);
>>> +
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> if (bus->opp_table) {
>>> @@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
>>> {
>>> struct exynos_bus *bus = dev_get_drvdata(dev);
>>>
>>> + platform_device_unregister(bus->icc_pdev);
>>> +
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> }
>>> @@ -431,6 +436,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
>>> if (ret < 0)
>>> goto err;
>>>
>>> + /* Create child platform device for the interconnect provider */
>>> + if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
>>> + bus->icc_pdev = platform_device_register_data(
>>> + dev, "exynos-generic-icc",
>>> + PLATFORM_DEVID_AUTO, NULL, 0);
>>> +
>>> + if (IS_ERR(bus->icc_pdev)) {
>>> + ret = PTR_ERR(bus->icc_pdev);
>>> + goto err;
>>> + }
>>> + }
>>> +
>>> max_state = bus->devfreq->profile->max_state;
>>> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
>>> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
>>> --
>>> 2.7.4
>>>
>>
>> It looks like very similar like the registering the interconnect
>> device of imx-bus.c
>> and I already reviewed and agreed this approach.
>>
>> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
>>
>> nitpick: IMHO, I think that 'exynos-icc' is proper and simple without
>> 'generic' word.
>> If we need to add new icc compatible int the future, we will add
>> 'exynosXXXX-icc' new compatible.
>> But, I'm not forcing it. just opinion. Anyway, I agree this approach.
>
> Thanks for review. I will change the name to exynos-icc in next version,
> as I commented at other patch, it is not part of any DT binding,
> it is just for device/driver matching between devfreq and interconnect.
Thanks. I have not any objection to use either 'exynos-generic-icc'
or 'exynos-icc'. It is just my opinion. And on next version,
please add linux-pm mailing list to Cc.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH V3] dt-bindings: thermal: Convert qoriq to json-schema
From: Anson Huang @ 2020-06-02 1:15 UTC (permalink / raw)
To: rui.zhang, daniel.lezcano, amit.kucheria, robh+dt, hongtao.jia,
linux-pm, devicetree, linux-kernel
Cc: Linux-imx
Convert the qoriq thermal binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V2:
- correct maintainer's email address.
---
.../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
.../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +++++++++++++++++++++
2 files changed, 112 insertions(+), 71 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
deleted file mode 100644
index 28f2cba..0000000
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
-
-Required properties:
-- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
- version of the device is determined by the TMU IP Block Revision
- Register (IPBRR0) at offset 0x0BF8.
- Table of correspondences between IPBRR0 values and example chips:
- Value Device
- ---------- -----
- 0x01900102 T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
- the SoC reference manual. The first cell is TTR0CR, the second is
- TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
- calibration data, as specified by the SoC reference manual.
- The first cell of each pair is the value to be written to TTCFGR,
- and the second is the value to be written to TSCFGR.
-- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring
- site ID, and represents the "n" in TRITSRn and TRATSRn.
-
-Optional property:
-- little-endian : If present, the TMU registers are little endian. If absent,
- the default is big endian.
-- clocks : the clock for clocking the TMU silicon.
-
-Example:
-
-tmu@f0000 {
- compatible = "fsl,qoriq-tmu";
- reg = <0xf0000 0x1000>;
- interrupts = <18 2 0 0>;
- fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
- fsl,tmu-calibration = <0x00000000 0x00000025
- 0x00000001 0x00000028
- 0x00000002 0x0000002d
- 0x00000003 0x00000031
- 0x00000004 0x00000036
- 0x00000005 0x0000003a
- 0x00000006 0x00000040
- 0x00000007 0x00000044
- 0x00000008 0x0000004a
- 0x00000009 0x0000004f
- 0x0000000a 0x00000054
-
- 0x00010000 0x0000000d
- 0x00010001 0x00000013
- 0x00010002 0x00000019
- 0x00010003 0x0000001f
- 0x00010004 0x00000025
- 0x00010005 0x0000002d
- 0x00010006 0x00000033
- 0x00010007 0x00000043
- 0x00010008 0x0000004b
- 0x00010009 0x00000053
-
- 0x00020000 0x00000010
- 0x00020001 0x00000017
- 0x00020002 0x0000001f
- 0x00020003 0x00000029
- 0x00020004 0x00000031
- 0x00020005 0x0000003c
- 0x00020006 0x00000042
- 0x00020007 0x0000004d
- 0x00020008 0x00000056
-
- 0x00030000 0x00000012
- 0x00030001 0x0000001d>;
- #thermal-sensor-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
new file mode 100644
index 0000000..4bc344a
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
+
+maintainers:
+ - Hongtao Jia <hongtao.jia@nxp.com>
+
+properties:
+ compatible:
+ description: |
+ The version of the device is determined by the TMU IP Block Revision
+ Register (IPBRR0) at offset 0x0BF8.
+ Table of correspondences between IPBRR0 values and example chips:
+ Value Device
+ ---------- -----
+ 0x01900102 T1040
+ enum:
+ - fsl,qoriq-tmu
+ - fsl,imx8mq-tmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,tmu-range:
+ $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ description: |
+ The values to be programmed into TTRnCR, as specified by the SoC
+ reference manual. The first cell is TTR0CR, the second is TTR1CR, etc.
+ maxItems: 4
+
+ fsl,tmu-calibration:
+ $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ description: |
+ A list of cell pairs containing temperature calibration data, as
+ specified by the SoC reference manual. The first cell of each pair
+ is the value to be written to TTCFGR, and the second is the value
+ to be written to TSCFGR.
+ items:
+ items:
+ - description: value for TTCFGR
+ - description: value for TSCFGR
+ minItems: 1
+ maxItems: 64
+
+ little-endian:
+ description: |
+ boolean, if present, the TMU registers are little endian. If absent,
+ the default is big endian.
+ type: boolean
+
+ clocks:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,tmu-range
+ - fsl,tmu-calibration
+ - '#thermal-sensor-cells'
+
+examples:
+ - |
+ tmu@f0000 {
+ compatible = "fsl,qoriq-tmu";
+ reg = <0xf0000 0x1000>;
+ interrupts = <18 2 0 0>;
+ fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
+ fsl,tmu-calibration = <0x00000000 0x00000025>,
+ <0x00000001 0x00000028>,
+ <0x00000002 0x0000002d>,
+ <0x00000003 0x00000031>,
+ <0x00000004 0x00000036>,
+ <0x00000005 0x0000003a>,
+ <0x00000006 0x00000040>,
+ <0x00000007 0x00000044>,
+ <0x00000008 0x0000004a>,
+ <0x00000009 0x0000004f>,
+ <0x0000000a 0x00000054>,
+ <0x00010000 0x0000000d>,
+ <0x00010001 0x00000013>,
+ <0x00010002 0x00000019>,
+ <0x00010003 0x0000001f>,
+ <0x00010004 0x00000025>,
+ <0x00010005 0x0000002d>,
+ <0x00010006 0x00000033>,
+ <0x00010007 0x00000043>,
+ <0x00010008 0x0000004b>,
+ <0x00010009 0x00000053>,
+ <0x00020000 0x00000010>,
+ <0x00020001 0x00000017>,
+ <0x00020002 0x0000001f>,
+ <0x00020003 0x00000029>,
+ <0x00020004 0x00000031>,
+ <0x00020005 0x0000003c>,
+ <0x00020006 0x00000042>,
+ <0x00020007 0x0000004d>,
+ <0x00020008 0x00000056>,
+ <0x00030000 0x00000012>,
+ <0x00030001 0x0000001d>;
+ #thermal-sensor-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* RE: [PATCH V2] dt-bindings: thermal: Convert qoriq to json-schema
From: Anson Huang @ 2020-06-02 1:30 UTC (permalink / raw)
To: Rob Herring
Cc: Zhang Rui, Daniel Lezcano, Amit Kucheria, open list:THERMAL,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dl-linux-imx, Jia Hongtao
In-Reply-To: <CAL_JsqKVL4J=-aLPsSYgGVdnx3qjA=J8M08ztzv9=0V9gY=14A@mail.gmail.com>
Hi, Rob
> Subject: Re: [PATCH V2] dt-bindings: thermal: Convert qoriq to json-schema
>
> On Sun, May 31, 2020 at 9:45 PM Anson Huang <Anson.Huang@nxp.com>
> wrote:
> >
> > Convert the qoriq thermal binding to DT schema format using
> > json-schema
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > Changes since V1:
> > - add 'maxItems' for 'fsl,tmu-range' property;
> > - add 'minItems'/'maxItems' and items descriptions for
> 'fsl,tmu-calibration' property;
> > - remove description for common property '#thermal-sensor-cells';
> > - refine 'fsl,tmu-calibration' format in example.
> > ---
> > .../devicetree/bindings/thermal/qoriq-thermal.txt | 71
> > ------------- .../devicetree/bindings/thermal/qoriq-thermal.yaml |
> > 112 +++++++++++++++++++++
> > 2 files changed, 112 insertions(+), 71 deletions(-) delete mode
> > 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > create mode 100644
> > Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
>
> [...]
>
> > diff --git
> > a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> > b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> > new file mode 100644
> > index 0000000..c5df999
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> > @@ -0,0 +1,112 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fthermal%2Fqoriq-thermal.yaml%23&data=0
> 2%7C
> >
> +01%7CAnson.Huang%40nxp.com%7Cbb14200bf9dd47404fd308d8064c5719
> %7C686ea
> >
> +1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637266272232329711&am
> p;sdata=gz
> > +zLUrr9f56HcPB1iy4xQvj2tw41Mc9Af5QUJbuvnCY%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7CAns
> on.Hua
> >
> +ng%40nxp.com%7Cbb14200bf9dd47404fd308d8064c5719%7C686ea1d3bc2
> b4c6fa92
> >
> +cd99c5c301635%7C0%7C0%7C637266272232329711&sdata=7qkHkpj
> XPXMYn13c
> > +I1pndBwFgfI2%2F6gMfCgWPrQSnmc%3D&reserved=0
> > +
> > +title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
> > +
> > +maintainers:
> > + - Hongtao Jia <hongtao.jia@freescale.com>
>
> This email is bouncing. Should be @nxp.com?
Yes, but looks like hongtao is no longer in NXP, so the hongtao.jia@nxp.com
can NOT be touched in, I sent out V3 patch and also got the notification of failed
to send to hongtao.jia@nxp.com, so I will use myself as maintainer, correct me if anything
wrong. Will send a V4.
Thanks,
Anson
^ permalink raw reply
* [PATCH V4] dt-bindings: thermal: Convert qoriq to json-schema
From: Anson Huang @ 2020-06-02 1:22 UTC (permalink / raw)
To: rui.zhang, daniel.lezcano, amit.kucheria, robh+dt, linux-pm,
devicetree, linux-kernel
Cc: Linux-imx
Convert the qoriq thermal binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V3:
- Update maintainer since previous maintainer's email is NOT longer available.
---
.../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
.../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +++++++++++++++++++++
2 files changed, 112 insertions(+), 71 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
deleted file mode 100644
index 28f2cba..0000000
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
-
-Required properties:
-- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
- version of the device is determined by the TMU IP Block Revision
- Register (IPBRR0) at offset 0x0BF8.
- Table of correspondences between IPBRR0 values and example chips:
- Value Device
- ---------- -----
- 0x01900102 T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
- the SoC reference manual. The first cell is TTR0CR, the second is
- TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
- calibration data, as specified by the SoC reference manual.
- The first cell of each pair is the value to be written to TTCFGR,
- and the second is the value to be written to TSCFGR.
-- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring
- site ID, and represents the "n" in TRITSRn and TRATSRn.
-
-Optional property:
-- little-endian : If present, the TMU registers are little endian. If absent,
- the default is big endian.
-- clocks : the clock for clocking the TMU silicon.
-
-Example:
-
-tmu@f0000 {
- compatible = "fsl,qoriq-tmu";
- reg = <0xf0000 0x1000>;
- interrupts = <18 2 0 0>;
- fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
- fsl,tmu-calibration = <0x00000000 0x00000025
- 0x00000001 0x00000028
- 0x00000002 0x0000002d
- 0x00000003 0x00000031
- 0x00000004 0x00000036
- 0x00000005 0x0000003a
- 0x00000006 0x00000040
- 0x00000007 0x00000044
- 0x00000008 0x0000004a
- 0x00000009 0x0000004f
- 0x0000000a 0x00000054
-
- 0x00010000 0x0000000d
- 0x00010001 0x00000013
- 0x00010002 0x00000019
- 0x00010003 0x0000001f
- 0x00010004 0x00000025
- 0x00010005 0x0000002d
- 0x00010006 0x00000033
- 0x00010007 0x00000043
- 0x00010008 0x0000004b
- 0x00010009 0x00000053
-
- 0x00020000 0x00000010
- 0x00020001 0x00000017
- 0x00020002 0x0000001f
- 0x00020003 0x00000029
- 0x00020004 0x00000031
- 0x00020005 0x0000003c
- 0x00020006 0x00000042
- 0x00020007 0x0000004d
- 0x00020008 0x00000056
-
- 0x00030000 0x00000012
- 0x00030001 0x0000001d>;
- #thermal-sensor-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
new file mode 100644
index 0000000..ae76208
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+properties:
+ compatible:
+ description: |
+ The version of the device is determined by the TMU IP Block Revision
+ Register (IPBRR0) at offset 0x0BF8.
+ Table of correspondences between IPBRR0 values and example chips:
+ Value Device
+ ---------- -----
+ 0x01900102 T1040
+ enum:
+ - fsl,qoriq-tmu
+ - fsl,imx8mq-tmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,tmu-range:
+ $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ description: |
+ The values to be programmed into TTRnCR, as specified by the SoC
+ reference manual. The first cell is TTR0CR, the second is TTR1CR, etc.
+ maxItems: 4
+
+ fsl,tmu-calibration:
+ $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ description: |
+ A list of cell pairs containing temperature calibration data, as
+ specified by the SoC reference manual. The first cell of each pair
+ is the value to be written to TTCFGR, and the second is the value
+ to be written to TSCFGR.
+ items:
+ items:
+ - description: value for TTCFGR
+ - description: value for TSCFGR
+ minItems: 1
+ maxItems: 64
+
+ little-endian:
+ description: |
+ boolean, if present, the TMU registers are little endian. If absent,
+ the default is big endian.
+ type: boolean
+
+ clocks:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,tmu-range
+ - fsl,tmu-calibration
+ - '#thermal-sensor-cells'
+
+examples:
+ - |
+ tmu@f0000 {
+ compatible = "fsl,qoriq-tmu";
+ reg = <0xf0000 0x1000>;
+ interrupts = <18 2 0 0>;
+ fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
+ fsl,tmu-calibration = <0x00000000 0x00000025>,
+ <0x00000001 0x00000028>,
+ <0x00000002 0x0000002d>,
+ <0x00000003 0x00000031>,
+ <0x00000004 0x00000036>,
+ <0x00000005 0x0000003a>,
+ <0x00000006 0x00000040>,
+ <0x00000007 0x00000044>,
+ <0x00000008 0x0000004a>,
+ <0x00000009 0x0000004f>,
+ <0x0000000a 0x00000054>,
+ <0x00010000 0x0000000d>,
+ <0x00010001 0x00000013>,
+ <0x00010002 0x00000019>,
+ <0x00010003 0x0000001f>,
+ <0x00010004 0x00000025>,
+ <0x00010005 0x0000002d>,
+ <0x00010006 0x00000033>,
+ <0x00010007 0x00000043>,
+ <0x00010008 0x0000004b>,
+ <0x00010009 0x00000053>,
+ <0x00020000 0x00000010>,
+ <0x00020001 0x00000017>,
+ <0x00020002 0x0000001f>,
+ <0x00020003 0x00000029>,
+ <0x00020004 0x00000031>,
+ <0x00020005 0x0000003c>,
+ <0x00020006 0x00000042>,
+ <0x00020007 0x0000004d>,
+ <0x00020008 0x00000056>,
+ <0x00030000 0x00000012>,
+ <0x00030001 0x0000001d>;
+ #thermal-sensor-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: mmc: Convert mxs mmc to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591069066-12727-1-git-send-email-Anson.Huang@nxp.com>
Convert the MXS MMC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Documentation/devicetree/bindings/mmc/mxs-mmc.txt | 27 -----------
Documentation/devicetree/bindings/mmc/mxs-mmc.yaml | 56 ++++++++++++++++++++++
2 files changed, 56 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
deleted file mode 100644
index 515addc..0000000
--- a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Freescale MXS MMC controller
-
-The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller
-to support MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties in mmc.txt
-and the properties used by the mxsmmc driver.
-
-Required properties:
-- compatible: Should be "fsl,<chip>-mmc". The supported chips include
- imx23 and imx28.
-- interrupts: Should contain ERROR interrupt number
-- dmas: DMA specifier, consisting of a phandle to DMA controller node
- and SSP DMA channel ID.
- Refer to dma.txt and fsl-mxs-dma.txt for details.
-- dma-names: Must be "rx-tx".
-
-Examples:
-
-ssp0: ssp@80010000 {
- compatible = "fsl,imx28-mmc";
- reg = <0x80010000 2000>;
- interrupts = <96>;
- dmas = <&dma_apbh 0>;
- dma-names = "rx-tx";
- bus-width = <8>;
-};
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
new file mode 100644
index 0000000..8fb9e59
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mxs-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS MMC controller
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+description: |
+ The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller
+ to support MMC, SD, and SDIO types of memory cards.
+
+ This file documents differences between the core properties in mmc.txt
+ and the properties used by the mxsmmc driver.
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx23-mmc
+ - fsl,imx28-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ mmc@80010000 {
+ compatible = "fsl,imx28-mmc";
+ reg = <0x80010000 2000>;
+ interrupts = <96>;
+ dmas = <&dma_apbh 0>;
+ dma-names = "rx-tx";
+ bus-width = <8>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: mmc: Convert imx mmc to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591069066-12727-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX MMC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/mmc/fsl-imx-mmc.txt | 23 ----------
.../devicetree/bindings/mmc/fsl-imx-mmc.yaml | 51 ++++++++++++++++++++++
2 files changed, 51 insertions(+), 23 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
deleted file mode 100644
index 184ccff..0000000
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Freescale Secure Digital Host Controller for i.MX2/3 series
-
-This file documents differences to the properties defined in mmc.txt.
-
-Required properties:
-- compatible : Should be "fsl,<chip>-mmc", chip can be imx21 or imx31
-
-Optional properties:
-- dmas: One DMA phandle with arguments as defined by the devicetree bindings
- of the used DMA controller.
-- dma-names: Has to be "rx-tx".
-
-Example:
-
-sdhci1: sdhci@10014000 {
- compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
- reg = <0x10014000 0x1000>;
- interrupts = <11>;
- dmas = <&dma 7>;
- dma-names = "rx-tx";
- bus-width = <4>;
- cd-gpios = <&gpio3 29>;
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
new file mode 100644
index 0000000..777a732
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fsl-imx-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Secure Digital Host Controller for i.MX2/3 series
+
+maintainers:
+ - Markus Pargmann <mpa@pengutronix.de>
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,imx21-mmc
+ - const: fsl,imx31-mmc
+ - items:
+ - const: fsl,imx27-mmc
+ - const: fsl,imx21-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ mmc@10014000 {
+ compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
+ reg = <0x10014000 0x1000>;
+ interrupts = <11>;
+ dmas = <&dma 7>;
+ dma-names = "rx-tx";
+ bus-width = <4>;
+ cd-gpios = <&gpio3 29>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: mmc: Convert imx esdhc to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591069066-12727-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX ESDHC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 67 -----------
.../devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 122 +++++++++++++++++++++
2 files changed, 122 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
deleted file mode 100644
index de1b8bd..0000000
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
-
-The Enhanced Secure Digital Host Controller on Freescale i.MX family
-provides an interface for MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
-
-Required properties:
-- compatible : Should be "fsl,<chip>-esdhc", the supported chips include
- "fsl,imx25-esdhc"
- "fsl,imx35-esdhc"
- "fsl,imx51-esdhc"
- "fsl,imx53-esdhc"
- "fsl,imx6q-usdhc"
- "fsl,imx6sl-usdhc"
- "fsl,imx6sx-usdhc"
- "fsl,imx6ull-usdhc"
- "fsl,imx7d-usdhc"
- "fsl,imx7ulp-usdhc"
- "fsl,imx8mq-usdhc"
- "fsl,imx8mm-usdhc"
- "fsl,imx8mn-usdhc"
- "fsl,imx8mp-usdhc"
- "fsl,imx8qm-usdhc"
- "fsl,imx8qxp-usdhc"
-
-Optional properties:
-- fsl,wp-controller : Indicate to use controller internal write protection
-- fsl,delay-line : Specify the number of delay cells for override mode.
- This is used to set the clock delay for DLL(Delay Line) on override mode
- to select a proper data sampling window in case the clock quality is not good
- due to signal path is too long on the board. Please refer to eSDHC/uSDHC
- chapter, DLL (Delay Line) section in RM for details.
-- voltage-ranges : Specify the voltage range in case there are software
- transparent level shifters on the outputs of the controller. Two cells are
- required, first cell specifies minimum slot voltage (mV), second cell
- specifies maximum slot voltage (mV). Several ranges could be specified.
-- fsl,tuning-start-tap: Specify the start dealy cell point when send first CMD19
- in tuning procedure.
-- fsl,tuning-step: Specify the increasing delay cell steps in tuning procedure.
- The uSDHC use one delay cell as default increasing step to do tuning process.
- This property allows user to change the tuning step to more than one delay
- cells which is useful for some special boards or cards when the default
- tuning step can't find the proper delay window within limited tuning retries.
-- fsl,strobe-dll-delay-target: Specify the strobe dll control slave delay target.
- This delay target programming host controller loopback read clock, and this
- property allows user to change the delay target for the strobe input read clock.
- If not use this property, driver default set the delay target to value 7.
- Only eMMC HS400 mode need to take care of this property.
-
-Examples:
-
-esdhc@70004000 {
- compatible = "fsl,imx51-esdhc";
- reg = <0x70004000 0x4000>;
- interrupts = <1>;
- fsl,wp-controller;
-};
-
-esdhc@70008000 {
- compatible = "fsl,imx51-esdhc";
- reg = <0x70008000 0x4000>;
- interrupts = <2>;
- cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
- wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
new file mode 100644
index 0000000..7d0ea27
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fsl-imx-esdhc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+description: |
+ The Enhanced Secure Digital Host Controller on Freescale i.MX family
+ provides an interface for MMC, SD, and SDIO types of memory cards.
+
+ This file documents differences between the core properties described
+ by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx25-esdhc
+ - fsl,imx35-esdhc
+ - fsl,imx51-esdhc
+ - fsl,imx53-esdhc
+ - fsl,imx6q-usdhc
+ - fsl,imx6sl-usdhc
+ - fsl,imx6sx-usdhc
+ - fsl,imx6ull-usdhc
+ - fsl,imx7d-usdhc
+ - fsl,imx7ulp-usdhc
+ - fsl,imx8mq-usdhc
+ - fsl,imx8mm-usdhc
+ - fsl,imx8mn-usdhc
+ - fsl,imx8mp-usdhc
+ - fsl,imx8qm-usdhc
+ - fsl,imx8qxp-usdhc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,wp-controller:
+ description: |
+ boolean, if present, indicate to use controller internal write protection.
+ type: boolean
+
+ fsl,delay-line:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the number of delay cells for override mode.
+ This is used to set the clock delay for DLL(Delay Line) on override mode
+ to select a proper data sampling window in case the clock quality is not good
+ due to signal path is too long on the board. Please refer to eSDHC/uSDHC
+ chapter, DLL (Delay Line) section in RM for details.
+ default: 0
+
+ voltage-ranges:
+ $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ description: |
+ Specify the voltage range in case there are software
+ transparent level shifters on the outputs of the controller. Two cells are
+ required, first cell specifies minimum slot voltage (mV), second cell
+ specifies maximum slot voltage (mV). Several ranges could be specified.
+ items:
+ items:
+ - description: value for minimum slot voltage
+ - description: value for maximum slot voltage
+ maxItems: 1
+
+ fsl,tuning-start-tap:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the start dealy cell point when send first CMD19 in tuning procedure.
+ default: 0
+
+ fsl,tuning-step:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the increasing delay cell steps in tuning procedure.
+ The uSDHC use one delay cell as default increasing step to do tuning process.
+ This property allows user to change the tuning step to more than one delay
+ cells which is useful for some special boards or cards when the default
+ tuning step can't find the proper delay window within limited tuning retries.
+ default: 0
+
+ fsl,strobe-dll-delay-target:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the strobe dll control slave delay target.
+ This delay target programming host controller loopback read clock, and this
+ property allows user to change the delay target for the strobe input read clock.
+ If not use this property, driver default set the delay target to value 7.
+ Only eMMC HS400 mode need to take care of this property.
+ default: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ mmc@70004000 {
+ compatible = "fsl,imx51-esdhc";
+ reg = <0x70004000 0x4000>;
+ interrupts = <1>;
+ fsl,wp-controller;
+ };
+
+ mmc@70008000 {
+ compatible = "fsl,imx51-esdhc";
+ reg = <0x70008000 0x4000>;
+ interrupts = <2>;
+ cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
+ wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] Convert i.MX/MXS mmc binding to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
This patch series converts i.MX and MXS mmc binding to json-schema,
fix some minor issues in original binding doc, such as node name should
be 'mmc', compatible name for i.MX27, reg/interrupts should be required
properties etc..
Anson Huang (3):
dt-bindings: mmc: Convert imx esdhc to json-schema
dt-bindings: mmc: Convert imx mmc to json-schema
dt-bindings: mmc: Convert mxs mmc to json-schema
.../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 67 -----------
.../devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 122 +++++++++++++++++++++
.../devicetree/bindings/mmc/fsl-imx-mmc.txt | 23 ----
.../devicetree/bindings/mmc/fsl-imx-mmc.yaml | 51 +++++++++
Documentation/devicetree/bindings/mmc/mxs-mmc.txt | 27 -----
Documentation/devicetree/bindings/mmc/mxs-mmc.yaml | 56 ++++++++++
6 files changed, 229 insertions(+), 117 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
delete mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
--
2.7.4
^ permalink raw reply
* [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
From: Lukas Bulwahn @ 2020-06-02 5:21 UTC (permalink / raw)
To: Julius Werner, Evan Benn, Wim Van Sebroeck, Guenter Roeck,
linux-watchdog
Cc: Rob Herring, devicetree, Joe Perches, kernel-janitors,
linux-kernel, Lukas Bulwahn
Commit 5c24a28b4eb8 ("dt-bindings: watchdog: Add ARM smc wdt for mt8173
watchdog") added the new ARM SMC WATCHDOG DRIVER entry in MAINTAINERS, but
slipped in a minor mistake.
Luckily, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
Update file entry to intended file location.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
---
Julius, Evan, please ack.
Wim, please pick this minor patch into your -next tree.
applies cleanly on next-20200529
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b045b70e54df..dcfb09700b96 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1489,7 +1489,7 @@ ARM SMC WATCHDOG DRIVER
M: Julius Werner <jwerner@chromium.org>
R: Evan Benn <evanbenn@chromium.org>
S: Maintained
-F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
+F: Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
F: drivers/watchdog/arm_smc_wdt.c
ARM SMMU DRIVERS
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
From: Oleksij Rempel @ 2020-06-02 5:24 UTC (permalink / raw)
To: peng.fan
Cc: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh, linux-arm-kernel, linux-kernel, linux-imx,
leonard.crestez, daniel.baluta, l.stach, devicetree, linux-clk
In-Reply-To: <1590999602-29482-2-git-send-email-peng.fan@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]
On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> index 26b7a88c2fea..906377acf2cd 100644
> --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> @@ -18,7 +18,8 @@ Messaging Unit Device Node:
> Required properties:
> -------------------
> - compatible : should be "fsl,<chip>-mu", the supported chips include
> - imx6sx, imx7s, imx8qxp, imx8qm.
> + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
> + imx8mp.
> The "fsl,imx6sx-mu" compatible is seen as generic and should
> be included together with SoC specific compatible.
> There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
> --
> 2.16.4
>
>
Hi Peng,
The fsl,mu.yaml was already taken by Rob, so one or other patch will
break by merge. I assume you should drop this change.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
From: Peng Fan @ 2020-06-02 5:26 UTC (permalink / raw)
To: Oleksij Rempel
Cc: shawnguo@kernel.org, Fabio Estevam, kernel@pengutronix.de,
Aisheng Dong, robh+dt@kernel.org, sboyd@kernel.org,
linux@rempel-privat.de, jaswinder.singh@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx, Leonard Crestez,
Daniel Baluta, l.stach@pengutronix.de, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20200602052448.fxepmwltc4465q4i@pengutronix.de>
Hi Oleksij,
> Subject: Re: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
>
> On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng.fan@nxp.com wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
> >
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > index 26b7a88c2fea..906377acf2cd 100644
> > --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > @@ -18,7 +18,8 @@ Messaging Unit Device Node:
> > Required properties:
> > -------------------
> > - compatible : should be "fsl,<chip>-mu", the supported chips include
> > - imx6sx, imx7s, imx8qxp, imx8qm.
> > + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
> > + imx8mp.
> > The "fsl,imx6sx-mu" compatible is seen as generic and should
> > be included together with SoC specific compatible.
> > There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
> > --
> > 2.16.4
> >
> >
>
> Hi Peng,
>
> The fsl,mu.yaml was already taken by Rob, so one or other patch will break by
> merge. I assume you should drop this change.
Yes. I'll rebase this patch based on Rob's tree. Thanks for reminding me.
Thanks,
Peng.
>
>
> Regards,
> Oleksij
> --
> Pengutronix e.K. |
> |
> Steuerwalder Str. 21 |
> http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone:
> +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax:
> +49-5121-206917-5555 |
^ 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