* Re: [PATCH 13/16] debug_vm_pgtable/pmd_clear: Don't use pmd/pud_clear on pte entries
From: Anshuman Khandual @ 2020-08-13 5:27 UTC (permalink / raw)
To: Aneesh Kumar K.V, linux-mm, akpm; +Cc: linuxppc-dev
In-Reply-To: <20200812063358.369514-13-aneesh.kumar@linux.ibm.com>
On 08/12/2020 12:03 PM, Aneesh Kumar K.V wrote:
> pmd_clear() should not be used to clear pmd level pte entries.
Could you please elaborate on this. The proposed change set does
not match the description here.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> mm/debug_vm_pgtable.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
> index 061c19bba7f0..529892b9be2f 100644
> --- a/mm/debug_vm_pgtable.c
> +++ b/mm/debug_vm_pgtable.c
> @@ -191,6 +191,8 @@ static void __init pmd_advanced_tests(struct mm_struct *mm,
> pmd = READ_ONCE(*pmdp);
> WARN_ON(pmd_young(pmd));
>
> + /* Clear the pte entries */
> + pmdp_huge_get_and_clear(mm, vaddr, pmdp);
> pgtable = pgtable_trans_huge_withdraw(mm, pmdp);
> }
>
> @@ -313,6 +315,8 @@ static void __init pud_advanced_tests(struct mm_struct *mm,
> pudp_test_and_clear_young(vma, vaddr, pudp);
> pud = READ_ONCE(*pudp);
> WARN_ON(pud_young(pud));
> +
> + pudp_huge_get_and_clear(mm, vaddr, pudp);
> }
>
> static void __init pud_leaf_tests(unsigned long pfn, pgprot_t prot)
> @@ -431,8 +435,6 @@ static void __init pud_populate_tests(struct mm_struct *mm, pud_t *pudp,
> * This entry points to next level page table page.
> * Hence this must not qualify as pud_bad().
> */
> - pmd_clear(pmdp);
> - pud_clear(pudp);
Both entires are cleared before creating a fresh page table entry.
Why that is a problem.
> pud_populate(mm, pudp, pmdp);
> pud = READ_ONCE(*pudp);
> WARN_ON(pud_bad(pud));
> @@ -564,7 +566,6 @@ static void __init pmd_populate_tests(struct mm_struct *mm, pmd_t *pmdp,
> * This entry points to next level page table page.
> * Hence this must not qualify as pmd_bad().
> */
> - pmd_clear(pmdp);
Ditto.
> pmd_populate(mm, pmdp, pgtable);
> pmd = READ_ONCE(*pmdp);
> WARN_ON(pmd_bad(pmd));
>
^ permalink raw reply
* Re: [PATCH 10/16] debug_vm_pgtable/thp: Use page table depost/withdraw with THP
From: Anshuman Khandual @ 2020-08-13 5:25 UTC (permalink / raw)
To: Aneesh Kumar K.V, linux-mm, akpm; +Cc: linuxppc-dev
In-Reply-To: <20200812063358.369514-10-aneesh.kumar@linux.ibm.com>
On 08/12/2020 12:03 PM, Aneesh Kumar K.V wrote:
> Architectures like ppc64 use deposited page table while updating the huge pte
> entries.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> mm/debug_vm_pgtable.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
> index 644d28861ce9..48475d288df1 100644
> --- a/mm/debug_vm_pgtable.c
> +++ b/mm/debug_vm_pgtable.c
> @@ -147,7 +147,7 @@ static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
> static void __init pmd_advanced_tests(struct mm_struct *mm,
> struct vm_area_struct *vma, pmd_t *pmdp,
> unsigned long pfn, unsigned long vaddr,
> - pgprot_t prot)
> + pgprot_t prot, pgtable_t pgtable)
> {
> pmd_t pmd;
>
> @@ -158,6 +158,8 @@ static void __init pmd_advanced_tests(struct mm_struct *mm,
> /* Align the address wrt HPAGE_PMD_SIZE */
> vaddr = (vaddr & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE;
>
> + pgtable_trans_huge_deposit(mm, pmdp, pgtable);
> +
> pmd = pmd_mkhuge(pfn_pmd(pfn, prot));
> set_pmd_at(mm, vaddr, pmdp, pmd);
> pmdp_set_wrprotect(mm, vaddr, pmdp);
> @@ -188,6 +190,8 @@ static void __init pmd_advanced_tests(struct mm_struct *mm,
> pmdp_test_and_clear_young(vma, vaddr, pmdp);
> pmd = READ_ONCE(*pmdp);
> WARN_ON(pmd_young(pmd));
> +
> + pgtable = pgtable_trans_huge_withdraw(mm, pmdp);
> }
>
> static void __init pmd_leaf_tests(unsigned long pfn, pgprot_t prot)
> @@ -1002,7 +1006,7 @@ static int __init debug_vm_pgtable(void)
> pgd_clear_tests(mm, pgdp);
>
> pte_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
> - pmd_advanced_tests(mm, vma, pmdp, pmd_aligned, vaddr, prot);
> + pmd_advanced_tests(mm, vma, pmdp, pmd_aligned, vaddr, prot, saved_ptep);
> pud_advanced_tests(mm, vma, pudp, pud_aligned, vaddr, prot);
> hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
>
>
Makes sense, if it is required for THP to work correctly but needs to be tested
across enabled platforms. Why should not the same apply for pud_advanced_tests()
on platforms that supports PUD based THP.
^ permalink raw reply
* [PATCH] powerpc/papr_scm: Limit the readability of 'perf_stats' sysfs attribute
From: Vaibhav Jain @ 2020-08-13 4:34 UTC (permalink / raw)
To: linuxppc-dev, linux-nvdimm
Cc: Santosh Sivaraj, Oliver O'Halloran, Aneesh Kumar K . V,
Vaibhav Jain, Dan Williams, Ira Weiny
The newly introduced 'perf_stats' attribute uses the default access
mode of 0444 letting non-root users access performance stats of an
nvdimm and potentially force the kernel into issuing large number of
expensive HCALLs. Since the information exposed by this attribute
cannot be cached hence its better to ward of access to this attribute
from users who don't need to access these performance statistics.
Hence this patch adds check in perf_stats_show() to only let users
that are 'perfmon_capable()' to read the nvdimm performance
statistics.
Fixes: 2d02bf835e573 ('powerpc/papr_scm: Fetch nvdimm performance stats from PHYP')
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
arch/powerpc/platforms/pseries/papr_scm.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index f439f0dfea7d1..36c51bf8af9a8 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -792,6 +792,10 @@ static ssize_t perf_stats_show(struct device *dev,
struct nvdimm *dimm = to_nvdimm(dev);
struct papr_scm_priv *p = nvdimm_provider_data(dimm);
+ /* Allow access only to perfmon capable users */
+ if (!perfmon_capable())
+ return -EACCES;
+
if (!p->stat_buffer_len)
return -ENOENT;
--
2.26.2
^ permalink raw reply related
* [PATCH 3/3] selftests/powerpc: Run tm-tmspr test for longer
From: Michael Ellerman @ 2020-08-13 1:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20200813013445.686464-1-mpe@ellerman.id.au>
This test creates some threads, which write to TM SPRs, and then makes
sure the registers maintain the correct values across context switches
and contention with other threads.
But currently the test finishes almost instantaneously, which reduces
the chance of it hitting an interesting condition.
So increase the number of loops, so it runs a bit longer, though still
less than 2s on a Power8.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/tm/tm-tmspr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/tm/tm-tmspr.c b/tools/testing/selftests/powerpc/tm/tm-tmspr.c
index 2ff329e2fca9..794d574db784 100644
--- a/tools/testing/selftests/powerpc/tm/tm-tmspr.c
+++ b/tools/testing/selftests/powerpc/tm/tm-tmspr.c
@@ -33,7 +33,7 @@
#include "utils.h"
#include "tm.h"
-int num_loops = 10000;
+int num_loops = 1000000;
int passed = 1;
void tfiar_tfhar(void *in)
--
2.25.1
^ permalink raw reply related
* [PATCH 2/3] selftests/powerpc: Don't use setaffinity in tm-tmspr
From: Michael Ellerman @ 2020-08-13 1:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20200813013445.686464-1-mpe@ellerman.id.au>
This test tries to set affinity to CPUs that don't exist, especially
if the set of online CPUs doesn't start at 0.
But there's no real reason for it to use setaffinity in the first
place, it's just trying to create lots of threads to cause contention.
So drop the setaffinity entirely.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/tm/tm-tmspr.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/tools/testing/selftests/powerpc/tm/tm-tmspr.c b/tools/testing/selftests/powerpc/tm/tm-tmspr.c
index 17becf3dcee4..2ff329e2fca9 100644
--- a/tools/testing/selftests/powerpc/tm/tm-tmspr.c
+++ b/tools/testing/selftests/powerpc/tm/tm-tmspr.c
@@ -38,14 +38,8 @@ int passed = 1;
void tfiar_tfhar(void *in)
{
- int i, cpu;
unsigned long tfhar, tfhar_rd, tfiar, tfiar_rd;
- cpu_set_t cpuset;
-
- CPU_ZERO(&cpuset);
- cpu = (unsigned long)in >> 1;
- CPU_SET(cpu, &cpuset);
- sched_setaffinity(0, sizeof(cpuset), &cpuset);
+ int i;
/* TFIAR: Last bit has to be high so userspace can read register */
tfiar = ((unsigned long)in) + 1;
--
2.25.1
^ permalink raw reply related
* [PATCH 1/3] selftests/powerpc: Fix TM tests when CPU 0 is offline
From: Michael Ellerman @ 2020-08-13 1:34 UTC (permalink / raw)
To: linuxppc-dev
Several of the TM tests fail spuriously if CPU 0 is offline, because
they blindly try to affinitise to CPU 0.
Fix them by picking any online CPU and using that instead.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/tm/tm-poison.c | 11 +++++++----
tools/testing/selftests/powerpc/tm/tm-trap.c | 10 ++++++----
tools/testing/selftests/powerpc/tm/tm-unavailable.c | 9 ++++++---
3 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/tools/testing/selftests/powerpc/tm/tm-poison.c b/tools/testing/selftests/powerpc/tm/tm-poison.c
index 977558497c16..29e5f26af7b9 100644
--- a/tools/testing/selftests/powerpc/tm/tm-poison.c
+++ b/tools/testing/selftests/powerpc/tm/tm-poison.c
@@ -26,7 +26,7 @@
int tm_poison_test(void)
{
- int pid;
+ int cpu, pid;
cpu_set_t cpuset;
uint64_t poison = 0xdeadbeefc0dec0fe;
uint64_t unknown = 0;
@@ -35,10 +35,13 @@ int tm_poison_test(void)
SKIP_IF(!have_htm());
- /* Attach both Child and Parent to CPU 0 */
+ cpu = pick_online_cpu();
+ FAIL_IF(cpu < 0);
+
+ // Attach both Child and Parent to the same CPU
CPU_ZERO(&cpuset);
- CPU_SET(0, &cpuset);
- sched_setaffinity(0, sizeof(cpuset), &cpuset);
+ CPU_SET(cpu, &cpuset);
+ FAIL_IF(sched_setaffinity(0, sizeof(cpuset), &cpuset) != 0);
pid = fork();
if (!pid) {
diff --git a/tools/testing/selftests/powerpc/tm/tm-trap.c b/tools/testing/selftests/powerpc/tm/tm-trap.c
index 601f0c1d450d..c75960af8018 100644
--- a/tools/testing/selftests/powerpc/tm/tm-trap.c
+++ b/tools/testing/selftests/powerpc/tm/tm-trap.c
@@ -247,8 +247,7 @@ void *pong(void *not_used)
int tm_trap_test(void)
{
uint16_t k = 1;
-
- int rc;
+ int cpu, rc;
pthread_attr_t attr;
cpu_set_t cpuset;
@@ -267,9 +266,12 @@ int tm_trap_test(void)
usr1_sa.sa_sigaction = usr1_signal_handler;
sigaction(SIGUSR1, &usr1_sa, NULL);
- /* Set only CPU 0 in the mask. Both threads will be bound to cpu 0. */
+ cpu = pick_online_cpu();
+ FAIL_IF(cpu < 0);
+
+ // Set only one CPU in the mask. Both threads will be bound to that CPU.
CPU_ZERO(&cpuset);
- CPU_SET(0, &cpuset);
+ CPU_SET(cpu, &cpuset);
/* Init pthread attribute */
rc = pthread_attr_init(&attr);
diff --git a/tools/testing/selftests/powerpc/tm/tm-unavailable.c b/tools/testing/selftests/powerpc/tm/tm-unavailable.c
index 2ca2fccb0a3e..a1348a5f721a 100644
--- a/tools/testing/selftests/powerpc/tm/tm-unavailable.c
+++ b/tools/testing/selftests/powerpc/tm/tm-unavailable.c
@@ -338,16 +338,19 @@ void test_fp_vec(int fp, int vec, pthread_attr_t *attr)
int tm_unavailable_test(void)
{
- int rc, exception; /* FP = 0, VEC = 1, VSX = 2 */
+ int cpu, rc, exception; /* FP = 0, VEC = 1, VSX = 2 */
pthread_t t1;
pthread_attr_t attr;
cpu_set_t cpuset;
SKIP_IF(!have_htm());
- /* Set only CPU 0 in the mask. Both threads will be bound to CPU 0. */
+ cpu = pick_online_cpu();
+ FAIL_IF(cpu < 0);
+
+ // Set only one CPU in the mask. Both threads will be bound to that CPU.
CPU_ZERO(&cpuset);
- CPU_SET(0, &cpuset);
+ CPU_SET(cpu, &cpuset);
/* Init pthread attribute. */
rc = pthread_attr_init(&attr);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
From: Nathan Lynch @ 2020-08-13 1:07 UTC (permalink / raw)
To: Michael Ellerman, Tyrel Datwyler, linuxppc-dev; +Cc: cheloha, ldufour
In-Reply-To: <87lfij9yp6.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Tyrel Datwyler <tyreld@linux.ibm.com> writes:
>> On 8/11/20 6:20 PM, Nathan Lynch wrote:
>>>
>>> +static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb)
>>> +{
>>> + const unsigned int resched_interval = 20;
>>> +
>>> + BUG_ON(lmb < drmem_info->lmbs);
>>> + BUG_ON(lmb >= drmem_info->lmbs + drmem_info->n_lmbs);
>>
>> I think BUG_ON is a pretty big no-no these days unless there is no other option.
>
> It's complicated, but yes we would like to avoid adding them if we can.
>
> In a case like this there is no other option, *if* the check has to be
> in drmem_lmb_next().
>
> But I don't think we really need to check that there.
>
> If for some reason this was called with an *lmb pointing outside of the
> lmbs array it would confuse the cond_resched() logic, but it's not worth
> crashing the box for that IMHO.
The BUG_ONs are pretty much orthogonal to the cond_resched().
It's not apparent from the context of the change, but some users of the
for_each_drmem_lmb* macros modify elements of the drmem_info->lmbs
array. If the lmb passed to drmem_lmb_next() violates the bounds check
(say, if the callsite inappropriately modifies it within the loop), such
users are guaranteed to corrupt other objects in memory. This was my
thinking in adding the BUG_ONs, and I don't see another place to do
it.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix P10 PVR revision in /proc/cpuinfo for SMT4 cores
From: Michael Neuling @ 2020-08-13 0:34 UTC (permalink / raw)
To: Michael Ellerman; +Cc: grimm, linuxppc-dev
In-Reply-To: <87sgd3zyt6.fsf@mpe.ellerman.id.au>
On Mon, 2020-08-03 at 22:41 +1000, Michael Ellerman wrote:
> Michael Neuling <mikey@neuling.org> writes:
> > On POWER10 bit 12 in the PVR indicates if the core is SMT4 or
> > SMT8. Bit 12 is set for SMT4.
> >
> > Without this patch, /proc/cpuinfo on a SMT4 DD1 POWER10 looks like
> > this:
> > cpu : POWER10, altivec supported
> > revision : 17.0 (pvr 0080 1100)
> >
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
> > ---
> > arch/powerpc/kernel/setup-common.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> This should have a Fixes: pointing at something so it gets backported.
Yes it should.
Mikey
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
From: Michael Ellerman @ 2020-08-13 0:28 UTC (permalink / raw)
To: Tyrel Datwyler, Nathan Lynch, linuxppc-dev; +Cc: cheloha, ldufour
In-Reply-To: <5e8213a6-802b-f7ca-b43b-a3de8a03d1da@linux.ibm.com>
Tyrel Datwyler <tyreld@linux.ibm.com> writes:
> On 8/11/20 6:20 PM, Nathan Lynch wrote:
>> The drmem lmb list can have hundreds of thousands of entries, and
>> unfortunately lookups take the form of linear searches. As long as
>> this is the case, traversals have the potential to monopolize the CPU
>> and provoke lockup reports, workqueue stalls, and the like unless
>> they explicitly yield.
>>
>> Rather than placing cond_resched() calls within various
>> for_each_drmem_lmb() loop blocks in the code, put it in the iteration
>> expression of the loop macro itself so users can't omit it.
>>
>> Call cond_resched() on every 20th element. Each iteration of the loop
>> in DLPAR code paths can involve around ten RTAS calls which can each
>> take up to 250us, so this ensures the check is performed at worst
>> every few milliseconds.
>>
>> Fixes: 6c6ea53725b3 ("powerpc/mm: Separate ibm, dynamic-memory data from DT format")
>> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
>> ---
>> arch/powerpc/include/asm/drmem.h | 18 +++++++++++++++++-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> Changes since v1:
>> * Add bounds assertions in drmem_lmb_next().
>> * Call cond_resched() in the iterator on only every 20th element
>> instead of on every iteration, to reduce overhead in tight loops.
>>
>> diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
>> index 17ccc6474ab6..583277e30dd2 100644
>> --- a/arch/powerpc/include/asm/drmem.h
>> +++ b/arch/powerpc/include/asm/drmem.h
>> @@ -8,6 +8,9 @@
>> #ifndef _ASM_POWERPC_LMB_H
>> #define _ASM_POWERPC_LMB_H
>>
>> +#include <linux/bug.h>
>> +#include <linux/sched.h>
>> +
>> struct drmem_lmb {
>> u64 base_addr;
>> u32 drc_index;
>> @@ -26,8 +29,21 @@ struct drmem_lmb_info {
>>
>> extern struct drmem_lmb_info *drmem_info;
>>
>> +static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb)
>> +{
>> + const unsigned int resched_interval = 20;
>> +
>> + BUG_ON(lmb < drmem_info->lmbs);
>> + BUG_ON(lmb >= drmem_info->lmbs + drmem_info->n_lmbs);
>
> I think BUG_ON is a pretty big no-no these days unless there is no other option.
It's complicated, but yes we would like to avoid adding them if we can.
In a case like this there is no other option, *if* the check has to be
in drmem_lmb_next().
But I don't think we really need to check that there.
If for some reason this was called with an *lmb pointing outside of the
lmbs array it would confuse the cond_resched() logic, but it's not worth
crashing the box for that IMHO.
cheers
^ permalink raw reply
* [RFC PATCH v1 1/4] powerpc: apm82181: create shared dtsi for APM bluestone
From: Christian Lamparter @ 2020-08-12 22:41 UTC (permalink / raw)
To: linuxppc-dev, devicetree; +Cc: Paul Mackerras, Rob Herring, Chris Blake
In-Reply-To: <cover.1597271958.git.chunkeey@gmail.com>
This patch adds an DTSI-File that can be used by various device-tree
files for APM82181-based devices.
Some of the nodes (like UART, PCIE, SATA) are used by the uboot and
need to stick with the naming-conventions of the old times'.
I've added comments whenever this was the case. But unfortunately,
this I've to point out that for this reason, there are some warning
messages when compiling the dtb:
> apm82181.dtsi:440.26-483.5: Warning (pci_bridge): /plb/pciex@d00000000: node name is not "pci" or "pcie"
> wd-mybooklive.dtb: Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge'
Signed-off-By: Chris Blake <chrisrblake93@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
arch/powerpc/boot/dts/apm82181.dtsi | 485 ++++++++++++++++++++++++++++
1 file changed, 485 insertions(+)
create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi
diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi
new file mode 100644
index 000000000000..54a9a6fda4af
--- /dev/null
+++ b/arch/powerpc/boot/dts/apm82181.dtsi
@@ -0,0 +1,485 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Device Tree template include for various Bluestone (APM82181) boards.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Tirumala R Marri <tmarri@apm.com>,
+ * Christian Lamparter <chunkeey@gmail.com>,
+ * Chris Blake <chrisrblake93@gmail.com>
+ */
+
+#include <dt-bindings/dma/dw-dmac.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ dcr-parent = <&{/cpus/cpu@0}>;
+ compatible = "apm,bluestone";
+
+ aliases {
+ ethernet0 = &EMAC0; /* needed for BSP u-boot */
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,apm82181";
+ reg = <0x00000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <32768>;
+ d-cache-size = <32768>;
+ dcr-controller;
+ dcr-access-method = "native";
+ next-level-cache = <&L2C0>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x00000000 0x00000000>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "apm,uic-apm82181", "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0x0c0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "apm,uic-apm82181", "ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0x0d0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x1e IRQ_TYPE_LEVEL_HIGH>,
+ <0x1f IRQ_TYPE_LEVEL_HIGH>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "apm,uic-apm82181", "ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0x0e0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x0a IRQ_TYPE_LEVEL_HIGH>,
+ <0x0b IRQ_TYPE_LEVEL_HIGH>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "apm,uic-apm82181","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0x0f0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x10 IRQ_TYPE_LEVEL_HIGH>,
+ <0x11 IRQ_TYPE_LEVEL_HIGH>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ OCM1: ocm@400040000 {
+ compatible = "apm,ocm-apm82181", "ibm,ocm";
+ status = "okay";
+ cell-index = <1>;
+ /* configured in U-Boot */
+ reg = <4 0x00040000 0x8000>; /* 32K */
+ };
+
+ SDR0: sdr {
+ compatible = "apm,sdr-apm82181", "ibm,sdr-460ex";
+ dcr-reg = <0x00e 0x002>;
+ };
+
+ CPR0: cpr {
+ compatible = "apm,cpr-apm82181", "ibm,cpr-460ex";
+ dcr-reg = <0x00c 0x002>;
+ };
+
+ L2C0: l2c {
+ compatible = "ibm,l2-cache-apm82181", "ibm,l2-cache";
+ dcr-reg = <0x020 0x008
+ 0x030 0x008>;
+ cache-line-size = <32>;
+ cache-size = <262144>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <0x0b IRQ_TYPE_EDGE_RISING>;
+ };
+
+ CPM0: cpm {
+ compatible = "ibm,cpm-apm821xx", "ibm,cpm";
+ cell-index = <0>;
+ dcr-reg = <0x160 0x003>;
+ pm-cpu = <0x02000000>;
+ pm-doze = <0x302570F0>;
+ pm-nap = <0x302570F0>;
+ pm-deepsleep = <0x302570F0>;
+ pm-iic-device = <&IIC0>;
+ pm-emac-device = <&EMAC0>;
+ unused-units = <0x00000100>;
+ idle-doze = <0x02000000>;
+ standby = <0xfeff791d>;
+ };
+
+ plb {
+ compatible = "apm,plb-apm82181", "ibm,plb-460ex", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges; /* Filled in by U-Boot */
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "apm,sdram-apm82181", "ibm,sdram-460ex", "ibm,sdram-405gp";
+ dcr-reg = <0x010 0x002>;
+ };
+
+ RTC: rtc {
+ compatible = "ibm,rtc";
+ dcr-reg = <0x240 0x009>;
+ interrupts = <0x1a IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&UIC2>;
+ status = "disabled";
+ };
+
+ TRNG: trng@110000 {
+ compatible = "amcc,ppc460ex-rng", "ppc4xx-rng", "amcc, ppc4xx-trng";
+ reg = <4 0x00110000 0x100>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <0x03 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ PKA: pka@114000 {
+ compatible = "ppc4xx-pka", "amcc,ppc4xx-pka", "amcc, ppc4xx-pka";
+ reg = <4 0x00114000 0x4000>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x14 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
+
+ CRYPTO: crypto@180000 {
+ compatible = "amcc,ppc460ex-crypto", "amcc,ppc4xx-crypto";
+ reg = <4 0x00180000 0x80400>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x1d IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled"; /* hardware option */
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
+ descriptor-memory = "ocm";
+ dcr-reg = <0x180 0x062>;
+ num-tx-chans = <1>;
+ num-rx-chans = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = <0x06 IRQ_TYPE_LEVEL_HIGH>,
+ <0x07 IRQ_TYPE_LEVEL_HIGH>,
+ <0x03 IRQ_TYPE_LEVEL_HIGH>,
+ <0x04 IRQ_TYPE_LEVEL_HIGH>,
+ <0x05 IRQ_TYPE_LEVEL_HIGH>,
+ <0x08 IRQ_TYPE_EDGE_FALLING>,
+ <0x09 IRQ_TYPE_EDGE_FALLING>,
+ <0x0c IRQ_TYPE_EDGE_FALLING>,
+ <0x0d IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "txeob", "rxeob", "serr",
+ "txde", "rxde",
+ "tx0coal", "tx1coal",
+ "rx0coal", "rx1coal";
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-460ex", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0xb0000000 0x00000004 0xb0000000 0x50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-460ex", "ibm,ebc";
+ dcr-reg = <0x012 0x002>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ ranges = <0x00000003 0x00000000 0xe0000000 0x8000000>;
+ interrupts = <0x06 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "cfi-flash";
+ bank-width = <1>;
+ reg = <0x00000000 0x00000000 0x00100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "disabled";
+ };
+
+ ndfc@1,0 {
+ compatible = "ibm,ndfc";
+ reg = <00000003 00000000 00002000>;
+ ccr = <0x00001000>;
+ bank-settings = <0x80002222>;
+ status = "disabled";
+
+ nand {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+ };
+
+ UART0: serial@ef600300 {
+ /*
+ * AMCC's BSP u-boot scans for the "ns16550"
+ * compatible, without it, u-boot wouldn't
+ * set the required "clock-frequency".
+ *
+ * The hardware documentation states:
+ * "Register compatibility with 16750 register set"
+ */
+ compatible = "ns16750", "ns16550";
+ reg = <0xef600300 0x00000008>;
+ virtual-reg = <0xef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <0x01 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ UART1: serial@ef600400 {
+ /* same "ns16750" as with UART0 */
+ compatible = "ns16750", "ns16550";
+ reg = <0xef600400 0x00000008>;
+ virtual-reg = <0xef600400>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x01 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic-460ex", "ibm,iic";
+ reg = <0xef600700 0x00000014>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x02 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic-460ex", "ibm,iic";
+ reg = <0xef600800 0x00000014>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x03 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ GPIO0: gpio@ef600b00 {
+ compatible = "ibm,ppc4xx-gpio";
+ reg = <0xef600b00 0x00000048>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ status = "disabled";
+ };
+
+ EMAC0: ethernet@ef600c00 {
+ device_type = "network";
+ compatible = "ibm,emac-apm821xx", "ibm,emac4sync";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC2 0x10 IRQ_TYPE_LEVEL_HIGH>,
+ <1 &UIC2 0x14 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "status", "wake";
+
+ reg = <0xef600c00 0x000000c4>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <9000>;
+ rx-fifo-size = <16384>;
+ tx-fifo-size = <2048>;
+ phy-mode = "rgmii";
+ phy-map = <0x00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ status = "disabled";
+ };
+
+ TAH0: emac-tah@ef601350 {
+ compatible = "ibm,tah-460ex", "ibm,tah";
+ reg = <0xef601350 0x00000030>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii-405ex", "ibm,rgmii";
+ reg = <0xef601500 0x00000008>;
+ has-mdio;
+ };
+ };
+
+ USBOTG0: usbotg@bff80000 {
+ compatible = "amcc,dwc-otg";
+ reg = <4 0xbff80000 0x10000>;
+ interrupt-parent = <&USBOTG0>;
+ interrupts = <0 1 2>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC2 0x1c IRQ_TYPE_LEVEL_HIGH>,
+ <1 &UIC1 0x1a IRQ_TYPE_LEVEL_LOW>,
+ <2 &UIC0 0x0c IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "usb-otg", "high-power", "dma";
+ dr_mode = "host";
+ status = "disabled";
+ };
+
+ AHBDMA0: dma@bffd0800 {
+ compatible = "snps,dma-spear1340";
+ reg = <4 0xbffd0800 0x400>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x19 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <3>;
+
+ dma-channels = <2>;
+ dma-masters = <3>;
+ block_size = <4095>;
+ data-width = <4>, <4>, <4>;
+ multi-block = <1>, <1>;
+
+ chan_allocation_order = <1>;
+ chan_priority = <1>;
+
+ snps,dma-protection-control =
+ <(DW_DMAC_HPROT1_PRIVILEGED_MODE |
+ DW_DMAC_HPROT2_BUFFERABLE)>;
+ is_memcpy;
+ };
+
+ SATA0: sata@bffd1000 {
+ compatible = "amcc,sata-460ex";
+ reg = <4 0xbffd1000 0x800>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x1a IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&AHBDMA0 0 0 1>;
+ dma-names = "sata-dma";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ SATA1: sata@bffd1800 {
+ compatible = "amcc,sata-460ex";
+ reg = <4 0xbffd1800 0x800>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x1b IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&AHBDMA0 1 0 2>;
+ dma-names = "sata-dma";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ MSI: ppc4xx-msi@c10000000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = <0xc 0x10000000 0x100
+ 0xc 0x10000000 0x100>;
+ sdr-base = <0x36C>;
+ msi-data = <0x00004440>;
+ msi-mask = <0x0000ffe0>;
+ interrupts =<0 1 2 3 4 5 6 7>;
+ interrupt-parent = <&MSI>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ msi-available-ranges = <0x0 0x100>;
+ interrupt-map =
+ <0 &UIC3 0x18 IRQ_TYPE_EDGE_RISING>,
+ <1 &UIC3 0x19 IRQ_TYPE_EDGE_RISING>,
+ <2 &UIC3 0x1a IRQ_TYPE_EDGE_RISING>,
+ <3 &UIC3 0x1b IRQ_TYPE_EDGE_RISING>,
+ <4 &UIC3 0x1c IRQ_TYPE_EDGE_RISING>,
+ <5 &UIC3 0x1d IRQ_TYPE_EDGE_RISING>,
+ <6 &UIC3 0x1e IRQ_TYPE_EDGE_RISING>,
+ <7 &UIC3 0x1f IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
+
+ PCIE0: pciex@d00000000 {
+ device_type = "pci"; /* see ppc4xx_pci_find_bridge */
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-apm821xx", "ibm,plb-pciex";
+ primary;
+ port = <0x0>; /* port number */
+ reg = <0x0000000d 0x00000000 0x20000000>, /* Config space access */
+ <0x0000000c 0x08010000 0x00001000>; /* Registers */
+ dcr-reg = <0x100 0x020>;
+ sdr-base = <0x300>;
+
+ /*
+ * Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <0x02000000 0x00000000 0x80000000 0x0000000e 0x00000000 0x00000000 0x80000000>,
+ <0x02000000 0x00000000 0x00000000 0x0000000f 0x00000000 0x00000000 0x00100000>,
+ <0x01000000 0x00000000 0x00000000 0x0000000f 0x80000000 0x00000000 0x00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
+
+ /* This drives busses 0x40 to 0x7f */
+ bus-range = <0x40 0x7f>;
+
+ /*
+ * Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map =
+ <0x0 0x0 0x0 0x1 &UIC3 0x0c IRQ_TYPE_LEVEL_HIGH>, /* swizzled int A */
+ <0x0 0x0 0x0 0x2 &UIC3 0x0d IRQ_TYPE_LEVEL_HIGH>, /* swizzled int B */
+ <0x0 0x0 0x0 0x3 &UIC3 0x0e IRQ_TYPE_LEVEL_HIGH>, /* swizzled int C */
+ <0x0 0x0 0x0 0x4 &UIC3 0x0f IRQ_TYPE_LEVEL_HIGH>; /* swizzled int D */
+ status = "disabled";
+ };
+ };
+};
--
2.28.0
^ permalink raw reply related
* [RFC PATCH v1 3/4] powerpc: apm82181: add Meraki MR24 AP
From: Christian Lamparter @ 2020-08-12 22:41 UTC (permalink / raw)
To: linuxppc-dev, devicetree; +Cc: Paul Mackerras, Rob Herring, Chris Blake
In-Reply-To: <08dd11e8ce996a0df27dca3a9316bfc4ede0d0d0.1597271958.git.chunkeey@gmail.com>
This patch adds the device-tree definitions for Meraki MR24
Accesspoint devices.
Ready to go images and install instruction can be found @OpenWrt.
Signed-off-By: Chris Blake <chrisrblake93@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
arch/powerpc/boot/dts/meraki-mr24.dts | 237 +++++++++++++++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
2 files changed, 238 insertions(+)
create mode 100644 arch/powerpc/boot/dts/meraki-mr24.dts
diff --git a/arch/powerpc/boot/dts/meraki-mr24.dts b/arch/powerpc/boot/dts/meraki-mr24.dts
new file mode 100644
index 000000000000..945e3e6b2585
--- /dev/null
+++ b/arch/powerpc/boot/dts/meraki-mr24.dts
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Device Tree Source for Meraki MR24 (Ikarem)
+ *
+ * Copyright (C) 2016 Chris Blake <chrisrblake93@gmail.com>
+ *
+ * Based on Cisco Meraki GPL Release r23-20150601 MR24 DTS
+ */
+
+/dts-v1/;
+
+#include "apm82181.dtsi"
+
+/ {
+ model = "Meraki MR24 Access Point";
+ compatible = "meraki,mr24";
+
+ aliases {
+ serial0 = &UART1;
+ led-boot = &status;
+ led-failsafe = &failsafe;
+ led-running = &status;
+ led-upgrade = &status;
+ };
+
+ chosen {
+ stdout-path = "/plb/opb/serial@ef600400";
+ };
+};
+
+
+&CRYPTO {
+ status = "okay";
+};
+
+&PKA {
+ status = "okay";
+};
+
+&TRNG {
+ status = "okay";
+};
+
+&EBC0 {
+ /* Ikarem has 32MB of NAND */
+ ndfc@1,0 {
+ status = "okay";
+ /* 32 MiB NAND Flash */
+ nand {
+ partition@0 {
+ label = "u-boot";
+ reg = <0x00000000 0x00150000>;
+ read-only;
+ };
+
+ partition@150000 {
+ /*
+ * The u-boot environment size is one NAND
+ * block (16KiB). u-boot allocates four NAND
+ * blocks (64KiB) in order to have spares
+ * around for bad block management
+ */
+ label = "u-boot-env";
+ reg = <0x00150000 0x00010000>;
+ read-only;
+ };
+
+ partition@160000 {
+ /*
+ * redundant u-boot environment.
+ * has to be kept it in sync with the
+ * data in "u-boot-env".
+ */
+ label = "u-boot-env-redundant";
+ reg = <0x00160000 0x00010000>;
+ read-only;
+ };
+
+ partition@170000 {
+ label = "oops";
+ reg = <0x00170000 0x00010000>;
+ };
+
+ partition@180000 {
+ label = "ubi";
+ reg = <0x00180000 0x01e80000>;
+ };
+ };
+ };
+};
+
+&UART1 {
+ status = "okay";
+};
+
+&GPIO0 {
+ status = "okay";
+};
+
+&IIC0 {
+ status = "okay";
+ /* Boot ROM is at 0x52-0x53, do not touch */
+ /* Unknown chip at 0x6e, not sure what it is */
+};
+
+&EMAC0 {
+ status = "okay";
+
+ phy-mode = "rgmii-id";
+ phy-map = <0x2>;
+ phy-address = <0x1>;
+ phy-handle = <&phy>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy: phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+};
+
+&POB0 {
+ leds {
+ compatible = "gpio-leds";
+
+ status: power-green {
+ label = "mr24:green:power";
+ gpios = <&GPIO0 18 GPIO_ACTIVE_LOW>;
+ };
+
+ failsafe: power-orange {
+ label = "mr24:orange:power";
+ gpios = <&GPIO0 19 GPIO_ACTIVE_LOW>;
+ };
+
+ lan {
+ label = "mr24:green:wan";
+ gpios = <&GPIO0 17 GPIO_ACTIVE_LOW>;
+ };
+
+ ssi-0 {
+ label = "mr24:green:wifi1";
+ gpios = <&GPIO0 23 GPIO_ACTIVE_LOW>;
+ };
+
+ ssi-1 {
+ label = "mr24:green:wifi2";
+ gpios = <&GPIO0 22 GPIO_ACTIVE_LOW>;
+ };
+
+ ssi-2 {
+ label = "mr24:green:wifi3";
+ gpios = <&GPIO0 21 GPIO_ACTIVE_LOW>;
+ };
+
+ ssi-3 {
+ label = "mr24:green:wifi4";
+ gpios = <&GPIO0 20 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ /* Label as per Meraki's "MR24 Installation Guide" */
+ label = "Factory Reset Button";
+ linux,code = <KEY_RESTART>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <0x15 IRQ_TYPE_EDGE_FALLING>;
+ gpios = <&GPIO0 16 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+};
+
+&PCIE0 {
+ status = "okay";
+ /*
+ * relevant lspci topology:
+ *
+ * -+-[0000:40]---00.0-[41-7f]----00.0-[42-45]--+-02.0-[43]----00.0
+ * +-03.0-[44]----00.0
+ *
+ */
+
+ bridge@64,0 {
+ reg = <0x00400000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ bridge@65,0 {
+ /* IDT PES3T3 PCI Express Switch */
+ compatible = "pci111d,8039";
+ reg = <0x00410000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ bridge@66,2 {
+ compatible = "pci111d,8039";
+ reg = <0x00421000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ wifi0: wifi@67,0 {
+ /* Atheros AR9380 2.4GHz */
+ compatible = "pci168c,0030";
+ reg = <0x00430000 0 0 0 0>;
+ };
+ };
+
+ bridge@66,3 {
+ compatible = "pci111d,8039";
+ reg = <0x00421800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ wifi1: wifi@68,0 {
+ /* Atheros AR9380 5GHz */
+ compatible = "pci168c,0030";
+ reg = <0x00440000 0 0 0 0>;
+ };
+ };
+ };
+ };
+};
+
+&MSI {
+ status = "okay";
+};
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 1122702c804a..7d479928fd48 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -60,6 +60,7 @@ static char *board[] __initdata = {
"amcc,taishan",
"amcc,yosemite",
"mosaixtech,icon",
+ "meraki,mr24",
"wd,mybooklive",
};
--
2.28.0
^ permalink raw reply related
* [RFC PATCH v1 0/4] powerpc: apm82181: adding customer devices
From: Christian Lamparter @ 2020-08-12 22:41 UTC (permalink / raw)
To: linuxppc-dev, devicetree; +Cc: Paul Mackerras, Rob Herring, Chris Blake
Hello,
I've been holding on to these devices dts' for a while now.
But ever since the recent purge of the PPC405, I'm feeling
the urge to move forward.
The devices in question have been running with OpenWrt since
around 2016/2017. Back then it was linux v4.4 and required
many out-of-tree patches (for WIFI, SATA, CRYPTO...), that
since have been integrated. So, there's nothing else in the
way I think.
Now, I've looked around in the arch/powerpc for recent .dts
and device submissions to get an understanding of what is
required.
From the looks of it, it seems like every device gets a
skeleton defconfig and a CONFIG_$DEVICE symbol (Like:
CONFIG_MERAKI_MR24, CONFIG_WD_MYBOOKLIVE).
Will this be the case? Or would it make sense to further
unite the Bluestone, MR24 and MBL under a common CONFIG_APM82181
and integrate the BLUESTONE device's defconfig into it as well?
(I've stumbled accross the special machine compatible
handling of ppc in the Documentation/devicetree/usage-model.rst
already.)
Cheers,
Christian
Note:
If someone has a WD MyBook Live (DUO) and is interested in
giving it a spin with 5.8. I've made a:
"build your own Debian System" sort of script that can be
found on github: <https://github.com/chunkeey/mbl-debian>
(the only remaining patch hack is for debian's make-kpkg crossbuild)
Furthermore, the OpenWrt project currently has images for the
following apm82181 devices:
Cisco Meraki MX60(W) - Needs DSA for the AR8327
Netgear WNDAP620/WNDAP660 - (Could be next)
Netgear WNDR4700 - Needs DSA for the AR8327
Note2: I do have a stash of extensive APM82181 related documentation.
Christian Lamparter (4):
powerpc: apm82181: create shared dtsi for APM bluestone
powerpc: apm82181: add WD MyBook Live NAS
powerpc: apm82181: add Meraki MR24 AP
powerpc: apm82181: integrate bluestone.dts
arch/powerpc/boot/dts/apm82181.dtsi | 485 +++++++++++++++++++++
arch/powerpc/boot/dts/bluestone.dts | 456 +++++--------------
arch/powerpc/boot/dts/meraki-mr24.dts | 237 ++++++++++
arch/powerpc/boot/dts/wd-mybooklive.dts | 199 +++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 4 +-
5 files changed, 1033 insertions(+), 348 deletions(-)
create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi
create mode 100644 arch/powerpc/boot/dts/meraki-mr24.dts
create mode 100644 arch/powerpc/boot/dts/wd-mybooklive.dts
--
2.28.0
^ permalink raw reply
* [RFC PATCH v1 4/4] powerpc: apm82181: integrate bluestone.dts
From: Christian Lamparter @ 2020-08-12 22:41 UTC (permalink / raw)
To: linuxppc-dev, devicetree; +Cc: Paul Mackerras, Rob Herring, Chris Blake
In-Reply-To: <0732d462e1f727dc95898bd33cdde920ce81e2ff.1597271958.git.chunkeey@gmail.com>
This patch tries to integrate the existing bluestone.dts into the
apm82181.dtsi framework.
The original bluestone.dts produces a peculiar warning message.
> bluestone.dts:120.10-125.4: Warning (i2c_bus_reg):
> /plb/opb/i2c@ef600700/sttm@4C: I2C bus unit address format error, expected "4c"
For now, this has been kept alone.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
arch/powerpc/boot/dts/bluestone.dts | 456 +++++++---------------------
1 file changed, 109 insertions(+), 347 deletions(-)
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
index cc965a1816b6..bf83bdaa8ec9 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -8,388 +8,150 @@
/dts-v1/;
+#include "apm82181.dtsi"
+
/ {
- #address-cells = <2>;
- #size-cells = <1>;
model = "apm,bluestone";
compatible = "apm,bluestone";
- dcr-parent = <&{/cpus/cpu@0}>;
aliases {
- ethernet0 = &EMAC0;
serial0 = &UART0;
serial1 = &UART1;
};
+};
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu@0 {
- device_type = "cpu";
- model = "PowerPC,apm821xx";
- reg = <0x00000000>;
- clock-frequency = <0>; /* Filled in by U-Boot */
- timebase-frequency = <0>; /* Filled in by U-Boot */
- i-cache-line-size = <32>;
- d-cache-line-size = <32>;
- i-cache-size = <32768>;
- d-cache-size = <32768>;
- dcr-controller;
- dcr-access-method = "native";
- next-level-cache = <&L2C0>;
- };
- };
-
- memory {
- device_type = "memory";
- reg = <0x00000000 0x00000000 0x00000000>; /* Filled in by U-Boot */
- };
+&CRYPTO {
+ status = "okay";
+};
- UIC0: interrupt-controller0 {
- compatible = "ibm,uic";
- interrupt-controller;
- cell-index = <0>;
- dcr-reg = <0x0c0 0x009>;
- #address-cells = <0>;
- #size-cells = <0>;
- #interrupt-cells = <2>;
- };
+&PKA {
+ status = "okay";
+};
- UIC1: interrupt-controller1 {
- compatible = "ibm,uic";
- interrupt-controller;
- cell-index = <1>;
- dcr-reg = <0x0d0 0x009>;
- #address-cells = <0>;
- #size-cells = <0>;
- #interrupt-cells = <2>;
- interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
- interrupt-parent = <&UIC0>;
- };
+&TRNG {
+ status = "okay";
+};
- UIC2: interrupt-controller2 {
- compatible = "ibm,uic";
- interrupt-controller;
- cell-index = <2>;
- dcr-reg = <0x0e0 0x009>;
- #address-cells = <0>;
- #size-cells = <0>;
- #interrupt-cells = <2>;
- interrupts = <0xa 0x4 0xb 0x4>; /* cascade */
- interrupt-parent = <&UIC0>;
- };
+&EBC0 {
+ status = "okay";
- UIC3: interrupt-controller3 {
- compatible = "ibm,uic";
- interrupt-controller;
- cell-index = <3>;
- dcr-reg = <0x0f0 0x009>;
- #address-cells = <0>;
- #size-cells = <0>;
- #interrupt-cells = <2>;
- interrupts = <0x10 0x4 0x11 0x4>; /* cascade */
- interrupt-parent = <&UIC0>;
- };
-
- OCM: ocm@400040000 {
- compatible = "ibm,ocm";
+ nor_flash@0,0 {
status = "okay";
- cell-index = <1>;
- /* configured in U-Boot */
- reg = <4 0x00040000 0x8000>; /* 32K */
- };
-
- SDR0: sdr {
- compatible = "ibm,sdr-apm821xx";
- dcr-reg = <0x00e 0x002>;
- };
-
- CPR0: cpr {
- compatible = "ibm,cpr-apm821xx";
- dcr-reg = <0x00c 0x002>;
- };
-
- L2C0: l2c {
- compatible = "ibm,l2-cache-apm82181", "ibm,l2-cache";
- dcr-reg = <0x020 0x008
- 0x030 0x008>;
- cache-line-size = <32>;
- cache-size = <262144>;
- interrupt-parent = <&UIC1>;
- interrupts = <11 1>;
- };
- plb {
- compatible = "ibm,plb4";
- #address-cells = <2>;
+ compatible = "amd,s29gl512n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0x00000000 0x00000000 0x00400000>;
+ #address-cells = <1>;
#size-cells = <1>;
- ranges;
- clock-frequency = <0>; /* Filled in by U-Boot */
-
- SDRAM0: sdram {
- compatible = "ibm,sdram-apm821xx";
- dcr-reg = <0x010 0x002>;
+ partition@0 {
+ label = "kernel";
+ reg = <0x00000000 0x00180000>;
};
-
- MAL0: mcmal {
- compatible = "ibm,mcmal2";
- descriptor-memory = "ocm";
- dcr-reg = <0x180 0x062>;
- num-tx-chans = <1>;
- num-rx-chans = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-parent = <&UIC2>;
- interrupts = < /*TXEOB*/ 0x6 0x4
- /*RXEOB*/ 0x7 0x4
- /*SERR*/ 0x3 0x4
- /*TXDE*/ 0x4 0x4
- /*RXDE*/ 0x5 0x4>;
+ partition@180000 {
+ label = "env";
+ reg = <0x00180000 0x00020000>;
+ };
+ partition@1a0000 {
+ label = "u-boot";
+ reg = <0x001a0000 0x00060000>;
};
+ };
+
+ ndfc@1,0 {
+ status = "okay";
- POB0: opb {
- compatible = "ibm,opb";
+ /* 2Gb Nand Flash */
+ nand {
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0xb0000000 0x00000004 0xb0000000 0x50000000>;
- clock-frequency = <0>; /* Filled in by U-Boot */
-
- EBC0: ebc {
- compatible = "ibm,ebc";
- dcr-reg = <0x012 0x002>;
- #address-cells = <2>;
- #size-cells = <1>;
- clock-frequency = <0>; /* Filled in by U-Boot */
- /* ranges property is supplied by U-Boot */
- ranges = < 0x00000003 0x00000000 0xe0000000 0x8000000>;
- interrupts = <0x6 0x4>;
- interrupt-parent = <&UIC1>;
-
- nor_flash@0,0 {
- compatible = "amd,s29gl512n", "cfi-flash";
- bank-width = <2>;
- reg = <0x00000000 0x00000000 0x00400000>;
- #address-cells = <1>;
- #size-cells = <1>;
- partition@0 {
- label = "kernel";
- reg = <0x00000000 0x00180000>;
- };
- partition@180000 {
- label = "env";
- reg = <0x00180000 0x00020000>;
- };
- partition@1a0000 {
- label = "u-boot";
- reg = <0x001a0000 0x00060000>;
- };
- };
- ndfc@1,0 {
- compatible = "ibm,ndfc";
- reg = <0x00000003 0x00000000 0x00002000>;
- ccr = <0x00001000>;
- bank-settings = <0x80002222>;
- #address-cells = <1>;
- #size-cells = <1>;
- /* 2Gb Nand Flash */
- nand {
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "firmware";
- reg = <0x00000000 0x00C00000>;
- };
- partition@c00000 {
- label = "environment";
- reg = <0x00C00000 0x00B00000>;
- };
- partition@1700000 {
- label = "kernel";
- reg = <0x01700000 0x00E00000>;
- };
- partition@2500000 {
- label = "root";
- reg = <0x02500000 0x08200000>;
- };
- partition@a700000 {
- label = "device-tree";
- reg = <0x0A700000 0x00B00000>;
- };
- partition@b200000 {
- label = "config";
- reg = <0x0B200000 0x00D00000>;
- };
- partition@bf00000 {
- label = "diag";
- reg = <0x0BF00000 0x00C00000>;
- };
- partition@cb00000 {
- label = "vendor";
- reg = <0x0CB00000 0x3500000>;
- };
- };
- };
+ partition@0 {
+ label = "firmware";
+ reg = <0x00000000 0x00C00000>;
};
-
- UART0: serial@ef600300 {
- device_type = "serial";
- compatible = "ns16550";
- reg = <0xef600300 0x00000008>;
- virtual-reg = <0xef600300>;
- clock-frequency = <0>; /* Filled in by U-Boot */
- current-speed = <0>; /* Filled in by U-Boot */
- interrupt-parent = <&UIC1>;
- interrupts = <0x1 0x4>;
+ partition@c00000 {
+ label = "environment";
+ reg = <0x00C00000 0x00B00000>;
};
-
- UART1: serial@ef600400 {
- device_type = "serial";
- compatible = "ns16550";
- reg = <0xef600400 0x00000008>;
- virtual-reg = <0xef600400>;
- clock-frequency = <0>; /* Filled in by U-Boot */
- current-speed = <0>; /* Filled in by U-Boot */
- interrupt-parent = <&UIC0>;
- interrupts = <0x1 0x4>;
+ partition@1700000 {
+ label = "kernel";
+ reg = <0x01700000 0x00E00000>;
};
-
- IIC0: i2c@ef600700 {
- compatible = "ibm,iic";
- reg = <0xef600700 0x00000014>;
- interrupt-parent = <&UIC0>;
- interrupts = <0x2 0x4>;
- #address-cells = <1>;
- #size-cells = <0>;
- rtc@68 {
- compatible = "st,m41t80";
- reg = <0x68>;
- interrupt-parent = <&UIC0>;
- interrupts = <0x9 0x8>;
- };
- sttm@4C {
- compatible = "adm,adm1032";
- reg = <0x4C>;
- interrupt-parent = <&UIC1>;
- interrupts = <0x1E 0x8>; /* CPU_THERNAL_L */
- };
+ partition@2500000 {
+ label = "root";
+ reg = <0x02500000 0x08200000>;
};
-
- IIC1: i2c@ef600800 {
- compatible = "ibm,iic";
- reg = <0xef600800 0x00000014>;
- interrupt-parent = <&UIC0>;
- interrupts = <0x3 0x4>;
+ partition@a700000 {
+ label = "device-tree";
+ reg = <0x0A700000 0x00B00000>;
};
-
- RGMII0: emac-rgmii@ef601500 {
- compatible = "ibm,rgmii";
- reg = <0xef601500 0x00000008>;
- has-mdio;
+ partition@b200000 {
+ label = "config";
+ reg = <0x0B200000 0x00D00000>;
};
-
- TAH0: emac-tah@ef601350 {
- compatible = "ibm,tah";
- reg = <0xef601350 0x00000030>;
+ partition@bf00000 {
+ label = "diag";
+ reg = <0x0BF00000 0x00C00000>;
};
-
- EMAC0: ethernet@ef600c00 {
- device_type = "network";
- compatible = "ibm,emac-apm821xx", "ibm,emac4sync";
- interrupt-parent = <&EMAC0>;
- interrupts = <0x0 0x1>;
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map = </*Status*/ 0x0 &UIC2 0x10 0x4
- /*Wake*/ 0x1 &UIC2 0x14 0x4>;
- reg = <0xef600c00 0x000000c4>;
- local-mac-address = [000000000000]; /* Filled in by U-Boot */
- mal-device = <&MAL0>;
- mal-tx-channel = <0>;
- mal-rx-channel = <0>;
- cell-index = <0>;
- max-frame-size = <9000>;
- rx-fifo-size = <16384>;
- tx-fifo-size = <2048>;
- phy-mode = "rgmii";
- phy-map = <0x00000000>;
- rgmii-device = <&RGMII0>;
- rgmii-channel = <0>;
- tah-device = <&TAH0>;
- tah-channel = <0>;
- has-inverted-stacr-oc;
- has-new-stacr-staopc;
+ partition@cb00000 {
+ label = "vendor";
+ reg = <0x0CB00000 0x3500000>;
};
};
+ };
+};
- PCIE0: pciex@d00000000 {
- device_type = "pci";
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- compatible = "ibm,plb-pciex-apm821xx", "ibm,plb-pciex";
- primary;
- port = <0x0>; /* port number */
- reg = <0x0000000d 0x00000000 0x20000000 /* Config space access */
- 0x0000000c 0x08010000 0x00001000>; /* Registers */
- dcr-reg = <0x100 0x020>;
- sdr-base = <0x300>;
+&UART0 {
+ status = "okay";
+};
- /* Outbound ranges, one memory and one IO,
- * later cannot be changed
- */
- ranges = <0x02000000 0x00000000 0x80000000 0x0000000e 0x00000000 0x00000000 0x80000000
- 0x02000000 0x00000000 0x00000000 0x0000000f 0x00000000 0x00000000 0x00100000
- 0x01000000 0x00000000 0x00000000 0x0000000f 0x80000000 0x00000000 0x00010000>;
+&UART1 {
+ status = "okay";
+};
- /* Inbound 2GB range starting at 0 */
- dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
+&IIC0 {
+ status = "okay";
+ rtc@68 {
+ compatible = "st,m41t80";
+ reg = <0x68>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x9 0x8>;
+ };
+ sttm@4C {
+ compatible = "adm,adm1032";
+ reg = <0x4C>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <0x1E 0x8>; /* CPU_THERNAL_L */
+ };
+};
- /* This drives busses 40 to 0x7f */
- bus-range = <0x40 0x7f>;
+&IIC1 {
+ status = "okay";
+};
- /* Legacy interrupts (note the weird polarity, the bridge seems
- * to invert PCIe legacy interrupts).
- * We are de-swizzling here because the numbers are actually for
- * port of the root complex virtual P2P bridge. But I want
- * to avoid putting a node for it in the tree, so the numbers
- * below are basically de-swizzled numbers.
- * The real slot is on idsel 0, so the swizzling is 1:1
- */
- interrupt-map-mask = <0x0 0x0 0x0 0x7>;
- interrupt-map = <
- 0x0 0x0 0x0 0x1 &UIC3 0xc 0x4 /* swizzled int A */
- 0x0 0x0 0x0 0x2 &UIC3 0xd 0x4 /* swizzled int B */
- 0x0 0x0 0x0 0x3 &UIC3 0xe 0x4 /* swizzled int C */
- 0x0 0x0 0x0 0x4 &UIC3 0xf 0x4 /* swizzled int D */>;
- };
+&RGMII0 {
+ status = "okay";
+};
- MSI: ppc4xx-msi@C10000000 {
- compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
- reg = < 0xC 0x10000000 0x100
- 0xC 0x10000000 0x100>;
- sdr-base = <0x36C>;
- msi-data = <0x00004440>;
- msi-mask = <0x0000ffe0>;
- interrupts =<0 1 2 3 4 5 6 7>;
- interrupt-parent = <&MSI>;
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- msi-available-ranges = <0x0 0x100>;
- interrupt-map = <
- 0 &UIC3 0x18 1
- 1 &UIC3 0x19 1
- 2 &UIC3 0x1A 1
- 3 &UIC3 0x1B 1
- 4 &UIC3 0x1C 1
- 5 &UIC3 0x1D 1
- 6 &UIC3 0x1E 1
- 7 &UIC3 0x1F 1
- >;
- };
- };
+&TAH0 {
+ status = "okay";
+};
+
+&MAL0 {
+ status = "okay";
+};
+
+&EMAC0 {
+ status = "okay";
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ phy-mode = "rgmii";
+ phy-map = <0x00000000>;
+};
+
+&PCIE0 {
+ status = "okay";
+};
+
+&MSI {
+ status = "okay";
};
--
2.28.0
^ permalink raw reply related
* [RFC PATCH v1 2/4] powerpc: apm82181: add WD MyBook Live NAS
From: Christian Lamparter @ 2020-08-12 22:41 UTC (permalink / raw)
To: linuxppc-dev, devicetree; +Cc: Paul Mackerras, Rob Herring, Chris Blake
In-Reply-To: <15a94dddc15d29bac02439beb77fd066771c747a.1597271958.git.chunkeey@gmail.com>
This patch adds the device-tree definitions for
Western Digital MyBook Live NAS devices.
Technically, this devicetree file is shared by two, very
similar devices.
There's the My Book Live and the My Book Live Duo. WD's uboot
on the device will enable/disable the nodes for the device.
Ready to go images and install instruction can be found @OpenWrt.org
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
arch/powerpc/boot/dts/wd-mybooklive.dts | 199 +++++++++++++++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 3 +-
2 files changed, 201 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/boot/dts/wd-mybooklive.dts
diff --git a/arch/powerpc/boot/dts/wd-mybooklive.dts b/arch/powerpc/boot/dts/wd-mybooklive.dts
new file mode 100644
index 000000000000..0871cc17bc9d
--- /dev/null
+++ b/arch/powerpc/boot/dts/wd-mybooklive.dts
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ * (c) Copyright 2010 Western Digital Technologies, Inc. All Rights Reserved.
+ */
+
+/dts-v1/;
+
+#include "apm82181.dtsi"
+
+/ {
+ compatible = "wd,mybooklive";
+ model = "MyBook Live";
+
+ aliases {
+ serial0 = &UART0;
+ };
+};
+
+&POB0 {
+ ebc {
+ nor_flash@0,0 {
+ status = "okay";
+ compatible = "amd,s29gl512n", "jedec-probe", "cfi-flash", "mtd-rom";
+ bank-width = <1>;
+ reg = <0x00000000 0x00000000 0x00080000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ /* Part of bootrom - Don't use it without a jump */
+ label = "free";
+ reg = <0x00000000 0x0001e000>;
+ };
+
+ partition@1e000 {
+ label = "env";
+ reg = <0x0001e000 0x00002000>;
+ };
+
+ partition@20000 {
+ label = "uboot";
+ reg = <0x00020000 0x00050000>;
+ };
+ };
+ };
+
+ GPIO1: gpio@e0000000 {
+ compatible = "wd,mbl-gpio";
+ reg-names = "dat";
+ reg = <0xe0000000 0x1>;
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ enable-button {
+ /* Defined in u-boot as: NOT_NOR
+ * "enables features other than NOR
+ * specifically, the buffer at CS2"
+ * (button).
+ *
+ * Note: This option is disabled as
+ * it prevents the system from being
+ * rebooted successfully.
+ */
+
+ gpio-hog;
+ line-name = "Enable Reset Button, disable NOR";
+ gpios = <1 GPIO_ACTIVE_HIGH>;
+ output-low;
+ };
+ };
+
+ GPIO2: gpio@e0100000 {
+ compatible = "wd,mbl-gpio";
+ reg-names = "dat";
+ reg = <0xe0100000 0x1>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ no-output;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ failsafe: power-red {
+ label = "mbl:red:power";
+ gpios = <&GPIO1 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "panic";
+ };
+
+ status: power-green {
+ label = "mbl:green:power";
+ gpios = <&GPIO1 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ power-blue {
+ label = "mbl:blue:power";
+ gpios = <&GPIO1 6 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "disk-activity";
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <60>; /* 3 * 20 = 60ms */
+ autorepeat;
+
+ reset-button {
+ label = "Reset button";
+ linux,code = <KEY_RESTART>;
+ gpios = <&GPIO2 2 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ usbpwr: usb-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "Power USB Core";
+ gpios = <&GPIO1 2 GPIO_ACTIVE_LOW>;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ sata1pwr: sata1-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "Power Drive Port 1";
+ gpios = <&GPIO1 3 GPIO_ACTIVE_LOW>;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on; /* needed to read OS from HDD */
+ };
+
+ sata0pwr: sata0-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "Power Drive Port 0";
+ gpios = <&GPIO1 7 GPIO_ACTIVE_LOW>;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on; /* needed to read OS from HDD */
+ };
+};
+
+&EMAC0 {
+ status = "okay";
+
+ phy-map = <0x2>;
+ phy-address = <0x1>;
+ phy-handle = <&phy>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset-gpios = <&GPIO1 0 GPIO_ACTIVE_LOW>;
+
+ phy: phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+};
+
+&CRYPTO {
+ status = "okay";
+};
+
+&PKA {
+ status = "okay";
+};
+
+&TRNG {
+ status = "okay";
+};
+
+&SATA0 {
+ status = "okay";
+
+ drive0: sata-port@0 {
+ reg = <0>;
+ #thermal-sensor-cells = <0>;
+ };
+};
+
+&SATA1 {
+ status = "okay";
+
+ drive1: sata-port@0 {
+ reg = <0>;
+ #thermal-sensor-cells = <0>;
+ };
+};
+
+&UART0 {
+ status = "okay";
+};
+
+&USBOTG0 {
+ status = "okay";
+ dr_mode = "host";
+ vbus-supply = <&usbpwr>;
+};
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 3dbd8ddd734a..1122702c804a 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -59,7 +59,8 @@ static char *board[] __initdata = {
"amcc,sequoia",
"amcc,taishan",
"amcc,yosemite",
- "mosaixtech,icon"
+ "mosaixtech,icon",
+ "wd,mybooklive",
};
static int __init ppc44x_probe(void)
--
2.28.0
^ permalink raw reply related
* Re: [PATCH v3 2/2] powerpc/uaccess: Add pre-update addressing to __get_user_asm() and __put_user_asm()
From: Segher Boessenkool @ 2020-08-12 19:37 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <13041c7df39e89ddf574ea0cdc6dedfdd9734140.1597235091.git.christophe.leroy@csgroup.eu>
On Wed, Aug 12, 2020 at 12:25:17PM +0000, Christophe Leroy wrote:
> Enable pre-update addressing mode in __get_user_asm() and __put_user_asm()
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> v3: new, splited out from patch 1.
It still looks fine to me, you can keep my Reviewed-by: :-)
Segher
^ permalink raw reply
* Re: [PATCH v2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()
From: Segher Boessenkool @ 2020-08-12 19:30 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <0b63e2b8-a134-9a50-2106-8ff110cf9a31@csgroup.eu>
On Wed, Aug 12, 2020 at 02:32:51PM +0200, Christophe Leroy wrote:
> Anyway, it seems that GCC doesn't make much use of the "m<>" and the
> pre-update form.
GCC does not use update form outside of inner loops much. Did you
expect anything else?
> Most of the benefit of flexible addressing seems to be
> achieved with patch 1 ie without the "m<>" constraint and update form.
Yes.
Segher
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
From: Tyrel Datwyler @ 2020-08-12 16:22 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: cheloha, ldufour
In-Reply-To: <20200812012005.1919255-1-nathanl@linux.ibm.com>
On 8/11/20 6:20 PM, Nathan Lynch wrote:
> The drmem lmb list can have hundreds of thousands of entries, and
> unfortunately lookups take the form of linear searches. As long as
> this is the case, traversals have the potential to monopolize the CPU
> and provoke lockup reports, workqueue stalls, and the like unless
> they explicitly yield.
>
> Rather than placing cond_resched() calls within various
> for_each_drmem_lmb() loop blocks in the code, put it in the iteration
> expression of the loop macro itself so users can't omit it.
>
> Call cond_resched() on every 20th element. Each iteration of the loop
> in DLPAR code paths can involve around ten RTAS calls which can each
> take up to 250us, so this ensures the check is performed at worst
> every few milliseconds.
>
> Fixes: 6c6ea53725b3 ("powerpc/mm: Separate ibm, dynamic-memory data from DT format")
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> ---
> arch/powerpc/include/asm/drmem.h | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> Changes since v1:
> * Add bounds assertions in drmem_lmb_next().
> * Call cond_resched() in the iterator on only every 20th element
> instead of on every iteration, to reduce overhead in tight loops.
>
> diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
> index 17ccc6474ab6..583277e30dd2 100644
> --- a/arch/powerpc/include/asm/drmem.h
> +++ b/arch/powerpc/include/asm/drmem.h
> @@ -8,6 +8,9 @@
> #ifndef _ASM_POWERPC_LMB_H
> #define _ASM_POWERPC_LMB_H
>
> +#include <linux/bug.h>
> +#include <linux/sched.h>
> +
> struct drmem_lmb {
> u64 base_addr;
> u32 drc_index;
> @@ -26,8 +29,21 @@ struct drmem_lmb_info {
>
> extern struct drmem_lmb_info *drmem_info;
>
> +static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb)
> +{
> + const unsigned int resched_interval = 20;
> +
> + BUG_ON(lmb < drmem_info->lmbs);
> + BUG_ON(lmb >= drmem_info->lmbs + drmem_info->n_lmbs);
I think BUG_ON is a pretty big no-no these days unless there is no other option.
-Tyrel
> +
> + if ((lmb - drmem_info->lmbs) % resched_interval == 0)
> + cond_resched();
> +
> + return ++lmb;
> +}
> +
> #define for_each_drmem_lmb_in_range(lmb, start, end) \
> - for ((lmb) = (start); (lmb) < (end); (lmb)++)
> + for ((lmb) = (start); (lmb) < (end); lmb = drmem_lmb_next(lmb))
>
> #define for_each_drmem_lmb(lmb) \
> for_each_drmem_lmb_in_range((lmb), \
>
^ permalink raw reply
* Re: [PATCH v3 8/8] mm/vmalloc: Hugepage vmalloc mappings
From: Jonathan Cameron @ 2020-08-12 16:18 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linux-arch, linuxppc-dev, Catalin Marinas, x86, linux-kernel,
linuxarm, linux-mm, Zefan Li, Borislav Petkov, H. Peter Anvin,
Thomas Gleixner, Will Deacon, Ingo Molnar, linux-arm-kernel
In-Reply-To: <20200812132524.000067a6@Huawei.com>
On Wed, 12 Aug 2020 13:25:24 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> On Mon, 10 Aug 2020 12:27:32 +1000
> Nicholas Piggin <npiggin@gmail.com> wrote:
>
> > On platforms that define HAVE_ARCH_HUGE_VMAP and support PMD vmaps,
> > vmalloc will attempt to allocate PMD-sized pages first, before falling
> > back to small pages.
> >
> > Allocations which use something other than PAGE_KERNEL protections are
> > not permitted to use huge pages yet, not all callers expect this (e.g.,
> > module allocations vs strict module rwx).
> >
> > This reduces TLB misses by nearly 30x on a `git diff` workload on a
> > 2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%.
> >
> > This can result in more internal fragmentation and memory overhead for a
> > given allocation, an option nohugevmap is added to disable at boot.
> >
> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Hi Nicholas,
>
> Busy afternoon, but a possible point of interest in line in the meantime.
>
I did manage to get back to this.
The issue I think is that ARM64 defines THREAD_ALIGN with CONFIG_VMAP_STACK
to be 2* THREAD SIZE. There is comment in arch/arm64/include/asm/memory.h
that this is to allow cheap checking of overflow.
A quick grep suggests ARM64 is the only architecture to do this...
Jonathan
>
> ...
>
> > @@ -2701,22 +2760,45 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
> > pgprot_t prot, unsigned long vm_flags, int node,
> > const void *caller)
> > {
> > - struct vm_struct *area;
> > + struct vm_struct *area = NULL;
> > void *addr;
> > unsigned long real_size = size;
> > + unsigned long real_align = align;
> > + unsigned int shift = PAGE_SHIFT;
> >
> > size = PAGE_ALIGN(size);
> > if (!size || (size >> PAGE_SHIFT) > totalram_pages())
> > goto fail;
> >
> > - area = __get_vm_area_node(real_size, align, VM_ALLOC | VM_UNINITIALIZED |
> > + if (vmap_allow_huge && (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))) {
> > + unsigned long size_per_node;
> > +
> > + /*
> > + * Try huge pages. Only try for PAGE_KERNEL allocations,
> > + * others like modules don't yet expect huge pages in
> > + * their allocations due to apply_to_page_range not
> > + * supporting them.
> > + */
> > +
> > + size_per_node = size;
> > + if (node == NUMA_NO_NODE)
> > + size_per_node /= num_online_nodes();
> > + if (size_per_node >= PMD_SIZE)
> > + shift = PMD_SHIFT;
> > + }
> > +
> > +again:
> > + align = max(real_align, 1UL << shift);
> > + size = ALIGN(real_size, align);
>
> So my suspicion is that the issue on arm64 is related to this.
> In the relevant call path, align is 32K whilst the size is 16K
>
> Previously I don't think we force size to be a multiple of align.
>
> I think this results in nr_pages being double what it was before.
>
>
> > +
> > + area = __get_vm_area_node(size, align, VM_ALLOC | VM_UNINITIALIZED |
> > vm_flags, start, end, node, gfp_mask, caller);
> > if (!area)
> > goto fail;
> >
> > - addr = __vmalloc_area_node(area, gfp_mask, prot, node);
> > + addr = __vmalloc_area_node(area, gfp_mask, prot, shift, node);
> > if (!addr)
> > - return NULL;
> > + goto fail;
> >
> > /*
> > * In this function, newly allocated vm_struct has VM_UNINITIALIZED
> > @@ -2730,8 +2812,16 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
> > return addr;
> >
> > fail:
> > - warn_alloc(gfp_mask, NULL,
> > + if (shift > PAGE_SHIFT) {
> > + shift = PAGE_SHIFT;
> > + goto again;
> > + }
> > +
> > + if (!area) {
> > + /* Warn for area allocation, page allocations already warn */
> > + warn_alloc(gfp_mask, NULL,
> > "vmalloc: allocation failure: %lu bytes", real_size);
> > + }
> > return NULL;
> > }
> >
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
From: Christophe Leroy @ 2020-08-12 14:26 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, cheloha, ldufour
In-Reply-To: <878sekyo2l.fsf@linux.ibm.com>
Le 12/08/2020 à 15:46, Nathan Lynch a écrit :
> Hi Christophe,
>
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> +static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb)
>>> +{
>>> + const unsigned int resched_interval = 20;
>>> +
>>> + BUG_ON(lmb < drmem_info->lmbs);
>>> + BUG_ON(lmb >= drmem_info->lmbs + drmem_info->n_lmbs);
>>
>> BUG_ON() shall be avoided unless absolutely necessary.
>> Wouldn't WARN_ON() together with an early return be enough ?
>
> Not sure what a sensible early return behavior would be. If the iterator
> doesn't advance the pointer the behavior will be a hang.
I was thinking about returning lmb++ without checking the cond_resched
stuff.
>
> BUG_ON a bounds-check failure is appropriate here; many users of this
> API will corrupt memory otherwise.
It looks really strange to me to do bounds-checks in an iterator like
this. Should be checked before entering the loop.
>
>>> +
>>> + if ((lmb - drmem_info->lmbs) % resched_interval == 0)
>>> + cond_resched();
>>
>> Do you need something that precise ? Can't you use 16 or 32 and use a
>> logical AND instead of a MODULO ?
>
> Eh if you're executing in this code you've already lost with respect to
> performance considerations at this level, see the discussion on v1. I'll
> use 16 since I'm going to reroll the patch though.
>
>> And what garanties that lmb is always an element of a table based at
>> drmem_info->lmbs ?
>
> Well, that's its only intended use right now. There should not be any
> other arrays of drmem_lmb objects, and I hope we don't gain any.
>
>
>> What about:
>>
>> static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb,
>> struct drmem_lmb *start)
>> {
>> const unsigned int resched_interval = 16;
>>
>> if ((++lmb - start) & resched_interval == 0)
> ^^^
> Did you mean '%' here? The bitwise AND doesn't do what I want.
I meant '& (resched_interval - 1)' indeed. But yes we can leave the %,
GCC will change a % 16 to an & 15.
>
> Otherwise, making drmem_lmb_next() more general by adding a 'start'
> argument could ease refactoring to come, so I'll do that.
Yes, the main idea is to avoid the access to a global variable in such
an helper.
>
Christophe
^ permalink raw reply
* Re: [PATCH 14/16] debug_vm_pgtable/hugetlb: Disable hugetlb test on ppc64
From: Aneesh Kumar K.V @ 2020-08-12 13:52 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm, akpm; +Cc: linuxppc-dev
In-Reply-To: <83766a01-6ffb-798c-c5b9-46b2d672f618@arm.com>
On 8/12/20 7:04 PM, Anshuman Khandual wrote:
>
>
> On 08/12/2020 06:46 PM, Aneesh Kumar K.V wrote:
>> On 8/12/20 6:33 PM, Anshuman Khandual wrote:
>>>
>>>
>>> On 08/12/2020 12:03 PM, Aneesh Kumar K.V wrote:
>>>> The seems to be missing quite a lot of details w.r.t allocating
>>>> the correct pgtable_t page (huge_pte_alloc()), holding the right
>>>> lock (huge_pte_lock()) etc. The vma used is also not a hugetlb VMA.
>>>>
>>>> ppc64 do have runtime checks within CONFIG_DEBUG_VM for most of these.
>>>> Hence disable the test on ppc64.
>>>
>>> This test is free from any platform specific #ifdefs which should
>>> never be broken. If hugetlb_advanced_tests() does not work or is
>>> not detailed enough for ppc64, then it would be great if you could
>>> suggest some improvements so that it works for all enabled platforms.
>>>
>>>
>>
>> As mentioned the test is broken. For hugetlb, the pgtable_t pages should be allocated by huge_pte_alloc(). We need to hold huget_pte_lock() before updating huge tlb pte. That takes hugepage size, which is mostly derived out of vma. Hence vma need to be a hugetlb vma. Some of the functions also depend on hstate. Also we should use set_huge_pte_at() when setting up hugetlb pte entries. I was tempted to remove that test completely marking it broken. But avoided that by marking it broken on only PPC64.
>
> The test is not broken, hugetlb helpers on multiple platforms dont complain about
> this at all. The tests here emulate 'enough' MM objects required for the helpers
> on enabled platforms, to perform the primary task i.e page table transformation it
> is expected to do. The test does not claim to emulate a perfect MM environment for
> a given subsystem's (like HugeTLB) arch helpers. Now in this case, the MM objects
> being emulated for the HugeTLB advanced tests does not seem to be sufficient for
> ppc64 but it can be improved. But that does not mean it is broken in it's current
> form for other platforms.
>
There is nothing ppc64 specific here. It is just that we have
CONFIG_DEBUG_VM based checks for different possibly wrong usages of
these functions. This was done because we have different page sizes, two
different translations to support and we want to avoid any wrong usage.
IMHO expecting hugetlb page table helpers to work with a non hugetlb VMA
and without holding hugeTLB pte lock is a clear violation of hugetlb
interface.
-aneesh
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
From: Nathan Lynch @ 2020-08-12 13:46 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev; +Cc: tyreld, cheloha, ldufour
In-Reply-To: <c39976ce-a95c-a9cb-d119-d272b8de2f28@csgroup.eu>
Hi Christophe,
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> +static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb)
>> +{
>> + const unsigned int resched_interval = 20;
>> +
>> + BUG_ON(lmb < drmem_info->lmbs);
>> + BUG_ON(lmb >= drmem_info->lmbs + drmem_info->n_lmbs);
>
> BUG_ON() shall be avoided unless absolutely necessary.
> Wouldn't WARN_ON() together with an early return be enough ?
Not sure what a sensible early return behavior would be. If the iterator
doesn't advance the pointer the behavior will be a hang.
BUG_ON a bounds-check failure is appropriate here; many users of this
API will corrupt memory otherwise.
>> +
>> + if ((lmb - drmem_info->lmbs) % resched_interval == 0)
>> + cond_resched();
>
> Do you need something that precise ? Can't you use 16 or 32 and use a
> logical AND instead of a MODULO ?
Eh if you're executing in this code you've already lost with respect to
performance considerations at this level, see the discussion on v1. I'll
use 16 since I'm going to reroll the patch though.
> And what garanties that lmb is always an element of a table based at
> drmem_info->lmbs ?
Well, that's its only intended use right now. There should not be any
other arrays of drmem_lmb objects, and I hope we don't gain any.
> What about:
>
> static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb,
> struct drmem_lmb *start)
> {
> const unsigned int resched_interval = 16;
>
> if ((++lmb - start) & resched_interval == 0)
^^^
Did you mean '%' here? The bitwise AND doesn't do what I want.
Otherwise, making drmem_lmb_next() more general by adding a 'start'
argument could ease refactoring to come, so I'll do that.
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries/hotplug-cpu: wait indefinitely for vCPU death
From: Greg Kurz @ 2020-08-12 13:36 UTC (permalink / raw)
To: Michael Roth
Cc: Nathan Lynch, linuxppc-dev, Cedric Le Goater,
Thiago Jung Bauermann
In-Reply-To: <20200811161544.10513-1-mdroth@linux.vnet.ibm.com>
On Tue, 11 Aug 2020 11:15:44 -0500
Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> For a power9 KVM guest with XIVE enabled, running a test loop
> where we hotplug 384 vcpus and then unplug them, the following traces
> can be seen (generally within a few loops) either from the unplugged
> vcpu:
>
> [ 1767.353447] cpu 65 (hwid 65) Ready to die...
> [ 1767.952096] Querying DEAD? cpu 66 (66) shows 2
> [ 1767.952311] list_del corruption. next->prev should be c00a000002470208, but was c00a000002470048
> [ 1767.952322] ------------[ cut here ]------------
> [ 1767.952323] kernel BUG at lib/list_debug.c:56!
> [ 1767.952325] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 1767.952326] LE SMP NR_CPUS=2048 NUMA pSeries
> [ 1767.952328] Modules linked in: fuse nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat_ipv6 nf_nat_ipv6 nft_chain_route_ipv6 nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_chain_route_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink uio_pdrv_genirq ip_tables xfs libcrc32c sd_mod sg xts vmx_crypto virtio_net net_failover failover virtio_scsi dm_multipath dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> [ 1767.952352] CPU: 66 PID: 0 Comm: swapper/66 Kdump: loaded Not tainted 4.18.0-221.el8.ppc64le #1
> [ 1767.952354] NIP: c0000000007ab50c LR: c0000000007ab508 CTR: 00000000000003ac
> [ 1767.952355] REGS: c0000009e5a17840 TRAP: 0700 Not tainted (4.18.0-221.el8.ppc64le)
> [ 1767.952355] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28000842 XER: 20040000
> [ 1767.952360] CFAR: c0000000001ffe64 IRQMASK: 1
> [ 1767.952360] GPR00: c0000000007ab508 c0000009e5a17ac0 c000000001ac0700 0000000000000054
> [ 1767.952360] GPR04: c0000009f056cf90 c0000009f05f5628 c0000009ed40d654 c000000001c90700
> [ 1767.952360] GPR08: 0000000000000007 c0000009f0573980 00000009ef2b0000 7562202c38303230
> [ 1767.952360] GPR12: 0000000000000000 c0000007fff6ce80 c00a000002470208 0000000000000000
> [ 1767.952360] GPR16: 0000000000000001 c0000009f05fbb00 0000000000000800 c0000009ff3d4980
> [ 1767.952360] GPR20: c0000009f05fbb10 5deadbeef0000100 5deadbeef0000200 0000000000187961
> [ 1767.952360] GPR24: c0000009e5a17b78 0000000000000000 0000000000000001 ffffffffffffffff
> [ 1767.952360] GPR28: c00a000002470200 c0000009f05fbb10 c0000009f05fbb10 0000000000000000
> [ 1767.952375] NIP [c0000000007ab50c] __list_del_entry_valid+0xac/0x100
> [ 1767.952376] LR [c0000000007ab508] __list_del_entry_valid+0xa8/0x100
> [ 1767.952377] Call Trace:
> [ 1767.952378] [c0000009e5a17ac0] [c0000000007ab508] __list_del_entry_valid+0xa8/0x100 (unreliable)
> [ 1767.952381] [c0000009e5a17b20] [c000000000476e18] free_pcppages_bulk+0x1f8/0x940
> [ 1767.952383] [c0000009e5a17c20] [c00000000047a9a0] free_unref_page+0xd0/0x100
> [ 1767.952386] [c0000009e5a17c50] [c0000000000bc2a8] xive_spapr_cleanup_queue+0x148/0x1b0
> [ 1767.952388] [c0000009e5a17cf0] [c0000000000b96dc] xive_teardown_cpu+0x1bc/0x240
> [ 1767.952391] [c0000009e5a17d30] [c00000000010bf28] pseries_mach_cpu_die+0x78/0x2f0
> [ 1767.952393] [c0000009e5a17de0] [c00000000005c8d8] cpu_die+0x48/0x70
> [ 1767.952394] [c0000009e5a17e00] [c000000000021cf0] arch_cpu_idle_dead+0x20/0x40
> [ 1767.952397] [c0000009e5a17e20] [c0000000001b4294] do_idle+0x2f4/0x4c0
> [ 1767.952399] [c0000009e5a17ea0] [c0000000001b46a8] cpu_startup_entry+0x38/0x40
> [ 1767.952400] [c0000009e5a17ed0] [c00000000005c43c] start_secondary+0x7bc/0x8f0
> [ 1767.952403] [c0000009e5a17f90] [c00000000000ac70] start_secondary_prolog+0x10/0x14
>
> or on the worker thread handling the unplug:
>
> [ 1538.253044] pseries-hotplug-cpu: Attempting to remove CPU <NULL>, drc index: 1000013a
> [ 1538.360259] Querying DEAD? cpu 314 (314) shows 2
> [ 1538.360736] BUG: Bad page state in process kworker/u768:3 pfn:95de1
> [ 1538.360746] cpu 314 (hwid 314) Ready to die...
> [ 1538.360784] page:c00a000002577840 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0
> [ 1538.361881] flags: 0x5ffffc00000000()
> [ 1538.361908] raw: 005ffffc00000000 5deadbeef0000100 5deadbeef0000200 0000000000000000
> [ 1538.361955] raw: 0000000000000000 0000000000000000 00000000ffffff7f 0000000000000000
> [ 1538.362002] page dumped because: nonzero mapcount
> [ 1538.362033] Modules linked in: kvm xt_CHECKSUM ipt_MASQUERADE xt_conntrack ipt_REJECT nft_counter nf_nat_tftp nft_objref nf_conntrack_tftp tun bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink sunrpc xts vmx_crypto ip_tables xfs libcrc32c sd_mod sg virtio_net net_failover virtio_scsi failover dm_mirror dm_region_hash dm_log dm_mod
> [ 1538.362613] CPU: 0 PID: 548 Comm: kworker/u768:3 Kdump: loaded Not tainted 4.18.0-224.el8.bz1856588.ppc64le #1
> [ 1538.362687] Workqueue: pseries hotplug workque pseries_hp_work_fn
> [ 1538.362725] Call Trace:
> [ 1538.362743] [c0000009d4adf590] [c000000000e0e0fc] dump_stack+0xb0/0xf4 (unreliable)
> [ 1538.362789] [c0000009d4adf5d0] [c000000000475dfc] bad_page+0x12c/0x1b0
> [ 1538.362827] [c0000009d4adf660] [c0000000004784bc] free_pcppages_bulk+0x5bc/0x940
> [ 1538.362871] [c0000009d4adf760] [c000000000478c38] page_alloc_cpu_dead+0x118/0x120
> [ 1538.362918] [c0000009d4adf7b0] [c00000000015b898] cpuhp_invoke_callback.constprop.5+0xb8/0x760
> [ 1538.362969] [c0000009d4adf820] [c00000000015eee8] _cpu_down+0x188/0x340
> [ 1538.363007] [c0000009d4adf890] [c00000000015d75c] cpu_down+0x5c/0xa0
> [ 1538.363045] [c0000009d4adf8c0] [c00000000092c544] cpu_subsys_offline+0x24/0x40
> [ 1538.363091] [c0000009d4adf8e0] [c0000000009212f0] device_offline+0xf0/0x130
> [ 1538.363129] [c0000009d4adf920] [c00000000010aee4] dlpar_offline_cpu+0x1c4/0x2a0
> [ 1538.363174] [c0000009d4adf9e0] [c00000000010b2f8] dlpar_cpu_remove+0xb8/0x190
> [ 1538.363219] [c0000009d4adfa60] [c00000000010b4fc] dlpar_cpu_remove_by_index+0x12c/0x150
> [ 1538.363264] [c0000009d4adfaf0] [c00000000010ca24] dlpar_cpu+0x94/0x800
> [ 1538.363302] [c0000009d4adfc00] [c000000000102cc8] pseries_hp_work_fn+0x128/0x1e0
> [ 1538.363347] [c0000009d4adfc70] [c00000000018aa84] process_one_work+0x304/0x5d0
> [ 1538.363394] [c0000009d4adfd10] [c00000000018b5cc] worker_thread+0xcc/0x7a0
> [ 1538.363433] [c0000009d4adfdc0] [c00000000019567c] kthread+0x1ac/0x1c0
> [ 1538.363469] [c0000009d4adfe30] [c00000000000b7dc] ret_from_kernel_thread+0x5c/0x80
>
> The latter trace is due to the following sequence:
>
> page_alloc_cpu_dead
> drain_pages
> drain_pages_zone
> free_pcppages_bulk
>
> where drain_pages() in this case is called under the assumption that
> the unplugged cpu is no longer executing. To ensure that is the case,
> and early call is made to __cpu_die()->pseries_cpu_die(), which runs
> a loop that waits for the cpu to reach a halted state by polling its
> status via query-cpu-stopped-state RTAS calls. It only polls for
> 25 iterations before giving up, however, and in the trace above this
> results in the following being printed only .1 seconds after the
> hotplug worker thread begins processing the unplug request:
>
> [ 1538.253044] pseries-hotplug-cpu: Attempting to remove CPU <NULL>, drc index: 1000013a
> [ 1538.360259] Querying DEAD? cpu 314 (314) shows 2
>
> At that point the worker thread assumes the unplugged CPU is in some
> unknown/dead state and procedes with the cleanup, causing the race with
> the XIVE cleanup code executed by the unplugged CPU.
>
> Fix this by waiting indefinitely, but also making an effort to avoid
> spurious lockup messages by allowing for rescheduling after polling
> the CPU status and printing a warning if we wait for longer than 120s.
>
> Fixes: eac1e731b59ee ("powerpc/xive: guest exploitation of the XIVE interrupt controller")
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1856588
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Cedric Le Goater <clg@kaod.org>
> Cc: Greg Kurz <groug@kaod.org>
> Cc: Nathan Lynch <nathanl@linux.ibm.com>
> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> ---
> changes from v1:
> - renamed from "powerpc/pseries/hotplug-cpu: increase wait time for vCPU death"
> - wait indefinitely, but issue cond_resched() when RTAS reports that CPU
> hasn't stopped (Michael)
> - print a warning after 120s of waiting (Michael)
> - use pr_warn() instead of default printk() level
> ---
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index c6e0d8abf75e..7a974ed6b240 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -107,22 +107,28 @@ static int pseries_cpu_disable(void)
> */
> static void pseries_cpu_die(unsigned int cpu)
> {
> - int tries;
> int cpu_status = 1;
> unsigned int pcpu = get_hard_smp_processor_id(cpu);
> + unsigned long timeout = jiffies + msecs_to_jiffies(120000);
>
> - for (tries = 0; tries < 25; tries++) {
> + while (true) {
> cpu_status = smp_query_cpu_stopped(pcpu);
> if (cpu_status == QCSS_STOPPED ||
> cpu_status == QCSS_HARDWARE_ERROR)
> break;
> - cpu_relax();
>
> + if (time_after(jiffies, timeout)) {
> + pr_warn("CPU %i (hwid %i) didn't die after 120 seconds\n",
> + cpu, pcpu);
> + timeout = jiffies + msecs_to_jiffies(120000);
> + }
> +
> + cond_resched();
> }
>
> - if (cpu_status != 0) {
> - printk("Querying DEAD? cpu %i (%i) shows %i\n",
> - cpu, pcpu, cpu_status);
> + if (cpu_status == QCSS_HARDWARE_ERROR) {
> + pr_warn("CPU %i (hwid %i) reported error while dying\n",
> + cpu, pcpu);
> }
>
> /* Isolation and deallocation are definitely done by
Reviewed-by: Greg Kurz <groug@kaod.org>
With my reproducer I used to hit the issues this patch is supposed to
fix after less than 30 minutes (KVM guest runnning upstream kernel on
a Witherspoon system running a recent RHEL8.3 rc). With this patch
applied I could run the reproducer for a couple of hours without seeing
anything wrong.
Thanks !
Tested-by: Greg Kurz <groug@kaod.org>
^ permalink raw reply
* Re: [PATCH 14/16] debug_vm_pgtable/hugetlb: Disable hugetlb test on ppc64
From: Anshuman Khandual @ 2020-08-12 13:34 UTC (permalink / raw)
To: Aneesh Kumar K.V, linux-mm, akpm; +Cc: linuxppc-dev
In-Reply-To: <efc8f8c8-c16d-0826-9401-a45005ecaf62@linux.ibm.com>
On 08/12/2020 06:46 PM, Aneesh Kumar K.V wrote:
> On 8/12/20 6:33 PM, Anshuman Khandual wrote:
>>
>>
>> On 08/12/2020 12:03 PM, Aneesh Kumar K.V wrote:
>>> The seems to be missing quite a lot of details w.r.t allocating
>>> the correct pgtable_t page (huge_pte_alloc()), holding the right
>>> lock (huge_pte_lock()) etc. The vma used is also not a hugetlb VMA.
>>>
>>> ppc64 do have runtime checks within CONFIG_DEBUG_VM for most of these.
>>> Hence disable the test on ppc64.
>>
>> This test is free from any platform specific #ifdefs which should
>> never be broken. If hugetlb_advanced_tests() does not work or is
>> not detailed enough for ppc64, then it would be great if you could
>> suggest some improvements so that it works for all enabled platforms.
>>
>>
>
> As mentioned the test is broken. For hugetlb, the pgtable_t pages should be allocated by huge_pte_alloc(). We need to hold huget_pte_lock() before updating huge tlb pte. That takes hugepage size, which is mostly derived out of vma. Hence vma need to be a hugetlb vma. Some of the functions also depend on hstate. Also we should use set_huge_pte_at() when setting up hugetlb pte entries. I was tempted to remove that test completely marking it broken. But avoided that by marking it broken on only PPC64.
The test is not broken, hugetlb helpers on multiple platforms dont complain about
this at all. The tests here emulate 'enough' MM objects required for the helpers
on enabled platforms, to perform the primary task i.e page table transformation it
is expected to do. The test does not claim to emulate a perfect MM environment for
a given subsystem's (like HugeTLB) arch helpers. Now in this case, the MM objects
being emulated for the HugeTLB advanced tests does not seem to be sufficient for
ppc64 but it can be improved. But that does not mean it is broken in it's current
form for other platforms.
>
>
>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>> ---
>>> mm/debug_vm_pgtable.c | 6 +++++-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
>>> index 529892b9be2f..3e112d0ba1b2 100644
>>> --- a/mm/debug_vm_pgtable.c
>>> +++ b/mm/debug_vm_pgtable.c
>>> @@ -800,6 +800,7 @@ static void __init hugetlb_basic_tests(unsigned long pfn, pgprot_t prot)
>>> #endif /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
>>> }
>>> +#ifndef CONFIG_PPC_BOOK3S_64
>>> static void __init hugetlb_advanced_tests(struct mm_struct *mm,
>>> struct vm_area_struct *vma,
>>> pte_t *ptep, unsigned long pfn,
>>> @@ -842,6 +843,7 @@ static void __init hugetlb_advanced_tests(struct mm_struct *mm,
>>> pte = huge_ptep_get(ptep);
>>> WARN_ON(!(huge_pte_write(pte) && huge_pte_dirty(pte)));
>>> }
>>> +#endif
>>> #else /* !CONFIG_HUGETLB_PAGE */
>>> static void __init hugetlb_basic_tests(unsigned long pfn, pgprot_t prot) { }
>>> static void __init hugetlb_advanced_tests(struct mm_struct *mm,
>>> @@ -1053,7 +1055,9 @@ static int __init debug_vm_pgtable(void)
>>> pud_populate_tests(mm, pudp, saved_pmdp);
>>> spin_unlock(ptl);
>>> - //hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
>>> +#ifndef CONFIG_PPC_BOOK3S_64
>>> + hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
>>> +#endif
>>> spin_lock(&mm->page_table_lock);
>>> p4d_clear_tests(mm, p4dp);
>>>
>
>
^ permalink raw reply
* Re: [PATCH 14/16] debug_vm_pgtable/hugetlb: Disable hugetlb test on ppc64
From: Aneesh Kumar K.V @ 2020-08-12 13:16 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm, akpm; +Cc: linuxppc-dev
In-Reply-To: <d067c278-6391-72f1-75c2-ccbd52909233@arm.com>
On 8/12/20 6:33 PM, Anshuman Khandual wrote:
>
>
> On 08/12/2020 12:03 PM, Aneesh Kumar K.V wrote:
>> The seems to be missing quite a lot of details w.r.t allocating
>> the correct pgtable_t page (huge_pte_alloc()), holding the right
>> lock (huge_pte_lock()) etc. The vma used is also not a hugetlb VMA.
>>
>> ppc64 do have runtime checks within CONFIG_DEBUG_VM for most of these.
>> Hence disable the test on ppc64.
>
> This test is free from any platform specific #ifdefs which should
> never be broken. If hugetlb_advanced_tests() does not work or is
> not detailed enough for ppc64, then it would be great if you could
> suggest some improvements so that it works for all enabled platforms.
>
>
As mentioned the test is broken. For hugetlb, the pgtable_t pages should
be allocated by huge_pte_alloc(). We need to hold huget_pte_lock()
before updating huge tlb pte. That takes hugepage size, which is mostly
derived out of vma. Hence vma need to be a hugetlb vma. Some of the
functions also depend on hstate. Also we should use set_huge_pte_at()
when setting up hugetlb pte entries. I was tempted to remove that test
completely marking it broken. But avoided that by marking it broken on
only PPC64.
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> mm/debug_vm_pgtable.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
>> index 529892b9be2f..3e112d0ba1b2 100644
>> --- a/mm/debug_vm_pgtable.c
>> +++ b/mm/debug_vm_pgtable.c
>> @@ -800,6 +800,7 @@ static void __init hugetlb_basic_tests(unsigned long pfn, pgprot_t prot)
>> #endif /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
>> }
>>
>> +#ifndef CONFIG_PPC_BOOK3S_64
>> static void __init hugetlb_advanced_tests(struct mm_struct *mm,
>> struct vm_area_struct *vma,
>> pte_t *ptep, unsigned long pfn,
>> @@ -842,6 +843,7 @@ static void __init hugetlb_advanced_tests(struct mm_struct *mm,
>> pte = huge_ptep_get(ptep);
>> WARN_ON(!(huge_pte_write(pte) && huge_pte_dirty(pte)));
>> }
>> +#endif
>> #else /* !CONFIG_HUGETLB_PAGE */
>> static void __init hugetlb_basic_tests(unsigned long pfn, pgprot_t prot) { }
>> static void __init hugetlb_advanced_tests(struct mm_struct *mm,
>> @@ -1053,7 +1055,9 @@ static int __init debug_vm_pgtable(void)
>> pud_populate_tests(mm, pudp, saved_pmdp);
>> spin_unlock(ptl);
>>
>> - //hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
>> +#ifndef CONFIG_PPC_BOOK3S_64
>> + hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
>> +#endif
>>
>> spin_lock(&mm->page_table_lock);
>> p4d_clear_tests(mm, p4dp);
>>
^ permalink raw reply
* [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
From: Christian Zigotzky @ 2020-08-12 13:09 UTC (permalink / raw)
To: daniel.vetter
Cc: Darren Stevens, mad skateman, Michel Dänzer,
Maling list - DRI developers, kvm-ppc@vger.kernel.org,
R.T.Dickinson, linuxppc-dev
In-Reply-To: <9805f81d-651d-d1a3-fd05-fb224a8c2031@xenosoft.de>
Hello Daniel,
The VirtIO-GPU doesn't work anymore with the latest Git kernel in a
virtual e5500 PPC64 QEMU machine [1,2] after the commit "drm/virtio:
Call the right shmem helpers". [3]
The kernel 5.8 works with the VirtIO-GPU in this virtual machine.
I bisected today [4].
Result: drm/virtio: Call the right shmem helpers (
d323bb44e4d23802eb25d13de1f93f2335bd60d0) [3] is the first bad commit.
I was able to revert the first bad commit. [5] After that I compiled a
new kernel again. Then I was able to boot Linux with this kernel in a
virtual e5500 PPC64 QEMU machine with the VirtIO-GPU.
I created a patch. [6] With this patch I can use the VirtIO-GPU again.
Could you please check the first bad commit?
Thanks,
Christian
[1] QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m
1024 -kernel uImage -drive
format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic
user,model=e1000 -append "rw root=/dev/vda2" -device virtio-vga -device
virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb
-device usb-audio,bus=newusb.0 -smp 4
[2] Error messages:
virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0
(slots), used 0 (slots)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc0000000000c7324
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 2 PID: 1678 Comm: kworker/2:2 Not tainted
5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty #1
Workqueue: events .virtio_gpu_dequeue_ctrl_func
NIP: c0000000000c7324 LR: c0000000000c72e4 CTR: c000000000462930
REGS: c00000003dba75e0 TRAP: 0300 Not tainted
(5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty)
MSR: 0000000090029000 <CE,EE,ME> CR: 24002288 XER: 00000000
DEAR: 0000000000000010 ESR: 0000000000000000 IRQMASK: 0
GPR00: c0000000000c6188 c00000003dba7870 c0000000017f2300 c00000003d893010
GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000000
GPR08: 0000000000000000 0000000000000000 0000000000000000 7f7f7f7f7f7f7f7f
GPR12: 0000000024002284 c00000003fff9200 c00000000008c3a0 c0000000061566c0
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000001 0000000000110000 0000000000000000 0000000000000000
GPR28: c00000003d893010 0000000000000000 0000000000000000 c00000003d893010
NIP [c0000000000c7324] .dma_direct_unmap_sg+0x4c/0xd8
LR [c0000000000c72e4] .dma_direct_unmap_sg+0xc/0xd8
Call Trace:
[c00000003dba7870] [c00000003dba7950] 0xc00000003dba7950 (unreliable)
[c00000003dba7920] [c0000000000c6188] .dma_unmap_sg_attrs+0x5c/0x98
[c00000003dba79d0] [c0000000005cd438] .drm_gem_shmem_free_object+0x98/0xcc
[c00000003dba7a50] [c0000000006af5b4] .virtio_gpu_cleanup_object+0xc8/0xd4
[c00000003dba7ad0] [c0000000006ad3bc] .virtio_gpu_cmd_unref_cb+0x1c/0x30
[c00000003dba7b40] [c0000000006adab8]
.virtio_gpu_dequeue_ctrl_func+0x208/0x28c
[c00000003dba7c10] [c000000000086b70] .process_one_work+0x1a4/0x258
[c00000003dba7cb0] [c0000000000870f4] .worker_thread+0x214/0x284
[c00000003dba7d70] [c00000000008c4f0] .kthread+0x150/0x158
[c00000003dba7e20] [c00000000000082c] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
f821ff51 7cb82b78 7cdb3378 4e000000 7cfa3b78 3bc00000 7f9ec000 41fc0014
382100b0 81810008 7d808120 48bc1ba8 <e93d0010> ebfc0248 833d0018 7fff4850
---[ end trace f28d194d9f0955a8 ]---
virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0
(slots), used 0 (slots)
virtio_gpu virtio0: swiotlb buffer is full (sz: 16384 bytes), total 0
(slots), used 0 (slots)
---
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d323bb44e4d23802eb25d13de1f93f2335bd60d0
[4] https://forum.hyperion-entertainment.com/viewtopic.php?p=51377#p51377
[5] git revert d323bb44e4d23802eb25d13de1f93f2335bd60d0 //Output:
[master 966950f724e4] Revert "drm/virtio: Call the right shmem helpers"
1 file changed, 1 insertion(+), 1 deletion(-)
[6]
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 6ccbd01cd888..346cef5ce251 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -150,7 +150,7 @@ static int virtio_gpu_object_shmem_init(struct
virtio_gpu_device *vgdev,
if (ret < 0)
return -EINVAL;
- shmem->pages = drm_gem_shmem_get_pages_sgt(&bo->base.base);
+ shmem->pages = drm_gem_shmem_get_sg_table(&bo->base.base);
if (!shmem->pages) {
drm_gem_shmem_unpin(&bo->base.base);
return -EINVAL;
---
^ 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