[PATCH v2] x86/paravirt: Disable virt spinlock on bare metal
The kernel can change spinlock behavior when running as a guest. But
this guest-friendly behavior causes performance problems on bare metal.
So there's a 'virt_spin_lock_key' static key to switch between the two
modes.
The static key is always enabled by default (run in guest mode) and
should be disabled for bare metal (and in some guests that want native
behavior).
Performance drop is reported when running encode/decode workload and
BenchSEE cache sub-workload.
Bisect points to commit ce0a1b608bfc ("x86/paravirt: Silence unused
native_pv_lock_init() function warning"). When CONFIG_PARAVIRT_SPINLOCKS
is disabled the virt_spin_lock_key is incorrectly set to true on bare
metal. The qspinlock degenerates to test-and-set spinlock, which
decrease the performance on bare metal.
Fix this by disabling virt_spin_lock_key if it is on bare metal,
regardless of CONFIG_PARAVIRT_SPINLOCKS.
Fixes: ce0a1b608bfc ("x86/paravirt: Silence unused native_pv_lock_init()
function warning")
Suggested-by: Dave Hansen
Suggested-by: Qiuxu Zhuo
Reported-by: Prem Nath Dey
Reported-by: Xiaoping Zhou
Reviewed-by: Juergen Gross
Signed-off-by: Chen Yu
---
v1->v2:
Refine the commit log per Dave's suggestion.
Simplify the fix by directly disabling the virt_spin_lock_key on bare metal.
Collect Reviewed-by from Juergen.
---
arch/x86/kernel/paravirt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 5358d43886ad..c193c9e60a1b 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -55,8 +55,7 @@ DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key);
void __init native_pv_lock_init(void)
{
- if (IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS) &&
- !boot_cpu_has(X86_FEATURE_HYPERVISOR))
+ if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
static_branch_disable(_spin_lock_key);
}
--
2.25.1
Re: [PATCH] x86/paravirt: Disable virt spinlock when CONFIG_PARAVIRT_SPINLOCKS disabled
On 2024-05-23 at 09:30:59 -0700, Dave Hansen wrote:
> On 5/16/24 06:02, Chen Yu wrote:
> > Performance drop is reported when running encode/decode workload and
> > BenchSEE cache sub-workload.
> > Bisect points to commit ce0a1b608bfc ("x86/paravirt: Silence unused
> > native_pv_lock_init() function warning"). When CONFIG_PARAVIRT_SPINLOCKS
> > is disabled the virt_spin_lock_key is set to true on bare-metal.
> > The qspinlock degenerates to test-and-set spinlock, which decrease the
> > performance on bare-metal.
> >
> > Fix this by disabling virt_spin_lock_key if CONFIG_PARAVIRT_SPINLOCKS
> > is not set, or it is on bare-metal.
>
> This is missing some background:
>
> The kernel can change spinlock behavior when running as a guest. But
> this guest-friendly behavior causes performance problems on bare metal.
> So there's a 'virt_spin_lock_key' static key to switch between the two
> modes.
>
> The static key is always enabled by default (run in guest mode) and
> should be disabled for bare metal (and in some guests that want native
> behavior).
>
> ... then describe the regression and the fix
>
Thanks Juergen for your review.
And thanks Dave for the write up, I'll refine the log according to your
suggestion.
> > diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> > index 5358d43886ad..ee51c0949ed8 100644
> > --- a/arch/x86/kernel/paravirt.c
> > +++ b/arch/x86/kernel/paravirt.c
> > @@ -55,7 +55,7 @@ DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key);
> >
> > void __init native_pv_lock_init(void)
> > {
> > - if (IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS) &&
> > + if (!IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS) ||
> > !boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > static_branch_disable(_spin_lock_key);
> > }
> This gets used at a single site:
>
> if (pv_enabled())
> goto pv_queue;
>
> if (virt_spin_lock(lock))
> return;
>
> which is logically:
>
> if (IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS))
> goto ...; // don't look at virt_spin_lock_key
>
> if (virt_spin_lock_key)
> return; // On virt, but non-paravirt. Did Test-and-Set
> // spinlock.
>
Thanks for the description in detail, my original change might break the
"X86_FEATURE_HYPERVISOR + NO_CONFIG_PARAVIRT_SPINLOCKS " case that, the guest
can not fall into test-and-set.
> So I _think_ Arnd was trying to optimize native_pv_lock_init() away when
> it's going to get skipped over anyway by the 'goto'.
>
> But this took me at least 30 minutes of scratching my head and trying to
> untangle the whole thing. It's all far too subtle for my taste, and all
> of that to save a few bytes of init text in a configuration that's
> probably not even used very often (PARAVIRT=y, but PARAVIRT_SPINLOCKS=n).
>
> Let's just keep it simple. How about the attached patch?
Yes, this one works, I'll refine it.
thanks,
Chenyu
[PATCH] x86/paravirt: Disable virt spinlock when CONFIG_PARAVIRT_SPINLOCKS disabled
Performance drop is reported when running encode/decode workload and
BenchSEE cache sub-workload.
Bisect points to commit ce0a1b608bfc ("x86/paravirt: Silence unused
native_pv_lock_init() function warning"). When CONFIG_PARAVIRT_SPINLOCKS
is disabled the virt_spin_lock_key is set to true on bare-metal.
The qspinlock degenerates to test-and-set spinlock, which decrease the
performance on bare-metal.
Fix this by disabling virt_spin_lock_key if CONFIG_PARAVIRT_SPINLOCKS
is not set, or it is on bare-metal.
Fixes: ce0a1b608bfc ("x86/paravirt: Silence unused native_pv_lock_init()
function warning")
Suggested-by: Qiuxu Zhuo
Reported-by: Prem Nath Dey
Reported-by: Xiaoping Zhou
Signed-off-by: Chen Yu
---
arch/x86/kernel/paravirt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 5358d43886ad..ee51c0949ed8 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -55,7 +55,7 @@ DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key);
void __init native_pv_lock_init(void)
{
- if (IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS) &&
+ if (!IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS) ||
!boot_cpu_has(X86_FEATURE_HYPERVISOR))
static_branch_disable(_spin_lock_key);
}
--
2.25.1
Re: [PATCH 1/3] init: Declare rodata_enabled and mark_rodata_ro() at all time
Hi, On Mon, Jan 29, 2024 at 12:09:50PM -0800, Luis Chamberlain wrote: > On Thu, Dec 21, 2023 at 10:02:46AM +0100, Christophe Leroy wrote: > > Declaring rodata_enabled and mark_rodata_ro() at all time > > helps removing related #ifdefery in C files. > > > > Signed-off-by: Christophe Leroy > > Very nice cleanup, thanks!, applied and pushed > > Luis On next-20240130, which has your modules-next branch, and thus this series and the other "module: Use set_memory_rox()" series applied, my kernel crashes in some very weird way. Reverting your branch makes the crash go away. I thought I'd report it right away. Maybe you folks would know what's happening here? This is on arm64. [ 10.481015] Unable to handle kernel paging request at virtual address ffde85245d30 [ 10.490369] KASAN: maybe wild-memory-access in range [0x00f42922e980-0x00f42922e987] [ 10.503744] Mem abort info: [ 10.509383] ESR = 0x9647 [ 10.514400] EC = 0x25: DABT (current EL), IL = 32 bits [ 10.522366] SET = 0, FnV = 0 [ 10.526343] EA = 0, S1PTW = 0 [ 10.530695] FSC = 0x07: level 3 translation fault [ 10.537081] Data abort info: [ 10.540839] ISV = 0, ISS = 0x0047, ISS2 = 0x [ 10.546456] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 10.551726] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 10.557612] swapper pgtable: 4k pages, 39-bit VAs, pgdp=41f98000 [ 10.565214] [ffde85245d30] pgd=10023003, p4d=10023003, pud=10023003, pmd=1001121eb003, pte= [ 10.578887] Internal error: Oops: 9647 [#1] PREEMPT SMP [ 10.585815] Modules linked in: [ 10.590235] CPU: 6 PID: 195 Comm: (udev-worker) Tainted: GB 6.8.0-rc2-next-20240130-02908-ge8ad01d60927-dirty #163 3f2318148ecc5fa70d1092c2b874f9b59bdb7d60 [ 10.607021] Hardware name: Google Tentacruel board (DT) [ 10.613607] pstate: a049 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 10.621954] pc : module_bug_finalize+0x118/0x148 [ 10.626823] lr : module_bug_finalize+0x118/0x148 [ 10.631463] sp : ffc0820478d0 [ 10.631466] x29: ffc0820478d0 x28: ffc082047ca0 x27: ffde8d7d31a0 [ 10.631477] x26: ffde85223780 x25: x24: ffde8c413cc0 [ 10.631486] x23: ffde8dfcec80 x22: ffde8dfce000 x21: ffde85223ba8 [ 10.631495] x20: ffde85223780 x19: ffde85245d28 x18: [ 10.631504] x17: ffde8aa15938 x16: ffde8aabdd90 x15: ffde8aab8124 [ 10.631513] x14: ffde8acdd380 x13: 41b58ab3 x12: ffbbd1bf9d91 [ 10.631522] x11: 1ffbd1bf9d90 x10: ffbbd1bf9d90 x9 : dfc0 [ 10.631531] x8 : 00442e406270 x7 : ffde8dfcec87 x6 : 0001 [ 10.631539] x5 : ffde8dfcec80 x4 : x3 : ffde8bbadf08 [ 10.631548] x2 : 0001 x1 : ffde8eaff080 x0 : [ 10.631556] Call trace: [ 10.631559] module_bug_finalize+0x118/0x148 [ 10.631565] load_module+0x25ec/0x2a78 [ 10.631572] __do_sys_init_module+0x234/0x418 [ 10.631578] __arm64_sys_init_module+0x4c/0x68 [ 10.631584] invoke_syscall+0x68/0x198 [ 10.631589] el0_svc_common.constprop.0+0x11c/0x150 [ 10.631594] do_el0_svc+0x38/0x50 [ 10.631598] el0_svc+0x50/0xa0 [ 10.631604] el0t_64_sync_handler+0x120/0x130 [ 10.631609] el0t_64_sync+0x1a8/0x1b0 [ 10.631619] Code: 97c5418e c89ffef5 91002260 97c53ca7 (f9000675) [ 10.631624] ---[ end trace ]--- [ 10.642965] Kernel panic - not syncing: Oops: Fatal exception [ 10.642975] SMP: stopping secondary CPUs [ 10.648339] Kernel Offset: 0x1e0a80 from 0xffc08000 [ 10.648343] PHYS_OFFSET: 0x4000 [ 10.648345] CPU features: 0x0,c061,7002814a,2100720b [ 10.648350] Memory Limit: none
Re: [PATCH] remoteproc: mediatek: Refactor single core check and fix retrocompatibility
On Wed, Sep 20, 2023 at 11:03 PM Laura Nao wrote:
>
> On 9/19/23 11:23, AngeloGioacchino Del Regno wrote:
> > In older devicetrees we had the ChromeOS EC in a node called "cros-ec"
> > instead of the newer "cros-ec-rpmsg", but this driver is now checking
> > only for the latter, breaking compatibility with those.
> >
> > Besides, we can check if the SCP is single or dual core by simply
> > walking through the children of the main SCP node and checking if
> > if there's more than one "mediatek,scp-core" compatible node.
> >
> > Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core
> > SCP")
> > Signed-off-by: AngeloGioacchino Del Regno
> >
> > ---
> > drivers/remoteproc/mtk_scp.c | 18 +++---
> > 1 file changed, 7 insertions(+), 11 deletions(-)
> >
>
> Tested on asurada (spherion) and jacuzzi (juniper). The issue was detected by
> KernelCI, so:
>
> Reported-by: "kernelci.org bot"
> Tested-by: Laura Nao
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
on Hayato (MT8192) and Juniper (MT8183).
Re: [PATCH] remoteproc: mediatek: Detect single/multi core SCP with rpmsg-name property
On Tue, Sep 19, 2023 at 5:26 PM AngeloGioacchino Del Regno
wrote:
>
> Il 19/09/23 07:03, Chen-Yu Tsai ha scritto:
> > In the just landed multi-core SCP work, detection of single/multi core
> > SCP is done by checking the immediate child node of the SCP complex
> > device node. In the original work this was done by matching the child
> > node's name. However the name wasn't previously standardized. This
> > resulted in breakage on MT8183 and MT8192 Chromebooks while the driver
> > side changes were picked up and the device tree changes were not picked
> > up.
> >
> > Instead, match against the "mediatek,rpmsg-name" property, which is
> > required to be present in the rpmsg sub-node. This makes the
> > aforementioned devices running old device trees working again.
> >
> > Reported-by: Laura Nao
> > Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core
> > SCP")
> > Signed-off-by: Chen-Yu Tsai
> > ---
> > The patch is based on next-20230918 with a whole bunch of local patches
> > stacked on top. None of my local patches are related to remoteproc, so
> > it should be fine.
> >
> > I tested on both MT8183 Juniper and MT8192 Hayato and on both systems
> > the SCP successfully probed again.
>
> Instead of checking "mediatek,rpmsg-name", I think that a better way of
> checking if
> this is single or multi core is to count the number of cores...
>
> I've sent my own version of this, please check [1].
My version checks the structure of the device node, much like the original
code, just against a different property/node name. If it's multi-core,
there would be sub-nodes for each core, and the rpmsg property would be
under those.
Either way works. What we need right now is a quick fix to get things
working again. We can discuss how to make things better later.
Honestly I think it should just be based on the compatible string. However
the current design seems quite fragile. The driver probably can't handle
the core device nodes being out of order.
ChenYu
Re: [PATCH v17 00/14] Add support for MT8195 SCP 2nd core
On Tue, Sep 19, 2023 at 9:17 AM Mathieu Poirier wrote: > > On Mon, Sep 18, 2023 at 06:44:25PM +0800, Chen-Yu Tsai wrote: > > On Mon, Sep 18, 2023 at 6:32 PM Laura Nao wrote: > > > > > > > Other than patch 2 and 14, I have applied this set. The remaining > > > > patches will > > > > have to be resent to Matthias. > > > > > > > Thanks, > > > > Mathieu > > > > > > Hello, > > > > > > With patch 2 missing, the SCP is not probed correctly anymore on asurada > > > (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence > > > of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single > > > or multicore. Without patch 2 the driver wrongly assumes the SCP on > > > MT8192 and MT8183 are multicore, leading to the following errors during > > > initialization: > > > > > > 10696 04:33:59.126671 <3>[ 15.465714] platform 1050.scp:cros-ec: > > > invalid resource (null) > > > 10697 04:33:59.142855 <3>[ 15.478560] platform 1050.scp:cros-ec: > > > Failed to parse and map sram memory > > > 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 1050.scp: Failed to > > > initialize core 0 rproc > > > > > > The issue was caught by KernelCI, complete logs can be found here: > > > - asurada: > > > https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html > > > - kukui: > > > https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html > > > > > > Reporting the issue so that patch 2 and 14 can be resent and merged soon. > > > > This being a backward incompatible DT binding change, maybe we should revert > > the node name change. Or, the driver could simply count the number of child > > nodes that have the "mediatek,rpmsg-name" property, which is required. > > > > You have a point. Can someone send a patch that makes this patchset backward > compatible? Please do so as quickly as possible to that it can go in the next > merge window with the rest of this feature. Otherwize I'll have to back out > the > whole thing. I sent out a patch [1] implementing my proposed change. ChenYu [1] https://lore.kernel.org/linux-remoteproc/20230919050305.3817347-1-we...@chromium.org/
[PATCH] remoteproc: mediatek: Detect single/multi core SCP with rpmsg-name property
In the just landed multi-core SCP work, detection of single/multi core
SCP is done by checking the immediate child node of the SCP complex
device node. In the original work this was done by matching the child
node's name. However the name wasn't previously standardized. This
resulted in breakage on MT8183 and MT8192 Chromebooks while the driver
side changes were picked up and the device tree changes were not picked
up.
Instead, match against the "mediatek,rpmsg-name" property, which is
required to be present in the rpmsg sub-node. This makes the
aforementioned devices running old device trees working again.
Reported-by: Laura Nao
Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core
SCP")
Signed-off-by: Chen-Yu Tsai
---
The patch is based on next-20230918 with a whole bunch of local patches
stacked on top. None of my local patches are related to remoteproc, so
it should be fine.
I tested on both MT8183 Juniper and MT8192 Hayato and on both systems
the SCP successfully probed again.
drivers/remoteproc/mtk_scp.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index ea227b566c54..ca15d9f382a1 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -1149,13 +1149,23 @@ static int scp_is_single_core(struct platform_device
*pdev)
struct device *dev = >dev;
struct device_node *np = dev_of_node(dev);
struct device_node *child;
+ bool has_rpmsg;
child = of_get_next_available_child(np, NULL);
if (!child)
return dev_err_probe(dev, -ENODEV, "No child node\n");
+ /*
+* On single core SCP systems, the immediate child of the SCP device
+* is the rpmsg node; on multi core systems, there's an intermediate
+* level node, one describing each core. Instead of matching on the
+* node name, which was recently changed in the DT binding in a
+* backward incompatible way, match against the "mediatek,rpmsg-name"
+* property, which is required in all rpmsg sub-nodes.
+*/
+ has_rpmsg = of_property_present(child, "mediatek,rpmsg-name");
of_node_put(child);
- return of_node_name_eq(child, "cros-ec-rpmsg");
+ return has_rpmsg;
}
static int scp_cluster_init(struct platform_device *pdev, struct
mtk_scp_of_cluster *scp_cluster)
--
2.42.0.459.ge4e396fd5e-goog
Re: [PATCH v17 00/14] Add support for MT8195 SCP 2nd core
On Mon, Sep 18, 2023 at 6:32 PM Laura Nao wrote: > > > Other than patch 2 and 14, I have applied this set. The remaining patches > > will > > have to be resent to Matthias. > > > Thanks, > > Mathieu > > Hello, > > With patch 2 missing, the SCP is not probed correctly anymore on asurada > (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of > the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or > multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and > MT8183 are multicore, leading to the following errors during initialization: > > 10696 04:33:59.126671 <3>[ 15.465714] platform 1050.scp:cros-ec: > invalid resource (null) > 10697 04:33:59.142855 <3>[ 15.478560] platform 1050.scp:cros-ec: > Failed to parse and map sram memory > 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 1050.scp: Failed to > initialize core 0 rproc > > The issue was caught by KernelCI, complete logs can be found here: > - asurada: > https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html > - kukui: > https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html > > Reporting the issue so that patch 2 and 14 can be resent and merged soon. This being a backward incompatible DT binding change, maybe we should revert the node name change. Or, the driver could simply count the number of child nodes that have the "mediatek,rpmsg-name" property, which is required. ChenYu
Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors
On Tue, Apr 20, 2021 at 09:28:06AM -0400, Calvin Walton wrote:
> On Tue, 2021-04-20 at 21:15 +0800, Chen Yu wrote:
> >
> > Okay. I would vote for the the patch from Bas as it was a combined
> > work from two
> > authors and tested by several AMD users. But let me paste it here too
> > for Artem to
> > see if this also works for him:
> >
> >
> > From 00e0622b1b693a5c7dc343aeb3aa51614a9e125e Mon Sep 17 00:00:00
> > 2001
> > From: Bas Nieuwenhuizen
> > Date: Fri, 12 Mar 2021 21:27:40 +0800
> > Subject: [PATCH] tools/power/turbostat: Fix turbostat for AMD Zen
> > CPUs
> >
> >
> > @@ -297,7 +297,10 @@ int idx_to_offset(int idx)
> >
> > switch (idx) {
> > case IDX_PKG_ENERGY:
> > - offset = MSR_PKG_ENERGY_STATUS;
> > + if (do_rapl & RAPL_AMD_F17H)
> > + offset = MSR_PKG_ENERGY_STAT;
> > + else
> > + offset = MSR_PKG_ENERGY_STATUS;
> > break;
> > case IDX_DRAM_ENERGY:
> > offset = MSR_DRAM_ENERGY_STATUS;
>
> This patch has the same issue I noticed with the initial revision of
> Terry's patch - the idx_to_offset function returns type int (32-bit
> signed), but MSR_PKG_ENERGY_STAT is greater than INT_MAX (or rather,
> would be interpreted as a negative number)
>
> The end result is, as far as I can tell, that it hits the if (offset <
> 0) check in update_msr_sum() resulting in the timer callback for
> updating the stat in the background when long durations are used to not
> happen.
>
> For short durations it still works fine since the background update
> isn't used.
>
Ah, got it, nice catch. How about an incremental patch based on Bas' one
to fix this 'overflow' issue? Would converting offset_to_idx(), idx_to_offset()
and
update_msr_sum() to use off_t instead of int be enough? Do you or Terry have
interest
to cook that patch? For Terry's version, I'm not sure if spliting
the code into different CPU vendor would benefit in the future, except
that we would have plenty of new MSRs to be introduced in the future.
thanks,
Chenyu
>
> --
> Calvin Walton
>
Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors
On Tue, Apr 20, 2021 at 10:07:01AM +0200, Borislav Petkov wrote:
> On Tue, Apr 20, 2021 at 10:03:36AM +0800, Chen Yu wrote:
> > On Mon, Apr 19, 2021 at 02:58:12PM -0500, Terry Bowman wrote:
> > > Turbostat fails to correctly collect and display RAPL summary information
> > > on Family 17h and 19h AMD processors. Running turbostat on these
> > > processors
> > > returns immediately. If turbostat is working correctly then RAPL summary
> > > data is displayed until the user provided command completes. If a command
> > > is not provided by the user then turbostat is designed to continuously
> > > display RAPL information until interrupted.
> > >
> > > The issue is due to offset_to_idx() and idx_to_offset() missing support
> > > for
> > > AMD MSR addresses/offsets. offset_to_idx()'s switch statement is missing
> > > cases for AMD MSRs and idx_to_offset() does not include a path to return
> > > AMD MSR(s) for any idx.
> > >
> > > The solution is add AMD MSR support to offset_to_idx() and
> > > idx_to_offset().
> > > These functions are split-out and renamed along architecture vendor lines
> > > for supporting both AMD and Intel MSRs.
> > >
> > > Fixes: 9972d5d84d76 ("tools/power turbostat: Enable accumulate RAPL
> > > display")
> > > Signed-off-by: Terry Bowman
> > Thanks for fixing, Terry, and previously there was a patch for this from
> > Bas Nieuwenhuizen:
> > https://lkml.org/lkml/2021/3/12/682
> > and it is expected to have been merged in Len's branch already.
>
> Expected?
>
> So is it or is it not?
>
This patch was sent to Len and it is not in public repo yet. He is preparing
for a new
release of turbostat as merge window is approaching.
> And can you folks agree on a patch already and give it to Artem for
> testing (CCed) because he's triggering it too:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=212357
>
Okay. I would vote for the the patch from Bas as it was a combined work from two
authors and tested by several AMD users. But let me paste it here too for Artem
to
see if this also works for him:
>From 00e0622b1b693a5c7dc343aeb3aa51614a9e125e Mon Sep 17 00:00:00 2001
From: Bas Nieuwenhuizen
Date: Fri, 12 Mar 2021 21:27:40 +0800
Subject: [PATCH] tools/power/turbostat: Fix turbostat for AMD Zen CPUs
It was reported that on Zen+ system turbostat started exiting,
which was tracked down to the MSR_PKG_ENERGY_STAT read failing because
offset_to_idx wasn't returning a non-negative index.
This patch combined the modification from Bingsong Si and
Bas Nieuwenhuizen and addd the MSR to the index system as alternative for
MSR_PKG_ENERGY_STATUS.
Fixes: 9972d5d84d76 ("tools/power turbostat: Enable accumulate RAPL display")
Reported-by: youling257
Tested-by: youling257
Tested-by: sibingsong
Tested-by: Kurt Garloff
Co-developed-by: Bingsong Si
Signed-off-by: Chen Yu
---
tools/power/x86/turbostat/turbostat.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index a7c4f0772e53..a7c965734fdf 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -297,7 +297,10 @@ int idx_to_offset(int idx)
switch (idx) {
case IDX_PKG_ENERGY:
- offset = MSR_PKG_ENERGY_STATUS;
+ if (do_rapl & RAPL_AMD_F17H)
+ offset = MSR_PKG_ENERGY_STAT;
+ else
+ offset = MSR_PKG_ENERGY_STATUS;
break;
case IDX_DRAM_ENERGY:
offset = MSR_DRAM_ENERGY_STATUS;
@@ -326,6 +329,7 @@ int offset_to_idx(int offset)
switch (offset) {
case MSR_PKG_ENERGY_STATUS:
+ case MSR_PKG_ENERGY_STAT:
idx = IDX_PKG_ENERGY;
break;
case MSR_DRAM_ENERGY_STATUS:
@@ -353,7 +357,7 @@ int idx_valid(int idx)
{
switch (idx) {
case IDX_PKG_ENERGY:
- return do_rapl & RAPL_PKG;
+ return do_rapl & (RAPL_PKG | RAPL_AMD_F17H);
case IDX_DRAM_ENERGY:
return do_rapl & RAPL_DRAM;
case IDX_PP0_ENERGY:
--
2.25.1
thanks,
Chenyu
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG
> Nürnberg
Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors
On Mon, Apr 19, 2021 at 02:58:12PM -0500, Terry Bowman wrote:
> Turbostat fails to correctly collect and display RAPL summary information
> on Family 17h and 19h AMD processors. Running turbostat on these processors
> returns immediately. If turbostat is working correctly then RAPL summary
> data is displayed until the user provided command completes. If a command
> is not provided by the user then turbostat is designed to continuously
> display RAPL information until interrupted.
>
> The issue is due to offset_to_idx() and idx_to_offset() missing support for
> AMD MSR addresses/offsets. offset_to_idx()'s switch statement is missing
> cases for AMD MSRs and idx_to_offset() does not include a path to return
> AMD MSR(s) for any idx.
>
> The solution is add AMD MSR support to offset_to_idx() and idx_to_offset().
> These functions are split-out and renamed along architecture vendor lines
> for supporting both AMD and Intel MSRs.
>
> Fixes: 9972d5d84d76 ("tools/power turbostat: Enable accumulate RAPL display")
> Signed-off-by: Terry Bowman
Thanks for fixing, Terry, and previously there was a patch for this from Bas
Nieuwenhuizen:
https://lkml.org/lkml/2021/3/12/682
and it is expected to have been merged in Len's branch already.
thanks,
Chenyu
Re: [PATCH 0/2] sunxi: Enforce consistent MMC numbering
Hi, On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland wrote: > > Dealing with the inconsistent numbering has been a major pain, and > there is a solution with (as far as I can tell) no tangible downsides. > So let's use it. > > Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help > when referencing the whole, unpartitioned device, like is needed for > updating the bootloader and firmware. So for the use case of "write a > bootloader to the SD card, regardless of where the board is currently > booted from", I know of two options: > - Dig around in sysfs to find the mmc number from the MMIO address, > which means I have to know the MMIO addresses for every SoC, or > - Apply patches like these. > > Samuel Holland (2): > ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering > arm64: dts: allwinner: Enforce consistent MMC numbering > > arch/arm/boot/dts/sunxi-h3-h5.dtsi| 6 ++ > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++ > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 6 ++ At least with Rockchip this is now done at the board level. IIRC it was a request from other people to not do it at the SoC level. I don't recall exactly who though. ChenYu > 3 files changed, 18 insertions(+) > > -- > 2.26.3 > >
Re: [PATCH] nvmem: sunxi_sid: Set type to OTP
On Mon, Apr 19, 2021 at 9:58 AM Samuel Holland wrote: > > This device currently reports an "Unknown" type in sysfs. > Since it is an eFuse hardware device, set its type to OTP. > > Signed-off-by: Samuel Holland Acked-by: Chen-Yu Tsai
Re: [PATCH] Fix turbostat exiting with an error when run on AMD CPUs
Hi Calvin, On Wed, Apr 14, 2021 at 10:08:07PM -0400, Calvin Walton wrote: > On Wed, 2021-04-14 at 22:05 -0400, Calvin Walton wrote: > > The current version of turbostat exits immediately upon entering the > > main loop, with error code -13. This is a regression that was > > introducted > > in these commits: > > > > 9972d5d84d76 tools/power turbostat: Enable accumulate RAPL display > > 87e15da95775 tools/power turbostat: Introduce functions to accumulate > > RAPL consumption > > Ah, I failed to check the mailing list before sending this patch! Terry > Bowman's fix here should probably be preferred: > https://patchwork.kernel.org/project/linux-pm/patch/20210331155807.3838-1-terry.bow...@amd.com/ > > My patch was simply the minimum necessary to get turbostat working > again. Thanks for reporting this. We had a fix for this previously at https://lkml.org/lkml/2021/3/12/682 I'll check with Len if this patch has been merged. thanks, Chenyu > -- > Calvin Walton >
Re: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties from pwm nodes rv1108.dtsi
On Mon, Apr 12, 2021 at 6:03 PM Johan Jonker wrote: > > On 4/12/21 5:15 AM, Chen-Yu Tsai wrote: > > On Sun, Apr 11, 2021 at 9:11 PM Johan Jonker wrote: > >> > >> A test with the command below gives this error: > >> > >> /arch/arm/boot/dts/rv1108-evb.dt.yaml: > >> pwm@1028: 'interrupts' does not match any of the regexes: > >> 'pinctrl-[0-9]+' > >> > >> "interrupts" is an undocumented property, so remove them > >> from pwm nodes in rv1108.dtsi. > >> > >> make ARCH=arm dtbs_check > >> DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml > >> > >> Signed-off-by: Johan Jonker > > > > Given that the interrupts were specified, meaning they are wired up in > > hardware, > > shouldn't the solution be to add the interrupts property to the binding > > instead? > > > > After all, the device tree describes the actual hardware, not just what the > > implementations need. > > > > ChenYu > > > > Hi, > > The question of what to do with it was asked in version 1, but no answer > was given, so I made a proposal. > The device tree description should be complete, but also as lean as > possible. If someone manages to sneak in undocumented properties without > reason then the ultimate consequence should be removal I think. > > Not sure about the (missing?) rv1108 TRM, but for rk3328 the interrupt > is used for: > > PWM_INTSTS 0x0040 W 0x Interrupt Status Register > Channel Interrupt Polarity Flag > This bit is used in capture mode in order to identify the > transition of the input waveform when interrupt is generated. > Channel Interrupt Status > Interrupt generated > > PWM_INT_EN 0x0044 W 0x Interrupt Enable Register > Channel Interrupt Enable > > Is there any current realistic use/setup for it to convince rob+dt this > should be added to pwm-rockchip.yaml? Well, the PWM core has capture support, and pwm-sti implements it with interrupt support, so I guess there's at least a legitimate case for adding that to the binding. Whether someone has an actual use case for it and adds code to implement it is another story. > The rk3328 interrupt rkpwm_int seems shared between channels, but only > included to pwm3. What is the proper way for that? I guess the bigger question is why was the PWM controller split into four device nodes, instead of just one encompassing the whole block. Now we'd have to introduce a new binding to support capture mode and interrupts. In that case I agree with dropping the interrupts for now, as it just won't fit. But I would add this additional information to the commit message. Regards ChenYu
Re: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties from pwm nodes rv1108.dtsi
On Sun, Apr 11, 2021 at 9:11 PM Johan Jonker wrote: > > A test with the command below gives this error: > > /arch/arm/boot/dts/rv1108-evb.dt.yaml: > pwm@1028: 'interrupts' does not match any of the regexes: > 'pinctrl-[0-9]+' > > "interrupts" is an undocumented property, so remove them > from pwm nodes in rv1108.dtsi. > > make ARCH=arm dtbs_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml > > Signed-off-by: Johan Jonker Given that the interrupts were specified, meaning they are wired up in hardware, shouldn't the solution be to add the interrupts property to the binding instead? After all, the device tree describes the actual hardware, not just what the implementations need. ChenYu
Re: [PATCH] cpufreq: intel_pstate: Simplify intel_pstate_update_perf_limits()
On Wed, Apr 07, 2021 at 04:21:55PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Because pstate.max_freq is always equal to the product of > pstate.max_pstate and pstate.scaling and, analogously, > pstate.turbo_freq is always equal to the product of > pstate.turbo_pstate and pstate.scaling, the result of the > max_policy_perf computation in intel_pstate_update_perf_limits() is > always equal to the quotient of policy_max and pstate.scaling, > regardless of whether or not turbo is disabled. Analogously, the > result of min_policy_perf in intel_pstate_update_perf_limits() is > always equal to the quotient of policy_min and pstate.scaling. > > Accordingly, intel_pstate_update_perf_limits() need not check > whether or not turbo is enabled at all and in order to compute > max_policy_perf and min_policy_perf it can always divide policy_max > and policy_min, respectively, by pstate.scaling. Make it do so. > > While at it, move the definition and initialization of the > turbo_max local variable to the code branch using it. > > No intentional functional impact. > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu
Re: [PATCH v2] rockchip: enabled LAN port on NanoPi R2S
On Mon, Apr 5, 2021 at 7:03 PM Johan Jonker wrote:
>
> Hi Tianling,
>
> On 4/5/21 11:34 AM, Tianling Shen wrote:
> > From: David Bauer
> >
> > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > This is required for the USB3 attached LAN port to work.
> >
> > Signed-off-by: David Bauer
> > [added device node for USB Ethernet controller]
> > Signed-off-by: Tianling Shen
> > ---
> > .../boot/dts/rockchip/rk3328-nanopi-r2s.dts | 32 +++
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > index faf496d789cf..18936b393d9d 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > @@ -13,6 +13,10 @@
> > model = "FriendlyElec NanoPi R2S";
> > compatible = "friendlyarm,nanopi-r2s", "rockchip,rk3328";
> >
> > + aliases {
> > + ethernet1 =
> > + };
> > +
> > chosen {
> > stdout-path = "serial2:150n8";
> > };
> > @@ -37,6 +41,16 @@
> > };
> > };
> >
>
> > + vcc_rtl8153: vcc-rtl8153-regulator {
>
> sort nodename
>
> > + compatible = "regulator-fixed";
> > + gpio = < RK_PC6 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_en_drv>;
> > + regulator-always-on;
>
> > + regulator-name = "vcc_rtl8153";
>
> exception to the sort rule
> sort regulator-name above all other regulator properties
>
> > + enable-active-high;
>
> sort
>
>
> Heiko's sort rules:
>
> compatible
> reg
> interrupts
> [alphabetical]
> status [if needed]
>
>
>
> > + };
> > +
> > leds {
> > compatible = "gpio-leds";
> > pinctrl-0 = <_led_pin>, <_led_pin>, <_led_pin>;
> > @@ -265,6 +279,12 @@
> > };
> > };
> > };
> > +
> > + usb {
> > + rtl8153_en_drv: rtl8153-en-drv {
> > + rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO
> > _pull_none>;
> > + };
> > + };
> > };
> >
> > _domains {
> > @@ -364,6 +384,18 @@
> > dr_mode = "host";
> > };
> >
> > + {
> > + dr_mode = "host";
> > + status = "okay";
> > +
>
> > + r8153: usb-eth@2 {
>
> With YAML undocumented additional properties and nodes generate
> notifications.
> We need a change in the documents below for that.
> rockchip,dwc3.yaml > usb-drd.yaml > usb.yaml
>
> Is there a standard for the usb-eth nodename?
The USB devices binding seems to specify "device" and then
"interface" sub-nodes.
> > + compatible = "realtek,rtl8153";
>
> Since a while Rob has improved has scripts.
> There's no escape anymore.
> Add a YAML document to this serie for "realtek,rtl8153".
Actually it should be "usbbda,8153", which conforms to
Documentation/devicetree/bindings/usb/usb-device.yaml
Giving "realtek,rtl8153" to the kernel will not help it match any
device.
ChenYu
> Improve checking for undocumented compatible strings
> https://github.com/devicetree-org/dt-schema/commit/93e7ada8d53af099074cb5d53f7caa12835784e0
>
> > + reg = <2>;
>
> Why 2 ?
>
> > +
>
> > + local-mac-address = [ 00 00 00 00 00 00 ]; /* Filled in by
> > U-Boot */
>
> This is a private property.
> In a generic dts that's up to the user.
>
> > + };
> > +};
> > +
> > _host0_ehci {
> > status = "okay";
> > };
> >
>
Re: [PATCH] rockchip: enabled LAN port on NanoPi R2S
On Mon, Apr 5, 2021 at 4:53 PM Tianling Shen wrote:
>
> Hi Chen-Yu,
>
> On 2021-04-05 16:14, Chen-Yu Tsai wrote:
> >
> > Hi,
> >
> > On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen wrote:
> > >
> > > From: David Bauer
> > >
> > > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > > This is required for the USB3 attached LAN port to work.
> > >
> > > Signed-off-by: David Bauer
> > > Signed-off-by: Tianling Shen
> > > ---
> > > .../boot/dts/rockchip/rk3328-nanopi-r2s.dts | 23 +++
> > > 1 file changed, 23 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > index faf496d789cf..6ba9799a95c5 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > @@ -37,6 +37,18 @@
> > > };
> > > };
> > >
> > > + vcc_rtl8153: vcc-rtl8153-regulator {
> > > + compatible = "regulator-fixed";
> > > + gpio = < RK_PC6 GPIO_ACTIVE_HIGH>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_en_drv>;
> > > + regulator-always-on;
> > > + regulator-name = "vcc_rtl8153";
> > > + regulator-min-microvolt = <500>;
> > > + regulator-max-microvolt = <500>;
> >
> > This is just a simple switch, not an actual regulator.
> > It would make more sense to drop the voltage range and
> > instead have the implementation pass-through voltage
> > constraints from its parent.
>
> Thanks, I'll remove them in v2.
>
> >
> > > + enable-active-high;
> > > + };
> > > +
> > > leds {
> > > compatible = "gpio-leds";
> > > pinctrl-0 = <_led_pin>, <_led_pin>,
> > > <_led_pin>;
> > > @@ -265,6 +277,12 @@
> > > };
> > > };
> > > };
> > > +
> > > + usb {
> > > + rtl8153_en_drv: rtl8153-en-drv {
> > > + rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO
> > > _pull_none>;
> > > + };
> > > + };
> > > };
> > >
> > > _domains {
> > > @@ -364,6 +382,11 @@
> > > dr_mode = "host";
> > > };
> > >
> > > + {
> > > + dr_mode = "host";
> > > + status = "okay";
> >
> > Please also add a device node for the actual Ethernet controller, and
> > set up an aliases node for it, so that the bootloader has some place
> > to fill in a MAC address.
>
> But there's no valid (unique) MAC address for both this or on-board
> ethernet...
> They're non-existent in design.
Correct. And thanks for confirming that it's not just me and Robin that
got boards without the MAC address EEPROM...
If the user sets some MAC address in the bootloader environment by hand,
the bootloader could still potentially pass that MAC address to Linux
through the device tree. Whether the board has a valid address or not
is beside the point.
ChenYu
> Thanks,
> Tianling.
>
> >
> >
> > ChenYu
> >
> > > +};
> > > +
> > > _host0_ehci {
> > > status = "okay";
> > > };
> > > --
> > > 2.17.1
> > >
> > >
> > > ___
> > > linux-arm-kernel mailing list
> > > linux-arm-ker...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] rockchip: enabled LAN port on NanoPi R2S
Hi,
On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen wrote:
>
> From: David Bauer
>
> Enable the USB3 port on the FriendlyARM NanoPi R2S.
> This is required for the USB3 attached LAN port to work.
>
> Signed-off-by: David Bauer
> Signed-off-by: Tianling Shen
> ---
> .../boot/dts/rockchip/rk3328-nanopi-r2s.dts | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> index faf496d789cf..6ba9799a95c5 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> @@ -37,6 +37,18 @@
> };
> };
>
> + vcc_rtl8153: vcc-rtl8153-regulator {
> + compatible = "regulator-fixed";
> + gpio = < RK_PC6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_en_drv>;
> + regulator-always-on;
> + regulator-name = "vcc_rtl8153";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
This is just a simple switch, not an actual regulator.
It would make more sense to drop the voltage range and
instead have the implementation pass-through voltage
constraints from its parent.
> + enable-active-high;
> + };
> +
> leds {
> compatible = "gpio-leds";
> pinctrl-0 = <_led_pin>, <_led_pin>, <_led_pin>;
> @@ -265,6 +277,12 @@
> };
> };
> };
> +
> + usb {
> + rtl8153_en_drv: rtl8153-en-drv {
> + rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO
> _pull_none>;
> + };
> + };
> };
>
> _domains {
> @@ -364,6 +382,11 @@
> dr_mode = "host";
> };
>
> + {
> + dr_mode = "host";
> + status = "okay";
Please also add a device node for the actual Ethernet controller, and
set up an aliases node for it, so that the bootloader has some place
to fill in a MAC address.
ChenYu
> +};
> +
> _host0_ehci {
> status = "okay";
> };
> --
> 2.17.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 28/38] dt-bindings: power: supply: axp20x: Convert to DT schema format
On Fri, Mar 12, 2021 at 11:52 PM Sebastian Reichel wrote: > > Convert the binding to DT schema format. > > Cc: Chen-Yu Tsai > Signed-off-by: Sebastian Reichel Looks good to me. Though I'm not well versed in the new YAML binding format yet. Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH v2] ARM: dts: sun8i: h3: beelink-x2: Add power button
On Wed, Mar 24, 2021 at 4:44 AM Jernej Skrabec wrote: > > Beelink X2 has power button. Add node for it. > > Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai
Re: [PATCH v3 6/8] power: supply: Clean-up few drivers by using managed work init
Hi,
On Tue, Mar 23, 2021 at 9:58 PM Matti Vaittinen
wrote:
>
> Few drivers implement remove call-back only for ensuring a delayed
> work gets cancelled prior driver removal. Clean-up these by switching
> to use devm_delayed_work_autocancel() instead.
>
> This change is compile-tested only. All testing is appreciated.
>
> Signed-off-by: Matti Vaittinen
> Acked-by: Sebastian Reichel
> ---
> Changelog from RFCv2:
> - RFC dropped. No functional changes.
>
> drivers/power/supply/axp20x_usb_power.c | 15 +--
> drivers/power/supply/bq24735-charger.c | 18 ++
> drivers/power/supply/ltc2941-battery-gauge.c | 20 +++-
> drivers/power/supply/sbs-battery.c | 16 +---
> 4 files changed, 23 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/power/supply/axp20x_usb_power.c
> b/drivers/power/supply/axp20x_usb_power.c
> index 8933ae26c3d6..4259709e3491 100644
> --- a/drivers/power/supply/axp20x_usb_power.c
> +++ b/drivers/power/supply/axp20x_usb_power.c
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -646,21 +647,16 @@ static int axp20x_usb_power_probe(struct
> platform_device *pdev)
> }
> }
>
> + ret = devm_delayed_work_autocancel(>dev, >vbus_detect,
> + axp20x_usb_power_poll_vbus);
> + if (ret)
> + return ret;
This doesn't look right. The IRQ is requested before this, and the delayed_work
struct is initialized even earlier, so you'd be re-initializing the struct,
with the work item potentially running or queued up already.
ChenYu
> if (axp20x_usb_vbus_needs_polling(power))
> queue_delayed_work(system_power_efficient_wq,
> >vbus_detect, 0);
>
> return 0;
> }
>
> -static int axp20x_usb_power_remove(struct platform_device *pdev)
> -{
> - struct axp20x_usb_power *power = platform_get_drvdata(pdev);
> -
> - cancel_delayed_work_sync(>vbus_detect);
> -
> - return 0;
> -}
> -
> static const struct of_device_id axp20x_usb_power_match[] = {
> {
> .compatible = "x-powers,axp202-usb-power-supply",
> @@ -680,7 +676,6 @@ MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
>
> static struct platform_driver axp20x_usb_power_driver = {
> .probe = axp20x_usb_power_probe,
> - .remove = axp20x_usb_power_remove,
> .driver = {
> .name = DRVNAME,
> .of_match_table = axp20x_usb_power_match,
Re: [PATCH] cpufreq: intel_pstate: Clean up frequency computations
On Tue, Mar 16, 2021 at 04:52:43PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Notice that some computations related to frequency in intel_pstate > can be simplified if (a) intel_pstate_get_hwp_max() updates the > relevant members of struct cpudata by itself and (b) the "turbo > disabled" check is moved from it to its callers, so modify the code > accordingly and while at it rename intel_pstate_get_hwp_max() to > intel_pstate_get_hwp_cap() which better reflects its purpose and > provide a simplified variat of it, __intel_pstate_get_hwp_cap(), > suitable for the initialization path. > > No intentional functional impact. > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
Re: [PATCH] ACPI: CPPC: Add emtpy stubs of functions for CONFIG_ACPI_CPPC_LIB unset
On Tue, Mar 16, 2021 at 04:54:03PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > For convenience, add empty stubs of library functions defined in > cppc_acpi.c for the CONFIG_ACPI_CPPC_LIB unset case. > > Because one of them needs to return CPUFREQ_ETERNAL, include > linux/cpufreq.h into the CPPC library header file and drop the > direct inclusion of it from cppc_acpi.c. > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
Re: [RFC RESEND PATCH v2 6/8] power: supply: Clean-up few drivers by using managed work init
Hi,
On Mon, Mar 22, 2021 at 3:38 PM Matti Vaittinen
wrote:
>
> Few drivers implement remove call-back only for ensuring a delayed
> work gets cancelled prior driver removal. Clean-up these by switching
> to use devm_delayed_work_autocancel() instead.
>
> This change is compile-tested only. All testing is appreciated.
>
> Signed-off-by: Matti Vaittinen
> Acked-by: Sebastian Reichel
> ---
> drivers/power/supply/axp20x_usb_power.c | 15 +--
> drivers/power/supply/bq24735-charger.c | 18 ++
> drivers/power/supply/ltc2941-battery-gauge.c | 20 +++-
> drivers/power/supply/sbs-battery.c | 16 +---
> 4 files changed, 23 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/power/supply/axp20x_usb_power.c
> b/drivers/power/supply/axp20x_usb_power.c
> index 8933ae26c3d6..4259709e3491 100644
> --- a/drivers/power/supply/axp20x_usb_power.c
> +++ b/drivers/power/supply/axp20x_usb_power.c
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -646,21 +647,16 @@ static int axp20x_usb_power_probe(struct
> platform_device *pdev)
> }
> }
>
> + ret = devm_delayed_work_autocancel(>dev, >vbus_detect,
> + axp20x_usb_power_poll_vbus);
> + if (ret)
> + return ret;
This doesn't look right. The IRQ is requested before this, and the delayed_work
struct is initialized even earlier, so you'd be re-initializing the struct,
with the work item potentially running or queued up already.
ChenYu
> if (axp20x_usb_vbus_needs_polling(power))
> queue_delayed_work(system_power_efficient_wq,
> >vbus_detect, 0);
>
> return 0;
> }
>
> -static int axp20x_usb_power_remove(struct platform_device *pdev)
> -{
> - struct axp20x_usb_power *power = platform_get_drvdata(pdev);
> -
> - cancel_delayed_work_sync(>vbus_detect);
> -
> - return 0;
> -}
> -
> static const struct of_device_id axp20x_usb_power_match[] = {
> {
> .compatible = "x-powers,axp202-usb-power-supply",
> @@ -680,7 +676,6 @@ MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
>
> static struct platform_driver axp20x_usb_power_driver = {
> .probe = axp20x_usb_power_probe,
> - .remove = axp20x_usb_power_remove,
> .driver = {
> .name = DRVNAME,
> .of_match_table = axp20x_usb_power_match,
Re: linux-next: build warning after merge of the net-next tree
Hi Stephen,
On Wed, Mar 17, 2021 at 06:56:05PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (sparc64
> defconfig) produced this warning:
>
> drivers/net/ethernet/intel/e1000e/netdev.c:6926:12: warning:
> 'e1000e_pm_prepare' defined but not used [-Wunused-function]
> static int e1000e_pm_prepare(struct device *dev)
> ^
>
> Introduced by commit
>
> ccf8b940e5fd ("e1000e: Leverage direct_complete to speed up s2ram")
>
> CONFIG_PM_SLEEP is not set for this build.
>
Thanks for reporting. I think we need to add the '__maybe_unused' attribute as
in case
CONFIG_PM_SLEEP is not set. Tony, it seems that the original v1 patch should
eliminate
this warning, could you please help double check and apply that version?
thanks,
Chenyu
> --
> Cheers,
> Stephen Rothwell
Re: [3/3,v3] tools/power turbostat: Enable accumulate RAPL display
Hi Youling, Bas, and Bingsong,
On Wed, Mar 10, 2021 at 04:03:31PM -0800, Doug Smythies wrote:
> Hi Yu,
>
> I am just resending your e-mail, adjusting the "To:" list to
> include the 3 others that have submitted similar patches.
>
> ... Doug
>
Could you please help check if the following combined patch works?
Thanks,
Chenyu
>From 00e0622b1b693a5c7dc343aeb3aa51614a9e125e Mon Sep 17 00:00:00 2001
From: Bas Nieuwenhuizen
Date: Fri, 12 Mar 2021 21:27:40 +0800
Subject: [PATCH] tools/power/turbostat: Fix turbostat for AMD Zen CPUs
It was reported that on Zen+ system turbostat started exiting,
which was tracked down to the MSR_PKG_ENERGY_STAT read failing because
offset_to_idx wasn't returning a non-negative index.
This patch combined the modification from Bingsong Si and
Bas Nieuwenhuizen and addd the MSR to the index system as alternative for
MSR_PKG_ENERGY_STATUS.
Fixes: 9972d5d84d76 ("tools/power turbostat: Enable accumulate RAPL display")
Reported-by: youling257
Co-developed-by: Bingsong Si
Signed-off-by: Chen Yu
---
tools/power/x86/turbostat/turbostat.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index a7c4f0772e53..a7c965734fdf 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -297,7 +297,10 @@ int idx_to_offset(int idx)
switch (idx) {
case IDX_PKG_ENERGY:
- offset = MSR_PKG_ENERGY_STATUS;
+ if (do_rapl & RAPL_AMD_F17H)
+ offset = MSR_PKG_ENERGY_STAT;
+ else
+ offset = MSR_PKG_ENERGY_STATUS;
break;
case IDX_DRAM_ENERGY:
offset = MSR_DRAM_ENERGY_STATUS;
@@ -326,6 +329,7 @@ int offset_to_idx(int offset)
switch (offset) {
case MSR_PKG_ENERGY_STATUS:
+ case MSR_PKG_ENERGY_STAT:
idx = IDX_PKG_ENERGY;
break;
case MSR_DRAM_ENERGY_STATUS:
@@ -353,7 +357,7 @@ int idx_valid(int idx)
{
switch (idx) {
case IDX_PKG_ENERGY:
- return do_rapl & RAPL_PKG;
+ return do_rapl & (RAPL_PKG | RAPL_AMD_F17H);
case IDX_DRAM_ENERGY:
return do_rapl & RAPL_DRAM;
case IDX_PP0_ENERGY:
--
2.25.1
Re: [3/3,v3] tools/power turbostat: Enable accumulate RAPL display
On Wed, Mar 10, 2021 at 04:03:31PM -0800, Doug Smythies wrote: > Hi Yu, > > I am just resending your e-mail, adjusting the "To:" list to > include the 3 others that have submitted similar patches. > Thanks for adding the authors. I'll combine their patch with their credits and send to Len for pulling. thanks, Chenyu > ... Doug > > On Mon, Mar 8, 2021 at 8:11 AM Chen Yu wrote: > > > > Hi, > > On Mon, Mar 08, 2021 at 07:37:07AM -0800, Doug Smythies wrote: > > > On Mon, Mar 8, 2021 at 5:50 AM youling257 wrote: > > > > > > > > this cause turbostat not work on amd cpu. > > > > > > > > root@localhost:~# /turbostat > > > > turbostat version 20.09.30 - Len Brown > > > > CPUID(0): AuthenticAMD 0xd CPUID levels; 0x801f xlevels; > > > > family:model:stepping 0x17:18:1 (23:24:1) > > > > > > There are already two fixes for this in the queue. > > > https://marc.info/?l=linux-pm=161382097503925=2 > > > https://marc.info/?l=linux-pm=161141701219263=2 > > Thanks for reporting and pointing this out. I assume these two patches are > > both fixing the > > same issue? It looks like these two patches should be merged into one: > > 1. Bingsong's patch access MSR_PKG_ENERGY_STAT only when RAPL_AMD_F17H is > > set, > >which is consistent with the original context. > > 2. Bas Nieuwenhuizen's patch also fixes the issue in idx_valid() > >in case RAPL_PKG was not set but with RAPL_AMD_F17H set. > > > > thanks, > > Chenyu
Re: [3/3,v3] tools/power turbostat: Enable accumulate RAPL display
Hi, On Mon, Mar 08, 2021 at 07:37:07AM -0800, Doug Smythies wrote: > On Mon, Mar 8, 2021 at 5:50 AM youling257 wrote: > > > > this cause turbostat not work on amd cpu. > > > > root@localhost:~# /turbostat > > turbostat version 20.09.30 - Len Brown > > CPUID(0): AuthenticAMD 0xd CPUID levels; 0x801f xlevels; > > family:model:stepping 0x17:18:1 (23:24:1) > > There are already two fixes for this in the queue. > https://marc.info/?l=linux-pm=161382097503925=2 > https://marc.info/?l=linux-pm=161141701219263=2 Thanks for reporting and pointing this out. I assume these two patches are both fixing the same issue? It looks like these two patches should be merged into one: 1. Bingsong's patch access MSR_PKG_ENERGY_STAT only when RAPL_AMD_F17H is set, which is consistent with the original context. 2. Bas Nieuwenhuizen's patch also fixes the issue in idx_valid() in case RAPL_PKG was not set but with RAPL_AMD_F17H set. thanks, Chenyu
Re: [PATCH] media: platform: sunxi: sun6i-csi: fix error return code of sun6i_video_start_streaming()
On Sat, Mar 6, 2021 at 10:15 PM Jia-Ju Bai wrote:
>
> When sun6i_video_remote_subdev() returns NULL to subdev, no error return
> code of sun6i_video_start_streaming() is assigned.
> To fix this bug, ret is assigned with -EINVAL in this case.
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
This should have the tag:
Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
Please try to add them when fixing bugs. And this should also be tagged
for stable, so
Cc:
Otherwise,
Acked-by: Chen-Yu Tsai
[PATCH] arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices
From: Chen-Yu Tsai
The macros for the clock and reset indices for the RSB hardware block
were replaced with raw numbers when the RSB controller node was added.
This was done to avoid cross-tree dependencies.
Now that both the clk and DT changes have been merged, we can switch
back to using the macros.
Fixes: aaad900757a6 ("arm64: dts: allwinner: h6: Add RSB controller node")
Signed-off-by: Chen-Yu Tsai
---
Small patch split out from the H6 RSB clock support patch.
This should be merged for v5.12.
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 49e979794094..af8b7d0ef750 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -995,9 +995,9 @@ r_rsb: rsb@7083000 {
compatible = "allwinner,sun8i-a23-rsb";
reg = <0x07083000 0x400>;
interrupts = ;
- clocks = <_ccu 13>;
+ clocks = <_ccu CLK_R_APB2_RSB>;
clock-frequency = <300>;
- resets = <_ccu 7>;
+ resets = <_ccu RST_R_APB2_RSB>;
pinctrl-names = "default";
pinctrl-0 = <_rsb_pins>;
status = "disabled";
--
2.30.1
Re: [PATCH] clk: sunxi-ng: v3s: add support for variable rate audio pll output
On Thu, Feb 18, 2021 at 4:06 PM Icenowy Zheng wrote: > > > > 于 2021年2月18日 GMT+08:00 下午3:58:35, Maxime Ripard 写到: > >Hi, > > > >On Fri, Feb 12, 2021 at 02:57:25PM +0100, Tobias Schramm wrote: > >> Previously the variable rate audio pll output was fixed to a divider > >of > >> four. This is unfortunately incompatible with generating commonly > >used > >> I2S core clock rates like 24.576MHz from the 24MHz parent clock. > >> This commit adds support for arbitrary audio pll output dividers to > >fix > >> that. > >> > >> Signed-off-by: Tobias Schramm > > > >It's not really clear to me how that would help. > > We have introducee SDM-based accurate audio PLL on several > other SoCs. Some people is quite sensitive about audio-related things. Right. What you really want is the SDM-based fractional clock support. Just look at the other drivers. > > > >The closest frequency we can provide for 24.576MHz would be 24580645 > >Hz, > >with N = 127, M = 31 and P = 4, so it would work with what we have > >already? Correct. And that is still slightly off. It's even worse for the 44.1khz family. ChenYu > >Maxime > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
On Sat, Feb 6, 2021 at 12:21 AM Jernej Škrabec wrote:
>
> Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> > On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
> wrote:
> > > >
> > > > Channel 1 has polarity bits for vsync and hsync signals but driver never
> > > > sets them. It turns out that with pre-HDMI2 controllers seemingly there
> > > > is no issue if polarity is not set. However, with HDMI2 controllers
> > > > (H6) there often comes to de-synchronization due to phase shift. This
> > > > causes flickering screen. It's safe to assume that similar issues might
> > > > happen also with pre-HDMI2 controllers.
> > > >
> > > > Solve issue with setting vsync and hsync polarity. Note that display
> > > > stacks with tcon top have polarity bits actually in tcon0 polarity
> > > > register.
> > > >
> > > > Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> > > > Tested-by: Andre Heider
> > > > Signed-off-by: Jernej Skrabec
> > > > ---
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> > > > 2 files changed, 29 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/
> sun4i_tcon.c
> > > > index 6b9af4c08cd6..0d132dae58c0 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon
> *tcon,
> > > > SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> > > > SUN4I_TCON1_BASIC5_H_SYNC(hsync));
> > > >
> > > > + /* Setup the polarity of sync signals */
> > > > + if (tcon->quirks->polarity_in_ch0) {
> > > > + val = 0;
> > > > +
> > > > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > > > + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> > > > +
> > > > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > > > + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> > > > +
> > > > + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> > > > + } else {
> > > > + val = SUN4I_TCON1_IO_POL_UNKNOWN;
> > >
> > > I think a comment for the origin of this is warranted.
> >
> > If it's anything like TCON0, it's the pixel clock polarity
>
> Hard to say, DW HDMI controller has "data enable" polarity along hsync and
> vsync. It could be either or none of those.
>
> What should I write in comment? BSP drivers and documentation use only generic
> names like io2_inv.
Just say that we don't know exactly what it is, but it is required for things
to work properly? Would be interesting to know what happens if you don't set
this bit, but do set VSYNC/HSYNC polarity properly.
ChenYu
Re: [linux-sunxi] [PATCH 5/5] drm/sun4i: dw-hdmi: Fix max. frequency for H6
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> It turns out that reasoning for lowering max. supported frequency is
> wrong. Scrambling works just fine. Several now fixed bugs prevented
> proper functioning, even with rates lower than 340 MHz. Issues were just
> more pronounced with higher frequencies.
>
> Fix that by allowing max. supported frequency in HW and fix the comment.
>
> Fixes: cd9063757a22 ("drm/sun4i: DW HDMI: Lower max. supported rate for H6")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH 4/5] drm/sun4i: Fix H6 HDMI PHY configuration
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> cpce value for 594 MHz is set differently in BSP driver. Fix that.
>
> Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Re: [PATCH 3/5] drm/sun4i: dw-hdmi: always set clock rate
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> As expected, HDMI controller clock should always match pixel clock. In
> the past, changing HDMI controller rate would seemingly worsen
> situation. However, that was the result of other bugs which are now
> fixed.
>
> Fix that by removing set_rate quirk and always set clock rate.
>
> Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI controller")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> Channel 1 has polarity bits for vsync and hsync signals but driver never
> sets them. It turns out that with pre-HDMI2 controllers seemingly there
> is no issue if polarity is not set. However, with HDMI2 controllers
> (H6) there often comes to de-synchronization due to phase shift. This
> causes flickering screen. It's safe to assume that similar issues might
> happen also with pre-HDMI2 controllers.
>
> Solve issue with setting vsync and hsync polarity. Note that display
> stacks with tcon top have polarity bits actually in tcon0 polarity
> register.
>
> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 6b9af4c08cd6..0d132dae58c0 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> SUN4I_TCON1_BASIC5_H_SYNC(hsync));
>
> + /* Setup the polarity of sync signals */
> + if (tcon->quirks->polarity_in_ch0) {
> + val = 0;
> +
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> +
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> +
> + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> + } else {
> + val = SUN4I_TCON1_IO_POL_UNKNOWN;
I think a comment for the origin of this is warranted.
Otherwise,
Reviewed-by: Chen-Yu Tsai
> +
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> + val |= SUN4I_TCON1_IO_POL_HSYNC_POSITIVE;
> +
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + val |= SUN4I_TCON1_IO_POL_VSYNC_POSITIVE;
> +
> + regmap_write(tcon->regs, SUN4I_TCON1_IO_POL_REG, val);
> + }
> +
> /* Map output pins to channel 1 */
> regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
>SUN4I_TCON_GCTL_IOMAP_MASK,
> @@ -1500,6 +1523,7 @@ static const struct sun4i_tcon_quirks
> sun8i_a83t_tv_quirks = {
>
> static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
> .has_channel_1 = true,
> + .polarity_in_ch0= true,
> .set_mux= sun8i_r40_tcon_tv_set_mux,
> };
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index c5ac1b02482c..b504fb2d3de5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -154,6 +154,10 @@
> #define SUN4I_TCON1_BASIC5_V_SYNC(height) (((height) - 1) &
> 0x3ff)
>
> #define SUN4I_TCON1_IO_POL_REG 0xf0
> +#define SUN4I_TCON1_IO_POL_UNKNOWN BIT(26)
> +#define SUN4I_TCON1_IO_POL_HSYNC_POSITIVE BIT(25)
> +#define SUN4I_TCON1_IO_POL_VSYNC_POSITIVE BIT(24)
> +
> #define SUN4I_TCON1_IO_TRI_REG 0xf4
>
> #define SUN4I_TCON_ECC_FIFO_REG0xf8
> @@ -236,6 +240,7 @@ struct sun4i_tcon_quirks {
> boolneeds_de_be_mux; /* sun6i needs mux to select backend */
> boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
> boolsupports_lvds; /* Does the TCON support an LVDS output? */
> + boolpolarity_in_ch0; /* some tcon1 channels have polarity bits in
> tcon0 pol register */
> u8 dclk_min_div; /* minimum divider for TCON0 DCLK */
>
> /* callback to handle tcon muxing options */
> --
> 2.30.0
>
Re: [linux-sunxi] [PATCH 1/5] clk: sunxi-ng: mp: fix parent rate change flag check
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> one. Fix that.
>
> Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when
> allowed")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
[PATCH 1/2] tools/power turbostat: Support Alder Lake P
Share the code between Alder Lake P and Alder Lake S. Tested-by: Wendy Wang Signed-off-by: Chen Yu --- tools/power/x86/turbostat/turbostat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index 389ea5209a83..34628e3e7099 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -4986,6 +4986,7 @@ unsigned int intel_model_duplicates(unsigned int model) case INTEL_FAM6_ROCKETLAKE: case INTEL_FAM6_LAKEFIELD: case INTEL_FAM6_ALDERLAKE: + case INTEL_FAM6_ALDERLAKE_L: return INTEL_FAM6_CANNONLAKE_L; case INTEL_FAM6_ATOM_TREMONT_L: -- 2.25.1
[PATCH 0/2] Add more CPUs support in turbostat
Alder Lake P and Ice Lake D are added in this patch set. Chen Yu (2): tools/power turbostat: Support Alder Lake Mobile tools/power turbostat: Support Ice Lake D tools/power/x86/turbostat/turbostat.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.25.1
[PATCH 2/2] tools/power turbostat: Support Ice Lake D
Ice Lake D is low-end server version of Ice Lake X, reuse the code accordingly. Tested-by: Wendy Wang Signed-off-by: Chen Yu --- tools/power/x86/turbostat/turbostat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index 34628e3e7099..d3c2ef91ac49 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -4993,6 +4993,7 @@ unsigned int intel_model_duplicates(unsigned int model) return INTEL_FAM6_ATOM_TREMONT; case INTEL_FAM6_ICELAKE_X: + case INTEL_FAM6_ICELAKE_D: case INTEL_FAM6_SAPPHIRERAPIDS_X: return INTEL_FAM6_SKYLAKE_X; } -- 2.25.1
Re: [linux-sunxi] Re: [PATCH v5 06/20] mfd: axp20x: Allow AXP chips without interrupt lines
On Thu, Jan 28, 2021 at 6:15 PM Maxime Ripard wrote: > > On Wed, Jan 27, 2021 at 05:24:46PM +, Andre Przywara wrote: > > Currently the AXP chip requires to have its IRQ line connected to some > > interrupt controller, and will fail probing when this is not the case. > > > > On a new Allwinner SoC (H616) there is no NMI pin anymore, and at > > least one board does not connect the AXP's IRQ pin to anything else, > > so the interrupt functionality of the AXP chip is simply not available. > > > > Check whether the interrupt line number returned by the platform code is > > valid, before trying to register the irqchip. If not, we skip this > > registration, to avoid the driver to bail out completely. > > > > Signed-off-by: Andre Przywara > > Acked-by: Maxime Ripard Acked-by: Chen-Yu Tsai
Re: [PATCH v5 14/20] dt-bindings: bus: rsb: Add H616 compatible string
On Thu, Jan 28, 2021 at 1:26 AM Andre Przywara wrote: > > Add the obvious compatible name to the existing RSB binding, and pair > it with the existing A23 fallback compatible string, as the devices are > compatible. > > Signed-off-by: Andre Przywara Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH v5 04/20] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
Hi, On Thu, Jan 28, 2021 at 1:26 AM Andre Przywara wrote: > > The AXP305 PMIC used in AXP805 seems to be fully compatible to the ^ This statement doesn't quite make sense. I assume you wanted to mention a board or the H616 SoC here? > AXP805 PMIC, so add the proper chain of compatible strings. > > Also at least on one board (Orangepi Zero2) there is no interrupt line > connected to the CPU, so make the "interrupts" property optional. > > Signed-off-by: Andre Przywara > --- > Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt > b/Documentation/devicetree/bindings/mfd/axp20x.txt > index 4991a6415796..4fd748101e3c 100644 > --- a/Documentation/devicetree/bindings/mfd/axp20x.txt > +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt > @@ -26,10 +26,10 @@ Required properties: > * "x-powers,axp803" > * "x-powers,axp806" > * "x-powers,axp805", "x-powers,axp806" > +* "x-powers,axp803", "x-powers,axp805", "x-powers,axp806" axp305? axp803 is used with A64 IIRC. ChenYu > * "x-powers,axp809" > * "x-powers,axp813" > - reg: The I2C slave address or RSB hardware address for the AXP chip > -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin > - interrupt-controller: The PMIC has its own internal IRQs > - #interrupt-cells: Should be set to 1 > > @@ -43,6 +43,7 @@ more information: > AXP20x/LDO3: software-based implementation > > Optional properties: > +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin > - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz > AXP152/20X: range: 750-1875, Default: 1.5 MHz > AXP22X/8XX: range: 1800-4050, Default: 3 MHz > -- > 2.17.5 > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/20210127172500.13356-5-andre.przywara%40arm.com.
Re: arm: sunxi: &83t: WARNING: CPU: 2 PID: 57 at drivers/thermal/thermal_core.c:563 thermal_zone_device_update
Hi, On Sun, Jan 31, 2021 at 12:54 AM Corentin Labbe wrote: > > Hello > > When booting next-20210128, I got the following warning on by bpim3 > 6.148421] [ cut here ] > [6.153145] WARNING: CPU: 2 PID: 57 at drivers/thermal/thermal_core.c:563 > thermal_zone_device_update+0x134/0x154 > [6.163378] 'thermal_zone_device_update' must not be called without > 'get_temp' ops set > [6.171300] Modules linked in: sha256_generic libsha256 > [6.176553] CPU: 2 PID: 57 Comm: kworker/2:1 Not tainted > 5.11.0-rc1-00042-gf3788af62cfe #399 > [6.184984] Hardware name: Allwinner A83t board > [6.189517] Workqueue: events deferred_probe_work_func > [6.194686] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [6.202438] [] (show_stack) from [] > (dump_stack+0x98/0xac) > [6.209666] [] (dump_stack) from [] (__warn+0xc0/0xd8) > [6.216545] [] (__warn) from [] > (warn_slowpath_fmt+0x98/0xc0) > [6.224030] [] (warn_slowpath_fmt) from [] > (thermal_zone_device_update+0x134/0x154) > [6.233426] [] (thermal_zone_device_update) from [] > (__thermal_cooling_device_register+0x334/0x35c) > [6.244204] [] (__thermal_cooling_device_register) from > [] (__cpufreq_cooling_register.constprop.0+0x184/0x294) > [6.256026] [] (__cpufreq_cooling_register.constprop.0) from > [] (of_cpufreq_cooling_register+0x40/0x7c) > [6.267153] [] (of_cpufreq_cooling_register) from [] > (cpufreq_online+0x2b4/0x8f4) > [6.276379] [] (cpufreq_online) from [] > (cpufreq_add_dev+0x6c/0x78) > [6.284383] [] (cpufreq_add_dev) from [] > (subsys_interface_register+0xa4/0xf0) > [6.293344] [] (subsys_interface_register) from [] > (cpufreq_register_driver+0x144/0x2dc) > [6.303169] [] (cpufreq_register_driver) from [] > (dt_cpufreq_probe+0x298/0x3b8) > [6.312215] [] (dt_cpufreq_probe) from [] > (platform_probe+0x5c/0xb8) > [6.320313] [] (platform_probe) from [] > (really_probe+0x1dc/0x3b8) > [6.328231] [] (really_probe) from [] > (driver_probe_device+0x5c/0xb4) > [6.336406] [] (driver_probe_device) from [] > (bus_for_each_drv+0x84/0xc8) > [6.344928] [] (bus_for_each_drv) from [] > (__device_attach+0xe8/0x154) > [6.353189] [] (__device_attach) from [] > (bus_probe_device+0x84/0x8c) > [6.361365] [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [6.370321] [] (deferred_probe_work_func) from [] > (process_one_work+0x1dc/0x438) > [6.379456] [] (process_one_work) from [] > (worker_thread+0x25c/0x55c) > [6.387632] [] (worker_thread) from [] > (kthread+0x124/0x150) > [6.395032] [] (kthread) from [] > (ret_from_fork+0x14/0x24) > [6.402256] Exception stack(0xc12d1fb0 to 0xc12d1ff8) > [6.407307] 1fa0: > > [6.415478] 1fc0: > > [6.423648] 1fe0: 0013 > [6.430301] ---[ end trace bd63a5c976f3611c ]--- > > I bisected the problem to > ARM: dts: sunxi: Remove thermal zones without trip points > > Reverting this commit remove the warning. The thermal subsystem seems to require a thermal zone be present for each thermal sensor that is registered. So maybe a better solution is not to remove the thermal zones without trip points, but just add the standard passive and critical trip points based on the SoC's thermal limits. ChenYu
Re: [PATCH v5 00/10] sunxi: Support IRQ wakeup from deep sleep
On Mon, Jan 25, 2021 at 6:56 PM Maxime Ripard wrote:
>
> On Sat, Jan 23, 2021 at 12:26:26AM -0600, Samuel Holland wrote:
> > On 1/22/21 4:47 AM, Maxime Ripard wrote:
> > > On Thu, Jan 21, 2021 at 07:33:54PM -0600, Samuel Holland wrote:
> > >> On 1/21/21 2:35 PM, Marc Zyngier wrote:
> > >>> On Sun, 17 Jan 2021 23:50:30 -0600, Samuel Holland wrote:
> > Allwinner sun6i/sun8i/sun50i SoCs (A31 and newer) have two interrupt
> > controllers: GIC and R_INTC. GIC does not support wakeup. R_INTC
> > handles
> > the external NMI pin, and provides 32+ IRQs to the ARISC. The first 16
> > of these correspond 1:1 to a block of GIC IRQs starting with the NMI.
> > The last 13-16 multiplex the first (up to) 128 GIC SPIs.
> >
> > This series replaces the existing chained irqchip driver that could
> > only
> > control the NMI, with a stacked irqchip driver that also provides
> > wakeup
> > capability for those multiplexed SPI IRQs. The idea is to preconfigure
> > the ARISC's IRQ controller, and then the ARISC firmware knows to wake
> > up
> > as soon as it receives an IRQ. It can also decide how deep it can
> > suspend based on the enabled wakeup IRQs.
> >
> > [...]
> > >>>
> > >>> Applied to irq/irqchip-5.12, thanks!
> > >>>
> > >>> [01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi
> > >>> commit: ad6b47cdef760410311f41876b21eb0c6fda4717
> > >>> [02/10] dt-bindings: irq: sun6i-r: Add a compatible for the H3
> > >>> commit: 6436eb4417094ea3308b33d8392fc02a1068dc78
> > >>> [03/10] irqchip/sun6i-r: Use a stacked irqchip driver
> > >>> commit: 4e34614636b31747b190488240a95647c227021f
> > >>> [04/10] irqchip/sun6i-r: Add wakeup support
> > >>> commit: 7ab365f6cd6de1e2b0cb1e1e3873dbf68e6f1003
> > >>>
> > >>> Please route the dts patches via the soc tree. Also, I had to
> > >>> manually fix the first patch as it wouldn't apply on top of
> > >>> 5.11-rc4 (which tree has it been diffed against?). Please
> > >>> check that the resolution is correct.
> > >>
> > >> This series was based on sunxi/for-next, which contains commit
> > >> 752b0aac99c7 ("dt-bindings: irq: sun7i-nmi: Add binding documentation
> > >> for the V3s NMI")[1].
> > >
> > > I assume merging the DT bits alone would break things? If so, I guess we
> > > can wait for 5.12 to be released before merging it
> >
> > Patch 5 does not depend on the new driver, so it could be merged at any
> > time. Yes, the remaining patches would break things if merged without
> > the driver.
>
> I've applied patch 5 then, could you send the rest of the DT patches
> when 5.13-rc1 is out?
I've put them in a for-5.13-late branch and merged them into for-next.
This should get a bit of boot testing via KernelCI. Maybe we'll get to
sending a late pull request for 5.13, maybe not.
ChenYu
Re: [PATCH] power: supply: axp20x_usb_power: Init work before enabling IRQs
On Sun, Jan 24, 2021 at 11:24 PM Samuel Holland wrote:
>
> The IRQ handler calls mod_delayed_work() on power->vbus_detect. However,
> that work item is not initialized until after the IRQs are enabled. If
> an IRQ is already pending when the driver is probed, the driver calls
> mod_delayed_work() on an uninitialized work item, which causes an oops.
>
> Fixes: bcfb7ae3f50b ("power: supply: axp20x_usb_power: Only poll while
> offline")
> Signed-off-by: Samuel Holland
> ---
> drivers/power/supply/axp20x_usb_power.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/axp20x_usb_power.c
> b/drivers/power/supply/axp20x_usb_power.c
> index 20817a49110b..02aba3da271a 100644
> --- a/drivers/power/supply/axp20x_usb_power.c
> +++ b/drivers/power/supply/axp20x_usb_power.c
> @@ -711,20 +711,21 @@ static int axp20x_usb_power_probe(struct
> platform_device *pdev)
> struct_size(power, irqs,
> axp_data->num_irq_names),
> GFP_KERNEL);
> if (!power)
> return -ENOMEM;
>
> platform_set_drvdata(pdev, power);
>
> power->axp20x_id = axp_data->axp20x_id;
> power->regmap = axp20x->regmap;
> power->num_irqs = axp_data->num_irq_names;
> + INIT_DELAYED_WORK(>vbus_detect, axp20x_usb_power_poll_vbus);
Nit:
Since axp20x_usb_power_poll_vbus() calls power_supply_changed() on
power->supply, it would make more sense to have INIT_DELAYED_WORK()
after devm_power_supply_register(), just so things are ordered correctly.
In practice this has no effect on the end result, since by the time the
interrupts are enabled the power supply would have been registered.
ChenYu
> if (power->axp20x_id == AXP202_ID) {
> /* Enable vbus valid checking */
> ret = regmap_update_bits(power->regmap, AXP20X_VBUS_MON,
> AXP20X_VBUS_MON_VBUS_VALID,
> AXP20X_VBUS_MON_VBUS_VALID);
> if (ret)
> return ret;
>
> if (IS_ENABLED(CONFIG_AXP20X_ADC))
> @@ -763,21 +764,20 @@ static int axp20x_usb_power_probe(struct
> platform_device *pdev)
> ret = devm_request_any_context_irq(>dev, power->irqs[i],
>axp20x_usb_power_irq, 0,
>DRVNAME, power);
> if (ret < 0) {
> dev_err(>dev, "Error requesting %s IRQ: %d\n",
> axp_data->irq_names[i], ret);
> return ret;
> }
> }
>
> - INIT_DELAYED_WORK(>vbus_detect, axp20x_usb_power_poll_vbus);
> if (axp20x_usb_vbus_needs_polling(power))
> queue_delayed_work(system_power_efficient_wq,
> >vbus_detect, 0);
>
> return 0;
> }
>
> static int axp20x_usb_power_remove(struct platform_device *pdev)
> {
> struct axp20x_usb_power *power = platform_get_drvdata(pdev);
>
> --
> 2.26.2
>
Re: [PATCH v2] ARM: dts: sun7i: a20: bananapro: Fix ethernet node
On Fri, Jan 22, 2021 at 3:54 AM Jernej Škrabec wrote: > > Dne četrtek, 21. januar 2021 ob 18:08:36 CET je Hermann Lauer napisal(a): > > BPi Pro needs TX and RX delay for Gbit to work reliable and avoid high > > packet loss rates. The realtek phy driver overrides the settings of the > > pull ups for the delays, so fix this for Banana Pro. > > > > Signed-off-by: Hermann Lauer > > Much better. Now the only thing missing is "Fixes" tag, which references > commit which introduced the issue. Probably this will be the commit which > added ethernet node. This tag is important for deciding which commits should > be backported to stable releases. Take a look in v1 for M2U fixes tag. > > Btw, each version should have changelog under "---" line, so maintainers and > reviewers know what changed. The subject line should also be more concise. "Fix ethernet phy-mode" reads much better than "Fix ethernet node", which could mean a number of things. ChenYu
[PATCH v4 4/4] arm64: dts: rockchip: rk3399: Add NanoPi M4B
From: Chen-Yu Tsai
The NanoPi M4B is a minor revision of the original M4.
The differences against the original Nanopi M4 that are common with the
other M4V2 revision include:
- microphone header removed
- power button added
- recovery button added
Additional changes specific to the M4B:
- USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x
USB 2.0 ports
- ADB toggle switch added; this changes the top USB 3.0 host port to
a peripheral port
- Type-C port no longer supports data or PD
- WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0
but only 1T1R (down from 2T2R) for WiFi
Add a new dts file for the new board revision that shows the difference
against the original.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index b29a445b355a..62d3abc17a24 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -34,6 +34,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-kobol-helios64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
new file mode 100644
index ..72182c58cc46
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPi M4B board device tree source
+ *
+ * Copyright (c) 2020 Chen-Yu Tsai
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi-m4.dts"
+
+/ {
+ model = "FriendlyElec NanoPi M4B";
+ compatible = "friendlyarm,nanopi-m4b", "rockchip,rk3399";
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <150>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+};
+
+/* No USB type-C PD power manager */
+/delete-node/
+
+ {
+ status = "disabled";
+};
+
+_host {
+ phy-supply = <_usb2>;
+};
+
+_otg {
+ phy-supply = <_typec>;
+};
+
+_otg {
+ phy-supply = <_usb1>;
+};
+
+_typec {
+ enable-active-high;
+ gpios = < RK_PD2 GPIO_ACTIVE_HIGH>;
+};
--
2.29.2
[PATCH v4 3/4] arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4
From: Chen-Yu Tsai
Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the
NanoPi M4 family, no such signal is routed to the expansion header on
the base board.
As the schematics for the expansion board were not released, it is
unclear how this is handled, but the likely answer is that the signal
is always pulled high.
Move the ep-gpios property from the common nanopi4.dtsi file to the
board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios,
matching the board design.
A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux
driver is required, as the driver currently requires the property to be
present.
Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4")
Reviewed-by: Robin Murphy
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts | 1 +
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
index e0d75617bb7e..452728b82e42 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
@@ -95,6 +95,7 @@ map3 {
};
{
+ ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
num-lanes = <4>;
vpcie3v3-supply = <_sys>;
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 76a8b40a93c6..48ed4aaa37f3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -504,7 +504,6 @@ _phy {
};
{
- ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
max-link-speed = <2>;
num-lanes = <2>;
vpcie0v9-supply = <_s3>;
--
2.29.2
[PATCH v4 2/4] dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B
From: Chen-Yu Tsai The NanoPi M4B is a minor revision of the original M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi Add a compatible string for the new board revision. Acked-by: Rob Herring Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 8a2dd9f1cff2..c3036f95c7bc 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -132,6 +132,7 @@ properties: - enum: - friendlyarm,nanopc-t4 - friendlyarm,nanopi-m4 + - friendlyarm,nanopi-m4b - friendlyarm,nanopi-neo4 - const: rockchip,rk3399 -- 2.29.2
[PATCH v4 0/4] arm64: rockchip: Fix PCIe ep-gpios requirement and Add Nanopi M4B
From: Chen-Yu Tsai Hi everyone, This is v4 of my Nanopi M4B series. Changes since v3 include: - Directly return dev_err_probe() instead of having a separate return statement Changes since v2 include: - Replaced dev_err() with dev_err_probe() for gpiod_get_optional() error - Added Reviewed-by tag from Robin Murphy for patch 3 Changes since v1 include: - Rewrite subject of patch 1 to match existing convention and reference 'ep-gpios' DT property instead of the 'ep_gpio' field This series mainly adds support for the new Nanopi M4B, which is a newer variant of the Nanopi M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi While working on this, I found that for the M4 family, the PCIe reset pin (from the M.2 expansion board) was not wired to the SoC. Only the NanoPC T4 has this wired. This ended up in patches 1 and 3. Patch 1 makes ep_gpio in the Rockchip PCIe driver optional. This property is optional in the DT binding, so this just makes the driver adhere to the binding. Patch 2 adds a new compatible string for the new board. Patch 3 moves the ep-gpios property of the pcie controller from the common nanopi4.dtsi file to the nanopc-t4.dts file. Patch 4 adds a new device tree file for the new board. It includes the original device tree for the M4, and then lists the differences. Given that patch 3 would make PCIe unusable without patch 1, I suggest merging patch 1 through the PCI tree as a fix for 5.11, and the rest for 5.12 through the Rockchip tree. Please have a look. The changes are mostly trivial. Regards ChenYu Chen-Yu Tsai (4): PCI: rockchip: Make 'ep-gpios' DT property optional dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4 arm64: dts: rockchip: rk3399: Add NanoPi M4B .../devicetree/bindings/arm/rockchip.yaml | 1 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 1 + .../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++ .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - drivers/pci/controller/pcie-rockchip.c| 9 ++-- 6 files changed, 59 insertions(+), 6 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts -- 2.29.2
[PATCH v4 1/4] PCI: rockchip: Make 'ep-gpios' DT property optional
From: Chen-Yu Tsai
The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is
an optional property. And indeed there are boards that don't require it.
Make the driver follow the binding by using devm_gpiod_get_optional()
instead of devm_gpiod_get().
Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
parse DT")
Signed-off-by: Chen-Yu Tsai
---
Changes since v3:
- Directly return dev_err_probe() instead of having a separate return
statement
Changes since v2:
- Fix error message for failed GPIO
Changes since v1:
- Rewrite subject to match existing convention and reference
'ep-gpios' DT property instead of the 'ep_gpio' field
---
drivers/pci/controller/pcie-rockchip.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip.c
b/drivers/pci/controller/pcie-rockchip.c
index 904dec0d3a88..a2ad0b7614a4 100644
--- a/drivers/pci/controller/pcie-rockchip.c
+++ b/drivers/pci/controller/pcie-rockchip.c
@@ -118,11 +118,10 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
}
if (rockchip->is_rc) {
- rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
- if (IS_ERR(rockchip->ep_gpio)) {
- dev_err(dev, "missing ep-gpios property in node\n");
- return PTR_ERR(rockchip->ep_gpio);
- }
+ rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
GPIOD_OUT_HIGH);
+ if (IS_ERR(rockchip->ep_gpio))
+ return dev_err_probe(dev, PTR_ERR(rockchip->ep_gpio),
+"failed to get ep GPIO\n");
}
rockchip->aclk_pcie = devm_clk_get(dev, "aclk");
--
2.29.2
Re: [PATCH v4 1/4] dt-bindings: usb: add rk3328 dwc3 docs
On Thu, Jan 21, 2021 at 12:30 PM Lindsey Stanpoor wrote: > > On Fri, Nov 6, 2020 at 11:42 PM Felipe Balbi wrote: > > > > > > Hi, > > > > Lindsey Stanpoor writes: > > > On Wed, Sep 2, 2020 at 11:12 AM wrote: > > >> > > >> From: Cameron Nemo > > >> > > >> Document compatible for dwc3 on the Rockchip rk3328 platform. > > > > > > Hi all, > > > > > > Wanted to give this patch submission a gentle ping. > > > > > > Rob Herring acked the documentation changes, but I have not heard > > > anything > > > from the USB or Rockchip maintainers. This patchset would facilitate USB3 > > > support for Rockchip rk3328 devices like the Pine Rock64. > > > > > > If there is anything I can do to help move this along, please let me know. > > > > Sorry, it had fallen through the cracks. It's now in my testing/next. > > Following up on this. Will this move out of your testing/next? The binding changes are likely stale now that the dwc3 binding has been converted to YAML. See Greg's USB tree. Also the DT changes should go through the arm-soc tree separately, so we can stack on additional changes enabling USB3 on other boards. ChenYu > -- > Cameron > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v3 1/4] PCI: rockchip: Make 'ep-gpios' DT property optional
On Tue, Jan 19, 2021 at 5:11 PM Heiko Stübner wrote:
>
> Am Mittwoch, 6. Januar 2021, 14:46:14 CET schrieb Chen-Yu Tsai:
> > From: Chen-Yu Tsai
> >
> > The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is
> > an optional property. And indeed there are boards that don't require it.
> >
> > Make the driver follow the binding by using devm_gpiod_get_optional()
> > instead of devm_gpiod_get().
> >
> > Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
> > Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
> > Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
> > parse DT")
> > Signed-off-by: Chen-Yu Tsai
> > ---
> > Heiko, I dropped you reviewed-by due to the error message change
> >
> > Changes since v2:
> > - Fix error message for failed GPIO
> >
> > Changes since v1:
> > - Rewrite subject to match existing convention and reference
> > 'ep-gpios' DT property instead of the 'ep_gpio' field
> > ---
> > drivers/pci/controller/pcie-rockchip.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-rockchip.c
> > b/drivers/pci/controller/pcie-rockchip.c
> > index 904dec0d3a88..90c957e3bc73 100644
> > --- a/drivers/pci/controller/pcie-rockchip.c
> > +++ b/drivers/pci/controller/pcie-rockchip.c
> > @@ -118,9 +118,10 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie
> > *rockchip)
> > }
> >
> > if (rockchip->is_rc) {
> > - rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
> > + rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
> > GPIOD_OUT_HIGH);
> > if (IS_ERR(rockchip->ep_gpio)) {
> > - dev_err(dev, "missing ep-gpios property in node\n");
> > + dev_err_probe(dev, PTR_ERR(rockchip->ep_gpio),
> > + "failed to get ep GPIO\n");
> > return PTR_ERR(rockchip->ep_gpio);
>
> looking at [0] shouldn't that be just
> return dev_err_probe(dev, PTR_ERR(.)...);
> instead of dev_err_probe + additional return?
You're right. I was only expecting dev_err_probe() to deal with -EPROBE_DEFER.
I believe there won't be any future changes that would add any code here,
so I'll respin with the proper changes you mentioned.
Thanks!
ChenYu
> Heiko
>
> [0] https://elixir.bootlin.com/linux/latest/source/drivers/base/core.c#L4223
>
> > }
> > }
> >
>
>
>
>
Re: [PATCH v3 0/4] arm64: rockchip: Fix PCIe ep-gpios requirement and Add Nanopi M4B
Hi, On Wed, Jan 6, 2021 at 9:46 PM Chen-Yu Tsai wrote: > > From: Chen-Yu Tsai > > Hi everyone, > > This is v3 of my Nanopi M4B series. Changes since v2 include: > > - Replaced dev_err() with dev_err_probe() for gpiod_get_optional() error > - Added Reviewed-by tag from Robin Murphy for patch 3 > > Changes since v1 include: > > - Rewrite subject of patch 1 to match existing convention and reference > 'ep-gpios' DT property instead of the 'ep_gpio' field > > This series mainly adds support for the new Nanopi M4B, which is a newer > variant of the Nanopi M4. > > The differences against the original Nanopi M4 that are common with the > other M4V2 revision include: > > - microphone header removed > - power button added > - recovery button added > > Additional changes specific to the M4B: > > - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x > USB 2.0 ports > - ADB toggle switch added; this changes the top USB 3.0 host port to > a peripheral port > - Type-C port no longer supports data or PD > - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 > but only 1T1R (down from 2T2R) for WiFi > > While working on this, I found that for the M4 family, the PCIe reset > pin (from the M.2 expansion board) was not wired to the SoC. Only the > NanoPC T4 has this wired. This ended up in patches 1 and 3. > > Patch 1 makes ep_gpio in the Rockchip PCIe driver optional. This property > is optional in the DT binding, so this just makes the driver adhere to > the binding. > > Patch 2 adds a new compatible string for the new board. > > Patch 3 moves the ep-gpios property of the pcie controller from the > common nanopi4.dtsi file to the nanopc-t4.dts file. > > Patch 4 adds a new device tree file for the new board. It includes the > original device tree for the M4, and then lists the differences. > > Given that patch 3 would make PCIe unusable without patch 1, I suggest > merging patch 1 through the PCI tree as a fix for 5.10, and the rest > for 5.11 through the Rockchip tree. Gentle ping. I would really like to get the PCIe controller fix merged before -rc6 (cut-off for arm-soc -next) and be able to get the new board into 5.12. Or we could have all of them merged for 5.12, though depending on the order the PRs are sent and merged by Linus there would be a possible window where PCIe doesn't work for the Nanopi M4's. Thanks ChenYu > Please have a look. The changes are mostly trivial. > > > Regards > ChenYu > > Chen-Yu Tsai (4): > PCI: rockchip: Make 'ep-gpios' DT property optional > dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B > arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4 > arm64: dts: rockchip: rk3399: Add NanoPi M4B > > .../devicetree/bindings/arm/rockchip.yaml | 1 + > arch/arm64/boot/dts/rockchip/Makefile | 1 + > .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 1 + > .../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++ > .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - > drivers/pci/controller/pcie-rockchip.c| 5 +- > 6 files changed, 58 insertions(+), 3 deletions(-) > create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts > > -- > 2.29.2 >
Re: [linux-sunxi] Re: [PATCH v3 02/21] mmc: sunxi: add support for A100 mmc controller
On Mon, Jan 18, 2021 at 11:53 PM Andre Przywara wrote: > > On Mon, 18 Jan 2021 14:28:54 +0100 > Maxime Ripard wrote: > > Hi Maxime, > > > On Mon, Jan 18, 2021 at 02:08:29AM +, Andre Przywara wrote: > > > From: Yangtao Li > > > > > > This patch adds support for A100 MMC controller, which use word > > > address for internal dma. > > > > > > Signed-off-by: Yangtao Li > > > Signed-off-by: Andre Przywara > > > > We should also disable the timings setup in probe to derive them from > > the DT. This is causing issues on some SoCs already, so it would be > > best to not make the situation worse > > But only for those new SoCs, where we have the speed modes in the DT > in every case (so only new ones)? And this disabling would be > SoC/compatible string dependent? Happy to send a patch later if that is > what you were thinking about. > > Also I was wondering about the voltage dependent speed modes: At the > moment the driver declares both MMC_CAP_1_8V_DDR and MMC_CAP_3_3V_DDR, > so I mimic this in the .dtsi. However in the eventual DTB this looks > somewhat dodgy, since most boards only support one of those voltages. Do > we ignore this, and rely on the vqmmc-supply to limit this choice? IIRC the DDR flags for separate voltages was added after we (I) added MMC DDR support to our driver. And yes, the core also checks vqmmc-supply before actually selecting the mode. ChenYu > Cheers, > Andre > > Btw: This patch is already in Ulf's -next tree, I just included it here > for the sake of completeness. Is that a problem? I don't think it > affects the build, so we don't care too much? > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/20210118155228.3bd0e909%40slackpad.fritz.box.
Re: [linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection
On Wed, Jan 13, 2021 at 5:16 PM Chen-Yu Tsai wrote: > > On Thu, Jan 7, 2021 at 6:27 PM Samuel Holland wrote: > > > > On 1/6/21 5:38 AM, Chen-Yu Tsai wrote: > > > On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard wrote: > > >> > > >> On Mon, Jan 04, 2021 at 10:54:19AM +, André Przywara wrote: > > >>> On 03/01/2021 10:00, Samuel Holland wrote: > > >>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers > > >>>> PMIC, configure the connection to use the RSB bus rather than the I2C > > >>>> bus. Compared to the I2C controller that shares the pins, the RSB > > >>>> controller allows a higher bus frequency, and it is more CPU-efficient. > > >>> > > >>> But is it really necessary to change the DTs for those boards in this > > >>> way? It means those newer DTs now become incompatible with older > > >>> kernels, and I don't know if those reasons above really justify this. > > >>> > > >>> I understand that we officially don't care about "newer DTs on older > > >>> kernels", but do we really need to break this deliberately, for no > > >>> pressing reasons? > > >>> > > >>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > > >>> just want to avoid breaking existing ones. > > >> > > >> Doing so would also introduce some inconsistencies, one more thing to > > >> consider during reviews, and would require more testing effort. > > >> > > >> I'm not sure that stretching our - already fairly sparse - resources > > >> thin would be very wise here, especially for something that we don't > > >> have to do and for a setup that isn't really used that much. > > > > > > As soon as some software component starts running RSB, (which I assume > > > is what Samuel is planning to do in Crust?), there's a chance that it > > > doesn't switch the chip back to I2C. And then Linux won't be able to > > > access it. > > > > Crust can handle either way via a config option, which currently > > defaults to I2C for H6. It must use the same selection as Linux, not > > only because of the PMIC mode, but also because of the pinctrl. > > Could Crust be made to also handle pinctrl? > > > TF-A is already converted to use RSB[1], and it does switch the PMIC > > back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is > > fine. However, Linux currently does not switch the PMIC back. So the > > most likely problem from this patch is that, with new Linux + old TF-A, > > TF-A will be unable to power down the board or access regulators after > > an SoC reset. > > > > I expect there will be a TF-A release between now and when 5.12 hits > > stable, but people tend not upgrade their U-Boot/TF-A very often. > > > > We could solve this by having the Linux RSB driver switch all child > > devices back to I2C in .shutdown, or by dropping this patch and only > > using RSB for new boards (which would also address Andre's concern). > > This will work for most cases, except in a kernel panic or IIRC direct > reboot using sysrq. So it's not robust as we'd like it to be. I also wonder what would happen when there are multiple RSB devices, and we switch them back to I2C one by one. It's not like there's an option to switch all of them back at the same time, unlike switching from I2C to RSB. The A80 and A83T are the platforms that would be affected. So I merged the previous patch, i.e. changes to the .dtsi, but I think we should delay this one by a release. That would give us more time to think about it, and let users upgrade U-Boot/TF-A. ChenYu > ChenYu > > > Cheers, > > Samuel > > > > [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576 > > [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575 > > > > > So I'm for keeping things consistent and converting all users to RSB. > > > > > > > > > ChenYu > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "linux-sunxi" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to linux-sunxi+unsubscr...@googlegroups.com. > > To view this discussion on the web, visit > > https://groups.google.com/d/msgid/linux-sunxi/bc95a8d2-ebec-489c-10af-fd5a80ea1276%40sholland.org.
Re: [PATCH] ARM: dts: sun8i-v3s: Add CSI0 MCLK pin definition
On Wed, Dec 30, 2020 at 11:29 AM Chen-Yu Tsai wrote: > > On Tue, Dec 22, 2020 at 4:17 PM Jernej Škrabec > wrote: > > > > Hi! > > > > Dne petek, 18. december 2020 ob 20:50:33 CET je Paul Kocialkowski > > napisal(a): > > > This adds a device-tree definition for the CSI0 MCLK pin, > > > which can be used for feeding MIPI CSI-2 sensors. > > > > > > Signed-off-by: Paul Kocialkowski > > > > Is this used anywhere? Current policy is to add pin definitions only if any > > user exists. > > IIRC we sort of loosened that requirement with the use of /omit-if-no-ref/. > The A20 dtsi file has a whole bunch of pins defined that are not directly > used but are available for users to reference, especially in overlays. > The "-@" parameter for the device tree compiler, used to build overlay > compatible DTBs, makes the compiler ignore /omit-if-no-ref/ and include > all the nodes. I've queued up this patch for 5.12. ChenYu
[PATCH v2 2/3] dt-bindings: arm: rockchip: Add Radxa ROCK Pi E
From: Chen-Yu Tsai Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page puts it, "E for Ethernets". It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both directly served by Ethernet controllers in the SoC, a USB 3.0 host port, a power-only USB type-C port, a 3.5mm headphone jack for audio output, two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT and PoE header. The board comes in multiple configurations, differing in the amount of onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants can all share the same device tree. The USB 2.0 OTG controller is available on the 40-pin header. This is not enabled in the device tree, since it is possible to use it in a host-only configuration, or in OTG mode with an extra pin from the header as the ID pin. The device tree is based on the one of the Rock64, with various parts modified to match the ROCK Pi E, and some parts updated to newer styles, such as the gmac2io node's mdio sub-node. Add a compatible string for the new board. Acked-by: Rob Herring Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 773fd4c531ed..c3036f95c7bc 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -468,6 +468,11 @@ properties: - const: radxa,rockpi4 - const: rockchip,rk3399 + - description: Radxa ROCK Pi E +items: + - const: radxa,rockpi-e + - const: rockchip,rk3328 + - description: Radxa ROCK Pi N8 items: - const: radxa,rockpi-n8 -- 2.29.2
[PATCH v2 1/3] arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node
From: Chen-Yu Tsai
The gmac2phy is integrated with the PHY within the SoC. Any properties
related to this integration can be included in the .dtsi file, instead
of having board dts files specify them separately.
Add the clock_in_out property to specify the direction of the PHY clock.
This is the minimum required to have gmac2phy working on Linux. Other
examples include assigned-clocks, assigned-clock-rates, and
assigned-clock-parents properties, but the hardware default plus the
implementation requesting the appropriate clock rate also works.
Fixes: 9c4cc910fe28 ("ARM64: dts: rockchip: Add gmac2phy node support for
rk3328")
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index db0d5c8e5f96..93c734d8a46c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -928,6 +928,7 @@ gmac2phy: ethernet@ff55 {
phy-mode = "rmii";
phy-handle = <>;
snps,txpbl = <0x4>;
+ clock_in_out = "output";
status = "disabled";
mdio {
--
2.29.2
[PATCH v2 0/3] arm64: rockchip: rk3328: Add Radxa ROCK Pi E
From: Chen-Yu Tsai Hi everyone, This is v2 of my ROCK Pi E support series. Changes since v1: - Picked up Rob's Ack for the binding - Dropped comment about LED color - Dropped max-frequency from emmc node - Changed pingroup name from "ethernet-phy" to "ephy" to avoid DT binding check failure - Dropped cap-mmc-highspeed from sdmmc node - Fixed regulator properties to have consistent ordering - Added adc-key for recovery button - Sorted header files This series adds support for the Radxa ROCK Pi E. This is a router oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page puts it, "E for Ethernets". It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both directly served by Ethernet controllers in the SoC, a USB 3.0 host port, a power-only USB type-C port, a 3.5mm headphone jack for audio output, two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT and PoE header. The board comes in multiple configurations, differing in the amount of onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants can all share the same device tree. Currently, the 802.11ac chip lacks an in-kernel driver. The USB 2.0 OTG controller is available on the 40-pin header. This is not enabled in the device tree, since it is possible to use it in a host-only configuration, or in OTG mode with an extra pin from the header as the ID pin. The device tree is based on the one of the Rock64, with various parts modified to match the ROCK Pi E, and some parts updated to newer styles, such as the gmac2io node's mdio sub-node. Patch 1 adds the clock_in_out property to the gmac2phy node. This would always have the same setting for gmac2phy, which uses an integrated PHY in RMII mode. Having this set by default makes enabling gmac2phy at the board level simpler. Patch 2 adds a compatible string for this board to the list of Rockchip based devices. Patch 3 adds a device tree file for this board. This is based on the one for the Rock64, with many modifications to adapt it to the new board, as well as style updates. Please have a look. Regards ChenYu Chen-Yu Tsai (3): arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node dt-bindings: arm: rockchip: Add Radxa ROCK Pi E arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E .../devicetree/bindings/arm/rockchip.yaml | 5 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 382 ++ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 + 4 files changed, 389 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts -- 2.29.2
[PATCH v2 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
From: Chen-Yu Tsai
Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
As the official wiki page puts it, "E for Ethernets".
It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
a power-only USB type-C port, a 3.5mm headphone jack for audio output,
two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
and PoE header.
The board comes in multiple configurations, differing in the amount of
onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
can all share the same device tree.
The USB 2.0 OTG controller is available on the 40-pin header. This is
not enabled in the device tree, since it is possible to use it in a
host-only configuration, or in OTG mode with an extra pin from the
header as the ID pin.
The device tree is based on the one of the Rock64, with various parts
modified to match the ROCK Pi E, and some parts updated to newer styles,
such as the gmac2io node's mdio sub-node.
Add a new device tree file for the new board.
The voltages for the adc-keys were selected to have some tolerances for
resistor variances and the ADC itself also causing voltage drops. Since
the recover button is the only button on the adc line, this should not
cause any issues.
Signed-off-by: Chen-Yu Tsai
---
Changes since v1:
- Dropped comment about LED color
- Dropped max-frequency from emmc node
- Changed pingroup name from "ethernet-phy" to "ephy"
to avoid DT binding check failure
- Dropped cap-mmc-highspeed from sdmmc node
- Fixed regulator properties to have consistent ordering
- Added adc-key for recovery button
- Sorted header files
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3328-rock-pi-e.dts| 382 ++
2 files changed, 383 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 622d320ddd13..62d3abc17a24 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
new file mode 100644
index ..2d71ca7e429c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * (C) Copyright 2020 Chen-Yu Tsai
+ *
+ * Based on ./rk3328-rock64.dts, which is
+ *
+ * Copyright (c) 2017 PINE64
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include
+
+#include "rk3328.dtsi"
+
+/ {
+ model = "Radxa ROCK Pi E";
+ compatible = "radxa,rockpi-e", "rockchip,rk3328";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <175>;
+
+ /* This button is unpopulated out of the factory. */
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <1>;
+ };
+ };
+
+ gmac_clkin: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_clkin";
+ #clock-cells = <0>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <_pin>;
+ pinctrl-names = "default";
+
+ led-0 {
+ color = ;
+ gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+ regulator-name = "vcc_sd";
+ regulator-boot-on;
+ vin-supply
Re: [PATCH] ARM: dts: sun8i: h2-plus: bananapi-m2-zero: Increase BT UART speed
On Sat, Jan 16, 2021 at 6:37 PM Jernej Skrabec wrote: > > Bluetooth module on BananaPi M2 Zero can also be used for streaming > audio. However, for that case higher UART speed is required. > > Add a max-speed property. > > Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: bananapi-m2-plus: Increase BT UART speed
On Sat, Jan 16, 2021 at 6:52 PM Jernej Skrabec wrote: > > Bluetooth module on BananaPi M2 Plus can also be used for streaming > audio. However, for that case higher UART speed is required. > > Add a max-speed property. > > Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection
On Thu, Jan 7, 2021 at 6:27 PM Samuel Holland wrote: > > On 1/6/21 5:38 AM, Chen-Yu Tsai wrote: > > On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard wrote: > >> > >> On Mon, Jan 04, 2021 at 10:54:19AM +, André Przywara wrote: > >>> On 03/01/2021 10:00, Samuel Holland wrote: > >>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers > >>>> PMIC, configure the connection to use the RSB bus rather than the I2C > >>>> bus. Compared to the I2C controller that shares the pins, the RSB > >>>> controller allows a higher bus frequency, and it is more CPU-efficient. > >>> > >>> But is it really necessary to change the DTs for those boards in this > >>> way? It means those newer DTs now become incompatible with older > >>> kernels, and I don't know if those reasons above really justify this. > >>> > >>> I understand that we officially don't care about "newer DTs on older > >>> kernels", but do we really need to break this deliberately, for no > >>> pressing reasons? > >>> > >>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > >>> just want to avoid breaking existing ones. > >> > >> Doing so would also introduce some inconsistencies, one more thing to > >> consider during reviews, and would require more testing effort. > >> > >> I'm not sure that stretching our - already fairly sparse - resources > >> thin would be very wise here, especially for something that we don't > >> have to do and for a setup that isn't really used that much. > > > > As soon as some software component starts running RSB, (which I assume > > is what Samuel is planning to do in Crust?), there's a chance that it > > doesn't switch the chip back to I2C. And then Linux won't be able to > > access it. > > Crust can handle either way via a config option, which currently > defaults to I2C for H6. It must use the same selection as Linux, not > only because of the PMIC mode, but also because of the pinctrl. Could Crust be made to also handle pinctrl? > TF-A is already converted to use RSB[1], and it does switch the PMIC > back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is > fine. However, Linux currently does not switch the PMIC back. So the > most likely problem from this patch is that, with new Linux + old TF-A, > TF-A will be unable to power down the board or access regulators after > an SoC reset. > > I expect there will be a TF-A release between now and when 5.12 hits > stable, but people tend not upgrade their U-Boot/TF-A very often. > > We could solve this by having the Linux RSB driver switch all child > devices back to I2C in .shutdown, or by dropping this patch and only > using RSB for new boards (which would also address Andre's concern). This will work for most cases, except in a kernel panic or IIRC direct reboot using sysrq. So it's not robust as we'd like it to be. ChenYu > Cheers, > Samuel > > [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576 > [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575 > > > So I'm for keeping things consistent and converting all users to RSB. > > > > > > ChenYu > > > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/bc95a8d2-ebec-489c-10af-fd5a80ea1276%40sholland.org.
Re: [linux-sunxi] [PATCH] arm64: dts: allwinner: h6: PineH64 model B: Add bluetooth
On Mon, Jan 11, 2021 at 5:16 AM Jernej Skrabec wrote: > > PineH64 model B has wifi+bt combo module. Wifi is already supported, so > lets add also bluetooth node. > > Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Looks good to me, though I couldn't find anything on the polarity of the interrupt lines. ChenYu
Re: [PATCH][v3] cpufreq: intel_pstate: Get percpu max freq via HWP MSR register if available
On Tue, Jan 12, 2021 at 02:52:50PM +0100, Rafael J. Wysocki wrote: > On Tue, Jan 12, 2021 at 6:19 AM Chen Yu wrote: > > > > Currently when turbo is disabled(either by BIOS or by the user), the > > intel_pstate driver reads the max non-turbo frequency from the package-wide > > MSR_PLATFORM_INFO(0xce) register. However on asymmetric platforms it is > > possible in theory that small and big core with HWP enabled might have > > different max non-turbo cpu frequency, because the MSR_HWP_CAPABILITIES > > is percpu scope according to Intel Software Developer Manual. > > > > The turbo max freq is already percpu basis in current code, thus make > > similar change to the max non-turbo frequency as well. > > > > Reported-by: Wendy Wang > > Signed-off-by: Chen Yu > > --- > > v2: Per Srinivas' suggestion, avoid duplicated assignment of max_pstate. > > v3: Per Rafael's suggestion, do not add new argument in > > intel_pstate_get_hwp_max() > > to avoid redundant local vars. > > Per Srinivas' suggestion, refined the commit log to reflect the > > 'non-turbo' > > max frequency. > > Looks good now, thanks! > > Is it needed in -stable and if so, which -stable series should it go into? > Yes, I think so, it should be Cc: sta...@vger.kernel.org # 4.18+ as the HWP reading turbo frequency was firstly introduced in v4.18-rc2 and it was easier to be applied. BTW, this patch is on top of your previous patch set on intel_pstate clean up: https://patchwork.kernel.org/project/linux-pm/list/?series=410797 thanks, Chenyu
Re: [PATCH v3 2/4] dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B
On Wed, Jan 6, 2021 at 9:46 PM Chen-Yu Tsai wrote: > > From: Chen-Yu Tsai > > The NanoPi M4B is a minor revision of the original M4. > > The differences against the original Nanopi M4 that are common with the > other M4V2 revision include: > > - microphone header removed > - power button added > - recovery button added > > Additional changes specific to the M4B: > > - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x > USB 2.0 ports > - ADB toggle switch added; this changes the top USB 3.0 host port to > a peripheral port > - Type-C port no longer supports data or PD > - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 > but only 1T1R (down from 2T2R) for WiFi > > Add a compatible string for the new board revision. > > Signed-off-by: Chen-Yu Tsai This was Acked-by: Rob Herring back in v2.
[PATCH][v3] cpufreq: intel_pstate: Get percpu max freq via HWP MSR register if available
Currently when turbo is disabled(either by BIOS or by the user), the
intel_pstate driver reads the max non-turbo frequency from the package-wide
MSR_PLATFORM_INFO(0xce) register. However on asymmetric platforms it is
possible in theory that small and big core with HWP enabled might have
different max non-turbo cpu frequency, because the MSR_HWP_CAPABILITIES
is percpu scope according to Intel Software Developer Manual.
The turbo max freq is already percpu basis in current code, thus make
similar change to the max non-turbo frequency as well.
Reported-by: Wendy Wang
Signed-off-by: Chen Yu
---
v2: Per Srinivas' suggestion, avoid duplicated assignment of max_pstate.
v3: Per Rafael's suggestion, do not add new argument in
intel_pstate_get_hwp_max()
to avoid redundant local vars.
Per Srinivas' suggestion, refined the commit log to reflect the 'non-turbo'
max frequency.
--
drivers/cpufreq/intel_pstate.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index eaf32ef7a030..99e180f644c3 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1724,11 +1724,9 @@ static void intel_pstate_max_within_limits(struct
cpudata *cpu)
static void intel_pstate_get_cpu_pstates(struct cpudata *cpu)
{
cpu->pstate.min_pstate = pstate_funcs.get_min();
- cpu->pstate.max_pstate = pstate_funcs.get_max();
cpu->pstate.max_pstate_physical = pstate_funcs.get_max_physical();
cpu->pstate.turbo_pstate = pstate_funcs.get_turbo();
cpu->pstate.scaling = pstate_funcs.get_scaling();
- cpu->pstate.max_freq = cpu->pstate.max_pstate * cpu->pstate.scaling;
if (hwp_active && !hwp_mode_bdw) {
unsigned int phy_max, current_max;
@@ -1736,9 +1734,12 @@ static void intel_pstate_get_cpu_pstates(struct cpudata
*cpu)
intel_pstate_get_hwp_max(cpu, _max, _max);
cpu->pstate.turbo_freq = phy_max * cpu->pstate.scaling;
cpu->pstate.turbo_pstate = phy_max;
+ cpu->pstate.max_pstate =
HWP_GUARANTEED_PERF(READ_ONCE(cpu->hwp_cap_cached));
} else {
cpu->pstate.turbo_freq = cpu->pstate.turbo_pstate *
cpu->pstate.scaling;
+ cpu->pstate.max_pstate = pstate_funcs.get_max();
}
+ cpu->pstate.max_freq = cpu->pstate.max_pstate * cpu->pstate.scaling;
if (pstate_funcs.get_aperf_mperf_shift)
cpu->aperf_mperf_shift = pstate_funcs.get_aperf_mperf_shift();
--
2.17.1
Re: [PATCH 2/2][v2] cpufreq: intel_pstate: Get percpu max freq via HWP MSR register if available
On Mon, Jan 11, 2021 at 03:11:02AM -0800, Srinivas Pandruvada wrote: > On Mon, 2021-01-11 at 15:43 +0800, Chen Yu wrote: > > Currently when turbo is disabled(either by BIOS or by the user), the > > intel_pstate > > driver reads the max frequency from the package-wide > > MSR_PLATFORM_INFO(0xce) register. > > However on asymmetric platforms it is possible in theory that small > > and big core with > > HWP enabled might have different max cpu frequency > max non-turbo frequency (although code call max_freq). > Okay, will change. Thanks, Chenyu > Thanks, > Srinivas >
Re: [PATCH 1/2][v2] cpufreq: intel_pstate: Add parameter to get guarantee frequency
On Mon, Jan 11, 2021 at 01:44:09PM +0100, Rafael J. Wysocki wrote: > On Mon, Jan 11, 2021 at 8:40 AM Chen Yu wrote: > > > > Add input parameter to receive guarantee pstate from > > intel_pstate_get_hwp_max() > > for later use. > > I'm not a fan of this change, because the new argument will only be > needed in one place where intel_pstate_get_hwp_max() and it requires > adding redundant local vars and pointless updates elsewhere. > > Besides, in intel_pstate_get_cpu_pstates() you can do something like > this after calling intel_pstate_get_hwp_max(): > > cpu->pstate.max_pstate = HWP_GUARANTEED_PERF(READ_ONCE(cpu->hwp_cap_cached)); > cpu->pstate.max_freq = cpu->pstate.max_pstate * cpu->pstate.scaling; Okay, will do in next version. Thanks, Chenyu
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
On Mon, Jan 11, 2021 at 3:50 PM Heiko Stübner wrote:
>
> Am Montag, 11. Januar 2021, 04:27:47 CET schrieb Chen-Yu Tsai:
> > On Mon, Jan 11, 2021 at 4:06 AM Heiko Stübner wrote:
> > >
> > > Hi,
> > >
> > > Am Sonntag, 10. Januar 2021, 16:37:15 CET schrieb Chen-Yu Tsai:
> > > > > > + vcc_sd: sdmmc-regulator {
> > > > > > + compatible = "regulator-fixed";
> > > > > > + gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
> > > > > > + pinctrl-names = "default";
> > > > > > + pinctrl-0 = <_pin>;
> > > > >
> > > > > > + regulator-boot-on;
> > > > > > + regulator-name = "vcc_sd";
> > > > >
> > > > > regulator-name above other regulator properties
> > > >
> > > > That is actually what I was used to, but some other rockchip dts files
> > > > have all the properties sorted alphabetically. So I stuck with what I
> > > > saw.
> > >
> > > I try to keep it alphabetical except for the exceptions :-D .
> > >
> > > regulator-name is such an exception. Similar to compatibles, the
> > > regulator-name is an entry needed to see if you're at the right node,
> > > so I really like it being the topmost regulator-foo property - just makes
> > > reading easier.
> > >
> > > (same for the compatible first, then regs, interrupts parts, as well
> > > as "status-last")
> > >
> > > But oftentimes, I just fix the ordering when applying - but seem to have
> > > missed this somewhere in those "other Rockchip dts files" ;-) .
> >
> > I was slightly confused. I looked again and yes regulator-name is always the
> > first regulator related property. What's off is that in some cases min/max
> > voltage comes before always-on/boot-on, and in others vice versa.
> >
> > For example in the Rock64 and ROC-RK3328-CC device trees, in the fixed
> > regulators, always-on/boot-on come before min/max voltage, while in the
> > PMIC the other order is used.
>
> That's likely undecidednes on my part ;-)
>
> There could be an argument for a "name, voltages, flags" sorting, but on
> the other hand just keeping it alphabetical with the naming on top
> creates less special cases.
And min before max? :D
[PATCH 2/2][v2] cpufreq: intel_pstate: Get percpu max freq via HWP MSR register if available
Currently when turbo is disabled(either by BIOS or by the user), the
intel_pstate
driver reads the max frequency from the package-wide MSR_PLATFORM_INFO(0xce)
register.
However on asymmetric platforms it is possible in theory that small and big
core with
HWP enabled might have different max cpu frequency, because the
MSR_HWP_CAPABILITIES
is percpu scope according to Intel Software Developer Manual.
The turbo max freq is already percpu basis in current code, thus make similar
change
to the max non-turbo frequency as well.
Reported-by: Wendy Wang
Signed-off-by: Chen Yu
---
v2: per Srinivas' suggestion, avoid duplicated assignment of max_pstate.
--
drivers/cpufreq/intel_pstate.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index bd3dd1be73ba..f2d18991d969 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1725,11 +1725,9 @@ static void intel_pstate_max_within_limits(struct
cpudata *cpu)
static void intel_pstate_get_cpu_pstates(struct cpudata *cpu)
{
cpu->pstate.min_pstate = pstate_funcs.get_min();
- cpu->pstate.max_pstate = pstate_funcs.get_max();
cpu->pstate.max_pstate_physical = pstate_funcs.get_max_physical();
cpu->pstate.turbo_pstate = pstate_funcs.get_turbo();
cpu->pstate.scaling = pstate_funcs.get_scaling();
- cpu->pstate.max_freq = cpu->pstate.max_pstate * cpu->pstate.scaling;
if (hwp_active && !hwp_mode_bdw) {
unsigned int phy_max, current_max, guar_state;
@@ -1737,8 +1735,12 @@ static void intel_pstate_get_cpu_pstates(struct cpudata
*cpu)
intel_pstate_get_hwp_max(cpu, _max, _max,
_state);
cpu->pstate.turbo_freq = phy_max * cpu->pstate.scaling;
cpu->pstate.turbo_pstate = phy_max;
+ cpu->pstate.max_pstate = guar_state;
+ cpu->pstate.max_freq = guar_state * cpu->pstate.scaling;
} else {
cpu->pstate.turbo_freq = cpu->pstate.turbo_pstate *
cpu->pstate.scaling;
+ cpu->pstate.max_pstate = pstate_funcs.get_max();
+ cpu->pstate.max_freq = cpu->pstate.max_pstate *
cpu->pstate.scaling;
}
if (pstate_funcs.get_aperf_mperf_shift)
--
2.17.1
[PATCH 1/2][v2] cpufreq: intel_pstate: Add parameter to get guarantee frequency
Add input parameter to receive guarantee pstate from intel_pstate_get_hwp_max()
for later use.
No functional change intended.
Signed-off-by: Chen Yu
---
drivers/cpufreq/intel_pstate.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index eaf32ef7a030..bd3dd1be73ba 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -830,7 +830,7 @@ static struct freq_attr *hwp_cpufreq_attrs[] = {
};
static void intel_pstate_get_hwp_max(struct cpudata *cpu, int *phy_max,
-int *current_max)
+int *current_max, int *guar_max)
{
u64 cap;
@@ -842,6 +842,7 @@ static void intel_pstate_get_hwp_max(struct cpudata *cpu,
int *phy_max,
*current_max = HWP_HIGHEST_PERF(cap);
*phy_max = HWP_HIGHEST_PERF(cap);
+ *guar_max = HWP_GUARANTEED_PERF(cap);
}
static void intel_pstate_hwp_set(unsigned int cpu)
@@ -1205,7 +1206,7 @@ static ssize_t store_no_turbo(struct kobject *a, struct
kobj_attribute *b,
static void update_qos_request(enum freq_qos_req_type type)
{
- int max_state, turbo_max, freq, i, perf_pct;
+ int max_state, turbo_max, guar_state, freq, i, perf_pct;
struct freq_qos_request *req;
struct cpufreq_policy *policy;
@@ -1223,7 +1224,7 @@ static void update_qos_request(enum freq_qos_req_type
type)
continue;
if (hwp_active)
- intel_pstate_get_hwp_max(cpu, _max, _state);
+ intel_pstate_get_hwp_max(cpu, _max, _state,
_state);
else
turbo_max = cpu->pstate.turbo_pstate;
@@ -1731,9 +1732,9 @@ static void intel_pstate_get_cpu_pstates(struct cpudata
*cpu)
cpu->pstate.max_freq = cpu->pstate.max_pstate * cpu->pstate.scaling;
if (hwp_active && !hwp_mode_bdw) {
- unsigned int phy_max, current_max;
+ unsigned int phy_max, current_max, guar_state;
- intel_pstate_get_hwp_max(cpu, _max, _max);
+ intel_pstate_get_hwp_max(cpu, _max, _max,
_state);
cpu->pstate.turbo_freq = phy_max * cpu->pstate.scaling;
cpu->pstate.turbo_pstate = phy_max;
} else {
@@ -2209,7 +2210,7 @@ static void intel_pstate_update_perf_limits(struct
cpudata *cpu,
unsigned int policy_max)
{
int32_t max_policy_perf, min_policy_perf;
- int max_state, turbo_max;
+ int max_state, turbo_max, guar_state;
int max_freq;
/*
@@ -2218,7 +2219,7 @@ static void intel_pstate_update_perf_limits(struct
cpudata *cpu,
* rather than pure ratios.
*/
if (hwp_active) {
- intel_pstate_get_hwp_max(cpu, _max, _state);
+ intel_pstate_get_hwp_max(cpu, _max, _state,
_state);
} else {
max_state = global.no_turbo || global.turbo_disabled ?
cpu->pstate.max_pstate : cpu->pstate.turbo_pstate;
@@ -2331,9 +2332,9 @@ static void intel_pstate_verify_cpu_policy(struct cpudata
*cpu,
update_turbo_state();
if (hwp_active) {
- int max_state, turbo_max;
+ int max_state, turbo_max, guar_state;
- intel_pstate_get_hwp_max(cpu, _max, _state);
+ intel_pstate_get_hwp_max(cpu, _max, _state,
_state);
max_freq = max_state * cpu->pstate.scaling;
} else {
max_freq = intel_pstate_get_max_freq(cpu);
@@ -2691,7 +2692,7 @@ static void intel_cpufreq_adjust_perf(unsigned int cpunum,
static int intel_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
- int max_state, turbo_max, min_freq, max_freq, ret;
+ int max_state, turbo_max, guar_state, min_freq, max_freq, ret;
struct freq_qos_request *req;
struct cpudata *cpu;
struct device *dev;
@@ -2719,7 +2720,7 @@ static int intel_cpufreq_cpu_init(struct cpufreq_policy
*policy)
if (hwp_active) {
u64 value;
- intel_pstate_get_hwp_max(cpu, _max, _state);
+ intel_pstate_get_hwp_max(cpu, _max, _state,
_state);
policy->transition_delay_us =
INTEL_CPUFREQ_TRANSITION_DELAY_HWP;
rdmsrl_on_cpu(cpu->cpu, MSR_HWP_REQUEST, );
WRITE_ONCE(cpu->hwp_req_cached, value);
--
2.17.1
[PATCH 0/2][v2] Get percpu max freq via HWP MSR register
Asymmetric platforms might have different max cpu frequency between small and big cores. Currently the intel_pstate driver uses package wide MSR register that can not distinguish max cpu frequency between small and big cores when turbo is disabled, which causes inconsistency compared to the scenario when turbo mode is enabled. This patch changes the logic from package wide MSR register to percpu HWP register so as to avoid this issue. This path is based on Rafael's previous patchset to clean up the intel_pstate_get_hwp_max() https://patchwork.kernel.org/project/linux-pm/patch/2241039.bdjsIDbar3@kreacher/ Chen Yu (2): cpufreq: intel_pstate: Add parameter to get guarantee cpufreq: intel_pstate: Get percpu max freq via HWP MSR register if available drivers/cpufreq/intel_pstate.c | 29 - 1 file changed, 16 insertions(+), 13 deletions(-) -- 2.17.1
Re: [PATCH] arm64: dts: rockchip: rename pinctrl nodename to gmac2io for nanopi-r2s board
Hi Rob,
On Mon, Jan 11, 2021 at 3:50 AM Johan Jonker wrote:
>
> A test with the command below gives this error:
> /arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml:
> ethernet-phy: 'reg' is a required property
>
> The pinctrl nodename "ethernet-phy" conflicts with the rules
> in the "ethernet-phy.yaml" document, so rename it to "gmac2io".
This seems more like an unintended side effect of the ethernet-phy binding.
Is there a way to limit the matching of the binding only if the parent is an
"mdio" or "ethernet" node? Would that make more sense?
Regards
ChenYu
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/ethernet-phy.yaml
>
> Signed-off-by: Johan Jonker
> ---
> arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> index 2ee07d15a..86732b45d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> @@ -280,7 +280,7 @@
> };
> };
>
> - ethernet-phy {
> + gmac2io {
> eth_phy_reset_pin: eth-phy-reset-pin {
> rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO
> _pull_down>;
> };
> --
> 2.11.0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
On Mon, Jan 11, 2021 at 4:17 AM Johan Jonker wrote:
>
> Hi Chen-Yu,
>
> Most is already answered by Heiko.
>
> On 1/10/21 4:37 PM, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Sun, Jan 10, 2021 at 10:45 PM Johan Jonker wrote:
> >>
> >> Hi Chen-Yu,
> >>
> >> Some comments, have a look if it is useful...
> >>
> >> On 1/10/21 4:58 AM, Chen-Yu Tsai wrote:
> >>> From: Chen-Yu Tsai
> >>>
> >>> Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
> >>> As the official wiki page puts it, "E for Ethernets".
> >>>
> >>> It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
> >>> directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
> >>> a power-only USB type-C port, a 3.5mm headphone jack for audio output,
> >>
> >>> two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
> >>> and PoE header.
> >>>
> >>> The board comes in multiple configurations, differing in the amount of
> >>> onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
> >>> 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
> >>> can all share the same device tree.
> >>>
> >>> The USB 2.0 OTG controller is available on the 40-pin header. This is
> >>> not enabled in the device tree, since it is possible to use it in a
> >>> host-only configuration, or in OTG mode with an extra pin from the
> >>> header as the ID pin.
> >>>
> >>> The device tree is based on the one of the Rock64, with various parts
> >>> modified to match the ROCK Pi E, and some parts updated to newer styles,
> >>> such as the gmac2io node's mdio sub-node.
> >>>
> >>> Add a new device tree file for the new board.
> >>>
> >>> Signed-off-by: Chen-Yu Tsai
> >>> ---
> >>> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> >>> .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
> >>> 2 files changed, 370 insertions(+)
> >>> create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >>>
> >>> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> >>> b/arch/arm64/boot/dts/rockchip/Makefile
> >>> index 622d320ddd13..62d3abc17a24 100644
> >>> --- a/arch/arm64/boot/dts/rockchip/Makefile
> >>> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> >>> @@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
> >>> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
> >>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >>> b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >>> new file mode 100644
> >>> index ..7818d2e8180c
> >>> --- /dev/null
> >>> +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >>> @@ -0,0 +1,369 @@
> >>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >>> +/*
> >>> + * (C) Copyright 2020 Chen-Yu Tsai
> >>> + *
> >>> + * Based on ./rk3328-rock64.dts, which is
> >>> + *
> >>> + * Copyright (c) 2017 PINE64
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include "rk3328.dtsi"
> >>> +
> >>> +/ {
> >>> + model = "Radxa ROCK Pi E";
> >>> + compatible = "radxa,rockpi-e", "rockchip,rk3328";
> >>> +
> >>> + chosen {
> >>> + stdout-path = "serial2:150n8";
> >>> + };
> >>> +
> >>> + gmac_clkin: external-gmac-clock {
> >>> + compatible = "fixed-clock";
> >>> + clock-frequency = <12500>;
> >>> + clock-output-names = "gmac_clkin";
> >>> + #clock-cells = <0>
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
On Mon, Jan 11, 2021 at 4:06 AM Heiko Stübner wrote:
>
> Hi,
>
> Am Sonntag, 10. Januar 2021, 16:37:15 CET schrieb Chen-Yu Tsai:
> > > > + vcc_sd: sdmmc-regulator {
> > > > + compatible = "regulator-fixed";
> > > > + gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <_pin>;
> > >
> > > > + regulator-boot-on;
> > > > + regulator-name = "vcc_sd";
> > >
> > > regulator-name above other regulator properties
> >
> > That is actually what I was used to, but some other rockchip dts files
> > have all the properties sorted alphabetically. So I stuck with what I
> > saw.
>
> I try to keep it alphabetical except for the exceptions :-D .
>
> regulator-name is such an exception. Similar to compatibles, the
> regulator-name is an entry needed to see if you're at the right node,
> so I really like it being the topmost regulator-foo property - just makes
> reading easier.
>
> (same for the compatible first, then regs, interrupts parts, as well
> as "status-last")
>
> But oftentimes, I just fix the ordering when applying - but seem to have
> missed this somewhere in those "other Rockchip dts files" ;-) .
I was slightly confused. I looked again and yes regulator-name is always the
first regulator related property. What's off is that in some cases min/max
voltage comes before always-on/boot-on, and in others vice versa.
For example in the Rock64 and ROC-RK3328-CC device trees, in the fixed
regulators, always-on/boot-on come before min/max voltage, while in the
PMIC the other order is used.
ChenYu
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
Hi,
On Sun, Jan 10, 2021 at 10:45 PM Johan Jonker wrote:
>
> Hi Chen-Yu,
>
> Some comments, have a look if it is useful...
>
> On 1/10/21 4:58 AM, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai
> >
> > Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
> > As the official wiki page puts it, "E for Ethernets".
> >
> > It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
> > directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
> > a power-only USB type-C port, a 3.5mm headphone jack for audio output,
>
> > two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
> > and PoE header.
> >
> > The board comes in multiple configurations, differing in the amount of
> > onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
> > 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
> > can all share the same device tree.
> >
> > The USB 2.0 OTG controller is available on the 40-pin header. This is
> > not enabled in the device tree, since it is possible to use it in a
> > host-only configuration, or in OTG mode with an extra pin from the
> > header as the ID pin.
> >
> > The device tree is based on the one of the Rock64, with various parts
> > modified to match the ROCK Pi E, and some parts updated to newer styles,
> > such as the gmac2io node's mdio sub-node.
> >
> > Add a new device tree file for the new board.
> >
> > Signed-off-by: Chen-Yu Tsai
> > ---
> > arch/arm64/boot/dts/rockchip/Makefile | 1 +
> > .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
> > 2 files changed, 370 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> > b/arch/arm64/boot/dts/rockchip/Makefile
> > index 622d320ddd13..62d3abc17a24 100644
> > --- a/arch/arm64/boot/dts/rockchip/Makefile
> > +++ b/arch/arm64/boot/dts/rockchip/Makefile
> > @@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
> > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> > b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> > new file mode 100644
> > index ..7818d2e8180c
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> > @@ -0,0 +1,369 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * (C) Copyright 2020 Chen-Yu Tsai
> > + *
> > + * Based on ./rk3328-rock64.dts, which is
> > + *
> > + * Copyright (c) 2017 PINE64
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include
> > +#include
> > +#include
> > +#include "rk3328.dtsi"
> > +
> > +/ {
> > + model = "Radxa ROCK Pi E";
> > + compatible = "radxa,rockpi-e", "rockchip,rk3328";
> > +
> > + chosen {
> > + stdout-path = "serial2:150n8";
> > + };
> > +
> > + gmac_clkin: external-gmac-clock {
> > + compatible = "fixed-clock";
> > + clock-frequency = <12500>;
> > + clock-output-names = "gmac_clkin";
> > + #clock-cells = <0>;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-0 = <_pin>;
> > + pinctrl-names = "default";
> > +
> > + led-0 {
>
> > + /* schematic say green but the actual thing is blue */
>
> In rockpie-v1.2-20200427-sch.pdf this led is already called "LED_BLUE",
> so comment maybe not needed anymore?
Thanks. Did not notice there was a new revision.
> > + color = ;
> > + gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
> > + linux,default-trigger = "heartbeat";
> > + };> + };
> > +
> > + vcc_sd: sdmmc-regulator {
> > + compatible = "regulator-fixed";
> > + gpio
[PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
From: Chen-Yu Tsai
Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
As the official wiki page puts it, "E for Ethernets".
It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
a power-only USB type-C port, a 3.5mm headphone jack for audio output,
two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
and PoE header.
The board comes in multiple configurations, differing in the amount of
onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
can all share the same device tree.
The USB 2.0 OTG controller is available on the 40-pin header. This is
not enabled in the device tree, since it is possible to use it in a
host-only configuration, or in OTG mode with an extra pin from the
header as the ID pin.
The device tree is based on the one of the Rock64, with various parts
modified to match the ROCK Pi E, and some parts updated to newer styles,
such as the gmac2io node's mdio sub-node.
Add a new device tree file for the new board.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
2 files changed, 370 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 622d320ddd13..62d3abc17a24 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
new file mode 100644
index ..7818d2e8180c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -0,0 +1,369 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * (C) Copyright 2020 Chen-Yu Tsai
+ *
+ * Based on ./rk3328-rock64.dts, which is
+ *
+ * Copyright (c) 2017 PINE64
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "rk3328.dtsi"
+
+/ {
+ model = "Radxa ROCK Pi E";
+ compatible = "radxa,rockpi-e", "rockchip,rk3328";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ gmac_clkin: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_clkin";
+ #clock-cells = <0>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <_pin>;
+ pinctrl-names = "default";
+
+ led-0 {
+ /* schematic say green but the actual thing is blue */
+ color = ;
+ gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+ regulator-boot-on;
+ regulator-name = "vcc_sd";
+ vin-supply = <_io>;
+ };
+
+ vcc_host_5v: vcc-host-5v-regulator {
+ compatible = "regulator-fixed";
+ gpio = < RK_PA7 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_host_drv>;
+ enable-active-high;
+ regulator-name = "vcc_host_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_sys>;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc_wifi: vcc-wifi-regulator {
+ compatible = "regulator-fixed";
+ gpio = < RK_PA0 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pin
[PATCH 1/3] arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node
From: Chen-Yu Tsai
The gmac2phy is integrated with the PHY within the SoC. Any properties
related to this integration can be included in the .dtsi file, instead
of having board dts files specify them separately.
Add the clock_in_out property to specify the direction of the PHY clock.
This is the minimum required to have gmac2phy working on Linux. Other
examples include assigned-clocks, assigned-clock-rates, and
assigned-clock-parents properties, but the hardware default plus the
implementation requesting the appropriate clock rate also works.
Fixes: 9c4cc910fe28 ("ARM64: dts: rockchip: Add gmac2phy node support for
rk3328")
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index db0d5c8e5f96..93c734d8a46c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -928,6 +928,7 @@ gmac2phy: ethernet@ff55 {
phy-mode = "rmii";
phy-handle = <>;
snps,txpbl = <0x4>;
+ clock_in_out = "output";
status = "disabled";
mdio {
--
2.29.2
[PATCH 0/3] arm64: rockchip: rk3328: Add Radxa ROCK Pi E
From: Chen-Yu Tsai Hi everyone, This series adds support for the Radxa ROCK Pi E. This is a router oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page puts it, "E for Ethernets". It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both directly served by Ethernet controllers in the SoC, a USB 3.0 host port, a power-only USB type-C port, a 3.5mm headphone jack for audio output, two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT and PoE header. The board comes in multiple configurations, differing in the amount of onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants can all share the same device tree. Currently, the 802.11ac chip lacks an in-kernel driver. The USB 2.0 OTG controller is available on the 40-pin header. This is not enabled in the device tree, since it is possible to use it in a host-only configuration, or in OTG mode with an extra pin from the header as the ID pin. The device tree is based on the one of the Rock64, with various parts modified to match the ROCK Pi E, and some parts updated to newer styles, such as the gmac2io node's mdio sub-node. Patch 1 adds the clock_in_out property to the gmac2phy node. This would always have the same setting for gmac2phy, which uses an integrated PHY in RMII mode. Having this set by default makes enabling gmac2phy at the board level simpler. Patch 2 adds a compatible string for this board to the list of Rockchip based devices. Patch 3 adds a device tree file for this board. This is based on the one for the Rock64, with many modifications to adapt it to the new board, as well as style updates. Please have a look. Regards ChenYu Chen-Yu Tsai (3): arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node dt-bindings: arm: rockchip: Add Radxa ROCK Pi E arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E .../devicetree/bindings/arm/rockchip.yaml | 5 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 + 4 files changed, 376 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts -- 2.29.2
[PATCH 2/3] dt-bindings: arm: rockchip: Add Radxa ROCK Pi E
From: Chen-Yu Tsai Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page puts it, "E for Ethernets". It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both directly served by Ethernet controllers in the SoC, a USB 3.0 host port, a power-only USB type-C port, a 3.5mm headphone jack for audio output, two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT and PoE header. The board comes in multiple configurations, differing in the amount of onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants can all share the same device tree. The USB 2.0 OTG controller is available on the 40-pin header. This is not enabled in the device tree, since it is possible to use it in a host-only configuration, or in OTG mode with an extra pin from the header as the ID pin. The device tree is based on the one of the Rock64, with various parts modified to match the ROCK Pi E, and some parts updated to newer styles, such as the gmac2io node's mdio sub-node. Add a compatible string for the new board. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 773fd4c531ed..c3036f95c7bc 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -468,6 +468,11 @@ properties: - const: radxa,rockpi4 - const: rockchip,rk3399 + - description: Radxa ROCK Pi E +items: + - const: radxa,rockpi-e + - const: rockchip,rk3328 + - description: Radxa ROCK Pi N8 items: - const: radxa,rockpi-n8 -- 2.29.2
[PATCH] staging: rtl8723bs: wifi_regd.c: Fix incorrect number of regulatory rules
From: Chen-Yu Tsai
The custom regulatory ruleset in the rtl8723bs driver lists an incorrect
number of rules: one too many. This results in an out-of-bounds access,
as detected by KASAN. This was possible thanks to the newly added support
for KASAN on ARMv7.
Fix this by filling in the correct number of rules given.
KASAN report:
==
BUG: KASAN: global-out-of-bounds in cfg80211_does_bw_fit_range+0x14/0x4c
[cfg80211]
Read of size 4 at addr bf20c254 by task ip/971
CPU: 2 PID: 971 Comm: ip Tainted: G C
5.11.0-rc2-00020-gf7fe528a7ebe #1
Hardware name: Allwinner sun8i Family
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x9c/0xb4)
[] (dump_stack) from []
(print_address_description.constprop.2+0x1dc/0x2dc)
[] (print_address_description.constprop.2) from []
(kasan_report+0x1a8/0x1c4)
[] (kasan_report) from []
(cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211])
[] (cfg80211_does_bw_fit_range [cfg80211]) from []
(freq_reg_info_regd.part.6+0x108/0x124 [>
[] (freq_reg_info_regd.part.6 [cfg80211]) from []
(handle_channel_custom.constprop.12+0x48/>
[] (handle_channel_custom.constprop.12 [cfg80211]) from []
(wiphy_apply_custom_regulatory+0>
[] (wiphy_apply_custom_regulatory [cfg80211]) from []
(rtw_regd_init+0x60/0x70 [r8723bs])
[] (rtw_regd_init [r8723bs]) from []
(rtw_cfg80211_init_wiphy+0x164/0x1e8 [r8723bs])
[] (rtw_cfg80211_init_wiphy [r8723bs]) from []
(_netdev_open+0xe4/0x28c [r8723bs])
[] (_netdev_open [r8723bs]) from [] (netdev_open+0x60/0x88
[r8723bs])
[] (netdev_open [r8723bs]) from [] (__dev_open+0x178/0x220)
[] (__dev_open) from [] (__dev_change_flags+0x258/0x2c4)
[] (__dev_change_flags) from [] (dev_change_flags+0x40/0x80)
[] (dev_change_flags) from [] (do_setlink+0x538/0x1160)
[] (do_setlink) from [] (__rtnl_newlink+0x65c/0xad8)
[] (__rtnl_newlink) from [] (rtnl_newlink+0x4c/0x6c)
[] (rtnl_newlink) from [] (rtnetlink_rcv_msg+0x1f8/0x454)
[] (rtnetlink_rcv_msg) from [] (netlink_rcv_skb+0xc4/0x1e0)
[] (netlink_rcv_skb) from [] (netlink_unicast+0x2c8/0x3c4)
[] (netlink_unicast) from [] (netlink_sendmsg+0x320/0x5f0)
[] (netlink_sendmsg) from [] (sys_sendmsg+0x320/0x3e0)
[] (sys_sendmsg) from [] (___sys_sendmsg+0xe8/0x12c)
[] (___sys_sendmsg) from [] (__sys_sendmsg+0xc0/0x120)
[] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x58)
Exception stack(0xc5693fa8 to 0xc5693ff0)
3fa0: 0074 c7a39800 0003 b6cee648
3fc0: 0074 c7a39800 0001 0128 78d18349 b6ceeda0 004f7cb0
3fe0: 0128 b6cee5e8 aeca151f aec1d746
The buggy address belongs to the variable:
rtw_drv_halt+0xf908/0x6b4 [r8723bs]
Memory state around the buggy address:
bf20c100: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9
bf20c180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>bf20c200: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9
^
bf20c280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
bf20c300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==
Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Signed-off-by: Chen-Yu Tsai
---
drivers/staging/rtl8723bs/os_dep/wifi_regd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
b/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
index 578b9f734231..65592bf84f38 100644
--- a/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
+++ b/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
@@ -34,7 +34,7 @@
NL80211_RRF_PASSIVE_SCAN)
static const struct ieee80211_regdomain rtw_regdom_rd = {
- .n_reg_rules = 3,
+ .n_reg_rules = 2,
.alpha2 = "99",
.reg_rules = {
RTW_2GHZ_CH01_11,
--
2.29.2
Re: [PATCH v1 1/3] cpufreq: intel_pstate: Always read hwp_cap_cached with READ_ONCE()
On Thu, Jan 07, 2021 at 07:42:15PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Because intel_pstate_get_hwp_max() which updates hwp_cap_cached > may run in parallel with the readers of it, annotate all of the > read accesses to it with READ_ONCE(). > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
Re: [PATCH v1 2/3] cpufreq: intel_pstate: Change intel_pstate_get_hwp_max() argument
On Thu, Jan 07, 2021 at 07:43:30PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > All of the callers of intel_pstate_get_hwp_max() access the struct > cpudata object that corresponds to the given CPU already and the > function itself needs to access that object (in order to update > hwp_cap_cached), so modify the code to pass a struct cpudata pointer > to it instead of the CPU number. > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
Re: [PATCH v1 3/3] cpufreq: intel_pstate: Rename two functions
On Thu, Jan 07, 2021 at 07:44:18PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Rename intel_cpufreq_adjust_hwp() and intel_cpufreq_adjust_perf_ctl() > to intel_cpufreq_hwp_update() and intel_cpufreq_perf_ctl_update(), > respectively, to avoid possible confusion with the ->adjist_perf() > callback function, intel_cpufreq_adjust_perf(). > > Signed-off-by: Rafael J. Wysocki > --- Tested-by: Chen Yu
[PATCH v3 0/4] arm64: rockchip: Fix PCIe ep-gpios requirement and Add Nanopi M4B
From: Chen-Yu Tsai Hi everyone, This is v3 of my Nanopi M4B series. Changes since v2 include: - Replaced dev_err() with dev_err_probe() for gpiod_get_optional() error - Added Reviewed-by tag from Robin Murphy for patch 3 Changes since v1 include: - Rewrite subject of patch 1 to match existing convention and reference 'ep-gpios' DT property instead of the 'ep_gpio' field This series mainly adds support for the new Nanopi M4B, which is a newer variant of the Nanopi M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi While working on this, I found that for the M4 family, the PCIe reset pin (from the M.2 expansion board) was not wired to the SoC. Only the NanoPC T4 has this wired. This ended up in patches 1 and 3. Patch 1 makes ep_gpio in the Rockchip PCIe driver optional. This property is optional in the DT binding, so this just makes the driver adhere to the binding. Patch 2 adds a new compatible string for the new board. Patch 3 moves the ep-gpios property of the pcie controller from the common nanopi4.dtsi file to the nanopc-t4.dts file. Patch 4 adds a new device tree file for the new board. It includes the original device tree for the M4, and then lists the differences. Given that patch 3 would make PCIe unusable without patch 1, I suggest merging patch 1 through the PCI tree as a fix for 5.10, and the rest for 5.11 through the Rockchip tree. Please have a look. The changes are mostly trivial. Regards ChenYu Chen-Yu Tsai (4): PCI: rockchip: Make 'ep-gpios' DT property optional dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4 arm64: dts: rockchip: rk3399: Add NanoPi M4B .../devicetree/bindings/arm/rockchip.yaml | 1 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 1 + .../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++ .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - drivers/pci/controller/pcie-rockchip.c| 5 +- 6 files changed, 58 insertions(+), 3 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts -- 2.29.2
[PATCH v3 1/4] PCI: rockchip: Make 'ep-gpios' DT property optional
From: Chen-Yu Tsai
The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is
an optional property. And indeed there are boards that don't require it.
Make the driver follow the binding by using devm_gpiod_get_optional()
instead of devm_gpiod_get().
Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
parse DT")
Signed-off-by: Chen-Yu Tsai
---
Heiko, I dropped you reviewed-by due to the error message change
Changes since v2:
- Fix error message for failed GPIO
Changes since v1:
- Rewrite subject to match existing convention and reference
'ep-gpios' DT property instead of the 'ep_gpio' field
---
drivers/pci/controller/pcie-rockchip.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip.c
b/drivers/pci/controller/pcie-rockchip.c
index 904dec0d3a88..90c957e3bc73 100644
--- a/drivers/pci/controller/pcie-rockchip.c
+++ b/drivers/pci/controller/pcie-rockchip.c
@@ -118,9 +118,10 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
}
if (rockchip->is_rc) {
- rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
+ rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
GPIOD_OUT_HIGH);
if (IS_ERR(rockchip->ep_gpio)) {
- dev_err(dev, "missing ep-gpios property in node\n");
+ dev_err_probe(dev, PTR_ERR(rockchip->ep_gpio),
+ "failed to get ep GPIO\n");
return PTR_ERR(rockchip->ep_gpio);
}
}
--
2.29.2
[PATCH v3 2/4] dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B
From: Chen-Yu Tsai The NanoPi M4B is a minor revision of the original M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi Add a compatible string for the new board revision. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index ef4544ad6f82..773fd4c531ed 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -132,6 +132,7 @@ properties: - enum: - friendlyarm,nanopc-t4 - friendlyarm,nanopi-m4 + - friendlyarm,nanopi-m4b - friendlyarm,nanopi-neo4 - const: rockchip,rk3399 -- 2.29.2
[PATCH v3 4/4] arm64: dts: rockchip: rk3399: Add NanoPi M4B
From: Chen-Yu Tsai
The NanoPi M4B is a minor revision of the original M4.
The differences against the original Nanopi M4 that are common with the
other M4V2 revision include:
- microphone header removed
- power button added
- recovery button added
Additional changes specific to the M4B:
- USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x
USB 2.0 ports
- ADB toggle switch added; this changes the top USB 3.0 host port to
a peripheral port
- Type-C port no longer supports data or PD
- WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0
but only 1T1R (down from 2T2R) for WiFi
Add a new dts file for the new board revision that shows the difference
against the original.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 1ab55a124a87..622d320ddd13 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -33,6 +33,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-kobol-helios64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
new file mode 100644
index ..72182c58cc46
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPi M4B board device tree source
+ *
+ * Copyright (c) 2020 Chen-Yu Tsai
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi-m4.dts"
+
+/ {
+ model = "FriendlyElec NanoPi M4B";
+ compatible = "friendlyarm,nanopi-m4b", "rockchip,rk3399";
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <150>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+};
+
+/* No USB type-C PD power manager */
+/delete-node/
+
+ {
+ status = "disabled";
+};
+
+_host {
+ phy-supply = <_usb2>;
+};
+
+_otg {
+ phy-supply = <_typec>;
+};
+
+_otg {
+ phy-supply = <_usb1>;
+};
+
+_typec {
+ enable-active-high;
+ gpios = < RK_PD2 GPIO_ACTIVE_HIGH>;
+};
--
2.29.2
[PATCH v3 3/4] arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4
From: Chen-Yu Tsai
Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the
NanoPi M4 family, no such signal is routed to the expansion header on
the base board.
As the schematics for the expansion board were not released, it is
unclear how this is handled, but the likely answer is that the signal
is always pulled high.
Move the ep-gpios property from the common nanopi4.dtsi file to the
board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios,
matching the board design.
A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux
driver is required, as the driver currently requires the property to be
present.
Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4")
Reviewed-by: Robin Murphy
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts | 1 +
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
index e0d75617bb7e..452728b82e42 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
@@ -95,6 +95,7 @@ map3 {
};
{
+ ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
num-lanes = <4>;
vpcie3v3-supply = <_sys>;
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 76a8b40a93c6..48ed4aaa37f3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -504,7 +504,6 @@ _phy {
};
{
- ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
max-link-speed = <2>;
num-lanes = <2>;
vpcie0v9-supply = <_s3>;
--
2.29.2
Re: [PATCH 0/4] bus: sunxi-rsb: Implement power managment
On Wed, Jan 6, 2021 at 6:50 PM Maxime Ripard wrote: > > Hi! > > On Sun, Jan 03, 2021 at 05:06:31AM -0600, Samuel Holland wrote: > > This series adds system (complete power down) and runtime (clock gate) > > PM hooks to the RSB controller driver. Tested on A64 and H6. > > > > Samuel Holland (4): > > bus: sunxi-rsb: Move OF match table > > bus: sunxi-rsb: Split out controller init/exit functions > > bus: sunxi-rsb: Implement suspend/resume/shutdown callbacks > > bus: sunxi-rsb: Implement runtime power management > > > > drivers/bus/sunxi-rsb.c | 211 > > 1 file changed, 150 insertions(+), 61 deletions(-) > > For the whole series, > > Acked-by: Maxime Ripard Thanks! Pushed out to kernel.org.
Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection
On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard wrote: > > On Mon, Jan 04, 2021 at 10:54:19AM +, André Przywara wrote: > > On 03/01/2021 10:00, Samuel Holland wrote: > > > On boards where the only peripheral connected to PL0/PL1 is an X-Powers > > > PMIC, configure the connection to use the RSB bus rather than the I2C > > > bus. Compared to the I2C controller that shares the pins, the RSB > > > controller allows a higher bus frequency, and it is more CPU-efficient. > > > > But is it really necessary to change the DTs for those boards in this > > way? It means those newer DTs now become incompatible with older > > kernels, and I don't know if those reasons above really justify this. > > > > I understand that we officially don't care about "newer DTs on older > > kernels", but do we really need to break this deliberately, for no > > pressing reasons? > > > > P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > > just want to avoid breaking existing ones. > > Doing so would also introduce some inconsistencies, one more thing to > consider during reviews, and would require more testing effort. > > I'm not sure that stretching our - already fairly sparse - resources > thin would be very wise here, especially for something that we don't > have to do and for a setup that isn't really used that much. As soon as some software component starts running RSB, (which I assume is what Samuel is planning to do in Crust?), there's a chance that it doesn't switch the chip back to I2C. And then Linux won't be able to access it. So I'm for keeping things consistent and converting all users to RSB. ChenYu
Re: [PATCH net-next 5/5] net: stmmac: dwmac-sun8i: Add a shutdown callback
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote: > > The Ethernet MAC and PHY are usually major consumers of power on boards > which may not be able to fully power off (that have no PMIC). Powering > down the MAC and internal PHY saves power while these boards are "off". > > Signed-off-by: Samuel Holland Reviewed-by: Chen-Yu Tsai
Re: [PATCH net-next 4/5] net: stmmac: dwmac-sun8i: Minor probe function cleanup
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote: > > Adjust the spacing and use an explicit "return 0" in the success path > to make the function easier to parse. > > Signed-off-by: Samuel Holland Reviewed-by: Chen-Yu Tsai
Re: [PATCH net-next 2/5] net: stmmac: dwmac-sun8i: Remove unnecessary PHY power check
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote: > > sun8i_dwmac_unpower_internal_phy already checks if the PHY is powered, > so there is no need to do it again here. > > Signed-off-by: Samuel Holland Reviewed-by: Chen-Yu Tsai
