* [PATCH v6] KVM: arm/arm64: Route vtimer events to user space
From: Paolo Bonzini @ 2016-09-23 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474628854-69945-1-git-send-email-agraf@suse.de>
On 23/09/2016 13:07, Alexander Graf wrote:
> + timer_ret = kvm_timer_sync_hwstate(vcpu);
>
> kvm_vgic_sync_hwstate(vcpu);
>
> preempt_enable();
>
> ret = handle_exit(vcpu, run, ret);
> +
> + if ((ret == 1) && timer_ret) {
> + /*
> + * We have to exit straight away to ensure that we only
> + * ever notify user space once about a level change
> + */
Is this really a requirement? It complicates the logic noticeably.
Paolo
> + ret = -EINTR;
> + run->exit_reason = KVM_EXIT_INTR;
> + }
> }
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Arnd Bergmann @ 2016-09-23 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474597146-33312-1-git-send-email-b18965@freescale.com>
On Friday, September 23, 2016 10:19:05 AM CEST Alison Wang wrote:
> The ARMv8 architecture supports:
> 1. 64-bit execution state, AArch64.
> 2. 32-bit execution state, AArch32, that is compatible with previous
> versions of the ARM architecture.
>
> LayerScape platforms are compliant with ARMv8 architecture. This patch
> is to support running 32-bit Linux kernel for LayerScape platforms.
>
> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
>
> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> Signed-off-by: Alison Wang <alison.wang@nxp.com>
I'm not too happy about adding random 64-bit platforms in arch/arm/.
We have done this twice already (ARCH_VIRT and ARCH_BCM2835), which
are both platforms that can come with ARMv6, ARMv7 or ARMv8 cores
and are otherwise almost identical. However, there are two problem
I see with the general approach:
a) We don't actually support ARMv8 as a target architecture, in fact
we don't even support ARMv7VE (Cortex-A7/A12/A15/A17, Krait-400,
PJ4B-MP and Brahma-B15) properly. For an ARMv8-only kernel
we should pass the correct compiler flags. We should also have
this for any upcoming Cortex-A32 and Cortex-R52 platforms.
b) Generally speaking it's a bad idea to run an platform that
supports aarch64 in aarch32 mode, you should use a native kernel
with syscall emulation for 32-bit user space unless you have a
very strong reason not to do that. If you have a strong reason
why your platform is different from all the others, please at
least explain it in the changelog.
On the other hand, any platform support both aarch64 and aarch32
mode should in theory run with a 32-bit kernel, and it might be
nice to allow that for *all* platforms that we support on a 64-bit
kernel. If we decide to do this, we should come up with a way to
include the platform configuration from arch/arm64 in the arm
Kconfig file.
Arnd
^ permalink raw reply
* [PATCH] i2c: uniphier-f: fix misdetection of incomplete STOP condition
From: Wolfram Sang @ 2016-09-23 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474632241-10440-1-git-send-email-yamada.masahiro@socionext.com>
On Fri, Sep 23, 2016 at 09:04:01PM +0900, Masahiro Yamada wrote:
> Currently, the status register FI2C_SR is checked immediately after
> a STOP condition is issued in case of the deferred STOP condition.
> It takes typically 5-10 usec until the corresponding bits in the
> register are set, so the error check for "stop condition was not
> completed" is very likely to be false positive.
>
> Add wait code to relax the status register check.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Use readl_poll_timeout?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160923/fdca9ba0/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Robin Murphy @ 2016-09-23 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474597146-33312-1-git-send-email-b18965@freescale.com>
Hi Alison,
On 23/09/16 03:19, Alison Wang wrote:
> The ARMv8 architecture supports:
> 1. 64-bit execution state, AArch64.
> 2. 32-bit execution state, AArch32, that is compatible with previous
> versions of the ARM architecture.
>
> LayerScape platforms are compliant with ARMv8 architecture. This patch
> is to support running 32-bit Linux kernel for LayerScape platforms.
>
> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
>
> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> Signed-off-by: Alison Wang <alison.wang@nxp.com>
> ---
> arch/arm/Kconfig | 9 +++++++++
> arch/arm/mach-imx/Kconfig | 14 ++++++++++++++
> arch/arm/mach-imx/Makefile | 4 +++-
> arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
> 4 files changed, 49 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/mach-imx/mach-layerscape.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f0c8068..e8d470e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
> default 3 if ARM_LPAE
> default 2
>
> +config ARCH_AARCH32_ES_SUPPORT
> + def_bool n
> + help
> + The ARMv8 architecture supports 64-bit execution state, AArch64
> + and 32-bit execution state, AArch32, that is compatible with
> + previous versions of the ARM architecture.
> +
> + Enable AArch32 execution state support for ARMv8 architecture.
What's this supposed to do, exactly? I've been running 32-bit kernels on
my Juno with very little issue (beyond a couple of DT tweaks, and some
firmware hacks with a corresponding bit of A64 assembly tacked on the
front of the zImage to switch into AArch32 state).
Robin.
> +
> source "init/Kconfig"
>
> source "kernel/Kconfig.freezer"
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 0ac05a0..fda4f5f 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -549,6 +549,20 @@ config SOC_LS1021A
> help
> This enables support for Freescale LS1021A processor.
>
> +config ARCH_LAYERSCAPE_AARCH32
> + bool "Freescale Layerscape SoC AArch32 ES support"
> + select ARCH_AARCH32_ES_SUPPORT
> + select ARM_AMBA
> + select ARM_GIC
> + select ARM_ARCH_TIMER
> + select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
> + select PCI_LAYERSCAPE if PCI
> + select PCI_DOMAINS if PCI
> +
> + help
> + This enables support for Freescale Layerscape SoC family in
> + in AArch32 execution state.
> +
> endif
>
> comment "Cortex-A/Cortex-M asymmetric multiprocessing platforms"
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index 737450f..7ded4fa 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -69,7 +69,7 @@ obj-$(CONFIG_HAVE_IMX_ANATOP) += anatop.o
> obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
> obj-$(CONFIG_HAVE_IMX_SRC) += src.o
> -ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A),)
> +ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A)$(CONFIG_ARCH_LAYERSCAPE_AARCH32),)
> AFLAGS_headsmp.o :=-Wa,-march=armv7-a
> obj-$(CONFIG_SMP) += headsmp.o platsmp.o
> obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
> @@ -96,4 +96,6 @@ obj-$(CONFIG_SOC_VF610) += mach-vf610.o
>
> obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o
>
> +obj-$(CONFIG_ARCH_LAYERSCAPE_AARCH32) += mach-layerscape.o
> +
> obj-y += devices/
> diff --git a/arch/arm/mach-imx/mach-layerscape.c b/arch/arm/mach-imx/mach-layerscape.c
> new file mode 100644
> index 0000000..acfb2a2
> --- /dev/null
> +++ b/arch/arm/mach-imx/mach-layerscape.c
> @@ -0,0 +1,23 @@
> +/*
> + * Copyright 2015-2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <asm/mach/arch.h>
> +
> +#include "common.h"
> +
> +static const char * const layerscape_dt_compat[] __initconst = {
> + "fsl,ls1012a",
> + "fsl,ls1043a",
> + "fsl,ls1046a",
> + NULL,
> +};
> +
> +DT_MACHINE_START(LAYERSCAPE_AARCH32, "Freescale LAYERSCAPE")
> + .dt_compat = layerscape_dt_compat,
> +MACHINE_END
>
^ permalink raw reply
* [PATCH net-next] drivers: net: xgene: Fix MSS programming
From: David Miller @ 2016-09-23 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474584453-9071-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Thu, 22 Sep 2016 15:47:33 -0700
> Current driver programs static value of MSS in hardware register for TSO
> offload engine to segment the TCP payload regardless the MSS value
> provided by network stack.
>
> This patch fixes this by programming hardware registers with the
> stack provided MSS value.
>
> Since the hardware has the limitation of having only 4 MSS registers,
> this patch uses reference count of mss values being used.
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
> Signed-off-by: Toan Le <toanle@apm.com>
Applied.
^ permalink raw reply
* [PATCH 2/2] armv8: aarch32: Add SMP support for 32-bit Linux kernel
From: Mark Rutland @ 2016-09-23 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474597146-33312-2-git-send-email-b18965@freescale.com>
On Fri, Sep 23, 2016 at 10:19:06AM +0800, Alison Wang wrote:
> The patch adds SMP support for running 32-bit Linux kernel for
> Layerscape platforms. Spin-table method is used for SMP support.
So far, spin-table has not been defined for 32-bit, and the code below,
while mostly a copy of the 64-bit code, is somewhat different.
If you want a common enable method, I would strongly advise that you use
PSCI, which is well-defined for both 32-bit and 64-bit. There are a
number of problems with spin-table, and I would not recommend extending
it to 32-bit ARM.
Thanks,
Mark.
^ permalink raw reply
* [PATCH V11 0/8] Introduce ACPI world to ITS irqchip
From: Auger Eric @ 2016-09-23 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473705147-6588-1-git-send-email-tn@semihalf.com>
Hi,
On 12/09/2016 20:32, Tomasz Nowicki wrote:
> The series builds the PCI/MSI domain stack based on initial IORT driver
> which is added in first place. As a reference please see IORT spec:
> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
>
> Tested on Cavium ThunderX server and Qualcomm Technologies server platform QDF2XXX.
> The patches can be found here:
> https://github.com/semihalf-nowicki-tomasz/linux.git (its-acpi-v11)
Tested-by: Eric Auger <eric.auger@redhat.com>
on a Cavium QEMU guest with mach-virt.
Thanks
Eric
>
> v10 -> v11
> - rebased against v4.8-rc6
> - bug fix for iort_match_node_callback() error handling
> - patch 1-2 changelog updates
>
> v9 -> v10
> - error handling improvements for iort_match_node_callback() but no functional changes
> - iort.h -> acpi_iort.h header name change
> - style improvements
>
> v8 -> v9
> - rebased against v4.8-rc4
> - move root IORT pointer validation to one place iort_scan_node()
> - function names & Kconfig option name improvements
> - remove annoying dev_err() appearances for non-IORT users
> - for debug purpose print full ITS resource range
>
> v7 -> v8
> - rebased against v4.8-rc1
> - move IORT support under new drivers/acpi/arm64 directory
> - memory leak fix for iort_match_node_callback()
> - iort_node_map_rid() algorithm improvements
> - fix RID match check in iort_id_map()
> - fix typos and white spaces
>
> v6 -> v7
> - rebased against irq/irqchip-4.8
> - improvements for IORT ID mapping
> - call IORT init call from acpi_init() instead of arch_initcall()
> - split IORT driver in to two parts: core and ITS/MSI
>
> v5 -> v6
> - added locking mechanism for IORT list with domain token
> - IORT function name improvements
> - extended IORT RID mapping helper
> - reworked IORT to be more SMMU friendly
> - IORT functions which map RID and find corresponding domain are not
> PCI specific any more (struct pci_dev -> struct device)
> - bug fixes
>
> v4 -> v5
> - rebased against v4.7-rc1
> - drop generic layer and call IORT functions directly
> - improve resource abstraction and string formatting
>
> v3 -> v4
> - rebased against v4.5
> - add ACPI support for IRQ domain handling on a per-device basis
> - reorder domain setup step
> - improve error handling
> - code style improvements
>
> v2 -> v3
> - rebased on top of 4.4
> - fixes and improvements for redistributor init via GICC structures
> - fixes as per kbuild reports
>
> v1 -> v2
> - rebased on top of 4.4-rc4
> - use pci_msi_domain_get_msi_rid for requester ID to device ID translation
>
> Tomasz Nowicki (8):
> ACPI: I/O Remapping Table (IORT) initial support
> ACPI: Add new IORT functions to support MSI domain handling
> PCI/MSI: Setup MSI domain on a per-device basis using IORT ACPI table
> irqchip/gicv3-its: Cleanup for ITS domain initialization
> irqchip/gicv3-its: Refactor ITS DT init code to prepare for ACPI
> irqchip/gicv3-its: Probe ITS in the ACPI way
> irqchip/gicv3-its: Factor out PCI-MSI part that might be reused for
> ACPI
> irqchip/gicv3-its: Use MADT ITS subtable to do PCI/MSI domain
> initialization
>
> drivers/acpi/Kconfig | 4 +
> drivers/acpi/Makefile | 2 +
> drivers/acpi/arm64/Kconfig | 6 +
> drivers/acpi/arm64/Makefile | 1 +
> drivers/acpi/arm64/iort.c | 366 +++++++++++++++++++++++++++++++
> drivers/acpi/bus.c | 2 +
> drivers/irqchip/Kconfig | 1 +
> drivers/irqchip/irq-gic-v3-its-pci-msi.c | 88 ++++++--
> drivers/irqchip/irq-gic-v3-its.c | 171 +++++++++++----
> drivers/irqchip/irq-gic-v3.c | 7 +-
> drivers/pci/msi.c | 11 +-
> include/linux/acpi_iort.h | 42 ++++
> include/linux/irqchip/arm-gic-v3.h | 4 +-
> 13 files changed, 635 insertions(+), 70 deletions(-)
> create mode 100644 drivers/acpi/arm64/Kconfig
> create mode 100644 drivers/acpi/arm64/Makefile
> create mode 100644 drivers/acpi/arm64/iort.c
> create mode 100644 include/linux/acpi_iort.h
>
^ permalink raw reply
* [PATCH v6] KVM: arm/arm64: Route vtimer events to user space
From: Christoffer Dall @ 2016-09-23 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd9267b6-2323-2d74-0553-71a89d05a654@redhat.com>
On Fri, Sep 23, 2016 at 02:11:41PM +0200, Paolo Bonzini wrote:
>
>
> On 23/09/2016 13:07, Alexander Graf wrote:
> > + timer_ret = kvm_timer_sync_hwstate(vcpu);
> >
> > kvm_vgic_sync_hwstate(vcpu);
> >
> > preempt_enable();
> >
> > ret = handle_exit(vcpu, run, ret);
> > +
> > + if ((ret == 1) && timer_ret) {
> > + /*
> > + * We have to exit straight away to ensure that we only
> > + * ever notify user space once about a level change
> > + */
>
> Is this really a requirement? It complicates the logic noticeably.
>
If we skip this, then we have to somehow remember that the sync may have
updated the line level when we reach the flush state (and didn't exit),
and I would like maintaining that state even less than doing this check.
What we could do is to compare the timer->irq.level with the kvm_run
state outside of the run loop (on the way to userspace) and update the
kvm_run state if there's a discrepancy. That way, we can maintain the
'timer->irq.level != kvm_run' means, we have to exit, and whenever we
are exiting, we are reporting the most recent state to user space
anyway.
Would that work?
(By the way, the check should be via a call into the arch timer code,
kvm_timer_update_user_state() or something like that).
Also, the comment above is confusing, because that's not why this check
is here, the check is here so that we don't loose track of the timer
output level change if there's no exit to userspace.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v6] KVM: arm/arm64: Route vtimer events to user space
From: Paolo Bonzini @ 2016-09-23 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D82BA95A-A89E-46EB-93D2-197DF44433EC@suse.de>
On 23/09/2016 14:36, Alexander Graf wrote:
>>>
>>> + if ((ret == 1) && timer_ret) {
>>> + /*
>>> + * We have to exit straight away to ensure that we only
>>> + * ever notify user space once about a level change
>>> + */
>>
>> Is this really a requirement? It complicates the logic noticeably.
>
> The alternative would be to track the state on ioctl entry, which
> Christoffer disliked :).
Ok, I see. Maybe he's convinced by the ugly code. :)
It's not an architectural concept, it's a KVM API concept. Tracking the
state on entry just the equivalent of making this vmexit edge-triggered
(both rising and falling edge).
Paolo
^ permalink raw reply
* [PATCH v5 1/3] ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency
From: Maxime Ripard @ 2016-09-23 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922071313.12891-2-dannym@scratchpost.org>
Hi,
On Thu, Sep 22, 2016 at 09:13:11AM +0200, Danny Milosavljevic wrote:
> ASoC: sun4i-codec: Rename "sun4i_codec_widgets" to "sun4i_codec_controls" for
> consistency with the struct field name.
Your commit log still has the flaws your other patches had in the
previous version.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160923/3e8272c4/attachment.sig>
^ permalink raw reply
* [PATCH 5/5] arm64: Add uprobe support
From: Catalin Marinas @ 2016-09-23 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923041230.GC29470@localhost.localdomain>
On Fri, Sep 23, 2016 at 09:42:30AM +0530, Pratyush Anand wrote:
> On 22/09/2016:05:50:30 PM, Catalin Marinas wrote:
> > On Thu, Sep 22, 2016 at 08:53:28AM +0530, Pratyush Anand wrote:
> > > On 21/09/2016:06:04:04 PM, Catalin Marinas wrote:
> > > > On Wed, Sep 21, 2016 at 04:30:47PM +0530, Pratyush Anand wrote:
> > > > > On 20/09/2016:05:59:46 PM, Catalin Marinas wrote:
> > > > > > > +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct *mm,
> > > > > > > + unsigned long addr)
> > > > > > > +{
> > > > > > > + probe_opcode_t insn;
> > > > > > > +
> > > > > > > + /* TODO: Currently we do not support AARCH32 instruction probing */
> > > > > >
> > > > > > Is there a way to check (not necessarily in this file) that we don't
> > > > > > probe 32-bit tasks?
> > > > >
> > > > > - Well, I do not have complete idea about it that, how it can be done. I think
> > > > > we can not check that just by looking a single bit in an instruction.
> > > > > My understanding is that, we can only know about it when we are executing the
> > > > > instruction, by reading pstate, but that would not be useful for uprobe
> > > > > instruction analysis.
> > > > >
> > > > > I hope, instruction encoding for aarch32 and aarch64 are different, and by
> > > > > analyzing for all types of aarch32 instructions, we will be able to decide
> > > > > that whether instruction is 32 bit trace-able or not. Accordingly, we can use
> > > > > either BRK or BKPT instruction for breakpoint generation.
> > > >
> > > > We may have some unrelated instruction encoding overlapping but I
> > > > haven't checked. I was more thinking about whether we know which task is
> > > > being probed and check is_compat_task() or maybe using
> > > > compat_user_mode(regs).
> > >
> > > I had thought of this, but problem is that we might not have task in existence
> > > when we enable uprobes. For example: Lets say we are inserting a trace probe at
> > > offset 0x690 in a executable binary.
> > >
> > > echo "p test:0x690" > /sys/kernel/debug/tracing/uprobe_events
> > > echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
> > >
> > > In the 'enable' step, it is decided that whether instruction is traceable or
> > > not.
> > >
> > > (1) But at this point 'test' executable might not be running.
>
> Let me correct myself first here. When executable is not running, then,
> arch_uprobe_analyze_insn() is not called while uprobes enabling (ie writing '1'
> to 'enable'). In that case, it is called when binary is executed and task is
> created.
I kind of figured this out. This function needs to read the actual
instruction from memory, so that won't be possible until at least the
executable file has an address_space in the kernel. What's not clear to
me is how early this is done, do we have the mm_struct fully populated?
> > > (2) Even if it is running, is_compat_task() or compat_user_mode() might not be
> > > usable, as they work with 'current' task.
> >
> > What I find strange is that uprobes allows you to insert a breakpoint
> > instruction that's not even compatible with the task (so it would
> > SIGILL rather than generate a debug exception).
> >
> > > What I was thinking that, let it go with 'TODO' as of now.
> >
> > Only that I don't have any guarantee that someone is going to fix it ;).
> >
> > As a quick workaround you could check mm->task_size > TASK_SIZE_32 in
> > the arch_uprobe_analyze_insn() function.
>
> It would be doable. TASK_SIZE_32 is defined only for COMPAT. So, may be I can
> return -EINVAL when mm->task_size < TASK_SIZE_64.
That's just a temporary workaround. If we ever merge ILP32, this test
would no longer be enough (as the ISA is AArch64 but with TASK_SIZE_32).
Looking@prepare_uprobe(), we have a weak is_trap_insn() function.
This check is meaningless without knowing which instruction set we
target. A false positive here, however, is not that bad as we wouldn't
end up inserting the wrong breakpoint in the executable. But it looks to
me like the core uprobe code needs to pass some additional information
like the type of task or ELF format to the arch code to make a useful
choice of breakpoint type.
--
Catalin
^ permalink raw reply
* [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode
From: Rob Herring @ 2016-09-23 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR0401MB1709F91B0C1EB6C80D741E4492F50@VI1PR0401MB1709.eurprd04.prod.outlook.com>
On Sun, Sep 18, 2016 at 03:37:27AM +0000, Po Liu wrote:
> Hi Shawn,
>
>
> > -----Original Message-----
> > From: Shawn Guo [mailto:shawnguo at kernel.org]
> > Sent: Sunday, September 18, 2016 8:52 AM
> > To: Po Liu
> > Cc: linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > linux-kernel at vger.kernel.org; devicetree at vger.kernel.org; Roy Zang; Arnd
> > Bergmann; Marc Zyngier; Stuart Yoder; Leo Li; M.H. Lian; Murali
> > Karicheri; Bjorn Helgaas; Mingkai Hu
> > Subject: Re: [PATCH v5 3/3] pci:aer: add support aer interrupt with none
> > MSI/MSI-X/INTx mode
> >
> > On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
> > > On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
> > > When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
> > > maybe there is interrupt line for aer pme etc. Search the interrupt
> > > number in the fdt file. Then fixup the dev->irq with it.
> > >
> > > Signed-off-by: Po Liu <po.liu@nxp.com>
> >
> > Will the new kernel work with existing/old DTB? I'm trying to
> > understand the dependency between driver and DTS changes.
>
> Yes, We've never use name 'intr' before. So we remove it is ok.
> 'aer' is a dts name for researching it's true interrupt number by
> kernel. This patch is first time to use name 'aer'. So it must be
> compatible with existing/old DTB.
Please explain why you are not breaking compatibility in the commit
message. I asked for this on v2.
> > > ---
> > > changes for v5:
> > > - Add clear 'aer' interrup-names description
> > >
> > > .../devicetree/bindings/pci/layerscape-pci.txt | 11 +++++---
> > > drivers/pci/pcie/portdrv_core.c | 31
> > +++++++++++++++++++---
> > > 2 files changed, 35 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > index 41e9f55..101d0a7 100644
> > > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > @@ -18,8 +18,10 @@ Required properties:
> > > - reg: base addresses and lengths of the PCIe controller
> > > - interrupts: A list of interrupt outputs of the controller. Must
> > contain an
> > > entry for each entry in the interrupt-names property.
> > > -- interrupt-names: Must include the following entries:
> > > - "intr": The interrupt that is asserted for controller interrupts
> > > +- interrupt-names: It may be include the following entries:
"may be" is not okay. It should be "must" or explain when an interrupt
would not be present. Really, differences in interrupts means you need
different compatible strings.
Rob
> > > + "aer": The interrupt that is asserted for aer interrupt
> > > + "pme": The interrupt that is asserted for pme interrupt
> > > + ......
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Eric Anholt @ 2016-09-23 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb-hRjD+FmyZ4SKurp94V=HR3L90OLNc-6eUKuy9AK_Rg@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt <eric@anholt.net> wrote:
>
>> The RPi firmware exposes all of the board's GPIO lines through
>> property calls. Linux chooses to control most lines directly through
>> the pinctrl driver, but for the FXL6408 GPIO expander on the Pi3, we
>> need to access them through the firmware.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>
> Aha
>
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
>> @@ -0,0 +1,22 @@
>> +Raspberry Pi power domain driver
>
> Really? :)
Thanks.
>> +Required properties:
>> +
>> +- compatible: Should be "raspberrypi,firmware-gpio"
>
> Usually this is vendor,compat, is the vendors name "raspberrypi"?
Yes, this driver is for part of the Raspberry Pi Foundation's firmware
code (you can find the same pattern in the firmware and firmware power
domain drivers).
>> +- gpio-controller: Marks the device node as a gpio controller
>> +- #gpio-cells: Should be <2> for GPIO number and flags
>> +- ngpios: Number of GPIO lines to control. See gpio.txt
>
> Is this ever anything else than 8? Else omit it and hardcode
> 8 in the driver instead.
(see below)
>> +- firmware: Reference to the RPi firmware device node
>
> Reference the DT binding for this.
>
>> +- raspberrypi,firmware-gpio-offset:
>> + Number the firmware uses for the first GPIO line
>> + controlled by this driver
>
> Does this differ between different instances of this hardware or
> can it just be open coded in the driver instead?
This is which range (128-135) of the firmware's GPIOs we're controlling.
If another GPIO expander appears later (quite believable, I think
they're down to 1 spare line on this expander), then we would just make
another node with a new offset and ngpios for that expander.
Sort of related: I also worry that we have races with the firmware for
the platform GPIO bits, since both ARM and firmware are doing RMWs (or,
even worse, maybe just Ws?) of the registers controlled by the pinctrl
driver. Hopefully I can get the firmware to pass control of devices
like this over to Linux, with firmware making requests to us, but I
don't know if that will happen and we may need to access other GPIOs
using this interface :(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160923/2ef4c585/attachment.sig>
^ permalink raw reply
* [GIT PULL] arm64 fixes for 4.8
From: Catalin Marinas @ 2016-09-23 13:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull a couple of last-minute arm64 fixes for 4.8. Thanks.
The following changes since commit 3be7988674ab33565700a37b210f502563d932e6:
Linux 4.8-rc7 (2016-09-18 17:27:41 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to 67787b68ec48c239d5ec12f9bf5adaf5c459517a:
arm64: kgdb: handle read-only text / modules (2016-09-23 11:25:01 +0100)
----------------------------------------------------------------
- Fix secondary CPU to NUMA node assignment
- Fix kgdb breakpoint insertion in read-only text sections (when
CONFIG_DEBUG_RODATA or CONFIG_DEBUG_SET_MODULE_RONX are enabled)
----------------------------------------------------------------
AKASHI Takahiro (1):
arm64: kgdb: handle read-only text / modules
David Daney (1):
arm64: Call numa_store_cpu_info() earlier.
arch/arm64/include/asm/debug-monitors.h | 2 --
arch/arm64/kernel/kgdb.c | 36 ++++++++++++++++++++++-----------
arch/arm64/kernel/smp.c | 14 ++++++-------
3 files changed, 30 insertions(+), 22 deletions(-)
--
Catalin
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Lorenzo Pieralisi @ 2016-09-23 13:09 UTC (permalink / raw)
To: linux-arm-kernel
Current vexpress smp init code detects whether to override the
default smp ops with MCPM smp ops by matching the "cci-400"
compatible string, in that MCPM requires control over CCI ports
to manage low-power states entry/exit.
The "cci-400" compatible string check is a necessary but not
sufficient condition for MCPM to work, because the cci-400
can be made visible to the kernel, but firmware can nonetheless
disable non-secure CCI ports control, while still allowing PMU
access; if booted in non-secure world, the kernel would still
blindly override smp operations with MCPM operations, resulting
in kernel faults when the CCI ports programming interface is
accessed from non-secure world.
This means that the "cci-400" compatible string check would
result in a false positive in systems that eg boot in HYP mode,
where CCI ports non-secure access is explicitly not allowed,
and it is reported in the respective device tree nodes with
CCI ports marked as disabled.
Refactor the smp operations initialization to make sure that
the kernel is actually allowed to take control over CCI ports
(by enabling MCPM smp operations) before overriding default
vexpress smp operations.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index 8b8d072..6cfd782 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -26,17 +26,34 @@
bool __init vexpress_smp_init_ops(void)
{
#ifdef CONFIG_MCPM
+ int cpu;
+ struct device_node *cpu_node, *cci_node;
+
/*
- * The best way to detect a multi-cluster configuration at the moment
- * is to look for the presence of a CCI in the system.
+ * The best way to detect a multi-cluster configuration
+ * is to detect if the kernel can take over CCI ports
+ * control. Loop over possible CPUs and check if CCI
+ * port control is available.
* Override the default vexpress_smp_ops if so.
*/
- struct device_node *node;
- node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
- if (node && of_device_is_available(node)) {
- mcpm_smp_set_ops();
- return true;
+ for_each_possible_cpu(cpu) {
+ bool available;
+
+ cpu_node = of_get_cpu_node(cpu, NULL);
+ if (WARN(!cpu_node, "Missing cpu device node!"))
+ return false;
+
+ cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
+ available = cci_node && of_device_is_available(cci_node);
+ of_node_put(cci_node);
+ of_node_put(cpu_node);
+
+ if (!available)
+ return false;
}
+
+ mcpm_smp_set_ops();
+ return true;
#endif
return false;
}
--
2.10.0
^ permalink raw reply related
* [PATCH 2/2] drivers: cci: add missing CCI port availability firmware check
From: Lorenzo Pieralisi @ 2016-09-23 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923130907.4187-1-lorenzo.pieralisi@arm.com>
The CCI ports programming interface is available to the kernel
only when booted in secure mode (or when firmware enables
non-secure access to override CCI ports control). In both cases,
firmware reports the CCI ports availability through the device
tree CCI ports nodes, which must be parsed and their status checked
by the kernel probing path.
This check is currently missing and may cause the kernel to
erroneously believe it is free to take control of CCI ports
where in practice CCI ports control is forbidden.
Add the missing CCI port availability check to the CCI driver
in order to guarantee sane CCI usage.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/bus/arm-cci.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 5755907f..3c7a1c7 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -2199,6 +2199,9 @@ static int cci_probe_ports(struct device_node *np)
if (!of_match_node(arm_cci_ctrl_if_matches, cp))
continue;
+ if (!of_device_is_available(cp))
+ continue;
+
i = nb_ace + nb_ace_lite;
if (i >= nb_cci_ports)
@@ -2241,6 +2244,13 @@ static int cci_probe_ports(struct device_node *np)
ports[i].dn = cp;
}
+ /*
+ * If there is no CCI port that is under kernel control
+ * return early and report probe status.
+ */
+ if (!nb_ace && !nb_ace_lite)
+ return -ENODEV;
+
/* initialize a stashed array of ACE ports to speed-up look-up */
cci_ace_init_ports();
--
2.10.0
^ permalink raw reply related
* [PATCH] iommu/arm-smmu: Work around ARM DMA configuration
From: Robin Murphy @ 2016-09-23 13:11 UTC (permalink / raw)
To: linux-arm-kernel
The 32-bit ARM DMA configuration code predates the IOMMU core's default
domain functionality, and instead relies on allocating its own domains
and attaching any devices using the generic IOMMU binding to them.
Unfortunately, it does this relatively early on in the creation of the
device, before we've seen our add_device callback, which leads us to
attempt to operate on a half-configured master.
To avoid a crash, check for this situation on attach, but refuse to
play, as there's nothing we can do. This at least allows VFIO to keep
working for people who update their 32-bit DTs to the generic binding,
albeit with a few (innocuous) warnings from the DMA layer on boot.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c841eb7a1a74..3af7f8f62d0a 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1228,6 +1228,16 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
return -ENXIO;
}
+ /*
+ * FIXME: The arch/arm DMA API code tries to attach devices to its own
+ * domains between of_xlate() and add_device() - we have no way to cope
+ * with that, so until ARM gets converted to rely on groups and default
+ * domains, just say no (but more politely than by dereferencing NULL).
+ * This should be at least a WARN_ON once that's sorted.
+ */
+ if (!fwspec->iommu_priv)
+ return -ENODEV;
+
smmu = fwspec_smmu(fwspec);
/* Ensure that the domain is finalised */
ret = arm_smmu_init_domain_context(domain, smmu);
--
2.8.1.dirty
^ permalink raw reply related
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Stuart Yoder @ 2016-09-23 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f4195baa-907d-2c00-eb62-d4452ed749c8@arm.com>
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Friday, September 23, 2016 7:17 AM
> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: Jason Jin <jason.jin@nxp.com>
> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>
> Hi Alison,
>
> On 23/09/16 03:19, Alison Wang wrote:
> > The ARMv8 architecture supports:
> > 1. 64-bit execution state, AArch64.
> > 2. 32-bit execution state, AArch32, that is compatible with previous
> > versions of the ARM architecture.
> >
> > LayerScape platforms are compliant with ARMv8 architecture. This patch
> > is to support running 32-bit Linux kernel for LayerScape platforms.
> >
> > Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
> >
> > Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> > Signed-off-by: Alison Wang <alison.wang@nxp.com>
> > ---
> > arch/arm/Kconfig | 9 +++++++++
> > arch/arm/mach-imx/Kconfig | 14 ++++++++++++++
> > arch/arm/mach-imx/Makefile | 4 +++-
> > arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
> > 4 files changed, 49 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/mach-imx/mach-layerscape.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index f0c8068..e8d470e 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
> > default 3 if ARM_LPAE
> > default 2
> >
> > +config ARCH_AARCH32_ES_SUPPORT
> > + def_bool n
> > + help
> > + The ARMv8 architecture supports 64-bit execution state, AArch64
> > + and 32-bit execution state, AArch32, that is compatible with
> > + previous versions of the ARM architecture.
> > +
> > + Enable AArch32 execution state support for ARMv8 architecture.
>
> What's this supposed to do, exactly? I've been running 32-bit kernels on
> my Juno with very little issue (beyond a couple of DT tweaks, and some
> firmware hacks with a corresponding bit of A64 assembly tacked on the
> front of the zImage to switch into AArch32 state).
Which arch/arm/mach-* platform are you using for Juno?
Thanks,
Stuart
^ permalink raw reply
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Eric Anholt @ 2016-09-23 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda6HpJp97FUAh6yvo-BhiDbAXxzQS9U6uT+jvg6hiB8ag@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt <eric@anholt.net> wrote:
>
>> This driver will be used for accessing the FXL6408 GPIO exander on the
>> Pi3. We can't drive it directly from Linux because the firmware is
>> continuously polling one of the expander's lines to do its
>> undervoltage detection.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
> (...)
>
>> +config GPIO_RASPBERRYPI
>> + tristate "Raspberry Pi firmware-based GPIO access"
>> + depends on OF_GPIO && RASPBERRYPI_FIRMWARE && (ARCH_BCM2835 || COMPILE_TEST)
>> + help
>> + Turns on support for using the Raspberry Pi firmware to
>> + control GPIO pins. Used for access to the FXL6408 GPIO
>> + expander on the Pi 3.
>
> Maybe it should be named GPIO_RPI_FXL6408 ?
>
> (No strong opinion.)
See DT binding comment -- I think since this driver has no dependency on
being to the 6408 on the pi3, we shouldn't needlessly bind it to the
FXL6408. (the help comment was just context for why you would want the
driver today).
>> +static int rpi_gpio_dir_in(struct gpio_chip *gc, unsigned off)
>> +{
>> + /* We don't have direction control. */
>> + return -EINVAL;
>> +}
>> +
>> +static int rpi_gpio_dir_out(struct gpio_chip *gc, unsigned off, int val)
>> +{
>> + /* We don't have direction control. */
>> + return -EINVAL;
>> +}
>
> IMO this should return OK if you try to set it to the direction
> that the line is hardwired for in that case, not just fail everything.
>
> If you return errors here, any generic driver that tries to
> set the line as input or output will fail and then require a
> second workaround in that driver if it is used on rpi etc etc.
>
> Try to return zero if the consumer asks for the direction that
> the line is set to.
>
> Also implement .get_direction(). Doing so will show how to
> do the above two calls in the right way.
I was worried about the lack of direction support. The firmware
interface doesn't give me anything for direction, and a get or set
of the value doesn't try to set direction.
I can try to bother them to give me support for that, but if they
cooperate on that it means that users will only get HDMI detection once
they update firmware.
The alternative to new firmware interface would be to provide a bunch of
DT saying which of these should be in/out at boot time and refuse to
change them after that. That seems like a mess, though.
>> +static void rpi_gpio_set(struct gpio_chip *gc, unsigned off, int val)
>> +{
>> + struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
>> + u32 packet[2] = { rpi->offset + off, val };
>> + int ret;
>> +
>> + ret = rpi_firmware_property(rpi->firmware,
>> + RPI_FIRMWARE_SET_GPIO_STATE,
>> + &packet, sizeof(packet));
>> + if (ret)
>> + dev_err(rpi->dev, "Error setting GPIO %d state: %d\n", off, ret);
>> +}
>> +
>> +static int rpi_gpio_get(struct gpio_chip *gc, unsigned off)
>> +{
>> + struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
>> + u32 packet[2] = { rpi->offset + off, 0 };
>> + int ret;
>> +
>> + ret = rpi_firmware_property(rpi->firmware,
>> + RPI_FIRMWARE_GET_GPIO_STATE,
>> + &packet, sizeof(packet));
>> + if (ret) {
>> + dev_err(rpi->dev, "Error getting GPIO state: %d\n", ret);
>> + return ret;
>> + } else if (packet[0]) {
>> + dev_err(rpi->dev, "Firmware error getting GPIO state: %d\n",
>> + packet[0]);
>> + return -EINVAL;
>> + } else {
>> + return packet[1];
>> + }
>
> You can just remove the last } else { } clause and return on a
> single line.
>
> Please do it like this though:
>
> return !!packet[1];
>
> So you clamp the returned value to a boolean.
Will do.
>> + rpi->gc.get = rpi_gpio_get;
>> + rpi->gc.set = rpi_gpio_set;
>> + rpi->gc.can_sleep = true;
>> +
>> + ret = gpiochip_add(&rpi->gc);
>> + if (ret)
>> + return ret;
>
> Use devm_gpiochip_add_data() and pass NULL as data
> so you can still use the devm* function.
Oh, nice.
>> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
>> index 3fb357193f09..671ccd00aea2 100644
>> --- a/include/soc/bcm2835/raspberrypi-firmware.h
>> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
>> @@ -73,11 +73,13 @@ enum rpi_firmware_property_tag {
>> RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE = 0x00030014,
>> RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
>> RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
>> + RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
>> RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
>> RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
>> RPI_FIRMWARE_SET_VOLTAGE = 0x00038003,
>> RPI_FIRMWARE_SET_TURBO = 0x00038009,
>> RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
>> + RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
>
> Can you please merge this orthogonally into the rpi tree to ARM SoC?
This driver would appear in the rpi downstream tree once we settle the
driver here. Or are you asking me to delay this series until I can get
them to pull just a patch extending the set of packets?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160923/83848ae6/attachment.sig>
^ permalink raw reply
* [PATCH] drm/sun4i: rgb: Enable panel after controller
From: Maxime Ripard @ 2016-09-23 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB2pmO7AMqmE9SMR1vFFsY5jMUALGSvtd=AvpU1=_jSHUw@mail.gmail.com>
On Thu, Sep 22, 2016 at 08:03:31AM +1000, Jonathan Liu wrote:
> Hi Maxime,
>
> On Thursday, 22 September 2016, Maxime Ripard <maxime.ripard@free-electrons.
> com> wrote:
>
> > On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote:
> > > The panel should be enabled after the controller so that the panel
> > > prepare/enable delays are properly taken into account. Similarly, the
> > > panel should be disabled before the controller so that the panel
> > > unprepare/disable delays are properly taken into account.
> > >
> > > This is useful for avoiding visual glitches.
> >
> > This is not really taking any delays into account, especially since
> > drm_panel_enable and prepare are suppose to block until their
> > operation is complete.
>
>
> drm_panel_prepare turns on power to the LCD using enable-gpios property of
> the panel and then blocks for prepare delay. The prepare delay for panel
> can be set to how long it takes between the time the panel is powered to
> when it is ready to receive images. If backlight property is specified the
> backlight will be off while the panel is powered on.
>
> drm_panel_enable blocks for enable delay and then turns on the backlight.
> The enable delay can be set to how long it takes for panel to start making
> the image visible after receiving the first valid frame. For example if the
> panel starts off as white and the TFT takes some time to initialize to
> black before it shows the image being received.
>
> Refer to drivers/gpu/drm/panel-panel.simple.c for details.
>From drm_panel.h:
"""
* drm_panel_enable - enable a panel
* @panel: DRM panel
*
* Calling this function will cause the panel display drivers to be turned on
* and the backlight to be enabled. Content will be visible on screen after
* this call completes.
"""
"""
* drm_panel_prepare - power on a panel
* @panel: DRM panel
*
* Calling this function will enable power and deassert any reset signals to
* the panel. After this has completed it is possible to communicate with any
* integrated circuitry via a command bus.
"""
Those comments clearly says that the caller should not have to deal
with the delays, even more so by just moving calls around and hoping
that the code running in between is adding enough delay for the panel
to behave properly.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160923/1be13bd7/attachment.sig>
^ permalink raw reply
* [PATCH v6 3/4] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Marc Zyngier @ 2016-09-23 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-3-git-send-email-oss@buserror.net>
On 22/09/16 09:35, Scott Wood wrote:
> Erratum A-008585 says that the ARM generic timer counter "has the
> potential to contain an erroneous value for a small number of core
> clock cycles every time the timer value changes". Accesses to TVAL
> (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
>
> The workaround is to reread TVAL and count registers until successive
> reads return the same value. Writes to TVAL are replaced with an
> equivalent write to CVAL.
>
> The workaround is to reread TVAL and count registers until successive reads
> return the same value, and when writing TVAL to retry until counter
> reads before and after the write return the same value.
>
> The workaround is enabled if the fsl,erratum-a008585 property is found in
> the timer node in the device tree. This can be overridden with the
> clocksource.arm_arch_timer.fsl-a008585 boot parameter, which allows KVM
> users to enable the workaround until a mechanism is implemented to
> automatically communicate this information.
>
> This erratum can be found on LS1043A and LS2080A.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> ---
> v6:
> - Addressed feedback from Mark Rutland
>
> v5:
> - Export arch_timer_read_ool_enabled so that get_cycles() can be called
> from modules.
>
> v4:
> - Undef ARCH_TIMER_REG_READ after use
>
> v3:
> - Used cval rather than a loop for the write side of the erratum
> - Added a Kconfig control
> - Moved the device tree binding into its own patch
> - Added erratum to silicon-errata.txt
> - Changed function names to contain the erratum name
> - Factored out the setting of erratum versions of set_next_event
> to improve readability
> - Added a comment clarifying that the timeout is arbitrary
>
> v2:
> Significant rework based on feedback, including using static_key,
> disabling VDSO counter access rather than adding the workaround to the
> VDSO, and uninlining the loops.
>
> Dropped the separate property for indicating that writes to TVAL are
> affected, as I believe that's just a side effect of the implicit
> counter read being corrupted, and thus a chip that is affected by one
> will always be affected by the other.
>
> Dropped the arm32 portion as it seems there was confusion about whether
> LS1021A is affected. Currently I am being told that it is not
> affected.
>
> I considered writing to CVAL rather than looping on TVAL writes, but
> that would still have required separate set_next_event() code for the
> erratum, and adding CVAL to the enum would have required a bunch of
> extra handlers in switch statements (even where unused, due to compiler
> warnings about unhandled enum values) including in an arm32 header. It
> seemed better to avoid the arm32 interaction and new untested
> accessors.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> ---
> Documentation/arm64/silicon-errata.txt | 2 +
> Documentation/kernel-parameters.txt | 9 +++
> arch/arm64/include/asm/arch_timer.h | 47 ++++++++++++++-
> drivers/clocksource/Kconfig | 10 ++++
> drivers/clocksource/arm_arch_timer.c | 104 +++++++++++++++++++++++++++++++++
> 5 files changed, 169 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
> index 4da60b4..041e3a9 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -60,3 +60,5 @@ stable kernels.
> | Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
> +| | | | |
> +| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 46c030a..fb4de4d 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -698,6 +698,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> loops can be debugged more effectively on production
> systems.
>
> + clocksource.arm_arch_timer.fsl-a008585=
> + [ARM64]
> + Format: <bool>
> + Enable/disable the workaround of Freescale/NXP
> + erratum A-008585. This can be useful for KVM
> + guests, if the guest device tree doesn't show the
> + erratum. If unspecified, the workaround is
> + enabled based on the device tree.
> +
> clearcpuid=BITNUM [X86]
> Disable CPUID feature X for the kernel. See
> arch/x86/include/asm/cpufeatures.h for the valid bit
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index 7ff386c..cddd5b7 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -24,10 +24,51 @@
>
> #include <linux/bug.h>
> #include <linux/init.h>
> +#include <linux/jump_label.h>
> #include <linux/types.h>
>
> #include <clocksource/arm_arch_timer.h>
>
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
> +extern struct static_key_false arch_timer_read_ool_enabled;
> +#define needs_fsl_a008585_workaround() \
> + static_branch_unlikely(&arch_timer_read_ool_enabled)
> +#else
> +#define needs_fsl_a008585_workaround() false
> +#endif
> +
> +u32 __fsl_a008585_read_cntp_tval_el0(void);
> +u32 __fsl_a008585_read_cntv_tval_el0(void);
> +u64 __fsl_a008585_read_cntvct_el0(void);
> +
> +/*
> + * The number of retries is an arbitrary value well beyond the highest number
> + * of iterations the loop has been observed to take.
> + */
> +#define __fsl_a008585_read_reg(reg) ({ \
> + u64 _old, _new; \
> + int _retries = 200; \
> + \
> + do { \
> + _old = read_sysreg(reg); \
> + _new = read_sysreg(reg); \
> + _retries--; \
> + } while (unlikely(_old != _new) && _retries); \
> + \
> + WARN_ON_ONCE(!_retries); \
> + _new; \
> +})
> +
> +#define arch_timer_unstable_reg_read(reg) \
I think this name is the only thing I don't like about this patch,
because it is only unstable if the workaround is on. This is a minor
thing and it can be addressed when/after merging it. No need to respin
it on this account.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
The usual question is "Who takes it?". I'm quite keen on it, as my
LS2085 is otherwise completely unusable.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Robin Murphy @ 2016-09-23 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR0401MB2638049F479731B3CC903B248DC80@VI1PR0401MB2638.eurprd04.prod.outlook.com>
On 23/09/16 14:13, Stuart Yoder wrote:
>
>
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>> Sent: Friday, September 23, 2016 7:17 AM
>> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
>> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
>> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
>> <leoyang.li@nxp.com>
>> Cc: Jason Jin <jason.jin@nxp.com>
>> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>>
>> Hi Alison,
>>
>> On 23/09/16 03:19, Alison Wang wrote:
>>> The ARMv8 architecture supports:
>>> 1. 64-bit execution state, AArch64.
>>> 2. 32-bit execution state, AArch32, that is compatible with previous
>>> versions of the ARM architecture.
>>>
>>> LayerScape platforms are compliant with ARMv8 architecture. This patch
>>> is to support running 32-bit Linux kernel for LayerScape platforms.
>>>
>>> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
>>>
>>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>>> ---
>>> arch/arm/Kconfig | 9 +++++++++
>>> arch/arm/mach-imx/Kconfig | 14 ++++++++++++++
>>> arch/arm/mach-imx/Makefile | 4 +++-
>>> arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
>>> 4 files changed, 49 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/mach-imx/mach-layerscape.c
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index f0c8068..e8d470e 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
>>> default 3 if ARM_LPAE
>>> default 2
>>>
>>> +config ARCH_AARCH32_ES_SUPPORT
>>> + def_bool n
>>> + help
>>> + The ARMv8 architecture supports 64-bit execution state, AArch64
>>> + and 32-bit execution state, AArch32, that is compatible with
>>> + previous versions of the ARM architecture.
>>> +
>>> + Enable AArch32 execution state support for ARMv8 architecture.
>>
>> What's this supposed to do, exactly? I've been running 32-bit kernels on
>> my Juno with very little issue (beyond a couple of DT tweaks, and some
>> firmware hacks with a corresponding bit of A64 assembly tacked on the
>> front of the zImage to switch into AArch32 state).
>
> Which arch/arm/mach-* platform are you using for Juno?
I don't even know! :) I just start with a multi_v7_defconfig plus a few
extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
combination of mach-vexpress and mach-virt.
Robin.
>
> Thanks,
> Stuart
>
^ permalink raw reply
* [PATCH 01/10] [v3] dt-bindings: fsl: update for more SoCs
From: Rob Herring @ 2016-09-23 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-2-git-send-email-shh.xie@gmail.com>
On Tue, Sep 13, 2016 at 04:09:54PM +0800, shh.xie at gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
The subject could be more specific: "Add LS1043A/LS1046A/LS2080A SoC
compatible strings"
>
> Adds SoC compatible for LS1043A and LS2080A which are supported, and
> for LS1046A which is going to be supported.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
> changes in V3:
> 1. new patch.
>
> Documentation/devicetree/bindings/arm/fsl.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Otherwise,
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH 02/10][v3] dt-bindings: fsl: updates bindings for some SoC-specific devices
From: Rob Herring @ 2016-09-23 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-3-git-send-email-shh.xie@gmail.com>
On Tue, Sep 13, 2016 at 04:09:55PM +0800, shh.xie at gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
Again, subject could still be more specific. Aim to make it unique
enough that the same subject could never appear again.
> SCFG and DCFG are SoC-specific devices can be found on SoCs like LS1021A,
> LS1043A and LS1046A, this patch updates bindings for SCFG and DCFG to
> reflect more SoCs.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
> changes in V3:
> 1. added supported <chip>s.
>
> change in V2:
> 1. new patch.
>
> Documentation/devicetree/bindings/arm/fsl.txt | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 04/10] [v3] dt-bindings: qoriq-clock: update for more SoCs
From: Rob Herring @ 2016-09-23 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-5-git-send-email-shh.xie@gmail.com>
On Tue, Sep 13, 2016 at 04:09:57PM +0800, shh.xie at gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
>
> Adds compatible for SoCs which use clockgen, the SoCs are LS1043A,
> LS1046A, LS2080A.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
> change in v3:
> 1. new patch.
>
> Documentation/devicetree/bindings/clock/qoriq-clock.txt | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox