Re: [PATCH v4 1/3] KVM: x86: add support for user wait instructions
On 6/19/2019 2:23 PM, Xiaoyao Li wrote:
On 6/19/2019 2:09 PM, Tao Xu wrote:
UMONITOR, UMWAIT and TPAUSE are a set of user wait instructions.
This patch adds support for user wait instructions in KVM. Availability
of the user wait instructions is indicated by the presence of the CPUID
feature flag WAITPKG CPUID.0x07.0x0:ECX[5]. User wait instructions may
be executed at any privilege level, and use IA32_UMWAIT_CONTROL MSR to
set the maximum time.
The behavior of user wait instructions in VMX non-root operation is
determined first by the setting of the "enable user wait and pause"
secondary processor-based VM-execution control bit 26.
If the VM-execution control is 0, UMONITOR/UMWAIT/TPAUSE cause
an invalid-opcode exception (#UD).
If the VM-execution control is 1, treatment is based on the
setting of the “RDTSC exiting” VM-execution control. Because KVM never
enables RDTSC exiting, if the instruction causes a delay, the amount of
time delayed is called here the physical delay. The physical delay is
first computed by determining the virtual delay. If
IA32_UMWAIT_CONTROL[31:2] is zero, the virtual delay is the value in
EDX:EAX minus the value that RDTSC would return; if
IA32_UMWAIT_CONTROL[31:2] is not zero, the virtual delay is the minimum
of that difference and AND(IA32_UMWAIT_CONTROL,FFFCH).
Because umwait and tpause can put a (psysical) CPU into a power saving
state, by default we dont't expose it to kvm and enable it only when
guest CPUID has it.
Detailed information about user wait instructions can be found in the
latest Intel 64 and IA-32 Architectures Software Developer's Manual.
Co-developed-by: Jingqi Liu
Signed-off-by: Jingqi Liu
Signed-off-by: Tao Xu
---
no changes in v4.
---
arch/x86/include/asm/vmx.h | 1 +
arch/x86/kvm/cpuid.c | 2 +-
arch/x86/kvm/vmx/capabilities.h | 6 ++
arch/x86/kvm/vmx/vmx.c | 4
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index a39136b0d509..8f00882664d3 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -69,6 +69,7 @@
#define SECONDARY_EXEC_PT_USE_GPA 0x0100
#define SECONDARY_EXEC_MODE_BASED_EPT_EXEC 0x0040
#define SECONDARY_EXEC_TSC_SCALING 0x0200
+#define SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE 0x0400
#define PIN_BASED_EXT_INTR_MASK 0x0001
#define PIN_BASED_NMI_EXITING 0x0008
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index e18a9f9f65b5..48bd851a6ae5 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -405,7 +405,7 @@ static inline int __do_cpuid_ent(struct
kvm_cpuid_entry2 *entry, u32 function,
F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ |
F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) |
F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) |
- F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B);
+ F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/;
/* cpuid 7.0.edx*/
const u32 kvm_cpuid_7_0_edx_x86_features =
diff --git a/arch/x86/kvm/vmx/capabilities.h
b/arch/x86/kvm/vmx/capabilities.h
index d6664ee3d127..fd77e17651b4 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -253,6 +253,12 @@ static inline bool cpu_has_vmx_tsc_scaling(void)
SECONDARY_EXEC_TSC_SCALING;
}
+static inline bool vmx_waitpkg_supported(void)
+{
+ return vmcs_config.cpu_based_2nd_exec_ctrl &
+ SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE;
Shouldn't it be
return vmx->secondary_exec_control &
SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE; ?
vmx->secondary_exec_control is another way to get SECONDARY_EXEC_CONTROL
but it need to add vmx as input. Use vmcs_config.cpu_based_2nd_exec_ctrl
is easy expand to use in other place.
Re: [PATCH 1/3] arch: riscv: add config option for building SiFive's SoC resource
On Mon, 17 Jun 2019 12:29:48 PDT (-0700), lolliv...@baylibre.com wrote: Create a config option for building SiFive SoC specific resources e.g. SiFive device tree, platform drivers... Signed-off-by: Loys Ollivier Cc: Paul Walmsley Cc: Palmer Dabbelt --- arch/riscv/Kconfig | 2 ++ arch/riscv/Kconfig.socs | 8 arch/riscv/boot/dts/sifive/Makefile | 2 +- 3 files changed, 11 insertions(+), 1 deletion(-) create mode 100644 arch/riscv/Kconfig.socs diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index ee32c66e1af3..eace5857c9e9 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -94,6 +94,8 @@ config PGTABLE_LEVELS default 3 if 64BIT default 2 +source "arch/riscv/Kconfig.socs" + menu "Platform type" choice diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs new file mode 100644 index ..60dae1b5f276 --- /dev/null +++ b/arch/riscv/Kconfig.socs @@ -0,0 +1,8 @@ +menu "SoC selection" + +config SOC_SIFIVE + bool "SiFive SoCs" + help + This enables support for SiFive SoC platform hardware. + +endmenu diff --git a/arch/riscv/boot/dts/sifive/Makefile b/arch/riscv/boot/dts/sifive/Makefile index baaeef9efdcb..6d6189e6e4af 100644 --- a/arch/riscv/boot/dts/sifive/Makefile +++ b/arch/riscv/boot/dts/sifive/Makefile @@ -1,2 +1,2 @@ # SPDX-License-Identifier: GPL-2.0 -dtb-y += hifive-unleashed-a00.dtb +dtb-$(CONFIG_SOC_SIFIVE) += hifive-unleashed-a00.dtb Reviewed-by: Palmer Dabbelt
Re: [PATCH 3/3] riscv: defconfig: enable SOC_SIFIVE
On Mon, 17 Jun 2019 12:29:50 PDT (-0700), lolliv...@baylibre.com wrote: Enable SOC_SIFIVE so the default upstream config is bootable on the SiFive Unleashed Board. And have basic support for future boards based on the same SoC. Signed-off-by: Loys Ollivier --- arch/riscv/configs/defconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 4f02967e55de..6e3e37aa8fd1 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -12,6 +12,7 @@ CONFIG_CHECKPOINT_RESTORE=y CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y CONFIG_BPF_SYSCALL=y +CONFIG_SOC_SIFIVE=y CONFIG_SMP=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y @@ -49,8 +50,6 @@ CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_EARLYCON_RISCV_SBI=y -CONFIG_SERIAL_SIFIVE=y -CONFIG_SERIAL_SIFIVE_CONSOLE=y CONFIG_HVC_RISCV_SBI=y # CONFIG_PTP_1588_CLOCK is not set CONFIG_DRM=y @@ -66,9 +65,6 @@ CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_STORAGE=y CONFIG_USB_UAS=y CONFIG_VIRTIO_MMIO=y -CONFIG_CLK_SIFIVE=y -CONFIG_CLK_SIFIVE_FU540_PRCI=y -CONFIG_SIFIVE_PLIC=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_AUTOFS4_FS=y Reviewed-by: Palmer Dabbelt
Re: [PATCH 2/3] riscv: select SiFive platform drivers with SOC_SIFIVE
On Mon, 17 Jun 2019 12:29:49 PDT (-0700), lolliv...@baylibre.com wrote: On selection of SOC_SIFIVE select the corresponding platform drivers. Signed-off-by: Loys Ollivier --- arch/riscv/Kconfig.socs | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs index 60dae1b5f276..536c0ef4aee8 100644 --- a/arch/riscv/Kconfig.socs +++ b/arch/riscv/Kconfig.socs @@ -2,6 +2,11 @@ menu "SoC selection" config SOC_SIFIVE bool "SiFive SoCs" + select SERIAL_SIFIVE + select SERIAL_SIFIVE_CONSOLE + select CLK_SIFIVE + select CLK_SIFIVE_FU540_PRCI + select SIFIVE_PLIC help This enables support for SiFive SoC platform hardware. Reviewed-by: Palmer Dabbelt
[PATCH 1/2] clk: imx: Remove __init for imx_register_uart_clocks() API
From: Anson Huang
Some of i.MX SoCs' clock driver use platform driver model,
and they need to call imx_register_uart_clocks() API, so
imx_register_uart_clocks() API should NOT be in .init section.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
index f241189..76457b2 100644
--- a/drivers/clk/imx/clk.c
+++ b/drivers/clk/imx/clk.c
@@ -123,8 +123,8 @@ void imx_cscmr1_fixup(u32 *val)
return;
}
-static int imx_keep_uart_clocks __initdata;
-static struct clk ** const *imx_uart_clocks __initdata;
+static int imx_keep_uart_clocks;
+static struct clk ** const *imx_uart_clocks;
static int __init imx_keep_uart_clocks_param(char *str)
{
@@ -137,7 +137,7 @@ __setup_param("earlycon", imx_keep_uart_earlycon,
__setup_param("earlyprintk", imx_keep_uart_earlyprintk,
imx_keep_uart_clocks_param, 0);
-void __init imx_register_uart_clocks(struct clk ** const clks[])
+void imx_register_uart_clocks(struct clk ** const clks[])
{
if (imx_keep_uart_clocks) {
int i;
--
2.7.4
[PATCH 2/2] clk: imx8mq: Keep uart clocks on during system boot
From: Anson Huang
Call imx_register_uart_clocks() API to keep uart clocks enabled
when earlyprintk or earlycon is active.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx8mq.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index 5fbc2a7..d407a07 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -272,6 +272,14 @@ static const char * const imx8mq_clko2_sels[] =
{"osc_25m", "sys2_pll_200m", "sy
static struct clk_onecell_data clk_data;
+static struct clk ** const uart_clks[] = {
+ &clks[IMX8MQ_CLK_UART1_ROOT],
+ &clks[IMX8MQ_CLK_UART2_ROOT],
+ &clks[IMX8MQ_CLK_UART3_ROOT],
+ &clks[IMX8MQ_CLK_UART4_ROOT],
+ NULL
+};
+
static int imx8mq_clocks_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -555,6 +563,8 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
err = of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
WARN_ON(err);
+ imx_register_uart_clocks(uart_clks);
+
return err;
}
--
2.7.4
Re: WARNING in fanotify_handle_event
Hello, syzbot has tested the proposed patch and the reproducer did not trigger crash: Reported-and-tested-by: syzbot+c277e8e2f46414645...@syzkaller.appspotmail.com Tested on: commit: a6a3fd5c fanotify: update connector fsid cache on add mark git tree: https://github.com/amir73il/linux.git fsnotify-fix-fsid-cache kernel config: https://syzkaller.appspot.com/x/.config?x=fa9f7e1b6a8bb586 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Note: testing is done by a robot and is best-effort only.
Re: [PATCH 4/7] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel
Michael Ellerman's on June 19, 2019 3:14 pm: > Hi Naveen, > > Sorry I meant to reply to this earlier .. :/ > > "Naveen N. Rao" writes: >> With -mprofile-kernel, gcc emits 'mflr r0', followed by 'bl _mcount' to >> enable function tracing and profiling. So far, with dynamic ftrace, we >> used to only patch out the branch to _mcount(). However, mflr is >> executed by the branch unit that can only execute one per cycle on >> POWER9 and shared with branches, so it would be nice to avoid it where >> possible. >> >> We cannot simply nop out the mflr either. When enabling function >> tracing, there can be a race if tracing is enabled when some thread was >> interrupted after executing a nop'ed out mflr. In this case, the thread >> would execute the now-patched-in branch to _mcount() without having >> executed the preceding mflr. >> >> To solve this, we now enable function tracing in 2 steps: patch in the >> mflr instruction, use synchronize_rcu_tasks() to ensure all existing >> threads make progress, and then patch in the branch to _mcount(). We >> override ftrace_replace_code() with a powerpc64 variant for this >> purpose. > > According to the ISA we're not allowed to patch mflr at runtime. See the > section on "CMODX". According to "quasi patch class" engineering note, we can patch anything with a preferred nop. But that's written as an optional facility, which we don't have a feature to test for. > > I'm also not convinced the ordering between the two patches is > guaranteed by the ISA, given that there's possibly no isync on the other > CPU. Will they go through a context synchronizing event? synchronize_rcu_tasks() should ensure a thread is scheduled away, but I'm not actually sure it guarantees CSI if it's kernel->kernel. Could do a smp_call_function to do the isync on each CPU to be sure. Thanks, Nick
Re: [PATCH v4 1/3] KVM: x86: add support for user wait instructions
On 6/19/2019 3:01 PM, Tao Xu wrote:
On 6/19/2019 2:23 PM, Xiaoyao Li wrote:
On 6/19/2019 2:09 PM, Tao Xu wrote:
UMONITOR, UMWAIT and TPAUSE are a set of user wait instructions.
This patch adds support for user wait instructions in KVM. Availability
of the user wait instructions is indicated by the presence of the CPUID
feature flag WAITPKG CPUID.0x07.0x0:ECX[5]. User wait instructions may
be executed at any privilege level, and use IA32_UMWAIT_CONTROL MSR to
set the maximum time.
The behavior of user wait instructions in VMX non-root operation is
determined first by the setting of the "enable user wait and pause"
secondary processor-based VM-execution control bit 26.
If the VM-execution control is 0, UMONITOR/UMWAIT/TPAUSE cause
an invalid-opcode exception (#UD).
If the VM-execution control is 1, treatment is based on the
setting of the “RDTSC exiting” VM-execution control. Because KVM never
enables RDTSC exiting, if the instruction causes a delay, the amount of
time delayed is called here the physical delay. The physical delay is
first computed by determining the virtual delay. If
IA32_UMWAIT_CONTROL[31:2] is zero, the virtual delay is the value in
EDX:EAX minus the value that RDTSC would return; if
IA32_UMWAIT_CONTROL[31:2] is not zero, the virtual delay is the minimum
of that difference and AND(IA32_UMWAIT_CONTROL,FFFCH).
Because umwait and tpause can put a (psysical) CPU into a power saving
state, by default we dont't expose it to kvm and enable it only when
guest CPUID has it.
Detailed information about user wait instructions can be found in the
latest Intel 64 and IA-32 Architectures Software Developer's Manual.
Co-developed-by: Jingqi Liu
Signed-off-by: Jingqi Liu
Signed-off-by: Tao Xu
---
no changes in v4.
---
arch/x86/include/asm/vmx.h | 1 +
arch/x86/kvm/cpuid.c | 2 +-
arch/x86/kvm/vmx/capabilities.h | 6 ++
arch/x86/kvm/vmx/vmx.c | 4
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index a39136b0d509..8f00882664d3 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -69,6 +69,7 @@
#define SECONDARY_EXEC_PT_USE_GPA 0x0100
#define SECONDARY_EXEC_MODE_BASED_EPT_EXEC 0x0040
#define SECONDARY_EXEC_TSC_SCALING 0x0200
+#define SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE 0x0400
#define PIN_BASED_EXT_INTR_MASK 0x0001
#define PIN_BASED_NMI_EXITING 0x0008
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index e18a9f9f65b5..48bd851a6ae5 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -405,7 +405,7 @@ static inline int __do_cpuid_ent(struct
kvm_cpuid_entry2 *entry, u32 function,
F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ |
F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) |
F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) |
- F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B);
+ F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/;
/* cpuid 7.0.edx*/
const u32 kvm_cpuid_7_0_edx_x86_features =
diff --git a/arch/x86/kvm/vmx/capabilities.h
b/arch/x86/kvm/vmx/capabilities.h
index d6664ee3d127..fd77e17651b4 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -253,6 +253,12 @@ static inline bool cpu_has_vmx_tsc_scaling(void)
SECONDARY_EXEC_TSC_SCALING;
}
+static inline bool vmx_waitpkg_supported(void)
+{
+ return vmcs_config.cpu_based_2nd_exec_ctrl &
+ SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE;
Shouldn't it be
return vmx->secondary_exec_control &
SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE; ?
vmx->secondary_exec_control is another way to get SECONDARY_EXEC_CONTROL
but it need to add vmx as input. Use vmcs_config.cpu_based_2nd_exec_ctrl
is easy expand to use in other place.
This patch want to enable waitpkg for guest only when
guest_cpuid_has(vcpu, X86_FEATURE_WAITPKG), and it only updates
vmx->secondary_exec_control based on guest's cpuid when setup vcpu. But
vmcs_config remains unchanged. So using vmcs_config there is wrong.
RE: [PATCHv5 10/20] PCI: mobiveil: Fix the INTx process errors
Hi Karthikeyan,
> -Original Message-
> From: Karthikeyan Mitran [mailto:m.karthike...@mobiveil.co.in]
> Sent: 2019年6月19日 13:29
> To: Lorenzo Pieralisi
> Cc: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; Leo Li ;
> catalin.mari...@arm.com; will.dea...@arm.com; Mingkai Hu
> ; M.h. Lian ; Xiaowei Bao
>
> Subject: Re: [PATCHv5 10/20] PCI: mobiveil: Fix the INTx process errors
>
> On Fri, Jun 14, 2019 at 4:14 PM Lorenzo Pieralisi
> wrote:
> >
> > On Fri, Jun 14, 2019 at 12:38:51PM +0530, Karthikeyan Mitran wrote:
> > > Hi Lorenzo and Hou Zhiqiang
> > > PAB_INTP_AMBA_MISC_STAT does have other status in the higher bits,
> > > it should have been masked before checking for the status
> >
> > You are the maintainer for this driver, so if there is something to be
> > changed you must post a patch to that extent, I do not understand what
> > the above means, write the code to fix it, I won't do it.
> >
> > I am getting a bit annoyed with this Mobiveil driver so either you
> > guys sort this out or I will have to remove it from the kernel.
> >
> > > Acked-by: Karthikeyan Mitran
> >
> > Ok I assume this means you tested it but according to what you say
> > above, are there still issues with this code path ? Should we update
> > the patch ?
> Tested-by: Karthikeyan Mitran This patch
> fixes the INTx status extraction and handling, I don't see any need to update
> this patch.
Thanks a lot for your test!
Zhiqiang
> >
> > Moreover:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkern
> >
> elnewbies.org%2FPatchCulture&data=02%7C01%7Czhiqiang.hou%40nx
> p.com
> > %7C1445570163bb479cae3708d6f47709fb%7C686ea1d3bc2b4c6fa92cd99
> c5c301635
> > %7C0%7C0%7C636965189438647036&sdata=xXQ5MCPuXV08Cd%2Fi
> TBnkAmOVGOsH
> > XFi7e1xcvlYIwiA%3D&reserved=0
> >
> > Please read it and never top-post.
> Thank you very much, for the information.
>
> >
> > Thanks,
> > Lorenzo
> >
> > > On Wed, Jun 12, 2019 at 8:38 PM Lorenzo Pieralisi
> > > wrote:
> > > >
> > > > On Fri, Apr 12, 2019 at 08:36:12AM +, Z.q. Hou wrote:
> > > > > From: Hou Zhiqiang
> > > > >
> > > > > In the loop block, there is not code to update the loop key,
> > > > > this patch updates the loop key by re-read the INTx status
> > > > > register.
> > > > >
> > > > > This patch also add the clearing of the handled INTx status.
> > > > >
> > > > > Note: Need MV to test this fix.
> > > >
> > > > This means INTX were never tested and current code handling them
> > > > is, AFAICS, an infinite loop which is very very bad.
> > > >
> > > > This is a gross bug and must be fixed as soon as possible.
> > > >
> > > > I want Karthikeyan ACK and Tested-by on this patch.
> > > >
> > > > Lorenzo
> > > >
> > > > > Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host
> > > > > Bridge IP driver")
> > > > > Signed-off-by: Hou Zhiqiang
> > > > > Reviewed-by: Minghuan Lian
> > > > > Reviewed-by: Subrahmanya Lingappa
>
> > > > > ---
> > > > > V5:
> > > > > - Corrected and retouched the subject and changelog.
> > > > >
> > > > > drivers/pci/controller/pcie-mobiveil.c | 13 +
> > > > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > > > > b/drivers/pci/controller/pcie-mobiveil.c
> > > > > index 4ba458474e42..78e575e71f4d 100644
> > > > > --- a/drivers/pci/controller/pcie-mobiveil.c
> > > > > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > > > > @@ -361,6 +361,7 @@ static void mobiveil_pcie_isr(struct irq_desc
> *desc)
> > > > > /* Handle INTx */
> > > > > if (intr_status & PAB_INTP_INTX_MASK) {
> > > > > shifted_status = csr_readl(pcie,
> > > > > PAB_INTP_AMBA_MISC_STAT);
> > > > > + shifted_status &= PAB_INTP_INTX_MASK;
> > > > > shifted_status >>= PAB_INTX_START;
> > > > > do {
> > > > > for_each_set_bit(bit, &shifted_status,
> > > > > PCI_NUM_INTX) { @@ -372,12 +373,16 @@ static void
> mobiveil_pcie_isr(struct irq_desc *desc)
> > > > >
> dev_err_ratelimited(dev, "unexpected IRQ, INT%d\n",
> > > > >
> bit);
> > > > >
> > > > > - /* clear interrupt */
> > > > > - csr_writel(pcie,
> > > > > -shifted_status <<
> PAB_INTX_START,
> > > > > + /* clear interrupt handled */
> > > > > + csr_writel(pcie, 1 <<
> > > > > + (PAB_INTX_START + bit),
> > > > >
> PAB_INTP_AMBA_MISC_STAT);
> > > > > }
> > > > > - } while ((shifted_status >> PAB_INTX_START) != 0);
> > > > > +
> > > > > + shifted_status = csr_readl(pcie,
> > > > > +
> PAB_INTP_AMBA_MISC_STAT);
> > > > > +
[PATCH] media: atmel: atmel-isc: fix i386 build error
From: Eugen Hristev
ld: drivers/media/platform/atmel/atmel-isc-base.o:(.bss+0x0): multiple
definition of `debug'; arch/x86/entry/entry_32.o:(.entry.text+0x21ac): first
defined here
Changed module parameters to static.
Reported-by: kbuild test robot
Signed-off-by: Eugen Hristev
---
Hello Hans,
Sorry for this, it looks like i386 has a stray weird 'debug' symbol which
causes an error.
I changed the module parameters of the atmel-isc to 'static' but now they
cannot be accessed in the other module files.
Will have to create a get function to be used in the other files if needed
later. Any other way to make a symbol static to current module and not
current file ? It would be useful for other config variables as well.
I was not sure if you want to squash this over the faulty patch or add it
as a separate patch.
If you want me to squash it let me know and I will come up with a squashed
new version.
Thanks,
Eugen
drivers/media/platform/atmel/atmel-isc-base.c | 4 ++--
drivers/media/platform/atmel/atmel-isc.h | 4
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isc-base.c
b/drivers/media/platform/atmel/atmel-isc-base.c
index eb1f5d4..c1c776b 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -35,11 +35,11 @@
#include "atmel-isc-regs.h"
#include "atmel-isc.h"
-unsigned int debug;
+static unsigned int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "debug level (0-2)");
-unsigned int sensor_preferred = 1;
+static unsigned int sensor_preferred = 1;
module_param(sensor_preferred, uint, 0644);
MODULE_PARM_DESC(sensor_preferred,
"Sensor is preferred to output the specified format (1-on
0-off), default 1");
diff --git a/drivers/media/platform/atmel/atmel-isc.h
b/drivers/media/platform/atmel/atmel-isc.h
index f5f5932..bfaed2f 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -230,10 +230,6 @@ struct isc_device {
#define ATMEL_ISC_NAME "atmel-isc"
-/* module parameters */
-extern unsigned int debug;
-extern unsigned int sensor_preferred;
-
extern struct isc_format formats_list[];
extern const struct isc_format controller_formats[];
extern const u32 isc_gamma_table[GAMMA_MAX + 1][GAMMA_ENTRIES];
--
2.7.4
Re: [PATCH 3/4] powerpc/powernv: remove dead NPU DMA code
On Wed, Jun 19, 2019 at 10:34:54AM +1000, Alexey Kardashevskiy wrote: > > > On 23/05/2019 17:49, Christoph Hellwig wrote: > > None of these routines were ever used since they were added to the > > kernel. > > > It is still being used exactly in the way as it was explained before in > previous respins. Thanks. Please point to the in-kernel user, because that is the only relevant one. This is not just my opinion but we had a clear discussion on that at least years kernel summit.
[tip:x86/urgent] x86/microcode: Fix the microcode load on CPU hotplug for real
Commit-ID: 5423f5ce5ca410b3646f355279e4e937d452e622
Gitweb: https://git.kernel.org/tip/5423f5ce5ca410b3646f355279e4e937d452e622
Author: Thomas Gleixner
AuthorDate: Tue, 18 Jun 2019 22:31:40 +0200
Committer: Borislav Petkov
CommitDate: Wed, 19 Jun 2019 09:16:35 +0200
x86/microcode: Fix the microcode load on CPU hotplug for real
A recent change moved the microcode loader hotplug callback into the early
startup phase which is running with interrupts disabled. It missed that
the callbacks invoke sysfs functions which might sleep causing nice 'might
sleep' splats with proper debugging enabled.
Split the callbacks and only load the microcode in the early startup phase
and move the sysfs handling back into the later threaded and preemptible
bringup phase where it was before.
Fixes: 78f4e932f776 ("x86/microcode, cpuhotplug: Add a microcode loader CPU
hotplug callback")
Signed-off-by: Thomas Gleixner
Signed-off-by: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: sta...@vger.kernel.org
Cc: x86-ml
Link:
https://lkml.kernel.org/r/alpine.deb.2.21.1906182228350.1...@nanos.tec.linutronix.de
---
arch/x86/kernel/cpu/microcode/core.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode/core.c
index a813987b5552..cb0fdcaf1415 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -789,13 +789,16 @@ static struct syscore_ops mc_syscore_ops = {
.resume = mc_bp_resume,
};
-static int mc_cpu_online(unsigned int cpu)
+static int mc_cpu_starting(unsigned int cpu)
{
- struct device *dev;
-
- dev = get_cpu_device(cpu);
microcode_update_cpu(cpu);
pr_debug("CPU%d added\n", cpu);
+ return 0;
+}
+
+static int mc_cpu_online(unsigned int cpu)
+{
+ struct device *dev = get_cpu_device(cpu);
if (sysfs_create_group(&dev->kobj, &mc_attr_group))
pr_err("Failed to create group for CPU%d\n", cpu);
@@ -872,7 +875,9 @@ int __init microcode_init(void)
goto out_ucode_group;
register_syscore_ops(&mc_syscore_ops);
- cpuhp_setup_state_nocalls(CPUHP_AP_MICROCODE_LOADER,
"x86/microcode:online",
+ cpuhp_setup_state_nocalls(CPUHP_AP_MICROCODE_LOADER,
"x86/microcode:starting",
+ mc_cpu_starting, NULL);
+ cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "x86/microcode:online",
mc_cpu_online, mc_cpu_down_prep);
pr_info("Microcode Update Driver: v%s.", DRIVER_VERSION);
Review request for edac: ie31200: Add Intel Corporation 3rd Gen Core processor
Hi, Jason Baron Could you help to check if we can support Intel Corporation 3rd Gen Core processor in driver ie31200? It is tested by our customer. Test result is accepted by the customer. Summary: EDAC, ie31200: Add Intel Corporation 3rd Gen Core processor commit 9a5001c8840928c3b51bc330a078524dff4d9be5 (HEAD -> master) Author: Jiping Ma Date: Mon Jun 17 13:36:20 2019 +0800 EDAC, ie31200: Add Intel Corporation 3rd Gen Core processor 3rd Gen Core seems to work just like Skylake. Signed-off-by: Jiping Ma Thanks, Jiping
[PATCH] EDAC, ie31200: Add Intel Corporation 3rd Gen Core processor
3rd Gen Core seems to work just like Skylake.
Signed-off-by: Jiping Ma
---
drivers/edac/ie31200_edac.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/edac/ie31200_edac.c b/drivers/edac/ie31200_edac.c
index aac9b9b..1445336 100644
--- a/drivers/edac/ie31200_edac.c
+++ b/drivers/edac/ie31200_edac.c
@@ -19,6 +19,7 @@
* 0c08: Xeon E3-1200 v3 Processor DRAM Controller
* 1918: Xeon E3-1200 v5 Skylake Host Bridge/DRAM Registers
* 5918: Xeon E3-1200 Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM
Registers
+ * 0154: 3rd Gen Core processor DRAM Controller
*
* Based on Intel specification:
*
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e3-1200v3-vol-2-datasheet.pdf
@@ -59,6 +60,7 @@
#define PCI_DEVICE_ID_INTEL_IE31200_HB_7 0x0c08
#define PCI_DEVICE_ID_INTEL_IE31200_HB_8 0x1918
#define PCI_DEVICE_ID_INTEL_IE31200_HB_9 0x5918
+#define PCI_DEVICE_ID_INTEL_IE31200_HB_10 0x0154
#define IE31200_DIMMS 4
#define IE31200_RANKS 8
@@ -569,6 +571,9 @@ static void ie31200_remove_one(struct pci_dev *pdev)
PCI_VEND_DEV(INTEL, IE31200_HB_9), PCI_ANY_ID, PCI_ANY_ID, 0, 0,
IE31200},
{
+ PCI_VEND_DEV(INTEL, IE31200_HB_10), PCI_ANY_ID, PCI_ANY_ID, 0, 0
+ , IE31200},
+ {
0,
}/* 0 terminated list. */
};
--
1.9.1
Re: [PATCH v2] RISC-V: Break load reservations during switch_to
On Fri, Jun 07, 2019 at 03:22:22PM -0700, Palmer Dabbelt wrote: > The comment describes why in detail. This was found because QEMU never > gives up load reservations, the issue is unlikely to manifest on real > hardware. > > Thanks to Carlos Eduardo for finding the bug! > @@ -330,6 +330,17 @@ ENTRY(__switch_to) > add a3, a0, a4 > add a4, a1, a4 > REG_S ra, TASK_THREAD_RA_RA(a3) > + /* > + * The Linux ABI allows programs to depend on load reservations being > + * broken on context switches, but the ISA doesn't require that the > + * hardware ever breaks a load reservation. The only way to break a > + * load reservation is with a store conditional, so we emit one here. > + * Since nothing ever takes a load reservation on TASK_THREAD_RA_RA we > + * know this will always fail, but just to be on the safe side this > + * writes the same value that was unconditionally written by the > + * previous instruction. > + */ I suspect that you need to do the same as 32-bit ARM, and clear this in your exception return path, rather than in __switch_to, since handlers for interrupts and other exceptions could leave a dangling reservation. For ARM, the architecture permits a store-exclusive to succeed even if the address differed from the load-exclusive. I don't know if the same applies here, but regardless I believe the case above applies if an IRQ is taken from kernel context, since the handler can manipulate the same variable as the interrupted code. Thanks, Mark.
Re: [PATCH v13 3/3] dt-bindings: mfd: Document Renesas R-Car Gen3 RPC-IF controller bindings
Hi Marek, > Subject > > Re: [PATCH v13 3/3] dt-bindings: mfd: Document Renesas R-Car Gen3 RPC-IF > controller bindings > > On 6/6/19 9:40 AM, masonccy...@mxic.com.tw wrote: > [...] > > > RPC-IF works either in SPI or HyperFlash is decided by external hardware > > pins > > configuration and it can NOT switch it's operation mode in the run time. > > This is not like my understanding of MFD. > > Which external hardware pins decide the RPC configuration ? > > It seems to me like PHYCNT register, PHYMEM bitfield, selects what > device is connected, and then a couple of other bits control the > communication, but I see nothing which would be tied to any external > configuration pins. > You may refer to R-Car D3 Draak Eva. board hardware manual and start-up guide, i.e., Table 2.12 Pin Multiplexing of R-Car D3 Mode setting pins and set by hardware switch 1, 2, 3, 13, 31 and 10 to configure booting from SPI mode or HyperFlash mode. thanks & best regards, Mason CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. = CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =
[PATCHv2] clk: add imx8 clk defines
From: Oliver Graute added header defines for imx8qm clock Signed-off-by: Oliver Graute --- include/dt-bindings/clock/imx8qm-clock.h | 851 +++ 1 file changed, 851 insertions(+) create mode 100644 include/dt-bindings/clock/imx8qm-clock.h diff --git a/include/dt-bindings/clock/imx8qm-clock.h b/include/dt-bindings/clock/imx8qm-clock.h new file mode 100644 index ..47217e4eaa6b --- /dev/null +++ b/include/dt-bindings/clock/imx8qm-clock.h @@ -0,0 +1,851 @@ +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017 NXP +*/ + +#ifndef __DT_BINDINGS_CLOCK_IMX8QM_H +#define __DT_BINDINGS_CLOCK_IMX8QM_H + +#define IMX8QM_CLK_DUMMY 0 + +#define IMX8QM_A53_DIV 1 +#define IMX8QM_A53_CLK 2 +#define IMX8QM_A72_DIV 3 +#define IMX8QM_A72_CLK 4 + +/* SC Clocks. */ +#define IMX8QM_SC_I2C_DIV 5 +#define IMX8QM_SC_I2C_CLK 6 +#define IMX8QM_SC_PID0_DIV 7 +#define IMX8QM_SC_PID0_CLK 8 +#define IMX8QM_SC_PIT_DIV 9 +#define IMX8QM_SC_PIT_CLK 10 +#define IMX8QM_SC_TPM_DIV 11 +#define IMX8QM_SC_TPM_CLK 12 +#define IMX8QM_SC_UART_DIV 13 +#define IMX8QM_SC_UART_CLK 14 + +/* LSIO */ +#define IMX8QM_PWM0_DIV15 +#define IMX8QM_PWM0_CLK16 +#define IMX8QM_PWM1_DIV17 +#define IMX8QM_PWM1_CLK18 +#define IMX8QM_PWM2_DIV19 +#define IMX8QM_PWM2_CLK20 +#define IMX8QM_PWM3_DIV21 +#define IMX8QM_PWM3_CLK22 +#define IMX8QM_PWM4_DIV23 +#define IMX8QM_PWM4_CLK24 +#define IMX8QM_PWM5_DIV26 +#define IMX8QM_PWM5_CLK27 +#define IMX8QM_PWM6_DIV28 +#define IMX8QM_PWM6_CLK29 +#define IMX8QM_PWM7_DIV30 +#define IMX8QM_PWM7_CLK31 +#define IMX8QM_FSPI0_DIV 32 +#define IMX8QM_FSPI0_CLK 33 +#define IMX8QM_FSPI1_DIV 34 +#define IMX8QM_FSPI1_CLK 35 +#define IMX8QM_GPT0_DIV36 +//#define IMX8QM_GPT0_CLK 37 +#define IMX8QM_GPT1_DIV38 +//#define IMX8QM_GPT1_CLK 39 +#define IMX8QM_GPT2_DIV40 +#define IMX8QM_GPT2_CLK41 +#define IMX8QM_GPT3_DIV42 +#define IMX8QM_GPT3_CLK43 +#define IMX8QM_GPT4_DIV44 +#define IMX8QM_GPT4_CLK45 + +/* Connectivity */ +#define IMX8QM_APBHDMA_CLK 46 +#define IMX8QM_GPMI_APB_CLK47 +#define IMX8QM_GPMI_APB_BCH_CLK48 +#define IMX8QM_GPMI_BCH_IO_DIV 49 +#define IMX8QM_GPMI_BCH_IO_CLK 50 +#define IMX8QM_GPMI_BCH_DIV51 +#define IMX8QM_GPMI_BCH_CLK52 +#define IMX8QM_SDHC0_IPG_CLK 53 +#define IMX8QM_SDHC0_DIV 54 +#define IMX8QM_SDHC0_CLK 55 +#define IMX8QM_SDHC1_IPG_CLK 56 +#define IMX8QM_SDHC1_DIV 57 +#define IMX8QM_SDHC1_CLK 58 +#define IMX8QM_SDHC2_IPG_CLK 59 +#define IMX8QM_SDHC2_DIV 60 +#define IMX8QM_SDHC2_CLK 61 +#define IMX8QM_USB2_OH_AHB_CLK 62 +#define IMX8QM_USB2_OH_IPG_S_CL63 +#define IMX8QM_USB2_OH_IPG_S_PL301_CLK 64 +#define IMX8QM_USB2_PHY_IPG_CLK65 +#define IMX8QM_USB3_IPG_CLK66 +#define IMX8QM_USB3_CORE_PCLK 67 +#define IMX8QM_USB3_PHY_CLK68 +#define IMX8Q
[PATCHv2] clk: add imx8 clk defines
From: Oliver Graute added header defines for imx8qm clock Signed-off-by: Oliver Graute --- include/dt-bindings/clock/imx8qm-clock.h | 851 +++ 1 file changed, 851 insertions(+) create mode 100644 include/dt-bindings/clock/imx8qm-clock.h diff --git a/include/dt-bindings/clock/imx8qm-clock.h b/include/dt-bindings/clock/imx8qm-clock.h new file mode 100644 index ..47217e4eaa6b --- /dev/null +++ b/include/dt-bindings/clock/imx8qm-clock.h @@ -0,0 +1,851 @@ +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017 NXP +*/ + +#ifndef __DT_BINDINGS_CLOCK_IMX8QM_H +#define __DT_BINDINGS_CLOCK_IMX8QM_H + +#define IMX8QM_CLK_DUMMY 0 + +#define IMX8QM_A53_DIV 1 +#define IMX8QM_A53_CLK 2 +#define IMX8QM_A72_DIV 3 +#define IMX8QM_A72_CLK 4 + +/* SC Clocks. */ +#define IMX8QM_SC_I2C_DIV 5 +#define IMX8QM_SC_I2C_CLK 6 +#define IMX8QM_SC_PID0_DIV 7 +#define IMX8QM_SC_PID0_CLK 8 +#define IMX8QM_SC_PIT_DIV 9 +#define IMX8QM_SC_PIT_CLK 10 +#define IMX8QM_SC_TPM_DIV 11 +#define IMX8QM_SC_TPM_CLK 12 +#define IMX8QM_SC_UART_DIV 13 +#define IMX8QM_SC_UART_CLK 14 + +/* LSIO */ +#define IMX8QM_PWM0_DIV15 +#define IMX8QM_PWM0_CLK16 +#define IMX8QM_PWM1_DIV17 +#define IMX8QM_PWM1_CLK18 +#define IMX8QM_PWM2_DIV19 +#define IMX8QM_PWM2_CLK20 +#define IMX8QM_PWM3_DIV21 +#define IMX8QM_PWM3_CLK22 +#define IMX8QM_PWM4_DIV23 +#define IMX8QM_PWM4_CLK24 +#define IMX8QM_PWM5_DIV26 +#define IMX8QM_PWM5_CLK27 +#define IMX8QM_PWM6_DIV28 +#define IMX8QM_PWM6_CLK29 +#define IMX8QM_PWM7_DIV30 +#define IMX8QM_PWM7_CLK31 +#define IMX8QM_FSPI0_DIV 32 +#define IMX8QM_FSPI0_CLK 33 +#define IMX8QM_FSPI1_DIV 34 +#define IMX8QM_FSPI1_CLK 35 +#define IMX8QM_GPT0_DIV36 +//#define IMX8QM_GPT0_CLK 37 +#define IMX8QM_GPT1_DIV38 +//#define IMX8QM_GPT1_CLK 39 +#define IMX8QM_GPT2_DIV40 +#define IMX8QM_GPT2_CLK41 +#define IMX8QM_GPT3_DIV42 +#define IMX8QM_GPT3_CLK43 +#define IMX8QM_GPT4_DIV44 +#define IMX8QM_GPT4_CLK45 + +/* Connectivity */ +#define IMX8QM_APBHDMA_CLK 46 +#define IMX8QM_GPMI_APB_CLK47 +#define IMX8QM_GPMI_APB_BCH_CLK48 +#define IMX8QM_GPMI_BCH_IO_DIV 49 +#define IMX8QM_GPMI_BCH_IO_CLK 50 +#define IMX8QM_GPMI_BCH_DIV51 +#define IMX8QM_GPMI_BCH_CLK52 +#define IMX8QM_SDHC0_IPG_CLK 53 +#define IMX8QM_SDHC0_DIV 54 +#define IMX8QM_SDHC0_CLK 55 +#define IMX8QM_SDHC1_IPG_CLK 56 +#define IMX8QM_SDHC1_DIV 57 +#define IMX8QM_SDHC1_CLK 58 +#define IMX8QM_SDHC2_IPG_CLK 59 +#define IMX8QM_SDHC2_DIV 60 +#define IMX8QM_SDHC2_CLK 61 +#define IMX8QM_USB2_OH_AHB_CLK 62 +#define IMX8QM_USB2_OH_IPG_S_CL63 +#define IMX8QM_USB2_OH_IPG_S_PL301_CLK 64 +#define IMX8QM_USB2_PHY_IPG_CLK65 +#define IMX8QM_USB3_IPG_CLK66 +#define IMX8QM_USB3_CORE_PCLK 67 +#define IMX8QM_USB3_PHY_CLK68 +#define IMX8Q
Re: [PATCH 5/5] Powerpc/Watchpoint: Fix length calculation for unaligned target
On 6/18/19 7:02 PM, Michael Neuling wrote: > On Tue, 2019-06-18 at 09:57 +0530, Ravi Bangoria wrote: >> Watchpoint match range is always doubleword(8 bytes) aligned on >> powerpc. If the given range is crossing doubleword boundary, we >> need to increase the length such that next doubleword also get >> covered. Ex, >> >> address len = 6 bytes >> |=. >>|v--|--v| >>| | | | | | | | | | | | | | | | | >>|---|---| >> <---8 bytes---> >> >> In such case, current code configures hw as: >> start_addr = address & ~HW_BREAKPOINT_ALIGN >> len = 8 bytes >> >> And thus read/write in last 4 bytes of the given range is ignored. >> Fix this by including next doubleword in the length. Watchpoint >> exception handler already ignores extraneous exceptions, so no >> changes required for that. > > Nice catch. Thanks. > > I assume this has been broken forever? Should we be CCing stable? If so, it > would be nice to have this self contained (separate from the refactor) so we > can > more easily backport it. Yes this has been broken forever. I'll add Fixes: tag and cc stable. > > Also, can you update > tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c to catch this issue? Sure, will add the test case. [...] >> +u16 hw_breakpoint_get_final_len(struct arch_hw_breakpoint *brk, >> +unsigned long *start_addr, >> +unsigned long *end_addr) > > I don't really like this. "final" is not a good name. Something like hardware > would be better. > > Also, can you put the start_addr and end addr in the arch_hw_breakpoint rather > than doing what you have above. Call them hw_start_addr, hw_end_addr. > > We could even set these two new addresses where we set the set of > arch_hw_breakpoint rather than having this late call. Sure, will use 'hw_' prefix for them.
Re: [PATCH 0/5] Powerpc/hw-breakpoint: Fixes plus Code refactor
On 6/18/19 11:47 AM, Michael Neuling wrote: > On Tue, 2019-06-18 at 08:01 +0200, Christophe Leroy wrote: >> >> Le 18/06/2019 à 06:27, Ravi Bangoria a écrit : >>> patch 1-3: Code refactor >>> patch 4: Speedup disabling breakpoint >>> patch 5: Fix length calculation for unaligned targets >> >> While you are playing with hw breakpoints, did you have a look at >> https://github.com/linuxppc/issues/issues/38 ? > > Agreed and also: > > https://github.com/linuxppc/issues/issues/170 > > https://github.com/linuxppc/issues/issues/128 > Yes, I'm aware of those. Will have a look at them.
[PATCH 2/4] arch: Add generic asid implement from arm
From: Guo Ren
The asid code is from arm64 and here is the ref link:
https://lore.kernel.org/linux-arm-kernel/20190321163623.20219-12-julien.gr...@arm.com/
Seems it's good for other arch to implement asid.
Signed-off-by: Guo Ren
---
arch/csky/include/asm/asid.h | 77 ++
arch/csky/mm/Makefile| 1 +
arch/csky/mm/asid.c | 185 +++
3 files changed, 263 insertions(+)
create mode 100644 arch/csky/include/asm/asid.h
create mode 100644 arch/csky/mm/asid.c
diff --git a/arch/csky/include/asm/asid.h b/arch/csky/include/asm/asid.h
new file mode 100644
index 000..bb62b58
--- /dev/null
+++ b/arch/csky/include/asm/asid.h
@@ -0,0 +1,77 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_ASM_ASID_H
+#define __ASM_ASM_ASID_H
+
+#include
+#include
+#include
+#include
+#include
+
+struct asid_info
+{
+ atomic64_t generation;
+ unsigned long *map;
+ atomic64_t __percpu *active;
+ u64 __percpu*reserved;
+ u32 bits;
+ /* Lock protecting the structure */
+ raw_spinlock_t lock;
+ /* Which CPU requires context flush on next call */
+ cpumask_t flush_pending;
+ /* Number of ASID allocated by context (shift value) */
+ unsigned intctxt_shift;
+ /* Callback to locally flush the context. */
+ void(*flush_cpu_ctxt_cb)(void);
+};
+
+#define NUM_ASIDS(info)(1UL << ((info)->bits))
+#define NUM_CTXT_ASIDS(info) (NUM_ASIDS(info) >> (info)->ctxt_shift)
+
+#define active_asid(info, cpu) *per_cpu_ptr((info)->active, cpu)
+
+void asid_new_context(struct asid_info *info, atomic64_t *pasid,
+ unsigned int cpu);
+
+/*
+ * Check the ASID is still valid for the context. If not generate a new ASID.
+ *
+ * @pasid: Pointer to the current ASID batch
+ * @cpu: current CPU ID. Must have been acquired throught get_cpu()
+ */
+static inline void asid_check_context(struct asid_info *info,
+ atomic64_t *pasid, unsigned int cpu)
+{
+ u64 asid, old_active_asid;
+
+ asid = atomic64_read(pasid);
+
+ /*
+* The memory ordering here is subtle.
+* If our active_asid is non-zero and the ASID matches the current
+* generation, then we update the active_asid entry with a relaxed
+* cmpxchg. Racing with a concurrent rollover means that either:
+*
+* - We get a zero back from the cmpxchg and end up waiting on the
+* lock. Taking the lock synchronises with the rollover and so
+* we are forced to see the updated generation.
+*
+* - We get a valid ASID back from the cmpxchg, which means the
+* relaxed xchg in flush_context will treat us as reserved
+* because atomic RmWs are totally ordered for a given location.
+*/
+ old_active_asid = atomic64_read(&active_asid(info, cpu));
+ if (old_active_asid &&
+ !((asid ^ atomic64_read(&info->generation)) >> info->bits) &&
+ atomic64_cmpxchg_relaxed(&active_asid(info, cpu),
+old_active_asid, asid))
+ return;
+
+ asid_new_context(info, pasid, cpu);
+}
+
+int asid_allocator_init(struct asid_info *info,
+ u32 bits, unsigned int asid_per_ctxt,
+ void (*flush_cpu_ctxt_cb)(void));
+
+#endif
diff --git a/arch/csky/mm/Makefile b/arch/csky/mm/Makefile
index c870eb3..897368f 100644
--- a/arch/csky/mm/Makefile
+++ b/arch/csky/mm/Makefile
@@ -11,3 +11,4 @@ obj-y += init.o
obj-y += ioremap.o
obj-y += syscache.o
obj-y += tlb.o
+obj-y += asid.o
diff --git a/arch/csky/mm/asid.c b/arch/csky/mm/asid.c
new file mode 100644
index 000..72b71bf
--- /dev/null
+++ b/arch/csky/mm/asid.c
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic ASID allocator.
+ *
+ * Based on arch/arm/mm/context.c
+ *
+ * Copyright (C) 2002-2003 Deep Blue Solutions Ltd, all rights reserved.
+ * Copyright (C) 2012 ARM Ltd.
+ */
+
+#include
+
+#include
+
+#define reserved_asid(info, cpu) *per_cpu_ptr((info)->reserved, cpu)
+
+#define ASID_MASK(info)(~GENMASK((info)->bits - 1, 0))
+#define ASID_FIRST_VERSION(info) (1UL << ((info)->bits))
+
+#define asid2idx(info, asid) (((asid) & ~ASID_MASK(info)) >>
(info)->ctxt_shift)
+#define idx2asid(info, idx)(((idx) << (info)->ctxt_shift) &
~ASID_MASK(info))
+
+static void flush_context(struct asid_info *info)
+{
+ int i;
+ u64 asid;
+
+ /* Update the list of reserved ASIDs and the ASID bitmap. */
+ bitmap_clear(info->map, 0, NUM_CTXT_ASIDS(info));
+
+ for_each_possible_cpu(i) {
+ asid = atomic64_xchg
[PATCH 0/4] csky: Use generic asid function from arm
From: Guo Ren Julien Grall plan to seperate asid allocator into generic and vmid and other architectures could use it. ref: https://lore.kernel.org/linux-arm-kernel/20190321163623.20219-1-julien.gr...@arm.com/ For C-SKY the first implementation is from mips and it's not implemented well for SMP in performance. Arm's asid allocator is right for us and we've tested it in our all CPUs:610/807/810/860 and it really reduce the tlb flush. We'll continue stress testing before merge into master. It's good for all architectures in linux and let's continue the work. @Julien Could you give a seperate patch for add generic asid ? Guo Ren (4): csky: Revert mmu ASID mechanism arch: Add generic asid implement from arm csky: Use generic asid algorithm to implement switch_mm csky: Improve tlb operation with help of asid arch/csky/abiv1/inc/abi/ckmmu.h | 6 + arch/csky/abiv2/inc/abi/ckmmu.h | 10 ++ arch/csky/include/asm/asid.h| 77 arch/csky/include/asm/mmu.h | 2 +- arch/csky/include/asm/mmu_context.h | 114 ++--- arch/csky/include/asm/pgtable.h | 2 - arch/csky/kernel/smp.c | 2 - arch/csky/mm/Makefile | 2 + arch/csky/mm/asid.c | 185 arch/csky/mm/context.c | 46 +++ arch/csky/mm/init.c | 2 - arch/csky/mm/tlb.c | 238 ++-- 12 files changed, 434 insertions(+), 252 deletions(-) create mode 100644 arch/csky/include/asm/asid.h create mode 100644 arch/csky/mm/asid.c create mode 100644 arch/csky/mm/context.c -- 2.7.4
[PATCH 1/4] csky: Revert mmu ASID mechanism
From: Guo Ren
Current C-SKY ASID mechanism is from mips and it doesn't work well
in a multi-core case. ASID per core mechanism is not suitable for
C-SKY SMP tlb maintain operations, eg: tlbi.vas need share the same
asid in all processors and it'll invalid the tlb entry in all cores
with the same asid.
This patch is prepare for new ASID mechanism.
Signed-off-by: Guo Ren
---
arch/csky/include/asm/mmu.h | 1 -
arch/csky/include/asm/mmu_context.h | 112 ++---
arch/csky/include/asm/pgtable.h | 2 -
arch/csky/kernel/smp.c | 2 -
arch/csky/mm/init.c | 2 -
arch/csky/mm/tlb.c | 190 ++--
6 files changed, 14 insertions(+), 295 deletions(-)
diff --git a/arch/csky/include/asm/mmu.h b/arch/csky/include/asm/mmu.h
index cb34467..06f509a 100644
--- a/arch/csky/include/asm/mmu.h
+++ b/arch/csky/include/asm/mmu.h
@@ -5,7 +5,6 @@
#define __ASM_CSKY_MMU_H
typedef struct {
- unsigned long asid[NR_CPUS];
void *vdso;
} mm_context_t;
diff --git a/arch/csky/include/asm/mmu_context.h
b/arch/csky/include/asm/mmu_context.h
index 734db3a1..86dde48 100644
--- a/arch/csky/include/asm/mmu_context.h
+++ b/arch/csky/include/asm/mmu_context.h
@@ -16,122 +16,24 @@
#define TLBMISS_HANDLER_SETUP_PGD(pgd) \
setup_pgd(__pa(pgd), false)
+
#define TLBMISS_HANDLER_SETUP_PGD_KERNEL(pgd) \
setup_pgd(__pa(pgd), true)
-#define cpu_context(cpu, mm) ((mm)->context.asid[cpu])
-#define cpu_asid(cpu, mm) (cpu_context((cpu), (mm)) & ASID_MASK)
-#define asid_cache(cpu)(cpu_data[cpu].asid_cache)
-
-#define ASID_FIRST_VERSION (1 << CONFIG_CPU_ASID_BITS)
-#define ASID_INC 0x1
-#define ASID_MASK (ASID_FIRST_VERSION - 1)
-#define ASID_VERSION_MASK ~ASID_MASK
+#define init_new_context(tsk,mm) 0
+#define activate_mm(prev,next) switch_mm(prev, next, current)
#define destroy_context(mm)do {} while (0)
#define enter_lazy_tlb(mm, tsk)do {} while (0)
#define deactivate_mm(tsk, mm) do {} while (0)
-/*
- * All unused by hardware upper bits will be considered
- * as a software asid extension.
- */
-static inline void
-get_new_mmu_context(struct mm_struct *mm, unsigned long cpu)
-{
- unsigned long asid = asid_cache(cpu);
-
- asid += ASID_INC;
- if (!(asid & ASID_MASK)) {
- flush_tlb_all();/* start new asid cycle */
- if (!asid) /* fix version if needed */
- asid = ASID_FIRST_VERSION;
- }
- cpu_context(cpu, mm) = asid_cache(cpu) = asid;
-}
-
-/*
- * Initialize the context related info for a new mm_struct
- * instance.
- */
-static inline int
-init_new_context(struct task_struct *tsk, struct mm_struct *mm)
-{
- int i;
-
- for_each_online_cpu(i)
- cpu_context(i, mm) = 0;
- return 0;
-}
-
-static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
- struct task_struct *tsk)
-{
- unsigned int cpu = smp_processor_id();
- unsigned long flags;
-
- local_irq_save(flags);
- /* Check if our ASID is of an older version and thus invalid */
- if ((cpu_context(cpu, next) ^ asid_cache(cpu)) & ASID_VERSION_MASK)
- get_new_mmu_context(next, cpu);
- write_mmu_entryhi(cpu_asid(cpu, next));
- TLBMISS_HANDLER_SETUP_PGD(next->pgd);
-
- /*
-* Mark current->active_mm as not "active" anymore.
-* We don't want to mislead possible IPI tlb flush routines.
-*/
- cpumask_clear_cpu(cpu, mm_cpumask(prev));
- cpumask_set_cpu(cpu, mm_cpumask(next));
-
- local_irq_restore(flags);
-}
-
-/*
- * After we have set current->mm to a new value, this activates
- * the context for the new mm so we see the new mappings.
- */
static inline void
-activate_mm(struct mm_struct *prev, struct mm_struct *next)
+switch_mm(struct mm_struct *prev, struct mm_struct *next,
+ struct task_struct *tsk)
{
- unsigned long flags;
- int cpu = smp_processor_id();
-
- local_irq_save(flags);
+ if (prev != next)
+ tlb_invalid_all();
- /* Unconditionally get a new ASID. */
- get_new_mmu_context(next, cpu);
-
- write_mmu_entryhi(cpu_asid(cpu, next));
TLBMISS_HANDLER_SETUP_PGD(next->pgd);
-
- /* mark mmu ownership change */
- cpumask_clear_cpu(cpu, mm_cpumask(prev));
- cpumask_set_cpu(cpu, mm_cpumask(next));
-
- local_irq_restore(flags);
}
-
-/*
- * If mm is currently active_mm, we can't really drop it. Instead,
- * we will get a new one for it.
- */
-static inline void
-drop_mmu_context(struct mm_struct *mm, unsigned int cpu)
-{
- unsigned long flags;
-
- local_irq_save(flags);
-
- if (cpumask_test_cpu(cpu, mm_cpumask(mm))) {
- get_new_mmu_context(mm, cpu);
-
[PATCH 3/4] csky: Use generic asid algorithm to implement switch_mm
From: Guo Ren
Use linux generic asid/vmid algorithm to implement csky
switch_mm function. The algorithm is from arm and it could
work with SMP system. It'll help reduce tlb flush for
switch_mm in task/vm switch.
Signed-off-by: Guo Ren
Cc: Julien Grall
Cc: Arnd Bergmann
---
arch/csky/abiv1/inc/abi/ckmmu.h | 6 +
arch/csky/abiv2/inc/abi/ckmmu.h | 10
arch/csky/include/asm/mmu.h | 1 +
arch/csky/include/asm/mmu_context.h | 12 --
arch/csky/mm/Makefile | 1 +
arch/csky/mm/context.c | 46 +
6 files changed, 74 insertions(+), 2 deletions(-)
create mode 100644 arch/csky/mm/context.c
diff --git a/arch/csky/abiv1/inc/abi/ckmmu.h b/arch/csky/abiv1/inc/abi/ckmmu.h
index 81f3771..ba8eb58 100644
--- a/arch/csky/abiv1/inc/abi/ckmmu.h
+++ b/arch/csky/abiv1/inc/abi/ckmmu.h
@@ -78,6 +78,12 @@ static inline void tlb_invalid_all(void)
cpwcr("cpcr8", 0x0400);
}
+
+static inline void local_tlb_invalid_all(void)
+{
+ tlb_invalid_all();
+}
+
static inline void tlb_invalid_indexed(void)
{
cpwcr("cpcr8", 0x0200);
diff --git a/arch/csky/abiv2/inc/abi/ckmmu.h b/arch/csky/abiv2/inc/abi/ckmmu.h
index e4480e6..73ded7c 100644
--- a/arch/csky/abiv2/inc/abi/ckmmu.h
+++ b/arch/csky/abiv2/inc/abi/ckmmu.h
@@ -85,6 +85,16 @@ static inline void tlb_invalid_all(void)
#endif
}
+static inline void local_tlb_invalid_all(void)
+{
+#ifdef CONFIG_CPU_HAS_TLBI
+ asm volatile("tlbi.all\n":::"memory");
+ sync_is();
+#else
+ tlb_invalid_all();
+#endif
+}
+
static inline void tlb_invalid_indexed(void)
{
mtcr("cr<8, 15>", 0x0200);
diff --git a/arch/csky/include/asm/mmu.h b/arch/csky/include/asm/mmu.h
index 06f509a..b382a14 100644
--- a/arch/csky/include/asm/mmu.h
+++ b/arch/csky/include/asm/mmu.h
@@ -5,6 +5,7 @@
#define __ASM_CSKY_MMU_H
typedef struct {
+ atomic64_t asid;
void *vdso;
} mm_context_t;
diff --git a/arch/csky/include/asm/mmu_context.h
b/arch/csky/include/asm/mmu_context.h
index 86dde48..0285b0a 100644
--- a/arch/csky/include/asm/mmu_context.h
+++ b/arch/csky/include/asm/mmu_context.h
@@ -20,20 +20,28 @@
#define TLBMISS_HANDLER_SETUP_PGD_KERNEL(pgd) \
setup_pgd(__pa(pgd), true)
-#define init_new_context(tsk,mm) 0
+#define ASID_MASK ((1 << CONFIG_CPU_ASID_BITS) - 1)
+#define cpu_asid(mm) (atomic64_read(&mm->context.asid) & ASID_MASK)
+
+#define init_new_context(tsk,mm) ({ atomic64_set(&(mm)->context.asid,
0); 0; })
#define activate_mm(prev,next) switch_mm(prev, next, current)
#define destroy_context(mm)do {} while (0)
#define enter_lazy_tlb(mm, tsk)do {} while (0)
#define deactivate_mm(tsk, mm) do {} while (0)
+void check_and_switch_context(struct mm_struct *mm, unsigned int cpu);
+
static inline void
switch_mm(struct mm_struct *prev, struct mm_struct *next,
struct task_struct *tsk)
{
+ unsigned int cpu = smp_processor_id();
+
if (prev != next)
- tlb_invalid_all();
+ check_and_switch_context(next, cpu);
TLBMISS_HANDLER_SETUP_PGD(next->pgd);
+ write_mmu_entryhi(next->context.asid.counter);
}
#endif /* __ASM_CSKY_MMU_CONTEXT_H */
diff --git a/arch/csky/mm/Makefile b/arch/csky/mm/Makefile
index 897368f..34cb5b1 100644
--- a/arch/csky/mm/Makefile
+++ b/arch/csky/mm/Makefile
@@ -12,3 +12,4 @@ obj-y += ioremap.o
obj-y += syscache.o
obj-y += tlb.o
obj-y += asid.o
+obj-y += context.o
diff --git a/arch/csky/mm/context.c b/arch/csky/mm/context.c
new file mode 100644
index 000..28ae9f0
--- /dev/null
+++ b/arch/csky/mm/context.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+static DEFINE_PER_CPU(atomic64_t, active_asids);
+static DEFINE_PER_CPU(u64, reserved_asids);
+
+struct asid_info asid_info;
+
+void check_and_switch_context(struct mm_struct *mm, unsigned int cpu)
+{
+ asid_check_context(&asid_info, &mm->context.asid, cpu);
+}
+
+static void asid_flush_cpu_ctxt(void)
+{
+ local_tlb_invalid_all();
+}
+
+static int asids_init(void)
+{
+ BUG_ON((1 << CONFIG_CPU_ASID_BITS - 1) <= num_possible_cpus());
+
+ if (asid_allocator_init(&asid_info, CONFIG_CPU_ASID_BITS, 1,
+ asid_flush_cpu_ctxt))
+ panic("Unable to initialize ASID allocator for %lu ASIDs\n",
+ NUM_ASIDS(&asid_info));
+
+ asid_info.active = &active_asids;
+ asid_info.reserved = &reserved_asids;
+
+ pr_info("ASID allocator initialised with %lu entries\n",
+ NUM_CTXT_ASIDS(&asid_info));
+
+ return 0;
+}
+early_initcall(asids_init
[PATCH 4/4] csky: Improve tlb operation with help of asid
From: Guo Ren
There are two generations of tlb operation instruction for C-SKY.
First generation is use mcr register and it need software do more
things, second generation is use specific instructions, eg:
tlbi.va, tlbi.vas, tlbi.alls
We implemented the following functions:
- flush_tlb_range (a range of entries)
- flush_tlb_page (one entry)
Above functions use asid from vma->mm to invalid tlb entries and
we could use tlbi.vas instruction for newest generation csky cpu.
- flush_tlb_kernel_range
- flush_tlb_one
Above functions don't care asid and it invalid the tlb entries only
with vpn and we could use tlbi.vaas instruction for newest generat-
ion csky cpu.
Signed-off-by: Guo Ren
Cc: Julien Grall
Cc: Arnd Bergmann
---
arch/csky/mm/tlb.c | 136 +++--
1 file changed, 132 insertions(+), 4 deletions(-)
diff --git a/arch/csky/mm/tlb.c b/arch/csky/mm/tlb.c
index efae81c..eb3ba6c 100644
--- a/arch/csky/mm/tlb.c
+++ b/arch/csky/mm/tlb.c
@@ -10,6 +10,13 @@
#include
#include
+/*
+ * One C-SKY MMU TLB entry contain two PFN/page entry, ie:
+ * 1VPN -> 2PFN
+ */
+#define TLB_ENTRY_SIZE (PAGE_SIZE * 2)
+#define TLB_ENTRY_SIZE_MASK(PAGE_MASK << 1)
+
void flush_tlb_all(void)
{
tlb_invalid_all();
@@ -17,27 +24,148 @@ void flush_tlb_all(void)
void flush_tlb_mm(struct mm_struct *mm)
{
+#ifdef CONFIG_CPU_HAS_TLBI
+ asm volatile("tlbi.asids %0"::"r"(cpu_asid(mm)));
+#else
tlb_invalid_all();
+#endif
}
+/*
+ * MMU operation regs only could invalid tlb entry in jtlb and we
+ * need change asid field to invalid I-utlb & D-utlb.
+ */
+#ifndef CONFIG_CPU_HAS_TLBI
+#define restore_asid_inv_utlb(oldpid, newpid) \
+do { \
+ if (oldpid == newpid) \
+ write_mmu_entryhi(oldpid + 1); \
+ write_mmu_entryhi(oldpid); \
+} while (0)
+#endif
+
void flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
unsigned long end)
{
- tlb_invalid_all();
+ unsigned long newpid = cpu_asid(vma->vm_mm);
+
+ start &= TLB_ENTRY_SIZE_MASK;
+ end += TLB_ENTRY_SIZE - 1;
+ end &= TLB_ENTRY_SIZE_MASK;
+
+#ifdef CONFIG_CPU_HAS_TLBI
+ while (start < end) {
+ asm volatile("tlbi.vas %0"::"r"(start | newpid));
+ start += 2*PAGE_SIZE;
+ }
+ sync_is();
+#else
+ {
+ unsigned long flags, oldpid;
+
+ local_irq_save(flags);
+ oldpid = read_mmu_entryhi() & ASID_MASK;
+ while (start < end) {
+ int idx;
+
+ write_mmu_entryhi(start | newpid);
+ start += 2*PAGE_SIZE;
+ tlb_probe();
+ idx = read_mmu_index();
+ if (idx >= 0)
+ tlb_invalid_indexed();
+ }
+ restore_asid_inv_utlb(oldpid, newpid);
+ local_irq_restore(flags);
+ }
+#endif
}
void flush_tlb_kernel_range(unsigned long start, unsigned long end)
{
- tlb_invalid_all();
+ start &= TLB_ENTRY_SIZE_MASK;
+ end += TLB_ENTRY_SIZE - 1;
+ end &= TLB_ENTRY_SIZE_MASK;
+
+#ifdef CONFIG_CPU_HAS_TLBI
+ while (start < end) {
+ asm volatile("tlbi.vaas %0"::"r"(start));
+ start += 2*PAGE_SIZE;
+ }
+ sync_is();
+#else
+ {
+ unsigned long flags, oldpid;
+
+ local_irq_save(flags);
+ oldpid = read_mmu_entryhi() & ASID_MASK;
+ while (start < end) {
+ int idx;
+
+ write_mmu_entryhi(start | oldpid);
+ start += 2*PAGE_SIZE;
+ tlb_probe();
+ idx = read_mmu_index();
+ if (idx >= 0)
+ tlb_invalid_indexed();
+ }
+ restore_asid_inv_utlb(oldpid, oldpid);
+ local_irq_restore(flags);
+ }
+#endif
}
void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)
{
- tlb_invalid_all();
+ int newpid = cpu_asid(vma->vm_mm);
+
+ addr &= TLB_ENTRY_SIZE_MASK;
+
+#ifdef CONFIG_CPU_HAS_TLBI
+ asm volatile("tlbi.vas %0"::"r"(addr | newpid));
+ sync_is();
+#else
+ {
+ int oldpid, idx;
+ unsigned long flags;
+
+ local_irq_save(flags);
+ oldpid = read_mmu_entryhi() & ASID_MASK;
+ write_mmu_entryhi(addr | newpid);
+ tlb_probe();
+ idx = read_mmu_index();
+ if (idx >= 0)
+ tlb_invalid_indexed();
+
+ restore_asid_inv_utlb(oldpid, newpid);
+ local_irq_restore(flags);
+ }
+#endif
}
void flush_tlb_one(unsigned long addr)
{
- tlb_invalid_all();
+ addr &= TLB_ENTRY_SIZE_MASK;
+
+#ifdef CONFIG_CPU_HAS_TLBI
+ asm volatile("tlbi.vaas %0"::"r"(addr));
+ sync_is();
+#else
+ {
+ int oldpid, idx;
+ unsigned long flags;
+
+ local_irq_save(flags);
+ oldpid = read_mmu_entryhi() & ASID_MASK;
+ write_mmu_entryhi(addr | oldpid);
+ tlb_probe();
+ id
[PATCH 1/1] scsi: virtio_scsi: remove unused 'affinity_hint_set'
The 'affinity_hint_set' is not used any longer since
commit 0d9f0a52c8b9 ("virtio_scsi: use virtio IRQ affinity").
Signed-off-by: Dongli Zhang
---
drivers/scsi/virtio_scsi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 13f1b3b..1705398 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -74,9 +74,6 @@ struct virtio_scsi {
u32 num_queues;
- /* If the affinity hint is set for virtqueues */
- bool affinity_hint_set;
-
struct hlist_node node;
/* Protected by event_vq lock */
--
2.7.4
Re: linux-next: Fixes tags need some work in the staging.current tree
On Tue, 18 Jun 2019 13:51:31 +0200
Greg KH wrote:
> On Tue, Jun 18, 2019 at 07:36:18AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > In commit
> >
> > 0c75376fa395 ("counter/ftm-quaddec: Add missing dependencies in Kconfig")
> >
> > Fixes tag
> >
> > Fixes: a3b9a99 ("counter: add FlexTimer Module Quadrature decoder counter
> > driver")
> >
> > has these problem(s):
> >
> > - SHA1 should be at least 12 digits long
> > Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
> > or later) just making sure it is not set (or set to "auto").
> >
> > In commit
> >
> > bce0d57db388 ("iio: imu: st_lsm6dsx: fix PM support for st_lsm6dsx i2c
> > controller")
> >
> > Fixes tag
> >
> > Fixes: c91c1c844ebd ("imu: st_lsm6dsx: add i2c embedded controller
> > support")
> >
> > has these problem(s):
> >
> > - Subject does not match target commit subject
> > Just use
> > git log -1 --format='Fixes: %h ("%s")'
>
> Ugh.
>
> I blame Jonathan for all of these as they came in through his tree :)
>
> thanks,
>
> greg k-h
I'll keep a closer eye on this going forwards.
Thanks,
Jonathan
Re: [PATCH 5/7] powerpc/ftrace: Update ftrace_location() for powerpc -mprofile-kernel
Steven Rostedt wrote:
On Tue, 18 Jun 2019 23:53:11 +0530
"Naveen N. Rao" wrote:
Naveen N. Rao wrote:
> Steven Rostedt wrote:
>> On Tue, 18 Jun 2019 20:17:04 +0530
>> "Naveen N. Rao" wrote:
>>
>>> @@ -1551,7 +1551,7 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end)
>>>key.flags = end;/* overload flags, as it is unsigned long */
>>>
>>> for (pg = ftrace_pages_start; pg; pg = pg->next) {
>>> - if (end < pg->records[0].ip ||
>>> + if (end <= pg->records[0].ip ||
>>
>> This breaks the algorithm. "end" is inclusive. That is, if you look for
>> a single byte, where "start" and "end" are the same, and it happens to
>> be the first ip on the pg page, it will be skipped, and not found.
>
> Thanks. It looks like I should be over-riding ftrace_location() instead.
> I will update this patch.
I think I will have ftrace own the two instruction range, regardless of
whether the preceding instruction is a 'mflr r0' or not. This simplifies
things and I don't see an issue with it as of now. I will do more
testing to confirm.
- Naveen
--- a/arch/powerpc/kernel/trace/ftrace.c
+++ b/arch/powerpc/kernel/trace/ftrace.c
@@ -951,6 +951,16 @@ void arch_ftrace_update_code(int command)
}
#ifdef CONFIG_MPROFILE_KERNEL
+/*
+ * We consider two instructions -- 'mflr r0', 'bl _mcount' -- to be part
+ * of ftrace. When checking for the first instruction, we want to include
+ * the next instruction in the range check.
+ */
+unsigned long ftrace_location(unsigned long ip)
+{
+ return ftrace_location_range(ip, ip + MCOUNT_INSN_SIZE);
+}
+
/* Returns 1 if we patched in the mflr */
static int __ftrace_make_call_prep(struct dyn_ftrace *rec)
{
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 21d8e201ee80..122e2bb4a739 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1573,7 +1573,7 @@ unsigned long ftrace_location_range(unsigned long start,
unsigned long end)
* the function tracer. It checks the ftrace internal tables to
* determine if the address belongs or not.
*/
-unsigned long ftrace_location(unsigned long ip)
+unsigned long __weak ftrace_location(unsigned long ip)
{
return ftrace_location_range(ip, ip);
}
Actually, instead of making this a weak function, let's do this:
In include/ftrace.h:
#ifndef FTRACE_IP_EXTENSION
# define FTRACE_IP_EXTENSION0
#endif
In arch/powerpc/include/asm/ftrace.h
#define FTRACE_IP_EXTENSION MCOUNT_INSN_SIZE
Then we can just have:
unsigned long ftrace_location(unsigned long ip)
{
return ftrace_location_range(ip, ip + FTRACE_IP_EXTENSION);
}
Thanks, that's indeed nice. I hope you don't mind me adding your SOB for
that.
- Naveen
Re: [PATCH] mailbox: tegra-hsp: mark PM functions as __maybe_unused
On Thu, 10 Jan 2019 at 09:16, Thierry Reding wrote:
>
> On Tue, Jan 08, 2019 at 03:37:13PM +0100, Anders Roxell wrote:
> > Without CONFIG_PM_SLEEP, we get annoying warnings about unused
> > functions:
> >
> > drivers/mailbox/tegra-hsp.c:782:12: warning: ‘tegra_hsp_resume’ defined but
> > not used [-Wunused-function]
> > static int tegra_hsp_resume(struct device *dev)
> > ^~~~
> >
> > Mark them as __maybe_unused to shut up the warning and silently drop the
> > functions without having to add ugly #ifdefs.
> >
> > Fixes: 9a63f0f40599 ("mailbox: tegra-hsp: Add suspend/resume support")
> > Signed-off-by: Anders Roxell
> > ---
> > drivers/mailbox/tegra-hsp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Acked-by: Thierry Reding
Will this be picked up ?
Cheers,
Anders
Re: [PATCH] ubsan: mark ubsan_type_mismatch_common inline
On Tue, Jun 18, 2019 at 05:06:39PM +0200, Arnd Bergmann wrote: > On Tue, Jun 18, 2019 at 3:59 PM Peter Zijlstra wrote: > > On Tue, Jun 18, 2019 at 04:27:45PM +0300, Andrey Ryabinin wrote: > > > On 6/18/19 3:56 PM, Arnd Bergmann wrote: > > > > On Mon, Jun 17, 2019 at 4:02 PM Peter Zijlstra > > > > wrote: > > > > I guess this: > > > ccflags-y += $(DISABLE_STACKLEAK_PLUGIN) > > > > Or more specifically this, I guess: > > > > CFLAGS_ubsan.o := $(call cc-option, -fno-conserve-stack > > -fno-stack-protector) $(DISABLE_STACKLEAK_PLUGIN) > > > > we'd not want to exclude all of lib/ from stackleak I figure. > > > > Of these two options, I think I prefer the latter, because a smaller > > whitelist is a better whitelist and since we already disable > > stack protector, it is only consistent to also disable stack leak. > > Ok, sounds good to me. Can you send that upstream then, or should > I write it up as a proper patch? If you could verify it actually works that would be great, I haven't tried to construct a failing .config yet.
Re: [PATCH] mailbox: tegra-hsp: mark PM functions as __maybe_unused
On Wed, 19 Jun 2019 at 09:56, Anders Roxell wrote:
>
> On Thu, 10 Jan 2019 at 09:16, Thierry Reding wrote:
> >
> > On Tue, Jan 08, 2019 at 03:37:13PM +0100, Anders Roxell wrote:
> > > Without CONFIG_PM_SLEEP, we get annoying warnings about unused
> > > functions:
> > >
> > > drivers/mailbox/tegra-hsp.c:782:12: warning: ‘tegra_hsp_resume’ defined
> > > but not used [-Wunused-function]
> > > static int tegra_hsp_resume(struct device *dev)
> > > ^~~~
> > >
> > > Mark them as __maybe_unused to shut up the warning and silently drop the
> > > functions without having to add ugly #ifdefs.
> > >
> > > Fixes: 9a63f0f40599 ("mailbox: tegra-hsp: Add suspend/resume support")
> > > Signed-off-by: Anders Roxell
> > > ---
> > > drivers/mailbox/tegra-hsp.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Acked-by: Thierry Reding
>
> Will this be picked up ?
its already solved.
Sorry for the noice. =/
Anders
>
> Cheers,
> Anders
Re: [PATCH] media: atmel: atmel-isc: fix i386 build error
Hi Eugen, On Wed, Jun 19, 2019 at 07:24:41AM +, eugen.hris...@microchip.com wrote: > From: Eugen Hristev > > ld: drivers/media/platform/atmel/atmel-isc-base.o:(.bss+0x0): multiple > definition of `debug'; arch/x86/entry/entry_32.o:(.entry.text+0x21ac): first > defined here > > Changed module parameters to static. > > Reported-by: kbuild test robot > Signed-off-by: Eugen Hristev > --- > > Hello Hans, > > Sorry for this, it looks like i386 has a stray weird 'debug' symbol which > causes an error. > I changed the module parameters of the atmel-isc to 'static' but now they > cannot be accessed in the other module files. > Will have to create a get function to be used in the other files if needed > later. Any other way to make a symbol static to current module and not > current file ? It would be useful for other config variables as well. > I was not sure if you want to squash this over the faulty patch or add it > as a separate patch. Please consider using dev_dbg() instead of a driver specific parameter for debug. For the patch: Acked-by: Sakari Ailus -- Sakari Ailus
Re: [PATCH] sparc: Remove redundant copy of the LGPL-2.0
On Thu, Jun 13, 2019 at 03:14:56PM -0700, David Miller wrote:
> > On 13/06/2019, David Miller wrote:
> >> From: Thomas Huth
> >> Date: Mon, 27 May 2019 18:32:53 +0200
> >>
> >>> We already provide the LGPL-2.0 text in LICENSES/preferred/LGPL-2.0,
> >>> so there is no need for this additional copy here.
> >>>
> >>> Signed-off-by: Thomas Huth
> >>
> >> Applied.
> >>
> >
> > Shouldn't the SPDX license identifiers in in arch/sparc/lib be adjusted to
> > reflect the original intent of LGPL licensing?
>
> Yes, can someone cook up a quick patch for me for that?
>
> Thanks.
David,
can you please review this quick one?
Thanks.
Update arch/sparc/lib/* to LGPL-2.0+ to be in order with original arch/sparc/lib/COPYING.LIB
sed -i 's/SPDX-License-Identifier: \(.*\) */SPDX-License-Identifier: LGPL-2.0+ *\//' arch/sparc/lib/*
Fixes: b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license")
Signed-off-by: Anatoly Pugachev
CC: Kate Stewart
CC: Philippe Ombredanne
CC: Thomas Gleixner
CC: David S. Miller
---
arch/sparc/lib/GENbzero.S| 2 +-
arch/sparc/lib/GENcopy_from_user.S | 2 +-
arch/sparc/lib/GENcopy_to_user.S | 2 +-
arch/sparc/lib/GENmemcpy.S | 2 +-
arch/sparc/lib/GENpage.S | 2 +-
arch/sparc/lib/GENpatch.S| 2 +-
arch/sparc/lib/Makefile | 2 +-
arch/sparc/lib/NG2copy_from_user.S | 2 +-
arch/sparc/lib/NG2copy_to_user.S | 2 +-
arch/sparc/lib/NG2memcpy.S | 2 +-
arch/sparc/lib/NG2patch.S| 2 +-
arch/sparc/lib/NG4clear_page.S | 2 +-
arch/sparc/lib/NG4copy_from_user.S | 2 +-
arch/sparc/lib/NG4copy_page.S| 2 +-
arch/sparc/lib/NG4copy_to_user.S | 2 +-
arch/sparc/lib/NG4memcpy.S | 2 +-
arch/sparc/lib/NG4memset.S | 2 +-
arch/sparc/lib/NG4patch.S| 2 +-
arch/sparc/lib/NGbzero.S | 2 +-
arch/sparc/lib/NGcopy_from_user.S| 2 +-
arch/sparc/lib/NGcopy_to_user.S | 2 +-
arch/sparc/lib/NGmemcpy.S| 2 +-
arch/sparc/lib/NGpage.S | 2 +-
arch/sparc/lib/NGpatch.S | 2 +-
arch/sparc/lib/PeeCeeI.c | 2 +-
arch/sparc/lib/U1copy_from_user.S| 2 +-
arch/sparc/lib/U1copy_to_user.S | 2 +-
arch/sparc/lib/U1memcpy.S| 2 +-
arch/sparc/lib/U3copy_from_user.S| 2 +-
arch/sparc/lib/U3copy_to_user.S | 2 +-
arch/sparc/lib/U3memcpy.S| 2 +-
arch/sparc/lib/U3patch.S | 2 +-
arch/sparc/lib/VISsave.S | 2 +-
arch/sparc/lib/ashldi3.S | 2 +-
arch/sparc/lib/ashrdi3.S | 2 +-
arch/sparc/lib/atomic32.c| 2 +-
arch/sparc/lib/atomic_64.S | 2 +-
arch/sparc/lib/bitext.c | 2 +-
arch/sparc/lib/bitops.S | 2 +-
arch/sparc/lib/blockops.S| 2 +-
arch/sparc/lib/bzero.S | 2 +-
arch/sparc/lib/checksum_32.S | 2 +-
arch/sparc/lib/checksum_64.S | 2 +-
arch/sparc/lib/clear_page.S | 2 +-
arch/sparc/lib/cmpdi2.c | 2 +-
arch/sparc/lib/copy_in_user.S| 2 +-
arch/sparc/lib/copy_page.S | 2 +-
arch/sparc/lib/copy_user.S | 2 +-
arch/sparc/lib/csum_copy.S | 2 +-
arch/sparc/lib/csum_copy_from_user.S | 2 +-
arch/sparc/lib/csum_copy_to_user.S | 2 +-
arch/sparc/lib/divdi3.S | 2 +-
arch/sparc/lib/ffs.S | 2 +-
arch/sparc/lib/hweight.S | 2 +-
arch/sparc/lib/iomap.c | 2 +-
arch/sparc/lib/ipcsum.S | 2 +-
arch/sparc/lib/libgcc.h | 2 +-
arch/sparc/lib/locks.S | 2 +-
arch/sparc/lib/lshrdi3.S | 2 +-
arch/sparc/lib/mcount.S | 2 +-
arch/sparc/lib/memcmp.S | 2 +-
arch/sparc/lib/memcpy.S | 2 +-
arch/sparc/lib/memmove.S | 2 +-
arch/sparc/lib/memscan_32.S | 2 +-
arch/sparc/lib/memscan_64.S | 2 +-
arch/sparc/lib/memset.S | 2 +-
arch/sparc/lib/muldi3.S | 2 +-
arch/sparc/lib/multi3.S | 2 +-
arch/sparc/lib/strlen.S | 2 +-
arch/sparc/lib/strncmp_32.S | 2 +-
arch/sparc/lib/strncmp_64.S | 2 +-
arch/sparc/lib/ucmpdi2.c | 2 +-
arch/sparc/lib/udivdi3.S | 2 +-
arch/sparc/lib/xor.S | 2 +-
74 files changed, 74 insertions(+), 74 deletions(-)
diff --git a/arch/sparc/lib/GENbzero.S b/arch/sparc/lib/GENbzero.S
index 63d618857d49..534347838dc2 100644
--- a/arch/sparc/lib/GENbzero.S
+++ b/arch/sparc/lib/GENbzero.S
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: LGPL-2.0+ */
/* GENbzero.S: Generic sparc64 memset/clear_user.
*
* Copyright (C) 2007 David S. Miller (da...@davemloft.net)
diff --git a/arch/sparc/lib/GENcopy_from_user.S b/arch/sparc/lib/GENcopy_from_user.S
index 6891a5678ea3..eede85e30109 100644
--- a/arch/sparc/lib/GENcopy_from_user.S
+++ b/a
Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
Hi Boris,
>
> Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
>
> On Tue, 18 Jun 2019 08:14:36 +0200
> Boris Brezillon wrote:
>
> > > > > > >
> > > > > > > How to make all #CS keep high for NAND to enter
> > > > > > > low-power standby mode if driver don't use
"legacy.select_chip()"
> > > ?
> > > > > >
> > > > > > See commit 02b4a52604a4 ("mtd: rawnand: Make ->select_chip()
> > > optional
> > > > > > when ->exec_op() is implemented") which states:
> > > > > >
> > > > > > "When [->select_chip() is] not implemented, the core
is
> > > assuming
> > > > > >the CS line is automatically asserted/deasserted by the
driver
> > > > > >->exec_op() implementation."
> > > > > >
> > > > > > Of course, the above is right only when the controller driver
> > > supports
> > > > > > the ->exec_op() interface.
> > > > >
> > > > > Currently, it seems that we will get the incorrect data and
error
> > > > > operation due to CS in error toggling if CS line is controlled
in
> > > > > ->exec_op().
>
> Oh, and please provide the modifications you added on top of this patch.
> Right now we're speculating on what you've done which is definitely not
> an efficient way to debug this sort of issues.
The patch is to add in beginning of ->exec_op() to control CS# low and
before return from ->exec_op() to control CS# High.
i.e,.
static in mxic_nand_exec_op( )
{
cs_to_low();
cs_to_high();
return;
}
But for nand_onfi_detect(),
it calls nand_read_param_page_op() and then nand_read_data_op().
mxic_nand_exec_op() be called twice for nand_onfi_detect() and
driver will get incorrect ONFI parameter table data from
nand_read_data_op().
thanks & best regards,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or
personal data, which is protected by applicable laws. Please be reminded that
duplication, disclosure, distribution, or use of this e-mail (and/or its
attachments) or any part thereof is prohibited. If you receive this e-mail in
error, please notify us immediately and delete this mail as well as its
attachment(s) from your system. In addition, please be informed that
collection, processing, and/or use of personal data is prohibited unless
expressly permitted by personal data protection laws. Thank you for your
attention and cooperation.
Macronix International Co., Ltd.
=
[PATCH] mm: vmscan: fix not scanning anonymous pages when detecting file refaults
When file refaults are detected and there are many inactive file pages,
the system never reclaim anonymous pages, the file pages are dropped
aggressively when there are still a lot of cold anonymous pages and
system thrashes. This issue impacts the performance of applications with
large executable, e.g. chrome.
When file refaults are detected. inactive_list_is_low() may return
different values depends on the actual_reclaim parameter, the following
2 conditions could be satisfied at the same time.
1) inactive_list_is_low() returns false in get_scan_count() to trigger
scanning file lists only.
2) inactive_list_is_low() returns true in shrink_list() to allow
scanning active file list.
In that case vmscan would only scan file lists, and as active file list
is also scanned, inactive_list_is_low() may keep returning false in
get_scan_count() until file cache is very low.
Before commit 2a2e48854d70 ("mm: vmscan: fix IO/refault regression in
cache workingset transition"), inactive_list_is_low() never returns
different value in get_scan_count() and shrink_list() in one
shrink_node_memcg() run. The original design should be that when
inactive_list_is_low() returns false for file lists, vmscan only scan
inactive file list. As only inactive file list is scanned,
inactive_list_is_low() would soon return true.
This patch makes the return value of inactive_list_is_low() independent
of actual_reclaim.
The problem can be reproduced by the following test program.
---8<---
void fallocate_file(const char *filename, off_t size)
{
struct stat st;
int fd;
if (!stat(filename, &st) && st.st_size >= size)
return;
fd = open(filename, O_WRONLY | O_CREAT, 0600);
if (fd < 0) {
perror("create file");
exit(1);
}
if (posix_fallocate(fd, 0, size)) {
perror("fallocate");
exit(1);
}
close(fd);
}
long *alloc_anon(long size)
{
long *start = malloc(size);
memset(start, 1, size);
return start;
}
long access_file(const char *filename, long size, long rounds)
{
int fd, i;
volatile char *start1, *end1, *start2;
const int page_size = getpagesize();
long sum = 0;
fd = open(filename, O_RDONLY);
if (fd == -1) {
perror("open");
exit(1);
}
/*
* Some applications, e.g. chrome, use a lot of executable file
* pages, map some of the pages with PROT_EXEC flag to simulate
* the behavior.
*/
start1 = mmap(NULL, size / 2, PROT_READ | PROT_EXEC, MAP_SHARED,
fd, 0);
if (start1 == MAP_FAILED) {
perror("mmap");
exit(1);
}
end1 = start1 + size / 2;
start2 = mmap(NULL, size / 2, PROT_READ, MAP_SHARED, fd, size / 2);
if (start2 == MAP_FAILED) {
perror("mmap");
exit(1);
}
for (i = 0; i < rounds; ++i) {
struct timeval before, after;
volatile char *ptr1 = start1, *ptr2 = start2;
gettimeofday(&before, NULL);
for (; ptr1 < end1; ptr1 += page_size, ptr2 += page_size)
sum += *ptr1 + *ptr2;
gettimeofday(&after, NULL);
printf("File access time, round %d: %f (sec)\n", i,
(after.tv_sec - before.tv_sec) +
(after.tv_usec - before.tv_usec) / 100.0);
}
return sum;
}
int main(int argc, char *argv[])
{
const long MB = 1024 * 1024;
long anon_mb, file_mb, file_rounds;
const char filename[] = "large";
long *ret1;
long ret2;
if (argc != 4) {
printf("usage: thrash ANON_MB FILE_MB FILE_ROUNDS\n");
exit(0);
}
anon_mb = atoi(argv[1]);
file_mb = atoi(argv[2]);
file_rounds = atoi(argv[3]);
fallocate_file(filename, file_mb * MB);
printf("Allocate %ld MB anonymous pages\n", anon_mb);
ret1 = alloc_anon(anon_mb * MB);
printf("Access %ld MB file pages\n", file_mb);
ret2 = access_file(filename, file_mb * MB, file_rounds);
printf("Print result to prevent optimization: %ld\n",
*ret1 + ret2);
return 0;
}
---8<---
Running the test program on 2GB RAM VM with kernel 5.2.0-rc5, the
program fills ram with 2048 MB memory, access a 200 MB file for 10
times. Without this patch, the file cache is dropped aggresively and
every access to the file is from disk.
$ ./thrash 2048 200 10
Allocate 2048 MB anonymous pages
Access 200 MB file pages
File access time, round 0: 2.489316 (sec)
File access time, round 1: 2.581277 (sec)
File access time, round 2: 2.487624 (sec)
File access time, round 3: 2.449100 (sec)
File access time, round 4: 2.420423 (sec)
File access tim
[tip:WIP.x86/ipi 3/11] arch/x86/kernel/nmi.c:515:46: error: 'cpu_is_dead' undeclared; did you mean 'cpuid_eax'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/ipi
head: 0663387727c00bb25ce1e76f30deb6b193f591f8
commit: 8adde844ea4f8d0d147e0ad6c675970a58550bae [3/11] x86/hotplug: Silence
APIC and NMI when CPU is dead
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 8adde844ea4f8d0d147e0ad6c675970a58550bae
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from include/asm-generic/percpu.h:7:0,
from arch/x86/include/asm/percpu.h:544,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from arch/x86/kernel/nmi.c:14:
arch/x86/kernel/nmi.c: In function 'do_nmi':
>> arch/x86/kernel/nmi.c:515:46: error: 'cpu_is_dead' undeclared (first use in
>> this function); did you mean 'cpuid_eax'?
if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
^
include/linux/percpu-defs.h:319:9: note: in definition of macro
'__pcpu_size_call_return'
typeof(variable) pscr_ret__; \
^~~~
arch/x86/kernel/nmi.c:515:32: note: in expansion of macro 'this_cpu_read'
if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
^
arch/x86/kernel/nmi.c:515:46: note: each undeclared identifier is reported
only once for each function it appears in
if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
^
include/linux/percpu-defs.h:319:9: note: in definition of macro
'__pcpu_size_call_return'
typeof(variable) pscr_ret__; \
^~~~
arch/x86/kernel/nmi.c:515:32: note: in expansion of macro 'this_cpu_read'
if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
^
vim +515 arch/x86/kernel/nmi.c
511
512 dotraplinkage notrace void
513 do_nmi(struct pt_regs *regs, long error_code)
514 {
> 515 if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
516 return;
517
518 if (this_cpu_read(nmi_state) != NMI_NOT_RUNNING) {
519 this_cpu_write(nmi_state, NMI_LATCHED);
520 return;
521 }
522 this_cpu_write(nmi_state, NMI_EXECUTING);
523 this_cpu_write(nmi_cr2, read_cr2());
524 nmi_restart:
525
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
Hi Mason,
masonccy...@mxic.com.tw wrote on Wed, 19 Jun 2019 16:04:43 +0800:
> Hi Boris,
>
> >
> > Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
> >
> > On Tue, 18 Jun 2019 08:14:36 +0200
> > Boris Brezillon wrote:
> >
> > > > > > > >
> > > > > > > > How to make all #CS keep high for NAND to enter
> > > > > > > > low-power standby mode if driver don't use
> "legacy.select_chip()"
> > > > ?
> > > > > > >
> > > > > > > See commit 02b4a52604a4 ("mtd: rawnand: Make ->select_chip()
> > > > optional
> > > > > > > when ->exec_op() is implemented") which states:
> > > > > > >
> > > > > > > "When [->select_chip() is] not implemented, the core
> is
> > > > assuming
> > > > > > >the CS line is automatically asserted/deasserted by the
> driver
> > > > > > >->exec_op() implementation."
> > > > > > >
> > > > > > > Of course, the above is right only when the controller driver
>
> > > > supports
> > > > > > > the ->exec_op() interface.
> > > > > >
> > > > > > Currently, it seems that we will get the incorrect data and
> error
> > > > > > operation due to CS in error toggling if CS line is controlled
> in
> > > > > > ->exec_op().
> >
> > Oh, and please provide the modifications you added on top of this patch.
> > Right now we're speculating on what you've done which is definitely not
> > an efficient way to debug this sort of issues.
>
We really need to see the datasheet of the NAND chip which has a
problem and how this LPM mode is advertized to understand what the
chip expects and eventually how to work-around it.
> The patch is to add in beginning of ->exec_op() to control CS# low and
> before return from ->exec_op() to control CS# High.
> i.e,.
> static in mxic_nand_exec_op( )
> {
> cs_to_low();
>
>
>
> cs_to_high();
> return;
> }
>
> But for nand_onfi_detect(),
> it calls nand_read_param_page_op() and then nand_read_data_op().
> mxic_nand_exec_op() be called twice for nand_onfi_detect()
Yes, this is expected and usually chips don't care.
> and
> driver will get incorrect ONFI parameter table data from
> nand_read_data_op().
>
Thanks,
Miquèl
Re: [PATCH 1/2] scsi_host: add support for request batching
On 5/30/19 1:28 PM, Paolo Bonzini wrote:
> This allows a list of requests to be issued, with the LLD only writing
> the hardware doorbell when necessary, after the last request was prepared.
> This is more efficient if we have lists of requests to issue, particularly
> on virtualized hardware, where writing the doorbell is more expensive than
> on real hardware.
>
> The use case for this is plugged IO, where blk-mq flushes a batch of
> requests all at once.
>
> The API is the same as for blk-mq, just with blk-mq concepts tweaked to
> fit the SCSI subsystem API: the "last" flag in blk_mq_queue_data becomes
> a flag in scsi_cmnd, while the queue_num in the commit_rqs callback is
> extracted from the hctx and passed as a parameter.
>
> The only complication is that blk-mq uses different plugging heuristics
> depending on whether commit_rqs is present or not. So we have two
> different sets of blk_mq_ops and pick one depending on whether the
> scsi_host template uses commit_rqs or not.
>
> Signed-off-by: Paolo Bonzini
> ---
> drivers/scsi/scsi_lib.c | 37 ++---
> include/scsi/scsi_cmnd.h | 1 +
> include/scsi/scsi_host.h | 16 ++--
> 3 files changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 601b9f1de267..eb4e67d02bfe 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1673,10 +1673,11 @@ static blk_status_t scsi_queue_rq(struct
> blk_mq_hw_ctx *hctx,
> blk_mq_start_request(req);
> }
>
> + cmd->flags &= SCMD_PRESERVED_FLAGS;
> if (sdev->simple_tags)
> cmd->flags |= SCMD_TAGGED;
> - else
> - cmd->flags &= ~SCMD_TAGGED;
> + if (bd->last)
> + cmd->flags |= SCMD_LAST;
>
> scsi_init_cmd_errh(cmd);
> cmd->scsi_done = scsi_mq_done;
> @@ -1807,10 +1808,37 @@ void __scsi_init_queue(struct Scsi_Host *shost,
> struct request_queue *q)
> }
> EXPORT_SYMBOL_GPL(__scsi_init_queue);
>
> +static const struct blk_mq_ops scsi_mq_ops_no_commit = {
> + .get_budget = scsi_mq_get_budget,
> + .put_budget = scsi_mq_put_budget,
> + .queue_rq = scsi_queue_rq,
> + .complete = scsi_softirq_done,
> + .timeout= scsi_timeout,
> +#ifdef CONFIG_BLK_DEBUG_FS
> + .show_rq= scsi_show_rq,
> +#endif
> + .init_request = scsi_mq_init_request,
> + .exit_request = scsi_mq_exit_request,
> + .initialize_rq_fn = scsi_initialize_rq,
> + .busy = scsi_mq_lld_busy,
> + .map_queues = scsi_map_queues,
> +};
> +
> +
> +static void scsi_commit_rqs(struct blk_mq_hw_ctx *hctx)
> +{
> + struct request_queue *q = hctx->queue;
> + struct scsi_device *sdev = q->queuedata;
> + struct Scsi_Host *shost = sdev->host;
> +
> + shost->hostt->commit_rqs(shost, hctx->queue_num);
> +}
> +
> static const struct blk_mq_ops scsi_mq_ops = {
> .get_budget = scsi_mq_get_budget,
> .put_budget = scsi_mq_put_budget,
> .queue_rq = scsi_queue_rq,
> + .commit_rqs = scsi_commit_rqs,
> .complete = scsi_softirq_done,
> .timeout= scsi_timeout,
> #ifdef CONFIG_BLK_DEBUG_FS
> @@ -1845,7 +1873,10 @@ int scsi_mq_setup_tags(struct Scsi_Host *shost)
> cmd_size += sizeof(struct scsi_data_buffer) + sgl_size;
>
> memset(&shost->tag_set, 0, sizeof(shost->tag_set));
> - shost->tag_set.ops = &scsi_mq_ops;
> + if (shost->hostt->commit_rqs)
> + shost->tag_set.ops = &scsi_mq_ops;
> + else
> + shost->tag_set.ops = &scsi_mq_ops_no_commit;
> shost->tag_set.nr_hw_queues = shost->nr_hw_queues ? : 1;
> shost->tag_set.queue_depth = shost->can_queue;
> shost->tag_set.cmd_size = cmd_size;
> diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
> index 76ed5e4acd38..91bd749a02f7 100644
> --- a/include/scsi/scsi_cmnd.h
> +++ b/include/scsi/scsi_cmnd.h
> @@ -57,6 +57,7 @@ struct scsi_pointer {
> #define SCMD_TAGGED (1 << 0)
> #define SCMD_UNCHECKED_ISA_DMA (1 << 1)
> #define SCMD_INITIALIZED (1 << 2)
> +#define SCMD_LAST(1 << 3)
> /* flags preserved across unprep / reprep */
> #define SCMD_PRESERVED_FLAGS (SCMD_UNCHECKED_ISA_DMA | SCMD_INITIALIZED)
>
> diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
> index 2b539a1b3f62..28f1c9177cd2 100644
> --- a/include/scsi/scsi_host.h
> +++ b/include/scsi/scsi_host.h
> @@ -80,8 +80,10 @@ struct scsi_host_template {
>* command block to the LLDD. When the driver finished
>* processing the command the done callback is invoked.
>*
> - * If queuecommand returns 0, then the HBA has accepted the
> - * command. The done() function must be called on the command
> + * If queuecommand returns 0, then the driver has accepted the
> + * command. It must also push it to the HBA if the scsi_cmnd
Re: [PATCH] ARC: ARCv2: jump label: implement jump label patching
On Tue, Jun 18, 2019 at 04:16:20PM +, Vineet Gupta wrote:
> > +/*
> > + * To make atomic update of patched instruction available we need to
> > guarantee
> > + * that this instruction doesn't cross L1 cache line boundary.
> > + *
Oh urgh. Is that the only way ARC can do text patching? We've actually
considered something like this on x86 at some point, but there we have
the 'fun' detail that the i-fetch window does not in fact align with L1
size on all uarchs, so that got complicated real fast.
I'm assuming you've looked at what x86 currently does and found
something like that doesn't work for ARC?
> > +/* Halt system on fatal error to make debug easier */
> > +#define arc_jl_fatal(format...)
> > \
> > +({ \
> > + pr_err(JUMPLABEL_ERR format); \
> > + BUG(); \
>
> Does it make sense to bring down the whole system vs. failing and returning.
> I see there is no error propagation to core code, but still.
It is what x86 does. And I've been fairly adamant about doing so. When
the kernel text is compromised, do you really want to continue running
it?
> > +})
> > +
> > +static inline u32 arc_gen_nop(void)
> > +{
> > + /* 1x 32bit NOP in middle endian */
I dare not ask...
> > + return 0x7000264a;
> > +}
> > +
> > + /*
> > +* All instructions are aligned by 2 bytes so we should never get offset
> > +* here which is not 2 bytes aligned.
> > +*/
> > + WRITE_ONCE(*instr_addr, instr);
> > + flush_icache_range(entry->code, entry->code + JUMP_LABEL_NOP_SIZE);
So do you have a 2 byte opcode that traps unconditionally? In that case
I'm thinking you could do something like x86 does. And it would avoid
that NOP padding you do to get the alignment.
[tip:WIP.x86/ipi 8/11] arch/x86/kernel/apic/ipi.c:48:6: error: redefinition of 'apic_smt_update'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/ipi
head: 0663387727c00bb25ce1e76f30deb6b193f591f8
commit: b3b483a0796da8f2c0d91b8594ef0ae593ec29fb [8/11] x86/apic: Add static
key to Control IPI shorthands
config: x86_64-randconfig-x015-201924 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout b3b483a0796da8f2c0d91b8594ef0ae593ec29fb
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> arch/x86/kernel/apic/ipi.c:48:6: error: redefinition of 'apic_smt_update'
void apic_smt_update(void)
^~~
In file included from arch/x86/include/asm/smp.h:13:0,
from arch/x86/kernel/apic/ipi.c:13:
arch/x86/include/asm/apic.h:72:20: note: previous definition of
'apic_smt_update' was here
static inline void apic_smt_update(void) {}
^~~
vim +/apic_smt_update +48 arch/x86/kernel/apic/ipi.c
47
> 48 void apic_smt_update(void)
49 {
50 if (!cpumask_equal(cpu_present_mask, &cpus_booted_once_mask))
51 static_branch_disable(&apic_use_ipi_shorthand);
52 else if (!apic_ipi_shorthand_off)
53 static_branch_enable(&apic_use_ipi_shorthand);
54 }
55
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
On Wed, 19 Jun 2019 16:04:43 +0800
masonccy...@mxic.com.tw wrote:
> Hi Boris,
>
> >
> > Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
> >
> > On Tue, 18 Jun 2019 08:14:36 +0200
> > Boris Brezillon wrote:
> >
> > > > > > > >
> > > > > > > > How to make all #CS keep high for NAND to enter
> > > > > > > > low-power standby mode if driver don't use
> "legacy.select_chip()"
> > > > ?
> > > > > > >
> > > > > > > See commit 02b4a52604a4 ("mtd: rawnand: Make ->select_chip()
> > > > optional
> > > > > > > when ->exec_op() is implemented") which states:
> > > > > > >
> > > > > > > "When [->select_chip() is] not implemented, the core
> is
> > > > assuming
> > > > > > >the CS line is automatically asserted/deasserted by the
> driver
> > > > > > >->exec_op() implementation."
> > > > > > >
> > > > > > > Of course, the above is right only when the controller driver
>
> > > > supports
> > > > > > > the ->exec_op() interface.
> > > > > >
> > > > > > Currently, it seems that we will get the incorrect data and
> error
> > > > > > operation due to CS in error toggling if CS line is controlled
> in
> > > > > > ->exec_op().
> >
> > Oh, and please provide the modifications you added on top of this patch.
> > Right now we're speculating on what you've done which is definitely not
> > an efficient way to debug this sort of issues.
>
> The patch is to add in beginning of ->exec_op() to control CS# low and
> before return from ->exec_op() to control CS# High.
> i.e,.
> static in mxic_nand_exec_op( )
> {
> cs_to_low();
>
>
>
> cs_to_high();
> return;
> }
>
> But for nand_onfi_detect(),
> it calls nand_read_param_page_op() and then nand_read_data_op().
> mxic_nand_exec_op() be called twice for nand_onfi_detect() and
> driver will get incorrect ONFI parameter table data from
> nand_read_data_op().
And I think it's valid to release the CE pin between
read_param_page_op() (CMD(0xEC)+ADDR(0x0)) and read_data_op() (data
cycles) if your chip is CE-dont-care compliant. So, either you have a
problem with your controller driver (CS-related timings are incorrect)
or your chip is not CE-dont-care compliant.
Re: [PATCH V3 11/17] clk: tegra210: support for Tegra210 clocks suspend and resume
On Tue, Jun 18, 2019 at 10:58:40AM -0700, Sowjanya Komatineni wrote:
>
> On 6/18/19 5:16 AM, Thierry Reding wrote:
> > On Tue, Jun 18, 2019 at 12:46:25AM -0700, Sowjanya Komatineni wrote:
> > > This patch adds system suspend and resume support for Tegra210
> > > clocks.
> > >
> > > All the CAR controller settings are lost on suspend when core power
> > > goes off.
> > >
> > > This patch has implementation for saving and restoring all the PLLs
> > > and clocks context during system suspend and resume to have the
> > > system back to operating state.
> > >
> > > Signed-off-by: Sowjanya Komatineni
> > > ---
> > > drivers/clk/tegra/clk-tegra210.c | 218
> > > +--
> > > 1 file changed, 211 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/clk/tegra/clk-tegra210.c
> > > b/drivers/clk/tegra/clk-tegra210.c
> > > index e1ba62d2b1a0..c34d92e871f4 100644
> > > --- a/drivers/clk/tegra/clk-tegra210.c
> > > +++ b/drivers/clk/tegra/clk-tegra210.c
> > > @@ -9,10 +9,12 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -20,6 +22,7 @@
> > > #include
> > > #include "clk.h"
> > > +#include "clk-dfll.h"
> > > #include "clk-id.h"
> > > /*
> > > @@ -36,6 +39,8 @@
> > > #define CLK_SOURCE_LA 0x1f8
> > > #define CLK_SOURCE_SDMMC2 0x154
> > > #define CLK_SOURCE_SDMMC4 0x164
> > > +#define CLK_OUT_ENB_Y 0x298
> > > +#define CLK_ENB_PLLP_OUT_CPU BIT(31)
> > > #define PLLC_BASE 0x80
> > > #define PLLC_OUT 0x84
> > > @@ -225,6 +230,7 @@
> > > #define CLK_RST_CONTROLLER_RST_DEV_Y_SET 0x2a8
> > > #define CLK_RST_CONTROLLER_RST_DEV_Y_CLR 0x2ac
> > > +#define CPU_SOFTRST_CTRL 0x380
> > > #define LVL2_CLK_GATE_OVRA 0xf8
> > > #define LVL2_CLK_GATE_OVRC 0x3a0
> > > @@ -2820,6 +2826,7 @@ static int tegra210_enable_pllu(void)
> > > struct tegra_clk_pll_freq_table *fentry;
> > > struct tegra_clk_pll pllu;
> > > u32 reg;
> > > + int ret;
> > > for (fentry = pll_u_freq_table; fentry->input_rate; fentry++) {
> > > if (fentry->input_rate == pll_ref_freq)
> > > @@ -2836,7 +2843,7 @@ static int tegra210_enable_pllu(void)
> > > reg = readl_relaxed(clk_base + pllu.params->ext_misc_reg[0]);
> > > reg &= ~BIT(pllu.params->iddq_bit_idx);
> > > writel_relaxed(reg, clk_base + pllu.params->ext_misc_reg[0]);
> > > - udelay(5);
> > > + fence_udelay(5, clk_base);
> > > reg = readl_relaxed(clk_base + PLLU_BASE);
> > > reg &= ~GENMASK(20, 0);
> > > @@ -2844,13 +2851,13 @@ static int tegra210_enable_pllu(void)
> > > reg |= fentry->n << 8;
> > > reg |= fentry->p << 16;
> > > writel(reg, clk_base + PLLU_BASE);
> > > - udelay(1);
> > > + fence_udelay(1, clk_base);
> > These udelay() -> fence_udelay() seem like they should be a separate
> > patch.
> >
> > > reg |= PLL_ENABLE;
> > > writel(reg, clk_base + PLLU_BASE);
> > > + fence_udelay(1, clk_base);
> > > - readl_relaxed_poll_timeout_atomic(clk_base + PLLU_BASE, reg,
> > > - reg & PLL_BASE_LOCK, 2, 1000);
> > > - if (!(reg & PLL_BASE_LOCK)) {
> > > + ret = tegra210_wait_for_mask(&pllu, PLLU_BASE, PLL_BASE_LOCK);
> > > + if (ret) {
> > > pr_err("Timed out waiting for PLL_U to lock\n");
> > > return -ETIMEDOUT;
> > > }
> > > @@ -2890,12 +2897,12 @@ static int tegra210_init_pllu(void)
> > > reg = readl_relaxed(clk_base + XUSB_PLL_CFG0);
> > > reg &= ~XUSB_PLL_CFG0_PLLU_LOCK_DLY_MASK;
> > > writel_relaxed(reg, clk_base + XUSB_PLL_CFG0);
> > > - udelay(1);
> > > + fence_udelay(1, clk_base);
> > > reg = readl_relaxed(clk_base + PLLU_HW_PWRDN_CFG0);
> > > reg |= PLLU_HW_PWRDN_CFG0_SEQ_ENABLE;
> > > writel_relaxed(reg, clk_base + PLLU_HW_PWRDN_CFG0);
> > > - udelay(1);
> > > + fence_udelay(1, clk_base);
> > > reg = readl_relaxed(clk_base + PLLU_BASE);
> > > reg &= ~PLLU_BASE_CLKENABLE_USB;
> > > @@ -3282,6 +3289,188 @@ static void tegra210_disable_cpu_clock(u32 cpu)
> > > }
> > > #ifdef CONFIG_PM_SLEEP
> > > +static u32 cpu_softrst_ctx[3];
> > > +static struct platform_device *dfll_pdev;
> > > +static u32 *periph_clk_src_ctx;
> > > +struct periph_source_bank {
> > Blank line between the above two.
> >
> > > + u32 start;
> > > + u32 end;
> > > +};
> > > +
> > > +static struct periph_source_bank periph_srcs[] = {
> > > + [0] = {
> > > + .start = 0x100,
> > > + .end = 0x198,
> > > + },
> > > + [1] = {
> > > + .start = 0x1a0,
> > > + .end = 0x1f8,
> > > + },
> > > + [2] = {
> > > + .start = 0x3b4,
> > > + .end =
Re: [PATCH v5 02/10] [media] marvell-ccic: fix DMA s/g desc number calculation
On Fri, 2019-06-14 at 11:41 +0200, Jacopo Mondi wrote:
> Hi Lubomir,
>
> On Sun, May 05, 2019 at 04:00:23PM +0200, Lubomir Rintel wrote:
> > The commit d790b7eda953 ("[media] vb2-dma-sg: move dma_(un)map_sg here")
> > left dma_desc_nent unset. It previously contained the number of DMA
> > descriptors as returned from dma_map_sg().
> >
> > We can now (since the commit referred to above) obtain the same value from
> > the sg_table and drop dma_desc_nent altogether.
> >
> > Tested on OLPC XO-1.75 machine. Doesn't affect the OLPC XO-1's Cafe
> > driver, since that one doesn't do DMA.
> >
> > Fixes: d790b7eda953df474f470169ebdf111c02fa7a2d
>
> Could you use the proper 'fixes' format here?
> Fixes: d790b7eda953 ("[media] vb2-dma-sg: move dma_(un)map_sg here")
>
> > Signed-off-by: Lubomir Rintel
> > ---
> > drivers/media/platform/marvell-ccic/mcam-core.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
> > b/drivers/media/platform/marvell-ccic/mcam-core.c
> > index f1b301810260a..d97f39bde9bd6 100644
> > --- a/drivers/media/platform/marvell-ccic/mcam-core.c
> > +++ b/drivers/media/platform/marvell-ccic/mcam-core.c
> > @@ -200,7 +200,6 @@ struct mcam_vb_buffer {
> > struct list_head queue;
> > struct mcam_dma_desc *dma_desc; /* Descriptor virtual address */
> > dma_addr_t dma_desc_pa; /* Descriptor physical address */
> > - int dma_desc_nent; /* Number of mapped descriptors */
> > };
> >
> > static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_v4l2_buffer *vb)
> > @@ -608,9 +607,11 @@ static void mcam_dma_contig_done(struct mcam_camera
> > *cam, int frame)
> > static void mcam_sg_next_buffer(struct mcam_camera *cam)
> > {
> > struct mcam_vb_buffer *buf;
> > + struct sg_table *sg_table;
> >
> > buf = list_first_entry(&cam->buffers, struct mcam_vb_buffer, queue);
> > list_del_init(&buf->queue);
> > + sg_table = vb2_dma_sg_plane_desc(&buf->vb_buf.vb2_buf, 0);
> > /*
> > * Very Bad Not Good Things happen if you don't clear
> > * C1_DESC_ENA before making any descriptor changes.
> > @@ -618,7 +619,7 @@ static void mcam_sg_next_buffer(struct mcam_camera *cam)
> > mcam_reg_clear_bit(cam, REG_CTRL1, C1_DESC_ENA);
> > mcam_reg_write(cam, REG_DMA_DESC_Y, buf->dma_desc_pa);
> > mcam_reg_write(cam, REG_DESC_LEN_Y,
> > - buf->dma_desc_nent*sizeof(struct mcam_dma_desc));
> > + sg_table->nents*sizeof(struct mcam_dma_desc));
>
> Space betwen operators (it was there already, I know).
>
> Apart for that, patch seems fine to me:
> Reviewed-by: Jacopo Mondi
This has been already applied to media_tree.git, with the Fixes: tag
corrected by Mauro Chehab.
I suppose I can't make changes anymore and the space-between-operators
things is not worth fixing up in a separate commit?
> Thanks
>j
> > mcam_reg_write(cam, REG_DESC_LEN_U, 0);
> > mcam_reg_write(cam, REG_DESC_LEN_V, 0);
> > mcam_reg_set_bit(cam, REG_CTRL1, C1_DESC_ENA);
> >
Thank you
Lubo
Re: [PATCH] usbip: Implement map_urb_for_dma function for vhci to skip dma mapping
On Tue, Jun 18, 2019 at 11:30:34AM -0400, Alan Stern wrote:
> On Tue, 18 Jun 2019, Suwan Kim wrote:
>
> > vhci doesn’t do dma for remote device. Actually, the real dma
> > operation is done by network card driver. So, vhci doesn’t use and
> > need dma address of transfer buffer of urb.
> >
> > But hcd provides dma mapping function by defualt in usb_hcd_submit_urb()
> > and it causes unnecessary dma mapping which will be done again at
> > NIC driver and it wastes CPU cycles. So, implement map_urb_for_dma
> > function for vhci in order to skip the dma mapping procedure.
> >
> > Signed-off-by: Suwan Kim
> > ---
> > drivers/usb/usbip/vhci_hcd.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> > index 667d9c0ec905..9df4d9e36788 100644
> > --- a/drivers/usb/usbip/vhci_hcd.c
> > +++ b/drivers/usb/usbip/vhci_hcd.c
> > @@ -1287,6 +1287,13 @@ static int vhci_free_streams(struct usb_hcd *hcd,
> > struct usb_device *udev,
> > return 0;
> > }
> >
> > +static int vhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
> > + gfp_t mem_flags)
> > +{
> > + dev_dbg(hcd->self.controller, "vhci does not map urb for dma\n");
> > + return 0;
> > +}
> > +
> > static const struct hc_driver vhci_hc_driver = {
> > .description= driver_name,
> > .product_desc = driver_desc,
> > @@ -1302,6 +1309,7 @@ static const struct hc_driver vhci_hc_driver = {
> > .urb_dequeue= vhci_urb_dequeue,
> >
> > .get_frame_number = vhci_get_frame_number,
> > + .map_urb_for_dma = vhci_map_urb_for_dma,
> >
> > .hub_status_data = vhci_hub_status,
> > .hub_control= vhci_hub_control,
>
> If the goal is to avoid wasting CPU cycles, you probably should have a
> vhci_unmap_urb_for_dma routine as well.
I missed that. Thank you for pointing it out.
I will send v2 including unmap function.
Regards
Suwan Kim
Re: [PATCH] mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind
On 6/18/19 7:06 PM, Yang Shi wrote:
> The BUG_ON was removed by commit
> d44d363f65780f2ac2ec672164555af54896d40d ("mm: don't assume anonymous
> pages have SwapBacked flag") since 4.12.
Perhaps that commit should be sent to stable@ ? Although with
VM_BUG_ON() this is less critical than plain BUG_ON().
Re: [PATCH v3 2/8] clocksource/drivers/tegra: Remove duplicated use of per_cpu_ptr
On Tue, Jun 18, 2019 at 05:03:52PM +0300, Dmitry Osipenko wrote: > It was left unnoticed by accident, which means that the code could be > cleaned up a tad more. > > Acked-by: Jon Hunter > Signed-off-by: Dmitry Osipenko > --- > drivers/clocksource/timer-tegra.c | 42 ++- > 1 file changed, 25 insertions(+), 17 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v3 1/8] clocksource/drivers/tegra: Restore timer rate on Tegra210
On Tue, Jun 18, 2019 at 05:03:51PM +0300, Dmitry Osipenko wrote:
> The clocksource rate is initialized only for the first per-CPU clocksource
> and then that rate shall be replicated for the rest of clocksource's
> because they are initialized manually in the code.
>
> Fixes: 3be2a85a0b61 ("clocksource/drivers/tegra: Support per-CPU timers on
> all Tegra's")
> Acked-by: Jon Hunter
> Tested-by: Jon Hunter
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/clocksource/timer-tegra.c | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
Re: [PATCH v3 4/8] clocksource/drivers/tegra: Drop unneeded typecasting in one place
On Tue, Jun 18, 2019 at 05:03:54PM +0300, Dmitry Osipenko wrote: > There is no need to cast void because kernel allows to do that without > a warning message from a compiler. > > Acked-by: Jon Hunter > Signed-off-by: Dmitry Osipenko > --- > drivers/clocksource/timer-tegra.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v3 5/8] clocksource/drivers/tegra: Add verbose definition for 1MHz constant
On Tue, Jun 18, 2019 at 05:03:55PM +0300, Dmitry Osipenko wrote: > Convert all 1MHz literals to a verbose constant for better readability. > > Suggested-by: Daniel Lezcano > Acked-by: Jon Hunter > Signed-off-by: Dmitry Osipenko > --- > drivers/clocksource/timer-tegra.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
[no subject]
ВНИМАНИЕ; В вашем почтовом ящике превышен лимит хранилища, который составляет 5 ГБ, как определено администратором, который в настоящее время работает на 10,9 ГБ. Возможно, вы не сможете отправлять или получать новую почту, пока вы не подтвердите свою почту. Чтобы подтвердить свой почтовый ящик, отправьте следующую информацию ниже: название: Имя пользователя: пароль: Подтвердите Пароль: Эл. адрес: Телефон: Если вы не сможете подтвердить свой почтовый ящик, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Код подтверждения: en: 006,524.RU Техническая поддержка почты © 2019 благодарю вас Системный администратор.
Re: [PATCH v3 3/8] clocksource/drivers/tegra: Set and use timer's period
On Tue, Jun 18, 2019 at 05:03:53PM +0300, Dmitry Osipenko wrote: > The of_clk structure has a period field that is set up initially by > timer_of_clk_init(), that period value need to be adjusted for a case of > TIMER1-9 that are running at a fixed rate that doesn't match the clock's > rate. Note that the period value is currently used only by some of the > clocksource drivers internally and hence this is just a minor cleanup > change that doesn't fix anything. > > Signed-off-by: Dmitry Osipenko > --- > drivers/clocksource/timer-tegra.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v3 7/8] clocksource/drivers/tegra: Cycles can't be 0
On Tue, Jun 18, 2019 at 05:03:57PM +0300, Dmitry Osipenko wrote: > Tegra's timer uses n+1 scheme for the counter, i.e. timer will fire after > one tick if 0 is loaded. The minimum and maximum numbers of oneshot ticks > are defined by clockevents_config_and_register(min, max) invocation and > the min value is set to 1 tick. Hence "cycles" value can't ever be 0, > unless it's a bug in clocksource core. > > Signed-off-by: Dmitry Osipenko > --- > drivers/clocksource/timer-tegra.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v3 6/8] clocksource/drivers/tegra: Restore base address before cleanup
On Tue, Jun 18, 2019 at 05:03:56PM +0300, Dmitry Osipenko wrote: > We're adjusting the timer's base for each per-CPU timer to point to the > actual start of the timer since device-tree defines a compound registers > range that includes all of the timers. In this case the original base > need to be restore before calling iounmap to unmap the proper address. > > Signed-off-by: Dmitry Osipenko > --- > drivers/clocksource/timer-tegra.c | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v3 8/8] clocksource/drivers/tegra: Set up maximum-ticks limit properly
On Tue, Jun 18, 2019 at 05:03:58PM +0300, Dmitry Osipenko wrote: > Tegra's timer has 29 bits for the counter and for the "load" register > which sets counter to a load-value. The counter's value is lower than > the actual value by 1 because it starts to decrement after one tick, > hence the maximum number of ticks that hardware can handle equals to > 29 bits + 1. > > Signed-off-by: Dmitry Osipenko > --- > drivers/clocksource/timer-tegra.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: bcachefs status update (it's done cooking; let's get this sucker merged)
On Thu 13-06-19 09:02:24, Dave Chinner wrote: > On Wed, Jun 12, 2019 at 12:21:44PM -0400, Kent Overstreet wrote: > > This would simplify things a lot and eliminate a really nasty corner case - > > page > > faults trigger readahead. Even if the buffer and the direct IO don't > > overlap, > > readahead can pull in pages that do overlap with the dio. > > Page cache readahead needs to be moved under the filesystem IO > locks. There was a recent thread about how readahead can race with > hole punching and other fallocate() operations because page cache > readahead bypasses the filesystem IO locks used to serialise page > cache invalidation. > > e.g. Readahead can be directed by userspace via fadvise, so we now > have file->f_op->fadvise() so that filesystems can lock the inode > before calling generic_fadvise() such that page cache instantiation > and readahead dispatch can be serialised against page cache > invalidation. I have a patch for XFS sitting around somewhere that > implements the ->fadvise method. > > I think there are some other patches floating around to address the > other readahead mechanisms to only be done under filesytem IO locks, > but I haven't had time to dig into it any further. Readahead from > page faults most definitely needs to be under the MMAPLOCK at > least so it serialises against fallocate()... Yes, I have patch to make madvise(MADV_WILLNEED) go through ->fadvise() as well. I'll post it soon since the rest of the series isn't really dependent on it. Honza -- Jan Kara SUSE Labs, CR
[tip:WIP.x86/ipi 3/11] arch/x86//kernel/nmi.c:515:32: note: in expansion of macro 'this_cpu_read'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/ipi
head: 0663387727c00bb25ce1e76f30deb6b193f591f8
commit: 8adde844ea4f8d0d147e0ad6c675970a58550bae [3/11] x86/hotplug: Silence
APIC and NMI when CPU is dead
config: i386-randconfig-x009-201924 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 8adde844ea4f8d0d147e0ad6c675970a58550bae
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/asm-generic/percpu.h:7:0,
from arch/x86/include/asm/percpu.h:544,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from arch/x86//kernel/nmi.c:14:
arch/x86//kernel/nmi.c: In function 'do_nmi':
arch/x86//kernel/nmi.c:515:46: error: 'cpu_is_dead' undeclared (first use in
this function); did you mean 'cpuid_eax'?
if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
^
include/linux/percpu-defs.h:319:9: note: in definition of macro
'__pcpu_size_call_return'
typeof(variable) pscr_ret__; \
^~~~
>> arch/x86//kernel/nmi.c:515:32: note: in expansion of macro 'this_cpu_read'
if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
^
arch/x86//kernel/nmi.c:515:46: note: each undeclared identifier is reported
only once for each function it appears in
if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
^
include/linux/percpu-defs.h:319:9: note: in definition of macro
'__pcpu_size_call_return'
typeof(variable) pscr_ret__; \
^~~~
>> arch/x86//kernel/nmi.c:515:32: note: in expansion of macro 'this_cpu_read'
if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
^
vim +/this_cpu_read +515 arch/x86//kernel/nmi.c
511
512 dotraplinkage notrace void
513 do_nmi(struct pt_regs *regs, long error_code)
514 {
> 515 if (IS_ENABLED(CONFIG_SMP) && this_cpu_read(cpu_is_dead))
516 return;
517
518 if (this_cpu_read(nmi_state) != NMI_NOT_RUNNING) {
519 this_cpu_write(nmi_state, NMI_LATCHED);
520 return;
521 }
522 this_cpu_write(nmi_state, NMI_EXECUTING);
523 this_cpu_write(nmi_cr2, read_cr2());
524 nmi_restart:
525
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind
On 6/19/19 7:21 AM, Michal Hocko wrote:
> On Tue 18-06-19 14:13:16, Yang Shi wrote:
> [...]
>>
>> I used to have !__PageMovable(page), but it was removed since the
>> aforementioned reason. I could add it back.
>>
>> For the temporary off LRU page, I did a quick search, it looks the most
>> paths have to acquire mmap_sem, so it can't race with us here. Page
>> reclaim/compaction looks like the only race. But, since the mapping should
>> be preserved even though the page is off LRU temporarily unless the page is
>> reclaimed, so we should be able to exclude temporary off LRU pages by
>> calling page_mapping() and page_anon_vma().
>>
>> So, the fix may look like:
>>
>> if (!PageLRU(head) && !__PageMovable(page)) {
>> if (!(page_mapping(page) || page_anon_vma(page)))
>> return -EIO;
>
> This is getting even more muddy TBH. Is there any reason that we have to
> handle this problem during the isolation phase rather the migration?
I think it was already said that if pages can't be isolated, then
migration phase won't process them, so they're just ignored.
However I think the patch is wrong to abort immediately when
encountering such page that cannot be isolated (AFAICS). IMHO it should
still try to migrate everything it can, and only then return -EIO.
RE: [PATCH v2] mei: no need to check return value of debugfs_create functions
>
> When calling debugfs functions, there is no need to ever check the return
> value. The function can work or not, but the code logic should never do
> something different based on this.
Maybe need to mention that API has changed in patch '
ff9fb72bc07705c00795ca48631f7fffe24d2c6b' in 5.0
and create_dir() doesn't return NULL but ERR_PTR() and proper checking is done
inside the debugfs functions.
Not sure how critical is that but, but this should go probably to stable 5.0+
as well.
Ack otherwise.
>
> Cc: Tomas Winkler
> Cc: Arnd Bergmann
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
> ---
> v2: break the patch up properly
>
> drivers/misc/mei/debugfs.c | 47 +-
> drivers/misc/mei/main.c| 8 +--
> drivers/misc/mei/mei_dev.h | 7 ++
> 3 files changed, 14 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c index
> 0970142bcace..df6bf8b81936 100644
> --- a/drivers/misc/mei/debugfs.c
> +++ b/drivers/misc/mei/debugfs.c
> @@ -233,47 +233,22 @@ void mei_dbgfs_deregister(struct mei_device *dev)
> *
> * @dev: the mei device structure
> * @name: the mei device name
> - *
> - * Return: 0 on success, <0 on failure.
> */
> -int mei_dbgfs_register(struct mei_device *dev, const char *name)
> +void mei_dbgfs_register(struct mei_device *dev, const char *name)
> {
> - struct dentry *dir, *f;
> + struct dentry *dir;
>
> dir = debugfs_create_dir(name, NULL);
> - if (!dir)
> - return -ENOMEM;
> -
> dev->dbgfs_dir = dir;
>
> - f = debugfs_create_file("meclients", S_IRUSR, dir,
> - dev, &mei_dbgfs_fops_meclients);
> - if (!f) {
> - dev_err(dev->dev, "meclients: registration failed\n");
> - goto err;
> - }
> - f = debugfs_create_file("active", S_IRUSR, dir,
> - dev, &mei_dbgfs_fops_active);
> - if (!f) {
> - dev_err(dev->dev, "active: registration failed\n");
> - goto err;
> - }
> - f = debugfs_create_file("devstate", S_IRUSR, dir,
> - dev, &mei_dbgfs_fops_devstate);
> - if (!f) {
> - dev_err(dev->dev, "devstate: registration failed\n");
> - goto err;
> - }
> - f = debugfs_create_file("allow_fixed_address", S_IRUSR | S_IWUSR,
> dir,
> - &dev->allow_fixed_address,
> - &mei_dbgfs_fops_allow_fa);
> - if (!f) {
> - dev_err(dev->dev, "allow_fixed_address: registration
> failed\n");
> - goto err;
> - }
> - return 0;
> -err:
> - mei_dbgfs_deregister(dev);
> - return -ENODEV;
> + debugfs_create_file("meclients", S_IRUSR, dir, dev,
> + &mei_dbgfs_fops_meclients);
> + debugfs_create_file("active", S_IRUSR, dir, dev,
> + &mei_dbgfs_fops_active);
> + debugfs_create_file("devstate", S_IRUSR, dir, dev,
> + &mei_dbgfs_fops_devstate);
> + debugfs_create_file("allow_fixed_address", S_IRUSR | S_IWUSR, dir,
> + &dev->allow_fixed_address,
> + &mei_dbgfs_fops_allow_fa);
> }
>
> diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c index
> ad02097d7fee..f894d1f8a53e 100644
> --- a/drivers/misc/mei/main.c
> +++ b/drivers/misc/mei/main.c
> @@ -984,16 +984,10 @@ int mei_register(struct mei_device *dev, struct
> device *parent)
> goto err_dev_create;
> }
>
> - ret = mei_dbgfs_register(dev, dev_name(clsdev));
> - if (ret) {
> - dev_err(clsdev, "cannot register debugfs ret = %d\n", ret);
> - goto err_dev_dbgfs;
> - }
> + mei_dbgfs_register(dev, dev_name(clsdev));
>
> return 0;
>
> -err_dev_dbgfs:
> - device_destroy(mei_class, devno);
> err_dev_create:
> cdev_del(&dev->cdev);
> err_dev_add:
> diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h index
> fca832fcac57..f71a023aed3c 100644
> --- a/drivers/misc/mei/mei_dev.h
> +++ b/drivers/misc/mei/mei_dev.h
> @@ -718,13 +718,10 @@ bool mei_hbuf_acquire(struct mei_device *dev);
> bool mei_write_is_idle(struct mei_device *dev);
>
> #if IS_ENABLED(CONFIG_DEBUG_FS)
> -int mei_dbgfs_register(struct mei_device *dev, const char *name);
> +void mei_dbgfs_register(struct mei_device *dev, const char *name);
> void mei_dbgfs_deregister(struct mei_device *dev); #else -static inline int
> mei_dbgfs_register(struct mei_device *dev, const char *name) -{
> - return 0;
> -}
> +static inline void mei_dbgfs_register(struct mei_device *dev, const
> +char *name) {}
> static inline void mei_dbgfs_deregister(struct mei_device *dev) {} #endif /*
> CONFIG_DEBUG_FS */
>
> --
> 2.22.0
Re: Linux behaviour problems comes down to GNU idol based on Morphine Psychosis
Yes, then I think we have solved the behavioural problem of Linux, and it seems to come down to the GNU idol, that seems based on Morphine Psychosis. And such the worst Stallman fans, have irate behaviour. And much have pointed to that already, and much criticism done, and indeed the GNU idol should be gone. And indeed I concluded this a while back, and suggested a Fair Labour direction for the OS instead. And replacing LSD culture, with Interculture, and Islam as the Bible is altered with Thorian belief, similar to LSD. then we keep the relevant of developments, and replace the irrelevant with interculture. And indeed the "acid" type never could do finances. Getting the Thor/Odin out, with it sectunrest and reality in. (Nor could they do mastering indeed, and rather than loudnesswar, we do suggest -10dB RMS masters too :)). Peace (Go With Thee), as was the original greeting, and As-Salam is indeed a name of The Divine. Eyx OS https://www.youtube.com/channel/UCR3gmLVjHS5A702wo4bol_Q
[PATCH v3] platform/x86: intel_pmc_core: transform Pkg C-state residency from TSC ticks into microseconds
Refer to the Intel SDM Vol.4, the package C-state residency counters of modern IA micro-architecture are all ticking in TSC frequency, hence we can apply simple math to transform the ticks into microseconds. i.e., residency (ms) = count / tsc_khz residency (us) = count / tsc_khz * 1000 This also aligns to other sysfs debug entries of residency counter in the same metric in microseconds, benefits reading and scripting. v2: restore the accidentally deleted newline, no function change. v3: apply kernel do_div() macro to calculate division Signed-off-by: Harry Pan --- drivers/platform/x86/intel_pmc_core.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c index f2c621b55f49..ab798efacc85 100644 --- a/drivers/platform/x86/intel_pmc_core.c +++ b/drivers/platform/x86/intel_pmc_core.c @@ -24,6 +24,7 @@ #include #include #include +#include #include "intel_pmc_core.h" @@ -738,7 +739,9 @@ static int pmc_core_pkgc_show(struct seq_file *s, void *unused) if (rdmsrl_safe(map[index].bit_mask, &pcstate_count)) continue; - seq_printf(s, "%-8s : 0x%llx\n", map[index].name, + pcstate_count *= 1000; + do_div(pcstate_count, tsc_khz); + seq_printf(s, "%-8s : %llu\n", map[index].name, pcstate_count); } -- 2.20.1
RE: [PATCH v2 1/6] net: macb: add phylink support
Hi Andrew, Sure, I will Cc Russel King in next version of patch series. Regards, Parshuram Thombare >-Original Message- >From: Andrew Lunn >Sent: Wednesday, June 19, 2019 3:03 AM >To: Parshuram Raju Thombare >Cc: nicolas.fe...@microchip.com; da...@davemloft.net; >f.faine...@gmail.com; net...@vger.kernel.org; hkallwe...@gmail.com; linux- >ker...@vger.kernel.org; Rafal Ciepiela ; Anil Joy >Varughese ; Piotr Sroka ; >Russell King >Subject: Re: [PATCH v2 1/6] net: macb: add phylink support > >EXTERNAL MAIL > > >On Tue, Jun 18, 2019 at 07:41:05PM +0100, Parshuram Thombare wrote: >> This patch replace phylib API's by phylink API's. > >Hi Parshuram > >When you repost as a proper threaded patchset, please Cc: Russell King, the >phylink maintainer. > > Thanks > Andrew
Re: [PATCH] PM: suspend: Rename pm_suspend_via_s2idle()
On Wed, Jun 19, 2019 at 2:19 AM Dmitry Torokhov wrote: > > Hi Rafael, > > On Tue, Jun 18, 2019 at 10:18:28AM +0200, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > The name of pm_suspend_via_s2idle() is confusing, as it doesn't > > reflect the purpose of the function precisely enough and it is > > very similar to pm_suspend_via_firmware(), which has a different > > purpose, so rename it as pm_suspend_default_s2idle() and update > > its only caller, i8042_register_ports(), accordingly. > > > > Signed-off-by: Rafael J. Wysocki > > I assume you'll take it through your tree... I will. > Acked-by: Dmitry Torokhov Thanks!
Re: [PATCH V3 02/17] pinctrl: tegra: add suspend and resume support
On Tue, Jun 18, 2019 at 11:00:05PM +0300, Dmitry Osipenko wrote:
> 18.06.2019 20:34, Sowjanya Komatineni пишет:
> >
> > On 6/18/19 9:50 AM, Sowjanya Komatineni wrote:
> >>
> >> On 6/18/19 8:41 AM, Stephen Warren wrote:
> >>> On 6/18/19 3:30 AM, Dmitry Osipenko wrote:
> 18.06.2019 12:22, Dmitry Osipenko пишет:
> > 18.06.2019 10:46, Sowjanya Komatineni пишет:
> >> This patch adds suspend and resume support for Tegra pinctrl driver
> >> and registers them to syscore so the pinmux settings are restored
> >> before the devices resume.
> >>
> >> Signed-off-by: Sowjanya Komatineni
> >> ---
> >> drivers/pinctrl/tegra/pinctrl-tegra.c | 62
> >>
> >> drivers/pinctrl/tegra/pinctrl-tegra.h | 5 +++
> >> drivers/pinctrl/tegra/pinctrl-tegra114.c | 1 +
> >> drivers/pinctrl/tegra/pinctrl-tegra124.c | 1 +
> >> drivers/pinctrl/tegra/pinctrl-tegra20.c | 1 +
> >> drivers/pinctrl/tegra/pinctrl-tegra210.c | 13 +++
> >> drivers/pinctrl/tegra/pinctrl-tegra30.c | 1 +
> >> 7 files changed, 84 insertions(+)
> >>
> >> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
> >> b/drivers/pinctrl/tegra/pinctrl-tegra.c
> >> index 34596b246578..ceced30d8bd1 100644
> >> --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
> >> +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
> >> @@ -20,11 +20,16 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include "../core.h"
> >> #include "../pinctrl-utils.h"
> >> #include "pinctrl-tegra.h"
> >> +#define EMMC2_PAD_CFGPADCTRL_0 0x1c8
> >> +#define EMMC4_PAD_CFGPADCTRL_0 0x1e0
> >> +#define EMMC_DPD_PARKING (0x1fff << 14)
> >> +
> >> static inline u32 pmx_readl(struct tegra_pmx *pmx, u32 bank, u32 reg)
> >> {
> >> return readl(pmx->regs[bank] + reg);
> >> @@ -619,6 +624,48 @@ static void
> >> tegra_pinctrl_clear_parked_bits(struct tegra_pmx *pmx)
> >> pmx_writel(pmx, val, g->mux_bank, g->mux_reg);
> >> }
> >> }
> >> +
> >> + if (pmx->soc->has_park_padcfg) {
> >> + val = pmx_readl(pmx, 0, EMMC2_PAD_CFGPADCTRL_0);
> >> + val &= ~EMMC_DPD_PARKING;
> >> + pmx_writel(pmx, val, 0, EMMC2_PAD_CFGPADCTRL_0);
> >> +
> >> + val = pmx_readl(pmx, 0, EMMC4_PAD_CFGPADCTRL_0);
> >> + val &= ~EMMC_DPD_PARKING;
> >> + pmx_writel(pmx, val, 0, EMMC4_PAD_CFGPADCTRL_0);
> >> + }
> >> +}
> >
> > Is there any reason why parked_bit can't be changed to parked_bitmask
> > like I was
> > asking in a comment to v2?
> >
> > I suppose that it's more preferable to keep pinctrl-tegra.c
> > platform-agnostic for
> > consistency when possible, hence adding platform specifics here should
> > be discouraged.
> > And then the parked_bitmask will also result in a proper hardware
> > description in the code.
> >
>
> I'm now also vaguely recalling that Stephen Warren had some kind of a
> "code generator"
> for the pinctrl drivers. So I guess all those tables were auto-generated
> initially.
>
> Stephen, maybe you could adjust the generator to take into account the
> bitmask (of
> course if that's a part of the generated code) and then re-gen it all
> for Sowjanya?
> >>>
> >>> https://github.com/NVIDIA/tegra-pinmux-scripts holds the scripts that
> >>> generate
> >>> tegra-pinctrlNNN.c. See soc-to-kernel-pinctrl-driver.py. IIRC,
> >>> tegra-pinctrl.c (the core
> >>> file) isn't auto-generated. Sowjanya is welcome to send a patch to that
> >>> repo if the code
> >>> needs to be updated.
> >>
> >>
> >> Hi Dmitry,
> >>
> >> Just want to be clear on my understanding of your request.
> >>
> >> "change parked_bit to parked_bitmask" are you requested to change
> >> parked_bit of PINGROUP
> >> and DRV_PINGROUP to use bitmask value rather than bit position inorder to
> >> have parked bit
> >> configuration for EMMC PADs as well to happen by masking rather than
> >> checking for
> >> existence of parked_bit?
> >>
> >> Trying to understand the reason/benefit for changing parked_bit to
> >> parked_bitmask.
> > Also, Park bits in CFGPAD registers are not common for all CFGPAD
> > registers. Park bits are
> > available only for EMMC and also those bits are used for something else on
> > other CFGPAD
> > registers so bitmask can't be common and this also need an update to
> > DRV_PINGROUP macro args
> > just only to handle EMMC parked_bitmask. So not sure of the benefit in
> > using bitmask rather
>
> Hi Sowjanya,
>
> The main motivation is to describe hardware properly in the drivers. Why to
> make a
> hacky-looking workaround while you can make things properly? Especially if
> that doesn't take
> much effort.
>
> Stephe
Re: [PATCH V3 02/17] pinctrl: tegra: add suspend and resume support
On Tue, Jun 18, 2019 at 09:41:03AM -0600, Stephen Warren wrote:
> On 6/18/19 3:30 AM, Dmitry Osipenko wrote:
> > 18.06.2019 12:22, Dmitry Osipenko пишет:
> > > 18.06.2019 10:46, Sowjanya Komatineni пишет:
> > > > This patch adds suspend and resume support for Tegra pinctrl driver
> > > > and registers them to syscore so the pinmux settings are restored
> > > > before the devices resume.
> > > >
> > > > Signed-off-by: Sowjanya Komatineni
> > > > ---
> > > > drivers/pinctrl/tegra/pinctrl-tegra.c| 62
> > > >
> > > > drivers/pinctrl/tegra/pinctrl-tegra.h| 5 +++
> > > > drivers/pinctrl/tegra/pinctrl-tegra114.c | 1 +
> > > > drivers/pinctrl/tegra/pinctrl-tegra124.c | 1 +
> > > > drivers/pinctrl/tegra/pinctrl-tegra20.c | 1 +
> > > > drivers/pinctrl/tegra/pinctrl-tegra210.c | 13 +++
> > > > drivers/pinctrl/tegra/pinctrl-tegra30.c | 1 +
> > > > 7 files changed, 84 insertions(+)
> > > >
> > > > diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
> > > > b/drivers/pinctrl/tegra/pinctrl-tegra.c
> > > > index 34596b246578..ceced30d8bd1 100644
> > > > --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
> > > > +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
> > > > @@ -20,11 +20,16 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include "../core.h"
> > > > #include "../pinctrl-utils.h"
> > > > #include "pinctrl-tegra.h"
> > > > +#define EMMC2_PAD_CFGPADCTRL_0 0x1c8
> > > > +#define EMMC4_PAD_CFGPADCTRL_0 0x1e0
> > > > +#define EMMC_DPD_PARKING (0x1fff << 14)
> > > > +
> > > > static inline u32 pmx_readl(struct tegra_pmx *pmx, u32 bank, u32 reg)
> > > > {
> > > > return readl(pmx->regs[bank] + reg);
> > > > @@ -619,6 +624,48 @@ static void tegra_pinctrl_clear_parked_bits(struct
> > > > tegra_pmx *pmx)
> > > > pmx_writel(pmx, val, g->mux_bank, g->mux_reg);
> > > > }
> > > > }
> > > > +
> > > > + if (pmx->soc->has_park_padcfg) {
> > > > + val = pmx_readl(pmx, 0, EMMC2_PAD_CFGPADCTRL_0);
> > > > + val &= ~EMMC_DPD_PARKING;
> > > > + pmx_writel(pmx, val, 0, EMMC2_PAD_CFGPADCTRL_0);
> > > > +
> > > > + val = pmx_readl(pmx, 0, EMMC4_PAD_CFGPADCTRL_0);
> > > > + val &= ~EMMC_DPD_PARKING;
> > > > + pmx_writel(pmx, val, 0, EMMC4_PAD_CFGPADCTRL_0);
> > > > + }
> > > > +}
> > >
> > > Is there any reason why parked_bit can't be changed to parked_bitmask
> > > like I was
> > > asking in a comment to v2?
> > >
> > > I suppose that it's more preferable to keep pinctrl-tegra.c
> > > platform-agnostic for
> > > consistency when possible, hence adding platform specifics here should be
> > > discouraged.
> > > And then the parked_bitmask will also result in a proper hardware
> > > description in the code.
> > >
> >
> > I'm now also vaguely recalling that Stephen Warren had some kind of a "code
> > generator"
> > for the pinctrl drivers. So I guess all those tables were auto-generated
> > initially.
> >
> > Stephen, maybe you could adjust the generator to take into account the
> > bitmask (of
> > course if that's a part of the generated code) and then re-gen it all for
> > Sowjanya?
>
> https://github.com/NVIDIA/tegra-pinmux-scripts holds the scripts that
> generate tegra-pinctrlNNN.c. See soc-to-kernel-pinctrl-driver.py. IIRC,
> tegra-pinctrl.c (the core file) isn't auto-generated. Sowjanya is welcome to
> send a patch to that repo if the code needs to be updated.
If we want to do that, we may need to start off by bringing the pinmux
scripts up to date with the latest version of the generated files. There
have been a number of changes in the meantime that cause the scripts to
generate a bit of diff with regards to what's currently upstream. Sounds
like something fairly trivial, though.
Thierry
signature.asc
Description: PGP signature
Re: [alsa-devel] [PATCH v2 09/11] ASoC: Intel: hdac_hdmi: Set ops to NULL on remove
On Tue, 18 Jun 2019 08:58:22 -0700 Ranjani Sridharan wrote: > On Tue, 2019-06-18 at 13:00 +0200, Amadeusz Sławiński wrote: > > On Mon, 17 Jun 2019 13:51:42 -0700 > > Ranjani Sridharan wrote: > > > > > On Mon, 2019-06-17 at 13:36 +0200, Amadeusz Sławiński wrote: > > > > When we unload Skylake driver we may end up calling > > > > hdac_component_master_unbind(), it uses acomp->audio_ops, which > > > > we > > > > set > > > > in hdmi_codec_probe(), so we need to set it to NULL in > > > > hdmi_codec_remove(), > > > > otherwise we will dereference no longer existing pointer. > > > > > > Hi Amadeusz, > > > > > > It looks like the audio_ops should be deleted > > > snd_hdac_acomp_exit(). > > > Also, this doesnt seem to be the case with when the SOF driver is > > > removed. > > > Could you please give a bit more context on what error you see > > > when this happens? > > > > Hi, > > > > I get Oops. This is what happens with all other patches in this > > series and only this one reverted: > > > > root@APL:~# rmmod snd_soc_sst_bxt_rt298 > > root@APL:~# rmmod snd_soc_hdac_hdmi > > root@APL:~# rmmod snd_soc_skl > > Thanks, Amadeusz. I think the order in which the drivers are removed > is what's causing the oops in your case. With SOF, the order we > remove is > > 1. rmmod sof_pci_dev > 2. rmmod snd_soc_sst_bxt_rt298 > 3. rmmod snd_soc_hdac_hdmi > Well, there is nothing enforcing the order in which modules can be unloaded (and I see no reason to force it), as you can see from following excerpt, you can either start unloading from snd_soc_sst_bxt_rt298 or snd_soc_skl, and yes if you start from snd_soc_skl, there is no problem. snd_soc_sst_bxt_rt29840960 0 snd_soc_hdac_hdmi 45056 1 snd_soc_sst_bxt_rt298 snd_soc_dmic 16384 1 snd_soc_rt298 65536 2 snd_soc_sst_bxt_rt298 snd_soc_rt286 61440 0 snd_soc_rl6347a16384 2 snd_soc_rt298,snd_soc_rt286 snd_soc_skl 372736 0 snd_soc_sst_ipc20480 1 snd_soc_skl snd_soc_sst_dsp36864 1 snd_soc_skl snd_hda_ext_core 28672 2 snd_soc_hdac_hdmi,snd_soc_skl snd_hda_core 139264 3 snd_hda_ext_core,snd_soc_hdac_hdmi,snd_soc_skl snd_soc_acpi_intel_match53248 1 snd_soc_skl snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_soc_skl snd_soc_core 405504 6 snd_soc_rt298,snd_soc_rt286,snd_soc_hdac_hdmi,snd_soc_skl,snd_soc_dmic,snd_soc_sst_bxt_rt298 snd_compress 36864 2 snd_soc_core,snd_soc_skl snd_pcm_dmaengine 16384 1 snd_soc_core snd_pcm 163840 10 snd_soc_rt298,snd_soc_rt286,snd_hda_ext_core,snd_soc_hdac_hdmi,snd_compress,snd_soc_core,snd_soc_skl,snd_hda_core,snd_soc_sst_bxt_rt298,snd_pcm_dmaengine snd_timer 53248 1 snd_pcm Amadeusz
Re: [PATCH v5 0/3] Make IPA use PM_EM
On Thursday 30 May 2019 at 10:20:35 (+0100), Quentin Perret wrote: > Quentin Perret (3): > arm64: defconfig: Enable CONFIG_ENERGY_MODEL > thermal: cpu_cooling: Make the power-related code depend on IPA > thermal: cpu_cooling: Migrate to using the EM framework > > arch/arm64/configs/defconfig | 1 + > drivers/thermal/Kconfig | 1 + > drivers/thermal/cpu_cooling.c | 428 ++ > 3 files changed, 178 insertions(+), 252 deletions(-) Gentle ping on this :-) Is there any chance for the series to make it in 5.3 ? Or is it too late already ? In any case do let me know if there is anything I can do about it. Many thanks, Quentin
Re: Alternatives to /sys/kernel/debug/wakeup_sources
On Wed, Jun 19, 2019 at 1:52 AM Joel Fernandes wrote: > > On Tue, Jun 18, 2019 at 7:15 PM Tri Vo wrote: > [snip] > > > > > > > > > > > > Android userspace reading wakeup_sources is not ideal because: > > > > > > - Debugfs API is not stable, i.e. Android tools built on top of it > > > > > > are > > > > > > not guaranteed to be backward/forward compatible. > > > > > > - This file requires debugfs to be mounted, which itself is > > > > > > undesirable for security reasons. > > > > > > > > > > > > To address these problems, we want to contribute a way to expose > > > > > > these > > > > > > statistics that doesn't depend on debugfs. > > > > > > > > > > > > Some initial thoughts/questions: Should we expose the stats in > > > > > > sysfs? > > > > > > Or maybe implement eBPF-based solution? What do you think? > > > > > > > > We are going through Android's out-of-tree kernel dependencies along > > > > with > > > > userspace APIs that are not necessarily considered "stable and forever > > > > supported" upstream. The debugfs dependencies showed up on our radar as > > > > a > > > > result and so we are wondering if we should worry about changes in > > > > debugfs > > > > interface and hence the question(s) below. > > > > > > > > So, can we rely on /d/wakeup_sources to be considered a userspace API > > > > and > > > > hence maintained stable as we do for other /proc and /sys entries? > > > > > > > > If yes, then we will go ahead and add tests for this in LTP or > > > > somewhere else suitable. > > > > > > No, debugfs is not ABI. > > > > > > > If no, then we would love to hear suggestions for any changes that need > > > > to be > > > > made or we simply just move the debugfs entry into somewhere like > > > > /sys/power/ ? > > > > > > No, moving that entire file from debugfs into sysfs is not an option > > > either. > > > > > > The statistics for the wakeup sources associated with devices are already > > > there > > > under /sys/devices/.../power/ , but I guess you want all wakeup sources? > > > > > > That would require adding a kobject to struct wakeup_source and exposing > > > all of the statistics as separate attributes under it. In which case it > > > would be > > > good to replace the existing wakeup statistics under > > > /sys/devices/.../power/ > > > with symbolic links to the attributes under the wakeup_source kobject. > > > > Thanks for your input, Rafael! Your suggestion makes sense. I'll work > > on a patch for this. > > Does that entail making each wake up source, a new sysfs node under a > particular device, and then adding stats under that new node? Not under a device, because there are wakeup source objects without associated devices. It is conceivable to have a "wakeup_sources" directory under /sys/power/ and sysfs nodes for all wakeup sources in there. Then, instead of exposing wakeup statistics directly under /sys/devices/.../power/, there can be symbolic links from there to the new wakeup source nodes under "wakeup_sources" (so as to avoid exposing the same data in two different places in sysfs, which may be confusing). Cheers!
[PATCH v2 0/5] net: macb: cover letter
Hello !, This is second version of patch set containing following patches for Cadence ethernet controller driver. 1. 0001-net-macb-add-phylink-support.patch Replace phylib API's with phylink API's. 2. 0002-net-macb-add-support-for-sgmii-MAC-PHY-interface.patch This patch add support for SGMII mode. 3. 0004-net-macb-add-support-for-c45-PHY.patch This patch is to support C45 PHY. 4. 0005-net-macb-add-support-for-high-speed-interface This patch add support for 10G USXGMII PCS in fixed mode. 5. 0006-net-macb-parameter-added-to-cadence-ethernet-controller-DT-binding New parameter added to Cadence ethernet controller DT binding for USXGMII interface. Changes: 1. Dropped patch configuring TI PHY DP83867 from Cadence PCI wrapper driver. 2. Removed code registering emulated PHY for fixed mode. 3. Code reformatting as per Andrew's and Floren's suggestions. Regards, Parshuram Thombare Parshuram Thombare (5): net: macb: add phylink support net: macb: add support for sgmii MAC-PHY interface net: macb: add support for c45 PHY net: macb: add support for high speed interface net: macb: parameter added to cadence ethernet controller DT binding .../devicetree/bindings/net/macb.txt | 3 + drivers/net/ethernet/cadence/Kconfig | 2 +- drivers/net/ethernet/cadence/macb.h | 135 +++- drivers/net/ethernet/cadence/macb_main.c | 668 +- 4 files changed, 628 insertions(+), 180 deletions(-) -- 2.17.1
[PATCH v2 2/5] net: macb: add support for sgmii MAC-PHY interface
This patch add support for SGMII interface) and 2.5Gbps MAC in Cadence ethernet controller driver. Signed-off-by: Parshuram Thombare --- drivers/net/ethernet/cadence/macb.h | 76 ++-- drivers/net/ethernet/cadence/macb_main.c | 151 --- 2 files changed, 200 insertions(+), 27 deletions(-) diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h index 35ed13236c8b..d7ffbfb2ecc0 100644 --- a/drivers/net/ethernet/cadence/macb.h +++ b/drivers/net/ethernet/cadence/macb.h @@ -80,6 +80,7 @@ #define MACB_RBQPH 0x04D4 /* GEM register offsets. */ +#define GEM_NCR0x /* Network Control */ #define GEM_NCFGR 0x0004 /* Network Config */ #define GEM_USRIO 0x000c /* User IO */ #define GEM_DMACFG 0x0010 /* DMA Configuration */ @@ -159,6 +160,9 @@ #define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */ #define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */ #define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */ +#define GEM_PCS_CTRL 0x0200 /* PCS Control */ +#define GEM_PCS_STATUS 0x0204 /* PCS Status */ +#define GEM_PCS_AN_LP_BASE 0x0214 /* PCS AN LP BASE*/ #define GEM_DCFG1 0x0280 /* Design Config 1 */ #define GEM_DCFG2 0x0284 /* Design Config 2 */ #define GEM_DCFG3 0x0288 /* Design Config 3 */ @@ -274,6 +278,10 @@ #define MACB_IRXFCS_OFFSET 19 #define MACB_IRXFCS_SIZE 1 +/* GEM specific NCR bitfields. */ +#define GEM_TWO_PT_FIVE_GIG_OFFSET 29 +#define GEM_TWO_PT_FIVE_GIG_SIZE 1 + /* GEM specific NCFGR bitfields. */ #define GEM_GBE_OFFSET 10 /* Gigabit mode enable */ #define GEM_GBE_SIZE 1 @@ -326,6 +334,9 @@ #define MACB_MDIO_SIZE 1 #define MACB_IDLE_OFFSET 2 /* The PHY management logic is idle */ #define MACB_IDLE_SIZE 1 +#define MACB_DUPLEX_OFFSET 3 +#define MACB_DUPLEX_SIZE 1 + /* Bitfields in TSR */ #define MACB_UBR_OFFSET0 /* Used bit read */ @@ -459,11 +470,37 @@ #define MACB_REV_OFFSET0 #define MACB_REV_SIZE 16 +/* Bitfields in PCS_CONTROL. */ +#define GEM_PCS_CTRL_RST_OFFSET15 +#define GEM_PCS_CTRL_RST_SIZE 1 +#define GEM_PCS_CTRL_EN_AN_OFFSET 12 +#define GEM_PCS_CTRL_EN_AN_SIZE1 +#define GEM_PCS_CTRL_RESTART_AN_OFFSET 9 +#define GEM_PCS_CTRL_RESTART_AN_SIZE 1 + +/* Bitfields in PCS_STATUS. */ +#define GEM_PCS_STATUS_AN_DONE_OFFSET 5 +#define GEM_PCS_STATUS_AN_DONE_SIZE1 +#define GEM_PCS_STATUS_AN_SUPPORT_OFFSET 3 +#define GEM_PCS_STATUS_AN_SUPPORT_SIZE 1 +#define GEM_PCS_STATUS_LINK_OFFSET 2 +#define GEM_PCS_STATUS_LINK_SIZE 1 + +/* Bitfield in PCS_AN_LP_BASE */ +#define GEM_PCS_AN_LP_BASE_LINK_OFFSET 15 +#define GEM_PCS_AN_LP_BASE_LINK_SIZE 1 +#define GEM_PCS_AN_LP_BASE_DUPLEX_OFFSET 12 +#define GEM_PCS_AN_LP_BASE_DUPLEX_SIZE 1 +#define GEM_PCS_AN_LP_BASE_SPEED_OFFSET10 +#define GEM_PCS_AN_LP_BASE_SPEED_SIZE 2 + /* Bitfields in DCFG1. */ #define GEM_IRQCOR_OFFSET 23 #define GEM_IRQCOR_SIZE1 #define GEM_DBWDEF_OFFSET 25 #define GEM_DBWDEF_SIZE3 +#define GEM_NO_PCS_OFFSET 0 +#define GEM_NO_PCS_SIZE1 /* Bitfields in DCFG2. */ #define GEM_RX_PKT_BUFF_OFFSET 20 @@ -636,19 +673,32 @@ #define MACB_MAN_CODE 2 /* Capability mask bits */ -#define MACB_CAPS_ISR_CLEAR_ON_WRITE 0x0001 -#define MACB_CAPS_USRIO_HAS_CLKEN 0x0002 -#define MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII0x0004 -#define MACB_CAPS_NO_GIGABIT_HALF 0x0008 -#define MACB_CAPS_USRIO_DISABLED 0x0010 -#define MACB_CAPS_JUMBO0x0020 -#define MACB_CAPS_GEM_HAS_PTP 0x0040 -#define MACB_CAPS_BD_RD_PREFETCH 0x0080 -#define MACB_CAPS_NEEDS_RSTONUBR 0x0100 -#define MACB_CAPS_FIFO_MODE0x1000 -#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000 -#define MACB_CAPS_SG_DISABLED 0x4000 -#define MACB_CAPS_MACB_IS_GEM 0x8000 +#define MACB_CAPS_ISR_CLEAR_ON_WRITE BIT(0) +#define MACB_CAPS_USRIO_HAS_CLKEN BIT(1) +#define MACB_CAPS_USRIO_DEFAULT_IS_MII_GMIIBIT(2) +#define MACB_CAPS_NO_GIGABIT_HALF BIT(3) +#define MACB_CAPS_USRIO_DISABLED BIT(4) +#define MACB_CAPS_JUMBOBIT(5) +#define MACB_CAPS_GEM_HAS_PTP BIT(
[PATCH v2 3/5] net: macb: add support for c45 PHY
This patch modify MDIO read/write functions to support
communication with C45 PHY.
Signed-off-by: Parshuram Thombare
---
drivers/net/ethernet/cadence/macb.h | 15 --
drivers/net/ethernet/cadence/macb_main.c | 61 +++-
2 files changed, 61 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index d7ffbfb2ecc0..34768d35aea1 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -667,10 +667,17 @@
#define GEM_CLK_DIV96 5
/* Constants for MAN register */
-#define MACB_MAN_SOF 1
-#define MACB_MAN_WRITE 1
-#define MACB_MAN_READ 2
-#define MACB_MAN_CODE 2
+#define MACB_MAN_C22_SOF1
+#define MACB_MAN_C22_WRITE 1
+#define MACB_MAN_C22_READ 2
+#define MACB_MAN_C22_CODE 2
+
+#define MACB_MAN_C45_SOF0
+#define MACB_MAN_C45_ADDR 0
+#define MACB_MAN_C45_WRITE 1
+#define MACB_MAN_C45_POST_READ_INCR 2
+#define MACB_MAN_C45_READ 3
+#define MACB_MAN_C45_CODE 2
/* Capability mask bits */
#define MACB_CAPS_ISR_CLEAR_ON_WRITE BIT(0)
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index 884d2a4408ad..cf63381d54ee 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -344,11 +344,30 @@ static int macb_mdio_read(struct mii_bus *bus, int
mii_id, int regnum)
if (status < 0)
goto mdio_read_exit;
- macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
- | MACB_BF(RW, MACB_MAN_READ)
- | MACB_BF(PHYA, mii_id)
- | MACB_BF(REGA, regnum)
- | MACB_BF(CODE, MACB_MAN_CODE)));
+ if (regnum & MII_ADDR_C45) {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_ADDR)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(DATA, regnum & 0x)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)));
+
+ status = macb_mdio_wait_for_idle(bp);
+ if (status < 0)
+ goto mdio_read_exit;
+
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_READ)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)));
+ } else {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C22_SOF)
+ | MACB_BF(RW, MACB_MAN_C22_READ)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, regnum)
+ | MACB_BF(CODE, MACB_MAN_C22_CODE)));
+ }
status = macb_mdio_wait_for_idle(bp);
if (status < 0)
@@ -377,12 +396,32 @@ static int macb_mdio_write(struct mii_bus *bus, int
mii_id, int regnum,
if (status < 0)
goto mdio_write_exit;
- macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
- | MACB_BF(RW, MACB_MAN_WRITE)
- | MACB_BF(PHYA, mii_id)
- | MACB_BF(REGA, regnum)
- | MACB_BF(CODE, MACB_MAN_CODE)
- | MACB_BF(DATA, value)));
+ if (regnum & MII_ADDR_C45) {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_ADDR)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(DATA, regnum & 0x)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)));
+
+ status = macb_mdio_wait_for_idle(bp);
+ if (status < 0)
+ goto mdio_write_exit;
+
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_WRITE)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)
+ | MACB_BF(DATA, value)));
+ } else {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C22_SOF)
+ | MACB_BF(RW, MACB_MAN_C22_WRITE)
+ | MACB_BF(PHYA, mii_id)
[PATCH v2 1/5] net: macb: add phylink support
This patch replace phylib API's by phylink API's.
Signed-off-by: Parshuram Thombare
---
drivers/net/ethernet/cadence/Kconfig | 2 +-
drivers/net/ethernet/cadence/macb.h | 3 +
drivers/net/ethernet/cadence/macb_main.c | 312 +--
3 files changed, 182 insertions(+), 135 deletions(-)
diff --git a/drivers/net/ethernet/cadence/Kconfig
b/drivers/net/ethernet/cadence/Kconfig
index 1766697c9c5a..d71411a71587 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -22,7 +22,7 @@ if NET_VENDOR_CADENCE
config MACB
tristate "Cadence MACB/GEM support"
depends on HAS_DMA
- select PHYLIB
+ select PHYLINK
---help---
The Cadence MACB ethernet interface is found on many Atmel AT32 and
AT91 parts. This driver also supports the Cadence GEM (Gigabit
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 00ee5e8e0ff0..35ed13236c8b 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_ARCH_DMA_ADDR_T_64BIT) || defined(CONFIG_MACB_USE_HWSTAMP)
#define MACB_EXT_DESC
@@ -1227,6 +1228,8 @@ struct macb {
u32 rx_intr_mask;
struct macb_pm_data pm_data;
+ struct phylink *pl;
+ struct phylink_config pl_config;
};
#ifdef CONFIG_MACB_USE_HWSTAMP
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index c545c5b435d8..830af86d3c65 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "macb.h"
/* This structure is only used for MACB on SiFive FU540 devices */
@@ -438,115 +439,150 @@ static void macb_set_tx_clk(struct clk *clk, int speed,
struct net_device *dev)
netdev_err(dev, "adjusting tx_clk failed.\n");
}
-static void macb_handle_link_change(struct net_device *dev)
+static void gem_phylink_validate(struct phylink_config *pl_config,
+unsigned long *supported,
+struct phylink_link_state *state)
{
- struct macb *bp = netdev_priv(dev);
- struct phy_device *phydev = dev->phydev;
- unsigned long flags;
- int status_change = 0;
+ struct net_device *netdev = to_net_dev(pl_config->dev);
+ struct macb *bp = netdev_priv(netdev);
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+ switch (state->interface) {
+ case PHY_INTERFACE_MODE_GMII:
+ case PHY_INTERFACE_MODE_RGMII:
+ if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
+ if (!(bp->caps & MACB_CAPS_NO_GIGABIT_HALF)) {
+ phylink_set(mask, 1000baseT_Half);
+ phylink_set(mask, 1000baseT_Half);
+ }
+ }
+ /* fallthrough */
+ case PHY_INTERFACE_MODE_MII:
+ case PHY_INTERFACE_MODE_RMII:
+ phylink_set(mask, 10baseT_Half);
+ phylink_set(mask, 10baseT_Full);
+ phylink_set(mask, 100baseT_Half);
+ phylink_set(mask, 100baseT_Full);
+ break;
+ default:
+ break;
+ }
- spin_lock_irqsave(&bp->lock, flags);
+ bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
+ bitmap_and(state->advertising, state->advertising, mask,
+ __ETHTOOL_LINK_MODE_MASK_NBITS);
+}
- if (phydev->link) {
- if ((bp->speed != phydev->speed) ||
- (bp->duplex != phydev->duplex)) {
- u32 reg;
+static int gem_phylink_mac_link_state(struct phylink_config *pl_config,
+ struct phylink_link_state *state)
+{
+ struct net_device *netdev = to_net_dev(pl_config->dev);
+ struct macb *bp = netdev_priv(netdev);
- reg = macb_readl(bp, NCFGR);
- reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
- if (macb_is_gem(bp))
- reg &= ~GEM_BIT(GBE);
+ state->speed = bp->speed;
+ state->duplex = bp->duplex;
+ state->link = bp->link;
+ return 1;
+}
- if (phydev->duplex)
- reg |= MACB_BIT(FD);
- if (phydev->speed == SPEED_100)
- reg |= MACB_BIT(SPD);
- if (phydev->speed == SPEED_1000 &&
- bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
- reg |= GEM_BIT(GBE);
+static void gem_mac_config(struct phylink_config *pl_config, unsigne
RE: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup
Hi Uffe, > -Original Message- > From: Ulf Hansson > Sent: Monday, June 17, 2019 5:51 PM [...] > > The "const struct zynqmp_eemi_ops *eemi_ops; should then be moved into > a clock provider specific struct, which is assigned when calling > sdhci_arasan_register_sdclk. I understand that all the clock data is > folded into struct sdhci_arasan_data today, but I think that should be > moved into a "sub-struct" for the clock specifics. > > Moreover, when registering the clock, we should convert from using > devm_clk_register() into devm_clk_hw_register() as the first one is > now deprecated. Just a query here: When we switch to using devm_clk_hw_register() here, it will register the clk_hw and return int. Is there a way we can get the clk (related to the clk_hw registered) from the clock framework? I am asking this because we will need that clk pointer while calling clk_set_phase() function. Thanks, Manish
Re: [PATCH V3 02/17] pinctrl: tegra: add suspend and resume support
19.06.2019 11:31, Thierry Reding пишет:
> On Tue, Jun 18, 2019 at 11:00:05PM +0300, Dmitry Osipenko wrote:
>> 18.06.2019 20:34, Sowjanya Komatineni пишет:
>>>
>>> On 6/18/19 9:50 AM, Sowjanya Komatineni wrote:
On 6/18/19 8:41 AM, Stephen Warren wrote:
> On 6/18/19 3:30 AM, Dmitry Osipenko wrote:
>> 18.06.2019 12:22, Dmitry Osipenko пишет:
>>> 18.06.2019 10:46, Sowjanya Komatineni пишет:
This patch adds suspend and resume support for Tegra pinctrl driver
and registers them to syscore so the pinmux settings are restored
before the devices resume.
Signed-off-by: Sowjanya Komatineni
---
drivers/pinctrl/tegra/pinctrl-tegra.c | 62
drivers/pinctrl/tegra/pinctrl-tegra.h | 5 +++
drivers/pinctrl/tegra/pinctrl-tegra114.c | 1 +
drivers/pinctrl/tegra/pinctrl-tegra124.c | 1 +
drivers/pinctrl/tegra/pinctrl-tegra20.c | 1 +
drivers/pinctrl/tegra/pinctrl-tegra210.c | 13 +++
drivers/pinctrl/tegra/pinctrl-tegra30.c | 1 +
7 files changed, 84 insertions(+)
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
b/drivers/pinctrl/tegra/pinctrl-tegra.c
index 34596b246578..ceced30d8bd1 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
@@ -20,11 +20,16 @@
#include
#include
#include
+#include
#include "../core.h"
#include "../pinctrl-utils.h"
#include "pinctrl-tegra.h"
+#define EMMC2_PAD_CFGPADCTRL_0 0x1c8
+#define EMMC4_PAD_CFGPADCTRL_0 0x1e0
+#define EMMC_DPD_PARKING (0x1fff << 14)
+
static inline u32 pmx_readl(struct tegra_pmx *pmx, u32 bank, u32 reg)
{
return readl(pmx->regs[bank] + reg);
@@ -619,6 +624,48 @@ static void
tegra_pinctrl_clear_parked_bits(struct tegra_pmx *pmx)
pmx_writel(pmx, val, g->mux_bank, g->mux_reg);
}
}
+
+ if (pmx->soc->has_park_padcfg) {
+ val = pmx_readl(pmx, 0, EMMC2_PAD_CFGPADCTRL_0);
+ val &= ~EMMC_DPD_PARKING;
+ pmx_writel(pmx, val, 0, EMMC2_PAD_CFGPADCTRL_0);
+
+ val = pmx_readl(pmx, 0, EMMC4_PAD_CFGPADCTRL_0);
+ val &= ~EMMC_DPD_PARKING;
+ pmx_writel(pmx, val, 0, EMMC4_PAD_CFGPADCTRL_0);
+ }
+}
>>>
>>> Is there any reason why parked_bit can't be changed to parked_bitmask
>>> like I was
>>> asking in a comment to v2?
>>>
>>> I suppose that it's more preferable to keep pinctrl-tegra.c
>>> platform-agnostic for
>>> consistency when possible, hence adding platform specifics here should
>>> be discouraged.
>>> And then the parked_bitmask will also result in a proper hardware
>>> description in the code.
>>>
>>
>> I'm now also vaguely recalling that Stephen Warren had some kind of a
>> "code generator"
>> for the pinctrl drivers. So I guess all those tables were auto-generated
>> initially.
>>
>> Stephen, maybe you could adjust the generator to take into account the
>> bitmask (of
>> course if that's a part of the generated code) and then re-gen it all
>> for Sowjanya?
>
> https://github.com/NVIDIA/tegra-pinmux-scripts holds the scripts that
> generate
> tegra-pinctrlNNN.c. See soc-to-kernel-pinctrl-driver.py. IIRC,
> tegra-pinctrl.c (the core
> file) isn't auto-generated. Sowjanya is welcome to send a patch to that
> repo if the code
> needs to be updated.
Hi Dmitry,
Just want to be clear on my understanding of your request.
"change parked_bit to parked_bitmask" are you requested to change
parked_bit of PINGROUP
and DRV_PINGROUP to use bitmask value rather than bit position inorder to
have parked bit
configuration for EMMC PADs as well to happen by masking rather than
checking for
existence of parked_bit?
Trying to understand the reason/benefit for changing parked_bit to
parked_bitmask.
>>> Also, Park bits in CFGPAD registers are not common for all CFGPAD
>>> registers. Park bits are
>>> available only for EMMC and also those bits are used for something else on
>>> other CFGPAD
>>> registers so bitmask can't be common and this also need an update to
>>> DRV_PINGROUP macro args
>>> just only to handle EMMC parked_bitmask. So not sure of the benefit in
>>> using bitmask rather
>>
>> Hi Sowjanya,
>>
>> The main motivation is to describe hardware properly in the drivers. Why to
>> make a
>> hacky-looking workaround while you can make things properly? Especially if
[PATCH v2 4/5] net: macb: add support for high speed interface
This patch add support for high speed USXGMII PCS and 10G
speed in Cadence ethernet controller driver.
Signed-off-by: Parshuram Thombare
---
drivers/net/ethernet/cadence/macb.h | 41 +
drivers/net/ethernet/cadence/macb_main.c | 216 +++
2 files changed, 218 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 34768d35aea1..0910d0bfdceb 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -85,6 +85,7 @@
#define GEM_USRIO 0x000c /* User IO */
#define GEM_DMACFG 0x0010 /* DMA Configuration */
#define GEM_JML0x0048 /* Jumbo Max Length */
+#define GEM_HS_MAC_CONFIG 0x0050 /* GEM high speed config */
#define GEM_HRB0x0080 /* Hash Bottom */
#define GEM_HRT0x0084 /* Hash Top */
#define GEM_SA1B 0x0088 /* Specific1 Bottom */
@@ -172,6 +173,9 @@
#define GEM_DCFG7 0x0298 /* Design Config 7 */
#define GEM_DCFG8 0x029C /* Design Config 8 */
#define GEM_DCFG10 0x02A4 /* Design Config 10 */
+#define GEM_DCFG12 0x02AC /* Design Config 12 */
+#define GEM_USX_CONTROL0x0A80 /* USXGMII control register */
+#define GEM_USX_STATUS 0x0A88 /* USXGMII status register */
#define GEM_TXBDCTRL 0x04cc /* TX Buffer Descriptor control register */
#define GEM_RXBDCTRL 0x04d0 /* RX Buffer Descriptor control register */
@@ -279,6 +283,8 @@
#define MACB_IRXFCS_SIZE 1
/* GEM specific NCR bitfields. */
+#define GEM_ENABLE_HS_MAC_OFFSET 31
+#define GEM_ENABLE_HS_MAC_SIZE 1
#define GEM_TWO_PT_FIVE_GIG_OFFSET 29
#define GEM_TWO_PT_FIVE_GIG_SIZE 1
@@ -470,6 +476,10 @@
#define MACB_REV_OFFSET0
#define MACB_REV_SIZE 16
+/* Bitfield in HS_MAC_CONFIG */
+#define GEM_HS_MAC_SPEED_OFFSET0
+#define GEM_HS_MAC_SPEED_SIZE 3
+
/* Bitfields in PCS_CONTROL. */
#define GEM_PCS_CTRL_RST_OFFSET15
#define GEM_PCS_CTRL_RST_SIZE 1
@@ -535,6 +545,34 @@
#define GEM_RXBD_RDBUFF_OFFSET 8
#define GEM_RXBD_RDBUFF_SIZE 4
+/* Bitfields in DCFG12. */
+#define GEM_HIGH_SPEED_OFFSET 26
+#define GEM_HIGH_SPEED_SIZE1
+
+/* Bitfields in USX_CONTROL. */
+#define GEM_USX_CTRL_SPEED_OFFSET 14
+#define GEM_USX_CTRL_SPEED_SIZE3
+#define GEM_SERDES_RATE_OFFSET 12
+#define GEM_SERDES_RATE_SIZE 2
+#define GEM_RX_SCR_BYPASS_OFFSET 9
+#define GEM_RX_SCR_BYPASS_SIZE 1
+#define GEM_TX_SCR_BYPASS_OFFSET 8
+#define GEM_TX_SCR_BYPASS_SIZE 1
+#define GEM_RX_SYNC_RESET_OFFSET 2
+#define GEM_RX_SYNC_RESET_SIZE 1
+#define GEM_TX_EN_OFFSET 1
+#define GEM_TX_EN_SIZE 1
+#define GEM_SIGNAL_OK_OFFSET 0
+#define GEM_SIGNAL_OK_SIZE 1
+
+/* Bitfields in USX_STATUS. */
+#define GEM_USX_TX_FAULT_OFFSET28
+#define GEM_USX_TX_FAULT_SIZE 1
+#define GEM_USX_RX_FAULT_OFFSET27
+#define GEM_USX_RX_FAULT_SIZE 1
+#define GEM_USX_BLOCK_LOCK_OFFSET 0
+#define GEM_USX_BLOCK_LOCK_SIZE1
+
/* Bitfields in TISUBN */
#define GEM_SUBNSINCR_OFFSET 0
#define GEM_SUBNSINCR_SIZE 16
@@ -695,6 +733,7 @@
#define MACB_CAPS_MACB_IS_GEM BIT(31)
#define MACB_CAPS_PCS BIT(24)
#define MACB_CAPS_MACB_IS_GEM_GXL BIT(25)
+#define MACB_CAPS_HIGH_SPEED BIT(26)
#define MACB_GEM7010_IDNUM 0x009
#define MACB_GEM7014_IDNU 0x107
@@ -774,6 +813,7 @@
})
#define MACB_READ_NSR(bp) macb_readl(bp, NSR)
+#define GEM_READ_USX_STATUS(bp)gem_readl(bp, USX_STATUS)
/* struct macb_dma_desc - Hardware DMA descriptor
* @addr: DMA address of data buffer
@@ -1287,6 +1327,7 @@ struct macb {
struct macb_pm_data pm_data;
struct phylink *pl;
struct phylink_config pl_config;
+ u32 serdes_rate;
};
#ifdef CONFIG_MACB_USE_HWSTAMP
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index cf63381d54ee..7b59e64dfe20 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -87,6 +87,20 @@ static struct sifive_fu540_macb_mgmt *mgmt;
#define MACB_WOL_HAS_MAGIC_PACKET (0x1 << 0)
#define MACB_WOL_ENABLED (0x1 << 1)
+enum {
+ HS_MAC_SPEED_100M,
+ HS_MAC_SPEED_1000M,
+ H
[PATCH v2 5/5] net: macb: parameter added to cadence ethernet controller DT binding
New parameters added to Cadence ethernet controller DT binding for USXGMII interface. Signed-off-by: Parshuram Thombare --- Documentation/devicetree/bindings/net/macb.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index 63c73fafe26d..dabdf9d3b574 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -28,6 +28,9 @@ Required properties: Optional elements: 'rx_clk' applies to cdns,zynqmp-gem Optional elements: 'tsu_clk' - clocks: Phandles to input clocks. +- serdes-rate-gbps External serdes rate.Mandatory for USXGMII mode. + 5 - 5G + 10 - 10G The MAC address will be determined using the optional properties defined in ethernet.txt. -- 2.17.1
Re: [PATCH 4.19 00/75] 4.19.53-stable review
On 17/06/2019 22:09, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.53 release. > There are 75 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 19 Jun 2019 09:06:21 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.53-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v4.19: 12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 32 tests: 32 pass, 0 fail Linux version: 4.19.53-rc1-gd486e007abd0 Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH 5.1 000/115] 5.1.12-stable review
On 17/06/2019 22:08, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.1.12 release. > There are 115 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 19 Jun 2019 09:06:21 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.12-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.1.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v5.1: 12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 32 tests: 32 pass, 0 fail Linux version: 5.1.12-rc1-g760bc74bb0d3 Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
RE: [RFC net-next 1/5] net: stmmac: introduce IEEE 802.1Qbv configuration functionalities
> > +static int est_poll_srwo(void *ioaddr) {
> > + /* Poll until the EST GCL Control[SRWO] bit clears.
> > +* Total wait = 12 x 50ms ~= 0.6s.
> > +*/
> > + unsigned int retries = 12;
> > + unsigned int value;
> > +
> > + do {
> > + value = TSN_RD32(ioaddr + MTL_EST_GCL_CTRL);
> > + if (!(value & MTL_EST_GCL_CTRL_SRWO))
> > + return 0;
> > + msleep(50);
> > + } while (--retries);
> > +
> > + return -ETIMEDOUT;
>
> Maybe use one of the readx_poll_timeout() macros?
>
> > +static int est_read_gce(void *ioaddr, unsigned int row,
> > + unsigned int *gates, unsigned int *ti_nsec,
> > + unsigned int dbgb, unsigned int dbgm) {
> > + struct tsn_hw_cap *cap = &dw_tsn_hwcap;
> > + unsigned int ti_wid = cap->ti_wid;
> > + unsigned int gates_mask;
> > + unsigned int ti_mask;
> > + unsigned int value;
> > + int ret;
> > +
> > + gates_mask = (1 << cap->txqcnt) - 1;
> > + ti_mask = (1 << ti_wid) - 1;
> > +
> > + ret = est_read_gcl_config(ioaddr, &value, row, 0, dbgb, dbgm);
> > + if (ret) {
> > + TSN_ERR("Read GCE failed! row=%u\n", row);
>
> It is generally not a good idea to put wrappers around the kernel print
> functions. It would be better if all these functions took struct
> stmmac_priv *priv rather than ioaddr, so you could then do
>
> netdev_err(priv->dev, "Read GCE failed! row=%u\n", row);
>
> > + /* Ensure that HW is not in the midst of GCL transition */
> > + value = TSN_RD32(ioaddr + MTL_EST_CTRL);
>
> Also, don't put wrapper around readl()/writel().
>
> > + value &= ~MTL_EST_CTRL_SSWL;
> > +
> > + /* MTL_EST_CTRL value has been read earlier, if TILS value
> > +* differs, we update here.
> > +*/
> > + if (tils != dw_tsn_hwtunable[TSN_HWTUNA_TX_EST_TILS]) {
> > + value &= ~MTL_EST_CTRL_TILS;
> > + value |= (tils << MTL_EST_CTRL_TILS_SHIFT);
> > +
> > + TSN_WR32(value, ioaddr + MTL_EST_CTRL);
> > + dw_tsn_hwtunable[TSN_HWTUNA_TX_EST_TILS] = tils;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int est_set_ov(void *ioaddr,
> > + const unsigned int *ptov,
> > + const unsigned int *ctov)
> > +{
> > + unsigned int value;
> > +
> > + if (!dw_tsn_feat_en[TSN_FEAT_ID_EST])
> > + return -ENOTSUPP;
> > +
> > + value = TSN_RD32(ioaddr + MTL_EST_CTRL);
> > + value &= ~MTL_EST_CTRL_SSWL;
> > +
> > + if (ptov) {
> > + if (*ptov > EST_PTOV_MAX) {
> > + TSN_WARN("EST: invalid PTOV(%u), max=%u\n",
> > +*ptov, EST_PTOV_MAX);
>
> It looks like most o the TSN_WARN should actually be netdev_dbg().
>
>Andrew
Hi Andrew,
This file is targeted for dual licensing which is GPL-2.0 OR BSD-3-Clause.
This is the reason why we are using wrappers around the functions so that
all the function call is generic.
Regards,
Weifeng
Re: [PATCH 4.14 00/53] 4.14.128-stable review
On 17/06/2019 22:09, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.128 release. > There are 53 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 19 Jun 2019 09:06:21 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.128-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h I am still waiting on the test results for 4.14-128-rc1. The builds are all passing, but waiting for the tests to complete. We have been having some issues with our test farm this week and so the results are delayed, but should be available later today, I hope. Cheers Jon -- nvpublic
Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
Hi Miquel,
> > >
> > > Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND
controller
> > >
> > > On Tue, 18 Jun 2019 08:14:36 +0200
> > > Boris Brezillon wrote:
> > >
> > > > > > > > >
> > > > > > > > > How to make all #CS keep high for NAND to enter
> > > > > > > > > low-power standby mode if driver don't use
> > "legacy.select_chip()"
> > > > > ?
> > > > > > > >
> > > > > > > > See commit 02b4a52604a4 ("mtd: rawnand: Make
->select_chip()
> > > > > optional
> > > > > > > > when ->exec_op() is implemented") which states:
> > > > > > > >
> > > > > > > > "When [->select_chip() is] not implemented, the
core
> > is
> > > > > assuming
> > > > > > > >the CS line is automatically asserted/deasserted by the
> > driver
> > > > > > > >->exec_op() implementation."
> > > > > > > >
> > > > > > > > Of course, the above is right only when the controller
driver
> >
> > > > > supports
> > > > > > > > the ->exec_op() interface.
> > > > > > >
> > > > > > > Currently, it seems that we will get the incorrect data and
> > error
> > > > > > > operation due to CS in error toggling if CS line is
controlled
> > in
> > > > > > > ->exec_op().
> > >
> > > Oh, and please provide the modifications you added on top of this
patch.
> > > Right now we're speculating on what you've done which is definitely
not
> > > an efficient way to debug this sort of issues.
> >
>
> We really need to see the datasheet of the NAND chip which has a
> problem and how this LPM mode is advertized to understand what the
> chip expects and eventually how to work-around it.
okay, got it and thanks.
>
> > The patch is to add in beginning of ->exec_op() to control CS# low and
> > before return from ->exec_op() to control CS# High.
> > i.e,.
> > static in mxic_nand_exec_op( )
> > {
> > cs_to_low();
> >
> >
> >
> > cs_to_high();
> > return;
> > }
> >
> > But for nand_onfi_detect(),
> > it calls nand_read_param_page_op() and then nand_read_data_op().
> > mxic_nand_exec_op() be called twice for nand_onfi_detect()
>
> Yes, this is expected and usually chips don't care.
got it and I will try to fix it on my NFC driver.
>
> > and
> > driver will get incorrect ONFI parameter table data from
> > nand_read_data_op().
> >
>
> Thanks,
> Miquèl
best regards,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or
personal data, which is protected by applicable laws. Please be reminded that
duplication, disclosure, distribution, or use of this e-mail (and/or its
attachments) or any part thereof is prohibited. If you receive this e-mail in
error, please notify us immediately and delete this mail as well as its
attachment(s) from your system. In addition, please be informed that
collection, processing, and/or use of personal data is prohibited unless
expressly permitted by personal data protection laws. Thank you for your
attention and cooperation.
Macronix International Co., Ltd.
=
Re: linux-next: build failure after merge of the net-next tree
Greetings!
As the guilty party in authoring this, and also pretty new around here
I’m wondering what I need to do to help clean it up?
> On 19 Jun 2019, at 05:14, Masahiro Yamada
> wrote:
>
> On Wed, Jun 19, 2019 at 1:02 PM Masahiro Yamada
> wrote:
>>
>> Hi.
>>
>>
>> On Wed, Jun 19, 2019 at 12:23 PM Stephen Rothwell
>> wrote:
>>>
>>> Hi all,
>>>
>>> After merging the net-next tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> In file included from usr/include/linux/tc_act/tc_ctinfo.hdrtest.c:1:
>>> ./usr/include/linux/tc_act/tc_ctinfo.h:30:21: error: implicit declaration
>>> of function 'BIT' [-Werror=implicit-function-declaration]
>>> CTINFO_MODE_DSCP = BIT(0),
>>> ^~~
>>> ./usr/include/linux/tc_act/tc_ctinfo.h:30:2: error: enumerator value for
>>> 'CTINFO_MODE_DSCP' is not an integer constant
>>> CTINFO_MODE_DSCP = BIT(0),
>>> ^~~~
>>> ./usr/include/linux/tc_act/tc_ctinfo.h:32:1: error: enumerator value for
>>> 'CTINFO_MODE_CPMARK' is not an integer constant
>>> };
>>> ^
>>>
>>> Caused by commit
>>>
>>> 24ec483cec98 ("net: sched: Introduce act_ctinfo action")
>>>
>>> Presumably exposed by commit
>>>
>>> b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are
>>> self-contained")
>>>
>>> from the kbuild tree.
Stephen, thanks for the fixup - is that now in the tree or do I need to submit
a fix via the normal net-next channel so it gets picked up by the iproute2
people
who maintain a local copy of the uapi includes?
>>
>>
>> My commit correctly blocked the broken UAPI header, Hooray!
>>
>> People export more and more headers that
>> are never able to compile in user-space.
>>
>> We must block new breakages from coming in.
>>
>>
>> BIT() is not exported to user-space
>> since it is not prefixed with underscore.
>>
>>
>> You can use _BITUL() in user-space,
>> which is available in include/uapi/linux/const.h
Thanks for the pointers.
I am confused as to why I didn’t hit this issue when I built & run tested
locally off
the net-next tree.
>>
>>
>
>
> I just took a look at
> include/uapi/linux/tc_act/tc_ctinfo.h
>
>
> I just wondered why the following can be compiled:
>
> struct tc_ctinfo {
>tc_gen;
> };
>
>
> Then, I found 'tc_gen' is a macro.
>
> #define tc_gen \
>__u32 index; \
>__u32 capab; \
>int action; \
>int refcnt; \
>int bindcnt
>
>
>
> What a hell.
This is what other actions do e.g. tc_skbedit. Can you advise what I should do
instead?
> --
> Best Regards
> Masahiro Yamada
Many thanks to all for your valuable time & advice.
Cheers,
Kevin D-B
gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
signature.asc
Description: Message signed with OpenPGP
Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
Hi Boris,
> > >
> > > Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND
controller
> > >
> > > On Tue, 18 Jun 2019 08:14:36 +0200
> > > Boris Brezillon wrote:
> > >
> > > > > > > > >
> > > > > > > > > How to make all #CS keep high for NAND to enter
> > > > > > > > > low-power standby mode if driver don't use
> > "legacy.select_chip()"
> > > > > ?
> > > > > > > >
> > > > > > > > See commit 02b4a52604a4 ("mtd: rawnand: Make
->select_chip()
> > > > > optional
> > > > > > > > when ->exec_op() is implemented") which states:
> > > > > > > >
> > > > > > > > "When [->select_chip() is] not implemented, the
core
> > is
> > > > > assuming
> > > > > > > >the CS line is automatically asserted/deasserted by the
> > driver
> > > > > > > >->exec_op() implementation."
> > > > > > > >
> > > > > > > > Of course, the above is right only when the controller
driver
> >
> > > > > supports
> > > > > > > > the ->exec_op() interface.
> > > > > > >
> > > > > > > Currently, it seems that we will get the incorrect data and
> > error
> > > > > > > operation due to CS in error toggling if CS line is
controlled
> > in
> > > > > > > ->exec_op().
> > >
> > > Oh, and please provide the modifications you added on top of this
patch.
> > > Right now we're speculating on what you've done which is definitely
not
> > > an efficient way to debug this sort of issues.
> >
> > The patch is to add in beginning of ->exec_op() to control CS# low and
> > before return from ->exec_op() to control CS# High.
> > i.e,.
> > static in mxic_nand_exec_op( )
> > {
> > cs_to_low();
> >
> >
> >
> > cs_to_high();
> > return;
> > }
> >
> > But for nand_onfi_detect(),
> > it calls nand_read_param_page_op() and then nand_read_data_op().
> > mxic_nand_exec_op() be called twice for nand_onfi_detect() and
> > driver will get incorrect ONFI parameter table data from
> > nand_read_data_op().
>
> And I think it's valid to release the CE pin between
> read_param_page_op() (CMD(0xEC)+ADDR(0x0)) and read_data_op() (data
> cycles) if your chip is CE-dont-care compliant. So, either you have a
> problem with your controller driver (CS-related timings are incorrect)
> or your chip is not CE-dont-care compliant.
Understood, I will try to fix it on my NFC driver.
And I think CS# pin goes to high is much important for power consumption.
thanks & best regards,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or
personal data, which is protected by applicable laws. Please be reminded that
duplication, disclosure, distribution, or use of this e-mail (and/or its
attachments) or any part thereof is prohibited. If you receive this e-mail in
error, please notify us immediately and delete this mail as well as its
attachment(s) from your system. In addition, please be informed that
collection, processing, and/or use of personal data is prohibited unless
expressly permitted by personal data protection laws. Thank you for your
attention and cooperation.
Macronix International Co., Ltd.
=
Re: [PATCH V3 02/17] pinctrl: tegra: add suspend and resume support
On Wed, Jun 19, 2019 at 10:33:08AM +0200, Thierry Reding wrote:
> On Tue, Jun 18, 2019 at 09:41:03AM -0600, Stephen Warren wrote:
> > On 6/18/19 3:30 AM, Dmitry Osipenko wrote:
> > > 18.06.2019 12:22, Dmitry Osipenko пишет:
> > > > 18.06.2019 10:46, Sowjanya Komatineni пишет:
> > > > > This patch adds suspend and resume support for Tegra pinctrl driver
> > > > > and registers them to syscore so the pinmux settings are restored
> > > > > before the devices resume.
> > > > >
> > > > > Signed-off-by: Sowjanya Komatineni
> > > > > ---
> > > > > drivers/pinctrl/tegra/pinctrl-tegra.c| 62
> > > > >
> > > > > drivers/pinctrl/tegra/pinctrl-tegra.h| 5 +++
> > > > > drivers/pinctrl/tegra/pinctrl-tegra114.c | 1 +
> > > > > drivers/pinctrl/tegra/pinctrl-tegra124.c | 1 +
> > > > > drivers/pinctrl/tegra/pinctrl-tegra20.c | 1 +
> > > > > drivers/pinctrl/tegra/pinctrl-tegra210.c | 13 +++
> > > > > drivers/pinctrl/tegra/pinctrl-tegra30.c | 1 +
> > > > > 7 files changed, 84 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
> > > > > b/drivers/pinctrl/tegra/pinctrl-tegra.c
> > > > > index 34596b246578..ceced30d8bd1 100644
> > > > > --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
> > > > > +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
> > > > > @@ -20,11 +20,16 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > #include "../core.h"
> > > > > #include "../pinctrl-utils.h"
> > > > > #include "pinctrl-tegra.h"
> > > > > +#define EMMC2_PAD_CFGPADCTRL_0 0x1c8
> > > > > +#define EMMC4_PAD_CFGPADCTRL_0 0x1e0
> > > > > +#define EMMC_DPD_PARKING (0x1fff << 14)
> > > > > +
> > > > > static inline u32 pmx_readl(struct tegra_pmx *pmx, u32 bank, u32
> > > > > reg)
> > > > > {
> > > > > return readl(pmx->regs[bank] + reg);
> > > > > @@ -619,6 +624,48 @@ static void
> > > > > tegra_pinctrl_clear_parked_bits(struct tegra_pmx *pmx)
> > > > > pmx_writel(pmx, val, g->mux_bank, g->mux_reg);
> > > > > }
> > > > > }
> > > > > +
> > > > > + if (pmx->soc->has_park_padcfg) {
> > > > > + val = pmx_readl(pmx, 0, EMMC2_PAD_CFGPADCTRL_0);
> > > > > + val &= ~EMMC_DPD_PARKING;
> > > > > + pmx_writel(pmx, val, 0, EMMC2_PAD_CFGPADCTRL_0);
> > > > > +
> > > > > + val = pmx_readl(pmx, 0, EMMC4_PAD_CFGPADCTRL_0);
> > > > > + val &= ~EMMC_DPD_PARKING;
> > > > > + pmx_writel(pmx, val, 0, EMMC4_PAD_CFGPADCTRL_0);
> > > > > + }
> > > > > +}
> > > >
> > > > Is there any reason why parked_bit can't be changed to parked_bitmask
> > > > like I was
> > > > asking in a comment to v2?
> > > >
> > > > I suppose that it's more preferable to keep pinctrl-tegra.c
> > > > platform-agnostic for
> > > > consistency when possible, hence adding platform specifics here should
> > > > be discouraged.
> > > > And then the parked_bitmask will also result in a proper hardware
> > > > description in the code.
> > > >
> > >
> > > I'm now also vaguely recalling that Stephen Warren had some kind of a
> > > "code generator"
> > > for the pinctrl drivers. So I guess all those tables were auto-generated
> > > initially.
> > >
> > > Stephen, maybe you could adjust the generator to take into account the
> > > bitmask (of
> > > course if that's a part of the generated code) and then re-gen it all for
> > > Sowjanya?
> >
> > https://github.com/NVIDIA/tegra-pinmux-scripts holds the scripts that
> > generate tegra-pinctrlNNN.c. Seesoc-to-kernel-pinctrl-driver.py. IIRC,
> > tegra-pinctrl.c (the core file) isn't auto-generated. Sowjanya is welcome to
> > send a patch to that repo if the code needs to be updated.
>
> If we want to do that, we may need to start off by bringing the pinmux
> scripts up to date with the latest version of the generated files. There
> have been a number of changes in the meantime that cause the scripts to
> generate a bit of diff with regards to what's currently upstream. Sounds
> like something fairly trivial, though.
Something like the below should do the trick.
Thierry
--- >8 ---
From 9a684d2ad3c0e0c7b4dbda5904db1fda3757072b Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Wed, 19 Jun 2019 10:50:57 +0200
Subject: [pinmux scripts PATCH] Update kernel driver template
Some changes in recent years have modified the upstream kernel driver in
some ways that make it incompatible with the current template. Update
the template to take into account changes introduced by the following
commits:
commit e3d2160f12d6aa7a87d9db09d8458b4a3492cd45
Author: Paul Gortmaker
Date: Mon May 22 16:56:47 2017 -0400
pinctrl: tegra: clean up modular vs. non-modular distinctions
None of the Kconfigs for any of these drivers are tristate,
meaning that they curre
Re: [PATCH V2] i2c: tegra: disable irq in tegra_i2c_xfer_msg
On 18/06/2019 19:26, Dmitry Osipenko wrote:
> 18.06.2019 11:42, Bitan Biswas пишет:
>> tegra_i2c_xfer_msg initiates the I2C transfer in DMA
>> or PIO mode. It involves steps that need FIFO register
>> access, DMA API calls like dma_sync_single_for_device, etc.
>> Tegra I2C ISR has calls to tegra_i2c_empty_rx_fifo in PIO mode
>> and in DMA/PIO mode writes different I2C registers including
>> I2C interrupt status. ISR cannot start processing
>> before the preparation step at tegra_i2c_xfer_msg is complete.
>> Hence, a synchronization between ISR and tegra_i2c_xfer_msg
>> is in place today using spinlock.
>
> Please use full 75 chars per-line, this should make commit message to look
> better.
>
>> Spinlock busy waits and can add avoidable delays.
>>
>> In this patch needed synchronization is achieved by disabling
>> I2C interrupt during preparation step and enabling interrupt
>> once preparation is over and spinlock is no longer needed.
>>
>> Signed-off-by: Bitan Biswas
>> ---
>> drivers/i2c/busses/i2c-tegra.c | 17 -
>> 1 file changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>> index 6fb545e..ccc7fae 100644
>> --- a/drivers/i2c/busses/i2c-tegra.c
>> +++ b/drivers/i2c/busses/i2c-tegra.c
>> @@ -240,7 +240,6 @@ struct tegra_i2c_hw_feature {
>> * @bus_clk_rate: current I2C bus clock rate
>> * @clk_divisor_non_hs_mode: clock divider for non-high-speed modes
>> * @is_multimaster_mode: track if I2C controller is in multi-master mode
>> - * @xfer_lock: lock to serialize transfer submission and processing
>> * @tx_dma_chan: DMA transmit channel
>> * @rx_dma_chan: DMA receive channel
>> * @dma_phys: handle to DMA resources
>> @@ -270,8 +269,6 @@ struct tegra_i2c_dev {
>> u32 bus_clk_rate;
>> u16 clk_divisor_non_hs_mode;
>> bool is_multimaster_mode;
>> -/* xfer_lock: lock to serialize transfer submission and processing */
>> -spinlock_t xfer_lock;
>> struct dma_chan *tx_dma_chan;
>> struct dma_chan *rx_dma_chan;
>> dma_addr_t dma_phys;
>> @@ -835,7 +832,6 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
>>
>> status = i2c_readl(i2c_dev, I2C_INT_STATUS);
>>
>> -spin_lock(&i2c_dev->xfer_lock);
>> if (status == 0) {
>> dev_warn(i2c_dev->dev, "irq status 0 %08x %08x %08x\n",
>> i2c_readl(i2c_dev, I2C_PACKET_TRANSFER_STATUS),
>> @@ -935,7 +931,6 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
>>
>> complete(&i2c_dev->msg_complete);
>> done:
>> -spin_unlock(&i2c_dev->xfer_lock);
>> return IRQ_HANDLED;
>> }
>>
>> @@ -1054,7 +1049,6 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
>> *i2c_dev,
>> u32 packet_header;
>> u32 int_mask;
>> unsigned long time_left;
>> -unsigned long flags;
>> size_t xfer_size;
>> u32 *buffer = NULL;
>> int err = 0;
>> @@ -1085,7 +1079,10 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
>> *i2c_dev,
>> */
>> xfer_time += DIV_ROUND_CLOSEST(((xfer_size * 9) + 2) * MSEC_PER_SEC,
>> i2c_dev->bus_clk_rate);
>> -spin_lock_irqsave(&i2c_dev->xfer_lock, flags);
>> +if (!i2c_dev->irq_disabled) {
>> +disable_irq_nosync(i2c_dev->irq);
>> +i2c_dev->irq_disabled = true;
>> +}
>
> 1) Peter correctly pointed out in the other email that the disabling should
> be synced.
> But see more below in 3.
>
> 2) i2c_dev->irq_disabled == true can't ever be the case here because
> tegra_i2c_init()
> re-enables interrupt in a case of error condition. Hence interrupt always
> enabled at
> the beginning of the transfer.
>
> 3) In my previous answer I was suggesting to request IRQ in a disabled state,
> this
> will allow to remove i2c_dev->irq_disabled completely.
>
> Then the tegra_i2c_xfer_msg() will have to enable IRQ after completion of the
> transfer-preparation process and disable IRQ once transfer is done (both
> success and
> failure cases). This is actually not a bad additional motivation for this
> patch, to
> keep CPU's interrupt disabled while idling and not to only rely on interrupt
> masking
> of the I2C hardware.
>
> 4) ISR should simply return IRQ_NONE when interrupt status is 0 and allow
> kernel core
> to disable the faulty interrupt itself. There will be "unhandled interrupt"
> error
> message in KMSG log, following the disabling.
>
> 5) In order to request IRQ in a disabled state, the IRQ_NOAUTOEN flag need to
> be set
> before the requesting, like this:
>
> irq_set_status_flags(irq, IRQ_NOAUTOEN);
>
> devm_request_irq(&pdev->dev, irq...);
>
> In a result of combining 3-5, both i2c_dev->irq_disabled and i2c_dev->irq
> variables
> become obsolete and could be removed in addition to xfer_lock. That all is a
> good
> cleanup in my opinion.
I see, so basically you are simplifying the code by waiting to enable
the interrup
[PATCH] ext4: remove redundant assignment to node
From: Colin Ian King
Pointer 'node' is assigned a value that is never read, node is
later overwritten when it re-assigned a different value inside
the while-loop. The assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
fs/ext4/extents_status.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
index 023a3eb3afa3..7521de2dcf3a 100644
--- a/fs/ext4/extents_status.c
+++ b/fs/ext4/extents_status.c
@@ -1317,7 +1317,6 @@ static int es_do_reclaim_extents(struct ext4_inode_info
*ei, ext4_lblk_t end,
es = __es_tree_search(&tree->root, ei->i_es_shrink_lblk);
if (!es)
goto out_wrap;
- node = &es->rb_node;
while (*nr_to_scan > 0) {
if (es->es_lblk > end) {
ei->i_es_shrink_lblk = end + 1;
--
2.20.1
Re: [PATCH V2] i2c: tegra: disable irq in tegra_i2c_xfer_msg
19.06.2019 11:58, Jon Hunter пишет:
>
> On 18/06/2019 19:26, Dmitry Osipenko wrote:
>> 18.06.2019 11:42, Bitan Biswas пишет:
>>> tegra_i2c_xfer_msg initiates the I2C transfer in DMA
>>> or PIO mode. It involves steps that need FIFO register
>>> access, DMA API calls like dma_sync_single_for_device, etc.
>>> Tegra I2C ISR has calls to tegra_i2c_empty_rx_fifo in PIO mode
>>> and in DMA/PIO mode writes different I2C registers including
>>> I2C interrupt status. ISR cannot start processing
>>> before the preparation step at tegra_i2c_xfer_msg is complete.
>>> Hence, a synchronization between ISR and tegra_i2c_xfer_msg
>>> is in place today using spinlock.
>>
>> Please use full 75 chars per-line, this should make commit message to look
>> better.
>>
>>> Spinlock busy waits and can add avoidable delays.
>>>
>>> In this patch needed synchronization is achieved by disabling
>>> I2C interrupt during preparation step and enabling interrupt
>>> once preparation is over and spinlock is no longer needed.
>>>
>>> Signed-off-by: Bitan Biswas
>>> ---
>>> drivers/i2c/busses/i2c-tegra.c | 17 -
>>> 1 file changed, 8 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>>> index 6fb545e..ccc7fae 100644
>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>> @@ -240,7 +240,6 @@ struct tegra_i2c_hw_feature {
>>> * @bus_clk_rate: current I2C bus clock rate
>>> * @clk_divisor_non_hs_mode: clock divider for non-high-speed modes
>>> * @is_multimaster_mode: track if I2C controller is in multi-master mode
>>> - * @xfer_lock: lock to serialize transfer submission and processing
>>> * @tx_dma_chan: DMA transmit channel
>>> * @rx_dma_chan: DMA receive channel
>>> * @dma_phys: handle to DMA resources
>>> @@ -270,8 +269,6 @@ struct tegra_i2c_dev {
>>> u32 bus_clk_rate;
>>> u16 clk_divisor_non_hs_mode;
>>> bool is_multimaster_mode;
>>> - /* xfer_lock: lock to serialize transfer submission and processing */
>>> - spinlock_t xfer_lock;
>>> struct dma_chan *tx_dma_chan;
>>> struct dma_chan *rx_dma_chan;
>>> dma_addr_t dma_phys;
>>> @@ -835,7 +832,6 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
>>>
>>> status = i2c_readl(i2c_dev, I2C_INT_STATUS);
>>>
>>> - spin_lock(&i2c_dev->xfer_lock);
>>> if (status == 0) {
>>> dev_warn(i2c_dev->dev, "irq status 0 %08x %08x %08x\n",
>>> i2c_readl(i2c_dev, I2C_PACKET_TRANSFER_STATUS),
>>> @@ -935,7 +931,6 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
>>>
>>> complete(&i2c_dev->msg_complete);
>>> done:
>>> - spin_unlock(&i2c_dev->xfer_lock);
>>> return IRQ_HANDLED;
>>> }
>>>
>>> @@ -1054,7 +1049,6 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
>>> *i2c_dev,
>>> u32 packet_header;
>>> u32 int_mask;
>>> unsigned long time_left;
>>> - unsigned long flags;
>>> size_t xfer_size;
>>> u32 *buffer = NULL;
>>> int err = 0;
>>> @@ -1085,7 +1079,10 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
>>> *i2c_dev,
>>> */
>>> xfer_time += DIV_ROUND_CLOSEST(((xfer_size * 9) + 2) * MSEC_PER_SEC,
>>> i2c_dev->bus_clk_rate);
>>> - spin_lock_irqsave(&i2c_dev->xfer_lock, flags);
>>> + if (!i2c_dev->irq_disabled) {
>>> + disable_irq_nosync(i2c_dev->irq);
>>> + i2c_dev->irq_disabled = true;
>>> + }
>>
>> 1) Peter correctly pointed out in the other email that the disabling should
>> be synced.
>> But see more below in 3.
>>
>> 2) i2c_dev->irq_disabled == true can't ever be the case here because
>> tegra_i2c_init()
>> re-enables interrupt in a case of error condition. Hence interrupt always
>> enabled at
>> the beginning of the transfer.
>>
>> 3) In my previous answer I was suggesting to request IRQ in a disabled
>> state, this
>> will allow to remove i2c_dev->irq_disabled completely.
>>
>> Then the tegra_i2c_xfer_msg() will have to enable IRQ after completion of the
>> transfer-preparation process and disable IRQ once transfer is done (both
>> success and
>> failure cases). This is actually not a bad additional motivation for this
>> patch, to
>> keep CPU's interrupt disabled while idling and not to only rely on interrupt
>> masking
>> of the I2C hardware.
>>
>> 4) ISR should simply return IRQ_NONE when interrupt status is 0 and allow
>> kernel core
>> to disable the faulty interrupt itself. There will be "unhandled interrupt"
>> error
>> message in KMSG log, following the disabling.
>>
>> 5) In order to request IRQ in a disabled state, the IRQ_NOAUTOEN flag need
>> to be set
>> before the requesting, like this:
>>
>> irq_set_status_flags(irq, IRQ_NOAUTOEN);
>>
>> devm_request_irq(&pdev->dev, irq...);
>>
>> In a result of combining 3-5, both i2c_dev->irq_disabled and i2c_dev->irq
>> variables
>> become obsolete and could be removed in addition to xfer_lock. That all is
Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
On Wed, 19 Jun 2019 16:55:52 +0800
masonccy...@mxic.com.tw wrote:
> Hi Boris,
>
> > > >
> > > > Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND
> controller
> > > >
> > > > On Tue, 18 Jun 2019 08:14:36 +0200
> > > > Boris Brezillon wrote:
> > > >
> > > > > > > > > >
> > > > > > > > > > How to make all #CS keep high for NAND to enter
> > > > > > > > > > low-power standby mode if driver don't use
> > > "legacy.select_chip()"
> > > > > > ?
> > > > > > > > >
> > > > > > > > > See commit 02b4a52604a4 ("mtd: rawnand: Make
> ->select_chip()
> > > > > > optional
> > > > > > > > > when ->exec_op() is implemented") which states:
> > > > > > > > >
> > > > > > > > > "When [->select_chip() is] not implemented, the
> core
> > > is
> > > > > > assuming
> > > > > > > > >the CS line is automatically asserted/deasserted by the
>
> > > driver
> > > > > > > > >->exec_op() implementation."
> > > > > > > > >
> > > > > > > > > Of course, the above is right only when the controller
> driver
> > >
> > > > > > supports
> > > > > > > > > the ->exec_op() interface.
> > > > > > > >
> > > > > > > > Currently, it seems that we will get the incorrect data and
>
> > > error
> > > > > > > > operation due to CS in error toggling if CS line is
> controlled
> > > in
> > > > > > > > ->exec_op().
> > > >
> > > > Oh, and please provide the modifications you added on top of this
> patch.
> > > > Right now we're speculating on what you've done which is definitely
> not
> > > > an efficient way to debug this sort of issues.
> > >
> > > The patch is to add in beginning of ->exec_op() to control CS# low and
>
> > > before return from ->exec_op() to control CS# High.
> > > i.e,.
> > > static in mxic_nand_exec_op( )
> > > {
> > > cs_to_low();
> > >
> > >
> > >
> > > cs_to_high();
> > > return;
> > > }
> > >
> > > But for nand_onfi_detect(),
> > > it calls nand_read_param_page_op() and then nand_read_data_op().
> > > mxic_nand_exec_op() be called twice for nand_onfi_detect() and
> > > driver will get incorrect ONFI parameter table data from
> > > nand_read_data_op().
> >
> > And I think it's valid to release the CE pin between
> > read_param_page_op() (CMD(0xEC)+ADDR(0x0)) and read_data_op() (data
> > cycles) if your chip is CE-dont-care compliant. So, either you have a
> > problem with your controller driver (CS-related timings are incorrect)
> > or your chip is not CE-dont-care compliant.
>
> Understood, I will try to fix it on my NFC driver.
Before you do that, can you please try to understand where the problem
comes from and explain it to us? Hacking the NFC driver is only
meaningful if the problem is on the NFC side. If your NAND chip does
not support when the CS pin goes high between read_param_page_op() and
read_data_op() the problem should be fixed in the core.
Re: [PATCH v2 1/1] cpuidle-powernv : forced wakeup for stop states
Hi Nick,
Thanks for the review. Some replies below.
On 06/19/2019 09:53 AM, Nicholas Piggin wrote:
Abhishek Goel's on June 17, 2019 7:56 pm:
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect, there are cases
where the governor predicts a shallow idle state, hoping that the CPU will
be busy soon. However, if no new workload is scheduled on that CPU in the
near future, the CPU may end up in the shallow state.
This is problematic, when the predicted state in the aforementioned
scenario is a shallow stop state on a tickless system. As we might get
stuck into shallow states for hours, in absence of ticks or interrupts.
To address this, We forcefully wakeup the cpu by setting the
decrementer. The decrementer is set to a value that corresponds with the
residency of the next available state. Thus firing up a timer that will
forcefully wakeup the cpu. Few such iterations will essentially train the
governor to select a deeper state for that cpu, as the timer here
corresponds to the next available cpuidle state residency. Thus, cpu will
eventually end up in the deepest possible state.
Signed-off-by: Abhishek Goel
---
Auto-promotion
v1 : started as auto promotion logic for cpuidle states in generic
driver
v2 : Removed timeout_needed and rebased the code to upstream kernel
Forced-wakeup
v1 : New patch with name of forced wakeup started
v2 : Extending the forced wakeup logic for all states. Setting the
decrementer instead of queuing up a hrtimer to implement the logic.
drivers/cpuidle/cpuidle-powernv.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index 84b1ebe212b3..bc9ca18ae7e3 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -46,6 +46,26 @@ static struct stop_psscr_table
stop_psscr_table[CPUIDLE_STATE_MAX] __read_mostly
static u64 default_snooze_timeout __read_mostly;
static bool snooze_timeout_en __read_mostly;
+static u64 forced_wakeup_timeout(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+ int i;
+
+ for (i = index + 1; i < drv->state_count; i++) {
+ struct cpuidle_state *s = &drv->states[i];
+ struct cpuidle_state_usage *su = &dev->states_usage[i];
+
+ if (s->disabled || su->disable)
+ continue;
+
+ return (s->target_residency + 2 * s->exit_latency) *
+ tb_ticks_per_usec;
+ }
+
+ return 0;
+}
It would be nice to not have this kind of loop iteration in the
idle fast path. Can we add a flag or something to the idle state?
Currently, we do not have any callback notification or some feedback that
notifies the driver everytime some state is enabled/disabled. So we have
to parse everytime to get the next enabled state. Are you suggesting to
add something like next_enabled_state in cpuidle state structure itself
which will be updated when a state is enabled or disabled?
+
static u64 get_snooze_timeout(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -144,8 +164,26 @@ static int stop_loop(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
+ u64 dec_expiry_tb, dec, timeout_tb, forced_wakeup;
+
+ dec = mfspr(SPRN_DEC);
+ timeout_tb = forced_wakeup_timeout(dev, drv, index);
+ forced_wakeup = 0;
+
+ if (timeout_tb && timeout_tb < dec) {
+ forced_wakeup = 1;
+ dec_expiry_tb = mftb() + dec;
+ }
The compiler probably can't optimise away the SPR manipulations so try
to avoid them if possible.
Are you suggesting something like set_dec_before_idle?(in line with
what you have suggested to do after idle, reset_dec_after_idle)
+
+ if (forced_wakeup)
+ mtspr(SPRN_DEC, timeout_tb);
This should just be put in the above 'if'.
Fair point.
+
power9_idle_type(stop_psscr_table[index].val,
stop_psscr_table[index].mask);
+
+ if (forced_wakeup)
+ mtspr(SPRN_DEC, dec_expiry_tb - mftb());
This will sometimes go negative and result in another timer interrupt.
It also breaks irq work (which can be set here by machine check I
believe.
May need to implement some timer code to do this for you.
static void reset_dec_after_idle(void)
{
u64 now;
u64 *next_tb;
if (test_irq_work_pending())
return;
now = mftb;
next_tb = this_cpu_ptr(&decrementers_next_tb);
if (now >= *next_tb)
return;
set_dec(*next_tb - now);
if (test_irq_work_pen
Re: [PATCH V2] i2c: tegra: disable irq in tegra_i2c_xfer_msg
19.06.2019 12:02, Dmitry Osipenko пишет:
> 19.06.2019 11:58, Jon Hunter пишет:
>>
>> On 18/06/2019 19:26, Dmitry Osipenko wrote:
>>> 18.06.2019 11:42, Bitan Biswas пишет:
tegra_i2c_xfer_msg initiates the I2C transfer in DMA
or PIO mode. It involves steps that need FIFO register
access, DMA API calls like dma_sync_single_for_device, etc.
Tegra I2C ISR has calls to tegra_i2c_empty_rx_fifo in PIO mode
and in DMA/PIO mode writes different I2C registers including
I2C interrupt status. ISR cannot start processing
before the preparation step at tegra_i2c_xfer_msg is complete.
Hence, a synchronization between ISR and tegra_i2c_xfer_msg
is in place today using spinlock.
>>>
>>> Please use full 75 chars per-line, this should make commit message to look
>>> better.
>>>
Spinlock busy waits and can add avoidable delays.
In this patch needed synchronization is achieved by disabling
I2C interrupt during preparation step and enabling interrupt
once preparation is over and spinlock is no longer needed.
Signed-off-by: Bitan Biswas
---
drivers/i2c/busses/i2c-tegra.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c
b/drivers/i2c/busses/i2c-tegra.c
index 6fb545e..ccc7fae 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -240,7 +240,6 @@ struct tegra_i2c_hw_feature {
* @bus_clk_rate: current I2C bus clock rate
* @clk_divisor_non_hs_mode: clock divider for non-high-speed modes
* @is_multimaster_mode: track if I2C controller is in multi-master mode
- * @xfer_lock: lock to serialize transfer submission and processing
* @tx_dma_chan: DMA transmit channel
* @rx_dma_chan: DMA receive channel
* @dma_phys: handle to DMA resources
@@ -270,8 +269,6 @@ struct tegra_i2c_dev {
u32 bus_clk_rate;
u16 clk_divisor_non_hs_mode;
bool is_multimaster_mode;
- /* xfer_lock: lock to serialize transfer submission and processing */
- spinlock_t xfer_lock;
struct dma_chan *tx_dma_chan;
struct dma_chan *rx_dma_chan;
dma_addr_t dma_phys;
@@ -835,7 +832,6 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
status = i2c_readl(i2c_dev, I2C_INT_STATUS);
- spin_lock(&i2c_dev->xfer_lock);
if (status == 0) {
dev_warn(i2c_dev->dev, "irq status 0 %08x %08x %08x\n",
i2c_readl(i2c_dev, I2C_PACKET_TRANSFER_STATUS),
@@ -935,7 +931,6 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
complete(&i2c_dev->msg_complete);
done:
- spin_unlock(&i2c_dev->xfer_lock);
return IRQ_HANDLED;
}
@@ -1054,7 +1049,6 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
u32 packet_header;
u32 int_mask;
unsigned long time_left;
- unsigned long flags;
size_t xfer_size;
u32 *buffer = NULL;
int err = 0;
@@ -1085,7 +1079,10 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
*/
xfer_time += DIV_ROUND_CLOSEST(((xfer_size * 9) + 2) * MSEC_PER_SEC,
i2c_dev->bus_clk_rate);
- spin_lock_irqsave(&i2c_dev->xfer_lock, flags);
+ if (!i2c_dev->irq_disabled) {
+ disable_irq_nosync(i2c_dev->irq);
+ i2c_dev->irq_disabled = true;
+ }
>>>
>>> 1) Peter correctly pointed out in the other email that the disabling should
>>> be synced.
>>> But see more below in 3.
>>>
>>> 2) i2c_dev->irq_disabled == true can't ever be the case here because
>>> tegra_i2c_init()
>>> re-enables interrupt in a case of error condition. Hence interrupt always
>>> enabled at
>>> the beginning of the transfer.
>>>
>>> 3) In my previous answer I was suggesting to request IRQ in a disabled
>>> state, this
>>> will allow to remove i2c_dev->irq_disabled completely.
>>>
>>> Then the tegra_i2c_xfer_msg() will have to enable IRQ after completion of
>>> the
>>> transfer-preparation process and disable IRQ once transfer is done (both
>>> success and
>>> failure cases). This is actually not a bad additional motivation for this
>>> patch, to
>>> keep CPU's interrupt disabled while idling and not to only rely on
>>> interrupt masking
>>> of the I2C hardware.
>>>
>>> 4) ISR should simply return IRQ_NONE when interrupt status is 0 and allow
>>> kernel core
>>> to disable the faulty interrupt itself. There will be "unhandled interrupt"
>>> error
>>> message in KMSG log, following the disabling.
>>>
>>> 5) In order to request IRQ in a disabled state, the IRQ_NOAUTOEN flag need
>>> to be set
>>> before the requesting, like this:
>>>
>>> irq_set_status_flags(irq, IRQ_NOAUTOEN);
>>>
>>> devm_request_irq(&pdev->dev, irq...);
>>>
>>> In a result of combin
Re: [PATCH v5 04/14] soc: mediatek: Refactor polling timeout and documentation
On Tue, 2019-03-19 at 19:45 +0800, Nicolas Boichat wrote:
> On Tue, Mar 19, 2019 at 4:02 PM Weiyi Lu wrote:
> >
> > Use USEC_PER_SEC to indicate the polling timeout directly.
> > And add documentation of scp_domain_data.
> >
> > Signed-off-by: Weiyi Lu
> > ---
> > drivers/soc/mediatek/mtk-scpsys.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> > b/drivers/soc/mediatek/mtk-scpsys.c
> > index 9f52f501178b..2855111b221a 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -21,7 +21,7 @@
> > #include
> >
> > #define MTK_POLL_DELAY_US 10
> > -#define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> > +#define MTK_POLL_TIMEOUTUSEC_PER_SEC
> >
> > #define MTK_SCPD_ACTIVE_WAKEUP BIT(0)
> > #define MTK_SCPD_FWAIT_SRAMBIT(1)
> > @@ -108,6 +108,18 @@ static const char * const clk_names[] = {
> >
> > #define MAX_CLKS 3
> >
> > +/**
> > + * struct scp_domain_data - scp domain data for power on/off flow
> > + * @name: The domain name.
> > + * @sta_mask: The mask for power on/off status bit.
> > + * @ctl_offs: The offset for main power control register.
> > + * @sram_pdn_bits: The mask for sram power control bits.
> > + * @sram_pdn_ack_bits: The mask for sram power control acked bits.
> > + * @bus_prot_mask: The mask for single step bus protection.
> > + * @clk_id: The basic clock needs to be enabled before enabling certain
> > + * power domains.
>
> I assume these are the clock*s* that *this* scp_domain requires?
>
> So maybe just: "The basic clocks required by this power domain." ?
>
Thanks for revision. I'll update in next version.
> > + * @caps: The flag for active wake-up action.
> > + */
> > struct scp_domain_data {
> > const char *name;
> > u32 sta_mask;
> > --
> > 2.18.0
> >
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
On Wed, Jun 19, 2019 at 09:54:21AM +0100, Julien Grall wrote: > On 6/19/19 9:07 AM, Guo Ren wrote: > > You forgot CCing C-SKY folks :P > > I wasn't aware you could be interested :). > > > Move arm asid allocator code in a generic one is a agood idea, I've > > made a patchset for C-SKY and test is on processing, See: > > https://lore.kernel.org/linux-csky/1560930553-26502-1-git-send-email-guo...@kernel.org/ > > > > If you plan to seperate it into generic one, I could co-work with you. > > Was the ASID allocator work out of box on C-Sky? If so, I can easily move > the code in a generic place (maybe lib/asid.c). This is one place where I'd actually prefer not to go down the route of making the code generic. Context-switching and low-level TLB management is deeply architecture-specific and I worry that by trying to make this code common, we run the real risk of introducing subtle bugs on some architecture every time it is changed. Furthermore, the algorithm we use on arm64 is designed to scale to large systems using DVM and may well be too complex and/or sub-optimal for architectures with different system topologies or TLB invalidation mechanisms. It's not a lot of code, so I don't see that it's a big deal to keep it under arch/arm64. Will
Re: [PATCH v2 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
On 18/06/2019 22:28, Jeremy Linton wrote:
Hi,
On 6/18/19 12:23 PM, John Garry wrote:
On 18/06/2019 15:40, Valentin Schneider wrote:
On 18/06/2019 15:21, Jeremy Linton wrote:
[...]
+ * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be
found or
+ * the table revision isn't new enough.
+ * Otherwise returns flag value
+ */
Nit: strictly speaking we're not returning the flag value but its mask
applied to the flags field. I don't think anyone will care about
getting
the actual flag value, but it should be made obvious in the doc:
Or I clarify the code to actually do what the comments says. Maybe
that is what John G was also pointing out too?
No, I was just saying that the kernel topology can be broken without
this series.
Mmm I didn't find any reply from John regarding this in v1, but I
wouldn't
mind either way, as long as the doc & code are aligned.
BTW, to me, function acpi_pptt_cpu_is_thread() seems to try to do too
much, i.e. check if the PPTT is new enough to support the thread flag
and also check if it is set for a specific cpu. I'd consider separate
functions here.
Hi,
? Your suggesting replacing the
I am not saying definitely that this should be changed, it's just that
acpi_pptt_cpu_is_thread() returning false, true, or "no entry" is not a
typical API format.
How about acpi_pptt_support_thread_info(cpu) and
acpi_pptt_cpu_is_threaded(cpu), both returning false/true only?
None of this is ideal.
BTW, Have you audited which arm64 systems have MT bit set legitimately?
if (table->revision >= rev)
I know that checking the table revision is not on the fast path, but it
seems unnecessarily inefficient to always read it this way, I mean
calling acpi_table_get().
Can you have a static value for the table revision? Or is this just how
other table info is accessed in ACPI code?
cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
check with
if (revision_check(table, rev))
cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
and a function like
static int revision_check(acpi *table, int rev)
{
return (table->revision >= rev);
}
Although, frankly if one were to do this, it should probably be a macro
with the table type, and used in the dozen or so other places I found
doing similar checks (spcr, iort, etc).
Or something else?
thanks,
John
[...]
.
.
Re: [PATCH V3 4/5] cpufreq: Register notifiers with the PM QoS framework
On Wed, Jun 19, 2019 at 8:39 AM Viresh Kumar wrote: > > On 19-06-19, 00:23, Rafael J. Wysocki wrote: > > In patch [3/5] you could point notifiers for both min and max freq to the > > same > > notifier head. Both of your notifiers end up calling > > cpufreq_update_policy() > > anyway. > > I tried it and the changes in qos.c file look fine. But I don't like at all > how > cpufreq.c looks now. We only register for min-freq notifier now and that takes > care of max as well. What could have been better is if we could have > registered > a freq-notifier instead of min/max, which isn't possible as well because of > how > qos framework works. > > Honestly, the cpufreq changes look hacky to me :( > > What do you say. OK, leave it as is. That's not a big deal. It is slightly awkward, but oh well.
Re: [PATCH 10/21] tracing/probe: Split trace_event related data from trace_probe
On Wed, 19 Jun 2019 11:28:22 +0900 Masami Hiramatsu wrote: > > BTW, > > > > I pulled in patches 1-9 and I'm starting to test them now. > > Thanks! Should I send 10-21 patches in v2? Yes please. The tests have passed, and I will be pushing them to linux-next soon. But as I'm currently traveling, I can't give an exact time I will do that. -- Steve
Re: [PATCH v5 06/14] soc: mediatek: Refactor clock control
On Tue, 2019-03-19 at 20:02 +0800, Nicolas Boichat wrote:
> On Tue, Mar 19, 2019 at 4:02 PM Weiyi Lu wrote:
> >
> > Put clock enable and disable control in separate function.
> >
> > Signed-off-by: Weiyi Lu
> > ---
> > drivers/soc/mediatek/mtk-scpsys.c | 49 ---
> > 1 file changed, 32 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> > b/drivers/soc/mediatek/mtk-scpsys.c
> > index 765ad4a5e5df..3e9be07a2627 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -208,6 +208,33 @@ static int scpsys_regulator_disable(struct scp_domain
> > *scpd)
> > return regulator_disable(scpd->supply);
> > }
> >
> > +static int scpsys_clk_enable(struct clk *clk[], int max_num)
> > +{
> > + int i, ret = 0;
> > +
> > + for (i = 0; i < max_num && clk[i]; i++) {
> > + ret = clk_prepare_enable(clk[i]);
> > + if (ret) {
> > + for (--i; i >= 0; i--)
> > + clk_disable_unprepare(clk[i]);
>
> Would it be simpler to just call scpsys_clk_disable(clk, i) ?
>
OK, I'll try.
> > +
> > + break;
> > + }
> > + }
> > +
> > + return ret;
> > +}
>
> Maybe not for this series, but could you use clk_bulk_prepare_enable
> instead? The only issue is that it'd still call clk_prepare_enable on
> NULL clocks, but that does nothing, so it's just a little less
> efficient...
>
OK, I'll try after this series.
> > +
> > +static void scpsys_clk_disable(struct clk *clk[], int max_num)
> > +{
> > + int i;
> > +
> > + for (i = max_num - 1; i >= 0; i--) {
> > + if (clk[i])
>
> if test not needed, clk_disable_unprepare ignores NULL parameters.
>
You're right. Supposed it's not needed, I'll test.
> > + clk_disable_unprepare(clk[i]);
> > + }
> > +}
>
> ditto: clk_bulk_disable_unprepare
>
> > +
> > static int scpsys_power_on(struct generic_pm_domain *genpd)
> > {
> > struct scp_domain *scpd = container_of(genpd, struct scp_domain,
> > genpd);
> > @@ -216,21 +243,14 @@ static int scpsys_power_on(struct generic_pm_domain
> > *genpd)
> > u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> > u32 val;
> > int ret, tmp;
> > - int i;
> >
> > ret = scpsys_regulator_enable(scpd);
> > if (ret < 0)
> > return ret;
> >
> > - for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++) {
> > - ret = clk_prepare_enable(scpd->clk[i]);
> > - if (ret) {
> > - for (--i; i >= 0; i--)
> > - clk_disable_unprepare(scpd->clk[i]);
> > -
> > - goto err_clk;
> > - }
> > - }
> > + ret = scpsys_clk_enable(scpd->clk, MAX_CLKS);
> > + if (ret)
> > + goto err_clk;
> >
> > val = readl(ctl_addr);
> > val |= PWR_ON_BIT;
> > @@ -283,10 +303,7 @@ static int scpsys_power_on(struct generic_pm_domain
> > *genpd)
> > return 0;
> >
> > err_pwr_ack:
> > - for (i = MAX_CLKS - 1; i >= 0; i--) {
> > - if (scpd->clk[i])
> > - clk_disable_unprepare(scpd->clk[i]);
> > - }
> > + scpsys_clk_disable(scpd->clk, MAX_CLKS);
> > err_clk:
> > scpsys_regulator_disable(scpd);
> >
> > @@ -303,7 +320,6 @@ static int scpsys_power_off(struct generic_pm_domain
> > *genpd)
> > u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> > u32 val;
> > int ret, tmp;
> > - int i;
> >
> > if (scpd->data->bus_prot_mask) {
> > ret = mtk_infracfg_set_bus_protection(scp->infracfg,
> > @@ -344,8 +360,7 @@ static int scpsys_power_off(struct generic_pm_domain
> > *genpd)
> > if (ret < 0)
> > goto out;
> >
> > - for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++)
> > - clk_disable_unprepare(scpd->clk[i]);
> > + scpsys_clk_disable(scpd->clk, MAX_CLKS);
> >
> > ret = scpsys_regulator_disable(scpd);
> > if (ret < 0)
> > --
> > 2.18.0
> >
Re: [PATCH v2 1/5] net: macb: add phylink support
On Wed, Jun 19, 2019 at 09:40:36AM +0100, Parshuram Thombare wrote:
> This patch replace phylib API's by phylink API's.
>
> Signed-off-by: Parshuram Thombare
> ---
> drivers/net/ethernet/cadence/Kconfig | 2 +-
> drivers/net/ethernet/cadence/macb.h | 3 +
> drivers/net/ethernet/cadence/macb_main.c | 312 +--
> 3 files changed, 182 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig
> b/drivers/net/ethernet/cadence/Kconfig
> index 1766697c9c5a..d71411a71587 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -22,7 +22,7 @@ if NET_VENDOR_CADENCE
> config MACB
> tristate "Cadence MACB/GEM support"
> depends on HAS_DMA
> - select PHYLIB
> + select PHYLINK
> ---help---
> The Cadence MACB ethernet interface is found on many Atmel AT32 and
> AT91 parts. This driver also supports the Cadence GEM (Gigabit
> diff --git a/drivers/net/ethernet/cadence/macb.h
> b/drivers/net/ethernet/cadence/macb.h
> index 00ee5e8e0ff0..35ed13236c8b 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #if defined(CONFIG_ARCH_DMA_ADDR_T_64BIT) || defined(CONFIG_MACB_USE_HWSTAMP)
> #define MACB_EXT_DESC
> @@ -1227,6 +1228,8 @@ struct macb {
> u32 rx_intr_mask;
>
> struct macb_pm_data pm_data;
> + struct phylink *pl;
> + struct phylink_config pl_config;
> };
>
> #ifdef CONFIG_MACB_USE_HWSTAMP
> diff --git a/drivers/net/ethernet/cadence/macb_main.c
> b/drivers/net/ethernet/cadence/macb_main.c
> index c545c5b435d8..830af86d3c65 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include "macb.h"
>
> /* This structure is only used for MACB on SiFive FU540 devices */
> @@ -438,115 +439,150 @@ static void macb_set_tx_clk(struct clk *clk, int
> speed, struct net_device *dev)
> netdev_err(dev, "adjusting tx_clk failed.\n");
> }
>
> -static void macb_handle_link_change(struct net_device *dev)
> +static void gem_phylink_validate(struct phylink_config *pl_config,
> + unsigned long *supported,
> + struct phylink_link_state *state)
> {
> - struct macb *bp = netdev_priv(dev);
> - struct phy_device *phydev = dev->phydev;
> - unsigned long flags;
> - int status_change = 0;
> + struct net_device *netdev = to_net_dev(pl_config->dev);
> + struct macb *bp = netdev_priv(netdev);
> + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> +
> + switch (state->interface) {
> + case PHY_INTERFACE_MODE_GMII:
> + case PHY_INTERFACE_MODE_RGMII:
> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
> + phylink_set(mask, 1000baseT_Full);
> + phylink_set(mask, 1000baseX_Full);
> + if (!(bp->caps & MACB_CAPS_NO_GIGABIT_HALF)) {
> + phylink_set(mask, 1000baseT_Half);
> + phylink_set(mask, 1000baseT_Half);
> + }
> + }
> + /* fallthrough */
> + case PHY_INTERFACE_MODE_MII:
> + case PHY_INTERFACE_MODE_RMII:
> + phylink_set(mask, 10baseT_Half);
> + phylink_set(mask, 10baseT_Full);
> + phylink_set(mask, 100baseT_Half);
> + phylink_set(mask, 100baseT_Full);
> + break;
> + default:
> + break;
> + }
>
> - spin_lock_irqsave(&bp->lock, flags);
> + bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
> + bitmap_and(state->advertising, state->advertising, mask,
> +__ETHTOOL_LINK_MODE_MASK_NBITS);
Consider using linkmode_and() here.
> +}
>
> - if (phydev->link) {
> - if ((bp->speed != phydev->speed) ||
> - (bp->duplex != phydev->duplex)) {
> - u32 reg;
> +static int gem_phylink_mac_link_state(struct phylink_config *pl_config,
> + struct phylink_link_state *state)
> +{
> + struct net_device *netdev = to_net_dev(pl_config->dev);
> + struct macb *bp = netdev_priv(netdev);
>
> - reg = macb_readl(bp, NCFGR);
> - reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
> - if (macb_is_gem(bp))
> - reg &= ~GEM_BIT(GBE);
> + state->speed = bp->speed;
> + state->duplex = bp->duplex;
> + state->link = bp->link;
You can't read from the hardware what the actual MAC is doing?
> + return 1;
> +}
>
> - if (phydev->duplex)
> - reg |= MACB_BIT(FD);
> - if (phydev->speed == SPEED_100)
> -
Re: [PATCH 5/7] powerpc/ftrace: Update ftrace_location() for powerpc -mprofile-kernel
On Wed, 19 Jun 2019 13:26:37 +0530
"Naveen N. Rao" wrote:
> > In include/ftrace.h:
> >
> > #ifndef FTRACE_IP_EXTENSION
> > # define FTRACE_IP_EXTENSION0
> > #endif
> >
> >
> > In arch/powerpc/include/asm/ftrace.h
> >
> > #define FTRACE_IP_EXTENSION MCOUNT_INSN_SIZE
> >
> >
> > Then we can just have:
> >
> > unsigned long ftrace_location(unsigned long ip)
> > {
> > return ftrace_location_range(ip, ip + FTRACE_IP_EXTENSION);
> > }
>
> Thanks, that's indeed nice. I hope you don't mind me adding your SOB for
> that.
Actually, it's best not to put a SOB by anyone other than yourself. It
actually has legal meaning.
In this case, please add:
Suggested-by: Steven Rostedt (VMware)
Thanks!
-- Steve
Re: [PATCH] sched/core: Fix cpu controller for !RT_GROUP_SCHED
On Wed, Jun 05, 2019 at 04:20:03PM +0200, Michal Koutný wrote: > I considered relaxing the check to non-root cgroups only, however, as > your example shows, it doesn't prevent reaching the avoided state by > other paths. I'm not that familiar with RT sched to tell whether > RT-priority tasks in different task_groups break any assumptions. So I had another look and the check is bogus. The RT sched with !CONFIG_RT_GROUP_SCHED works only with the struct rt_rq embedded in the generic struct rq -- regardless of the task's membership in the cpu controller hierarchy. Perhaps, the commit message may mention this also prevents enabling cpu controller on unified hierarchy (if there are any (kernel) RT tasks to migrate). Reviewed-by: Michal Koutný
Re: [PATCH v5 07/14] soc: mediatek: Refactor sram control
On Tue, 2019-03-19 at 20:07 +0800, Nicolas Boichat wrote:
> On Tue, Mar 19, 2019 at 4:02 PM Weiyi Lu wrote:
> >
> > Put sram enable and disable control in separate functions.
> >
> > Signed-off-by: Weiyi Lu
>
> Refactoring looks ok, just a small comment.
>
> Reviewed-by: Nicolas Boichat
>
> > ---
> > drivers/soc/mediatek/mtk-scpsys.c | 79 ---
> > 1 file changed, 51 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> > b/drivers/soc/mediatek/mtk-scpsys.c
> > index 3e9be07a2627..65b734b40098 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -235,12 +235,55 @@ static void scpsys_clk_disable(struct clk *clk[], int
> > max_num)
> > }
> > }
> >
> > +static int scpsys_sram_enable(struct scp_domain *scpd, void __iomem
> > *ctl_addr)
> > +{
> > + u32 val;
> > + u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> > + int tmp;
> > +
> > + val = readl(ctl_addr) & ~scpd->data->sram_pdn_bits;
> > + writel(val, ctl_addr);
> > +
> > + /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> > + if (MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) {
> > + /*
> > +* Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
> > +* MT7622_POWER_DOMAIN_WB and thus just a trivial setup
> > +* is applied here.
> > +*/
> > + usleep_range(12000, 12100);
>
> Does the range really need to be so tight? Would 12000, 13000 also be ok?
>
I think Sean could give you a more accurate answer.
Hi Sean, would you mind answering this question?
> > + } else {
> > + /* Either wait until SRAM_PDN_ACK all 1 or 0 */
> > + int ret = readl_poll_timeout(ctl_addr, tmp,
> > + (tmp & pdn_ack) == 0,
> > + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> > + if (ret < 0)
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int scpsys_sram_disable(struct scp_domain *scpd, void __iomem
> > *ctl_addr)
> > +{
> > + u32 val;
> > + u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> > + int tmp;
> > +
> > + val = readl(ctl_addr) | scpd->data->sram_pdn_bits;
> > + writel(val, ctl_addr);
> > +
> > + /* Either wait until SRAM_PDN_ACK all 1 or 0 */
> > + return readl_poll_timeout(ctl_addr, tmp,
> > + (tmp & pdn_ack) == pdn_ack,
> > + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> > +}
> > +
> > static int scpsys_power_on(struct generic_pm_domain *genpd)
> > {
> > struct scp_domain *scpd = container_of(genpd, struct scp_domain,
> > genpd);
> > struct scp *scp = scpd->scp;
> > void __iomem *ctl_addr = scp->base + scpd->data->ctl_offs;
> > - u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> > u32 val;
> > int ret, tmp;
> >
> > @@ -252,6 +295,7 @@ static int scpsys_power_on(struct generic_pm_domain
> > *genpd)
> > if (ret)
> > goto err_clk;
> >
> > + /* subsys power on */
> > val = readl(ctl_addr);
> > val |= PWR_ON_BIT;
> > writel(val, ctl_addr);
> > @@ -273,24 +317,9 @@ static int scpsys_power_on(struct generic_pm_domain
> > *genpd)
> > val |= PWR_RST_B_BIT;
> > writel(val, ctl_addr);
> >
> > - val &= ~scpd->data->sram_pdn_bits;
> > - writel(val, ctl_addr);
> > -
> > - /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> > - if (MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) {
> > - /*
> > -* Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
> > -* MT7622_POWER_DOMAIN_WB and thus just a trivial setup is
> > -* applied here.
> > -*/
> > - usleep_range(12000, 12100);
> > -
> > - } else {
> > - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) ==
> > 0,
> > -MTK_POLL_DELAY_US,
> > MTK_POLL_TIMEOUT);
> > - if (ret < 0)
> > - goto err_pwr_ack;
> > - }
> > + ret = scpsys_sram_enable(scpd, ctl_addr);
> > + if (ret < 0)
> > + goto err_pwr_ack;
> >
> > if (scpd->data->bus_prot_mask) {
> > ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> > @@ -317,7 +346,6 @@ static int scpsys_power_off(struct generic_pm_domain
> > *genpd)
> > struct scp_domain *scpd = container_of(genpd, struct scp_domain,
> > genpd);
> > struct scp *scp = scpd->scp;
> > void __iomem *ctl_addr = scp->base + scpd->data->ctl_offs;
> > - u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> > u32 val;
> > int ret, tmp;
> >
> > @@ -329,17 +357,12 @@ static int scpsys_power_off(struct
