* [PATCH v2 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Sekhar Nori @ 2016-12-01 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZOxZRRUGkso_b0hLta4OWkeAgX2khcJxFc8EETFKiiXw@mail.gmail.com>
On Wednesday 30 November 2016 06:31 PM, Linus Walleij wrote:
> On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
>
>> This SoC has a separate pin controller for configuring pullup/pulldown
>> bias on groups of pins.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>>
>> v2 changes:
>> * Moved pin-controller at 22c00c device node after gpio at 226000 (there seem to be
>> more nodes in proper order here compared to the i2c at 228000 node suggested by
>> Sekhar)
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Take this through the ARM SoC tree.
Thanks Linus! Applied to v4.10/dt
Thanks,
Sekhar
^ permalink raw reply
* [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Robert Richter @ 2016-12-01 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eba92ea8-bdab-9a3a-7b18-caaeac15db5d@semihalf.com>
Tomasz, Bjorn,
On 01.12.16 09:49:51, Tomasz Nowicki wrote:
> I put the picture together here (on top of your pci/ecam branch):
> [1] https://github.com/semihalf-nowicki-tomasz/linux/commits/pci-quirks-thunderx-v2
please note that acpi_* functions must be protected with acpi_disabled
or something else to make sure an acpi enabled kernel does not break
dt. See the crash below with above branch.
-Robert
[ 12.493028] Unable to handle kernel NULL pointer dereference at virtual address 00000018
[ 12.501113] pgd = ffff0000090a0000
[ 12.504511] [00000018] *pgd=0000010fffef0003[ 12.508602] , *pud=0000010fffef0003
, *pmd=0000010fffee0003[ 12.514093] , *pte=0000000000000000
[ 12.517575]
[ 12.519064] Internal error: Oops: 96000005 [#1] SMP
[ 12.523933] Modules linked in:
[ 12.526987] CPU: 73 PID: 1 Comm: swapper/0 Tainted: G W 4.9.0-rc6.0.vanilla10-00019-g09abd2b6bbeb #135
[ 12.537409] Hardware name: Cavium ThunderX CRB/To be filled by O.E.M., BIOS 5.11 12/12/2012
[ 12.545748] task: ffff800fe85b8000 task.stack: ffff800ff4288000
[ 12.551674] PC is at acpi_ns_walk_namespace+0x68/0x1d4
[ 12.556803] LR is at acpi_get_devices+0x6c/0x94
...
[ 13.124920] [<ffff0000084dc5a0>] acpi_ns_walk_namespace+0x68/0x1d4
[ 13.131090] [<ffff0000084dcadc>] acpi_get_devices+0x6c/0x94
[ 13.136663] [<ffff0000084c0aec>] acpi_resource_consumer+0x34/0x44
[ 13.142752] [<ffff000008496bc0>] pci_ecam_create+0x80/0x228
[ 13.148314] [<ffff000008498e64>] pci_host_common_probe+0x294/0x348
[ 13.154486] [<ffff00000849bf3c>] thunder_ecam_probe+0x2c/0x38
[ 13.160226] [<ffff0000085880b8>] platform_drv_probe+0x60/0xc8
[ 13.165970] [<ffff000008585a04>] driver_probe_device+0x26c/0x420
[ 13.171966] [<ffff000008585cdc>] __driver_attach+0x124/0x128
[ 13.177615] [<ffff000008583238>] bus_for_each_dev+0x70/0xb0
[ 13.183177] [<ffff000008585060>] driver_attach+0x30/0x40
[ 13.188478] [<ffff000008584a98>] bus_add_driver+0x200/0x2b8
[ 13.194041] [<ffff000008586860>] driver_register+0x68/0x100
[ 13.199602] [<ffff000008587fdc>] __platform_driver_register+0x54/0x60
[ 13.206038] [<ffff000008c39b98>] thunder_ecam_driver_init+0x18/0x20
[ 13.212296] [<ffff000008082d94>] do_one_initcall+0x44/0x138
[ 13.217862] [<ffff000008c00d0c>] kernel_init_freeable+0x1ac/0x24c
[ 13.223950] [<ffff0000088605f0>] kernel_init+0x18/0x110
[ 13.229165] [<ffff000008082b30>] ret_from_fork+0x10/0x20
^ permalink raw reply
* [PATCH v15] acpi, apei, arm64: APEI initial support for aarch64.
From: fu.wei at linaro.org @ 2016-12-01 13:51 UTC (permalink / raw)
To: linux-arm-kernel
From: Tomasz Nowicki <tomasz.nowicki@linaro.org>
This patch provides APEI arch-specific bits for aarch64
Meanwhile,
(1)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
a generic place.
(2)select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64,
because arch_apei_get_mem_attribute is using efi_mem_attributes on ARM64.
[Fu Wei: improve && upstream]
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Tested-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
This patchset has been tested on the following platforms:
(1)ARM Foundation v8 model
Changelog:
v15:https://lkml.org/lkml/2016/12/1/
Improve the comment of acpi_disable_cmcff.
Rebase to 4.9.0-rc7-gd7c7bc3
v14:https://lkml.org/lkml/2016/8/10/231
Delete hest_ia32_init().
Fix a comment typo for acpi_disable_cmcff.
Rebase to 4.8.0-rc1-ge6c4d92
v13:https://lkml.org/lkml/2016/8/10/499
Fix a comment problem(add a "end").
Add a comment for the definition of acpi_disable_cmcff.
Rebase to 4.8.0-rc1-g372734a
v12:https://lkml.org/lkml/2016/7/29/97
Fix a comment problem(redundant "with").
Rebase to 4.7.0-g680eee2.
v11:https://lkml.org/lkml/2016/7/27/427
Rebase to v4.7-0e06f5c0.
v10:https://lkml.org/lkml/2016/4/14
Fix the Alphabetical order problem in arch/arm64/Kconfig.
v9: https://lkml.org/lkml/2016/4/5/522
Improve the comment for arch_apei_flush_tlb_one.
Using select "HAVE_ACPI_APEI if (ACPI && EFI)" to fix the EFI dependence
problem.
v8: https://lkml.org/lkml/2016/3/29/132
Fix a "undefined reference" bug by selecting EFI when ACPI_APEI is set
on ARM64.
v7: https://lkml.org/lkml/2016/3/17/183
Add comment for arch_apei_flush_tlb_one in arch/arm64/include/asm/acpi.h.
v6: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006644.html
Move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
a generic place.
Delete HAVE_ACPI_APEI_HEST_IA32.
v5: https://lkml.org/lkml/2015/12/10/131
Add "HAVE_ACPI_APEI_HEST_IA32" instead of
"#if defined(__i386__) || defined(__x86_64__)".
v4: https://lkml.org/lkml/2015/12/8/188
Rebase to latest kernel version(4.4-rc4).
Move arch_apei_flush_tlb_one into header file as a inline function
Add a new subfunction "hest_ia_init" for "acpi_disable_cmcff".
v3: https://lkml.org/lkml/2015/12/3/521
Remove "acpi_disable_cmcff" from arm64 code,
and wrap it in hest.c by "#if defined(__i386__) || defined(__x86_64__)"
v2: https://lkml.org/lkml/2015/12/2/432
Rebase to latest kernel version(4.4-rc3).
Move arch_apei_flush_tlb_one() to arch/arm64/kernel/acpi.c
v1: https://lkml.org/lkml/2015/8/14/199
Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h.
Delete arch/arm64/kernel/apei.c.
Add "#ifdef CONFIG_ACPI_APEI" for "acpi_disable_cmcff".
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/acpi.h | 23 ++++++++++++++++++++++-
arch/x86/kernel/acpi/apei.c | 3 ---
drivers/acpi/apei/hest.c | 13 ++++++++++---
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..657be7f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -52,6 +52,7 @@ config ARM64
select GENERIC_TIME_VSYSCALL
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
+ select HAVE_ACPI_APEI if (ACPI && EFI)
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_BITREVERSE
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index e517088..d0de0e0 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -17,6 +17,7 @@
#include <asm/cputype.h>
#include <asm/smp_plat.h>
+#include <asm/tlbflush.h>
/* Macros for consistency checks of the GICC subtable of MADT */
#define ACPI_MADT_GICC_LENGTH \
@@ -114,8 +115,28 @@ static inline const char *acpi_get_enable_method(int cpu)
}
#ifdef CONFIG_ACPI_APEI
+/*
+ * acpi_disable_cmcff is used in drivers/acpi/apei/hest.c for disabling
+ * IA-32 Architecture Corrected Machine Check (CMC) Firmware-First mode
+ * with a kernel command line parameter "acpi=nocmcoff". But we don't
+ * have this IA-32 specific feature on ARM64, this definition is only
+ * for compatibility.
+ */
+#define acpi_disable_cmcff 1
pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
-#endif
+
+/*
+ * Despite its name, this function must still broadcast the TLB
+ * invalidation in order to ensure other CPUs don't end up with junk
+ * entries as a result of speculation. Unusually, its also called in
+ * IRQ context (ghes_iounmap_irq) so if we ever need to use IPIs for
+ * TLB broadcasting, then we're in trouble here.
+ */
+static inline void arch_apei_flush_tlb_one(unsigned long addr)
+{
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+}
+#endif /* CONFIG_ACPI_APEI */
#ifdef CONFIG_ACPI_NUMA
int arm64_acpi_numa_init(void);
diff --git a/arch/x86/kernel/acpi/apei.c b/arch/x86/kernel/acpi/apei.c
index c280df6..ea3046e 100644
--- a/arch/x86/kernel/acpi/apei.c
+++ b/arch/x86/kernel/acpi/apei.c
@@ -24,9 +24,6 @@ int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr, void *data)
struct acpi_hest_ia_corrected *cmc;
struct acpi_hest_ia_error_bank *mc_bank;
- if (hest_hdr->type != ACPI_HEST_TYPE_IA32_CORRECTED_CHECK)
- return 0;
-
cmc = (struct acpi_hest_ia_corrected *)hest_hdr;
if (!cmc->enabled)
return 0;
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index 20b3fcf..8f2a98e 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -123,7 +123,13 @@ EXPORT_SYMBOL_GPL(apei_hest_parse);
*/
static int __init hest_parse_cmc(struct acpi_hest_header *hest_hdr, void *data)
{
- return arch_apei_enable_cmcff(hest_hdr, data);
+ if (hest_hdr->type != ACPI_HEST_TYPE_IA32_CORRECTED_CHECK)
+ return 0;
+
+ if (!acpi_disable_cmcff)
+ return !arch_apei_enable_cmcff(hest_hdr, data);
+
+ return 0;
}
struct ghes_arr {
@@ -232,8 +238,9 @@ void __init acpi_hest_init(void)
goto err;
}
- if (!acpi_disable_cmcff)
- apei_hest_parse(hest_parse_cmc, NULL);
+ rc = apei_hest_parse(hest_parse_cmc, NULL);
+ if (rc)
+ goto err;
if (!ghes_disable) {
rc = apei_hest_parse(hest_parse_ghes_count, &ghes_count);
--
2.9.3
^ permalink raw reply related
* [PATCH 1/5] gpio: pl061: use local state for parent IRQ storage
From: Sudeep Holla @ 2016-12-01 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480068564-9447-1-git-send-email-linus.walleij@linaro.org>
On 25/11/16 10:09, Linus Walleij wrote:
> The driver is poking around in the struct gpio_chip internals,
> which is a no-no. Use a variable in the local state container.
>
The entire series looks good to me. I also gave it a spin on my Juno. So,
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] nommu: allow mmap when !CONFIG_MMU
From: Benjamin Gaignard @ 2016-12-01 13:48 UTC (permalink / raw)
To: linux-arm-kernel
commit ab6494f0c96f ("nommu: Add noMMU support to the DMA API") have
add CONFIG_MMU compilation flag but that prohibit to use dma_mmap_wc()
when the platform doesn't have MMU.
This patch call vm_iomap_memory() in noMMU case to test if addresses
are correct and set wma->vm_flags rather than all return an error.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: arnd at arndb.de
---
arch/arm/mm/dma-mapping.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab4f745..230875e 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -868,6 +868,9 @@ static int __arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
vma->vm_end - vma->vm_start,
vma->vm_page_prot);
}
+#else
+ ret = vm_iomap_memory(vma, vma->vm_start,
+ (vma->vm_end - vma->vm_start));
#endif /* CONFIG_MMU */
return ret;
--
1.9.1
^ permalink raw reply related
* [PATCH] crypto: arm/aesbs - Select SIMD in Kconfig
From: Arnd Bergmann @ 2016-12-01 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201125616.GB2249@gondor.apana.org.au>
On Thursday, December 1, 2016 8:56:16 PM CET Herbert Xu wrote:
> On Thu, Dec 01, 2016 at 12:47:59AM +0100, Arnd Bergmann wrote:
> > Commit 585b5fa63da9 ("crypto: arm/aes - Select SIMD in Kconfig") added
> > the dependency for CRYPTO_AES_ARM_CE, but missed the same change
> > for CRYPTO_AES_ARM_BS:
> >
> > arch/arm/crypto/aes-arm-bs.o: In function `aesbs_mod_init':
> > aesbs-glue.c:(.init.text+0x38): undefined reference to `simd_skcipher_create_compat'
> >
> > Fixes: 211f41af534a ("crypto: aesbs - Convert to skcipher")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks Arnd. This should already be fixed by 6fdf436fd854.
Right. I have discarded my patch on today's linux-next and I
get no more link errors.
Arnd
^ permalink raw reply
* [PATCH v2] KVM: arm/arm64: Access CNTHCTL_EL2 bit fields correctly
From: Marc Zyngier @ 2016-12-01 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480592310-26079-1-git-send-email-jintack@cs.columbia.edu>
Hi Jintack,
On 01/12/16 11:38, Jintack Lim wrote:
> Current KVM world switch code is unintentionally setting wrong bits to
> CNTHCTL_EL2 when E2H == 1, which may allow guest OS to access physical
> timer. Bit positions of CNTHCTL_EL2 are changing depending on
> HCR_EL2.E2H bit. EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
> not set, but they are 11th and 10th bits respectively when E2H is set.
>
> In fact, on VHE we only need to set those bits once, not for every world
> switch. This is because the host kernel runs in EL2 with HCR_EL2.TGE ==
> 1, which makes those bits have no effect for the host kernel execution.
> So we just set those bits once for guests, and that's it.
>
> Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
> ---
> v2: Skip configuring cnthctl_el2 in world switch path on VHE system.
> This patch is based on linux-next.
>
> ---
> arch/arm/kvm/arm.c | 1 +
> include/kvm/arm_arch_timer.h | 1 +
> virt/kvm/arm/arch_timer.c | 23 ++++++++++++++++++++++
> virt/kvm/arm/hyp/timer-sr.c | 45 ++++++++++++++++++++++++++++++++------------
> 4 files changed, 58 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 8f92efa..38c0645 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -1286,6 +1286,7 @@ static void teardown_hyp_mode(void)
>
> static int init_vhe_mode(void)
> {
> + on_each_cpu(kvm_timer_init_vhe, NULL, 1);
I'm pretty sure this is not going to work with CPU hotplug, as you only
perform this once and for all at boot time.
I think it would be better if you called this init function as part of
cpu_init_hyp_mode().
> kvm_info("VHE mode initialized successfully\n");
> return 0;
> }
> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> index dda39d8..5853399 100644
> --- a/include/kvm/arm_arch_timer.h
> +++ b/include/kvm/arm_arch_timer.h
> @@ -76,4 +76,5 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>
> void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
>
> +void kvm_timer_init_vhe(void *dummy);
> #endif
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 17b8fa5..7a0d85d7 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -24,6 +24,7 @@
>
> #include <clocksource/arm_arch_timer.h>
> #include <asm/arch_timer.h>
> +#include <asm/kvm_hyp.h>
>
> #include <kvm/arm_vgic.h>
> #include <kvm/arm_arch_timer.h>
> @@ -507,3 +508,25 @@ void kvm_timer_init(struct kvm *kvm)
> {
> kvm->arch.timer.cntvoff = kvm_phys_timer_read();
> }
> +
> +/*
> + * On VHE system, we only need to configure trap on physical timer and counter
> + * accesses in EL0 and EL1 once, not for every world switch.
> + * The host kernel runs at EL2 with HCR_EL2.TGE == 1,
> + * and this makes those bits have no effect for the host kernel execution.
> + */
> +void kvm_timer_init_vhe(void *dummy)
> +{
> + /* When HCR_EL2.E2H ==1, EL1PCEN and EL1PCTEN are shifted by 10 */
> + u32 cnthctl_shift = 10;
> + u64 val;
> +
> + /*
> + * Disallow physical timer access for the guest.
> + * Physical counter access is allowed.
> + */
> + val = read_sysreg(cnthctl_el2);
> + val &= ~(CNTHCTL_EL1PCEN << cnthctl_shift);
> + val |= (CNTHCTL_EL1PCTEN << cnthctl_shift);
> + write_sysreg(val, cnthctl_el2);
> +}
If you make this called from cpu_init_hyp_mode(), it will have to be
guarded with is_kernel_in_hyp_mode().
> diff --git a/virt/kvm/arm/hyp/timer-sr.c b/virt/kvm/arm/hyp/timer-sr.c
> index 798866a..f7fc957 100644
> --- a/virt/kvm/arm/hyp/timer-sr.c
> +++ b/virt/kvm/arm/hyp/timer-sr.c
> @@ -21,6 +21,18 @@
>
> #include <asm/kvm_hyp.h>
>
> +#ifdef CONFIG_ARM64
> +static inline bool has_vhe(void)
> +{
> + if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
> + return true;
> +
> + return false;
> +}
> +#else
> +#define has_vhe() false
Could this now be moved to asm/virt.h, and maybe replace the current
implementation of is_kernel_in_hyp_mode? The latter may require some
more hacking around, so I'm not sure this is worth it.
> +#endif
> +
> /* vcpu is already in the HYP VA space */
> void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
> {
> @@ -35,10 +47,16 @@ void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
> /* Disable the virtual timer */
> write_sysreg_el0(0, cntv_ctl);
>
> - /* Allow physical timer/counter access for the host */
> - val = read_sysreg(cnthctl_el2);
> - val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
> - write_sysreg(val, cnthctl_el2);
> + /*
> + * We don't need to do this for VHE since the host kernel runs in EL2
> + * with HCR_EL2.TGE ==1, which makes those bits have no impact.
> + */
> + if (!has_vhe()) {
> + /* Allow physical timer/counter access for the host */
> + val = read_sysreg(cnthctl_el2);
> + val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
> + write_sysreg(val, cnthctl_el2);
> + }
>
> /* Clear cntvoff for the host */
> write_sysreg(0, cntvoff_el2);
> @@ -50,14 +68,17 @@ void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> u64 val;
>
> - /*
> - * Disallow physical timer access for the guest
> - * Physical counter access is allowed
> - */
> - val = read_sysreg(cnthctl_el2);
> - val &= ~CNTHCTL_EL1PCEN;
> - val |= CNTHCTL_EL1PCTEN;
> - write_sysreg(val, cnthctl_el2);
> + /* Those bits are already configured at boot on VHE-system */
> + if (!has_vhe()) {
> + /*
> + * Disallow physical timer access for the guest
> + * Physical counter access is allowed
> + */
> + val = read_sysreg(cnthctl_el2);
> + val &= ~CNTHCTL_EL1PCEN;
> + val |= CNTHCTL_EL1PCTEN;
> + write_sysreg(val, cnthctl_el2);
> + }
>
> if (timer->enabled) {
> write_sysreg(kvm->arch.timer.cntvoff, cntvoff_el2);
>
Otherwise, this looks good, and the generated code is quite nice.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
From: Marc Zyngier @ 2016-12-01 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA81747812F@lhreml504-mbs>
On 01/12/16 12:15, Shameerali Kolothum Thodi wrote:
>> For these interrupts, which are purely virtual, there is absolutely
>> nothing to do at the physical distributor level anyway. Furthermore,
>> kvm_notify_acked_irq doesn't know about per-cpu interrupt, which is why
>> we cannot notify them.
>
> Just to confirm, that means for any phys interrupt(PPI/SPI) to be injected
> to the Guest, the mapping bit has(HW bit set) to be used.
Yup.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] dmaengine: at_xdmac: don't restore unsaved status
From: Ludovic Desroches @ 2016-12-01 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104903.30019-1-alexandre.belloni@free-electrons.com>
On Thu, Dec 01, 2016 at 11:49:03AM +0100, Alexandre Belloni wrote:
> save_gs is supposed to save the channel status in order to be restored at
> resume time but it is never updated and is always 0. Anyway, the channel
> status is updated in the per channel loop later in the resume function.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Thanks
> ---
> drivers/dma/at_xdmac.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index b7d7f2d443a1..8c1abb794340 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -221,7 +221,6 @@ struct at_xdmac {
> int irq;
> struct clk *clk;
> u32 save_gim;
> - u32 save_gs;
> struct dma_pool *at_xdmac_desc_pool;
> struct at_xdmac_chan chan[0];
> };
> @@ -1896,7 +1895,6 @@ static int atmel_xdmac_resume(struct device *dev)
> }
>
> at_xdmac_write(atxdmac, AT_XDMAC_GIE, atxdmac->save_gim);
> - at_xdmac_write(atxdmac, AT_XDMAC_GE, atxdmac->save_gs);
> list_for_each_entry_safe(chan, _chan, &atxdmac->dma.channels, device_node) {
> atchan = to_at_xdmac_chan(chan);
> at_xdmac_chan_write(atchan, AT_XDMAC_CC, atchan->save_cc);
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH] crypto: arm/aesbs - Select SIMD in Kconfig
From: Herbert Xu @ 2016-12-01 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130234826.854879-1-arnd@arndb.de>
On Thu, Dec 01, 2016 at 12:47:59AM +0100, Arnd Bergmann wrote:
> Commit 585b5fa63da9 ("crypto: arm/aes - Select SIMD in Kconfig") added
> the dependency for CRYPTO_AES_ARM_CE, but missed the same change
> for CRYPTO_AES_ARM_BS:
>
> arch/arm/crypto/aes-arm-bs.o: In function `aesbs_mod_init':
> aesbs-glue.c:(.init.text+0x38): undefined reference to `simd_skcipher_create_compat'
>
> Fixes: 211f41af534a ("crypto: aesbs - Convert to skcipher")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks Arnd. This should already be fixed by 6fdf436fd854.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH net-next v2] net: thunderx: Fix transmit queue timeout issue
From: sunil.kovvuri at gmail.com @ 2016-12-01 12:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Sunil Goutham <sgoutham@cavium.com>
Transmit queue timeout issue is seen in two cases
- Due to a race condition btw setting stop_queue at xmit()
and checking for stopped_queue in NAPI poll routine, at times
transmission from a SQ comes to a halt. This is fixed
by using barriers and also added a check for SQ free descriptors,
incase SQ is stopped and there are only CQE_RX i.e no CQE_TX.
- Contrary to an assumption, a HW errata where HW doesn't stop transmission
even though there are not enough CQEs available for a CQE_TX is
not fixed in T88 pass 2.x. This results in a Qset error with
'CQ_WR_FULL' stalling transmission. This is fixed by adjusting
RXQ's RED levels for CQ level such that there is always enough
space left for CQE_TXs.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
v2: As suggested by David, replaced netif_tx_start_queue with
netif_tx_wake_queue.
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 52 ++++++++++++++++++----
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 24 ++--------
drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 15 ++++---
3 files changed, 54 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 1eacec8..2006f58 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -644,6 +644,7 @@ static int nicvf_cq_intr_handler(struct net_device *netdev, u8 cq_idx,
struct cmp_queue *cq = &qs->cq[cq_idx];
struct cqe_rx_t *cq_desc;
struct netdev_queue *txq;
+ struct snd_queue *sq;
unsigned int tx_pkts = 0, tx_bytes = 0;
spin_lock_bh(&cq->lock);
@@ -709,16 +710,20 @@ static int nicvf_cq_intr_handler(struct net_device *netdev, u8 cq_idx,
done:
/* Wakeup TXQ if its stopped earlier due to SQ full */
- if (tx_done) {
+ sq = &nic->qs->sq[cq_idx];
+ if (tx_done ||
+ (atomic_read(&sq->free_cnt) >= MIN_SQ_DESC_PER_PKT_XMIT)) {
netdev = nic->pnicvf->netdev;
txq = netdev_get_tx_queue(netdev,
nicvf_netdev_qidx(nic, cq_idx));
if (tx_pkts)
netdev_tx_completed_queue(txq, tx_pkts, tx_bytes);
- nic = nic->pnicvf;
+ /* To read updated queue and carrier status */
+ smp_mb();
if (netif_tx_queue_stopped(txq) && netif_carrier_ok(netdev)) {
- netif_tx_start_queue(txq);
+ netif_tx_wake_queue(txq);
+ nic = nic->pnicvf;
this_cpu_inc(nic->drv_stats->txq_wake);
if (netif_msg_tx_err(nic))
netdev_warn(netdev,
@@ -1054,6 +1059,9 @@ static netdev_tx_t nicvf_xmit(struct sk_buff *skb, struct net_device *netdev)
struct nicvf *nic = netdev_priv(netdev);
int qid = skb_get_queue_mapping(skb);
struct netdev_queue *txq = netdev_get_tx_queue(netdev, qid);
+ struct nicvf *snic;
+ struct snd_queue *sq;
+ int tmp;
/* Check for minimum packet length */
if (skb->len <= ETH_HLEN) {
@@ -1061,13 +1069,39 @@ static netdev_tx_t nicvf_xmit(struct sk_buff *skb, struct net_device *netdev)
return NETDEV_TX_OK;
}
- if (!netif_tx_queue_stopped(txq) && !nicvf_sq_append_skb(nic, skb)) {
+ snic = nic;
+ /* Get secondary Qset's SQ structure */
+ if (qid >= MAX_SND_QUEUES_PER_QS) {
+ tmp = qid / MAX_SND_QUEUES_PER_QS;
+ snic = (struct nicvf *)nic->snicvf[tmp - 1];
+ if (!snic) {
+ netdev_warn(nic->netdev,
+ "Secondary Qset#%d's ptr not initialized\n",
+ tmp - 1);
+ dev_kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
+ qid = qid % MAX_SND_QUEUES_PER_QS;
+ }
+
+ sq = &snic->qs->sq[qid];
+ if (!netif_tx_queue_stopped(txq) &&
+ !nicvf_sq_append_skb(snic, sq, skb, qid)) {
netif_tx_stop_queue(txq);
- this_cpu_inc(nic->drv_stats->txq_stop);
- if (netif_msg_tx_err(nic))
- netdev_warn(netdev,
- "%s: Transmit ring full, stopping SQ%d\n",
- netdev->name, qid);
+
+ /* Barrier, so that stop_queue visible to other cpus */
+ smp_mb();
+
+ /* Check again, incase another cpu freed descriptors */
+ if (atomic_read(&sq->free_cnt) > MIN_SQ_DESC_PER_PKT_XMIT) {
+ netif_tx_wake_queue(txq);
+ } else {
+ this_cpu_inc(nic->drv_stats->txq_stop);
+ if (netif_msg_tx_err(nic))
+ netdev_warn(netdev,
+ "%s: Transmit ring full, stopping SQ%d\n",
+ netdev->name, qid);
+ }
return NETDEV_TX_BUSY;
}
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index 7b336cd..d2ac133 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -1190,30 +1190,12 @@ static int nicvf_sq_append_tso(struct nicvf *nic, struct snd_queue *sq,
}
/* Append an skb to a SQ for packet transfer. */
-int nicvf_sq_append_skb(struct nicvf *nic, struct sk_buff *skb)
+int nicvf_sq_append_skb(struct nicvf *nic, struct snd_queue *sq,
+ struct sk_buff *skb, u8 sq_num)
{
int i, size;
int subdesc_cnt, tso_sqe = 0;
- int sq_num, qentry;
- struct queue_set *qs;
- struct snd_queue *sq;
-
- sq_num = skb_get_queue_mapping(skb);
- if (sq_num >= MAX_SND_QUEUES_PER_QS) {
- /* Get secondary Qset's SQ structure */
- i = sq_num / MAX_SND_QUEUES_PER_QS;
- if (!nic->snicvf[i - 1]) {
- netdev_warn(nic->netdev,
- "Secondary Qset#%d's ptr not initialized\n",
- i - 1);
- return 1;
- }
- nic = (struct nicvf *)nic->snicvf[i - 1];
- sq_num = sq_num % MAX_SND_QUEUES_PER_QS;
- }
-
- qs = nic->qs;
- sq = &qs->sq[sq_num];
+ int qentry;
subdesc_cnt = nicvf_sq_subdesc_required(nic, skb);
if (subdesc_cnt > atomic_read(&sq->free_cnt))
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
index 20511f2..9e21046 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
@@ -88,13 +88,13 @@
/* RED and Backpressure levels of CQ for pkt reception
* For CQ, level is a measure of emptiness i.e 0x0 means full
- * eg: For CQ of size 4K, and for pass/drop levels of 128/96
- * HW accepts pkt if unused CQE >= 2048
- * RED accepts pkt if unused CQE < 2048 & >= 1536
- * DROPs pkts if unused CQE < 1536
+ * eg: For CQ of size 4K, and for pass/drop levels of 160/144
+ * HW accepts pkt if unused CQE >= 2560
+ * RED accepts pkt if unused CQE < 2304 & >= 2560
+ * DROPs pkts if unused CQE < 2304
*/
-#define RQ_PASS_CQ_LVL 128ULL
-#define RQ_DROP_CQ_LVL 96ULL
+#define RQ_PASS_CQ_LVL 160ULL
+#define RQ_DROP_CQ_LVL 144ULL
/* RED and Backpressure levels of RBDR for pkt reception
* For RBDR, level is a measure of fullness i.e 0x0 means empty
@@ -306,7 +306,8 @@ void nicvf_sq_disable(struct nicvf *nic, int qidx);
void nicvf_put_sq_desc(struct snd_queue *sq, int desc_cnt);
void nicvf_sq_free_used_descs(struct net_device *netdev,
struct snd_queue *sq, int qidx);
-int nicvf_sq_append_skb(struct nicvf *nic, struct sk_buff *skb);
+int nicvf_sq_append_skb(struct nicvf *nic, struct snd_queue *sq,
+ struct sk_buff *skb, u8 sq_num);
struct sk_buff *nicvf_get_rcv_skb(struct nicvf *nic, struct cqe_rx_t *cqe_rx);
void nicvf_rbdr_task(unsigned long data);
--
2.7.4
^ permalink raw reply related
* [PATCH v2] mach-omap2: fixing wrong strcat for Non-NULL terminated string
From: Russell King - ARM Linux @ 2016-12-01 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480589913-8839-1-git-send-email-maninder1.s@samsung.com>
On Thu, Dec 01, 2016 at 04:28:33PM +0530, Maninder Singh wrote:
> variable name can have Non NULL terminated string after cropping
> which may result strcat to fail, and cropping is not
> required if (strlen(oh->name) + 8 < MOD_CLK_MAX_NAME_LEN).
>
> Issue caught with static analysis tool:
> "Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> ---
> v1 -> v2: changed strncpy to strlcpy
> arch/arm/mach-omap2/omap_hwmod.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 759e1d4..582b95a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -742,12 +742,14 @@ static int _init_main_clk(struct omap_hwmod *oh)
> char name[MOD_CLK_MAX_NAME_LEN];
> struct clk *clk;
>
> - /* +7 magic comes from '_mod_ck' suffix */
> - if (strlen(oh->name) + 7 > MOD_CLK_MAX_NAME_LEN)
> + /* +8 magic comes from strlen("_mod_ck") added as suffix */
> + if (strlen(oh->name) + 8 > MOD_CLK_MAX_NAME_LEN) {
> pr_warn("%s: warning: cropping name for %s\n", __func__,
> oh->name);
> + strlcpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
> + } else
> + strcpy(name, oh->name);
>
> - strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
> strcat(name, "_mod_ck");
>
> clk = clk_get(NULL, name);
> --
> 1.9.1
>
Simpler, clearer, and less error-prone:
static const char modck[] = "_mod_ck";
if (strlen(oh->name) >= MOD_CLK_MAX_NAME_LEN - strlen(modck))
pr_warn("%s: warning: cropping name for %s\n", __func__,
oh->name);
strlcpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - strlen(modck));
strlcat(name, modck, MOD_CLK_MAX_NAME_LEN);
Note that the length argument to strlcpy _includes_ the NUL terminator.
Also note the use of strlcat() which ensures that it won't overflow the
buffer.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Marcin Wojtas @ 2016-12-01 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201201648.6a50b442@xhacker>
Hi Jisheng,
2016-12-01 13:16 GMT+01:00 Jisheng Zhang <jszhang@marvell.com>:
> On Thu, 1 Dec 2016 20:02:05 +0800 Jisheng Zhang wrote:
>
>> Hi Marcin,
>>
>> On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
>>
>> > Hi Jisheng,
>> >
>> > Which baseline do you use?
>> >
>> > It took me really lot of time to catch why RX broke after rebase from
>> > LKv4.1 to LKv4.4. Between those two, in commit:
>> > 97303480753e ("arm64: Increase the max granular size")
>> > L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
>> > did NET_SKB_PAD.
>> >
>> > And 128 is more than the maximum that can fit into packet offset
>> > [11:8]@0x1400. In such case this correction is needed. Did it answer
>> > your doubts?
>>
>> That's key! Thanks a lot. In my repo, we don't have commit 97303480753e
>> ("arm64: Increase the max granular size")
>>
>> I think it would be great if this information can be added into the commit
>> msg.
>>
>> IIRC, arm64 maintainers considered to let L1_CACHE_BYTES the _minimum_ of
>> cache line sizes of arm64. If that's implemented and merged, then we can
>
> I just searched and found the email.
>
> "We may have to revisit this logic and consider L1_CACHE_BYTES the
> _minimum_ of cache line sizes in arm64 systems supported by the kernel.
> Do you have any benchmarks on Cavium boards that would show significant
> degradation with 64-byte L1_CACHE_BYTES vs 128?"
>
> https://patchwork.kernel.org/patch/8634481/
>
>
Thank you for the information. I debugged it before the discussion. In
future we would be able to revert it, however afair packet offset may
be needed by A3700 Buffer Management.
Best regards,
Marcin
^ permalink raw reply
* arasan,sdhci.txt "compatibility" DT binding
From: Mason @ 2016-12-01 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f64ea0f8-31be-c5b5-3a43-a30abd8aec30@rock-chips.com>
On 01/12/2016 05:09, Shawn Lin wrote:
> On 2016/11/28 23:44, Mason wrote:
>
>> Shawn Lin, could you take a look below and tell me exactly
>> which IP core(s) Rockchip is using in its SoCs?
>
> From the Host Controller version register (0xfe)
> bit[7:0]: 0x2 : specification version number is 3.00
> bit[15:8]: 0x10: Vendor version number is 1.0
>
> Command Queueing version register (0x200)
> bit[11:8]: 0x5 eMMC Major version number
> bit[7:4]: 0x1 eMMC manor version number
> bit[3:0]: 0x0 eMMC version suffix
>
> User guide "eMMC 5.1/SD3.0/SDIO3.0 Host Controller"
> Revision number: 1.14
> Released on Dec. 2014
Wow! Yet another HW revision I wasn't aware of :-)
For the record, I think the 0x200 register was introduced fairly
recently, as it's not documented in any of the user guides I have
access to.
To summarize the situation, Arasan has made (at least) the
following versions of the HW block:
SD_2.0_SDIO_2.0__MMC_3.31_Host_Controller
SD_3.0_SDIO_3.0_eMMC_4.4__Host_Controller
SD_3.0_SDIO_3.0_eMMC_4.41_Host_Controller
SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller
SD_3.0_SDIO_3.0_eMMC_4.51_Host_Controller
SD_3.0_SDIO_3.0_eMMC_5.1__Host Controller
SD_4.1_SDIO_4.1_eMMC_4.51_Host_Controller
SD_4.1_SDIO_4.1_eMMC_5.1__Host_Controller
Xilinx = "arasan,sdhci-8.9a" compat string
SD2.0 / SDIO2.0 / MMC3.31 (in Zynq)
SD3.0 / SDIO3.0 / eMMC4.51 (in ZynqMP)
Vendor version 0x89 (Zynq, from 8.9a) and 0x10 (ZynqMP)
Sigma = no compat string yet
SD3.0 / SDIO3.0 / eMMC4.4 (in SMP87xx)
Vendor version 0x99 (not related to document revision)
APM = "arasan,sdhci-4.9a"
SD3.0 / SDIO3.0 / eMMC4.41
Vendor version unknown
Rockchip = "arasan,sdhci-5.1"
SD3.0 / SDIO3.0 / eMMC 5.1
Vendor version 0x10
Conclusion, it doesn't look like the "Vendor version" field
contains dependable information, considering the duplicate
0x10 in different HW revisions.
Regards.
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Dave Martin @ 2016-12-01 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201103048.GO1574@e103592.cambridge.arm.com>
On Thu, Dec 01, 2016 at 10:30:51AM +0000, Dave Martin wrote:
[...]
> Basically, all the *new* state is caller-save.
>
> The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view
> Zn[bits 127:0] is callee-save for all n = 8..15.
Ramana is right -- the current procedure call standard (ARM IHI 0055B)
only requires the bottom _64_ bits of V8-V15 to be preserved (not all
128 bits as I stated).
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-12-01 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201200205.46dec339@xhacker>
On Thu, 1 Dec 2016 20:02:05 +0800 Jisheng Zhang wrote:
> Hi Marcin,
>
> On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
>
> > Hi Jisheng,
> >
> > Which baseline do you use?
> >
> > It took me really lot of time to catch why RX broke after rebase from
> > LKv4.1 to LKv4.4. Between those two, in commit:
> > 97303480753e ("arm64: Increase the max granular size")
> > L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
> > did NET_SKB_PAD.
> >
> > And 128 is more than the maximum that can fit into packet offset
> > [11:8]@0x1400. In such case this correction is needed. Did it answer
> > your doubts?
>
> That's key! Thanks a lot. In my repo, we don't have commit 97303480753e
> ("arm64: Increase the max granular size")
>
> I think it would be great if this information can be added into the commit
> msg.
>
> IIRC, arm64 maintainers considered to let L1_CACHE_BYTES the _minimum_ of
> cache line sizes of arm64. If that's implemented and merged, then we can
I just searched and found the email.
"We may have to revisit this logic and consider L1_CACHE_BYTES the
_minimum_ of cache line sizes in arm64 systems supported by the kernel.
Do you have any benchmarks on Cavium boards that would show significant
degradation with 64-byte L1_CACHE_BYTES vs 128?"
https://patchwork.kernel.org/patch/8634481/
> revert this patch later.
>
> Thanks,
> Jisheng
>
> >
> > Best regards,
> > Marcin
> >
> >
> >
> > 2016-12-01 12:26 GMT+01:00 Jisheng Zhang <jszhang@marvell.com>:
> > > Hi Gregory, Marcin,
> > >
> > > On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
> > >
> > >> From: Marcin Wojtas <mw@semihalf.com>
> > >>
> > >> Prepare the mvneta driver in order to be usable on the 64 bits platform
> > >> such as the Armada 3700.
> > >>
> > >> [gregory.clement at free-electrons.com]: this patch was extract from a larger
> > >> one to ease review and maintenance.
> > >>
> > >> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> > >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > >> ---
> > >> drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
> > >> 1 file changed, 16 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> > >> index 92b9af14c352..8ef03fb69bcd 100644
> > >> --- a/drivers/net/ethernet/marvell/mvneta.c
> > >> +++ b/drivers/net/ethernet/marvell/mvneta.c
> > >> @@ -296,6 +296,12 @@
> > >> /* descriptor aligned size */
> > >> #define MVNETA_DESC_ALIGNED_SIZE 32
> > >>
> > >> +/* Number of bytes to be taken into account by HW when putting incoming data
> > >> + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
> > >> + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
> > >
> > > We also brought up this driver on 64bit platforms, we doesn't have this
> > > patch. Maybe I'm wrong, I'm trying to understand why we need this
> > > modification. Let's assume the NET_SKB_PAD is 64B, we call
> > > mvneta_rxq_offset_set(pp, rxq, 64),
> > >
> > > {
> > > u32 val;
> > >
> > > val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
> > > val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
> > >
> > > /* Offset is in */
> > > val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
> > > // then this will be "val |= 8;" it doesn't exceeds the max offset of
> > > MVNETA_RXQ_CONFIG_REG(q) register.
> > >
> > > Could you please kindly point out where I am wrong?
> > >
> > >> + */
> > >> +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
> > >> +
> > >> #define MVNETA_RX_PKT_SIZE(mtu) \
> > >> ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
> > >> ETH_HLEN + ETH_FCS_LEN, \
> > >> @@ -416,6 +422,7 @@ struct mvneta_port {
> > >> u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
> > >>
> > >> u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
> > >> + u16 rx_offset_correction;
> > >> };
> > >>
> > >> /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> > >> @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
> > >> return -ENOMEM;
> > >> }
> > >>
> > >> + phys_addr += pp->rx_offset_correction;
> > >> mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
> > >> return 0;
> > >> }
> > >> @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
> > >> mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
> > >>
> > >> /* Set Offset */
> > >> - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
> > >> + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
> > >>
> > >> /* Set coalescing pkts and time */
> > >> mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
> > >> @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
> > >>
> > >> pp->rxq_def = rxq_def;
> > >>
> > >> + /* Set RX packet offset correction for platforms, whose
> > >> + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
> > >> + * platforms and 0B for 32-bit ones.
> > >
> > > Even we need this patch, I'm not sure this last comment is correct or not.
> > > NET_SKB_PAD is defined as:
> > >
> > > #define NET_SKB_PAD max(32, L1_CACHE_BYTES)
> > >
> > > we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
> > > should be 64B as well.
> > >
> > > Thanks,
> > > Jisheng
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
From: Shameerali Kolothum Thodi @ 2016-12-01 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be0586f4-57b7-b732-f97e-34798f57e066@arm.com>
> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> Sent: Thursday, December 01, 2016 10:58 AM
> To: Shameerali Kolothum Thodi; Paolo Bonzini; Radim Kr?m??
> Cc: Catalin Marinas; kvmarm at lists.cs.columbia.edu; linux-arm-
> kernel at lists.infradead.org; kvm at vger.kernel.org
> Subject: Re: [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-
> SPIs
>
> On 01/12/16 10:28, Shameerali Kolothum Thodi wrote:
> > Hi Marc,
> >
> >> -----Original Message-----
> >> From: kvmarm-bounces at lists.cs.columbia.edu [mailto:kvmarm-
> >> bounces at lists.cs.columbia.edu] On Behalf Of Marc Zyngier
> >> Sent: Thursday, December 01, 2016 9:26 AM
> >> To: Paolo Bonzini; Radim Kr?m??
> >> Cc: Catalin Marinas; kvmarm at lists.cs.columbia.edu; linux-arm-
> >> kernel at lists.infradead.org; kvm at vger.kernel.org
> >> Subject: [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
> >>
> >> When we inject a level triggerered interrupt (and unless it is
> backed
> >> by the physical distributor - timer style), we request a maintenance
> >> interrupt. Part of the processing for that interrupt is to feed to
> the
> >> rest of KVM (and to the eventfd subsystem) the information that the
> >> interrupt has been EOIed.
> >>
> >> But that notification only makes sense for SPIs, and not PPIs (such
> as
> >> the PMU interrupt). Skip over the notification if the interrupt is
> not
> >> an SPI.
> >
> > Just to clarify my understanding, the maintenance interrupt is
> generated
> > for cases where there is no mapping of virt to phys interrupts
> > (ie, ICH_LR HW bit is not set). And I was under the impression that
> > kvm_notify_acked_irq will eventually deactivate the interrupt on
> distributor
> > for such cases. Its not clear to me how the deactivation is done
> > otherwise.
> >
> > Could you please help me to understand this better.
>
> kvm_notify_acked_irq() doesn't do *anything* at the distributor level,
> ever (it has no idea of anything GIC-specific anyway). It's sole job is
> to signal the rest of the stack that an interrupt has been EOIed in the
> guest.
Thanks Marc. Understood. I got confused by the kvm_set_irq in the
kvm_notify_acked_irq path.
> For these interrupts, which are purely virtual, there is absolutely
> nothing to do at the physical distributor level anyway. Furthermore,
> kvm_notify_acked_irq doesn't know about per-cpu interrupt, which is why
> we cannot notify them.
Just to confirm, that means for any phys interrupt(PPI/SPI) to be injected
to the Guest, the mapping bit has(HW bit set) to be used.
Thanks,
Shameer
^ permalink raw reply
* arm64: dts: zx: support cpu-freq for zx296718
From: Baoyou Xie @ 2016-12-01 12:08 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.
So it can be used by cpufreq-dt driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 37 +++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 7a1aed7..16f7d5e 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/clock/zx296718-clock.h>
/ {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <&topcrm A53_GATE>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu at 1 {
@@ -88,6 +91,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu at 2 {
@@ -95,6 +99,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu3: cpu at 3 {
@@ -102,6 +107,38 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 648000000 {
+ opp-hz = /bits/ 64 <648000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <882000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <892000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1188000000 {
+ opp-hz = /bits/ 64 <1188000000>;
+ opp-microvolt = <1009000>;
+ clock-latency-ns = <500000>;
};
};
--
2.7.4
^ permalink raw reply related
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Arnd Bergmann @ 2016-12-01 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480553321-17400-2-git-send-email-zhangfei.gao@linaro.org>
On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> + 0x20 0x10 /* 1: i2c1 */
> + 0x20 0x20 /* 2: i2c2 */
> + 0x20 0x8000000>; /* 3: i2c6 */
> + };
> +
> +Specifying reset lines connected to IP modules
> +==============================================
> +example:
> +
> + i2c0: i2c at ..... {
> + ...
> + resets = <&iomcu_rst 0>;
> + ...
> + };
I don't really like this approach, since now the information is
in two places. Why not put the data into the reset specifier
directly when it is used?
Also the format seems a little too close to the actual register
layout and could be a little more abstract, using bit numbers instead
of a bitmask and register numbers instead of offsets.
Arnd
^ permalink raw reply
* [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols
From: James Morse @ 2016-12-01 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-6-git-send-email-labbott@redhat.com>
Hi Laura,
On 29/11/16 18:55, Laura Abbott wrote:
> __pa_symbol is technically the marco that should be used for kernel
macro
> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
> will do bounds checking. As part of this, introduce lm_alias, a
> macro which wraps the __va(__pa(...)) idiom used a few places to
> get the alias.
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index d55a7b0..4f0c77d 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -484,7 +481,7 @@ int swsusp_arch_resume(void)
> * Since we only copied the linear map, we need to find restore_pblist's
> * linear map address.
> */
> - lm_restore_pblist = LMADDR(restore_pblist);
> + lm_restore_pblist = lm_alias(restore_pblist);
>
> /*
> * We need a zero page that is zero before & after resume in order to
This change causes resume from hibernate to panic in:
> VIRTUAL_BUG_ON(x < (unsigned long) KERNEL_START ||
> x > (unsigned long) KERNEL_END);
It looks like kaslr's relocation code has already fixed restore_pblist, so your
debug virtual check catches this doing the wrong thing. My bug.
readelf -s vmlinux | grep ...
> 103495: ffff000008080000 0 NOTYPE GLOBAL DEFAULT 1 _text
> 92104: ffff000008e43860 8 OBJECT GLOBAL DEFAULT 24 restore_pblist
> 105442: ffff000008e85000 0 NOTYPE GLOBAL DEFAULT 24 _end
But restore_pblist == 0xffff800971b7f998 when passed to __phys_addr_symbol().
This fixes the problem:
----------------%<----------------
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 4f0c77d2ff7a..8bed26a2d558 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -457,7 +457,6 @@ int swsusp_arch_resume(void)
void *zero_page;
size_t exit_size;
pgd_t *tmp_pg_dir;
- void *lm_restore_pblist;
phys_addr_t phys_hibernate_exit;
void __noreturn (*hibernate_exit)(phys_addr_t, phys_addr_t, void *,
void *, phys_addr_t, phys_addr_t);
@@ -478,12 +477,6 @@ int swsusp_arch_resume(void)
goto out;
/*
- * Since we only copied the linear map, we need to find restore_pblist's
- * linear map address.
- */
- lm_restore_pblist = lm_alias(restore_pblist);
-
- /*
* We need a zero page that is zero before & after resume in order to
* to break before make on the ttbr1 page tables.
*/
@@ -534,7 +527,7 @@ int swsusp_arch_resume(void)
}
hibernate_exit(virt_to_phys(tmp_pg_dir), resume_hdr.ttbr1_el1,
- resume_hdr.reenter_kernel, lm_restore_pblist,
+ resume_hdr.reenter_kernel, restore_pblist,
resume_hdr.__hyp_stub_vectors, virt_to_phys(zero_page));
out:
----------------%<----------------
I can post it as a separate fixes patch if you prefer.
I also tested kexec. FWIW:
Tested-by: James Morse <james.morse@arm.com>
Thanks,
James
[0] Trace
[ 4.191607] Freezing user space processes ... (elapsed 0.000 seconds) done.
[ 4.224251] random: fast init done
[ 4.243825] PM: Using 3 thread(s) for decompression.
[ 4.243825] PM: Loading and decompressing image data (90831 pages)...
[ 4.255257] hibernate: Hibernated on CPU 0 [mpidr:0x100]
[ 5.213469] PM: Image loading progress: 0%
[ 5.579886] PM: Image loading progress: 10%
[ 5.740234] ata2: SATA link down (SStatus 0 SControl 0)
[ 5.760435] PM: Image loading progress: 20%
[ 5.970647] PM: Image loading progress: 30%
[ 6.563108] PM: Image loading progress: 40%
[ 6.848389] PM: Image loading progress: 50%
[ 7.526272] PM: Image loading progress: 60%
[ 7.702727] PM: Image loading progress: 70%
[ 7.899754] PM: Image loading progress: 80%
[ 8.100703] PM: Image loading progress: 90%
[ 8.300978] PM: Image loading progress: 100%
[ 8.305441] PM: Image loading done.
[ 8.308975] PM: Read 363324 kbytes in 4.05 seconds (89.70 MB/s)
[ 8.344299] PM: quiesce of devices complete after 22.706 msecs
[ 8.350762] PM: late quiesce of devices complete after 0.596 msecs
[ 8.381334] PM: noirq quiesce of devices complete after 24.365 msecs
[ 8.387729] Disabling non-boot CPUs ...
[ 8.412500] CPU1: shutdown
[ 8.415211] psci: CPU1 killed.
[ 8.460465] CPU2: shutdown
[ 8.463175] psci: CPU2 killed.
[ 8.504447] CPU3: shutdown
[ 8.507156] psci: CPU3 killed.
[ 8.540375] CPU4: shutdown
[ 8.543084] psci: CPU4 killed.
[ 8.580333] CPU5: shutdown
[ 8.583043] psci: CPU5 killed.
[ 8.601206] ------------[ cut here ]------------
[ 8.601206] kernel BUG at ../arch/arm64/mm/physaddr.c:25!
[ 8.601206] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 8.601206] Modules linked in:
[ 8.601206] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7-00010-g27c672
[ 8.601206] Hardware name: ARM Juno development board (r1) (DT)
[ 8.601206] task: ffff800976ca8000 task.stack: ffff800976c3c000
[ 8.601206] PC is at __phys_addr_symbol+0x30/0x34
[ 8.601206] LR is at swsusp_arch_resume+0x304/0x588
[ 8.601206] pc : [<ffff0000080992d8>] lr : [<ffff0000080938b4>] pstate: 20005
[ 8.601206] sp : ffff800976c3fca0
[ 8.601206] x29: ffff800976c3fca0 x28: ffff000008bee000
[ 8.601206] x27: 000000000e5ea000 x26: ffff000008e83000
[ 8.601206] x25: 0000000000000801 x24: 0000000040000000
[ 8.601206] x23: 0000000000000000 x22: 000000000e00d000
[ 8.601206] x21: ffff808000000000 x20: ffff800080000000
[ 8.601206] x19: 0000000000000000 x18: 4000000000000000
[ 8.601206] x17: 0000000000000000 x16: 0000000000000694
[ 8.601206] x15: ffff000008bee000 x14: 0000000000000008
[ 8.601206] x13: 0000000000000000 x12: 003d090000000000
[ 8.601206] x11: 0000000000000001 x10: fffffffff1a0f000
[ 8.601206] x9 : 0000000000000001 x8 : ffff800971a0aff8
[ 8.601206] x7 : 0000000000000001 x6 : 000000000000003f
[ 8.601206] x5 : 0000000000000040 x4 : 0000000000000000
[ 8.601206] x3 : ffff807fffffffff x2 : 0000000000000000
[ 8.601206] x1 : ffff000008e85000 x0 : ffff80097152b578
[ 8.601206]
[ 8.601206] Process swapper/0 (pid: 1, stack limit = 0xffff800976c3c020)
[ 8.601206] Stack: (0xffff800976c3fca0 to 0xffff800976c40000)
[ 8.601206] Call trace:
[ 8.601206] Exception stack(0xffff800976c3fad0 to 0xffff800976c3fc00)
[ 8.601206] [<ffff0000080992d8>] __phys_addr_symbol+0x30/0x34
[ 8.601206] [<ffff0000080fe340>] hibernation_restore+0xf8/0x130
[ 8.601206] [<ffff0000080fe3e4>] load_image_and_restore+0x6c/0x70
[ 8.601206] [<ffff0000080fe640>] software_resume+0x258/0x288
[ 8.601206] [<ffff0000080830b8>] do_one_initcall+0x38/0x128
[ 8.601206] [<ffff000008c60cf4>] kernel_init_freeable+0x1ac/0x250
[ 8.601206] [<ffff0000088acd10>] kernel_init+0x10/0x100
[ 8.601206] [<ffff000008082e80>] ret_from_fork+0x10/0x50
[ 8.601206] Code: b0005aa1 f9475c21 cb010000 d65f03c0 (d4210000)
[ 8.601206] ---[ end trace e15be9f4f989f0b5 ]---
[ 8.601206] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0b
[ 8.601206]
[ 8.601206] Kernel Offset: disabled
[ 8.601206] Memory Limit: none
[ 8.601206] ---[ end Kernel panic - not syncing: Attempted to kill init! exib
[ 8.601206]
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: zx: support cpu-freq for zx296718
From: Baoyou Xie @ 2016-12-01 12:02 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.
So it can be used by cpufreq-dt driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 37 +++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 7a1aed7..16f7d5e 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/clock/zx296718-clock.h>
/ {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <&topcrm A53_GATE>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu at 1 {
@@ -88,6 +91,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu at 2 {
@@ -95,6 +99,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu3: cpu at 3 {
@@ -102,6 +107,38 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 648000000 {
+ opp-hz = /bits/ 64 <648000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <882000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <892000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1188000000 {
+ opp-hz = /bits/ 64 <1188000000>;
+ opp-microvolt = <1009000>;
+ clock-latency-ns = <500000>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-12-01 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKeJBL7_V_7QPVNDAd9H4bgeLcSF8enuD96sgEmecuRkRA@mail.gmail.com>
Hi Marcin,
On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
> Hi Jisheng,
>
> Which baseline do you use?
>
> It took me really lot of time to catch why RX broke after rebase from
> LKv4.1 to LKv4.4. Between those two, in commit:
> 97303480753e ("arm64: Increase the max granular size")
> L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
> did NET_SKB_PAD.
>
> And 128 is more than the maximum that can fit into packet offset
> [11:8]@0x1400. In such case this correction is needed. Did it answer
> your doubts?
That's key! Thanks a lot. In my repo, we don't have commit 97303480753e
("arm64: Increase the max granular size")
I think it would be great if this information can be added into the commit
msg.
IIRC, arm64 maintainers considered to let L1_CACHE_BYTES the _minimum_ of
cache line sizes of arm64. If that's implemented and merged, then we can
revert this patch later.
Thanks,
Jisheng
>
> Best regards,
> Marcin
>
>
>
> 2016-12-01 12:26 GMT+01:00 Jisheng Zhang <jszhang@marvell.com>:
> > Hi Gregory, Marcin,
> >
> > On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
> >
> >> From: Marcin Wojtas <mw@semihalf.com>
> >>
> >> Prepare the mvneta driver in order to be usable on the 64 bits platform
> >> such as the Armada 3700.
> >>
> >> [gregory.clement at free-electrons.com]: this patch was extract from a larger
> >> one to ease review and maintenance.
> >>
> >> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >> ---
> >> drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
> >> 1 file changed, 16 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> >> index 92b9af14c352..8ef03fb69bcd 100644
> >> --- a/drivers/net/ethernet/marvell/mvneta.c
> >> +++ b/drivers/net/ethernet/marvell/mvneta.c
> >> @@ -296,6 +296,12 @@
> >> /* descriptor aligned size */
> >> #define MVNETA_DESC_ALIGNED_SIZE 32
> >>
> >> +/* Number of bytes to be taken into account by HW when putting incoming data
> >> + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
> >> + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
> >
> > We also brought up this driver on 64bit platforms, we doesn't have this
> > patch. Maybe I'm wrong, I'm trying to understand why we need this
> > modification. Let's assume the NET_SKB_PAD is 64B, we call
> > mvneta_rxq_offset_set(pp, rxq, 64),
> >
> > {
> > u32 val;
> >
> > val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
> > val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
> >
> > /* Offset is in */
> > val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
> > // then this will be "val |= 8;" it doesn't exceeds the max offset of
> > MVNETA_RXQ_CONFIG_REG(q) register.
> >
> > Could you please kindly point out where I am wrong?
> >
> >> + */
> >> +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
> >> +
> >> #define MVNETA_RX_PKT_SIZE(mtu) \
> >> ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
> >> ETH_HLEN + ETH_FCS_LEN, \
> >> @@ -416,6 +422,7 @@ struct mvneta_port {
> >> u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
> >>
> >> u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
> >> + u16 rx_offset_correction;
> >> };
> >>
> >> /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> >> @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
> >> return -ENOMEM;
> >> }
> >>
> >> + phys_addr += pp->rx_offset_correction;
> >> mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
> >> return 0;
> >> }
> >> @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
> >> mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
> >>
> >> /* Set Offset */
> >> - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
> >> + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
> >>
> >> /* Set coalescing pkts and time */
> >> mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
> >> @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
> >>
> >> pp->rxq_def = rxq_def;
> >>
> >> + /* Set RX packet offset correction for platforms, whose
> >> + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
> >> + * platforms and 0B for 32-bit ones.
> >
> > Even we need this patch, I'm not sure this last comment is correct or not.
> > NET_SKB_PAD is defined as:
> >
> > #define NET_SKB_PAD max(32, L1_CACHE_BYTES)
> >
> > we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
> > should be 64B as well.
> >
> > Thanks,
> > Jisheng
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Gregory CLEMENT @ 2016-12-01 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKeJBL7_V_7QPVNDAd9H4bgeLcSF8enuD96sgEmecuRkRA@mail.gmail.com>
Hi Jisheng,
On jeu., d?c. 01 2016, Marcin Wojtas <mw@semihalf.com> wrote:
> Hi Jisheng,
>
> Which baseline do you use?
>
> It took me really lot of time to catch why RX broke after rebase from
> LKv4.1 to LKv4.4. Between those two, in commit:
> 97303480753e ("arm64: Increase the max granular size")
> L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
> did NET_SKB_PAD.
>
> And 128 is more than the maximum that can fit into packet offset
> [11:8]@0x1400. In such case this correction is needed. Did it answer
> your doubts?
I can confirm also that without this patch it just doesn't work.
Gregory
>
> Best regards,
> Marcin
>
>
>
> 2016-12-01 12:26 GMT+01:00 Jisheng Zhang <jszhang@marvell.com>:
>> Hi Gregory, Marcin,
>>
>> On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
>>
>>> From: Marcin Wojtas <mw@semihalf.com>
>>>
>>> Prepare the mvneta driver in order to be usable on the 64 bits platform
>>> such as the Armada 3700.
>>>
>>> [gregory.clement at free-electrons.com]: this patch was extract from a larger
>>> one to ease review and maintenance.
>>>
>>> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>> ---
>>> drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
>>> index 92b9af14c352..8ef03fb69bcd 100644
>>> --- a/drivers/net/ethernet/marvell/mvneta.c
>>> +++ b/drivers/net/ethernet/marvell/mvneta.c
>>> @@ -296,6 +296,12 @@
>>> /* descriptor aligned size */
>>> #define MVNETA_DESC_ALIGNED_SIZE 32
>>>
>>> +/* Number of bytes to be taken into account by HW when putting incoming data
>>> + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
>>> + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
>>
>> We also brought up this driver on 64bit platforms, we doesn't have this
>> patch. Maybe I'm wrong, I'm trying to understand why we need this
>> modification. Let's assume the NET_SKB_PAD is 64B, we call
>> mvneta_rxq_offset_set(pp, rxq, 64),
>>
>> {
>> u32 val;
>>
>> val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
>> val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
>>
>> /* Offset is in */
>> val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
>> // then this will be "val |= 8;" it doesn't exceeds the max offset of
>> MVNETA_RXQ_CONFIG_REG(q) register.
>>
>> Could you please kindly point out where I am wrong?
>>
>>> + */
>>> +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
>>> +
>>> #define MVNETA_RX_PKT_SIZE(mtu) \
>>> ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
>>> ETH_HLEN + ETH_FCS_LEN, \
>>> @@ -416,6 +422,7 @@ struct mvneta_port {
>>> u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
>>>
>>> u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
>>> + u16 rx_offset_correction;
>>> };
>>>
>>> /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
>>> @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
>>> return -ENOMEM;
>>> }
>>>
>>> + phys_addr += pp->rx_offset_correction;
>>> mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
>>> return 0;
>>> }
>>> @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
>>> mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
>>>
>>> /* Set Offset */
>>> - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
>>> + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
>>>
>>> /* Set coalescing pkts and time */
>>> mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
>>> @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
>>>
>>> pp->rxq_def = rxq_def;
>>>
>>> + /* Set RX packet offset correction for platforms, whose
>>> + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
>>> + * platforms and 0B for 32-bit ones.
>>
>> Even we need this patch, I'm not sure this last comment is correct or not.
>> NET_SKB_PAD is defined as:
>>
>> #define NET_SKB_PAD max(32, L1_CACHE_BYTES)
>>
>> we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
>> should be 64B as well.
>>
>> Thanks,
>> Jisheng
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself
From: Peter Rosin @ 2016-12-01 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480593549-6464-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../bindings/sound/axentia,tse850-pcm5142.txt | 5 ++---
sound/soc/atmel/tse850-pcm5142.c | 23 +++-------------------
2 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
index 5b9b38f578bb..fd12ecb35b5c 100644
--- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -2,8 +2,7 @@ Devicetree bindings for the Axentia TSE-850 audio complex
Required properties:
- compatible: "axentia,tse850-pcm5142"
- - axentia,ssc-controller: The phandle of the atmel SSC controller used as
- cpu dai.
+ - axentia,cpu-dai: The phandle of the cpu dai.
- axentia,audio-codec: The phandle of the PCM5142 codec.
- axentia,add-gpios: gpio specifier that controls the mixer.
- axentia,loop1-gpios: gpio specifier that controls loop relays on channel 1.
@@ -77,7 +76,7 @@ Example:
sound {
compatible = "axentia,tse850-pcm5142";
- axentia,ssc-controller = <&ssc0>;
+ axentia,cpu-dai = <&ssc0>;
axentia,audio-codec = <&codec>;
axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
diff --git a/sound/soc/atmel/tse850-pcm5142.c b/sound/soc/atmel/tse850-pcm5142.c
index ac6a814c8ecf..a72c7d642026 100644
--- a/sound/soc/atmel/tse850-pcm5142.c
+++ b/sound/soc/atmel/tse850-pcm5142.c
@@ -51,11 +51,7 @@
#include <sound/soc.h>
#include <sound/pcm_params.h>
-#include "atmel_ssc_dai.h"
-
struct tse850_priv {
- int ssc_id;
-
struct gpio_desc *add;
struct gpio_desc *loop1;
struct gpio_desc *loop2;
@@ -329,23 +325,20 @@ static int tse850_dt_init(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct device_node *codec_np, *cpu_np;
- struct snd_soc_card *card = &tse850_card;
struct snd_soc_dai_link *dailink = &tse850_dailink;
- struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
if (!np) {
dev_err(&pdev->dev, "only device tree supported\n");
return -EINVAL;
}
- cpu_np = of_parse_phandle(np, "axentia,ssc-controller", 0);
+ cpu_np = of_parse_phandle(np, "axentia,cpu-dai", 0);
if (!cpu_np) {
- dev_err(&pdev->dev, "failed to get dai and pcm info\n");
+ dev_err(&pdev->dev, "failed to get cpu dai\n");
return -EINVAL;
}
dailink->cpu_of_node = cpu_np;
dailink->platform_of_node = cpu_np;
- tse850->ssc_id = of_alias_get_id(cpu_np, "ssc");
of_node_put(cpu_np);
codec_np = of_parse_phandle(np, "axentia,audio-codec", 0);
@@ -415,23 +408,14 @@ static int tse850_probe(struct platform_device *pdev)
return ret;
}
- ret = atmel_ssc_set_audio(tse850->ssc_id);
- if (ret != 0) {
- dev_err(dev,
- "failed to set SSC %d for audio\n", tse850->ssc_id);
- goto err_disable_ana;
- }
-
ret = snd_soc_register_card(card);
if (ret) {
dev_err(dev, "snd_soc_register_card failed\n");
- goto err_put_audio;
+ goto err_disable_ana;
}
return 0;
-err_put_audio:
- atmel_ssc_put_audio(tse850->ssc_id);
err_disable_ana:
regulator_disable(tse850->ana);
return ret;
@@ -443,7 +427,6 @@ static int tse850_remove(struct platform_device *pdev)
struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
snd_soc_unregister_card(card);
- atmel_ssc_put_audio(tse850->ssc_id);
regulator_disable(tse850->ana);
return 0;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
From: Peter Rosin @ 2016-12-01 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480593549-6464-1-git-send-email-peda@axentia.se>
The SSC is currently not usable with the ASoC simple-audio-card, as
every SSC audio user has to build a platform driver that may do as
little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
allocates the SSC and registers a DAI with the ASoC subsystem).
So, have that happen automatically, if the #sound-dai-cells property
is present in devicetree, which it has to be anyway for simple audio
card to work.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
include/linux/atmel-ssc.h | 1 +
3 files changed, 53 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index efc98ea1f23d..f8629bb73945 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -24,6 +24,8 @@ Optional properties:
this parameter to choose where the clock from.
- By default the clock is from TK pin, if the clock from RK pin, this
property is needed.
+ - #sound-dai-cells: Should contain <0>.
+ - This property makes the SSC into an automatically registered DAI.
Examples:
- PDC transfer:
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 0516ecda54d3..b2a0340f277e 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -20,6 +20,8 @@
#include <linux/of.h>
+#include "../../sound/soc/atmel/atmel_ssc_dai.h"
+
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
static LIST_HEAD(ssc_list);
@@ -145,6 +147,49 @@ static inline const struct atmel_ssc_platform_data * __init
platform_get_device_id(pdev)->driver_data;
}
+#ifdef CONFIG_SND_ATMEL_SOC_SSC
+static int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ struct device_node *np = ssc->pdev->dev.of_node;
+ int ret;
+ int id;
+
+ ssc->sound_dai = false;
+
+ if (!of_property_read_bool(np, "#sound-dai-cells"))
+ return 0;
+
+ id = of_alias_get_id(np, "ssc");
+ if (id < 0)
+ return id;
+
+ ret = atmel_ssc_set_audio(id);
+ ssc->sound_dai = !ret;
+
+ return ret;
+}
+
+static void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+ if (!ssc->sound_dai)
+ return;
+
+ atmel_ssc_put_audio(of_alias_get_id(ssc->pdev->dev.of_node, "ssc"));
+}
+#else
+static inline int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ if (of_property_read_bool(ssc->pdev->dev.of_node, "#sound-dai-cells"))
+ return -ENOTSUPP;
+
+ return 0;
+}
+
+static inline void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+}
+#endif
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -204,6 +249,9 @@ static int ssc_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n",
ssc->regs, ssc->irq);
+ if (ssc_sound_dai_probe(ssc))
+ dev_err(&pdev->dev, "failed to auto-setup ssc for audio\n");
+
return 0;
}
@@ -211,6 +259,8 @@ static int ssc_remove(struct platform_device *pdev)
{
struct ssc_device *ssc = platform_get_drvdata(pdev);
+ ssc_sound_dai_remove(ssc);
+
spin_lock(&user_lock);
list_del(&ssc->list);
spin_unlock(&user_lock);
diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
index 7c0f6549898b..fdb545101ede 100644
--- a/include/linux/atmel-ssc.h
+++ b/include/linux/atmel-ssc.h
@@ -20,6 +20,7 @@ struct ssc_device {
int user;
int irq;
bool clk_from_rk_pin;
+ bool sound_dai;
};
struct ssc_device * __must_check ssc_request(unsigned int ssc_num);
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox